duncan­lock­.net

In this When Will We Learn post, Drew DeVault talks about supply chain attacks against language package managers (npm, PyPI, cargo, etc…​) - and compares them to official Linux distribution repositories (deb, rpm, etc…​).

The conclusion drawn was:

The correct way to ship packages is with your distribution’s package manager. These have a separate review step, completely side-stepping typo-squatting, establishing a long-term relationship of trust between the vendor and the distribution packagers, and providing a dispassionate third-party to act as an intermediary between users and vendors. Furthermore, they offer stable distributions which can be relied upon for an extended period of time, provide cohesive whole-system integration testing, and unified patch distribution and CVE notifications for your entire system.

I think I agree with this, essentially. We do need to change the way we do …

Continue reading “Supply Chain Attacks & Package Managers - a Solution?”

Two screenshots of the nginx Welcome page, side-by-side, showing the page before the change and afterwards. The one on the left is dark-on-light and the one on the right is light-on-dark.
Figure 1. The nginx “Welcome” page, before & after my intended change.

I wanted to add dark mode support to the default nginx “Welcome to nginx” page. This is about the simplest change I could choose to make - it’s a simple, backwards compatible, small additive change to one single index.html file. My initial version of this change looks like this, and is added to the files <style> element, in the <head> section:

@media (prefers-color-scheme: dark) {
  body {
    background-color: #363839;
    color: #d1cec9;
  }
  a {
    color: #c4c4ff;
  }
}

So, this is the process of getting that change from my brain, into the upstream nginx codebase. 

Continue reading “How to Contribute a Change to Nginx”