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.) >> >> Thoughts? > > 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 verify. 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. -- Jeroen _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
