Re: CVS commit: src

[nia <nia%NetBSD.org@localhost>]

On Sat, Aug 15, 2020 at 06:49:11PM +0000, Taylor R Campbell wrote:
> - The behaviour is incompatible only in the sense that NetBSD's idea
>   of `adequate entropy' is stronger than FreeBSD's or Linux's, so
>   blocking is _more likely_ on NetBSD than on FreeBSD or Linux.

In practice, the blocking being more harsh is surprising to the typical
user. Other operating systems simply don't agree with NetBSD's unblocking
criteria. As an application author, I'd consider the difference between 
unblocking automatically after recieving some idle network packages and
only unblocking with user intervention to be an API difference.

> If FreeBSD makes _more_ promises, fine, but the GRND_RANDOM flag a
> silly API that exists only for Linux source compatibility that very
> few reasonable applications use.  So I don't see why it's important to
> put any attention on it or make any stronger promises about it than
> portable applications can rely on -- that's why, e.g., the man page I
> wrote specifically calls it out as silly, not recommended, for Linux
> source compatibility only, and with no usage examples.

Why does there need to be a specific code path for handling something
that's "silly, not recommended", and not even standardized? If something's
there, then someone with inevitably end up using it at some point. 

Keep the define, just make it do nothing.

If it's not supposed to be used, how will it be tested? Just remove
it and reduce potential for harm.

> The Rust API specifically describes getrandom(p,n,0) semantics:
> 
> https://docs.rs/rand/0.7.3/rand/rngs/struct.OsRng.html
> 
>   `It is possible that when used during early boot the first call to
>    OsRng will block until the system's RNG is initialised. It is also
>    possible (though highly unlikely) for OsRng to fail on some
>    platforms, most likely due to system mis-configuration.

Key word here being "possible". It's entirely valid for us to decide
that any entropy consolidated before userland is "good enough",
and initialize with that. We don't need to implement a Linux system call
just because Rust documentation provides a vague hint that an OS _may_
implement that specific Linux syscall's semantics.

> Obviously we can patch OpenSSL in base however we like, but at least
> one OpenSSL developer reported being uncomfortable with having
> getrandom(p,n,GNRD_INSECURE) semantics for getentropy if used
> upstream:
> 
> https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012334.html
> 
>   `If you make getentropy the insecure version, I will need to modify
>    OpenSSL to switch to getrandom() on NetBSD.'

We then had a long discussion about entropy (which is arguably not
on-topic). But, key point: I'm not sure why he considers OpenBSD's
implementation to be safe without blocking and NetBSD's to be unsafe. 
Marketing, I suspect. In practice, OpenSSL uses entirely non-blocking
APIs on both.