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

[Ben Hutchings]

On Sun, 24 Jun 2018 13:28:38 +0300 Adrian Bunk  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  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


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

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

[Adrian Bunk]

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  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.
libqt5core5a should abort with a clear error message in the preinst
on kernels < 3.17.

2. disable QT_CONFIG(getentropy) in Qt in buster

3. implement a fallback in Qt

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.

None of these 4 options should be more than 1 man-day of work.


The submitter of #902118 was running buster packages on a CentOS kernel. 
For such cases of users using non-Debian kernels option 4 would not help.

This CentOS kernel (3.14) is even older than the jessie kernel, and 
in this case the buster Qt might still not work in any case due to
QT_CONFIG(renameat2) which requires >= 3.16.


IMHO option 1 is the best solution since no matter what we do about this 
specific problem, running buster on the jessie kernel might still break 
somewhere else at any point in time.


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[Jürgen E . Fischer]

Hi,

my pbuilder workaround for this /var/cache/pbuilder/hooks/A01qt5stripabitag:

for i in /usr/lib/*-linux-gnu/libQt5Core.so.5.10.1; do
[ -f "$i" ] && strip --remove-section=.note.ABI-tag "$i"
done


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

On 14 May 2018 at 16:24, Mattia Rizzolo  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 :-)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 14 de mayo de 2018 13:43:18 -03 Dmitry Shachnev escribió:
[snip] 
> > - We do not know the impact we create by disabling the getentropy feature.
> > And normally that stuff is related to criptography. Believe me I don't
> > want to mess with that.
> 
> If we disable it, Qt will fall back to reading /dev/urandom directly.
> 
> As I understand, it will be a bit less secure because it is vulnerable
> to file descriptor exhaustion attacks, and also a bit slower. But on the
> other hand, it is a traditional interface for getting randomness, and the
> majority of software probably still uses it.
> 
> See for details:
> 
> - https://lwn.net/Articles/606141/
> - https://git.kernel.org/linus/c6e9d6f38894798696f23c8084ca7edbf16ee895

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.

In this case our users come first, so no, we should not disable this.

-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

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

[Dmitry Shachnev]

On Mon, May 14, 2018 at 10:41:47AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> = On the Qt side:
> - With an upstream maintainer hat on: Qt 5.10 is not meant for oldstable.
> People wanting to run Qt 5.10 on those system must modify whatever is
> necessary.

OK. This is an understandable point.

> - We do not know the impact we create by disabling the getentropy feature. 
> And 
> normally that stuff is related to criptography. Believe me I don't want to 
> mess with that.

If we disable it, Qt will fall back to reading /dev/urandom directly.

As I understand, it will be a bit less secure because it is vulnerable
to file descriptor exhaustion attacks, and also a bit slower. But on the
other hand, it is a traditional interface for getting randomness, and the
majority of software probably still uses it.

See for details:

- https://lwn.net/Articles/606141/
- https://git.kernel.org/linus/c6e9d6f38894798696f23c8084ca7edbf16ee895
- https://code.qt.io/cgit/qt/qtbase.git/commit/?id=120ecc976fc3d550

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 14 de mayo de 2018 11:56:05 -03 Lisandro Damián Nicanor Pérez Meyer 
escribió:
[snip] 
> > > - We do not know the impact we create by disabling the getentropy
> > > feature.
> > > And normally that stuff is related to criptography. Believe me I don't
> > > want to mess with that.
> > 
> > That's my fear as well indeed :(
> > What do you recomend to look at to discover what uses that feature?

On the other hand: should we deprive unstable/testing users of this feature 
just for a check that it's currently running on an oldstable kernel?

I strongly think we should not.


-- 
Una sola bomba nuclear puede arruinar el resto de tu día.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 14 de mayo de 2018 11:17:37 -03 Mattia Rizzolo escribió:
> On Mon, May 14, 2018 at 10:41:47AM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > = On the reproducible side:
> > - Ben Hutchings marked #876035 as minor
> > 
> > I do not understand the rationale but he is the kernel maintainer so I'll
> > simply trust him here.
> 
> The rationale is that this is a very uncommon configuration (an i386
> with loads of RAM).
> 
> > - They are using oldstable, which is clearly something we do not intend to
> > support with Qt 5.10. With our maintainer hat on: of course if there is
> > something we can do the better, but within some limits, like what upstream
> > expects.
> 
> *we are not using oldstable*, at least not in the way I understand your
> sentence.
> That Qt 5.10 is running in regular unstable chroots.
> We are simply using a tad older kernel from second-last LTS release.

Sorry, I wasn't clear enough: yes, I was actually expecting that. Still and 
oldstable kernel, so not a target for Qt 5.10 I'm afraid.

> Consider that glibc currently requires Linux 3.2.

But Qt requires a newer kernel it seems.

> > - We do not know the impact we create by disabling the getentropy feature.
> > And normally that stuff is related to criptography. Believe me I don't
> > want to mess with that.
> 
> That's my fear as well indeed :(
> What do you recomend to look at to discover what uses that feature?

Contacting upstream, specially whoever did the code:

  developm...@qt-project.org

Might require subscription though.

-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

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

[Mattia Rizzolo]

On Mon, May 14, 2018 at 10:41:47AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> = On the reproducible side:
> - Ben Hutchings marked #876035 as minor
> 
> I do not understand the rationale but he is the kernel maintainer so I'll
> simply trust him here.

The rationale is that this is a very uncommon configuration (an i386
with loads of RAM).

> - They are using oldstable, which is clearly something we do not intend to
> support with Qt 5.10. With our maintainer hat on: of course if there is
> something we can do the better, but within some limits, like what upstream
> expects.

*we are not using oldstable*, at least not in the way I understand your
sentence.
That Qt 5.10 is running in regular unstable chroots.
We are simply using a tad older kernel from second-last LTS release.

Consider that glibc currently requires Linux 3.2.

> - We do not know the impact we create by disabling the getentropy feature. And
> normally that stuff is related to criptography. Believe me I don't want to
> mess with that.

That's my fear as well indeed :(
What do you recomend to look at to discover what uses that feature?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone!

El lunes, 14 de mayo de 2018 08:26:55 -03 Dmitry Shachnev escribió:
> Control: reassign -1 libqt5core5a 5.10.1+dfsg-5
> Control: retitle -1 libqt5core5a: Requires Linux kernel 3.17.0 or newer
> 
> On Sun, Apr 29, 2018 at 06:21:57PM -0400, Scott Kitterman wrote:
> > I've reopened this at a normal priority since it seems to reliably happen
> > in a pbuilder/cowbuilder chroot environment (I hit it again today), but
> > nowhere else.
> 
> We discussed this on #debian-reproducible today and finally found the
> reason: Qt 5.10 started using the getrandom(2) syscall which was introduced
> in Linux 3.17.
> 
> However Debian oldstable (jessie) has 3.16 and it seems some people are
> still running this as a host kernel. Mattia (CCed) says he cannot use newer
> kernels because of bug #876035.
> 
> We can build Qt without the “getentropy” feature and that would lower the
> required kernel version to 3.16:
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/minimum-linux_
> p.h#n64
> 
> Lisandro, what is your opinion on this?

Let me try to sum up the info.

= On the reproducible side:
- Ben Hutchings marked #876035 as minor

I do not understand the rationale but he is the kernel maintainer so I'll 
simply trust him here.

- They are using oldstable, which is clearly something we do not intend to 
support with Qt 5.10. With our maintainer hat on: of course if there is 
something we can do the better, but within some limits, like what upstream 
expects.

= On the Qt side:
- With an upstream maintainer hat on: Qt 5.10 is not meant for oldstable. 
People wanting to run Qt 5.10 on those system must modify whatever is 
necessary.

- We do not know the impact we create by disabling the getentropy feature. And 
normally that stuff is related to criptography. Believe me I don't want to 
mess with that.

So in my point of view, without any further data, it's a non-go.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

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

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 libqt5core5a 5.10.1+dfsg-5
Bug #895718 [python-pyqt5] python-pyqt5: import PyQt5.QtCore fails
Bug reassigned from package 'python-pyqt5' to 'libqt5core5a'.
No longer marked as found in versions pyqt5/5.9.2+dfsg-1.
Ignoring request to alter fixed versions of bug #895718 to the same values 
previously set
Bug #895718 [libqt5core5a] python-pyqt5: import PyQt5.QtCore fails
Marked as found in versions qtbase-opensource-src/5.10.1+dfsg-5.
> retitle -1 libqt5core5a: Requires Linux kernel 3.17.0 or newer
Bug #895718 [libqt5core5a] python-pyqt5: import PyQt5.QtCore fails
Changed Bug title to 'libqt5core5a: Requires Linux kernel 3.17.0 or newer' from 
'python-pyqt5: import PyQt5.QtCore fails'.

-- 
895718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895718
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems