[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question about upcoming SHA1 removal



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.

Reply to: