On Tue, Aug 30, 2016 at 09:32:15AM -0400, Daniel Kahn Gillmor wrote: > On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote: > >> apt/auth.py appears to want to force gnupg to store its secret key > >> material in secring.gpg. This isn't a best practice, and modern > >> versions of gpg do not do so by default. I'd recommend dropping > >> tmp_secret_keyring entirely. > > > > Hmm, there should not even be any secret key material, as apt only > > deals with public keys. > > agreed, all the more reason to strip out those extra directives ;)
I assume that might change behavior if used with gpg1, so I'd rather keep it in if it does no harm. > > >> I'll be releasing a new version of gnupg shortly that will explicitly > >> declare that it Breaks: python-apt (<= 1.1.0~beta4). > > > > I think that's a bit overkill. While this part of python-apt is broken > > with the new gnupg, the rest works fine; and nobody uses the apt.auth > > module. Not to mention that I'm deprecating it, as we deprecated the gpg > > stuff in apt-key. > > If you want me to remove the Breaks: i can do so -- my goal was to > address the concerns raised in https://bugs.debian.org/835349. > > If you'd rather that i not provide a Breaks: or a Conflicts: for > python-apt, i can avoid it -- speak up though, i'm hoping to release the > next version of gnupg2 to unstable shortly :) I don't really care. More important are probably Breaks for software-properties, it's Authentication tab is fairly broken now. I think that's also where apt.auth was split off from, but I'm not entirely sure... > > >> Ideally, the next version of python-apt can have these bugs fixed and it > >> will work cleanly with the modern version of gnupg. > > > > Sure. But we should really support both old and new gpg versions, otherwise > > it gets a bit annoying. > > > > Maybe there's also an option to display fingerprints instead of keyids > > in --with-colons --list-keys? > > sure! > > gpg --fixed-list-mode --with-fingerprint --with-fingerprint --with-colons > --list-keys > > will produce lines of the form: > > fpr:::::::::0EE5BE979282D80B9F7540F1CCD2ED94D21739E9: How awful. There should be a way to integrate this into the pub output (and with all the other breaks, it should have just gone fingerprint by default everywhere). But oh well, it's better than nothing. > > The hex string shows up in $10 for "awk -F:", fields[9] in python after > fields = line.split(":"). > > providingn --with-fingerprint twice ensures that you get fingerprints > for both primary keys and subkeys -- if that's what you want. Hmm, I don't know. APT's subkey handling is fairly broken anyway (it's gpg verification does not consider subkeys at all, so if you specify a list signed-by of master key ids, APT would fail to validate a repo signed with a subkey, unless the subkey is in the list itself...) > > >> However, if your next upload of python-apt can't be built or run against > >> modern versions of GnuPG > > > > That would be silly :) > > i'm glad it will be straightforward to sort it out ;) > > Thanks for your work on this, > > --dkg -- Debian Developer - deb.li/jak | jak-linux.org - free software dev When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.
