Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.
Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.
While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].
Related post: OneRNG: a Fully-Open Entropy Generator (2014)
Related Stories
The OneRNG is an Open Hardware, Open Source, simple and verifiable USB-connected source of entropy; we do not ask you to "trust" us, we give you the ability to verify for yourself that the OneRNG does what we claim, and that it does nothing else.
OneRNG collects entropy from an avalanche diode circuit, and from a channel-hopping RF receiver. It even has a “tinfoil hat” to prevent RF interference — you can remove the hat in order to visually verify the components being used.
You rely on a high-quality source of random numbers to maintain your privacy and security in computer communication; but computers have too few sources of truly random data for the demands we place upon them. Increasingly we have been distrusting the solutions given to us by others, as they are shown to be weak in so many ways - because of faults in implementation, in design, or due to subversion by attackers who simply do not care about the consequences of their actions (I'm looking at you, NSA).
In general usage, we recommend that you use the OneRNG as an entropy source for your operating system's own RNG software; this allows you to consume extremely large quantities of random data without either blocking or reducing the quality of the data.
http://onerng.info
[Additional Info]:
http://moonbaseotago.com/onerng/
http://www.theregister.co.uk/2014/11/17/meet_onerng_a_fullyopen_entropy_generator_for_a_paranoid_age/
(Score: 0) by Anonymous Coward on Friday December 21 2018, @07:09PM (14 children)
And then it started making money for corporations.
It's been shit ever since.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @07:17PM (2 children)
still untainted by corp influence
(Score: 0) by Anonymous Coward on Friday December 21 2018, @07:25PM (1 child)
That thing is a well-polished turd.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @09:07PM
Proved he didn't know shit.
The complaint about the driver with the default enable option? They have been doing that since 3.0 or 2.6 something, at least. Plus nobody has been bothering with arch-specific filters, even on things like ARM-specific FPGA glue, causing SPARC, Alpha, S390, and even i686 arches to have loads of crap that are irrelevant to them, as well as dozens to hundreds of default-enabled drivers.
As stated in PP, the linux kernel has been on the road to a not so well polished turd for a while. I personally peg it at 2.6.9 when they broke API compatibility without using a new kernel major or minor version, instead breaking it twice more in the .1x and .2x series (I don't remember the specific versions, maybe someone with historical digging skills can figure it out.)
Point being, Linux has lost its way. The downside being nothing else once had the broad compatibility driver and protocol-wise, and now even Linux is taking that away.
(Score: 3, Insightful) by TheGratefulNet on Saturday December 22 2018, @12:52AM (10 children)
when I want a static IP, I want it even if the link goes down and back up again.
linux broke that very simple concept. NetworkManager is a piece of crap and even disabling it does not get you to full static files.
I hate that linux is now the playground of too-young-to-know-better kids. perhaps BSD is the place to be, again. it was once, and now that linux is basically ruined, its time to think about bsd again.
I'm working on an embedded system at work and the idiots chose a systemd distro and that's been no end of trouble. dammit.
"It is now safe to switch off your computer."
(Score: 3, Informative) by tibman on Saturday December 22 2018, @05:10AM (9 children)
Not all linux distros use systemd.
SN won't survive on lurkers alone. Write comments.
(Score: 1, Insightful) by Anonymous Coward on Saturday December 22 2018, @06:15AM (7 children)
No, but some of us still choose to use NetworkManager with OpenRC. There aren't a lot of good options for wifi configuration from a gui, "easy like it is in windows".
I agree NetworkManager is a tower of kludges and could be a lot better, but trying to set up multiple wifi configurations without editing wpa_supplicant.conf directly can get really fucking complicated and frankly a pita that nm alleviates.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @01:14PM (6 children)
What's so hard about wpa_passphrase XXX xxx >> /etc/wpa_supplicant.conf? The shit just works and it's not complicated at all. Do you have trouble reading man pages or something? I have 5 networks in my wpa_supplicant.conf, and I did absolutely 0 manually editing and it just works. The only thing I edited was my init script to give me a notify-send notification when the network connects or disconnects.
(Score: 2) by bzipitidoo on Saturday December 22 2018, @02:50PM (5 children)
Throw anything just a little complicated at the typical Linux distro's wifi, and it flops. Lately, I've been using PCLinuxOS on my laptop, in large part because it does not have systemd, and I'm not impressed. Had similar problems with Lubuntu.
Connect to free wifi at business X, go to business Y and connect to their free wifi, then go back to business X. It should reconnect to X's wifi, but it often won't. It'll try, and fail. The easy way to deal with that one is reboot.
Move around in a large building with lots of wifi that have very similar or the same names. The first time, it connects fine. When you move out of range, and need a different hot spot, it flops, and flops bad. Even a reboot won't clear it's stubborn refusal to update the wifi environment it sees. Got to go in and manually delete previous information, and I don't mean telling it to "forget" connections, no. Need to delete bad configurations from /etc. That's way beyond what a casual user should need to know.
Another annoyance is a curious inability to multitask while the wifi networking is working. Why can't I check the battery level while wifi is trying to connect?
Android does much better, but even that can hang itself up on the wrong info.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @03:09PM
Fascinating, and no doubt a PITA.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @05:25PM
those two distros are serious outliers. lubuntu uses a DE that barely/doesn't exist/is very stripped down and/or modified. pclinuxOS is maintained by a very small team the last i checked and is somewhat custom and boutique. i would be more convinced that there is an actual problem if you had said arch linux with NetworkMaanger
(Score: 1) by DeVilla on Saturday December 22 2018, @07:58PM (1 child)
I kind of want the opposite behavior. Just because I request to connect to a network once does not mean I want to reconnect every time I walk by. I want to have to explicitly tell the system I trust a network enough to reconnect without asking. My home, sure. My kid's school, I guess. The mall, a hotel, the airport ... not on your life. Right now I have to be in the habit of going in and editing every connect after the initial connection to tell it not to connect behind my back. That sucks.
As far as your other problems, I don't know if that's a PCLinuxOS thing or what. I switch hot spots at work at least as well as the windows users. (And I do have the work wifi setup as trusted for autoconnect.) I don't have problems with things like you battery level problem. In my experience though, that sounds like the kind of thing that can happen when you have a laptop with non-standard setups. Decktops were better about that. My employer tries to make sure they have Linux capable laptops.
(Score: 2) by bzipitidoo on Saturday December 22 2018, @09:41PM
Need to clarify what happens with business X, Y, and X again. Whether or not the reconnection is automatic, or manual and I initiated it, it fails, complaining of incorrect password or key, though it has the correct one or none was required. (In another minor annoyance, it then sets the connection dialog so it defaults to WEP. Seems to assume that if WPA failed, maybe the wifi is WEP. But no one uses WEP any more, and if they were, I wouldn't want to connect.) Anyway, a reboot clears things up. I haven't investigated further, but I shouldn't be surprised if some data was corrupted. If there is corruption of data, maybe it happens when I close the laptop and it goes to sleep and fails to suspend.
I think the problem is the apps they chose for the PCLinuxOS distro. They use this draknetcenter to handle the wifi. I suppose "drak" is for Mandrake. Just why PowerManager (the battery level icon) won't respond until draknetcenter gives the magic "connected" popup, I do not know. There doesn't seem to be any good reason for that behavior. Whatever, I'm thinking I need to move on to yet another distro. Perhaps I will try Void Linux next.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @08:09PM
I haven't had any issues like that on my thinkpad or my macbook air, both running linux with no DE at all just running straight wpa_supplicant. If I move to a different wifi location, it connects to the new AP as long as it's configured. If it doesn't for some reason, the most I've had to do is restart the service (which is just a sysvinit script that disables the interface, re-enables, and reconnects using wpa_supplicant and dhcpcd). The order that the AP's are listed in the conf is the order of precedence, so if I'm connected to my phone's hotspot and come into range of my home AP, it connects to the home wifi instead.
OpenBSD requires re-running the /etc/netstart script though.
Is your wifi card really obscure with a horrible driver or something?
(Score: 3, Insightful) by driverless on Saturday December 22 2018, @07:52AM
In other breaking news: The sun will rise tomorrow, snow is white, water is wet, and Windows 10 sucks.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @07:10PM (1 child)
Looks like this story has a small entropy pool, too. Coincidence, or fate?
(Score: 4, Funny) by Bot on Saturday December 22 2018, @01:14PM
The really ironic part is that if you look for entropy and randomness there are few options better than the behavior of systemd itself.
Account abandoned.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @07:23PM
Thanks for trying to mirror the document, but it is 404 right now.
(Score: 4, Insightful) by Anonymous Coward on Friday December 21 2018, @07:42PM (4 children)
"Systemd makes this behaviour worse..."
is there anything systemd improves?
(Score: 5, Informative) by rcamera on Friday December 21 2018, @07:46PM (1 child)
you mean other than nsa backdoors? yes - it also improves complexity.
/* no comment */
(Score: 1, Funny) by Anonymous Coward on Friday December 21 2018, @09:36PM
Value of red hat certs?
(Score: 2) by Thexalon on Friday December 21 2018, @09:23PM
Lennart Poettering's bank account, perhaps?
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 4, Insightful) by maxwell demon on Friday December 21 2018, @09:56PM
The number of distributions, since there are now some distributions that exist solely to avoid systemd.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Interesting) by Coward, Anonymous on Friday December 21 2018, @08:19PM (9 children)
With random numbers being so important for security, you'd think that servers include would include a hardware random-number generator that relies on physically-proper entropy, rather other weird sources (e.g. network or user input timing). How expensive can it be to make a chip that amplifies and digitizes Johnson- or Shot-noise?
(Score: 4, Interesting) by Arik on Friday December 21 2018, @08:41PM
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Friday December 21 2018, @08:46PM
And for virtual machines, a virtual hardware RNG, much like you get virtualised other hardware like NICs, TPM etc. VMs using this virtual RNG device can then use the hypervisor's pool as an additional entropy source (or whatever the hypervisor chooses to feed to the VM through this interface). Of course there'd need to be safeguards in the hypervisor to ensure there isn't a denial-of-service on the host if one VM suddenly asks for a huge amount of entropy in a short period of time, or a large amount of requests from lots of machines.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @10:11PM
Some BT dongles (only those by CSR chip?) have RNG, you can get 16bits with each call. Check http://www.digifail.com/projects/bt_rng.shtml [digifail.com] for analysis. Based in his first test, 500 iterations in 10 seconds, 50 per second, so 100 bytes, 800 bits. And from the further tests, those 100 bytes are probably high quality.
That was at least 9 years ago, a guy with a shell script and then a small C utility. https://hackaday.com/2009/12/19/bluetooth-based-psuedorandom-number-generation/ [hackaday.com]
And then we got https://en.wikipedia.org/wiki/RdRand [wikipedia.org] but that one could be poisoned.
I suggest reading https://hackaday.com/tag/prng/ [hackaday.com] https://hackaday.com/tag/rng/ [hackaday.com] https://hackaday.com/tag/entropy/ [hackaday.com] etc and see if something else is useful.
So yes, it is possible. When there is a will to do it.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @10:46PM
(Score: 2) by sjames on Saturday December 22 2018, @12:16AM (1 child)
It's not expensive at all. I've even seen RNGs thrown in as a freebie on various chips including flash chips. BUT, unlike the various auditable open software solutions, how do we audit the hardware?
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @10:52AM
http://nosuchlabs.com/ [nosuchlabs.com]
(Score: 3, Insightful) by stormwyrm on Saturday December 22 2018, @06:23AM (1 child)
The thing here is if you had a hardware RNG you didn't build yourself, the question becomes one of trust. How can you be certain that the RNG isn't actually a kleptographic system that produces output that LOOKS random to all statistical tests, but can really be predicted by someone with the right keys? Would you really trust, say, Intel to include a "true" RNG circuit in their CPUs that doesn't have such a back door? Judging from their past behaviour [soylentnews.org], I'd rather use the Arduino-based RNG [soylentnews.org] I built myself instead, slow as it is, thank you very much.
Numquam ponenda est pluralitas sine necessitate.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @01:03PM
a solution would be to have a standard port for hardware RNG so you can plug external ones. The paranoid should be able to sidechain/combine/xor two or more of them. Two backdoored RNG combined do not add two backdoors, but probably void both.
(Score: 1) by DeVilla on Saturday December 22 2018, @08:07PM
Have you read Ted's warning about RDRAND? It would probably apply to any other HWRNG.
(Score: 4, Informative) by darkfeline on Friday December 21 2018, @08:19PM (19 children)
It seems systemd can do no right.
Basically, Poettering's stance is that it is not possible to know how much entropy is in the saved file, therefore systemd errs on the side of caution by not crediting the kernel's entropy counter. For example someone may ship a bad seed file and thus compromise the integrity of the kernel's CSPRNG. The counterargument is that people shouldn't be shipping bad seed files. Poettering argues that many people will do so since they may not even be aware of seed files.
If systemd defaults to less secure, people complain (see the root USER fiasco). If systemd defaults to more secure, people complain.
(Note that Poettering OKed a patch to optionally enable incrementing the entropy counter, thus solving this issue. If you enable it, it's assumed you know the security implications of shipping or not shipping a seed file.)
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Friday December 21 2018, @08:43PM
are equally absurd
(Score: 5, Insightful) by Thexalon on Friday December 21 2018, @09:58PM (6 children)
In your post you describe two options:
1. Secure version where SSH gets stuck for a while waiting for entropy to be collected.
2. Insecure version where SSH starts up right away but isn't guaranteed to be safe.
And then you duck right past other options, like:
3. When you load up the seed files, check to see if they're "bad" (whatever that means). If they're "bad", then generate or otherwise acquire a good seed file. Another upside of this is that you should only have to fix this once.
4. Work with distros and other relevant projects to ensure that seed files aren't "bad" as often as possible, thus making the scenario above more rare.
And this exemplifies why people don't like Lennart: He is willing to screw up user's experiences and/or other packages that rely on his stuff to "solve" a problem he either lacks the creativity or the diligence to solve. It's a consistent tendency to make changes to functioning software attempting to achieve what seems like a platonic ideal of software which has the small drawback of making it no longer work properly.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @12:20AM
you cannot distribute seed file at all. it is negative entropy when shipped. It should be generated by the system at shutdown and deleted after it is loaded at startup. if you have to bassh systemd pile on the fact that a patch was needed to have the option to enable that feature but don't blame it for a secure default.
(Score: 5, Insightful) by coolgopher on Saturday December 22 2018, @12:23AM
Ideal software? SystemD is light years further away from that now than we were with scrappy ol' SysV and individual, replaceable components. The man repeatedly fails to comprehend the core Unix tenet of "do one thing, and do it well". And I do not comprehend why people keep accepting his cruddy software into their distros. Something is rotten in the state of Linux.
(Score: 2, Troll) by darkfeline on Saturday December 22 2018, @06:15AM (3 children)
Good job exposing your own ignorance.
> When you load up the seed files, check to see if they're "bad" (whatever that means)
You can't, that's the point. There's no way to really measure entropy, you can only estimate it. If you get it from a file you have no idea what the quality is.
>then generate
The only way to "generate" entropy is to wait for it to accumulate as the kernel runs, hence the multiple minute waits after boot. You're asking systemd to do what it's already doing. Again, you're just exposing your own ignorance.
>Work with distros and other relevant projects to ensure that
Lennart is worried about people rolling their own things, like embedded. This is *especially* bad for embedded because they usually have limited entropy sources. These people (much like you) probably have very little knowledge of entropy and cryptography to get this right.
>And this exemplifies why people don't like Lennart
Because they are ignorant, don't bother to research the technical details of the problem and solution, and spout FUD? Sounds about right.
Join the SDF Public Access UNIX System today!
(Score: 3, Informative) by Thexalon on Saturday December 22 2018, @01:25PM (2 children)
Then estimate it, and see what the estimate is.
I'm asking systemd to do what it's already doing when it's actually necessary to do that, not when it is theoretically conceivable that doing that might be required.
So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong (presumably, the issue gets discussed in any books / websites / other resources they're consulting when rolling their own), and for that reason you should do something very annoying for the vast majority of users who aren't rolling their own?
Again, it's taking a theoretical issue and using it as an excuse to mess things up for everybody who isn't affected by it. Lennart has busted the kernel for similar reasons before.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Pino P on Saturday December 22 2018, @08:42PM
This exposes the system to RNG attacks [wikipedia.org] in which the attacker replaces the seed file with a hand-crafted one that games the estimate.
Yes. See the "Prominent examples" in the "RNG attacks" article.
(Score: 2) by darkfeline on Wednesday December 26 2018, @01:15AM
Let me just give you a very simple example.
Take a "good" seed file. The first time this file is ever used in history, it has N bits of good entropy. Every subsequent time it is used, it has 0 bits of good entropy.
Now, tell me how systemd is supposed to estimate whether the seed file was ever used before in history? It might not even have been used on the same computer, or on the same drive, or in the same country.
This isn't a theoretical issue. Have you heard of Logjam, where everyone shipped a common Diffie-Hellman prime opening up an attack vector? Most people screw up cryptosystems, including distro maintainers and packagers.
Even IF we accept the risk, to dismiss Lennart's position off-hand is disingenuous. He has a valid point even if you disagree with it for valid reasons.
>So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong
All it takes to "roll their own" is to take an image snapshot of the disk, like for an embedded project. You don't even have to know about the seed file to get it wrong. In fact, it's the opposite: the people who don't even know about the seed file's existence are the most likely to get it wrong. If you do know about it, you're able to optionally enable it in systemd if you need it.
Join the SDF Public Access UNIX System today!
(Score: 5, Insightful) by sjames on Saturday December 22 2018, @12:28AM (8 children)
I've noticed that, but I suspect I read that in a different sense than you do :-)
If I understand, the concern is that the distributor who has already been trusted to ship an untainted system (including systemd) somehow can't be trusted to ship a good seed file? That sounds like a dumb excuse that's almost as good as "sorry, I have to wax my cow and floss the cat tonight.".
(Score: 2) by loonycyborg on Saturday December 22 2018, @07:41AM (7 children)
It's not a matter of trust. You can be absolutely sure that at least some distros will screw it up. This issue is easy to miss and won't result in bug reports from users because it doesn't break things in noticeable fashion, until it enables some attack on the system. And then it will be systemd that will be blamed for this. Damned if you do, damned if you don't.
(Score: 3, Insightful) by sjames on Saturday December 22 2018, @08:22AM (6 children)
Care to name one?
On the other hand, systemd will be rightly blamed when an embedded system appears to fail on upgrade with systemd taking over an hour in some cases to get past the random-seed issue.
In all cases like these, the rule in Unix is that the system should implement mechanism and leave policy to the admin.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @12:16PM
If you're running SystemD in an embedded system you'd probably be better off with XP.
(Score: 2) by loonycyborg on Saturday December 22 2018, @03:28PM (4 children)
Yes, it's easy to spot boot delay, research the issue and ensure there is some good source of entropy such as TPM or RDRAND. And all before the embedded system gets into user's hand.
(Score: 2) by sjames on Saturday December 22 2018, @05:57PM (2 children)
What makes you think either of those exist on an embedded device?
Some have it, some don't.
It's also easy to make it configurable and let the admin decide policy, but systemd is not very good about following the rule.
(Score: 2) by loonycyborg on Sunday December 23 2018, @09:40AM (1 child)
What do you mean? They agreed to make it configurable. The argument is only about the default value of that setting :P
(Score: 4, Informative) by sjames on Sunday December 23 2018, @06:17PM
They have agreed to nothing, that item is still open. The current discussion is more like reluctant and grudging potential agreement but let's hide that option somewhere and consider it to be experts only/debugging.
On the matter of systemd consuming the limited entropy available at boot time, they have agreed that it isn't really necessary but that they're going to keep doing it anyway.
The rest is workarounds with the kernel or the initrd taking over and doing things behind systemd's back so necessary things can get done without dealing with systemd's inability to handle it the one true systemd way.
(Score: 1) by DeVilla on Saturday December 22 2018, @08:22PM
Someone didn't read Ted's warning about RDRAND or doesn't care.
(Score: 3, Insightful) by Bot on Saturday December 22 2018, @01:09PM (1 child)
> Basically, Poettering's stance is that it is not possible to know how much entropy is in the saved file, therefore systemd errs on the side of caution
Basically, Poetterix should not take it on his shoulders to virtually sysadmin all linux boxen (boxenes, boxii, however you prefer to spell it) and make that a configurable option, so that I can access my VPS which hosts public information in less than fifteen mins.
This seems like a case of: i found a good excuse to inconvenience you, so BLAM there it is. Bonus points from my next employer, microsoft.
(note, of course my vps is systemd free)
Account abandoned.
(Score: 2) by coolgopher on Sunday December 23 2018, @01:24AM
*next* employer? His behaviour has long suggested otherwise...
(Score: 1, Interesting) by Anonymous Coward on Friday December 21 2018, @08:52PM (2 children)
Don't use systemd.
VOID linux. nuff said.
(Score: 5, Insightful) by coolgopher on Saturday December 22 2018, @12:16AM (1 child)
Or Devuan [devuan.org].
(Score: 1, Informative) by Anonymous Coward on Saturday December 22 2018, @01:11PM
or antix or mxlinux or gentoo or artix or obarun....
(Score: -1, Offtopic) by Anonymous Coward on Friday December 21 2018, @09:27PM (1 child)
...there's plenty at the White-House
(Score: 3, Touché) by maxwell demon on Friday December 21 2018, @09:59PM
Sorry, but you want high-quality entropy for your random numbers.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @09:54PM (2 children)
Start Haveged before sshd, if you don't mind RNG Quality. This maybe accomplished with systemd "Wants= haveged.service "on sshd unit file.
(Score: 0) by Anonymous Coward on Friday December 21 2018, @11:40PM
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @04:45PM
haveged is great. I use it on all my lab machines which lack natural entropy sources specifically to avoid this exact problem after reboots.
(Score: 5, Informative) by zeigerpuppy on Saturday December 22 2018, @12:27AM
Another reason to use Devuan. i recently installed the latest version on a production server and have been really happy, it's quick, has good compatibility with extra packages (ZFS installed without hassle). The devs are doing a great job of keeping proper linux alive. I hope Debian continues to do well because ultimately downstream projects like Devuan rely on it but I won't be installing stock Debian ever again.
Oh, as far as hardware RNG, I've had great success with Bitbabbler White, here's a good comparison list. https://everipedia.org/wiki/lang_en/Comparison_of_hardware_random_number_generators/ [everipedia.org]
For those wondering if I've tried systemd, yep, and it's a clusterfuck, unexplained boot delays and failures, unpredictable behaviour and frequent security bugs, no thanks.
(Score: 1, Funny) by Anonymous Coward on Saturday December 22 2018, @04:08PM (4 children)
"There are currently not any feasible work-arounds."
Not so [openbsd.org]
(Score: 3, Interesting) by Pino P on Saturday December 22 2018, @08:58PM (3 children)
What workaround does OpenBSD employ to gather enough entropy to bring up OpenSSH and LibreSSL as quickly as possible after a restart or power cycle?
(Score: 2) by coolgopher on Sunday December 23 2018, @01:30AM (2 children)
It's been many years since I last touched OpenBSD, but I seem to recall it dumping out an entropy file on shutdown that then gets loaded on boot. The man page [openbsd.org] suggests the same:
(Score: 3, Informative) by canopic jug on Sunday December 23 2018, @04:38AM (1 child)
... but I seem to recall it dumping out an entropy file on shutdown that then gets loaded on boot.
During shutdown /dev/random is dumped to the file /etc/random.seed [openbsd.org] and then on next boot, it and other data sources are read into the kernel [openbsd.org]. The down side is that it makes it harder to have a read-only main system.
Money is not free speech. Elections should not be auctions.
(Score: 2) by Pino P on Monday December 24 2018, @03:54PM
In other words, OpenBSD dumps entropy to a file and trusts on the next boot that an attacker hasn't modified it.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @04:43PM (1 child)
As always, security represents a tradeoff. The goal of a security system is to let the "good guys" use the system while at the same time preventing the "bad guys" from doing the same.
Typically this means making the "good guys" do more work to access the system, plus some risk that a "good guy" is mistaken for a "bad guy" and then the "good guy" can't use the system at all. In this case, the "good guys" must wait 10 minutes after bootup before they can use the system. If the system reboots a lot then this could represent an enormous amount of wasted "good guy" time.
This time is generally not free, so you need to weigh that against the risk of mistakes and the cost of a "bad guy" getting into the system. I would argue that in almost all normal computer systems the "good guy" time is worth substantially more than the expected negative consequences of a "bad guy" gaining unauthorized access.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @05:44PM
But not using /var/lib/urandom/random-seed, if I understand what systemd is doing differently from all other init systems, especially for the reason given, is just stupid.
And I still don't know what tangible benefit switching to systemd from OpenRC would get me, other than headaches.