Univention Bugzilla – Bug 43406
php7.0: Multiple issues (4.1)
Last modified: 2017-03-16 14:43:24 CET
Upstream php 7.0.14 fixes at least the following security issues: * NULL Pointer Dereference in WDDX Packet Deserialization with PDORow (CVE-2016-9934) * Invalid read when wddx decodes empty boolean element). (CVE-2016-9935) * Use After Free Vulnerability in unserialize() (CVE-2016-9936)
7.0.14-2 imported and built in scope php7.
OK: php 7.0.14 imported and build OK~: referenced CVEs are fixed. php deb package changelog does not reference all of them, but the code fixing CVE-2016-9936 is present reopen: It is currently unclear to me how php7 updates can be tracked by customers, e.g. on errata.univention.de. Releasing this security update is basically the announce of the php7 scope. On 2017-01-19 php 7.0.15 was released, fixing further issues regarding unserialize(). Should we update to that version?
> OK~: referenced CVEs are fixed. php deb package changelog does not reference all of them, but the code fixing CVE-2016-9936 is present Yes, that's the "fun" part of security tracking. If imported 7.0.15-1 from sid and built it as 7.0.15-1.6.201702011249. I've also built tidy-html5, since libtidy-dev is a build-dependency of php7.0 (to build php7.0-tidy).
OK: php7.0 7.0.15-1 available in php7 scope OK: Installable by docker container update job, tested with cronjob call: /usr/share/univention-updater/univention-actualise --dist-upgrade --silent Verified
With regard to the UCS 4.2 update, I think we have to adjust the versioning for this erratum to stay below the UCS 4.2 binary package version: I thing the new versioning scheme for UCS 4.2 will currently result in this situation: user@host:~$ \ ucs41_version="7.0.11-1.3.201610061254" \ errata41_version="7.0.15-1.7.201702011654" \ ucs42_version="7.0.15-1A~4.2.0.201702010918"; \ dpkg --compare-versions "$errata41_version" gt "$ucs41_version" && \ dpkg --compare-versions "$errata41_version" lt "$ucs42_version" && \ echo ok || echo fail fail Janek and me proposed this new errata-versioning "freeze+suffix" scheme: errata41_version="${ucs41_version}-errata4.1-4-$(buildtimestamp)" If nobody objects and suggests a better solution then I would go for that.
Ok, the "-" causes undesired behaviour in this case: user@host:~$ \ ucs41_version="7.0.11-1.3.201610061254" \ fictional_errata41_version="7.0.11-0-errata4.1-4.201702011654"; \ dpkg --compare-versions "$fictional_errata41_version" gt "$ucs41_version" && \ echo ok || echo fail ok Philipp proposed to adopt the Debian scheme +debXuY, where X: Debian Release Version Y: Incremented per package security update That "Y" would require additional scripting to track per package increments (again). So, two alternatives: A) with timestamp: errata41_version="${ucs41_version}+errata4.1.4.$(buildtimestamp)" B) with increment: errata41_version="${ucs41_version}+errata4.1.4.$(++$last_increment)" where last_increment is incremented in some suitable fashion (e.g. at least per errata scope) The latter one is a bit more complex scripting logic but might easier to decipher for the customer/supporter. Opinions?
Ok, I've tried to rebuilt the pacakges like this: ## tidy-html5: Note the "1:" epoch needs to be included! errata_scope=php7 released_version="1:5.2.0-2.2.201702011653"; \ build-package-ng -s "$errata_scope" -P ucs -r 4.1-0-0 --no-pbuilder-update \ -p tidy-html5 \ -v "${released_version}+${errata_scope//-/.}.$(date +%Y%m%d%H%M)" ## php7.0 errata_scope=php7 released_version="7.0.11-1.3.201610061254"; \ build-package-ng -s "$errata_scope" -P ucs -r 4.1-0-0 --no-pbuilder-update \ -p php7.0 \ -v "${released_version}+${errata_scope//-/.}.$(date +%Y%m%d%H%M)" But php7.0 fails at the end of the built with: ============================================================================= dpkg-source -b php7.0-7.0.15 dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../php7.0_7.0.11.orig.tar.{bz2,gz,lzma,xz} dpkg-buildpackage: error: dpkg-source -b php7.0-7.0.15 gave error exit status 255 ============================================================================= Back to the drawing board.
4.1 build-package-ng -r 4.1 -p php7 -s php7 4.2 build-package-ng -r 4.2 -p php7 -s php7 -b .
$ ls ucs_4.[12]-0-php7/source/php7.0_7.0.15*.dsc ucs_4.1-0-php7/source/php7.0_7.0.15-1.7.201702011654.dsc ucs_4.2-0-php7/source/php7.0_7.0.15-1A~4.2.0.201702030645.dsc $ build-package-ng -p php7.0 -s php7 -r 4.1-0-0 $ build-package-ng -p php7.0 -s php7 -r 4.2-0-0 -b . Please note that "-b ." must be given always from now on until the time, where UCS-4+ has a newer upstream version than ucs_4.1-0-php7. repo-ng can't know until Bug #3429 is resolved. Keep that in mind for security updates in UCS-4.2! Package: php7.0 Version: 7.0.15-1.A~4.2.0.201702101204 Branch: ucs_4.2-0 Scope: php7 $ ~phahn/bin/deb-ver-comp 7.0.11-1.3.201610061254 7.0.15-1.7.201702011654 7.0.15-1.A~4.2.0.201702101204 Sort as given 7.0.11-1.3.201610061254 7.0.15-1.7.201702011654 7.0.15-1.A~4.2.0.201702101204 Sort with Debian-update-version stripped as build-package-ng 7.0.11-1.3.201610061254 7.0.15-1.7.201702011654 7.0.15-1.A~4.2.0.201702101204 FYI: You can skip the default options "-P ucs --no-pbuilder-update"
> 4.2 > build-package-ng -r 4.2 -p php7 -s php7 -b . That's the well known concept of "den Debian-Suffix abschneiden und durch den neues UCS-Suffix mit Punkt davor anhängen" already documented here: https://hutten.knut.univention.de/mediawiki/index.php/Entwicklungsumgebung#Ausnahmen But the goal is a concept that works when we update to 7.0.16-1 in errata4.1-4. That's why Bug 43436 blocks. Anyway. Let's postpone that question for now.
> That's why Bug 43436 blocks. Wrong bug, I meant Bug 43488.
OK: php7.0 7.0.15-1 available in php7 scope, version smaller than in ucs4.2 OK: Installable by docker container update job, tested with cronjob call: /usr/share/univention-updater/univention-actualise --dist-upgrade --silent Verified
Update has been published