[arch-general] Pointless to use non-md5 for makepkg INTEGRITY_CHECK
At the request of the upstream developer, I was attempting to change the md5sums in my tarsnap PKGBUILD (http://aur.archlinux.org/packages.php?ID=22963) to use sha256 instead, and ran across a couple of issues. The way makepkg works, when you set INTEGRITY_CHECK in makepkg.conf, those values effect BOTH the generation of the checksums and also the verification upon package compilation. I believe the variable should only effect checksum generation. Validation of the checksums upon compilation should only fail in two cases: 1) There are no checksums listed in the PKGBUILD or 2) One of the listed checksums does not validate against the source The way things are now, it's not feasible to use a non-standard (read non-md5) checksum, because everyone who would like to build the package themselves would either have to alter their own makepkg.conf file, or simply ignore the warning of verification failure. Unless everyone moved to a different standard of checksum at the same time, I don't think it would be realistic for us to expect people to do this. I can't think of a use case where it wouldn't make sense just to verify whatever checksums are listed in the PKGBUILD, and only consult the INTEGRITY_CHECK settings when generating new checksums. This process also led the the discovery of an issue with the AUR code...it seems as though the AUR is hard-coded to check for md5sums only, so if you attempt to upload a package with just a sha256sums line, it will complain and prohibit you from updating the PKGBUILD. Has anyone else ever tried to use a non-standard INTEGRITY_CHECK setting? Is there something here that I'm missing? -- Aaron "ElasticDog" Schaefer
On Sun, Jan 11, 2009 at 04:37:04PM -0500, Aaron Schaefer wrote:
This process also led the the discovery of an issue with the AUR code...it seems as though the AUR is hard-coded to check for md5sums only, so if you attempt to upload a package with just a sha256sums line, it will complain and prohibit you from updating the PKGBUILD.
I removed the requirement for md5sums in AUR PKGBUILDs not too long ago. The change is in git and will take effect on the next release.
On Sun, Jan 11, 2009 at 3:37 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
At the request of the upstream developer, I was attempting to change the md5sums in my tarsnap PKGBUILD (http://aur.archlinux.org/packages.php?ID=22963) to use sha256 instead, and ran across a couple of issues. The way makepkg works, when you set INTEGRITY_CHECK in makepkg.conf, those values effect BOTH the generation of the checksums and also the verification upon package compilation.
I addressed this "upstream" in an earlier patch, so this will be fixed in pacman 3.3.0: http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=496b687c3d4a56641... -Dan
On Sun, Jan 11, 2009 at 7:05 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I addressed this "upstream" in an earlier patch, so this will be fixed in pacman 3.3.0: http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=496b687c3d4a56641...
-Dan
Fantastic! I hadn't thought to look at the git repos for the current versions of everything...I look forward to the fixes being pushed! -- Aaron "ElasticDog" Schaefer
On Sun, Jan 11, 2009 at 7:20 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Sun, Jan 11, 2009 at 7:05 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I addressed this "upstream" in an earlier patch, so this will be fixed in pacman 3.3.0: http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=496b687c3d4a56641...
-Dan
Fantastic! I hadn't thought to look at the git repos for the current versions of everything...I look forward to the fixes being pushed!
Currently, however, couldn't you just supply both md5 and sha1 checksums to cover all bases?
On Mon, Jan 12, 2009 at 10:44 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Currently, however, couldn't you just supply both md5 and sha1 checksums to cover all bases?
You could put them both in the PKGBUILD in order to be able to upload it to the AUR, but anyone who downloads it would get verification errors unless they updated their makepkg.conf to match the INTEGRITY_CHECK settings that were used when the PKGBUILD was created. If they did change it, they would have to change it back in order to prevent errors when compiling anything else. Once that patch gets pushed to the public, what do people think about switching over to sha256 as a default instead of md5 due to potential collision/security issues? -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 2:22 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
Once that patch gets pushed to the public, what do people think about switching over to sha256 as a default instead of md5 due to potential collision/security issues?
Haven't we been over this like a hundred times? md5sums are not used for security. Not ever. Nope. Nada. We use them solely to detect whether or not the download completed as expected. And sha256 is going way overboard here.
On Mon, Jan 12, 2009 at 3:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Haven't we been over this like a hundred times? md5sums are not used for security. Not ever. Nope. Nada.
We use them solely to detect whether or not the download completed as expected. And sha256 is going way overboard here.
It has been discussed before, in fact, you said this back in November: "The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256?" ...so a month ago you didn't think sha256 was going overboard, and now you do? I'd also make a semantics argument and say that if the "integrity" of the package could possibly be compromised by the creation of a malicious package with the same md5 checksum, then that absolutely effects the "security" of our system...the two ideas are not completely separate. Of course I realize that changing the checksum does not add any security benefits as far as package signing and all of that goes (establishing a truly secure package distribution system is a much bigger project), but it DOES eliminate one current vulnerability, and on top of that it's extremely easy to make the change. What is the downside? -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 3:23 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Mon, Jan 12, 2009 at 3:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Haven't we been over this like a hundred times? md5sums are not used for security. Not ever. Nope. Nada.
We use them solely to detect whether or not the download completed as expected. And sha256 is going way overboard here.
It has been discussed before, in fact, you said this back in November:
"The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256?"
...so a month ago you didn't think sha256 was going overboard, and now you do? I'd also make a semantics argument and say that if the "integrity" of the package could possibly be compromised by the creation of a malicious package with the same md5 checksum, then that absolutely effects the "security" of our system...the two ideas are not completely separate.
I do not recall my frame of mind at the time, but rereading that and knowing how I talk/write, I'd say that may have been tongue-in-cheek. I guess the point I was making was that simply bumping the checksum won't be the best solution because the NEXT choice may be labeled as insecure and then the next and the next. To put it in different terms: if you have some array that only holds 10 objects, and find out 10 isn't enough, you can bump it to 20. And when you find out 20 isn't enough, you can bump it to 100... and then 100 might not be enough... eventually, you're going to say "screw it" and tackle the problem differently (dynamically sized array). There has been lots and lots of work done to get GPG signed packages going on the pacman-dev list. Gerhard and Geoffroy, if I recall, kinda took the helm on this one. If we go with this solution, we won't have to play this game of cat-and-mouse with changing the checksums.
On Mon, Jan 12, 2009 at 3:45 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Jan 12, 2009 at 3:23 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Mon, Jan 12, 2009 at 3:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Haven't we been over this like a hundred times? md5sums are not used for security. Not ever. Nope. Nada.
We use them solely to detect whether or not the download completed as expected. And sha256 is going way overboard here.
It has been discussed before, in fact, you said this back in November:
"The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256?"
...so a month ago you didn't think sha256 was going overboard, and now you do? I'd also make a semantics argument and say that if the "integrity" of the package could possibly be compromised by the creation of a malicious package with the same md5 checksum, then that absolutely effects the "security" of our system...the two ideas are not completely separate.
I do not recall my frame of mind at the time, but rereading that and knowing how I talk/write, I'd say that may have been tongue-in-cheek.
I guess the point I was making was that simply bumping the checksum won't be the best solution because the NEXT choice may be labeled as insecure and then the next and the next.
To put it in different terms: if you have some array that only holds 10 objects, and find out 10 isn't enough, you can bump it to 20. And when you find out 20 isn't enough, you can bump it to 100... and then 100 might not be enough... eventually, you're going to say "screw it" and tackle the problem differently (dynamically sized array).
There has been lots and lots of work done to get GPG signed packages going on the pacman-dev list. Gerhard and Geoffroy, if I recall, kinda took the helm on this one. If we go with this solution, we won't have to play this game of cat-and-mouse with changing the checksums.
And remember makepkg source checksums are COMPLETELY different than signed packages. I'm not even sure why these two are being mentioned in the same light. -Dan
On Mon, Jan 12, 2009 at 3:48 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Jan 12, 2009 at 3:45 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Jan 12, 2009 at 3:23 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Mon, Jan 12, 2009 at 3:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Haven't we been over this like a hundred times? md5sums are not used for security. Not ever. Nope. Nada.
We use them solely to detect whether or not the download completed as expected. And sha256 is going way overboard here.
It has been discussed before, in fact, you said this back in November:
"The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256?"
...so a month ago you didn't think sha256 was going overboard, and now you do? I'd also make a semantics argument and say that if the "integrity" of the package could possibly be compromised by the creation of a malicious package with the same md5 checksum, then that absolutely effects the "security" of our system...the two ideas are not completely separate.
I do not recall my frame of mind at the time, but rereading that and knowing how I talk/write, I'd say that may have been tongue-in-cheek.
I guess the point I was making was that simply bumping the checksum won't be the best solution because the NEXT choice may be labeled as insecure and then the next and the next.
To put it in different terms: if you have some array that only holds 10 objects, and find out 10 isn't enough, you can bump it to 20. And when you find out 20 isn't enough, you can bump it to 100... and then 100 might not be enough... eventually, you're going to say "screw it" and tackle the problem differently (dynamically sized array).
There has been lots and lots of work done to get GPG signed packages going on the pacman-dev list. Gerhard and Geoffroy, if I recall, kinda took the helm on this one. If we go with this solution, we won't have to play this game of cat-and-mouse with changing the checksums.
And remember makepkg source checksums are COMPLETELY different than signed packages. I'm not even sure why these two are being mentioned in the same light.
Because the idea of "checksums for security" was brought up again.
On Mon, Jan 12, 2009 at 4:48 PM, Dan McGee <dpmcgee@gmail.com> wrote:
And remember makepkg source checksums are COMPLETELY different than signed packages. I'm not even sure why these two are being mentioned in the same light.
-Dan
The correlation came from the fact that the quote of Aaron's was from the "Can we trust our mirrors?" thread regarding the design and implementation of signed packages. I understand that they are two completely different problems/solutions. On Mon, Jan 12, 2009 at 4:45 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I guess the point I was making was that simply bumping the checksum won't be the best solution because the NEXT choice may be labeled as insecure and then the next and the next.
...
If we go with this solution, we won't have to play this game of cat-and-mouse with changing the checksums.
Security is ALWAYS a cat and mouse game...even if we implement a "secure" package signing solution, I'd venture a guess that it will have to be updated over time as the security world evolves. No solution is perfect (especially over time), and new hash/encryption functions are constantly being developed, as well as new ways to find vulnerabilities in those functions. That's just the way things go with cryptography, and security in general. I'd say that the justification for not updating the checksum method because "things are always changing" is not a valid reason to remain stagnant with an implementation that you know to be insecure. It has been proven that there are problems with md5 that could potentially cause issues with our current system, and changing one line in the default makepkg.conf would solve that particular problem, so why not do it? Is it that you don't see package verification as a possible security issue? Then why do we use hashes at all? Why not record the size of the file in bytes and put that in the PKGBUILD instead to check for incomplete downloads? If you say to make sure the download was not corrupted, isn't that just another way of saying we want to make sure that the user has downloaded what was intended? Switching to a better hash does that same exact thing, and eliminates the current threat of someone deliberately "corrupting" the file in a way that could cause harm to the user's system. I think you're dismissing this as a non-issue and saying it has been brought up before (which I acknowledge it has, but without any real discussion) without presenting any real downside to the proposed change. -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 4:20 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
Is it that you don't see package verification as a possible security issue? Then why do we use hashes at all? Why not record the size of the file in bytes and put that in the PKGBUILD instead to check for incomplete downloads?
Have you never had a corrupted download? "Alright, 356K... wait, not a tar file? what the hell?" checksums have been used to "check" transmission of data for ages. Hell, your router even does some form of checksumming on packets it sends and receives.
On Mon, Jan 12, 2009 at 5:29 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Have you never had a corrupted download? "Alright, 356K... wait, not a tar file? what the hell?"
checksums have been used to "check" transmission of data for ages. Hell, your router even does some form of checksumming on packets it sends and receives.
I'm not saying that since md5 is broken, it's completely worthless...its usage for packet verification still makes sense because that is extremely short-lived data that has other checks in place (sequence numbers, TTL values, identification codes, etc.) that prevent attackers from being able to take advantage of md5's weaknesses. When you're storing data that isn't temporary and want to use a checksum for verification of that data, you don't have a lot of other protections in place like you do with networking protocols. My point was that we absolutely SHOULD be using checksums, and preferably a checksum that has no known vulnerabilities at this time...that's all. Your response shows that you DO see the value in using checksums, but I'm not understanding your preference for md5 over sha256. -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 4:42 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Mon, Jan 12, 2009 at 5:29 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Have you never had a corrupted download? "Alright, 356K... wait, not a tar file? what the hell?"
checksums have been used to "check" transmission of data for ages. Hell, your router even does some form of checksumming on packets it sends and receives.
I'm not saying that since md5 is broken, it's completely worthless...its usage for packet verification still makes sense because that is extremely short-lived data that has other checks in place (sequence numbers, TTL values, identification codes, etc.) that prevent attackers from being able to take advantage of md5's weaknesses. When you're storing data that isn't temporary and want to use a checksum for verification of that data, you don't have a lot of other protections in place like you do with networking protocols.
My point was that we absolutely SHOULD be using checksums, and preferably a checksum that has no known vulnerabilities at this time...that's all. Your response shows that you DO see the value in using checksums, but I'm not understanding your preference for md5 over sha256.
It's not so much a preference as it is the fact that we won't be gaining much, if anything, from this change, and the change is going to take work. Making announcements, changing the official repos over, dealing with bug reports, etc etc... it's just work that seems like it's for naught.
On Mon, Jan 12, 2009 at 5:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
It's not so much a preference as it is the fact that we won't be gaining much, if anything, from this change, and the change is going to take work. Making announcements, changing the official repos over, dealing with bug reports, etc etc... it's just work that seems like it's for naught.
You wouldn't have to change anything at all except for the INTEGRITY_CHECK array in makepkg.conf. After the patch that Dan mentioned has been pushed, current users won't have problems (no matter what combination of checksums are present in a PKGBUILD), so the usage of sha256sums would gradually occur as packages are updated naturally. That's why I specifically said it would be best to make the change after pacman 3.0 has been released. There's no reason you'd have to go through the repos and make a sweeping update. -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 5:56 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
It's not so much a preference as it is the fact that we won't be gaining much, if anything, from this change, and the change is going to take work. Making announcements, changing the official repos over, dealing with bug reports, etc etc... it's just work that seems like it's for naught.
I made a patch and submitted it to pacman-dev, so the work is done...if you chose to implement it. This has definitely turned into a bike shed discussion (http://bikeshed.com/), which was not my intention. I hope I've demonstrated the value of this change, but do as you will. -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 9:38 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
I made a patch and submitted it to pacman-dev, so the work is done...if you chose to implement it.
Nix that...forgot pacman-dev was protected, so I have filed a feature request with the patch. There has been a bit more discussion/clarification there as well, if anyone cares: http://bugs.archlinux.org/task/12772 -- Aaron "ElasticDog" Schaefer
On Tue, Jan 13, 2009 at 12:11:25PM -0500, Aaron Schaefer wrote:
On Mon, Jan 12, 2009 at 9:38 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
I made a patch and submitted it to pacman-dev, so the work is done...if you chose to implement it.
Nix that...forgot pacman-dev was protected, so I have filed a feature request with the patch. There has been a bit more discussion/clarification there as well, if anyone cares:
What's pacman-dev protected from?
On Tue, Jan 13, 2009 at 11:29 AM, Loui Chang <louipc.ist@gmail.com> wrote:
On Tue, Jan 13, 2009 at 12:11:25PM -0500, Aaron Schaefer wrote:
On Mon, Jan 12, 2009 at 9:38 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
I made a patch and submitted it to pacman-dev, so the work is done...if you chose to implement it.
Nix that...forgot pacman-dev was protected, so I have filed a feature request with the patch. There has been a bit more discussion/clarification there as well, if anyone cares:
What's pacman-dev protected from?
I think he meant he wasn't subscribed :)
On Tue, Jan 13, 2009 at 12:32 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What's pacman-dev protected from?
I think he meant he wasn't subscribed :)
I subscribed and sent the patch, but it never showed up. I asked on IRC and someone said you had to be approved, so I assumed I didn't have permissions to post to the list. -- Aaron "ElasticDog" Schaefer
On Tue, Jan 13, 2009 at 12:17 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Tue, Jan 13, 2009 at 12:32 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What's pacman-dev protected from?
I think he meant he wasn't subscribed :)
I subscribed and sent the patch, but it never showed up. I asked on IRC and someone said you had to be approved, so I assumed I didn't have permissions to post to the list.
That's weird. It should let things through unless the attachment is over... hmmm 80K or something like that
On Tue, Jan 13, 2009 at 12:22 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Jan 13, 2009 at 12:17 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Tue, Jan 13, 2009 at 12:32 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What's pacman-dev protected from?
I think he meant he wasn't subscribed :)
I subscribed and sent the patch, but it never showed up. I asked on IRC and someone said you had to be approved, so I assumed I didn't have permissions to post to the list.
That's weird. It should let things through unless the attachment is over... hmmm 80K or something like that
I thought I was set up as a list owner, and I never got a message saying things were being blocked or in the queue. I'm not sure what happened. Are you certain you confirmed your subscription, and then sent from the correct email address? -Dan
On Tue, Jan 13, 2009 at 2:02 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I thought I was set up as a list owner, and I never got a message saying things were being blocked or in the queue. I'm not sure what happened. Are you certain you confirmed your subscription, and then sent from the correct email address?
-Dan
Yep, I sent the patch from the same address I subscribed with. After I saw that it didn't go through and then asked about it on IRC, I unsubscribed. Here was my confirmation... On Mon, Jan 12, 2009 at 9:37 PM, <pacman-dev-request@archlinux.org> wrote:
Welcome to the pacman-dev@archlinux.org mailing list!
To post to this list, send your email to:
pacman-dev@archlinux.org
General information about the mailing list is at:
http://archlinux.org/mailman/listinfo/pacman-dev
If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at:
http://archlinux.org/mailman/options/pacman-dev/aaron%40elasticdog.com
You can also make such adjustments via email by sending a message to:
pacman-dev-request@archlinux.org
with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions.
You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is:
axwoehzi
Normally, Mailman will remind you of your archlinux.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you.
On Mon, Jan 12, 2009 at 17:42, Aaron Schaefer <aaron@elasticdog.com> wrote:
My point was that we absolutely SHOULD be using checksums, and preferably a checksum that has no known vulnerabilities at this time...that's all. Your response shows that you DO see the value in using checksums, but I'm not understanding your preference for md5 over sha256.
It's not a preference of md5 over sha256. It's a lack of preference. A lot of us don't think it's a huge deal, as you are downloading source from some project's website (which could be faked, sure).. and so unless they KNOW you are using archlinux, what your ip is, and have taken the time to inject stuff that builds successfully with the original PKGBUILD _and_ is malicious... It's pretty far out there. Not to mention I've put sha1 and md5 in a lot of my packages, and I haven't heard of any attacks working against both algorithms to create a buildable malicious executable. And even if that wild and unresearched assumption of using two hashes is wrong, it doesn't matter. Anyone who wanted to do real harm would look at the binary packages we ship, skipping all the above effort. And lucky for Arch, there is work being done on package signing, and that's the concern we all seem to agree on. // jeff
On Mon, Jan 12, 2009 at 6:06 PM, Jeff Mickey <jeff@archlinux.org> wrote:
It's pretty far out there. Not to mention I've put sha1 and md5 in a lot of my packages, and I haven't heard of any attacks working against both algorithms to create a buildable malicious executable. And even if that wild and unresearched assumption of using two hashes is wrong, it doesn't matter. Anyone who wanted to do real harm would look at the binary packages we ship, skipping all the above effort.
I don't think it's that far out there...md5 has been known to be vulnerable since 2005 (theorized long before that), and it is possible to create completely different files with the same hash: http://www.mscs.dal.ca/~selinger/md5collision/ SHA-1 is also broken (also for a while now: http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html), but you're right, using them both does give you some protection. The problem is (which was the point of my original email), unless the users have both checksum types set in their makepkg.conf file, then the verification process of makepkg will show a warning even if both of the checksums are valid. That has been fixed, and I'm merely pointing out that it would be painless to move to a currently secure hash going forward. Like you said, since source is not downloaded directly from us (meaning we can't control it), being as protected as possible on our side of things will help if any one of our upstream providers does happen to get hacked. That's why I think you should care. It's true that some day we might have to move to Skein or whatever algorithm NIST decides will be the new SHA-3 standard, but that's just the way things are. -- Aaron "ElasticDog" Schaefer
On Mon, Jan 12, 2009 at 11:42 PM, Aaron Schaefer <aaron@elasticdog.com> wrote:
My point was that we absolutely SHOULD be using checksums, and preferably a checksum that has no known vulnerabilities at this time...that's all. Your response shows that you DO see the value in using checksums, but I'm not understanding your preference for md5 over sha256.
This makes sense in my opinion and the required work should be very low, simply changing the default in makepkg.conf, and waiting for the next pacman release with that other makepkg change (that might take some time though ;)). I think a big difference between archlinux packages and sources, is that packages are usually stored in the repos next to their checksums (only md5sum is supported there), while source checksums are stored in PKGBUILDs, not next to the sources. That means that when a package mirror is compromised, the checksums can be trivially updated, they are by no mean used for security here. But when a source mirror is compromised, the checksums in the PKGBUILDs normally remain the same, so they do have some security value here (in the situation where the PKGBUILD was created before the source mirror was compromised). Please correct me if I am wrong or totally offtopic :) Another thing to consider is that afaik, it is easy to find collisions on .tar files where padding is possible, but it might be much harder on tar.gz. And that md5sums are the shortest one so the best looking one in a PKGBUILD :) I thought that was the reason md5sums were still used everywhere.
participants (6)
-
Aaron Griffin
-
Aaron Schaefer
-
Dan McGee
-
Jeff Mickey
-
Loui Chang
-
Xavier