[arch-general] Pointless to use non-md5 for makepkg INTEGRITY_CHECK

[Aaron Schaefer]

On Mon, Jan 12, 2009 at 4:48 PM, Dan McGee <dpmcgee at 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 at 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