Re: checksum suggestion

2009-06-20 Thread Frank Murphy

On 19/06/09 20:36, Bill Davidsen wrote:

Tom Horsley wrote:


snip



I just posted a minuscule one liner in response to Stan's comment in the
'sha256sum' thread, it could be a two liner and include your suggestion.
Better yet would be to make the checksum file a shell script which one
could source and do the right thing no matter what comes in the future.
That would be convenient for easily confused users.



For confused users, have a simple icon\gui to do the cli bit.
Dare I say it Point  Click*

Frank

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


Re: checksum suggestion

2009-06-20 Thread Bruno Wolff III
On Thu, Jun 18, 2009 at 21:00:53 -0400,
  Tom Horsley tom.hors...@att.net wrote:
 There is little doubt that sometime soon some fiendish
 mathematician somewhere will discover that sha256sum
 is really hopelessly broken and only a fool would ever
 have used it, then we'll all have to switch to
 shaalephnullsum or some such :-).

There is already a process going on to create a new hash standard similar
to what was done for AES. The SHA-2 hashes are thought to be weak since
they use a scheme similar to MD5 and SHA1 and those have serious problems
now, but are still usable in most cases. See:
http://en.wikipedia.org/wiki/SHA-3

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


Re: checksum suggestion

2009-06-19 Thread Bill Davidsen

Tom Horsley wrote:

There is little doubt that sometime soon some fiendish
mathematician somewhere will discover that sha256sum
is really hopelessly broken and only a fool would ever
have used it, then we'll all have to switch to
shaalephnullsum or some such :-).

How about we forestall all this nonsense by creating
a new rpm that just has one symlink in it named

best-sum

Then everyone can just always use the best-sum program
when checking isos, etc and when a new release comes
out, it can come with a new best-sum package that installs
the appropriate symlink to the appropriate actual
checksum tool :-).

I just posted a minuscule one liner in response to Stan's comment in the 
'sha256sum' thread, it could be a two liner and include your suggestion. Better 
yet would be to make the checksum file a shell script which one could source and 
 do the right thing no matter what comes in the future. That would be 
convenient for easily confused users.


But barring some huge breakthrough in computing power or theory, sha256sum will 
be safe for decades.


Security note: any checksum is only as secure as the source of the checksum. If 
you get the checksum from a fedora official site then sha256sum is better than 
md5sum to protect against deliberate tampering. But if you are checking to catch 
transmission errors, which are random, then md5sum will catch all but one in 
billions. In other words, if an evildoer were tampering with the ISO image, they 
would probably tamper with the checksum you got from the same place, so 
sha256sum is subject to deliberate attacks from that method.


I think I got my official checksums from the wiki, I did download mine from an 
official site, I am not a trusting person. ;-)


--
Bill Davidsen david...@tmr.com
  We have more to fear from the bungling of the incompetent than from
the machinations of the wicked.  - from Slashdot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


Re: checksum suggestion

2009-06-19 Thread Wolfgang S. Rupprecht

Bill Davidsen david...@tmr.com writes:
 Security note: any checksum is only as secure as the source of the
 checksum. 

Very true.  One has to ask why bother having a checksum at all???  Why
not just digitally sign the iso directly (with a detached signature).

Digital signatures are just hash-digests of the object which have been
individually signed.  

Signing the iso's directly (instead of signing a checksum file) solves
two problems: 1) one knows that the checksum hasn't been tampered with
and 2) the mechanics of which checksum command to use is hidden from the
user.  There is also another slight advantage, newbies don't end up
comparing the checksums by hand if they don't notice the -c flag to
sha256sum.

-wolfgang
-- 
Wolfgang S. Rupprecht  Android 1.5 (Cupcake) and Fedora-11

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


Re: checksum suggestion

2009-06-19 Thread Tom Horsley
On Fri, 19 Jun 2009 15:36:25 -0400
Bill Davidsen wrote:

 But barring some huge breakthrough in computing power or theory, sha256sum 
 will 
 be safe for decades.

That's what they said about md5sum and sha2sum far less than decades ago :-).

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


checksum suggestion

2009-06-18 Thread Tom Horsley
There is little doubt that sometime soon some fiendish
mathematician somewhere will discover that sha256sum
is really hopelessly broken and only a fool would ever
have used it, then we'll all have to switch to
shaalephnullsum or some such :-).

How about we forestall all this nonsense by creating
a new rpm that just has one symlink in it named

best-sum

Then everyone can just always use the best-sum program
when checking isos, etc and when a new release comes
out, it can come with a new best-sum package that installs
the appropriate symlink to the appropriate actual
checksum tool :-).

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines