[pkg-gnupg-maint] 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 10:18:33AM -0400, Daniel Kahn Gillmor wrote:
> On Tue 2016-08-30 09:47:34 -0400, Julian Andres Klode wrote:
> > 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.
> 
> There should be no behavior that changes based on secret keys if secret
> keys are never used.  I'd rather not have spare directives floating
> around that we don't need -- i've been doing triage on things that try
> to manipulate gnupg programmatically, and the simpler we can make them
> the easier it will be to fix any problems that come up in GnuPG itself,
> i think.  There's a lot of cruft, and it would help my sanity to
> minimize the cruft.

Mmh, okay.

> 
> > 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...
> 
> Can you point me to a report about that?  I'm not seeing it in my scan
> of the bts at https://bugs.debian.org/src:software-properties

There is none. And it does not seem to be that annoying. While it now only
shows key ids and no names, you can at least still remove them. So it basically
works, but without it showing names, it's kind of useless for the target
audience.

> 
> >> > 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
> 
> To be clear, the output has pub:, then fpr:, then uid: lines in a row.
> it's pretty straightforward to track as you read the lines linearly.
> for any uid line, it is associated with the most recent fpr line, which
> itself is associated with the most recent pub line.

Yes.

> 
> the uid line is split out because you can have multiple uids associated
> with each pub+fpr.
> 
> For the fields we're interested in, this is the same output across all
> versions.
> 
> > (and with all the other breaks, it should have just gone fingerprint
> > by default everywhere).
> 
> i'm working on that, but there are internal data structure
> considerations that make it more costly to display the fingerprint
> (unfortunately, the datastructures in the keyring are 64-bit keyids, not
> full fingerprints).
> 
> > 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...)
> 
> interesting -- how is this done?  i thought apt was using gpgv to verify
> the signatures, and if there are subkeys in the keyrings gpgv knows
> about gpgv will be willing to accept those subkeys.  Are you saying apt
> itself parses the output of gpgv and the fingprints in it to some
> internal list of acceptable fingerprints?  If you could point to the
> right spot in the source, i'd be happy to look into it further.

APT uses gpgv and then parses the output of [GNUPG:] VALIDSIG to
determine the key id used to sign (and forgets to include the
subkey field).

If a list of allowed keys has been specified for the source via a
Signed-By field in the sources.list or the Release file, it then 
checks that the key it parsed from GPG is in that list.

If nobody specifies a Signed-By field (which is the default
right now), that of course does not affect anyone. I do want
to roll out the Release-file Signed-By field at some point
though, as it (very) slightly improves security.

-- 
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.