Your message dated Sat, 26 Aug 2023 14:16:47 +0200
with message-id <85c50434-05c5-41af-b8d6-bb1bb6cb1...@debian.org>
and subject line Re: Bug#760029: systemd: doesn't initialise RANDOM_SEED upon
installation
has caused the Debian Bug report #760029,
regarding systemd: doesn't initialise RANDOM_SEED upon installation
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
760029: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760029
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: systemd
Source-Version: 208-8
Tags: security
Hi,
At some point between squeeze and wheezy initscript started initialising the
RANDOM_SEED file in its postinst by basically doing the equivalent of a
"service urandom start". This feature doesn't actually seem to have been
integrated into the systemd package - which I personally consider it to be a
regression.
Could you please then initialise RANDOM_SEED at the package installation
time?
TIA.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--- End Message ---
--- Begin Message ---
On Thu, 18 Feb 2016 20:40:54 +0100 Raphael Geissert
<geiss...@debian.org> wrote:
Hi,
On 5 February 2016 at 00:08, Martin Pitt <mp...@debian.org> wrote:
> Raphael Geissert [2016-02-04 23:20 +0100]:
>> Given that systemd-random-seed writes to urandom, it only adds data to
>> the input pools. It does not attempt to alter the kernel's entropy
>> estimate, which would be done by using the RNDADDENTROPY ioctl.
>>
>> Having an identical random-seed from systemd should not be any worse
>> than not having one, pretty much as it should not be any worse for
>> some random process running as "nobody" writing 0s to u/random.
>
> I'm afraid I need some more convincing about this. The point of
> saving/restoring the seed on shutdown/boot is to add "good" entropy to
> the RNG. I know that by adding zeros to the pool you don't actually
> make the resulting numbers worse, but the point I'm really not sure
> about: doesn't adding a seed also increase the pool size? I. e. my
> concern is, if you inject a "bad" (because copied) seed, wouldn't that
> make /dev/random block less, or not at all?
No, it doesn't alter the kernel's entropy estimate, which is what
determines whether the random device should block.
Cf. https://sources.debian.net/src/linux/3.2.65-1/drivers/char/random.c/#L1276
random_write doesn't call credit_entropy_bits)
In other words, the seed that is loaded at boot time can only help the
randomness of the random device, but not its estimate and therefore
not its "blockingness".
> I think a much better answer than creating it in the postinst (where
> *both* the current RNG state *and* the eventual fate of that file are
> totally unknown) is to create the seed in d-i in finish-install, when
> the system ran long enough. Similarly, cloud-init could use pollinate
> or a similar technology to snitch some entropy from the host. In
> general, IMHO the right thing is to do this per machine/instance, not
> per image.
This would indeed be great and it could be done in addition to the
current proposal.
I skimmed over this old bug report again and given the concerns Martin
raised, I agree that we should not go down this road.
So I'm closing this as wontfix.
Regards,
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
