As a FYI, I did some experiments with kvm, and I do seem to have enough
entropy to get the KDC started there.
I have not played with Xen recently. It's a bit harder to set that up,
and I'm unsurprised that might be more tricky to get randomness with
than kvm.
On Mon, 7 May 2018 18:28:01 -0500 Benjamin Kaduk wrote:
> At high risk of opening up the RNG debate that I did not want to
> revisit, the current stance of upstream krb5 seems to fall into what
> I'll call the "Schneier worldview", that a fully-seeded
> well-designed CSPRNG can produce arbitrary a
On Tue, May 08, 2018 at 09:28:08AM -0400, Sam Hartman wrote:
> Benjamin> Now, we have getrandom(), which is a great API and is
> Benjamin> pretty much exactly what you want (again, at least in this
> Benjamin> worldview). IIUC Ted says that you should "just use
> Benjamin> getrando
> "Benjamin" == Benjamin Kaduk writes:
Benjamin> On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
>>
>> There are basically three "strengths" of random numbers available
>> now:
>>
>> Weak: /d
On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
>
> There are basically three "strengths" of random numbers available now:
>
> Weak: /dev/urandom
> Medium: getrandom(flags=0)
> Strong: /dev/random, getrandom(flags=GRND_RANDO
On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
> I'm returning from vacation and jumping into the middle of this.
>
> Back in the day when I wrote the code that became k5_get_os_entropy we
> viewed two cases:
>
> * kadmind. There we're likely to sometimes be generating long-term
> share
I'm returning from vacation and jumping into the middle of this.
Back in the day when I wrote the code that became k5_get_os_entropy we
viewed two cases:
* kadmind. There we're likely to sometimes be generating long-term
shared secrets, and it seemed like strong random numbers were
important
Benjamin Kaduk writes:
> On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:
>> This seems trivial enough that the krb5-kdc package could just ship
>> this service for now and gauge interest. I think all you'd need is a
>> program that called getrandom() and then exited when it returne
On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:
> Benjamin Kaduk writes:
> > On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> >> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
>
> >>> Arguably more preferable would be to have a systemd target that
> >>> ind
Benjamin Kaduk writes:
> On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
>> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
>>> Arguably more preferable would be to have a systemd target that
>>> indicates the RNG is seeded, and then krb5 could have its KDC service
>>> dep
On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> > Hi Ben,
> >
> > On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> > > I've cloned this bug as #898073 and reassigned that to krb5.
> > >
> > > krb5 is using
On Sun, 2018-05-06 at 20:43 +0100, Ben Hutchings wrote:
> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
[...]
> > If the above is correct, I'm not yet sure that I see a krb5-specific
> > bug. It is definitely true that krb5 is specifically requesting the
> > getrandom() semantics of blo
On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> Hi Ben,
>
> On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> > I've cloned this bug as #898073 and reassigned that to krb5.
> >
> > krb5 is using the new(ish) getrandom() system call to read random bits,
> > with the code
Hi Ben,
On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> I've cloned this bug as #898073 and reassigned that to krb5.
>
> krb5 is using the new(ish) getrandom() system call to read random bits,
> with the code comment "This ensures strong randomness while only
> blocking during fi
I've cloned this bug as #898073 and reassigned that to krb5.
krb5 is using the new(ish) getrandom() system call to read random bits,
with the code comment "This ensures strong randomness while only
blocking during first system boot."
While this is a regression, the kernel is only doing what krb5
On further investigation, Arne's absolutely right. I upgraded the
kernel back to 4.9.88-1 from Debian Security and installed 'haveged'
(another random number generator). Everything started quickly and
normally after a reboot. Turns out I hadn't noticed this on any of my
other virtual servers becaus
Interesting! I'd also noticed 'random: init done' being piped to console well
after the server had booted, but I didn't mention it because I didn't think it
was related. What you've said makes a lot of sense.
On Sat, 5 May 2018 11:54:54 +0200 Arne Nordmark wrote:
> I have also seen this on a co
I have also seen this on a couple of SSD-only systems.
I think the problem is that the random number generator takes about two
minutes to initialize, long enough for systemd to give up on these
processes. Unbound is similar, but there unit file keeps trying until
the random numbers are available.
Package: linux-image-4.9.0-6-amd64
Version: 4.9.88-1
Issue:
==
Kernel "linux-image-4.9.0-6-amd64," version 4.9.88-1, breaks systemd
startup of RPC, Kerberos KDC services.
Description:
After upgrading to the latest Stretch kernel (4.9.88-1), RPC and KDC
services time out during
19 matches
Mail list logo
