Skip to content

Instantly share code, notes, and snippets.

@kohsuke
Created November 2, 2016 00:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kohsuke/c712ce347d92070bdf92f90d1b300df6 to your computer and use it in GitHub Desktop.
Save kohsuke/c712ce347d92070bdf92f90d1b300df6 to your computer and use it in GitHub Desktop.
I'm the maintainer of the Jenkins debian package repository at http://pkg.jenkins.io/debian/
My repository is listed in https://wiki.debian.org/Teams/Apt/Sha1Removal and so I'm trying to fix it. And I have a question.
According to the said Wiki page, "Repositories with DSA keys need to be migrated to RSA first", but as far as I can tell, this is not strictly speaking necessary. I was able to generate a SHA256 signature like this, using my existing DSA/1024 key:
Command line:
$ gpg --detach-sign --armor --digest-algo sha256 < Release
Generated signature:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABEIAAYFAlgY+CQACgkQm30y8tUFguYidACfXjBx4maME/pn3KKEyrvESE5r
G8oAnigCLd0dbR2IiSMA4Gz3WSfIEEmJ
=CoaN
-----END PGP SIGNATURE-----
Output from pgpdump:
Old: Signature Packet(tag 2)(70 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - SHA256(hash 8)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Tue Nov 1 13:16:36 PDT 2016
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x9B7D32F2D50582E6
Hash left 2 bytes - 22 74
DSA r(159 bits) - ...
DSA s(158 bits) - ...
-> hash(DSA q bits)
... and "apt-get update" was happy with this.
I liked this approach because this buys more time for changing the signing key from DSA/1024 to RSA/4096. I can start generating this signature today to meet Jan 1 deadline of SHA1 removal, but I can give a longer heads up for my users before the signing key changes.
My question is, am I missing something? Is there any hole in what I'm trying to do?
Assuming this is OK transition story, I have a follow up question. The wiki page also says the following:
> Migrating from DSA to RSA is best done by signing the repository with
> two keys (old and new one) and shipping the new one to the users.
> A relatively safe way to ship the key would be to embed it in the
> package. Some months after those changes, it is OK to drop the old key
> from the repository and the users machines (if shipped with a package)."
I'm unclear how existing users will get the new key. IIUC, just shipping the new key to users by itself will do no good. The user would have to run "apt-key add NEWKEY.txt" or some such to import the new key. Are you guys recommending that the package does that on behalf of users by running this as a post installation script or some such? Or are we supposed to communicate to users, say via a blog post, that they need to do that? If the latter, what good does it do that the file is shipped inside a package, as opposed to download via HTTPS that we teach to new users?
Thanks in advance for any help you can give.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment