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.
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
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)
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
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
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 . 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  https://wiki.gentoo.org/wiki/Project:PHP/Php-ext-source-r3_migration_guide signature.asc Description: OpenPGP digital signature
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.
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