> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx wrote:
>
> That's all very nice, but nobody is going to run that.
They also don't have to upgrade their kernel, or deploy new
versions of OpenSSL. If platform release engineers don't
deploy core services that ensure reliably CSPRNG seeding,
then their
This vote has been closed, it passed 5 votes to 2 with no abstentions.
Up for discussion is the text of the next vote. I’m proposing this:
Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on
boot and first boot problems.
Comment: PR#9084 removed such mitigation due
On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
>
> > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
> > > >
> > > > For older kernels you
On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
> On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
> > >
> > > For older kernels you install rng-tools that feeds the hwrng in
> > > the kernel.
> >
> > Which works
On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
> >
> > For older kernels you install rng-tools that feeds the hwrng in
> > the kernel.
>
> Which works for me, and is pretty much the point I'm trying to make.
> Then, read
On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote:
>
> >The kernel actually already does this in recent versions, if
> configured to do it.
>
> "The" kernel. Which one is that? Which operating system?
>
> Modern Linux is fine. Is that all we care about?
This whole
> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
>
> For older kernels you install rng-tools that feeds the hwrng in
> the kernel.
Which works for me, and is pretty much the point I'm trying to make.
Then, read /dev/random once early at boot, and do nothing special
libcrypto (safely use
On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote:
> >
> >> This is not the sort of thing to bolt into the kernel, but is not
> >> unreasonable for systemd and the like.
> >
> > The kernel actually already does this in recent
> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote:
>
>> This is not the sort of thing to bolt into the kernel, but is not
>> unreasonable for systemd and the like.
>
> The kernel actually already does this in recent versions, if
> configured to do it.
We're talking about what to do with for
On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote:
>
> That's a different issue. What I was suggesting was a service that
> waits for seeding to be ready. So that other services can depend
> on that service, with that service using various sources to adequately
> seed the kernel
> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre
> wrote:
>
>> The init system would
>> need to create this kind of service, and then all software not using
>> getentropy()/getrandom() would need to depend on that service. It
>
> FWIW: systemd already has a service for saving and
> The reason I think nothing will change is that the problem is
> already solved, use getentropy()/getrandom().
I agree completely.
> The init system would
> need to create this kind of service, and then all software not using
> getentropy()/getrandom() would need to depend on that service. It
On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote:
>
> I think that having the RNG behaviour capriciously different on
> different systems based on the whims of whoever built the library
> for that system is not a good idea. OpenSSL should provide an RNG
> that does not block
On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
>
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.
Introducing DEVRANDOM_WAIT didn't cause any change for us,
On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote:
> See the discussion on openssl-users:
>
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html
>
On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote:
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
> >
> > Viktor replied:
> >
> > > I just want to make sure we don't lock ourselves in to a single
> > > potentially clumsy solution in the library. Various strategies
> > > may be
16 matches
Mail list logo
