Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#69485 - Deprecate insecure checksums in makepkg

Attached to Project: Pacman
Opened by Victor Engmark (l0b0) - Sunday, 31 January 2021, 09:09 GMT
Last edited by Allan McRae (Allan) - Sunday, 31 January 2021, 13:07 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: makepkg currently supports md5sum and sha1sum, both of which are considered insecure. Marked as high severity since as far as I can tell a chosen-prefix attack against either of these are within reach of private persons (https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix_collision_attack).


Additional info:
* makepkg (pacman) 5.2.2

Steps to reproduce:
1. Build any AUR package which uses "md5sums" or "sha1sums" in PKGBUILD.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 31 January 2021, 13:07 GMT
Reason for closing:  Won't implement
Comment by Allan McRae (Allan) - Sunday, 31 January 2021, 10:36 GMT
Changing the default does not give much increase in security if checksums in PKGBUILDs are generated by the packager and not upstream. There is some argument from Trust on First Use, but it is weak... So unless the packager gets a secure checksum from the upstream source, these checksums are only to check download integrity, not for security. BTW, the default checksum in "makepkg -g" will be CRC32 after the pacman-6.0 release, making it clear what the checksums generated by makepkg are and are not.
Comment by Levente Polyak (anthraxx) - Sunday, 31 January 2021, 12:08 GMT
I still strongly disagree here. Trust on first use is a useful fallback concept if you have no authenticated sources available, this is merely also what SSH does to raise the bar for trusting whatever you enter in your ssh shell. Anyway, even if we just exclude repo packages that get rebuild tons of times, lets focus on where TOFO shines: The AUR. There you have PKGBUILDs that literally everybody is building themselves with different caches and hence pulling the sources. Having trust on first use (first use is the AUR package maintainer) gives some confidence for all following builds. The advantages of tofu outweigh the dangers of misunderstanding about the concept of those hashes.
Comment by Morten Linderud (Foxboron) - Sunday, 31 January 2021, 12:15 GMT
Padding attacks on SHA1 has strictly been done through file formats where you can just pad the file (length extension attacks)? Right? How would you accomplish this on any compressed archives?
Comment by Levente Polyak (anthraxx) - Sunday, 31 January 2021, 12:40 GMT
@Morten: The compression layer makes it problematic indeed, would need some magic and potentially lucky graceful handling. Anyway, PKGBUILDs do not just contain complicated sources, they also contain plaintext files and patches. However I don't think that's quite the point to discuss here to focus and follow up on this, even tho the initial description is about that. With the new default of CRC we don't even need to discuss how to attack it, right? :)
Comment by Morten Linderud (Foxboron) - Sunday, 31 January 2021, 12:58 GMT
We do(!) But the point is to illustrate that the insecurity of md5/sha1 in the context of Arch is still fairly limited.
Comment by Allan McRae (Allan) - Sunday, 31 January 2021, 13:07 GMT
This has now been assigned to the pacman tracker. As such, it will be closed.

If people in Arch Land want to discuss this further, reopen and move back to the Arch section of the bug tracker.

Loading...