Some of you might be aware that the instructions for verifying our *-CHECKSUM files on Windows have been broken since we moved to SHA256. Previously, we linked users to a sha1sum.exe built by the GnuPG project. With SHA256, we don't have that ability.
Fortunately, the good folks working on MingW have made it possible for us to build a sha256sum.exe from the coreutils sources. We can do this in koji even. (A huge thanks to Richard Jones for his help and patches.)
Much of this is discussed at https://bugzilla.redhat.com/527060.
I've created a simple mingw32-sha256sum package, built it in koji and tested it on the lone Windows XP system I have readily available. Of course, I just built this as a scratch build, so it will expire at some point.
What I'm here for is to gather ideas for how to properly go about building the mingw32-sha256sum and keeping it around so that when I extract the sha256sum.exe and upload it to fedoraproject.org we will have the koji built rpm to compare the binary against. Otherwise, the whole process falls back to "Trust that Todd didn't trojan the executable." And while I'd be flattered if folks had that much trust in me, I think it would be unwise to encourage or expect. :)
(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?
On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote:
Some of you might be aware that the instructions for verifying our *-CHECKSUM files on Windows have been broken since we moved to SHA256. Previously, we linked users to a sha1sum.exe built by the GnuPG project. With SHA256, we don't have that ability.
Fortunately, the good folks working on MingW have made it possible for us to build a sha256sum.exe from the coreutils sources. We can do this in koji even. (A huge thanks to Richard Jones for his help and patches.)
Much of this is discussed at https://bugzilla.redhat.com/527060.
I've created a simple mingw32-sha256sum package, built it in koji and tested it on the lone Windows XP system I have readily available. Of course, I just built this as a scratch build, so it will expire at some point.
What I'm here for is to gather ideas for how to properly go about building the mingw32-sha256sum and keeping it around so that when I extract the sha256sum.exe and upload it to fedoraproject.org we will have the koji built rpm to compare the binary against. Otherwise, the whole process falls back to "Trust that Todd didn't trojan the executable." And while I'd be flattered if folks had that much trust in me, I think it would be unwise to encourage or expect. :)
(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!"
On Tue, Nov 24, 2009 at 9:25 AM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote:
Some of you might be aware that the instructions for verifying our *-CHECKSUM files on Windows have been broken since we moved to SHA256. Previously, we linked users to a sha1sum.exe built by the GnuPG project. With SHA256, we don't have that ability.
Fortunately, the good folks working on MingW have made it possible for us to build a sha256sum.exe from the coreutils sources. We can do this in koji even. (A huge thanks to Richard Jones for his help and patches.)
Much of this is discussed at https://bugzilla.redhat.com/527060.
I've created a simple mingw32-sha256sum package, built it in koji and tested it on the lone Windows XP system I have readily available. Of course, I just built this as a scratch build, so it will expire at some point.
What I'm here for is to gather ideas for how to properly go about building the mingw32-sha256sum and keeping it around so that when I extract the sha256sum.exe and upload it to fedoraproject.org we will have the koji built rpm to compare the binary against. Otherwise, the whole process falls back to "Trust that Todd didn't trojan the executable." And while I'd be flattered if folks had that much trust in me, I think it would be unwise to encourage or expect. :)
(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!"
Well giving people the instructions on how to compile this and getting a 'neutral' party to make these for the various Linux distributions would help. Depending on your level of trust, we could ask linux foundation, fsf or heck even micros.. ok scratch that one. But basically we can make our own for the time being and give out plain instructions for people to make them so that they can be replicated.
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
Jeroen van Meeuwen wrote:
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.
Indeed, that's the plan. It would be served up via SSL, just as the GPG keys and *-CHECKSUM files are currently. That way, if someone comes to https://fedoraproject.org/verify, they at least have our SSL certificate as a starting point for trust.
Jesse Keating wrote:
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!"
At some point, people need to bootstrap. The situation now is that there isn't a well trusted tool on Windows that we can point users to for verifying the *-CHECKSUM files (if you know differently, please let me know). I'd like to improve that by providing a sha256sum.exe that we can provide source code for, just as any decent cryptographic tool should have.
I also think it's important to keep in mind that the use for the sha256sum.exe is to verify that the bits they downloaded are intact, not that they have not been altered. To verify authenticity, checking the PGP signature on the *-CHECKSUM file is required. We explain how to do both on https://fedoraproject.org/verify. Many users, especially Windows users, only care about verifying the data's integrity.
I believe that providing a sha256sum.exe via https://fp.o/ is surely an improvement over "Download the .iso and hope it works or check it with some third-party checksum tool that we can't even hope to verify."
On Tue, 2009-11-24 at 13:06 -0500, Todd Zullinger wrote:
I believe that providing a sha256sum.exe via https://fp.o/ is surely an improvement over "Download the .iso and hope it works or check it with some third-party checksum tool that we can't even hope to verify."
I agree, I just wanted to point out the catch-22.
Jesse Keating wrote:
I agree, I just wanted to point out the catch-22.
Heh. I'm sorry if I came off a bit defensive. :)
Jesse Keating wrote:
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!"
I have the same opinion of signing the page with the hashes. The pages that list the hashes for F12 are:
https://fedoraproject.org/static/checksums/Fedora-12-i386-CHECKSUM https://fedoraproject.org/static/checksums/Fedora-12-x86_64-CHECKSUM
They are PGP-signed using *self-signed* keys listed in:
https://fedoraproject.org/static/fedora.gpg
One web page is signed using keys on another web page. So someone
1. Downloads the ISOs 2. Checks the hash vs. the web page 3. Checks the signature on the web page vs. a key on another web page 4. Cannot check the key
Unless you want people to:
4. Check the key vs. the one on the ISOs
which gets circular.
If we don't trust the page which has the hashes, why do we trust the page which has the keys more? If someone can alter the ISOs and then alter the published hashes to hide their tracks, why not alter the published keys, as well? Ultimately I'm wondering what problem we're solving by signing the web page in the first place.
Sign the hash page with a key which descends from a verifiable, trusted root (even a key signed by the release manager would be better than self-signed), or don't sign the page. I lean toward not signing, and IRL I'm a paranoid security guy.
Allen Kistler wrote:
I have the same opinion of signing the page with the hashes. The pages that list the hashes for F12 are:
https://fedoraproject.org/static/checksums/Fedora-12-i386-CHECKSUM https://fedoraproject.org/static/checksums/Fedora-12-x86_64-CHECKSUM
They are PGP-signed using *self-signed* keys listed in:
https://fedoraproject.org/static/fedora.gpg
One web page is signed using keys on another web page. So someone
- Downloads the ISOs
- Checks the hash vs. the web page
- Checks the signature on the web page vs. a key on another web page
- Cannot check the key
Unless you want people to:
- Check the key vs. the one on the ISOs
which gets circular.
If we don't trust the page which has the hashes, why do we trust the page which has the keys more? If someone can alter the ISOs and then alter the published hashes to hide their tracks, why not alter the published keys, as well? Ultimately I'm wondering what problem we're solving by signing the web page in the first place.
Sign the hash page with a key which descends from a verifiable, trusted root (even a key signed by the release manager would be better than self-signed), or don't sign the page. I lean toward not signing, and IRL I'm a paranoid security guy.
To be fair, the *-CHECKSUM files were only added to https://fedoraproject.org/static/checksums/ recently (F-11). And they are still widely available via mirrors and bit torrent. The GPG signatures are quite useful for anyone downloading the CHECKSUM files by those methods.
I don't mind that the GPG keys are role keys and are not signed by (m)any other keys (though Jesse has signed some of them in the past). Using SSL to get the keys seems reasonable to me. All trust has to start somewhere.
On Tue, Nov 24, 2009 at 10:33:16 -0500, Todd Zullinger tmz@pobox.com wrote:
What I'm here for is to gather ideas for how to properly go about building the mingw32-sha256sum and keeping it around so that when I extract the sha256sum.exe and upload it to fedoraproject.org we will have the koji built rpm to compare the binary against. Otherwise, the whole process falls back to "Trust that Todd didn't trojan the executable." And while I'd be flattered if folks had that much trust in me, I think it would be unwise to encourage or expect. :)
I was thinking about what the gpl requirements are for publishing executables built with mingw are for another project that might be set up on fedorahosted. Since mingw stuff is likely to include staticly linked libraries, I think you need to have pointers to the sources for the versions of all of the included libraries.
So while I haven't asked someone about this before, I was thinking that I would probably need to determine the libraries that got linked in and then note the versions that were used to do the build and include links into koji for all of the involved src rpms prominently on the download page.
infrastructure@lists.fedoraproject.org
-
Allen Kistler -
Bruno Wolff III -
Jeroen van Meeuwen -
Jesse Keating -
Stephen John Smoogen -
Todd Zullinger