Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Gordon Pettey
On Thu, Oct 19, 2017 at 5:32 PM, Hanno Böck  wrote:

> On Thu, 19 Oct 2017 21:08:40 +0200
> Michał Górny  wrote:
>
> >   manifest-hashes = SHA512 SHA3_512
>
> Counterproposal: Just use SHA512.
>
> There isn't any evidence that any SHA2-based hash algorithm is going to
> be broken any time soon. If that changes there will very likely be
> decades of warning before a break becomes practical.
>
> Having just one hash is simpler and using a well supported one like
> SHA512 may make things easier than using something that's still not
> very widely supported.


Yet having more than one lets you match make sure nobody hijacked your
manifest file when an attack vector is inevitably discovered for the old
new algorithm (whether SHA2, SHA3, or BLAKE2), because you'll be able to
confirm the file is the same one that matched the old checksum in addition
to the new one.


Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Hanno Böck
On Thu, 19 Oct 2017 21:08:40 +0200
Michał Górny  wrote:

>   manifest-hashes = SHA512 SHA3_512

Counterproposal: Just use SHA512.

There isn't any evidence that any SHA2-based hash algorithm is going to
be broken any time soon. If that changes there will very likely be
decades of warning before a break becomes practical.

Having just one hash is simpler and using a well supported one like
SHA512 may make things easier than using something that's still not
very widely supported.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Francesco Riosa
2017-10-19 23:00 GMT+02:00 Michał Górny :

> W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny
> napisał:
> >
> > 4. The new hashes that are stronger and commonly available are
> > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
> > our current algorithms, so either is a good candidate. The choice of
> > Keccak is purely arbitrary (because it's the winner?).
> >
>
> Actually, a small correction here: we support more implementations
> of SHA3 than BLAKE2, so the first one is less problematic for us.
>

Not researched in depth but:
B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while
sha-3 is deemed to be slower than sha-2, maybe this could be weighted while
choosing the algorithm wanted.

Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7
[cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1
[cpb] (see #2)

#0 cpb = cpu cycles per byte
#1 https://en.wikipedia.org/wiki/SHA-3#Speed
#2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html
* (in my limited experience)


Re: [gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Michał Górny
W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny
napisał:
> 
> 4. The new hashes that are stronger and commonly available are
> SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
> our current algorithms, so either is a good candidate. The choice of
> Keccak is purely arbitrary (because it's the winner?).
> 

Actually, a small correction here: we support more implementations
of SHA3 than BLAKE2, so the first one is less problematic for us.

-- 
Best regards,
Michał Górny




[gentoo-dev] Manifest2 hashes, take n+1-th

2017-10-19 Thread Michał Górny
Hi, everyone.

The previous discussion on Manifest2 hashes pretty much died away
pending fixes to Portage. Since Portage was fixed a while ago, and we
can now safely switch, I'd like to reboot the discussion before
submitting the item for the next Council meeting.

Considering all arguments made so far, I'd like to propose changing:

  manifest-hashes = SHA256 SHA512 WHIRLPOOL

to:

  manifest-hashes = SHA512 SHA3_512

In other words, removing SHA256 and WHIRLPOOL, and adding SHA3_512.


Rationale
-

1. The main argument for using multiple hashes is to prevent the (very
unlikely) possibility that if a weakness is discovered in one of
the hashes, the other would still hold. This is given by using two
algorithms; more than two do not increase security significantly, while
they do increase performance cost.

2. For the above to hold, the hashes should be diverse. SHA256
and SHA512 are the same algorithm, so a weakness discovered in either
would probably apply to both -- keeping both does not make sense at all.
Furthermore, both SHA2 and WHIRLPOOL use the same construct (MD), so
a weakness in the construct would apply to both.

3. Keeping one of the three old hashes is necessary for compatibility
reasons. Furthermore, the current versions of Portage consider SHA512
obligatory, so we can't remove it without redesigning Portage first
(though I think this applies only to developer installs, i.e. those
creating Manifests).

4. The new hashes that are stronger and commonly available are
SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
our current algorithms, so either is a good candidate. The choice of
Keccak is purely arbitrary (because it's the winner?).

All the above considered, I think it's most reasonable to use two hashes
with diverse constructs. SHA512 needs to be one of them, for
compatibility reasons. The other could be either SHA3_512 or BLAKE2B,
as a strong, future-proof hash. SHA3 is probably a better choice because
it's going to have more support as the official recommendation.

-- 
Best regards,
Michał Górny




[gentoo-dev] Last rites: php-ext-pecl-r2 eclass

2017-10-19 Thread Brian Evans
The php-ext-pecl-r2 eclass has no more consumers and is superseded by
php-ext-pecl-r3 eclass.

This eclass will be removed in 30 days.  Please update any overlays
still using this old eclass as the move to -r3 is rather trivial [1].

The php-ext-source-r2 eclass will follow once all consumers in the
Gentoo repository are updated and, potentially, marked stable.

Thank you,

Brian Evans

[1]
https://wiki.gentoo.org/wiki/Project:PHP/Php-ext-source-r3_migration_guide



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: net-analyzer/hexinject

2017-10-19 Thread Nils Freydank
Am Donnerstag, 19. Oktober 2017, 19:06:40 CEST schrieb Jonas Stein:
> Dear all,
> 
> The following packages are up for grabs:
> 
> net-analyzer/hexinject
> [...]

https://github.com/gentoo/gentoo/pull/5987
 
I’d take care of it. Works for me on gcc-6/hardened with the version bump.


-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Packages up for grabs: net-analyzer/hexinject

2017-10-19 Thread Jonas Stein
Dear all,

The following packages are up for grabs:

net-analyzer/hexinject

after retirement of the proxied maintainer.
In fact is was not maintained since years, because someone forgot to
remove the proxy-maint team as maintainer.

https://packages.gentoo.org/packages/net-analyzer/hexinject

Recently there was a new release upstream:
http://hexinject.sourceforge.net/

It would be nice, if you want to take care of this package.

-- 
Best,
Jonas























signature.asc
Description: OpenPGP digital signature