On Thu, October 9, 2014 14:58, Jonathan McDowell wrote:
> On Wed, Oct 08, 2014 at 07:57:14PM +0100, Jonathan Dowland wrote:
>> Hey, I noticed that the most recent DSA failed signature check for me.
>> This is because Thijs' signing key had an expiry of 2014-06-16 at some
>> point. He has more recently edited that forward a year. However, the
>> version of his key in debian-keyring 2013.04.21 (=wheezy) has the
>> above expiry. (It's fixed in 2014.08.31=jessie).

Indeed. In my opinion this is valid behaviour that should be supported.
When working with subkeys, they normally only have a lifetime of a few
years. Less than the support timeframe of a Debian release.

To be frank the current Debian keyring system does not really promote the
use of things like subkeys because if you rotate them it takes about a
month before Debian notices it. While there's a cryptographically
verifiable path that confirms the legitimacy of this new subkey, so
merging them in could be a quick and routine process.

>> I think it would be a nice-to-have if DSAs were verifyable by the
>> keyring package shipped in stable. That would imply updating keys in
>> the stable package to reflect (some) changes post-release.

I'm not sure if this is actually a 'nice to have'. Using a keyring but not
running gpg --refresh on it is a bad practice. You'll surely miss out on
indeed new subkeys or new expiry's, but even more importantly, you'll miss
out on revokes.

>> Person-power issues aside, what are your opinions on this, please? I'm
>> aware that you almost certainly lack the cycles to make such updates.
>
> We've had some discussion in the past about putting updates in the
> -updates suite for stable (and indeed there's a bug, #751480, which I
> have cc'd), and some discussion about whether we should continue to ship
> the debian-keyring package. I personally lean a bit towards the removal
> of the package and saying people should be pulling keys from keyservers,

Removing the keyring package seems like a good option to me. Keyservers
and the use of gpg --refresh map much better to the way PGP keys work than
a static copy of those keys being pumped around.

> but I understand there are those who like to have a snapshot of the
> keyring for the release. One of the problems with then updating the

I'm having trouble with coming up with concrete use cases for these
snapshots. Keys are not a static concept and are not meant to be.

Keys that do not change for the lifetime of a release are in existence and
they are managed in a separate package specifically for this purpose.

A completely different angle to approach this is that we would not sign
DSA's with a personal key, but instead with a role key not unsimilar to
the current archive keys in use...


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to