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.