[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Vicente Olivert Riera]

Apply a patch sent upstream to fix a compilation failure present on some
architectures which do not define the TIOCSRS485 macro and do not
include the <asm-generic/ioctls.h> header. This is how the error looks
like:

devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this
function)

Patch sent upstream:
	https://sourceforge.net/p/ser2net/mailman/message/32905302/

Fixes:
	http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/
	http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/
	http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 ...2net-0001-Fix-TIOCSRS485-undeclared-error.patch |   65 ++++++++++++++++++++
 1 files changed, 65 insertions(+), 0 deletions(-)
 create mode 100644 package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch

diff --git a/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch b/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
new file mode 100644
index 0000000..9c6d168
--- /dev/null
+++ b/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
@@ -0,0 +1,65 @@
+ser2net: Fix compilation failures due to missing TIOCSRS485 macro
+
+Patch sent upstream:
+	https://sourceforge.net/p/ser2net/mailman/message/32905302/
+
+Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+
+From: Yegor Yefremov <yegorslists@googlemail.com>
+
+include <asm-generic/ioctls.h> fixes compilations for systems,
+where <asm-generic/ioctls.h> won't be included automatically.
+
+Move special Linux includes to dataxfer.h.
+
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+---
+ dataxfer.h | 5 +++--
+ devcfg.c   | 2 --
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/dataxfer.h b/dataxfer.h
+index bd2665e..c3d7431 100644
+--- a/dataxfer.h
++++ b/dataxfer.h
+@@ -20,8 +20,6 @@
+ #ifndef DATAXFER
+ #define DATAXFER
+ 
+-#include <linux/serial.h>
+-
+ #include "controller.h"
+ 
+ #ifdef USE_UUCP_LOCKING
+@@ -30,6 +28,9 @@ extern int uucp_locking_enabled;
+ 
+ #ifdef linux
+ 
++#include <linux/serial.h>
++#include <asm-generic/ioctls.h>
++
+ #define USE_RS485_FEATURE
+ 
+ /* Check, if the toolchain provides serial_rs485 structure and macros */
+diff --git a/devcfg.c b/devcfg.c
+index ab819a6..1f84714 100644
+--- a/devcfg.c
++++ b/devcfg.c
+@@ -18,7 +18,6 @@
+  */
+ 
+ /* This code handles generating the configuration for the serial port. */
+-
+ #include <unistd.h>
+ #include <termios.h>
+ #include <sys/ioctl.h>
+@@ -31,7 +30,6 @@
+ #include <signal.h>
+ #include <errno.h>
+ #include <syslog.h>
+-#include <linux/serial.h>
+ 
+ #include "ser2net.h"
+ #include "selector.h"
+-- 
+1.9.1
-- 
1.7.1

[Buildroot] [PATCH] ser2net: Add a hash file

[Vicente Olivert Riera]

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
-- 
1.7.1

[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Yegor Yefremov]

