Re: systemctl restart sddm
On maandag 23 juli 2018 08:01:36 CEST Martin Steigerwald wrote:
> Hello inkbottle.
>
> inkbottle - 22.07.18, 23:42:
> > As some of you already know, since *completely uneventful* upgrade of
> > Friday, July 20, 2018, "sddm" does not start automatically anymore,
> > whether because something goes wrong at some point or because it
> > doesn't start at all, meaning it is not even invoked in the first
> > place, that I know not ;)
>
> Are you aware of
>
> sddm: takes extremely long time to start
> https://bugs.debian.org/898092
>
> Workaround #1: Just type something in tty until there is enough
> randomness. It usually just takes 5-20 seconds of typing something into
> tty. You don´t even need to login, just type something into the login
> prompt.
>
> Workaround #2: Install haveged (Maxy set it to recommended with sddm
> 0.18 package).
>
> Workaround #3: Downgrade the kernel.
>
> I am still using workaround #1, cause I am not convinced that installing
> haveged is beneficial for the reliability of /dev/random, at least not
> for creating new SSH and GPG keys. However there is a host of different
> opinions on that.
>
> Thanks.
>
I did some digging, as I was a bit surprised QHash needs (secure) randomness at all.
Turns out, reading http://doc.qt.io/qt-5/qhash.html#qhash , that QHash has an inbuilt
protection against hashtable bucket bias attacks (chosen input that hashes into the
same hash value, and therefore into the same hashtable bucket, leading to performance
hits).
Not sure where sddm uses the QHash, but it seems unlikely to me that there is much
potential for large amount of user controlled data ending up in the QHash.
In that case, sddm could just initialize the random seed by using qSetGlobalHashSeed()
with zero or some pseudo-random value and avoid the wait for entropy.
--
Sander
Reply to: