From: Omar Polo <op@omarpolo.com>
To: Emanuel Berg <moasenwood@zoho.eu>
Cc: help-gnu-emacs@gnu.org, emacs-devel@gnu.org
Subject: Re: urandom number in Emacs
Date: Sun, 07 Nov 2021 09:53:42 +0100 [thread overview]
Message-ID: <87czncs5f1.fsf@omarpolo.com> (raw)
In-Reply-To: <87czncmju0.fsf@zoho.eu>
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
next prev parent reply other threads:[~2021-11-07 8:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-06 16:35 urandom number in Emacs Emanuel Berg via Emacs development discussions.
2021-11-07 0:13 ` Emanuel Berg via Emacs development discussions.
2021-11-07 8:22 ` Omar Polo
2021-11-07 8:49 ` Emanuel Berg via Emacs development discussions.
2021-11-07 8:53 ` Omar Polo [this message]
2021-11-07 9:28 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-11-07 8:58 ` Emanuel Berg via Emacs development discussions.
2021-11-07 19:47 ` Emanuel Berg via Emacs development discussions.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czncs5f1.fsf@omarpolo.com \
--to=op@omarpolo.com \
--cc=emacs-devel@gnu.org \
--cc=help-gnu-emacs@gnu.org \
--cc=moasenwood@zoho.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).