help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: urandom number in Emacs


From: Omar Polo
Subject: Re: urandom number in Emacs
Date: Sun, 07 Nov 2021 09:53:42 +0100
User-agent: mu4e 1.6.9; emacs 29.0.50

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Omar Polo wrote:
>
>> I mean, if you really need something like that and emacs
>> doesn't already provide it, why don't try cooking a diff to
>> add it to base emacs instead that an external module?
>
> `random' isn't good enough for passwords, it could since it is
> a C built-in read from /dev/urandom but it doesn't, and you
> can't do that from Lisp since /dev/urandom is a non-regular
> file. head(1) and pwgen(1) can do it from C and so can Emacs,
> but to have it as a Lisp primitive or a DM ... but isn't that
> why you have DMs, you shouldn't have to recompile the whole
> thing to get it? It is more ... modular?

Recompiling Emacs from sources takes a couple of minutes, and it's a
trivial function that you can write and test apart before including it
to Emacs.  Also, I'm pretty sure that no distribution ships *by default*
Emacs modules.

Furthermore, it's an annoyance for the users: if I want to use it, I
have to compile it anyway, whether if it's an emacs built-in all I have
to do is install/update Emacs via my package manager and I'm happy ;-)

>> Also, the code is wrong:
>
>>>  if (nbytes == 0) {
>>>    return (rnd_num % max_num);
>>>  } else {
>>>    fprintf(stderr, "No entropy available!\n");
>>>    exit(1);
>>>  }
>>
>> I don't think you want to quit emacs unconditionally if
>> there's no entropy.
>
> OK ... I'll just return something to denote it didn't work.
> Hm ...

you could rewrite the function to return the value via a pointer, e.g.

int
get_random_number(uint32_t *n)
{
        /* do stuff */
        if (succeeded) {
                *n = the random number;
                return 0;
        }
        return -1;
}

/* later */

uint32_t n;
if (get_random_number(&n) == -1) {
        /* Ooops */
}

>> Also, in some circumstances there could be better (and
>> faster) ways to obtain a random number, see for
>> e.g. arc4random.
>
> Doesn't that read from /dev/urandom as well?
> What's better/faster about it? You need a DM/recompile for
> that as well since it is in libc, or am I wrong?

arc4random uses a per-process random stream that sometimes gets
re-initialized from /dev/urandom.  This means that most of the time you
have access to a good RNG without having to make a system call.

> Nah, if it was good enough for pwgen(1) I take it ...

You should also consider why that was good for pwgen.  If something is
good for program A, it may not be "good enough" for program B.  I don't
know pwgen, but given that's in the first section of the manual is
probably a program that generates a password, print it to stdout and
quits.  It doesn't have bottlenecks.

A program like Emacs on the other hand needs to call that function
possibly multiple times, so investigating a bit for a faster way to
obtain good random number is worth it IMHO.

>> P.S.: are you sure about checking for EAGAIN? A read for
>> a file descriptor not marked as non-blocking shouldn't fail
>> with EAGAIN
>
> I am not sure, again they had it in pwgen ...
>
>> but that's a minor nitpick.
>
> Indeed ... hehe



reply via email to

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