| Message ID | 1412692250-13513-2-git-send-email-Vincent.Riera@imgtec.com |
|---|---|
| State | Superseded |
| Headers | show |
Dear Vicente Olivert Riera, On Tue, 7 Oct 2014 15:30:50 +0100, Vicente Olivert Riera wrote: > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> > --- > package/ser2net/ser2net.hash | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > create mode 100644 package/ser2net/ser2net.hash > > diff --git a/package/ser2net/ser2net.hash b/package/ser2net/ser2net.hash > new file mode 100644 > index 0000000..d24e3a8 > --- /dev/null > +++ b/package/ser2net/ser2net.hash > @@ -0,0 +1,6 @@ > +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz > +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz > +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz > +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz > +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz > +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz Why having all those hashes? And the comment indicating how they have been found is missing (locally computed? found on the upstream web site). Best regards, Thomas
Dear Thomas Petazzoni, On 10/07/2014 06:23 PM, Thomas Petazzoni wrote: > Dear Vicente Olivert Riera, > > On Tue, 7 Oct 2014 15:30:50 +0100, Vicente Olivert Riera wrote: >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> >> --- >> package/ser2net/ser2net.hash | 6 ++++++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> create mode 100644 package/ser2net/ser2net.hash >> >> diff --git a/package/ser2net/ser2net.hash b/package/ser2net/ser2net.hash >> new file mode 100644 >> index 0000000..d24e3a8 >> --- /dev/null >> +++ b/package/ser2net/ser2net.hash >> @@ -0,0 +1,6 @@ >> +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz >> +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz >> +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz >> +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz >> +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz >> +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz > > Why having all those hashes? Why not? Those are all the hashes supported in Buildroot. The more we have the better. > And the comment indicating how they have > been found is missing (locally computed? found on the upstream web > site). I haven't added any comment because those hashes were locally computed. Do I need to add a comment explain that?
Dear Vicente Olivert Riera, On Wed, 8 Oct 2014 09:57:39 +0100, Vicente Olivert Riera wrote: > > Why having all those hashes? > > Why not? Those are all the hashes supported in Buildroot. The more we > have the better. I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO. Something to be discussed at the meeting maybe? > > And the comment indicating how they have > > been found is missing (locally computed? found on the upstream web > > site). > > I haven't added any comment because those hashes were locally computed. > Do I need to add a comment explain that? Yes, I believe so. Best regards, Thomas
Dear Thomas Petazzoni, On 10/08/2014 10:20 AM, Thomas Petazzoni wrote: > Dear Vicente Olivert Riera, > > On Wed, 8 Oct 2014 09:57:39 +0100, Vicente Olivert Riera wrote: > >>> Why having all those hashes? >> >> Why not? Those are all the hashes supported in Buildroot. The more we >> have the better. > > I disagree: more hashes means more work to do when bumping the package. > Either one strong hash, or two weaker hashes should be sufficient IMO. More work? I disagree. I created the hash file with a one-liner command: for i in md5 sha1 sha224 sha256 sha384 sha512; do echo $i `${i}sum ser2net-2.10.0.tar.gz` >> ../package/ser2net/ser2net.hash; done > Something to be discussed at the meeting maybe? > >>> And the comment indicating how they have >>> been found is missing (locally computed? found on the upstream web >>> site). >> >> I haven't added any comment because those hashes were locally computed. >> Do I need to add a comment explain that? > > Yes, I believe so. No problem, I can resend the patch adding that comment. Or maybe it's easier if you or Peter do it, since is a trivial change and you are the ones who will commit the patch at the end. > Best regards, > > Thomas >
On 10/08/2014 10:20 AM, Thomas Petazzoni wrote: > Dear Vicente Olivert Riera, > > On Wed, 8 Oct 2014 09:57:39 +0100, Vicente Olivert Riera wrote: > >>> Why having all those hashes? >> >> Why not? Those are all the hashes supported in Buildroot. The more we >> have the better. > > I disagree: more hashes means more work to do when bumping the package. > Either one strong hash, or two weaker hashes should be sufficient IMO. > > Something to be discussed at the meeting maybe? I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
On 10/08/2014 10:37 AM, Markos Chandras wrote: > On 10/08/2014 10:20 AM, Thomas Petazzoni wrote: >> Dear Vicente Olivert Riera, >> >> On Wed, 8 Oct 2014 09:57:39 +0100, Vicente Olivert Riera wrote: >> >>>> Why having all those hashes? >>> >>> Why not? Those are all the hashes supported in Buildroot. The more we >>> have the better. >> >> I disagree: more hashes means more work to do when bumping the package. >> Either one strong hash, or two weaker hashes should be sufficient IMO. >> >> Something to be discussed at the meeting maybe? > > I am curious, what's the point of supporting more than one hash types? > Why not support only the strongest one? The hashes have a limited range of values, so it's possible to have two inputs which produce the same hash. It's very unlikely, but it can happen. So, supporting more than one hash type is to increase the security. It's very unlikely that two inputs generate the same hash for one algorithm, and it's even more unlikely if those two input generate the same hashes for two different algorithms, and more for three algorithms, etc.
>>>>> "Markos" == Markos Chandras <Markos.Chandras@imgtec.com> writes: Hi, >> I disagree: more hashes means more work to do when bumping the package. >> Either one strong hash, or two weaker hashes should be sufficient IMO. >> >> Something to be discussed at the meeting maybe? > I am curious, what's the point of supporting more than one hash types? > Why not support only the strongest one? The point is that we want to use the hashes published by upstream if available, and different projects use different hashes. We could decide on one specific hash type (the "best one") to use whenever we calculate a hash ourselves through. Looking at what we have, that should probably be sha256: find package -name \*.hash|xargs grep -l Locally|xargs tail -n 1 ==> package/gnupg/gnupg.hash <== sha256 b7b5fdda78849955e0cdbc5a085f3a08f8b7fba126c622085debb62def5d6388 gnupg-1.4.18.tar.bz2 ==> package/libksba/libksba.hash <== sha256 bc96b95516bd2b67f413bc8b5cc5a75a2583c6e666d24dfd0d5bcc6b1aab46f9 libksba-1.3.1.tar.bz2 ==> package/libassuan/libassuan.hash <== sha256 39f8a7c9349aaaf7ccd937b90660153ec4d2d4df2465018754e5bcae5b1db77b libassuan-2.1.2.tar.bz2 ==> package/openssh/openssh.hash <== sha256 b2f8394eae858dabbdef7dac10b99aec00c95462753e80342e530bbb6f725507 openssh-6.7p1.tar.gz ==> package/dnsmasq/dnsmasq.hash <== sha256 7d0bd23f5d74b3a6b26a75d5ffcf9db81d461b47cbe578cb65a83a98008600b1 dnsmasq-2.72.tar.xz ==> package/atftp/atftp.hash <== sha1 fc9e9f821dfd2f257b4a5c32b948ed60b4e31fd1 atftp-0.7.1.tar.gz ==> package/gnupg2/gnupg2.hash <== sha256 7758e30dc382ae7a7167ed41b7f936aa50af5ea2d6fccdef663b5b750b65b8e0 gnupg-2.0.26.tar.bz2 ==> package/dejavu/dejavu.hash <== sha1 33fa825aa1dd44ce23a11af92b3078e978ff513d dejavu-fonts-ttf-2.34.tar.bz2 ==> package/fan-ctrl/fan-ctrl.hash <== sha1 d8ba5bac15e90c36a4e908ca1c98fac83bf702ea fan-ctrl.c?revision=1.3 ==> package/gnutls/gnutls.hash <== sha256 4762afab5e1b9e829c5f53d2b00cd5e41d43fa6d035efcf239e3fe0459134d45 gnutls-3.2.18.tar.xz ==> package/bash/bash.hash <== sha256 afc687a28e0e24dc21b988fa159ff9dbcf6b7caa92ade8645cc6d5605cd024d4 bash-4.3.tar.gz
On 10/08/2014 06:37 AM, Markos Chandras wrote: >>>> Why having all those hashes? >>> >>> Why not? Those are all the hashes supported in Buildroot. The more we >>> have the better. >> >> I disagree: more hashes means more work to do when bumping the package. >> Either one strong hash, or two weaker hashes should be sufficient IMO. >> >> Something to be discussed at the meeting maybe? > > I am curious, what's the point of supporting more than one hash types? > Why not support only the strongest one? Normally you want to use upstream-provided hashes and they're not of the same class for security. You've got basically 3 kinds of security: 1) Upstream releases new version/software with hashes. 2) Upstream releases tarball signed (pgp). 3) Upstream just releases. 1 and 2 can intersect which is great. Announcements ideally go into a mailing list hence the chance of compromising that is far lower than a hash file or note in the web page (which can be the same hosting site/server as the tarball). If you use a signed pgp that reduces the chance of website compromise since ideally the key is stored elsewhere as well. If the hash/signature is on a mailing list archive the same happens (another site, harder to get all the pieces together). If the release is using a weak hash (md5, sha1) for which there are possible collissions using two hashes makes it extremely difficult to collide in a useful way. (re)computing the hash for a bump/package requires that people check the signature and we trust that they did it right (did anyone recheck besides Baruch with openssh?) instead of just sha256sum(ing) the file and sticking that result. I think i've covered most of the cases here :) Regards.
On 10/08/2014 11:11 AM, Gustavo Zacarias wrote: > On 10/08/2014 06:37 AM, Markos Chandras wrote: > >>>>> Why having all those hashes? >>>> >>>> Why not? Those are all the hashes supported in Buildroot. The more we >>>> have the better. >>> >>> I disagree: more hashes means more work to do when bumping the package. >>> Either one strong hash, or two weaker hashes should be sufficient IMO. >>> >>> Something to be discussed at the meeting maybe? >> >> I am curious, what's the point of supporting more than one hash types? >> Why not support only the strongest one? > > Normally you want to use upstream-provided hashes and they're not of the > same class for security. > You've got basically 3 kinds of security: > 1) Upstream releases new version/software with hashes. > 2) Upstream releases tarball signed (pgp). > 3) Upstream just releases. > > 1 and 2 can intersect which is great. > Announcements ideally go into a mailing list hence the chance of > compromising that is far lower than a hash file or note in the web page > (which can be the same hosting site/server as the tarball). > If you use a signed pgp that reduces the chance of website compromise > since ideally the key is stored elsewhere as well. > If the hash/signature is on a mailing list archive the same happens > (another site, harder to get all the pieces together). > If the release is using a weak hash (md5, sha1) for which there are > possible collissions using two hashes makes it extremely difficult to > collide in a useful way. > (re)computing the hash for a bump/package requires that people check the > signature and we trust that they did it right (did anyone recheck > besides Baruch with openssh?) instead of just sha256sum(ing) the file > and sticking that result. > I think i've covered most of the cases here :) > Regards. > I understand that, but realistically speaking, supporting so many different hashes is not very efficient. If an upstream uses weak hashes for released tarballs, just verify the weak hash on your local pc and then generate a strong hash yourself. Is there really a point having a week md5 and a strong sha256 hash at the same time?
On 10/08/2014 07:18 AM, Markos Chandras wrote: > I understand that, but realistically speaking, supporting so many > different hashes is not very efficient. If an upstream uses weak hashes > for released tarballs, just verify the weak hash on your local pc and > then generate a strong hash yourself. Is there really a point having a > week md5 and a strong sha256 hash at the same time? "strong" hashes are so for now, weak hashes were strong at the time too remember, they're, grossly said, glorified checksums/CRCs (which were also considered well enough until the data set and computation power grew). If you truly want to ensure a certain degree of tamper resistance you need to go to the 2-way collision. After all a single value of 256 or 512 bits representing a file of 1 MB of compressed data is bound to hit some issue eventually. With two different hashing methods it's statistically very complex to win the lottery. Regards.
On 10/08/2014 11:43 AM, Gustavo Zacarias wrote: > On 10/08/2014 07:18 AM, Markos Chandras wrote: >> I understand that, but realistically speaking, supporting so many >> different hashes is not very efficient. If an upstream uses weak hashes >> for released tarballs, just verify the weak hash on your local pc and >> then generate a strong hash yourself. Is there really a point having a >> week md5 and a strong sha256 hash at the same time? > > "strong" hashes are so for now, weak hashes were strong at the time too > remember, they're, grossly said, glorified checksums/CRCs (which were > also considered well enough until the data set and computation power grew). > If you truly want to ensure a certain degree of tamper resistance you > need to go to the 2-way collision. > After all a single value of 256 or 512 bits representing a file of 1 MB > of compressed data is bound to hit some issue eventually. > With two different hashing methods it's statistically very complex to > win the lottery. > Regards. > Sure. But this probably is not a strong argument because for all I know they may find sha256 broken tomorrow morning and you have to update all the buildroot packages using that hash to verify the tarball. If you think something is "not strong enough" then don't use it :) Perhaps it's best if buildroot supported the two strongest algorithms and request that information for every package? I really see no point supporting eg md5 since we know it's weak. Anyway, that's my personal opinion, I just feel there is no clear "rule" here so developers are free to use whatever they want which may not always be acceptable by the maintainers :)
On 10/08/2014 08:25 AM, Markos Chandras wrote: > Sure. But this probably is not a strong argument because for all I know > they may find sha256 broken tomorrow morning and you have to update all > the buildroot packages using that hash to verify the tarball. If you > think something is "not strong enough" then don't use it :) > Perhaps it's best if buildroot supported the two strongest algorithms > and request that information for every package? I really see no point > supporting eg md5 since we know it's weak. Anyway, that's my personal > opinion, I just feel there is no clear "rule" here so developers are > free to use whatever they want which may not always be acceptable by the > maintainers :) Those last lines ^^^ :) If upstream maintainers ship with md5 there's not much we can do about it. In the end we do hashes for integrity above everything else and we don't want to get in the way of new/bumped packages hence hashes aren't mandatory for now (it would be good to have them all though). Regards. PS: and to detect sucky upstream that switches tarballs without bumping versions to cover their lower heads.
Dear Vicente Olivert Riera, On Tue, 7 Oct 2014 15:30:50 +0100, Vicente Olivert Riera wrote: > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> > --- > package/ser2net/ser2net.hash | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > create mode 100644 package/ser2net/ser2net.hash > > diff --git a/package/ser2net/ser2net.hash b/package/ser2net/ser2net.hash > new file mode 100644 > index 0000000..d24e3a8 > --- /dev/null > +++ b/package/ser2net/ser2net.hash > @@ -0,0 +1,6 @@ > +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz > +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz > +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz > +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz > +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz > +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz Following the discussion, can you resend a patch that 1/ has a more reasonable number of hashes, and 2/ declares how the hash was found (locally computed, indicated on the upstream web site), etc. In the mean time, I'll mark your patch as 'Changes Requested' in patchwork. Thanks, Thomas
diff --git a/package/ser2net/ser2net.hash b/package/ser2net/ser2net.hash new file mode 100644 index 0000000..d24e3a8 --- /dev/null +++ b/package/ser2net/ser2net.hash @@ -0,0 +1,6 @@ +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> --- package/ser2net/ser2net.hash | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net.hash