On Wed, 2019-09-11 at 15:52 -0400, Paul Thomas wrote:
> Hi All,
>
> First off, I want to acknowledge how great system Debian is, very nice work!
>
> I know the issue with Entropy Starvation is understood, and I
> understand the security concern:
>
Hi All,
First off, I want to acknowledge how great system Debian is, very nice work!
I know the issue with Entropy Starvation is understood, and I
understand the security concern:
https://wiki.debian.org/BoottimeEntropyStarvation
https://daniel-lange.com/archives/152-hello-buster.html
However,
On Mon, 2019-01-21 at 21:46 +, Ben Hutchings wrote:
> On Mon, 2019-01-21 at 20:49 +, Andy Simpkins wrote:
> [...]
> > Should we add to or change the possible entropy sources?
> [...]
>
> Yes, we should (by default) enable use of available hardware RNGs to
> produce entropy and if none is
On Mon, 2019-01-21 at 20:49 +, Andy Simpkins wrote:
[...]
> Should we add to or change the possible entropy sources?
[...]
Yes, we should (by default) enable use of available hardware RNGs to
produce entropy and if none is available then we should (by default)
install one of the various
Hi,
This thread seems to have gone quite for some time. Re-Reading the
thread I don't see any solutions being proposed that will truly suit
everyone.
If I have correctly understood the problem we are seeing a change from a
more open and trusting software environment to one with more emphasis on
On Jan 16, Guido Günther wrote:
> There's also jitterentropy-rngd which does the trick but I haven't
> looked at the security implications.
Nowadays rngd collects jitter entropy, so I would not use something
else.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Wed, 2019-01-16 at 11:05 +0100, Guido Günther wrote:
> Hi,
> On Mon, Jan 14, 2019 at 05:56:20PM +0100, W. Martin Borgert wrote:
> > Quoting Michael Stone :
> > > Unless the cpu supports rdrand/rdseed, installing rng-tools5
> > > won't
> > > really change anything. If it does support those, it
Hi,
On Mon, Jan 14, 2019 at 05:56:20PM +0100, W. Martin Borgert wrote:
> Quoting Michael Stone :
> > Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't
> > really change anything. If it does support those, it probably makes more
> > sense going forward to just enable
On 1/14/19 7:07 AM, Thomas Goirand wrote:
On 12/18/18 8:11 PM, Theodore Y. Ts'o wrote:
If you are firmly convinced that there is a good
chance that the NSA has suborned Intel in putting a backdoor into
RDRAND, you won't want to use that boot option.
I have read numerous times that some people
On January 14, 2019 11:56:20 AM EST, "W. Martin Borgert"
wrote:
>Quoting Michael Stone :
>> Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't
>> really change anything. If it does support those, it probably makes
>> more sense going forward to just enable
Quoting Michael Stone :
Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't
really change anything. If it does support those, it probably makes
more sense going forward to just enable CONFIG_RANDOM_TRUST_CPU
rather than installing another package.
This option is only
Sam Hartman wrote:
"Marco" == Marco d'Itri writes:
Marco> online. Is it enough to feed the host side of virtio-rng
Marco> with /dev/random or should everybody who has virtual machines
Marco> also install rngd in the host? Is rngd to be preferred to
Marco> haveged?
I'd also
On Mon, Jan 14, 2019 at 12:55:09PM +0100, Marco d'Itri wrote:
Agreed. I think that d-i should install rngd (or haveged? And why?) if
it detects a virtualized environment without virtio-rng.
Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't
really change anything. If it does
On 12/18/18 8:11 PM, Theodore Y. Ts'o wrote:
> If you are firmly convinced that there is a good
> chance that the NSA has suborned Intel in putting a backdoor into
> RDRAND, you won't want to use that boot option.
I have read numerous times that some people trust this or that part of
the
On Jan 13, Sam Hartman wrote:
> I recently discovered that Vmware appears to have no virtual RNG
> available to the guest at all.
AFAIK you are right.
> A buster vmware guest will boot but will be unable to start sshd because
> of lack of entropy for typically five minutes or so.
> A lot of
> "Marco" == Marco d'Itri writes:
Marco> online. Is it enough to feed the host side of virtio-rng
Marco> with /dev/random or should everybody who has virtual machines
Marco> also install rngd in the host? Is rngd to be preferred to
Marco> haveged?
I'd also like to point
On Jan 09, "Theodore Y. Ts'o" wrote:
> x86 systems have a high resolution timer; Rasberry PI's don't.
> Furthermore, if libvirt is miconfigured, it should just be fixed (and
> better yet, it should be configured to enable virtio-rng, which is
> *not* hard).
Can you clarify what is the best
On Thu, Jan 10, 2019 at 03:57:00PM +0100, Michael Biebl wrote:
with possible solutions like installing haveged
It still isn't clear to me that this is actually secure, so I'm not sure
we should be telling people to do it in release notes.
Mike Stone
On Thu, 10 Jan 2019, Michael Biebl wrote:
> Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> > On Thu, 10 Jan 2019, Michael Biebl wrote:
> >>> ACK, we also had to do the same in Grml[.org] and our latest release
> >>> (2018.12). Now we automatically enable haveged when users boot using
> >>> the
Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> On Thu, 10 Jan 2019, Michael Biebl wrote:
>>> ACK, we also had to do the same in Grml[.org] and our latest release
>>> (2018.12). Now we automatically enable haveged when users boot using
>>> the ssh boot option (which is something Grml specific,
On Thu, 10 Jan 2019, Michael Biebl wrote:
> > ACK, we also had to do the same in Grml[.org] and our latest release
> > (2018.12). Now we automatically enable haveged when users boot using
> > the ssh boot option (which is something Grml specific, taking care
> > of setting user password and
On Wed, 9 Jan 2019, Theodore Y. Ts'o wrote:
> On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
> >
> > There have been a number of bug reports and blog posts about this, despite
> > buster not being release yet. So it's not that uncommon.
>
> Pointers, please? Let's see them
Am 10.01.19 um 14:23 schrieb Michael Prokop:
> * Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]:
>> On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
>
>>> Pointers, please? Let's see them and investigate. The primary issue
>>> I've been aware of to date has been on Fedora systems, and it's
* Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]:
> On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
> > Pointers, please? Let's see them and investigate. The primary issue
> > I've been aware of to date has been on Fedora systems, and it's due to
> > some Red Hat specific changes that they
Hi,
On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
> Pointers, please? Let's see them and investigate. The primary issue
> I've been aware of to date has been on Fedora systems, and it's due to
> some Red Hat specific changes that they made for FEDRAMP compliance
> --- and Red Hat has dealt with
On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote:
>
> If the security issue only affects a small percentage of the installations
> and fixing it means breaking many other installations, then there has to
> be a discussion if we really want fix the issue or if a "don't do that"
>
On Wed, 2019-01-09 at 11:40 -0500, Theodore Y. Ts'o wrote:
> On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
[...]
> > No, that's utterly wrong. If it's a hassle to use good entropy, people
> > will use gettimeofday() for getting "entropy" and they will use it for
> > security
On Wed, Jan 9, 2019 at 12:13 PM Theodore Y. Ts'o wrote:
> On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
> >
> > There have been a number of bug reports and blog posts about this,
> despite
> > buster not being release yet. So it's not that uncommon.
>
> Pointers, please? Let's
On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
>
> There have been a number of bug reports and blog posts about this, despite
> buster not being release yet. So it's not that uncommon.
Pointers, please? Let's see them and investigate. The primary issue
I've been aware of to
On Tue, 8 Jan 2019, Theodore Y. Ts'o wrote:
> On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote:
> >
> > If the security issue only affects a small percentage of the installations
> > and fixing it means breaking many other installations, then there has to
> > be a discussion if
On Sun, 23 Dec 2018, Theodore Y. Ts'o wrote:
> On Sun, Dec 23, 2018 at 05:52:31PM +0100, Stefan Fritsch wrote:
> > I think some other questions should be considered first. Did Debian protect
> > from these attacks in the past? The answer is clearly no. Now, should we
> > break
> > the systems
On Sun, Dec 23, 2018 at 05:52:31PM +0100, Stefan Fritsch wrote:
> I think some other questions should be considered first. Did Debian protect
> from these attacks in the past? The answer is clearly no. Now, should we
> break
> the systems of those people who keep their random-seed file secret
On Tuesday, 18 December 2018 20:11:58 CET you wrote:
> On Mon, Dec 17, 2018 at 09:46:42PM +0100, Stefan Fritsch wrote:
> > There is a random seed file stored by systemd-random-seed.service that
> > saves entropy from one boot and loads it again after the next reboot. The
> > random seed file is
On Mon, Dec 17, 2018 at 09:46:42PM +0100, Stefan Fritsch wrote:
>
> There is a random seed file stored by systemd-random-seed.service that saves
> entropy from one boot and loads it again after the next reboot. The random
> seed file is re-written immediately after the file is read, so the
34 matches
Mail list logo
