[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2021-06-30 Thread Dan Streetman
please reopen if this is still an issue

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2017-08-18 Thread Marc Deslauriers
Hi John,

We get the current random seed unit from systemd. Please file a bug with
the upstream systemd project, or discuss these changes on the systemd
mailing list.

Once your changes are accepted by systemd, we will inherit them.

Thanks!

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2016-12-24 Thread John Denker
Here's an even simpler argument why random-seed-load and random-seed-save should
be seen as two separate stateless services, not as the "start" and "stop" of 
some
single long-lived service.

Suppose that during boot-up, random-seed-load fails for some reason.  There are
definitely ways this could happen.  (OTOH there are a surprising number of 
things
that could go wrong that systemd-random-seed save does /not/ report as an error
... but that is a topic for another day.)

Now suppose that in the minutes, hours, or days that follow, the problem is 
resolved.
Desired behavior:  We really want the 'save' service to be performed at 
shutdown.

The currently-observed behavior is that if 'load' failed then 'save' will never 
be
performed.  This is a Bad Thing from the security point of view.

Splitting the services as discussed above makes this issue (among
others) go away.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  New

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2016-12-24 Thread John Denker
OK, I implemented approach (2) from the previous comment.
The work consists of six steps, in two groups of three:

++ create system/systemd-random-seed-load.service
++ create system/systemd-random-seed-save.service
-- get rid of the old system/systemd-random-seed.service

++ create system/sysinit.target.wants/systemd-random-seed-load.service
++ create system/shutdown.target.wants/systemd-random-seed-save.service
-- get rid of the old system/sysinit.target.wants/systemd-random-seed.service

The two new .service files are simple and straightforward.  See attached
patch.

I retract my previous speculation about reimplementing the old
systemd-random-seed.service because AFAICT it was only invoked from
sysinit.target ... and anybody else who tried it almost certainly wasn't
getting acceptable results.

We must drop the whole idea of a systemd-random-seed "service" with an active
state bookended by a single start-event and a single stop-event.  That might
have seemed elegant at first glance, but it did not capture the right semantics.
It did not meet the security needs.

Implementing two separate one-shot services does what is needed.  It is
close to the longstanding init.d/urandom behavior.


** Patch added: "two separate one-shot random-seed services"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+attachment/4796118/+files/random-seed.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  New

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2016-12-23 Thread John Denker
I retract patch and recipe mentioned in the initial report.  The
problem is messier than I initially thought.

One fundamental consideration is that apparently systemctl won't
start a service that is marked active, and won't stop a service
that is marked inactive.  This is inconsistent with longstanding
initscript behavior, where you can start (or stop) something as
many times as you like.

0) Simple question:  Is there a way to teach the system to ignore
the nominal state and just run ExecStart or ExecStop as directed?
Maybe type=stateless rather than type=oneshot?  This would make
things a whole lot simpler.

1) Arguably "most" of the problem goes away if we document "restart"
(as in "systemctl restart systemd-random-seed") as the proper way
to refresh the seed.  That leaves init.d/urandom in a bad state,
because it knows nothing of "restart".

2) Here's another approach to consider:  A paire of separate services:
  systemctl start systemd-random-seed-load
and
  systemctl start systemd-random-seed-save

The latter is /started/ (not stopped!) at shutdown time.  Neither
service has an ExecStop method.  Neither service ever becomes active.
Either one can be started as many times as desired, in any order.

This is the only way I can think of to capture the semantics of the
longstanding init.d/urandom script.

The present systemd-random-seed script can trivially be reimplemented
in terms of the new pair of services.

This approach (2) would still require some changes to init.d/urandom,
but not quite as ugly as approach (1) would require.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  New

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again

2016-12-23 Thread Colin Watson
Wherever it goes, this part of the random-seed problems is not the
responsibility of the installer.  Reassigning to systemd for now because
that's where systemd-random-seed.service lives.

** Package changed: ubiquity (Ubuntu) => systemd (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  New

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  ---
  Observed on
  :; lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  :; apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu13
Candidate: 229-4ubuntu13
Version table:
   *** 229-4ubuntu13 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu10 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   229-4ubuntu4 500
  500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp