Scott Kitterman <deb...@kitterman.com> writes: > On Friday, June 14, 2024 5:25:33 PM EDT Russ Allbery wrote:
>> It requires that the signature on the Git tag be correctly checked and >> that fingerprint be put into the *.dsc file, yes. >> It doesn't require that dak then also trust the authorization checks. > Yes. It does. Since DAK has no way to check the signature of the tag > against the keyring, it has to trust the source package signature done > by tag2upload. The only two choices are blindly trust tag2upload is > correct or don't accept uploads from tag2upload. That's exactly what I just said. It has to trust that tag2upload verified the signature on the Git tag correctly. It does not have to trust that tag2upload performed the authorization check correctly; it has the fingerprint and can redo that itself. It is entirely correct that deployment of tag2upload means that there are two separate systems performing the OpenPGP signature verification for upload, and dak has to trust tag2upload's performance of that verification. This is inherent in the design: dak and tag2upload are verifying signatures over different types of objects, and the verification of the tag signature is not useful without also performing the transformation to a source package. That is exactly what the whole tag2upload server is there to do. dak should not be doing the source package transformation, because that is a much more complicated process and therefore a larger security attack surface. That's why it's done in a sandbox with a bunch of privilege separation. That does indeed mean that dak has to trust the tag2upload verification of the original Git tag and its verification of the semantics of that Git tag, because that's part and parcel with the rest of the work that tag2upload is doing. The tag2upload developers believe that the schemes proposed for trying to make the original signature portable to the generated *.dsc file are too awkward and complex to be supportable, and personally I agree. But this is entirely separate from the *authorization* check. After tag2upload uploads the *.dsc and *.changes file to dak, dak is in possession of the key fingerprint of the original signer, the source package name, the suite, and so forth. It can redo the *authorization* check itself if it so chooses. The only thing it can't do is the *authentication* check. > My impression (and I may be wrong, because it was awhile ago and since > I'm not an FTP Master I wasn't super focused on it) is that the > fundamental issue is tag2upload inherently requiring DAK to blindly > accept anything tag2upload signs and the FTP delegates not being > comfortable with that. Yes, I believe that's the core disagreement. I don't believe there is any way around that without breaking one or more design goals of tag2upload. It's not clear to me why it is considered a blocker for signature verification in the tag2upload case to be done by a different piece of software running on limited-access Debian project infrastructure instead of in dak, a piece of software running on limited-access Debian project infrastructure. But that's fine; it doesn't need to be clear to me. I believe it is in the remit of the FTP team delegation to make that decision, but there is also a constitutional process for appealing that decision to the project as a whole. The tag2upload developers have made their case, the FTP team can make their case for why they don't want to allow this, and the project can decide. That's how our system works. > That was the issue last time this was discussed (IIRC) and it doesn't > appear that anything has changed. I don't see how it can with the > current architecture. I agree. > I suspect a vote of no confidence by the project in the FTP Masters > would not be super motivating either. I think interpreting this GR as a vote of no confidence by the project in the FTP Masters would be an extreme overreaction. The FTP Masters were overruled in https://www.debian.org/vote/2007/vote_002 and life went on. All of us are at odds with the general consensus of the project at one point or another. That's just part of working collaboratively with people who are not clones of us. Feedback from the project as a whole can be extremely helpful and constructive. There's no reason to take it personally. I have been overruled in my design decisions many times in my life, including by people who were and remain close friends. Just becuase I think the FTP team made the wrong decision in this particular case does not mean I have no confidence in their regular work. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
