[MIR] pyqt5

[Scott Kitterman]

Required in Main as a build-dep of qscintilla2 with Qt5 support and is consistent with the overall goal of heading for Qt5 everywhere.

Robustly maintained in Debian and in Ubuntu by both the Kubuntu team and Canonical Ubuntu Engineering.

Meets all requirements of https://wiki.ubuntu.com/UbuntuMainInclusionRequirements

No history of security issues.

Essentially a new version of python-qt4, which is already in Main..

[Adam Conrad (adconrad)]

Duping the other two MIRs to this one, as they're only needed as deps of pyqt5.

[Dmitry Shachnev (mitya57)]

This will also require keeping qtwebkit-opensource-src in main (and not
demoting it as planned earlier).

[Adam Conrad (adconrad)]

23:40 < infinity> Anyhow, there's no pyqt4 webkit plugin, so maybe disabling the pyqt5 one (or making it work with oxide?) would work...

[Dmitry Shachnev (mitya57)]

There *is* a pyqt4 webkit module (it's just not split out), and the pyqt5 webkit module is important for me (retext uses it).

[Adam Conrad (adconrad)]

Oh, indeed, I had assumed that qt4 webkit wasn't in main but, look at that, we currently have qt4webkit, qt5webkit, *and* oxide-qt in main and even in ubuntu-desktop. Well done, us.

So, I can see why there'd be an urge to not make this situation any worse. Maybe the path of least resistance at least for this MIR would be to back out the qt5 changes from qscintilla2 and go back to the drawing board for 14.10.

[Scott Kitterman (kitterman)]

Can we just copy it to backports and then forward copy it when "U" opens if we
have to back it out? We'll want to be able to build all of the Qt5 based KDE
products on trusty as they are released over the next year, so we'll need this
one way or another and for infrastructure like this, I'd rather it's in the
archive than some random PPA.

In the meantime, until someone has done the work to get qt5webkit out of main,
can we not give up on this as it's already there, so qscintillla2 isn't
currently making it worse.

[Jamie Strandboge (jdstrand)]

FYI, we are doing the work to get qt5webkit out of main-- we have developed oxide and anything in main that needs a web engine should use it. Upstream has abandoned qt5webkit for qtwebengine and qt5webkit is falling out of maintenance soon (though to be fair, security updates came in the form of new snapshots and this is expected to continue with qtwebengine, which is one reason why we have developed oxide). I realize there can be ridiculously intense dependency chains with KDE, but much of Kubuntu is not in main and I don't see why we should continue having qt5webkit in main (or qtwebengine when it hits).

That said, I doubt all the work to get qt5webkit (or webkit-gtk) out for 14.04-- we'll probably have to add a release note or something this time that it isn't supported.

[Scott Kitterman (kitterman)]

On Wednesday, April 02, 2014 14:55:48 Jamie Strandboge <email address hidden>
wrote:
> That said, I doubt all the work to get qt5webkit (or webkit-gtk) out for
> 14.04-- we'll probably have to add a release note or something this time
> that it isn't supported.

On that basis, would you be OK with promoting pyqt5, qtserialport-opensource-
src, and qtx11extras-opensource-src for 14.04?

[Seth Arnold (seth-arnold)]

I'd appreciate another look at the package hardening; the pyqt5 build logs show that fortify is requested for 584 compilations (give or take grep mistakes), the stack protector for 584 compilations, PIE and pie for 72 to 74 compilations, and there's 790-ish compilations total. But hardening-check reports of the object files:

- 2 objects have Fortify Source functions, 25 do not, 29 not needed
- 2 executables are not compiled PIE
- 3 objects have stack protection, 53 do not.

I would like to know why the 25 object files don't have Fortify source turned on, and why 53 of 56 object files didn't get stack protection turned on.

Thanks

[Matthias Klose (doko)]

Am 04.04.2014 09:07, schrieb Seth Arnold:
> I'd appreciate another look at the package hardening; the pyqt5 build
> logs show that fortify is requested for 584 compilations (give or take
> grep mistakes), the stack protector for 584 compilations, PIE and pie
> for 72 to 74 compilations, and there's 790-ish compilations total. But
> hardening-check reports of the object files:
>
> - 2 objects have Fortify Source functions, 25 do not, 29 not needed
> - 2 executables are not compiled PIE
> - 3 objects have stack protection, 53 do not.
>
> I would like to know why the 25 object files don't have Fortify source
> turned on, and why 53 of 56 object files didn't get stack protection
> turned on.

I didn't look at the build logs, however if you just check the binary loadable
extensions (.so files) you get many false positives. Seen with other extension
modules as well. So you have to analyze the build log.

[Dmitry Shachnev (mitya57)]

On Fri, Apr 4, 2014 at 11:07 AM, Seth Arnold wrote:
> - 2 executables are not compiled PIE

According to lintian, this is because of fopen(). I can patch it to
use fopen64() if needed.

> I would like to know why the 25 object files don't have Fortify source
> turned on, and why 53 of 56 object files didn't get stack protection
> turned on.

AFAICS, all g++ calls have correct hardening flags. I think Matthias
is right, and these are false positives.

[Seth Arnold (seth-arnold)]

doko, mitya57, thanks for double-checking the hardening checks. It really would be nice to get PIE for the executables, please do make the change if you can. (I believe we're strongly interested in turning on PIE for all executables for Trustry+1, perhaps just for !x86, so getting this fixed will have lasting benefits beyond just this release.)

[Seth Arnold (seth-arnold)]

I reviewed pyqt5 version 5.2.1+dfsg-1ubuntu1 as checked into trusty. This
is not a full security audit, but only a quick gauge of maintainability.

- pyqt5 provides python bindings for the qt library
- Build-Depends: dpkg-dev, debhelper, fdupes, libdbus-1-dev,
  libglib2.0-dev, libgstreamer0.10-dev, libgstreamer-plugins-base0.10-dev,
  libicu-dev, libpulse-dev, libqt5opengl5-dev, libqt5sensors5-dev,
  libqt5serialport5-dev, libqt5svg5-dev, libqt5webkit5-dev,
  libqt5xmlpatterns5-dev, libqt5x11extras5-dev, libsqlite3-dev,
  libudev-dev, libxml2-dev, libxslt1-dev, python3-all-dbg,
  python3-all-dev, python3-dbus, python3-dbus-dbg, python3-sip-dbg,
  python3-sip-dev python3-sphinx, python-dbus-dev, qtdeclarative5-dev,
  qtmultimedia5-dev, qtlocation5-dev, qttools5-dev
- No cryptography
- Does not itself do networking
- Does not itself daemonize
- postinst and prerm cache and remove cached binaries
- No initscripts
- No dbus services
- No setuid executables
- Three binaries in /usr/bin/
- No sudo fragments
- No udev rules
- No test suite
- No cronjobs
- Some warnings in build logs, probably not a concern

- Subprocesses rarely spawned, looked careful
- Memory management looked so-so; most failed allocations would crash
  quickly, however
- Files frequently manipulated, parameters supplied by callers
- Logging looked safe
- Environment handling looked safe
- No privileged code portions
- No cryptography
- Does not itself do networking
- No temporary files
- Does use WebKit. See discussion in this bug for details. The security
  team cannot support any webkit packages except oxide.
- Does not appear to use qtjsbackend directly
- Clean cppcheck
- No polkit

The code looked pretty clean, if complicated; most of the complication is
due to the problem being solved, though.

Security team ACK for promoting pyqt5 to main -- so long as all stakeholders
recognize that all webkit packages are entirely unsupported.

[Seth Arnold (seth-arnold)]

I reviewed qtserialport-opensource-src version 5.2.1-1 as checked into
trusty. This should not be considered a full security audit but rather a
quick gauge of maintainability.

- This package provides Qt bindings for using serial ports
- Build-Depends: debhelper, libudev-dev, pkg-kde-tools, qtbase5-dev,
  libqt5sql5-sqlite, qttools5-dev-tools
- Does not use cryptography
- Does not use networking
- Does not daemonize
- postinst and postrm simply run ldconfig
- No initscripts
- No dbus services
- No setuid executables
- No sudo fragments
- No udev rules
- No cron jobs
- No test suite
- Build logs pretty clean, most warnings are documentation issues

- Spawned subprocesses used to keep executables small and run from
  libraries instead; no explicit argument handling
- Memory management looked careful
- File IO is restricted to serial devices and lock files
- Logging looked careful
- No environment variables
- No privileged portions of code
- No cryptography
- No networking
- No temporary files, though lock files may be stored in /tmp as a last
  resort
- No WebKit
- No Javascript
- No polkit
- Clean cppcheck

This code looked like usual-enough higher-level wrappers around an older
and somewhat crufty interface. Not all features are implemented which
might be surprising, but not really a security issue.

Security team ACK for promoting qtserialport-opensource-src to main.

[Seth Arnold (seth-arnold)]

There's so little code to qtx11extras-opensource-src that I didn't fill out the usual review form; it all looked pretty straightforward.

Security team ACK for qtx11extras-opensource-src.

Thanks

[Dmitry Shachnev (mitya57)]

Am 04.04.2014 14:16 schrieb "Dmitry Shachnev" <email address hidden>:
> According to lintian, this is because of fopen(). I can patch it to
> use fopen64() if needed.

I was wrong, fopen() relates to large file support, not PIE.

What do I need to add for PIE support? Is that the same as -fPIC which is
already in compiler flags?

[Adam Conrad (adconrad)]

@mitya57, you're looking for -fPIE, but keep in mind that can only be used for executables (or objects statically linked into executables), not for libraries.

Anyhow, based on the above ACKs, and my own quick review, I'm going to promote these three and close the bug.

[Adam Conrad (adconrad)]

Override component to main
qtserialport-opensource-src 5.2.1-1 in trusty: universe/misc -> main
qtx11extras-opensource-src 5.2.1-1 in trusty: universe/misc -> main
Override [y|N]? y
2 publications overridden.
Override component to main
pyqt5 5.2.1+dfsg-1ubuntu1 in trusty: universe/misc -> main
Override [y|N]? y
1 publication overridden.
Override component to main
libqt5serialport5 5.2.1-1 in trusty amd64: universe/libs/optional/100% -> main
libqt5serialport5 5.2.1-1 in trusty arm64: universe/libs/optional/100% -> main
libqt5serialport5 5.2.1-1 in trusty armhf: universe/libs/optional/100% -> main
libqt5serialport5 5.2.1-1 in trusty i386: universe/libs/optional/100% -> main
libqt5serialport5 5.2.1-1 in trusty powerpc: universe/libs/optional/100% -> main
libqt5serialport5 5.2.1-1 in trusty ppc64el: universe/libs/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty amd64: universe/libdevel/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty arm64: universe/libdevel/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty armhf: universe/libdevel/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty i386: universe/libdevel/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty powerpc: universe/libdevel/optional/100% -> main
libqt5serialport5-dev 5.2.1-1 in trusty ppc64el: universe/libdevel/optional/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty amd64: universe/debug/extra/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty arm64: universe/debug/extra/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty armhf: universe/debug/extra/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty i386: universe/debug/extra/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty powerpc: universe/debug/extra/100% -> main
qtserialport5-dbg 5.2.1-1 in trusty ppc64el: universe/debug/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty amd64: universe/doc/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty arm64: universe/doc/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty armhf: universe/doc/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty i386: universe/doc/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty powerpc: universe/doc/extra/100% -> main
qtserialport5-doc 5.2.1-1 in trusty ppc64el: universe/doc/extra/100% -> main
libqt5x11extras5 5.2.1-1 in trusty amd64: universe/libs/optional/100% -> main
libqt5x11extras5 5.2.1-1 in trusty arm64: universe/libs/optional/100% -> main
libqt5x11extras5 5.2.1-1 in trusty armhf: universe/libs/optional/100% -> main
libqt5x11extras5 5.2.1-1 in trusty i386: universe/libs/optional/100% -> main
libqt5x11extras5 5.2.1-1 in trusty powerpc: universe/libs/optional/100% -> main
libqt5x11extras5 5.2.1-1 in trusty ppc64el: universe/libs/optional/100% -> main
libqt5x11extras5-dev 5.2.1-1 in trusty amd64: universe/libdevel/optional/100% -> main
libqt5x11extras5-dev 5.2.1-1 in trusty arm64: universe/libdevel/optional/100% -> main
libqt5x11extras5-dev 5.2.1-1 in trusty armhf: universe/libdevel/optional/100% -> main
libqt5x11extras5-dev 5.2.1-1 in trusty i386: universe/libdevel/optional/100% -> main
libqt5x11extras5-dev 5.2.1-1 in trusty powerpc: universe/libdevel/optional/100% -> main
libqt5x11ext...