Thanks, I installed that into Gnulib master on savannah via the attached.
>From 1770bc4660a40265d6b9ee111f52e7c4c7ebb4c2 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 1 Jun 2020 17:57:27 -0700
Subject: [PATCH] getloadavg: fix double-increment bug
* lib/getloadavg.c (getloadavg): Fix doubl
On 6/1/20 4:51 PM, Bruno Haible wrote:
>> I could add text along
>> these lines if this sounds like a good idea.
>
> Yes, that would sound good.
Done via the attached patch.
>From af3ff63e457ddb6ba29295e3d5b78a93d834cb8e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 1 Jun 2020 17:02:54
Hi Paul,
> > No guidance regarding getrandom vs. crypto/gc-random any more?
>
> The main advantage of getrandom and/or getentropy over crypto/gc-random is the
> simpler API and lower maintenance/runtime overhead. crypto/gc-random is a
> better
> match if you're already using the other crypto/* A
On 6/1/20 12:01 PM, Bruno Haible wrote:
> No guidance regarding getrandom vs. crypto/gc-random any more?
The main advantage of getrandom and/or getentropy over crypto/gc-random is the
simpler API and lower maintenance/runtime overhead. crypto/gc-random is a better
match if you're already using the
The support for the three multithreading APIs is complete in Gnulib since
2020-01-19, except for the documentation. Let me now document it.
2020-06-01 Bruno Haible
doc: New chapter 'Multithreading'.
* doc/multithread.texi: New file.
* doc/gnulib.texi: Include it.
>Fro
---
doc/glibc-functions/getentropy.texi | 2 +-
doc/glibc-functions/getrandom.texi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/glibc-functions/getentropy.texi
b/doc/glibc-functions/getentropy.texi
index c9884ad24..2f66ada63 100644
--- a/doc/glibc-functions/getentro
I did some small doc restructuring: moving two sections to chapters where
IMO they fit better. (That's always debatable, though.)
2020-06-01 Bruno Haible
doc: Move 'Running self-tests under valgrind' section.
* doc/gnulib.texi (Build Infrastructure Modules): Include
va
Hello,
I have discovered some typographical errors in some licenses in Texinfo
format. There are some '.'s that end sentences but follow capital
letters. These must be changed to '@.'. See also here¹.
Note: Paul Eggert suggests here² that I should write to g...@gnu.org for
this issue, so that is
Hi Paul,
> I installed the attached patch to the Gnulib doc, which attempts to address
> this
> along with the GRND_INSECURE business.
No guidance regarding getrandom vs. crypto/gc-random any more?
We have two modules, 'getrandom' and 'crypto/gc-random' (in fact 3, if you also
count 'getentropy
getloadavg function increases elem counter twice:
for (elem = 0; elem < nelem; elem++) // Here
{
// ...
loadavg[elem++] = numerator / denominator; // And here
}
It leads to wrong Load Average in uptime command:
$ cat /proc/loadavg
0.01 0.02 0.00 1/122 992
$ uptime
18:36:59
>> Also, it looks like (to me) getrandom may suffer VM rollback attacks.
>> So claiming a stream is high quality may be questionable if a reboot
>> produces the same stream.
> On which systems does getrandom() have this problem?
In theory, it could be any system. Even a hardware random-number gene
On 6/1/20 11:00 AM, Bruno Haible wrote:
>> Also, there were some '.'s that should be changed to '@.' in the license
>> Texinfo files.
> I don't know whom to contact to change these.
I'd write g...@gnu.org.
Asher Gordon wrote on 2020-05-17:
> >> I also fixed a minor issue where "VCS" ended with
> >> "." rather than "@." (see (texinfo) Ending a Sentence).
> >
> > I won't spend time on a single instance of this very minor issue. But if
> > you want to submit a patch that fixes all instances of this issu
Hi Jeffrey,
I'm trying to state in simple-to-understand words what Simon said
about getrandom(), getentropy(), and libgcrypt.
If you have a better wording, please submit a patch.
> Nowadays it may be prudent to simply state the data returned from the
> prng should be treated as a seed and not us
On Sun, May 31, 2020 at 3:02 PM Bruno Haible wrote:
>
> Hi Simon,
>
> Thanks for your insights.
>
> > Historically, the problem is that for cryptographic purposes,
> > /dev/random and /dev/urandom can be a really bad choice on many
> > platforms. This has probably been improved over the years, es
15 matches
Mail list logo
