That perception is correct. It's limited because in practice Debian developers (being almost entirely volunteers!) don't have the resources to read and audit each line in an upstream release, so certainly intentionally obfuscated backdoors from a previously trustworthy upstream would almost certainly get through. But the type of attack in this article, with a new binary and an unwanted line of shell script to run it, would be very unlikely to get through.

There's also a limited set of people who can upload new packages and a separate team that reviews those, so duplicated functionality / low-quality apps are unlikely to make it into the archive in the first place. Yet Another 2048 Clone would probably not be allowed in unless it was part of e.g. an official GNOME game set.

It also helps that Debian insists on recompiling everything from source and does not redistribute binaries from an upstream source, even if freely-licensed source code is provided.

Thanks a lot for clarifying these things. Do they do any identity verification so people can be held accountable after the fact if something shady were to be discovered?

Yes.

> All work in Debian is performed by developers that can be identified. For those using Debian to be able to trust Debian, we feel it is important that our users can identify those that are working on the project and that development is as transparent as is possible. [0]

I don't personally use Debian very much these days -- my desktops all run Fedora, my servers (with a few exceptions) run CentOS and RHEL -- but I used Debian exclusively for many, many years and out of all Linux distributions Debian (IMO, of course) comes the closest to doing things "the right way". In and of itself, that is pretty amazing, I think, considering that there isn't really all that much that has changed in its 25 year history! In other words, they somehow managed to get things right the first time around.

There are a few things that could perhaps be done a little better or different but -- considering that Debian is an all-volunteer project -- I think they manage to do an awesome job with the limited resources available to them.

[0]: https://wiki.debian.org/DebianKeyring

Yes, that's part of why Debian uses PGP keys for package uploads and insists that your key is signed by other Debian developers and not simply anyone in the web of trust. (I am aware of one Debian developer who contributes / is known to the community by a pseudonym, but I'm told that a few other senior people in Debian know this person's legal name for this exact reason.)

While full auditing is impossible for any distribution, Debian has a multiple people eyeballing code.

Apart the package maintainers and contributors, the Security Team can also review critical packages and step in if something looks suspicious.

But, most importantly, the release cycle and the long freeze before releases is all about STABILITY and SECURITY.

Anybody can upload backdoored code on npm/PyPI etc, infect someone and then remove the malicious release without being detected.

Releasing something malicious or with serious bugs before a freeze cycle and going undetected for months is not impossible but much more difficult.

Your perception is entirely incorrect. Debian maintainers don't have the time (or often the knowledge) to review upstream changes. Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't.

Instead, the reason you don't see malware pushed to those repositories is because the incentives in the free software world don't align to make them happen in the first place. The moment some project would embed phone-home advertising it would be forked and replaced by all the major distros, so it doesn't happen.

There's also an alignment of incentives between upstream and packagers. If e.g. Xorg tried to embed something evil the volunteer contributors to Xorg would pro-actively sound the alarm and tell distros before they shipped that code.

None of this is true in the iOS and Android stores where you have proprietary paid-for apps where the incentive is to extract as much value from the user as the app store in question will allow, and where the upstream maintainers aren't free software advocates but some corporate employees that'll do what they're told at the cost of the wider software community.

It's an adversarial relationship, not a cooperative relationship.

The particular problem with Snappy is all that's submitted is a single binary blob. Usually with free software source code is submitted & built that has multiple mirrors. That alone can make a big difference.

> Debian maintainers don't have the time (or often the knowledge) to review upstream changes > Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't.

This is plain false. While it's impossible to guarantee a 100% code reviews, the number of bugs and vulnerabilities found, reported upstream, and patched by distributions (especially Debian) shows that code is being reviewed.

Every line of code should have been reviewed by at least one DD. But the system is self policing, so it's hard to guarantee that that's the case. But Debian certainly leans towards being a curated collection of software rather than a wild west.

Self-policing? Aren't only DDs allowed to upload to the repositories? From what I understand, dak (the Debian archive management software) won't publish a package which hasn't been approved by a sponsor DD.

The part that's self-policing is that nobody verifies that a DD has in fact reviewed the code that they're signing and uploading (and as another reply points out, for large codebases like the Linux kernel, the maintainer almost certainly doesn't and just trusts the upstream signature).