On 2025-02-12 10:22:14, Nils Bruin wrote: > In my opinion, this problem is commonly solved nowadays by curated software > distributions (through stores, trusted package repositories, etc.) with > keys that are predistributed with the operating system used. The integrity > control is then offloaded from the end-user to the distribution > maintainers. How do package maintainers protect against getting fed > compromised sources?
As the joke goes, very carefully. There are two different aspects of this problem. First, developers need to verify the sources they get from upstream, and second, users need to verify the sources they get from developers by way of untrusted mirrors. New distribution developers are taught several ways to verify the sources that they download. HTTPS isn't great, but is preferable to plain HTTP in this regard. Many upstreams advertise their public keys across multiple channels. If you can confirm that the key posted to the project's public HTTPS page is the same as the key in the maintainer's email signature for the past five years, and the same one posted on Github (or whatever), then that's a pretty good indicator. You can ask your fellow developers to confirm this from another country. Even better if you can meet them at FOSDEM or some equivalent conference. To strengthen this chain of trust and make it easier to verify, we have packages for many of these keys: https://packages.gentoo.org/categories/sec-keys These are shipped to each developer and user via the usual means. When a developer is adding a new version of a package, they can set a flag to have the package manager verify the signature on the tarball against the right sec-keys package. The developer then signs the hash of the tarball with his own key, which you implicitly trust by way of turtles upon turtles going back to the installation of the OS. That's just for developers. To get these packages to end users, we need to get the signed hashes of both the upstream tarballs and our build scripts to the users and then verify them. Again we do this via packages, all signed with gentoo.org keys that you implicitly trust. The rsync mirrors can change whatever they want, but the package manager verifies everything that it receives from the rsync mirrors before those changes "go live." The package manager is also implicitly trusted (it comes with the OS), so there is a chain of trust going back to the installation of the OS, at which point you were supposed to say a prayer. Most distributions have a similar system. It can't be replicated within sage (or on pypi et al.), and everyone who wants to address these sorts of problems is already a developer for some distribution, and we all suggest that you get your sage packages from the distribution in the first place :) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/Z609T5PCtOWYrYEu%40mertle.
