Ansgar 🙀 <ans...@43-1.org> writes: > On Fri, 2024-06-21 at 16:55 +0200, Matthias Urlichs wrote:
>> Umm, no. We're not dropping the check; we required a maintainer's >> signature before, and we still do so after. We just place a >> packaging-and-possibly-source-mangling server between A and B. > So we drop the integrity check using the maintainer's signature in the > archive... You do not now and never have had an integrity check that uses the maintainer's signature. The person signing the source package did not check its integrity, and therefore all the crypto and hashing in the world does not translate into an integrity check. You cannot create an integrity check out of thin air if nothing ever checked the integrity in the first place. This is Matthias's point. You can safely derive only two pieces of information from the maintainer signature on a package upload: 1. The maintainer wants to upload this package with this version (intent). 2. The maintainer thinks this source package represents their intent. Both of these are still true with tag2upload. The tag2upload Git tag signature includes metadata in which the maintainer clearly says "I want tag2upload to build the source package and I trust it to represent my intent." There is no integrity check on the contents of the source package, because the maintainer didn't make one. There will not be an integrity check on the contents of the Git tag either, because the maintainer didn't make one, although some integrity problems with the Git tag are going to be a lot easier to detect after the fact because of how Git works. (For example, some problems will be detectable by noticing that the Git tag does not correspond to any commit in the direct branch history of the relevant branch.) You don't even know that the maintainer built the source package on their own machine. Here is a thing someone could do today that dak would be perfectly happy with, but which would be worse than tag2upload in basically every respect: 1. Set up a Salsa CI job to build a source package on tag push. 2. Push an unsigned tag for a new Debian release to kick off that job. 3. Download the resulting artifacts, sign them, and upload them. This trusts the Salsa Git repository, CI, and artifact store with all of their huge attack surface, loses the traceability to a signed Git tag, and loses any indication in the archive of how the package was built. And yet dak treats this as perfectly fine, because the dak security model is "blindly trust the uploader." tag2upload implements this workflow properly, closing multiple potential security vulnerabilities (and providing a much nicer UI), and yet you would reject its uploads because you're fixated on the maintainer signature as the only possible measure of integrity. Even though the maintainer signature does not and never has represented an integrity check, as I would hope that example makes obvious. You're not even trusting the maintainer to decide what constitutes an adequate check for their package. You blindly trust any decision that the maintainer makes provided that it's expressed in the form of a signature on a source package, but if the uploader says "I want to trust this piece of project infrastructure to do this for me," you're saying no, you're not allowed to do that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
