bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57237: b2sum does not support '-a' options found at https://www.blak


From: Robert E. Novak
Subject: bug#57237: b2sum does not support '-a' options found at https://www.blake2.net/
Date: Mon, 15 Aug 2022 20:15:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

as a result, the Gnu version does not support blake2s (for smaller digests) and blakes2bp for higher performance on multicore systems.

Yes, I know about Blake3, but there are many reasons to support older hash algorithms.

The real problem is that you have co-opted the b2sum binary so that the testing required to find out if is system's b2sum application is the open source b2sum from https://www.blake2.net/ or the Gnu coreutils.  I am hopeful that a similar problem is not introduced with a coreutils version of b3sum?  Will you implement the C language single thread version (lower performance) or the parallel merkle tree rust implementation?

Since you introduce incompatible differences in the implementation, the least that you could do is to rename the Gnu Coreutils b2sum to gnub2sum so that applications that require different command line semantics do NOT Have to go through machinations to find all installed versions of b2sum on a system in order to select the correct invocation semantics.  Just my $0.02 worth, but I am trying to rationalize the world of cryptographic hash algorithms.  I have two blogs that reference this on linkedin ( * & ** ) so that you can understand part of the reason why this will become more important over time.

I realize that Gnu has a long tradition of implementing the Gnu version of commands and that in many cases the Gnu versions have become the "de facto" standards.  However this does not happen if you don't support the semantics of the commands that you are replacing.

I have been using Unix/Linux since 1974 (Arpanet node #6 at Urbana, Illinois) and I would never have made the transition to Linux if there were less semantic consistency over time.

If indeed you had implemented a superset of the Blake2 semantics, there would be no cause for concern.

* https://www.linkedin.com/pulse/canonical-cryptographic-hash-encoding-robert-e-novak/?trackingId=gjy%2FJwsjnJaviUN2ZYtuqw%3D%3D

This is a preliminary version and I hope to release a second version after further development.

** https://www.linkedin.com/pulse/thoughts-pragmatic-one-time-pads-encryption-robert-e-novak/?trackingId=3AUdLAGWSsDMYYuCINZuVA%3D%3D






reply via email to

[Prev in Thread] Current Thread [Next in Thread]