I vaguely remember some discussion about fixing the layout of the checksums so that it was clear one had to run sha256sum rather than sha1.
However, I see that it's still rather misleading in appearance--that is, the words SHA1 sum are written there along with what I assume are the sha256 sums. (I didn't actually download an ISO to check, but it seems to be a lot of numbers for an sha1.)
The nice people at distrowatch are apparently among the ones confused by this, as their links to downloads also include links clearly marked SHA1.
A minor issue to be sure, but those who frequent the forums know how Those Who Wish To Try The Latest will almost certainly be confused.
On Tue, 2009-11-17 at 21:55 -0500, Scott Robbins wrote:
I vaguely remember some discussion about fixing the layout of the checksums so that it was clear one had to run sha256sum rather than sha1.
However, I see that it's still rather misleading in appearance--that is, the words SHA1 sum are written there along with what I assume are the sha256 sums. (I didn't actually download an ISO to check, but it seems to be a lot of numbers for an sha1.)
The nice people at distrowatch are apparently among the ones confused by this, as their links to downloads also include links clearly marked SHA1.
A minor issue to be sure, but those who frequent the forums know how Those Who Wish To Try The Latest will almost certainly be confused.
This is planned to be fixed in F13, it was too late to make this change for F12 when it really came to a head as we were past the feature freeze, and as the release engineer, I really should respect the feature freeze.
On Wednesday 18 November 2009, Scott Robbins wrote:
The nice people at distrowatch are apparently among the ones confused by this, as their links to downloads also include links clearly marked SHA1.
I've replaced it with "SHA256" about an hour ago. But yes, I was also one of those confused by the layout :-(
Ladislav
On Wed, Nov 18, 2009 at 12:04:52PM +0800, Ladislav Bodnar wrote:
On Wednesday 18 November 2009, Scott Robbins wrote:
The nice people at distrowatch are apparently among the ones confused by this, as their links to downloads also include links clearly marked SHA1.
I've replaced it with "SHA256" about an hour ago. But yes, I was also one of those confused by the layout :-(
Heh, glad I said the "nice folks" at distrowatch. Well, we can blame Jesse. :) (Hopefully, you realize I'm just being silly--need sleep.)
Whimsically yours, (and thanks for distrowatch by the way, an enjoyable site),
On Wed, Nov 18, 2009 at 12:30:37AM -0500, Scott Robbins wrote:
As suspect, there's already posts on the forums about this. (Smugly mutters, "told ya so". :)
Seriously, someone pointed out that some docmentation, the docs for burning CD's seem to indicate that one should use sha1.
http://docs.fedoraproject.org/readme-burning-isos/en_US/sn-validating-files....
That should probably get fixed--I'm not sure if I have write access, and I don't have a Windows machine to test the instructions, so someone?
(Assuming of course, that neither the poster on the forums nor myself are missing something blatently obvious and there's nothing to correct.)
On 11/19/2009 02:20 AM, Scott Robbins wrote:
On Wed, Nov 18, 2009 at 12:30:37AM -0500, Scott Robbins wrote:
As suspect, there's already posts on the forums about this. (Smugly mutters, "told ya so". :)
Seriously, someone pointed out that some docmentation, the docs for burning CD's seem to indicate that one should use sha1.
http://docs.fedoraproject.org/readme-burning-isos/en_US/sn-validating-files....
That should probably get fixed--I'm not sure if I have write access, and I don't have a Windows machine to test the instructions, so someone?
Refer to
https://www.redhat.com/archives/fedora-websites-list/2009-November/msg00047....
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
Rahul
On Thu, 2009-11-19 at 02:26 +0530, Rahul Sundaram wrote:
On 11/19/2009 02:20 AM, Scott Robbins wrote:
On Wed, Nov 18, 2009 at 12:30:37AM -0500, Scott Robbins wrote:
As suspect, there's already posts on the forums about this. (Smugly mutters, "told ya so". :)
Seriously, someone pointed out that some docmentation, the docs for burning CD's seem to indicate that one should use sha1.
http://docs.fedoraproject.org/readme-burning-isos/en_US/sn-validating-files....
That should probably get fixed--I'm not sure if I have write access, and I don't have a Windows machine to test the instructions, so someone?
Refer to
https://www.redhat.com/archives/fedora-websites-list/2009-November/msg00047....
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
To be clear, I think the documentation page that Scott linked talks about SHA-1 not because someone misread the checksum file but simply because it's _old_. It was written at a time when the checksums actually where SHA-1. Note the reference to Fedora 7.
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
On 11/19/2009 03:43 AM, Adam Williamson wrote:
On Thu, 2009-11-19 at 02:26 +0530, Rahul Sundaram wrote:
On 11/19/2009 02:20 AM, Scott Robbins wrote:
On Wed, Nov 18, 2009 at 12:30:37AM -0500, Scott Robbins wrote:
As suspect, there's already posts on the forums about this. (Smugly mutters, "told ya so". :)
Seriously, someone pointed out that some docmentation, the docs for burning CD's seem to indicate that one should use sha1.
http://docs.fedoraproject.org/readme-burning-isos/en_US/sn-validating-files....
That should probably get fixed--I'm not sure if I have write access, and I don't have a Windows machine to test the instructions, so someone?
Refer to
https://www.redhat.com/archives/fedora-websites-list/2009-November/msg00047....
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
To be clear, I think the documentation page that Scott linked talks about SHA-1 not because someone misread the checksum file but simply because it's _old_. It was written at a time when the checksums actually where SHA-1. Note the reference to Fedora 7.
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
As you can read from the link to fedora-websites list, updating that documentation requires a Windows utility we can trust on.
Rahul
On Thu, 2009-11-19 at 03:59 +0530, Rahul Sundaram wrote:
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
As you can read from the link to fedora-websites list, updating that documentation requires a Windows utility we can trust on.
I disagree. The page could still be updated to say that the checksums are SHA-256, even before a Windows utility for checking such checksums is available. This would still be far more valuable (and accurate) than the current situation, in which the page is essentially lying to people by telling them the checksums are SHA-1. Don't make the perfect the enemy of the better. :)
On 11/19/2009 04:45 AM, Adam Williamson wrote:
On Thu, 2009-11-19 at 03:59 +0530, Rahul Sundaram wrote:
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
As you can read from the link to fedora-websites list, updating that documentation requires a Windows utility we can trust on.
I disagree. The page could still be updated to say that the checksums are SHA-256, even before a Windows utility for checking such checksums is available. This would still be far more valuable (and accurate) than the current situation, in which the page is essentially lying to people by telling them the checksums are SHA-1. Don't make the perfect the enemy of the better. :)
I was responding to your earlier point about updating the document and not the latter point about updating the verify website page. There is nothing to disagree, really.
Rahul
On Thu, 2009-11-19 at 04:43 +0530, Rahul Sundaram wrote:
On 11/19/2009 04:45 AM, Adam Williamson wrote:
On Thu, 2009-11-19 at 03:59 +0530, Rahul Sundaram wrote:
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
As you can read from the link to fedora-websites list, updating that documentation requires a Windows utility we can trust on.
I disagree. The page could still be updated to say that the checksums are SHA-256, even before a Windows utility for checking such checksums is available. This would still be far more valuable (and accurate) than the current situation, in which the page is essentially lying to people by telling them the checksums are SHA-1. Don't make the perfect the enemy of the better. :)
I was responding to your earlier point about updating the document and not the latter point about updating the verify website page. There is nothing to disagree, really.
Um. I'm still saying the docs.fedoraproject.org page should be updated immediately. I wasn't talking about the verify page in the bit you quoted above. Apologies if that wasn't clear.
Adam Williamson wrote:
To be clear, I think the documentation page that Scott linked talks about SHA-1 not because someone misread the checksum file but simply because it's _old_. It was written at a time when the checksums actually where SHA-1. Note the reference to Fedora 7.
Indeed. I filed a bug on this when Fedora 11 came out and it didn't get updated. After various discussion and some excellent help from Richard Jones, we have a pretty reasonable way to build a sha25sum.exe that we can distribute from fedoraproject.org and feel more comfortable recommending to Windows users.
Unfortunately, this didn't happen in time for Fedora 12. But seeing that it's been broken since Fedora 11, another week or two shouldn't kill us. :)
I think the above page needs to be updated to refer to SHA-256 checksums. Also, both it and https://fedoraproject.org/en/verify might benefit from explicitly mentioning the potential confusion between the signature algorithm and the checksum algorithm, until F13 is current.
I'm torn on whether we should call out this issue on fp.o/verify. The page does clearly indicate the command to be used. I fear that adding something like:
NOTE: Please don't confuse the 'Hash:' line in the *CHECKSUM file, (which is part of the PGP signature) with the type of hash algorithm used to verify the .iso files
might only server to add confusion to those who weren't already confused. I think many of the users who were confused downloaded via the torrents and likely never saw the fp.o/verify page at all anyway.
In the end, I think adding some comments directly to the *CHECKSUM files will be much more useful (and is something Jesse has said is on his list of rel-eng tasks -- a list I imagine is fairly long. ;).
I think something along the lines of:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
To verify the file(s) listed below, run:
sha256sum -c Fedora-12-i686-Live-CHECKSUM'
See https://fedoraproject.org/verify for more details.
5ad27455df004ee23fbc5a05dfa039a14e59956dccf4e767d493601e0bfa4001 Fedora-12-i686-Live.iso
On Wed, Nov 18, 2009 at 10:23:55PM -0500, Todd Zullinger wrote:
Adam Williamson wrote:
Unfortunately, this didn't happen in time for Fedora 12. But seeing that it's been broken since Fedora 11, another week or two shouldn't kill us. :)
It won't kill us, but sheesh, you should see some of the comments on the forums. :) It really only becomes an issue during a new release.
As I said in my original post, it's a relatively minor issue--the majority of folks who don't know how to use google will post a complaint in the forums and get their answer--sometimes sympathetic, sometimes rude, but they'll get their answer.
NOTE: Please don't confuse the 'Hash:' line in the *CHECKSUM file, (which is part of the PGP signature) with the type of hash algorithm used to verify the .iso files
might only server to add confusion to those who weren't already confused. I think many of the users who were confused downloaded via the torrents and likely never saw the fp.o/verify page at all anyway.
I agree with that. A very simple comment, such as your suggestion, should be ample, and cause less confusion than a detailed explanation. (I'm leaving in your suggestion for those who missed it the first time.) :)
I think something along the lines of:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
To verify the file(s) listed below, run:
sha256sum -c Fedora-12-i686-Live-CHECKSUM'
See https://fedoraproject.org/verify for more details.
On Thursday 19 November 2009, Rahul Sundaram wrote:
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
Maybe it would be simpler to call the file SHA256SUM (or SHA256) instead of CHECKSUM? As far as I remember, these files used to be called MD5SUM, then SHA1SUM, which made it very clear what was inside. But with so many different checksum standards, calling the file CHECKSUM is bound to lead to confusion.
Ladislav
On 11/19/2009 06:04 AM, Ladislav Bodnar wrote:
On Thursday 19 November 2009, Rahul Sundaram wrote:
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
Maybe it would be simpler to call the file SHA256SUM (or SHA256) instead of CHECKSUM? As far as I remember, these files used to be called MD5SUM, then SHA1SUM, which made it very clear what was inside. But with so many different checksum standards, calling the file CHECKSUM is bound to lead to confusion.
I think the generic name was picked up because nobody believes that SHA256 hashes are going to be cryptographically secure for a long time and we are bound to switch to stronger checksums over a period of time but I think, a clear filename does make it more easier to avoid this mass confusion. Jesse Keating?
Rahul
On Wed, Nov 18, 2009 at 5:39 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
On 11/19/2009 06:04 AM, Ladislav Bodnar wrote:
On Thursday 19 November 2009, Rahul Sundaram wrote:
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
Maybe it would be simpler to call the file SHA256SUM (or SHA256) instead of CHECKSUM? As far as I remember, these files used to be called MD5SUM, then SHA1SUM, which made it very clear what was inside. But with so many different checksum standards, calling the file CHECKSUM is bound to lead to confusion.
I think the generic name was picked up because nobody believes that SHA256 hashes are going to be cryptographically secure for a long time and we are bound to switch to stronger checksums over a period of time but I think, a clear filename does make it more easier to avoid this mass confusion. Jesse Keating?
That would be my guess also. My guess is that when the NIST new checksum is decided and published that will be the tools to work with. Looking for windows tools.. I only found ones that were Cygwin based.. it would be interesting to see if they can be ported to use MinGW
http://md5deep.sourceforge.net/ #this has tools for sha256 and works under cygwin.
Some sites use multiple checksums but there are pros and cons that I have heard various cryptoanalysts argue about and I am no clearer which ones are right :).
On Thu, 2009-11-19 at 06:09 +0530, Rahul Sundaram wrote:
On 11/19/2009 06:04 AM, Ladislav Bodnar wrote:
On Thursday 19 November 2009, Rahul Sundaram wrote:
Note that changing HASH: SHA1 to anything else in the top of the file will make the gpg check fail since it writes it out that way. So it's sort of a tricky issue to solve. Not sloppiness.
Maybe it would be simpler to call the file SHA256SUM (or SHA256) instead of CHECKSUM? As far as I remember, these files used to be called MD5SUM, then SHA1SUM, which made it very clear what was inside. But with so many different checksum standards, calling the file CHECKSUM is bound to lead to confusion.
I think the generic name was picked up because nobody believes that SHA256 hashes are going to be cryptographically secure for a long time and we are bound to switch to stronger checksums over a period of time but I think, a clear filename does make it more easier to avoid this mass confusion. Jesse Keating?
Rahul
Changing the filename each time was getting to be a hassle, so we named the file generically. This happened not only in pungi, but in many of the other tools we had to update when moving from md5 or sha1 to sha256. Since we know we'll have to do it again we've made that task easier next time.
The solution here is to put a blurb in the file itself about how to verify it. That is something I'm going to do, but by the time it was suggested and I conceded that it was needed, we were past the feature freeze and I was not going to introduce a feature in our compose tool at that point.