[pacman-dev] (no subject)
This was quickly discussed in IRC with others and we saw no reason which would prevent this from being changed. See the commit message for details. Note this is my first time contributing to arch/pacman and using git-send-email, so if there's anything wrong, please let me know!
From: Florian Bruhin <git@the-compiler.org> There were a few bug reports related to this: https://bugs.archlinux.org/task/39210 https://bugs.archlinux.org/task/38543 https://bugs.archlinux.org/task/37215 While disallowing md5sums entirely will break too much, the default should be changed to sha256 for the following reasons: - Using MD5 as default might motivate people to use MD5 for other purposes as well, which is usually a bad idea. Even if the change wouldn't have any effect on pacman itself, it has the benefit of stopping to encourage people to still use MD5. - While not actually the main motivation for this change, there is the possibility of provoking a hash collision. This is however difficult due to some factors, like compression. As the integrity check isn't designed to be a cryptographic check in the first place, this point is less important. sha256 was used over sha512 mainly to keep line length reasonable (under 80 chars). The performance loss should be negligible and only applies to building packages. On my machine, with an 1GB file (which is large compared to the average source file), sha256sum takes 5.7 seconds, md5sum 1.9 seconds. Signed-off-by: Florian Bruhin <git@the-compiler.org> --- etc/makepkg.conf.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index 712ca60..19c430a 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -80,7 +80,7 @@ BUILDENV=(!distcc color !ccache check !sign) OPTIONS=(strip docs libtool staticlibs emptydirs zipman purge !upx !debug) #-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512 -INTEGRITY_CHECK=(md5) +INTEGRITY_CHECK=(sha256) #-- Options to be used when stripping binaries. See `man strip' for details. STRIP_BINARIES="@STRIP_BINARIES@" #-- Options to be used when stripping shared libraries. See `man strip' for details. -- 2.0.0
On 06/06/14 05:39, me@the-compiler.org wrote:
From: Florian Bruhin <git@the-compiler.org>
There were a few bug reports related to this: https://bugs.archlinux.org/task/39210 https://bugs.archlinux.org/task/38543 https://bugs.archlinux.org/task/37215
And all those were rejected... The default means that people are using "makepkg -g" to generate them, so is useless. People should be using whatever upstream publishes (or better pgp signatures) to verify files. Allan
* Allan McRae <allan@archlinux.org> [2014-06-06 07:34:51 +1000]:
On 06/06/14 05:39, me@the-compiler.org wrote:
From: Florian Bruhin <git@the-compiler.org>
There were a few bug reports related to this: https://bugs.archlinux.org/task/39210 https://bugs.archlinux.org/task/38543 https://bugs.archlinux.org/task/37215
And all those were rejected...
Note only the first of this reports is actually what this patch changes. The other two propose *disallowing* md5sums entirely, which IMHO is not a good idea. The first one then was closed as a duplicate of one of the others, even though disallowing md5sums and changing the defaults are two completely different things. Looking at the count of bug reports (plus some votes, even on the reports proposing a more radical change), this is at least an issue worth discussing.
The default means that people are using "makepkg -g" to generate them, so is useless.
From the top of my head, I see three possible scenarios where a data corruption can occur: - On the server itself (wrong file but correct checksum hosted, etc.): This is the only case where a checksum generated via makepkg -g wouldn't help, and I'd guess this is the rarest scenario. - During transmission to (or on the machine of) the maintainer. While the mantainer initially won't know something is wrong, the users will and will hopefully complain. - During transmission to (or on the machine of) the user installing the package. I think this is the most common scenario. In this case, it doesn't matter how the checksums were generated by the maintainer. I do agree using upstream checksums is the best option if they are provided, but sadly that's often not the case - but I disagree about checksums being *useless* when they don't come from upstream directly.
People should be using whatever upstream publishes (or better pgp signatures) to verify files.
Please also note there are PKGBUILDs where there's no upstream source with a checksum (e.g. only VCS sources), and then some added files (install/patches/...). I did a quick grep against the aur git repo to find out what the current distribution of checksums is, out of curiosity: 41215 md5sums 5641 sha256sums 3230 sha1sums 2587 sha512sums 71 sha384sums So it seems to me the reality is that makepkg -g is still widely used. [offtopic] I also found some constructs to automatically get a checksum file from upstream via curl/wget - is this an encouraged thing to do? Though this one probably isn't a good idea :D md5sums=(`wget -qO- $source | md5sum | cut -c -32`) [/offtopic] No hurt feelings if this patch won't be accepted, but I think it'd be beneficial to hear other thoughts on this. Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
On 2014-06-06 07:20, Florian Bruhin wrote:
I also found some constructs to automatically get a checksum file from upstream via curl/wget - is this an encouraged thing to do? Though this one probably isn't a good idea :D md5sums=(`wget -qO- $source | md5sum | cut -c -32`)
I might be able to speak to that one a bit. Several of the packages that use some of these constructs act more like VCS packages than standard packages (e.g., they have a pkgver() function). This type of construct is incredibly helpful because it allows the integrity check to be made without the packager having to manually grab the checksums each update. Plus, if the packager has done her job well, then such a method should be equally as secure as manually grabbing the checksums (the location from which the checksums would be grabbed is the same). Admittedly, I have no idea if such a method is considered good practice, but it has seemed like a net positive to me. One final note though, the quality of packages in the User Repository (and the methods therein) have little to no bearing on the packaging techniques in [core] and [extra]. Even if the method for fetching checksums above were widely used and considered to be a good idea, it is not one I can imagine being helpful in the dev-maintained repos. -- All the best, Sam Stuewe (HalosGhost)
On 06/06/14 22:20, Florian Bruhin wrote:
[offtopic] I also found some constructs to automatically get a checksum file from upstream via curl/wget - is this an encouraged thing to do? Though this one probably isn't a good idea :D md5sums=(`wget -qO- $source | md5sum | cut -c -32`) [/offtopic]
Well, that is ... I have nothing polite to say.
* me@the-compiler.org <me@the-compiler.org> [2014-06-05 21:39:44 +0200]:
This was quickly discussed in IRC with others and we saw no reason which would prevent this from being changed. See the commit message for details.
Note this is my first time contributing to arch/pacman and using git-send-email, so if there's anything wrong, please let me know!
Blergh. This went wrong even more horrible than I thought. If you hate no-subject mails just as much as I do, my apologizes! I didn't expect --compose to send a separate mail with the changes, I thought I was editing the "template" which then would have the headers set correctly and the patch appended. In my defense, I did even do a test run first, just not with --compose. Whoops. Also, it was pointed out to me I was unclear about discussing it briefly "on IRC" - I was referring to #archlinux, not #archlinux-pacman. Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
participants (4)
-
Allan McRae
-
Florian Bruhin
-
me＠the-compiler.org
-
Sam Stuewe