Re: Question about upcoming SHA1 removal
On Fri, Nov 04, 2016 at 06:39:39PM +0000, Kohsuke Kawaguchi wrote:
> 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?
OK, I did not know this. I always assumed it only allows SHA1 and RIPEMD-160,
but apparently I was wrong. That said, AFAIUI a SHA256 hash does not fit into
the DSA sig packet, and is truncated (but really, AFAIUI).
We really need to get rid of the DSA keys too though. I just never added a
check for DSA keys themselves, as I thought I covered that with the SHA1
and RIPEMD check. I should probably fix that, if possible.
So, it's an accident that this works - the intention is to get rid of DSA
keys too. We even got rid of them for the personal DD keys already.
>
>
> 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?
Repositories are supposed to ship a key in /etc/apt/trusted.gpg.d in some
package, usually a keyring package. (You could also have a repo config package
that also adds a file to sources.list.d). Some repositories, like the Google
ones add the sources.list, gpg key to their main package - they only have
one package per repo.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: