On 11/24/2009 05:25 PM, Jesse Keating wrote:
On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote:
> (I really don't want to maintain the mingw32-sha256sum package for
> Fedora, as it's just a quick and dirty hack to built a small subset of
> of coreutils for Windows.)
Well, if you have to use a tool from the project, to verify other bits
from the project, the verification just became a lot less trusted. If
you don't trust the bits you got from the project, why would you trust
the tool the project gives you to verify the bits? "Here use this tool
to verify our bits. Trust us, we swear!"
While this is completely true for, say winxpsp2.iso vs. m$-md5um.exe,
mind that the sources to sha256sum.exe are actually available and can be
verified on a completely verifiable stack one does already trust
(verifiable except for x86 CPU inaccuracy of course).
If not the transparency helps to boost the trustworthiness, or if that's
not trustworthy enough, then how does one verify a binary rpm actually
comes from the source that is shipped alongside with it, not to even
mention gnupg shipped by Fedora against RPMs shipped by Fedora.
Then, if trust was anything worth being concerned about why would you
even need a .exe in the first place? For all you know the OS itself
makes the .exe say OK or NOT OK in very, very arbitrary ways you can't
The goal is, of course, to verify the .iso against what is listed as
it's sha256sum. Whether the tools ultimately come from the same source
doesn't matter. It should, though, be advisable to not include the
sha246sum.exe on the mirrors, and only serve the file over http over ssl.