On Tue, Oct 7, 2014 at 4:30 PM, Vicente Olivert Riera
<Vincent.Riera@imgtec.com> wrote:
> Apply a patch sent upstream to fix a compilation failure present on some
> architectures which do not define the TIOCSRS485 macro and do not
> include the <asm-generic/ioctls.h> header. This is how the error looks
> like:
>
> devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this
> function)
>
> Patch sent upstream:
>         https://sourceforge.net/p/ser2net/mailman/message/32905302/
>
> Fixes:
>         http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/
>         http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/
>         http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/
>
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  ...2net-0001-Fix-TIOCSRS485-undeclared-error.patch |   65 ++++++++++++++++++++
>  1 files changed, 65 insertions(+), 0 deletions(-)
>  create mode 100644 package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
>
> diff --git a/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch b/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
> new file mode 100644
> index 0000000..9c6d168
> --- /dev/null
> +++ b/package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
> @@ -0,0 +1,65 @@
> +ser2net: Fix compilation failures due to missing TIOCSRS485 macro
> +
> +Patch sent upstream:
> +       https://sourceforge.net/p/ser2net/mailman/message/32905302/
> +
> +Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> +
> +From: Yegor Yefremov <yegorslists@googlemail.com>
> +
> +include <asm-generic/ioctls.h> fixes compilations for systems,
> +where <asm-generic/ioctls.h> won't be included automatically.
> +
> +Move special Linux includes to dataxfer.h.
> +
> +Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> +---
> + dataxfer.h | 5 +++--
> + devcfg.c   | 2 --
> + 2 files changed, 3 insertions(+), 4 deletions(-)
> +
> +diff --git a/dataxfer.h b/dataxfer.h
> +index bd2665e..c3d7431 100644
> +--- a/dataxfer.h
> ++++ b/dataxfer.h
> +@@ -20,8 +20,6 @@
> + #ifndef DATAXFER
> + #define DATAXFER
> +
> +-#include <linux/serial.h>
> +-
> + #include "controller.h"
> +
> + #ifdef USE_UUCP_LOCKING
> +@@ -30,6 +28,9 @@ extern int uucp_locking_enabled;
> +
> + #ifdef linux
> +
> ++#include <linux/serial.h>
> ++#include <asm-generic/ioctls.h>
> ++
> + #define USE_RS485_FEATURE
> +
> + /* Check, if the toolchain provides serial_rs485 structure and macros */
> +diff --git a/devcfg.c b/devcfg.c
> +index ab819a6..1f84714 100644
> +--- a/devcfg.c
> ++++ b/devcfg.c
> +@@ -18,7 +18,6 @@
> +  */
> +
> + /* This code handles generating the configuration for the serial port. */
> +-
> + #include <unistd.h>
> + #include <termios.h>
> + #include <sys/ioctl.h>
> +@@ -31,7 +30,6 @@
> + #include <signal.h>
> + #include <errno.h>
> + #include <syslog.h>
> +-#include <linux/serial.h>
> +
> + #include "ser2net.h"
> + #include "selector.h"
> +--
> +1.9.1
> --
> 1.7.1

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

[Buildroot] [PATCH] ser2net: Add a hash file

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Thomas Petazzoni]

Dear Yegor Yefremov,

On Tue, 7 Oct 2014 16:33:09 +0200, Yegor Yefremov wrote:

> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

If you actually agree with the patch, or tested it, or have reviewed
it, you should give a Tested-by, Acked-by or Reviewed-by, not a
Signed-off-by. Please see
http://buildroot.org/downloads/manual/manual.html#_reviewing_and_testing_patches.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Yegor Yefremov]

On Tue, Oct 7, 2014 at 7:28 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Yegor Yefremov,
>
> On Tue, 7 Oct 2014 16:33:09 +0200, Yegor Yefremov wrote:
>
>> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
>
> If you actually agree with the patch, or tested it, or have reviewed
> it, you should give a Tested-by, Acked-by or Reviewed-by, not a
> Signed-off-by. Please see
> http://buildroot.org/downloads/manual/manual.html#_reviewing_and_testing_patches.

Then I'll choose

Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>

I was actually the author of the upstream ser2net patch, that's why I
thought SoB would be OK :-)

Yegor

[Buildroot] [PATCH] ser2net: Fix compilation failures due to missing TIOCSRS485 macro

[Peter Korsgaard]

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 > Apply a patch sent upstream to fix a compilation failure present on some
 > architectures which do not define the TIOCSRS485 macro and do not
 > include the <asm-generic/ioctls.h> header. This is how the error looks
 > like:

 > devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this
 > function)

 > Patch sent upstream:
 > 	https://sourceforge.net/p/ser2net/mailman/message/32905302/

 > Fixes:
 > 	http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/
 > 	http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/
 > 	http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/

 > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] ser2net: Add a hash file

[Vicente Olivert Riera]

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?

-- 
Vincent

[Buildroot] [PATCH] ser2net: Add a hash file

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] ser2net: Add a hash file

[Vicente Olivert Riera]

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
>


-- 
Vincent

[Buildroot] [PATCH] ser2net: Add a hash file

[Markos Chandras]

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?

-- 
markos

[Buildroot] [PATCH] ser2net: Add a hash file

[Vicente Olivert Riera]

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.

-- 
Vincent

[Buildroot] [PATCH] ser2net: Add a hash file

[Peter Korsgaard]

>>>>> "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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] ser2net: Add a hash file

[Gustavo Zacarias]

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.

[Buildroot] [PATCH] ser2net: Add a hash file

[Markos Chandras]

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?

-- 
markos

[Buildroot] [PATCH] ser2net: Add a hash file

[Gustavo Zacarias]

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.

[Buildroot] [PATCH] ser2net: Add a hash file

[Markos Chandras]

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 :)

-- 
markos

[Buildroot] [PATCH] ser2net: Add a hash file

[Gustavo Zacarias]

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.

[Buildroot] [PATCH] ser2net: Add a hash file

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com