Hello, On Mon 15 Jul 2019 at 10:22AM -07, Russ Allbery wrote: > Just to make sure I fully understand the model, is the idea that this > system will verify the signature on the Git tag, construct a source > package from the signed archive, and then sign the resulting source > package with some internal key? Assuming that by 'archive' you mean the committish at which the DD-signed tag points, then yes, that's the model. > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introduce a new > vulnerability, but my understanding was that the identity of the signature > on the source package was used in various other places. Presumably we > would need to introduce some new metadata so that the uploader is mapped > properly to the Git tag signer, rather than to some internal identity of > the source package construction service. Right. This might be needed. > Also, doesn't the archive publish the signed *.dsc files currently? I > believe this would mean that we would lose some published information from > those files that we currently have (namely which DD and which key signed > the package, which could be useful data in some incident response > scenarios). That said, there's been some discussion for some time about > having the archive sign all the *.dsc files instead of keeping the > uploader signature, which may be from an expired or unverifiable key > (particularly for packages that haven't been uploaded in some time). As you say, DD signatures on .dscs are only reliably useful in sid, where they're quite likely to be verifiable. So perhaps having them signed by this bot would be an improvement for some usecases. > There are also some interesting nuances here around handling DM packages, > where not everyone with a key in the keyring can upload every package, > although the obvious way to address that is probably for this service to > do the same DM checks that ftpmaster would normally do. Right. dgit-infrastructure already has code to do that. We just haven't hooked it up yet. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature