On 27/12/16 19:48, Eric Blake wrote:
> On 12/26/2016 02:04 PM, Zooko Wilcoz wrote:
>> Way to go! I'm really glad this is in here now and people can use it.
>>
>> Pull-request: https://github.com/coreutils/coreutils/pull/8
>
> On this list, we prefer that you mail your patches to the list, rather
On 12/26/2016 02:04 PM, Zooko Wilcoz wrote:
> Way to go! I'm really glad this is in here now and people can use it.
>
> Pull-request: https://github.com/coreutils/coreutils/pull/8
On this list, we prefer that you mail your patches to the list, rather
than making us chase down a URL to a cloned
Way to go! I'm really glad this is in here now and people can use it.
Pull-request: https://github.com/coreutils/coreutils/pull/8
Regards,
Zooko
On Mon, Nov 14, 2016 at 6:10 PM, Mike Frysinger wrote:
> On 29 Oct 2016 19:37, Pádraig Brady wrote:
>> On 09/10/16 21:28, Mike
On 29 Oct 2016 19:37, Pádraig Brady wrote:
> On 09/10/16 21:28, Mike Hodson wrote:
> > At the risk of going somewhat offtopic of this list, however, as this
> > is the one point of continual reference I have to the Blake2 hash in
> > common use (I am always interested in learning the new features
A simplified variant is now available at:
https://github.com/pixelb/coreutils/compare/blake2b
https://github.com/pixelb/coreutils/compare/blake2b.patch
That as the name suggests removes the --algorithm option
and just supports the BLAKE2b digest algorithm.
I also changed to auto determining the
On 11/01/2016 10:35 AM, Pádraig Brady wrote:
In your testing below showing that the blake2bp digest is
dependent on OMP_DYNAMIC env variable, that's just wrong,
whether it's a bug in the implementation or assumptions,
it's a bug.
I suspect it's a wrong assumption about the implementation.
The
On Mon, Oct 31, 2016 at 10:18:55PM -0400, Assaf Gordon wrote:
If by "equivalent" you mean just "happens to be the same length of digest but
different value",
then I fear many non-tech-savvy users would not be aware of this distinction.
+1. This seems horribly user-unfriendly.
With sha3 and
On 11/01/2016 03:35 PM, Pádraig Brady wrote:
> Yes I didn't like the thread hardcoding at all, and was going to analyze
> before release.
> Zooko/Samuel, is the digest value dependent on number of threads?
> Did parallelism efficiency fall off after 4?
BLAKE2{sp, bp} have respectively 8 and 4
CC'ing blake2 folks probably offlist.
Response below...
On 01/11/16 02:18, Assaf Gordon wrote:
> Hello Pádraig and all,
>
> I have some concerns about supporting different algorithm in b2sum.
> [long email ahead...]
>
> First, usability of multiple algorithms.
>
> From a usability POV, it
Hello Pádraig and all,
I have some concerns about supporting different algorithm in b2sum.
[long email ahead...]
First, usability of multiple algorithms.
From a usability POV, it is rarely (never?) the case that making a program
multithreaded or parallel, or optimizing for different CPU
On 31/10/16 22:41, Assaf Gordon wrote:
> Hello Pádraig and all,
>
> On 10/31/2016 03:52 PM, Pádraig Brady wrote:
>> Patch above updated.
>> Also I improved the test a bit.
>
> Thanks for the quick fix. I was able to check it on few system. Seems like
> non-gnu systems have some issues.
> All
Hello Pádraig and all,
On 10/31/2016 03:52 PM, Pádraig Brady wrote:
Patch above updated.
Also I improved the test a bit.
Thanks for the quick fix. I was able to check it on few system. Seems like
non-gnu systems have some issues.
All errors except Mac OS X (last in the list below) seems due
On 31/10/16 19:39, Assaf Gordon wrote:
> Hello Pádraig,
>
> On 10/31/2016 01:44 PM, Pádraig Brady wrote:
>> This preliminary patch passes tests and syntax checks:
>> https://github.com/pixelb/coreutils/compare/blake2
>
> from a cursory check, it seems at least "./src/blake2/b2sum.h" is not
>
Hello Pádraig,
On 10/31/2016 01:44 PM, Pádraig Brady wrote:
This preliminary patch passes tests and syntax checks:
https://github.com/pixelb/coreutils/compare/blake2
from a cursory check, it seems at least "./src/blake2/b2sum.h" is not included in
"makefile.am",
then is missing from "make
On 31/10/16 04:05, Pádraig Brady wrote:
> I've got this fairly well integrated with coreutils,
> and will present a patch perhaps tomorrow.
This preliminary patch passes tests and syntax checks:
https://github.com/pixelb/coreutils/compare/blake2
I hope to push this before the impending v8.26
Hi,
This is indeed a bug, but I'm not too fond of that fix, as it slightly alters
the semantics of the final() function. `outlen` goes from being the size of the
output buffer---which may be larger than the hash size---to being exactly, and
prescriptively, the hash output size.
The bug's root
I've got this fairly well integrated with coreutils,
and will present a patch perhaps tomorrow.
In testing I hit a bug in the reference implementation,
where I was getting random values for:
b2sum -a blake2bp -l8 /dev/null
I've fixed that up locally with this patch:
On 09/10/16 21:28, Mike Hodson wrote:
> Hello folks,
>
> At the risk of going somewhat offtopic of this list, however, as this
> is the one point of continual reference I have to the Blake2 hash in
> common use (I am always interested in learning the new features of
> Coreutils and have been a
Looking at the current implementation in openssl,
only the EVP interface is available, which is not currently
wrapped by gnulib, nor used by coreutils. Also even though
there is an SSE implementation available, this is not
available in openssl. Therefore we'll probably have to
skip openssl usage
On 09/10/16 05:59, Zooko Wilcox-OHearn wrote:
> Hello, folks!
>
> It's been about a year since the last update in this thread. I was
> reminded of it because I saw a well-intentioned project using "md5sum"
> to let its users identify a specific distribution of its software. Of
> course, md5sum is
Hello, folks!
It's been about a year since the last update in this thread. I was
reminded of it because I saw a well-intentioned project using "md5sum"
to let its users identify a specific distribution of its software. Of
course, md5sum is not secure for that!
Since md5sum is vulnerable to
Folks:
Earlier in this discussion Pádraig Brady asked ¹ if we had submitted
BLAKE2 for inclusion in openssl. We have ², but they haven't yet
included it ³.
Eventually, I think, openssl will support highly optimized
implementations of BLAKE2, but I think it will be a long time before
that is
On 11/10/15 17:59, Zooko Wilcox-OHearn wrote:
> Folks:
>
> Earlier in this discussion Pádraig Brady asked ¹ if we had submitted
> BLAKE2 for inclusion in openssl. We have ², but they haven't yet
> included it ³.
>
> Eventually, I think, openssl will support highly optimized
> implementations of
Dear coreutils hackers:
I think we should protect users by offering a replacement for md5sum.
md5sum is dangerous to users, because it is collision-resistant
whenever the data being processed is free of malicious input, but it
is vulnerable to collisions (and other weirder patterns) if the data
On 08/06/15 21:08, Taylor R Campbell wrote:
Date: Wed, 27 May 2015 17:59:10 +
From: Zooko Wilcox-OHearn zo...@leastauthority.com
Dear coreutils folks and RMS:
I'm writing to ask you to add the BLAKE2 hash function to coreutils.
Zooko asked me to send the following
Date: Wed, 27 May 2015 17:59:10 +
From: Zooko Wilcox-OHearn zo...@leastauthority.com
Dear coreutils folks and RMS:
I'm writing to ask you to add the BLAKE2 hash function to coreutils.
Zooko asked me to send the following timings of portable BLAKE2 C code
versus the
On 08/06/15 22:17, Taylor R Campbell wrote:
Date: Mon, 08 Jun 2015 21:24:30 +0100
From: Padraig Brady p...@draigbrady.com
On 08/06/15 21:08, Taylor R Campbell wrote:
Zooko asked me to send the following timings of portable BLAKE2 C code
versus the hand-optimized assembly
Date: Mon, 08 Jun 2015 21:24:30 +0100
From: Padraig Brady p...@draigbrady.com
On 08/06/15 21:08, Taylor R Campbell wrote:
Zooko asked me to send the following timings of portable BLAKE2 C code
versus the hand-optimized assembly for MD5 and portable C for SHA-256
that one
Thanks for the suggestion, Pádraig. I'll submit a feature request to openssl.
I think the name of the command is actually important:
My goal here is to make md5sum extinct, because it is unsafe. That's
why we made BLAKE2 to be faster than MD5, because we figured that we'd
never managed to
On 06/05/2015 10:06 AM, Zooko Wilcox-OHearn wrote:
Thanks for the suggestion, Pádraig. I'll submit a feature request to openssl.
I think the name of the command is actually important:
My goal here is to make md5sum extinct, because it is unsafe. That's
why we made BLAKE2 to be faster than
Dear coreutils folks:
Here's the feature-request for OpenSSL:
http://www.mail-archive.com/openssl-dev@openssl.org/msg39161.html
Regards,
Zooko
Dear Eric Blake:
Yes, that would be fine for my goal of killing md5sum, as long as all
of the distros spell b2sum the same way!
Regards,
Zooko
On 03/06/15 22:36, Zooko Wilcox-OHearn wrote:
Great! So the licensing is settled. Now what's the next step?
We'll have a look at including it in the coreutils release
after the imminent one (a few weeks time), along with the
sha3 implementation.
I'm leaning towards no new commands, and instead
Great! So the licensing is settled. Now what's the next step?
Regards,
Zooko
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
forget licensing ... GNU/coreutils requires copyright assignment doesn't it
?
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Creative Commons Legal Code
CC0 1.0 Universal
I think we can't
On 05/29/2015 01:22 PM, Richard Stallman wrote:
Creative Commons Legal Code
CC0 1.0 Universal
I think we can't integrate it as-is into GNU coreutils (which requires
GPLv3+), can we?
I think we can. Can you send me a cpy of the legal text of CC0?
The following is the
On 05/28/2015 05:05 PM, Mike Frysinger wrote:
On 28 May 2015 16:46, Bernhard Voelker wrote:
According to the COPYING file, the code currently is licensed under
the Creative Commons license:
Creative Commons Legal Code
CC0 1.0 Universal
I think we can't integrate it as-is into GNU
On 27/05/15 18:59, Zooko Wilcox-OHearn wrote:
Dear coreutils folks and RMS:
I'm writing to ask you to add the BLAKE2 hash function to coreutils.
The reason is that md5sum is the most widely-used tool for file
integrity, but it has flaws that could lead to users being exploited
if they use
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
The idea seems good to me, in principle.
--
Dr Richard Stallman
President, Free
On 05/27/2015 07:59 PM, Zooko Wilcox-OHearn wrote:
In sum, by adding b2sum to coreutils, we can help users protect
themselves from attackers, and also have a more efficient tool for
file integrity. You can get the source code here:
https://blake2.net/#dl
Technically +1.
According to the
On 28 May 2015 16:46, Bernhard Voelker wrote:
On 05/27/2015 07:59 PM, Zooko Wilcox-OHearn wrote:
In sum, by adding b2sum to coreutils, we can help users protect
themselves from attackers, and also have a more efficient tool for
file integrity. You can get the source code here:
Dear coreutils folks and RMS:
I'm writing to ask you to add the BLAKE2 hash function to coreutils.
The reason is that md5sum is the most widely-used tool for file
integrity, but it has flaws that could lead to users being exploited
if they use md5sum in certain reasonable-sounding ways. (I refer
43 matches
Mail list logo