[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