A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1134 ====================================================================== Reported By: nmav Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1134 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Nikos Mavrogiannopoulos Organization: Red Hat User Reference: Section: getentropy Page Number: 0 Line Number: 0 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2017-03-31 07:06 UTC Last Modified: 2017-04-07 18:54 UTC ====================================================================== Summary: Add getentropy interface ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000859 Add posix_random family of interfaces ======================================================================
---------------------------------------------------------------------- (0003668) steffen (reporter) - 2017-04-07 18:54 http://austingroupbugs.net/view.php?id=1134#c3668 ---------------------------------------------------------------------- I totally and completely disagree with #3667. Anyone can place mediocre high-level pseudo random code on top of a good low-level interface. I think it gets increasingly impossible to create something good on a mediocre or non-existing low-level entropy source interface. I for one adore POSIX because of the low-level interface that (would) allow(ed) me to use -nostdinc (and not to forget -fno-exceptions -fno-rtti). Except for getdirentries() almost anything one needs is available to create truly portable applications like so, which i think cannot be rated high enough! This is true even if vendors seem to favor more and more to put money into the Linux kernel than in their own complete distributions, in order to effectively safe money on the research side -- this is nothing but a degenerative motion towards a monoculture, and in real-life monocultures cannot survive. (In fact "safe even more money", if one looks at the manuals of some commercial vendors, which never got enough time nor love.) I regret that we don't get a high-level interface in addition, i.e., that the corresponding issue has been closed: because like this vendors could exchange algorithms as the necessities arise, and could provide optimised variants. And because errors would be encapsulated in the good maintained C library, rather than shipped in uncountable packages which implement their own / have a copy of some pseudo-random generator because they need the functionality. But it should be in addition, because in practice many tasks require good random entropy and systems do provide it since decades: /dev/u?random on Linux and FreeBSD, /dev/arandom on OpenBSD, increasingly often sysctl(2)s or direct system calls which provide the same data but without requiring a file-descriptor. It would be logical to lift this to a standardized level, in my opinion. Issue History Date Modified Username Field Change ====================================================================== 2017-03-31 07:06 nmav New Issue 2017-03-31 07:06 nmav Name => Nikos Mavrogiannopoulos 2017-03-31 07:06 nmav Organization => Red Hat 2017-03-31 07:06 nmav Section => getentropy 2017-03-31 07:06 nmav Page Number => 0 2017-03-31 07:06 nmav Line Number => 0 2017-03-31 07:17 Don Cragun Relationship added related to 0000859 2017-04-01 06:25 EdSchouten Note Added: 0003657 2017-04-06 09:46 nmav Note Added: 0003660 2017-04-06 20:00 shware_systems Note Added: 0003662 2017-04-07 08:47 nmav Note Added: 0003663 2017-04-07 10:35 schwarze Note Added: 0003664 2017-04-07 17:32 EdSchouten Note Added: 0003667 2017-04-07 18:54 steffen Note Added: 0003668 ======================================================================
