Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'

[Julian Andres Klode]

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.