On Tue 2016-08-30 10:31:50 -0400, Julian Andres Klode wrote:
> On Tue, Aug 30, 2016 at 10:18:33AM -0400, Daniel Kahn Gillmor wrote:
>> 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.

ok, i'm not going to worry about marking software-properties with a
Breaks: unless i hear otherwise from you.  thanks for giving me a
heads-up, though.  It does look like there's code in there that should
probably be pulled out just have it use python-apt directly.

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

Huh, i was unaware of the Signed-By field, actually, but i'm happy to
see it.  I'm not sure what i think about a primary key being listed
there by fingerprint while the Release file being signed by a subkey.  I
could see a (fairly weak) argument that rejecting that signature is
"working as it should", but i think you're probably right that this
might be better considered as a bug.  at least it's a bug that fails
closed rather than failing open though :)


Attachment: signature.asc
Description: PGP signature

Reproducible-builds mailing list

Reply via email to