On Wed, 7 Mar 2018 18:28:49 -0500
Ferris Ellis <ferris_at_ferrisellis.com> wrote:
> I was looking into using a crypto-service to do Apline package build
> signatures (as opposed to using a key on disk) and in doing so
> stumbled across the fact that Alpine package signatures currently use
> SHA1 digests. After a quick search on https://lists.alpinelinux.org I
> didn’t see any prior discussions related to this fact and thus am
> posting this to the mailing list.
> I wanted to start a dialog about the possibility of moving to using
> SHA2 digests (I would presume SHA256 would be the preferred option)
> for signatures as SHA1 is deemed insecure by many and is being phased
> out for most usage of PKI. This includes my use case, where the
> crypto-service I have deliberately no longer offers signatures with
> SHA1 digests and instead offers standard SHA2 digests.
> If the community is interested I’m happy to submit a more formal RFC
> on this. But, as I’m relatively new to the mailing list, I figured it
> was best to start with just a dialog!
I have been working to update .apk and index formats to binary. I was
hoping to do the hash algorithm change there. While I do have the
design ready, and some code too, it's taking a bit more than expected.
I am willing to accept backwards compatible patches at this point even
for the current formats. The signatures could be pretty easily updated.
Just add a new prefix type to identify the signatures as rsa-sha256 or
However, sign only the control.tar.gz part of apk. That in turn
contains hash for the control.tar.gz part containing the package
metadata. Changing this 'identity hash' from sha1 to sha256 would be
more intrusive. Same applies to the individual file checksums kept in
the file database for audit purposes. However, control.tar.gz does have
stronger hash (sha256) for data.tar.gz which contains the actual file
Received on Thu Mar 08 2018 - 14:53:56 UTC