On Friday, June 14, 2024 6:37:40 PM EDT Russ Allbery wrote: > 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.
Maybe. Maybe this breaks the thing into two parts in a way it wasn't before If you verify the signature on the source package and the key is in the keyring, you know that the package was uploaded by someone authorized to do so and that the code you have is what they signed. With tag2upload you have neither. You have tag2upload's claim of who signed the tag and the source package constructed by tag2upload. The connection to what the uploader intended to upload is completely indirect. > > 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. I don't think there's any real mystery about this, but the claim in the draft GR was that there was an unwillingness to communicate. While there is a legitimate core to the draft GR, it feels to me like there's a lot of puffery around it that makes the whole endeavor seem questionable. > 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. This is rather closer to the core to the FTP Master's delegated responsibilities in my judgement, so I'm not sure how comparable it is. I don't know, this is just speculation on my part. It may be fine. Some or all of them may be unwilling to continue to be responsible for managing the security of the archive once the security of the system has been (in what I believe to be their view) compromised. Scott K
signature.asc
Description: This is a digitally signed message part.
