Re: [RFC] General Resolution to deploy tag2upload
On Thu, 13 Jun 2024 at 12:02, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
>
> Sean Whitton writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> >[Joerg Jaspert wrote:]
> >> Actually, we can set acls on fingerprints and then that key wont be able
> >> to upload anymore. That is not something recorded in the keyrings or the
> >> DM list. Obviously that is not something used often (really really
> >> seldom), it is more for "this key is compromised badly, please turn off
> >> anything with it *NOW*" situations, which it's what Helmut meant with the
> >> urgent cases.
> [and]
> >> *Really* seldom. I would have to dig and see when, especially for the
> >> timing thing with keyring team.
> >
> > Thanks. Then possibly it is sufficient for ftpmaster just to disable
> > tag2upload's whole key until the keyring update is pushed.
>
> I'm not sure this is a sufficient answer. We don't want uploads by
> revoked keys to appear on *.dgit.d.o either.
Correct me if I am wrong, but if we are looking at dgit.d.o as
snapshot and audit log
of the tag2upload service, would it not be beneficial for the auditing
and back-tracing
process to actually keep the code that someone tried to upload via
tag2upload even
if their key is revoked, expired or signature is invalid?
Maybe re-tagged to something like invalid_$original_tag but still kept
around for people
to inspect if needed.
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
Reply to: