[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#895718: python-pyqt5: import PyQt5.QtCore fails



On Sun, 24 Jun 2018 13:28:38 +0300 Adrian Bunk <bunk@debian.org> wrote:
> On Mon, May 14, 2018 at 04:32:26PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On 14 May 2018 at 16:24, Mattia Rizzolo <mattia@debian.org> wrote:
> > > On Mon, May 14, 2018 at 01:55:55PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> > >> Quoting from the above:
> > >>
> > >>   The rationale of this system call is to provide resiliance against
> > >>   file descriptor exhaustion attacks, where the attacker consumes all
> > >>   available file descriptors, forcing the use of the fallback code where
> > >>   /dev/[u]random is not available.  Since the fallback code is often not
> > >>   well-tested, it is better to eliminate this potential failure mode
> > >>   entirely.
> > >>
> > >> So if we disable it we disable a feature providing a more robust method to
> > >> provide randomness to ours users.
> > >
> > > Reading this sounds like the presence of the syscall could be tested at
> > > runtime, and if present used and if not fall back to dev/urandom?
> > 
> > Patches directly at upstream (due to copyright issues) are welcomed :-)
> 
> As far as I can see, there are 4 sane options available:
> 
> 1. unsupported, and give a clear error
> For working upgrades it is important that software in a stable release 
> works on kernels of the previous and next stable releases.
> This also ends up being well-tested in upgrade scenarios.
> Running buster on the jessie kernel is not really supported,
> and even less tested.

I don't think userland package maintainers should be expected to
support anything older than the kernel version in the last stable
release.  If users really want that to work they should be responsible
for relaxing the dependency in a way that the maintainer accepts.

> libqt5core5a should abort with a clear error message in the preinst
> on kernels < 3.17.
> 
> 2. disable QT_CONFIG(getentropy) in Qt in buster

This would presumably be the simplest approach; it's theoretically less
secure but in practice it's exceedingly unlikely to be a problem.

> 3. implement a fallback in Qt

glibc now implements getentropy() and getrandom(), with fallbacks on
aolder kernel versions.  So I think that you could remove Qt's
implementation of getentropy() and have it call glibc's instead.  (But
I haven't looked at the Qt code in question; it might not be quite as
simple as that.)

> 4. backport getrandom to the jessie kernel
> getrandom is only ~ 20 LOC plus some syscall wiring, so if anyone wants 
> to convince/pay the Debian LTS team to backport that to the jessie 
> kernel it should be doable.
[...]

I don't think this meets the stable update criteria.  In itself it
wouldn't fix any weakness of the RNG.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: