Dear Maintainer,
At debian-user@lists.debian.org, it was discussed
  [ https://lists.debian.org/debian-user/2014/06/msg00856.html ff]
that the current linux source package for wheezy could not be verified using
  $ dpkg-source -x linux[...]
It was suggested on list to wish for a recent d-k to be distributed via
stable-updates, which I am hereby doing. If there is something I can
help with to make this possible, please let me know.

Best regards,
Simon Hollenbach

tags 751480 wontfix
thanks

Simon Hollenbach dijo [Fri, Jun 13, 2014 at 01:57:21PM +0200]:

Hi,

I would even argue in the opposite way :) The debian-keyring package
is not always updated when we upload a new keyring, and it's a
never-dying source of confusion. Given we have a public Git tree,
which is up-to-date with the live keyring, I guess that should suffice
— And maybe distributing the package as a static thing never to be
updated is no longer useful.

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,
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
keyring as it changes is that keys that may have been valid at release
but have been changed are no longer available, so you still run the risk
of not being able to verify signatures that are on your system. As a
result the bug in question has been marked wontfix.

J.

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

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.

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

Date: null >From: null >------------- >Body: ur-type{attachments