Re: tag2upload (git-debpush) service architecture - draft
On Mon, Jul 29, 2019 at 09:46:51 +0200, Ansgar wrote:
> There are also other issues, for example:
>
> - Such a service would bypass various sanity checks on the archive
> side, including various permission checks.
tag2upload checks the Debian Keyring and the DM ACL (from dak)/DM
keyring. What other checks are done per key that are avoided by this?
The proposed Git-Tag-Info field has the fingerprint of the original key
that signed the tag, if there are further keyring related checks that
ftp-master wish to perform themselves.
> - Such a service would need to properly validate the PGP signature.
> The archive really shouldn't rely on a third-party service for this.
> (In particular the service in question here doesn't do that as far as
> I can tell.)
I'm not clear on what the issue is here; perhaps you can expand? A DD/DM
has to sign the tag in Salsa[0], tag2upload does the appropriate check
that the tag is signed by a key that has the appropriate permissions to
do a source upload of the package in question.
There's no third party service being trusted here. The keyrings are from
Debian and the intent is to have tag2upload being run on Debian
infrastructure - indeed that's my understanding of part of the main
reason Ian has brought up his draft architecture here, to work out what
needs changed/included to make that possible.
It's not clear to me why this is significantly different from a security
perspective than the buildds; in fact as this service does not build
anything other than a source package it's much more auditable than the
binary uploads they perform[1].
J.
[0] Other Git Hosting Services Are Available.
[1] Until Reproducible Builds are at 100%.
--
101 things you can't have too much of : 40 - Star Wars toys.
Reply to: