GNU bug report logs -
#57237
b2sum does not support '-a' options found at https://www.blake2.net/
Previous Next
To reply to this bug, email your comments to 57237 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#57237
; Package
coreutils
.
(Tue, 16 Aug 2022 03:41:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Robert E. Novak" <sailnfool <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Tue, 16 Aug 2022 03:41:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#57237
; Package
coreutils
.
(Tue, 16 Aug 2022 12:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57237 <at> debbugs.gnu.org (full text, mbox):
On 16/08/2022 04:15, Robert E. Novak wrote:
> 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
Discussion on the initial GNU coreutils implementation,
including dropping of the -a interface was discussed at:
https://lists.gnu.org/archive/html/coreutils/2016-10/msg00007.html
https://lists.gnu.org/archive/html/coreutils/2016-11/msg00000.html
We broached keeping coreutils simpler using just blake2b with blake2 folks,
and there was general agreement. So essentially there were design negotiations
in the threads above to present the interface appropriate to most users
in the GNU coreutils b2sum implementation,
which would become the standard variant available.
Which systems are installing the reference version?
I presume this is an infrequent issue?
I would think the onus on the above systems would be to install the reference
version under a different name.
Note the GNU coreutils digest tools were refactored recently
around a single `cksum -a ...` tool, and there will be no
new separate digest specific tools in future (like b3sum etc.).
thanks,
Pádraig
This bug report was last modified 2 years and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.