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