Not much new here, the article mostly takes us over well trodden ground. But the second line was an eye opener: > This time, it is Google’s turn. [0] I guess

Not much new here, the article mostly takes us over well trodden ground. But the second line was an eye opener: > This time, it is Google’s turn. [0] I guess my reading of it must be tainted by reading this "real names'' critique first, but ye gods, it seems these people telling Open Source how it must improve its practices have no idea that Open Source has mostly solved the problems it seeks to address. The problem isn't knowing what has to happen. The problem is the people/companies using the output of Open Source simply don't care or don't contribute. Some illustrations of their suggestions. On the anonymity point first, Google's blog post says: > Goal: For Critical Software, Owners and Maintainers Cannot be Anonymous. Attackers like to have anonymity. Attackers like to have anonymity. There have been past supply-chain attacks where attackers capitalized on anonymity and worked their way through package communities to become maintainers Firstly, Debian does insist its developers provide government ID. I'm tempted to start ranting in strong agreeance with the article about how weak that is, but my point is - it's being done. In fact most things they list are done by Debian, and if not by Debian then by other projects. For example: > Goal: Authentication for Participants in Critical Software All contributions by a Debian developer must be signed with their gpg public key, minimum length 4096 bits. Or take this one: > Goal: Changes to Critical Software Require Approval by Two Independent Parties Debian does this to some extent but the kernel is exemplary in this regard. They insist every patch is signed off. It's no accident git provides a cryptographically secure audit trail of the origin of every line of code. > Goal: A Federated Model for Identities Debian has a public ldap database. Other projects use email identities, and open source has public gpg key servers for decades. > Goal: Trust the Build Process ... Ken Thompson's Turing Award lecture famously demonstrated in 1984 that authentic source code alone is not enough, and recent events have shown this attack is a real threat. Debian has literally pioneered the solution to this, reproducible builds. They acknowledge reproducible builds (but not Debian), go on to say "but are harder to achieve due to ephemeral data (such as timestamps) ending up in the release artefact". Apparently not so hard, because Debian has got around 80% of its archive to build reproducibly and open sourced how to do it. The open source project F-Droid is doing the same work for Google's own product (Android), which is also unacknowledged. [1] [2] > Goal: Fix the Widely Used Versions ... It’s also important to fix the vulnerability in the older versions, And that is, with the exception of a few packages that have now become so complex even backporting simple fixes is beyond a team of Debian Developers, is exactly what Debian does. To wit: for the 60,000 packages in it's released versions of software, Debian backports security fixes to the old version rather than moving to the new version. Yes, it’s an immense effort, but it is the right way to do it so it’s what is done. I could go on addressing the things they raise, but I hope the point is made. Open source knows how to do this stuff. That is not the problem. The last point above illustrates the real problem. Debian is regularly criticised here on HN for being too slow, too conservative. That's a direct consequence of the "backport only" policy, of course. It seems a _lot_ of people aren't prepared to put up with the pain it causes, or perhaps it is they don’t understand how the advantages it brings justifies the pain for many. The users probably aren’t aware of it, but it causes even more pain for Debian itself. Part of it arises from Debian’s absolute insistence audit trail it insists on: binary in archive -> "the source the human wrote" -> licence -> copyright owner. The original motivation for that was ensuring Debian is truly open source, how it meshes with the security via accountability aspects the Google blog is championing is obvious. Upstream projects that mix sources with lots of licences can make merely writing that trail down for every source file an epic task, eg: [3] But it’s not just size, some developers go further. They include “non-source forms” of unversioned software in their source, eg a minimised version of some ancient version jquery - or worse, some version they’ve tweak (hack it) a little. The Debian packager then has to go on a whumpus hunt trying to figure out what version, and if they modified it, and if the version in Debian suffice. If it doesn't they can't add another version of jquery to Debian, because doing that for every package would lead to an unmanageable explosion in the backporting work every jquery vulnerability would cause. It's not just npm, if a Python developer says "to use my package, do a pip install" and the package has a pinned dependency like =x.y.z the people who package the software, ie the open source people who have already solved the problems the Google blog is telling us how to solve, get a more grey hairs. But the thing that has literally forced distro packagers to literally give up on backporting fixes is packages that have grown too complex for a part time person to understand. Firefox is one example. But Mozilla is also a fine upstanding example of how to mitigate the problem: they publish Firefox ESR, which is, ta-da, a version of Firefox _they_ backport fixes to. We love you, Mozilla. You understand how security and reliability arise from change control. Other examples of huge complex packages Debian can't maintain the way the blog suggests are Kubernetes, and Chromium. They are packages produced by Google, of course. Unlike Mozilla, Google offers no help and makes no concessions to others for maintaining the stability and security of their packages. And here we have a blog article from Google, telling open source how to make its ecosystems more secure. The irony would be delicious, if it wasn’t so painful. [0] https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html https://security.googleblog.com/2021/02/know-prevent-fix-fra... [1] https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds [2] https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ [3] https://metadata.ftp-master.debian.org/changelogs//main/c/chromium/chromium_87.0.4280.141-0.1~deb10u1_copyright https://metadata.ftp-master.debian.org/changelogs//main/c/ch...