Hello, On Wed 12 Jun 2024 at 11:23pm +02, Joerg Jaspert wrote:
> On 17258 March 1977, Ian Jackson wrote: > >>> > And we also remove the Debian Maintainer role as dak would no > longer >>> > know who uploaded the package? Debian is larger than only Debian >>> > Developers. >>> This is a policy aspect. When we need to revoke a key used for uploading >>> this happens via keyring maintainers as far as I understand, but in >>> urgent cases it is ftp master who can also deny upload rights more >>> quickly than via a keyring update. In moving to tag2upload as a service >>> external to ftp, we partially move this capability from ftp master to >>> the entity running tag2upload (DSA afaiui). Is there a sensible way to >>> leave this policy aspect with the ftp team when using the tag2upload >>> service? In effect, I'm asking whether ftp could somehow provide an >>> authorization oracle to be used by tag2upload. >> tag2upload leaves this policy with the ftpmaster team. It uses the >> archive keyrings and dak's list of Debian Maintainers. > >> So there is no change here. > > 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. Could you say more specifically how seldom, and also how long it usually takes between you flicking the emergency switch, and the keyring team pushing an update? -- Sean Whitton
