Re: Planned changes to Debian Maintainer uploads
Hi,
Gunnar Wolf <gwolf@gwolf.org> writes:
> Hmm, this looks interesting, and useful. I'd like to add a bit as a
> wishlist item: Having this DB easily queriable (i.e. a webpage where
> you can query by key to see all the packages uploadable by a given
> key).
I agree that the information should be easily available. We can export
it to a static HTML page (with optional JS to sort by package or
maintainer) and to deb822 format. In addition it will be available in
the DD-accessible projectb copy on ries.d.o.
> And just thinking about possible complications: I *hope* we don't see
> any such behaviour, but this format would allow a DD to "censor" a
> given DM's activity. If I send "Deny" actions with somebody's key, it
> ends up blocking that person until somebody else is convinced to send
> corresponding "Allow" commands. Of course, if we see any such
> behaviour (repeatedly?), I might be reprehended and maybe even locked
> out of sending requests to this subsystem. Thoughts on this?
As Arno said this is already a potential problem with the current
interface, though I am not aware of any abuse. Blocking access to the
command interface would be an option, but I hope we don't need it and
would not implement it right away.
> Finally, it's interesting to me (as keyring-maint) that you are
> specifying the fingerprint. Of course, it makes sense. But it can make
> key migration (i.e. a DM moving from a 1024D to a 4096R key, or
> reacting to a key being compromised) as a more difficult thing, as the
> new key would first have to be inserted by us into the live keyring
> and only then the old key denied and the new one allowed. I guess we
> could automate this procedure when performing the keyring push...
Using fingerprints avoids dak to have perform the name -> fpr mapping
without any interaction (which would probably have the same problems as
we already have for people with multiple uids).
Key migration is indeed a small problem as the key needs to be known to
dak in order to grant upload permissions. So you can only move
permissions after the new keyring is active, but maybe we could add a
command to migrate between keys to make this easier. (Should this be
restricted to keyring maintainers? Or only available for ftpmaster and
keyring maintainers ping us[1]?)
Ansgar
[1] Which would be easier to implement as dak would not need to know
who is a keyring maintainer.
Reply to: