lp should generate 512sums in apt release files

Bug #1536602 reported by Dimitri John Ledkov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Won't Fix
Undecided
Unassigned

Bug Description

lp should generate 512sums in apt release files

Looking at:
http://archive.ubuntu.com/ubuntu/dists/devel/InRelease

It is sha512-signed file with highest checksums for included files being sha256

lp should generate SHA512 sums for published archives.

Related branches

William Grant (wgrant)
Changed in launchpad:
status: New → Won't Fix
Revision history for this message
William Grant (wgrant) wrote :

SHA-512 doesn't offer any serious benefits over SHA-256 now, and both being slight variants within the SHA-2 family it's not likely that this will change soon. Since SHA-512 would hugely bloat the compressed and uncompressed sizes of Release and Packages, the cons far outweigh the pros.

If I had been involved in implementing apt's SHA-2 support, I would have gone with SHA-512/256 to gain possible future proofness from SHA-512 while eliminating length extension attacks and the size downside, but SHA-256 is the best SHA-2 tradeoff supported by apt today.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Fair enough. I just found it funny that gpg signature is using SHA-512 hash, yet the checksums of files do not.

Can we finally start dropping older checksums in favor of bigger ones? Or do we still support lucid =) ?!

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Blast from the past, is the following hash configuration intentional or accidental, and should I fix this globally?

Packages & Sources have SHA512 published in Ubuntu archive, and PPAs do not.

InRelease do not have SHA512 anywhere.

I wonder if this is due to using apt-ftparchive without opting out of any hashes.

I'm working on implementing removing the md5 & sha1 bloat and I noticed that apt-ftparchive configs generated do not intentionally turn off sha512. Meaning it remains turned on.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Also yes, I agree that SHA-512/256 would be nice. Also we are now getting hw accelerated SHA3. Thus maybe it is time to look into using SHAKE256.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.