Re: more missing DLAs on the website

[Sylvain Beucler]

Hi,

On 02/04/2019 10:59, Holger Levsen wrote:
> On Mon, Apr 01, 2019 at 08:51:00PM +0200, Sylvain Beucler wrote:
>> I wondered whether we needed translations at:
> because:
> [...]
> - translations

OK so I guess we need DLA translations ;)
I was wondered whether actual users asked for them, but let's assume so.


> - https://www.debian.org/lts/security/2019/dla-1735 is a much better URL
>   than https://lists.debian.org/debian-lts-announce/2019/03/msg02342.html for 
> DLA-1735
> - much better means easier to refer/find after the fact

OK though I personally would either check the index page (www or lists)
to look-up by name, or
https://security-tracker.debian.org/tracker/DLA--1 to look-up by ID.


>
>> I would be willing to help here, however don't want to step on anybodies
>> toes...
> \o/ 
>
> Thanks for this offer! I don't think anybody would complain if you do this
> work... quite the contrary :)
>
>> Has anybody considered writing a script (assuming such a thing doesn't
>> already exist) that will somehow fetch the DLA from the mailing list
>> archive (given the URL), extract the contents from the ...
>> tags and then then calls parse-dla.pl on the result?
> Such a script exists, see the top of 
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/47

Cool, though we still have the parse-dla limitations, i.e. the results
needs to be manually checked every time.

It seems implicit given my involvement in the discussions and fixes for
the past weeks, but I'm willing to help improve this too :)

Cheers!
Sylvain

Re: more missing DLAs on the website

[Sylvain Beucler]

Hi,

On 02/04/2019 12:09, Holger Levsen wrote:
> On Tue, Apr 02, 2019 at 11:52:58AM +0200, Sylvain Beucler wrote:
>> OK so I guess we need DLA translations ;)
>> I was wondered whether actual users asked for them, but let's assume so.
> you might not be aware, but:
>
> ~/Projects/debian-www/webwml$ for i in english french russian danish japanese 
> ; do echo -n "$i: " ; find |grep -i dla|grep -c $i ; done
> english: 3574
> french: 703
> russian: 424
> danish: 73
> japanese: 108

That's precisely what I'm worried about: we're taking resources from
translators (and for quite boring texts), so I hope users do care about it.
I don't see security advisory translations in other distros, so we
better be confident this is worth the effort - including our effort to
double-publish DLAs at the website :)

>>> https://salsa.debian.org/webmaster-team/webwml/merge_requests/47
>> Cool, though we still have the parse-dla limitations, i.e. the results
>> needs to be manually checked every time.
> yup. and besides #859123 there is also #922246: "www/lts: if DLA-1234-1 and 
> DLA-1234-2 exist, only that last one shows up in indexes"
>
>> It seems implicit given my involvement in the discussions and fixes for
>> the past weeks, but I'm willing to help improve this too :)
> yay. please just go ahead. ;)

One issue is that I proposed to simplify the handling of parse-dla to
make is more robust (grab DLA description as a  block instead of
the fragile regexp-based HTMLization)
 - but no involved parties answer.
I'll let some time pass, then I guess I'll make the change and see who
complains :P

Ideally we could then cron this out as Markus suggested.

- Sylvain

Re: more missing DLAs on the website

[Sylvain Beucler]

Hi,

On Tue, Apr 02, 2019 at 12:55:31PM +0200, Markus Koschany wrote:
> Am 02.04.19 um 12:39 schrieb Sylvain Beucler:
> > Ideally we could then cron this out as Markus suggested.
> 
> So far I had no problems with the parse script. I just download the html
> file from the DLA announcement manually and then I use the script. The
> idea to use a  block would certainly simplify the parsing though.

The script can be used directly on the DLA text/mail, btw (it's not
based on the list archive, no need to download).

Also I remember fixing one of your DLAs before a webwml admin made an
angry commit, the script is sometimes silently bogus.


On Tue, Apr 02, 2019 at 11:57:43AM +, Holger Levsen wrote:
> On Tue, Apr 02, 2019 at 12:55:31PM +0200, Markus Koschany wrote:
> > First of all, thank you for your improvements on the parse script. I
> > share your concerns about the usefulness of translating the security
> > advisories. 
> 
> just because you/we understand English doesnt mean the whole world does.

I'm sure everybody understands the importance of translation, I did
quite a lot of i18n myself.  Just wondering its usefulness for DLAs.

But I figured that translating the DLAs is a matter of priority for
the translators, not us, so let's do the i18n on our side, and let the
translators prioritize :)


> > I agree without the translations we could also consider to
> > link to the mail archive.
> 
> and then the mail archive software changes one day, and the links break.
> 
> i agree there is a little overhead currently, but a.) there are benefits
> in doing so and b.) we can make the overhead go away.

I'll recap the rationale points in the Development wiki page in a few
days unless somebody beats me to it.

Cheers!
Sylvain

[SECURITY] [DLA 1737-1] pdns security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: pdns
Version: 3.4.1-4+deb8u9
CVE ID : CVE-2019-3871
Debian Bug : 924966

A vulnerability was found in PowerDNS Authoritative Server before
4.0.7 and before 4.1.7. An insufficient validation of data coming from
the user when building a HTTP request from a DNS query in the HTTP
Connector of the Remote backend, allowing a remote user to cause a
denial of service by making the server connect to an invalid endpoint,
or possibly information disclosure by making the server connect to an
internal endpoint and somehow extracting meaningful information about
the response.

Only installations using the pdns-backend-remote package are affected.

For Debian 8 "Jessie", this problem has been fixed in version
3.4.1-4+deb8u9.

We recommend that you upgrade your pdns packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlyeKOoACgkQj/HLbo2J
BZ/wWwgAiWPZFOh+OXBitp36ySi4OnkDolH9vz1iOPqk6zF8LU8M4PHrbmD2ORjr
pT/PrLHlTkEdPAZeD4vdDEO71CSwIDCCm5j6JAYrBhxTt5waFwFm0VBEUb9cl6Z2
lTXyTiYzXRbnDway8Nb7wS5JHOVbTDf5vQ8ZnP7c3dTvhP4khFoPpTG7W4V4t/Kq
T5X9yvnnmvM6n4nfzX8OdsTp3MPMw2uNECeYlksZKg/ER25bVTBLYWqPAodpiOmS
uQDgzSPqv5MkprxZy8sZXw4XrxGlgi/yMJzh5he9UbPBKijrJXV/jfBBkI4uucJZ
VgDmhGWd4iTdqR8tLFERHmAjItYWVQ==
=Hhny
-END PGP SIGNATURE-

Re: DLAs in the website: some updates and issues

[Sylvain Beucler]

Hi,

On 18/03/2019 15:56, Sylvain Beucler wrote:
> On Thu, Mar 07, 2019 at 08:02:18PM +0100, Laura Arjona Reina wrote:
>> El 5/3/19 a las 16:07, Markus Koschany escribió:
>>> thank your for your work on our website. Ideally we would like to make
>>> the whole process fully automatic without the need for any manual
>>> interaction. 
>> This is being discussed in #859123: automate import of DLAs and DSAs in
>> www.debian.org
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123
>>
>> In particular, I think this message from Lev Lamberov is relevant:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123#20
>>
>>> Can you tell us more about the current work flow of our DSA
>>> announcements on the front page? 
>> DSAs are manually imported by a web team member or a security team
>> member, using the parse_advisory.pl script.
>>
>>> Does someone from the webteam reviews
>>> the generation by hand? 
>> Usually yes, but also, as it is noted in Lev's message, I think the
>> format of DSA is more standard.
> I had a look at parse-dla.pl / parse-advisory.pl, and let's face it:
> it's a bunch of ad-hoc regexps that happen to work. Most of the times.
>
> I couldn't find a satisfying way to fix the trailing 
> recurring bug.

FYI I tracked down the difference ("For the (old)stable" vs. "For Debian
X") and adapted the regexp.
This confirms DLA formatting is on par with DSA's, the conversion script
is just fragile.


>>> I'm sure we can improve the current parse-dla.pl
>>> script and fix those markup bugs. We also thought about downloading the
>>> announcements from  https://lists.debian.org/debian-lts-announce/ and
>>> then create the DLA on the web page automatically. Is this a viable plan?
>>>
>> I don't know.
>>
>> I guess that if the security team does not that already it's probably
>> because of a reason (or maybe because nobody in the web team could find
>> the time+skills+motivation needed to make it possible...).
> So the core issue is taking a text mail and automagically generate a
> HTML equivalent.
>
> Lev suggested 4 months ago that LTS and DebSec work on a common
> mark-up format.  We could attempt to switch to MarkDown, but from
> experience it breaks easily, especially wrt newlines.
>
> Alternatively, a simple answer would be to keep the headers parsing
> (Package/Version/CVE ID/Debian Bug) but import the free-form
> description text verbatim as a monospace block (such as ).
> i.e. stop coping with ul/li, just auto-link https://... bits.
>
> I don't suggest merely linking the list archives, since AFAIU there is
> demand for advisories translations (if there isn't, though, a link
> would be enough IMHO).
>
> What do you think?
>
> Cheers!
> Sylvain

Accepted pdns 3.4.1-4+deb8u9 (source amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 29 Mar 2019 13:27:30 +
Source: pdns
Binary: pdns-server pdns-server-dbg pdns-backend-pipe pdns-backend-ldap 
pdns-backend-geo pdns-backend-mysql pdns-backend-pgsql pdns-backend-sqlite3 
pdns-backend-lua pdns-backend-lmdb pdns-backend-remote pdns-backend-mydns
Architecture: source amd64
Version: 3.4.1-4+deb8u9
Distribution: jessie-security
Urgency: high
Maintainer: Debian PowerDNS Maintainers 

Changed-By: Sylvain Beucler 
Description:
 pdns-backend-geo - geo backend for PowerDNS
 pdns-backend-ldap - LDAP backend for PowerDNS
 pdns-backend-lmdb - lmdb backend for PowerDNS
 pdns-backend-lua - Lua backend for PowerDNS
 pdns-backend-mydns - MyDNS compatibility backend for PowerDNS
 pdns-backend-mysql - generic MySQL backend for PowerDNS
 pdns-backend-pgsql - generic PostgreSQL backend for PowerDNS
 pdns-backend-pipe - pipe/coprocess backend for PowerDNS
 pdns-backend-remote - remote backend for PowerDNS
 pdns-backend-sqlite3 - sqlite 3 backend for PowerDNS
 pdns-server - extremely powerful and versatile nameserver
 pdns-server-dbg - debugging symbols for PowerDNS
Changes:
 pdns (3.4.1-4+deb8u9) jessie-security; urgency=high
 .
   * Non-maintainer upload by the Debian LTS team.
   * Fix CVE-2019-3871, rebasing upstream's fix for 4.0.6: an
 insufficient validation of data coming from the user when building
 a HTTP request from a DNS query in the HTTP Connector of the
 Remote backend, allowing a remote user to cause a denial of
 service by making the server connect to an invalid endpoint, or
 possibly information disclosure by making the server connect to an
 internal endpoint and somehow extracting meaningful information
 about the response.
Checksums-Sha1:
 fe9ba7366c6f0d0fb210e3d2f05d18a7a314aaca 2812 pdns_3.4.1-4+deb8u9.dsc
 fd9754bb66e4ad7434b1dd0ff21fb48de6578967 53628 
pdns_3.4.1-4+deb8u9.debian.tar.xz
 f09e38dbdf09c1c3b838458a51d0fc7b252a4453 1598900 
pdns-server_3.4.1-4+deb8u9_amd64.deb
 2ebdb50c9ccdf71ed065b3d00d0ec16065b599e7 33114800 
pdns-server-dbg_3.4.1-4+deb8u9_amd64.deb
 43effb35157afb74ae9b346a36dcaebdfb63f7da 53408 
pdns-backend-pipe_3.4.1-4+deb8u9_amd64.deb
 7af6fe82003b769513b0efc9b045dbc239ff2645 256406 
pdns-backend-ldap_3.4.1-4+deb8u9_amd64.deb
 0226bd09a00ca6559344b843745cafb028a62f8d 63242 
pdns-backend-geo_3.4.1-4+deb8u9_amd64.deb
 9b55d79e75ad973158231aff55d94979566c71c0 45748 
pdns-backend-mysql_3.4.1-4+deb8u9_amd64.deb
 9c404ade4b404d9afa5d486e8a53dfcdc02a4c6a 46062 
pdns-backend-pgsql_3.4.1-4+deb8u9_amd64.deb
 ac426bf45a27ededfe5f9d84b67422a1c3641e1a 38492 
pdns-backend-sqlite3_3.4.1-4+deb8u9_amd64.deb
 3ba52dd7a891ea2b732b5d5848bf56e659af54cf 60334 
pdns-backend-lua_3.4.1-4+deb8u9_amd64.deb
 2a8962ac6d84db864fd1bcc6eea8dfd0554e579e 41524 
pdns-backend-lmdb_3.4.1-4+deb8u9_amd64.deb
 699be6bec674104697a544af35fb994ffaf77bde 147278 
pdns-backend-remote_3.4.1-4+deb8u9_amd64.deb
 b95e23c9efb3d8f1010f4dcc679bbda9cb6594fc 41098 
pdns-backend-mydns_3.4.1-4+deb8u9_amd64.deb
Checksums-Sha256:
 675cc51be4a552cf922953b5071ded8f042ec7b4fe6cf9328d98695f2412440c 2812 
pdns_3.4.1-4+deb8u9.dsc
 375996e723e17d394bef6b31c9798545a3284345019b947077dd78902b30ab5d 53628 
pdns_3.4.1-4+deb8u9.debian.tar.xz
 22cc64adbddfb491224926f59da151a7f6dcd8ea82b3e08d495f8d2a63576e79 1598900 
pdns-server_3.4.1-4+deb8u9_amd64.deb
 b9c1c8ad290f7ee72a15a3fbd436e6de0fdba3bbe88ac7d71d53037ab3350e6f 33114800 
pdns-server-dbg_3.4.1-4+deb8u9_amd64.deb
 7f13d13dfaf407dcf647557dd4c5046ee3130f7952f2bbf2e061193a9a8694c7 53408 
pdns-backend-pipe_3.4.1-4+deb8u9_amd64.deb
 97c7909116151f46207a2f68cf88ad0a040d81e37709a6cd31296bf37df07d62 256406 
pdns-backend-ldap_3.4.1-4+deb8u9_amd64.deb
 4c29dc409b17ea36366ddf445525992839ce776154551a25d91f7d4ea412a476 63242 
pdns-backend-geo_3.4.1-4+deb8u9_amd64.deb
 86135f26ed34af0f5ecff547a412d2d58e4e07f248606019d7874acbebb43c49 45748 
pdns-backend-mysql_3.4.1-4+deb8u9_amd64.deb
 cc19edd06d99a86baa1cea150c64dd35148953f33dbac3d1be813b8ba29cc500 46062 
pdns-backend-pgsql_3.4.1-4+deb8u9_amd64.deb
 07fb683cd5bf1eb794f3c94a32cbdc82304b165738719519e83959510ac02444 38492 
pdns-backend-sqlite3_3.4.1-4+deb8u9_amd64.deb
 7bd24640d6dfc22182f0a1aa9b9b43bd65d206da706a1beee891c13ac0faf61f 60334 
pdns-backend-lua_3.4.1-4+deb8u9_amd64.deb
 5db00dc3418b2e816c75bc3ecc4f0fc0459ca73f1a54cd07f809f9c450c2e9cb 41524 
pdns-backend-lmdb_3.4.1-4+deb8u9_amd64.deb
 52a2ecc13492e5af24de4ffc20b1614387bb2f2b8bf6799240969e1da255a6ee 147278 
pdns-backend-remote_3.4.1-4+deb8u9_amd64.deb
 870f4c06142288f3246ca1f5e94ddefbd70234a5733ca37d8fc8b1e047ec0ba0 41098 
pdns-backend-mydns_3.4.1-4+deb8u9_amd64.deb
Files:
 552d4c7af012e548374a6c269fa74a03 2812 net extra pdns_3.4.1-4+deb8u9.dsc
 6c0d0b44deb1a91457b2ca434b6939af 53628 net extra 
pdns_3.4.1-4+deb8u9.debian.tar.xz
 cb3c9bcc9ccbfd9f59d9c3dc17fe1216 1598900 net extra 
pdns-server_3.4.1-4+deb8u9_amd64.deb
 3700a63717c474a9fc90d0e3fed2f204 33114800 debug extra 
pdns-server-dbg_3.4.1

Re: ghostscript testing

[Sylvain Beucler]

Hi,

On 27/03/2019 00:00, Markus Koschany wrote:
> Am 26.03.19 um 15:55 schrieb Sylvain Beucler:
> [...]
>> Markus, I read in the archives that you backported fixes in earlier
>> security uploads - any other tip? :)
> I did all the testing myself by setting up a Jessie environment and then
> I tested with the POCs and the command line tools to spot any
> regressions. I could reproduce all issues, so at one point I was
> confident the problem at hand was solved. Without an extensive test
> suite or a reproducer this is quite challenging. Since we made the
> decision to follow new upstream releases, we just have to make sure that
> reverse-dependencies keep working. So I would do some smoke testing and
> verify that the reported problem is fixed.
Thanks for confirming I didn't miss anything.

Waiting for 9.27 then.

Cheers!
Sylvain

Re: ghostscript testing

[Sylvain Beucler]

Hi,

On 25/03/2019 16:13, Sylvain Beucler wrote:
> On 25/03/2019 16:11, Sylvain Beucler wrote:
>> Hi,
>>
>> I prepared an update for ghostscript.
>> https://people.debian.org/~beuc/lts/ghostscript/
>>
>> Even if we recently rebased to the latest upstream in jessie, the
>> upstream patches did not apply cleanly and I did my best to replicate
>> the changes.
>> Note: we ship a 9.26*a* version which upstream does not provide publicly
>> AFAICS (plus it was dfsg-modified), but the conflicts are due to
>> upstream's master branch.
>>
>> Upstream seems to keep their test suite private. The documentation
>> reference a "smoke.ps" file that was removed years ago, and even then it
>> depended on PS files that I cannot locate.
>> https://www.ghostscript.com/doc/9.26/Release.htm#Testing
>>
>> Is there a known test suite for ghostscript?
>> (or maybe we should just wait for some 9.26
> [hit a shortcut by accident]
>
> (or maybe we should just wait for some 9.26b and backport it?)

Emilio kindly provided some info in private.

Debian Security intends to ship 9.27 when it comes out, so I'll probably
follow suite, given my limited understanding of PostScript and the lack
of test suite.
Emilio got the info privately as the previous uploader.
In the spirit of our continued transparency I would recommend to make
recaps such as this one on the list, because browsing archives is
usually informative and time-saving :)

The previous ghostscript upload also benefited from private real-life
testing on a cluster that was since then upgraded to squeeze, so
ghostscript testing remains an open issue.
Another argument in favor of going with 9.27.

Markus, I read in the archives that you backported fixes in earlier
security uploads - any other tip? :)

Cheers!
Sylvain

ghostscript testing

[Sylvain Beucler]

Hi,

I prepared an update for ghostscript.
https://people.debian.org/~beuc/lts/ghostscript/

Even if we recently rebased to the latest upstream in jessie, the
upstream patches did not apply cleanly and I did my best to replicate
the changes.
Note: we ship a 9.26*a* version which upstream does not provide publicly
AFAICS (plus it was dfsg-modified), but the conflicts are due to
upstream's master branch.

Upstream seems to keep their test suite private. The documentation
reference a "smoke.ps" file that was removed years ago, and even then it
depended on PS files that I cannot locate.
https://www.ghostscript.com/doc/9.26/Release.htm#Testing

Is there a known test suite for ghostscript?
(or maybe we should just wait for some 9.26

Cheers!
Sylvain

Re: ghostscript testing

[Sylvain Beucler]

On 25/03/2019 16:11, Sylvain Beucler wrote:
> Hi,
>
> I prepared an update for ghostscript.
> https://people.debian.org/~beuc/lts/ghostscript/
>
> Even if we recently rebased to the latest upstream in jessie, the
> upstream patches did not apply cleanly and I did my best to replicate
> the changes.
> Note: we ship a 9.26*a* version which upstream does not provide publicly
> AFAICS (plus it was dfsg-modified), but the conflicts are due to
> upstream's master branch.
>
> Upstream seems to keep their test suite private. The documentation
> reference a "smoke.ps" file that was removed years ago, and even then it
> depended on PS files that I cannot locate.
> https://www.ghostscript.com/doc/9.26/Release.htm#Testing
>
> Is there a known test suite for ghostscript?
> (or maybe we should just wait for some 9.26

[hit a shortcut by accident]

(or maybe we should just wait for some 9.26b and backport it?)

Cheers!
Sylvain

Debian LTS logo

[Sylvain Beucler]

Hi,

Is this our official logo?
I was contemplating adding it to my monthly reports:
https://raphaelhertzog.com/files/2015/03/Debian-LTS-2-small.png

Also, is there a version in higher resolution?

Cheers!
Sylvain

Re: more missing DLAs on the website

[Sylvain Beucler]

Hi,

Is there a rationale on why we are updating the website, by the way?
And with a full copy of the advisory?
(instead of e.g. pointing to the list archives).
I wondered whether we needed translations at:
https://lists.debian.org/debian-lts/2019/03/msg00101.html
https://lists.debian.org/debian-lts/2019/03/msg00152.html
but I didn't get any feedback.

This doesn't seem to be a tool issue (I made a few fixes btw) but rather
a matter of priority and man power.
Understanding the goals in the first place would help IMHO :)

Cheers!
Sylvain

On 01/04/2019 19:45, Holger Levsen wrote:
> hi,
>
> the number of missing DLAs on https://www.debian.org/lts/security/ has
> recently gone up again. Missing are:
>
> Emilio Pozuelo Monfort [DLA 1746-1] drupal7 security update
> Emilio Pozuelo Monfort [DLA 1745-1] libdatetime-timezone-perl new upstream 
> version
> Emilio Pozuelo Monfort [DLA 1744-1] tzdata new upstream version
> Emilio Pozuelo Monfort [DLA 1743-1] thunderbird security update
> Abhijith PA[DLA 1742-1] wordpress security update
> Thorsten Alteholz  [DLA 1741-1] php5 security update
> Mike Gabriel   [DLA 1740-1] libav security update
> Thorsten Alteholz  [DLA 1734-1] libraw security update
> Emilio Pozuelo Monfort [DLA 1732-1] openjdk-7 security update
> Mike Gabriel   [DLA 1730-1] libssh2 security update
> Thorsten Alteholz  [DLA 1729-1] wireshark security update
> Mike Gabriel   [DLA 1728-1] openssh security update
> Emilio Pozuelo Monfort [DLA 1727-1] firefox-esr security update
> Emilio Pozuelo Monfort [DLA 1726-1] bash security update
> Thorsten Alteholz  [DLA 1725-1] rsync security update
> Emilio Pozuelo Monfort [DLA 1724-1] ntfs-3g security update
> Mike Gabriel   [DLA 1723-1] cron security update
> Emilio Pozuelo Monfort [DLA 1722-1] firefox-esr security update
> Chris Lamb [DLA 1719-1] libjpeg-turbo security update
> Abhijith PA[DLA 1714-1] libsdl2 security update
> Abhijith PA[DLA 1713-1] libsdl1.2 security update
> Emilio Pozuelo Monfort [DLA 1712-1] libsndfile security update
> Markus Koschany[DLA 1711-1] systemd security update
> Bastian Blank  [DLA 1709-1] waagent security update
> Bastian Blank  [DLA 1688-1] waagent update
> Emilio Pozuelo Monfort [DLA 1684-1] systemd security update
> Emilio Pozuelo Monfort [DLA 1683-1] rdesktop security update
>
> What surprise me is that some people sometimes appearantly manage to
> update the website and some times not, I wonder why?
>
> I'd also like to remind everyone - who is a paid contributor via
> freexian - that it's your duty to update the website or provide an MR
> via https://salsa.debian.org/webmaster-team/webwml/merge_requests
>
> If your name is listed above, *please* update the website or provide an MR
> via https://salsa.debian.org/webmaster-team/webwml/merge_requests for
> those DLAs.
>
> If somebody picks up the rest, I'd also be really thankful. And probably
> not just me! ;)
>
>
> Last not least: I've thought about (not) naming people but decided to do
> so because I don't consider this public shaming but quite the contrary,
> everybody listed above has done great work! Which just has a tiny flaw
> which I'm sure you also want to fix, thus I made it easier for you to see if
> you're affected.
> I'm also sure this is mostly a tooling issue. #859123 is the best place
> to discuss fixes.
>
>

Re: Fwd: [SECURITY] [DSA 4427-1] samba security update

[Sylvain Beucler]

Thanks Mathieu.

I referenced it in our dla-needed.txt task list.
A member of the LTS team will look into it.

Cheers!
Sylvain

On 08/04/2019 11:10, Mathieu Parent wrote:
> Dear LTS maintainers, > > See attached patch for CVE-2019-3880 in samba. 
> Don't know if it
applies cleanly. > > Regards > > Mathieu Parent > > -- Forwarded
message - > De : Sebastien Delafond  > Date:
lun. 8 avr. 2019 à 10:27 > Subject: [SECURITY] [DSA 4427-1] samba
security update > To:  > >
> -
> Debian Security Advisory DSA-4427-1   secur...@debian.org
> https://www.debian.org/security/   Sebastien Delafond
> April 08, 2019    https://www.debian.org/security/faq
> -
>
> Package    : samba
> CVE ID : CVE-2019-3880
>
> Michael Hanselmann discovered that Samba, a SMB/CIFS file, print, and
> login server for Unix, was vulnerable to a symlink traversal
> attack. It would allow remote authenticated users with write
> permission to either write or detect files outside of Samba shares.
>
> For the stable distribution (stretch), this problem has been fixed in
> version 2:4.5.16+dfsg-1+deb9u1.
>
> We recommend that you upgrade your samba packages.
>
> For the detailed security status of samba please refer to
> its security tracker page at:
> https://security-tracker.debian.org/tracker/samba
>
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
>
> Mailing list: debian-security-annou...@lists.debian.org

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity

[Sylvain Beucler]

Hi,

On 08/04/2019 14:32, Holger Levsen wrote:
> I've done this again and am considering (in general) to not write these mails
> anymore. Please speak up if you think these mails are useful (or could
> be made more useful.)
>
> Today I do feel it's useful to point out, that one should not merely
> reclaim the packages but also update the notes and explain why the
> package is claimed for long but not uploaded. Else it will be unclaimed
> again next week.
I think they are useful, though according to the wiki page they are part
of the front-desk duties.

Should we update it?

- Sylvain

phpmyadmin CVE-2019-6799 review request

[Sylvain Beucler]

Hi,

I recently applied to join the Debian LTS project as a paid contributor.
As part of this process I'm preparing a DLA for phpmyadmin following
data/dla-needed.txt.

CVE-2019-6798 is actually not-affected (related Designer code was
refactored twice since Jessie).

CVE-2019-6799 is an annoying one that varies on whether:
- php5-mysql or php5-mysqlnd is installed,
- mysql.so or mysqli.so is used,
- open_basedir is in use,
- the user runs an arbitrary query or uses the import feature
Here is a package where I believe this vulnerability is fixed:
https://www.beuc.net/tmp/debian-lts/

Attached is the debdiff.

Testing a temporary database and attempting to run something like:
LOAD DATA LOCAL INFILE '/etc/phpmyadmin/config-db.php' INTO TABLE
test(text);
in one configuration from above would be a good test.

I would very much welcome your feedback :)

Cheers!
Sylvain

diff -Nru phpmyadmin-4.2.12/debian/changelog phpmyadmin-4.2.12/debian/changelog
--- phpmyadmin-4.2.12/debian/changelog	2019-01-29 18:10:17.0 +0100
+++ phpmyadmin-4.2.12/debian/changelog	2019-02-24 01:12:19.0 +0100
@@ -1,3 +1,11 @@
+phpmyadmin (4:4.2.12-2+deb8u5) UNRELEASED; urgency=high
+
+  * Non-maintainer upload by the Debian LTS team.
+  * Fix CVE-2019-6799: information leak (arbitrary file read) using SQL
+queries.
+
+ -- Sylvain Beucler   Sun, 24 Feb 2019 01:12:19 +0100
+
 phpmyadmin (4:4.2.12-2+deb8u4) jessie-security; urgency=high
 
   * Non-maintainer upload by the Debian LTS team.
diff -Nru phpmyadmin-4.2.12/debian/patches/CVE-2019-6799.patch phpmyadmin-4.2.12/debian/patches/CVE-2019-6799.patch
--- phpmyadmin-4.2.12/debian/patches/CVE-2019-6799.patch	1970-01-01 01:00:00.0 +0100
+++ phpmyadmin-4.2.12/debian/patches/CVE-2019-6799.patch	2019-02-24 01:12:19.0 +0100
@@ -0,0 +1,84 @@
+Description: Fix information leak (arbitrary file read) using SQL queries
+ Fix CVE-2019-6799
+ https://www.phpmyadmin.net/security/PMASA-2019-1/
+
+ This patch is based on upstream patches:
+ https://github.com/phpmyadmin/phpmyadmin/commit/c5e01f84ad48c5c626001cb92d7a95500920a900
+ https://github.com/phpmyadmin/phpmyadmin/commit/aeac90623e525057a7672ab3d98154b5c57c15ec
+ Avoid regression in 'Table > Import > Load CSV with LOAD DATA' by backporting:
+ https://github.com/phpmyadmin/phpmyadmin/commit/d02d61ada7c8e29753fd37440b511a1088efb060
+
+ Note: mitigated by /etc/phpmyadmin/apache.conf's open_basedir:
+ - php5-mysql: open_basedir fully disables LOAD DATA LOCAL INFILE;
+ - php5-mysqlnd: open_basedir is respected but some sensitive files
+   remain accessible, notably '/etc/phpmyadmin/config-db.php'.
+
+ Note: nothing to do with AllowArbitraryServer, works on local MySQL server as well.
+
+ Note: https://bugs.php.net/bug.php?id=77496 applies php5-mysqlnd but not php5-mysql.
+
+Author: Sylvain Beucler 
+Last-Updated: 2019-02-24
+
+Index: phpmyadmin-4.2.12/import.php
+===
+--- phpmyadmin-4.2.12.orig/import.php
 phpmyadmin-4.2.12/import.php
+@@ -6,6 +6,11 @@
+  * @package PhpMyAdmin
+  */
+ 
++/* Enable LOAD DATA LOCAL INFILE for LDI plugin */
++if (isset($_POST['format']) && $_POST['format'] == 'ldi') {
++define('PMA_ENABLE_LDI', 1);
++}
++
+ /**
+  * Get the variables sent or posted to this script and a core script
+  */
+Index: phpmyadmin-4.2.12/libraries/dbi/DBIMysql.class.php
+===
+--- phpmyadmin-4.2.12.orig/libraries/dbi/DBIMysql.class.php
 phpmyadmin-4.2.12/libraries/dbi/DBIMysql.class.php
+@@ -52,6 +52,10 @@ class PMA_DBI_Mysql implements PMA_DBI_E
+ ) {
+ global $cfg;
+ 
++if (ini_get('mysql.allow_local_infile')) {
++PMA_fatalError(__('Please disable mysql.allow_local_infile in your PHP configuration or install the mysqli extension.'));
++}
++
+ if (empty($client_flags)) {
+ if ($cfg['PersistentConnections'] || $persistent) {
+ $link = @mysql_pconnect($server, $user, $password);
+Index: phpmyadmin-4.2.12/libraries/dbi/DBIMysqli.class.php
+===
+--- phpmyadmin-4.2.12.orig/libraries/dbi/DBIMysqli.class.php
 phpmyadmin-4.2.12/libraries/dbi/DBIMysqli.class.php
+@@ -156,7 +156,12 @@ class PMA_DBI_Mysqli implements PMA_DBI_
+ 
+ $link = mysqli_init();
+ 
+-mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, true);
++// Note: CVE-2019-6799 for php5-mysql (non-nd)
++if (defined('PMA_ENABLE_LDI')) {
++mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, true);
++} else {
++mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, false);
++}
+ 
+ $client_flags = 0;
+ 
+@@ -219,6 +224,12 @@ class PMA_DBI_Mysqli implements PMA_DBI_
+ }
+ 
+ if ($return_value != false) {
++// Note: CVE-2019-6799 for php5-mysqlnd
++if (defined('

Experimenting with phpmyadmin's testsuite

[Sylvain Beucler]

Hi,

Since phpmyadmin is a regular guest here, I checked how its repository
testsuite performs.
(I didn't find prior work in that area on the list.)

Lots of errors/incomplete/skipped even with the upstream source, lots of
deprecation warnings.
The unit tests quickly halts on Debian's patched codebase due to
removing bundled libraries and getFilePath()/CVE-2016-6621.

The Selenium tests can be run from the upstream phpmyadmin source while
targetting a Debian install.
The testsuite recommends compiling and installing PECL runkit for
additional tests, but it makes it crash/halt.
It is not entirely stable, here are 2 full runs on +deb8u4:
Tests: 2192, Assertions: 4800, Failures: 4, Errors: 120, Incomplete: 9,
Skipped: 93.
Tests: 2192, Assertions: 4798, Failures: 4, Errors: 122, Incomplete: 8,
Skipped: 93.
(most of the Errors are actually "PHPUnit_Framework_Assert::assertTag is
deprecated")

That's still an indicator on whether an update significantly broke
something :)


Install instructions:

-

apt install phpunit-selenium ant php5-gd php5-gmp
mkdir -p /usr/share/selenium/
# using the latest selenium 2.x (didn't try 3.x)
wget -c
http://selenium-release.storage.googleapis.com/2.53/selenium-server-standalone-2.53.1.jar
\
 -O /usr/share/selenium/selenium-server.jar

# Needs old Firefox 58 (not 60) otherwise Selenium can't install its
extension
wget
http://ftp.fr.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_52.8.1esr-1~deb8u1_amd64.deb
wget
http://ftp.fr.debian.org/debian/pool/main/f/firefox-esr/firefox-esr-l10n-fr_52.8.1esr-1~deb8u1_all.deb
apt install libjsoncpp0
dpkg -i *.deb

# In a graphical session (possibly disable the screen saver):
java -jar /usr/share/selenium/selenium-server.jar

-

# additional selenium tests (headers) require runkit
# well drop that - actually that make the non-selenium testsuite crash...
wget http://pecl.php.net/get/runkit-1.0.4.tgz
apt install php5-dev
tar xzf runkit-1.0.4.tgz
cd runkit-1.0.4/
# README
phpize
./configure
make
make test
make install
cat < /etc/php5/mods-available/runkit.ini
extension=runkit.so
runkit.internal_override=1
EOF
#php5enmod runkit

-

git clone https://github.com/phpmyadmin/phpmyadmin/
cd phpmyadmin/
git checkout RELEASE_4_2_12
# Note: build.xml => phpunit --configuration phpunit.xml.dist =>
test/bootstrap-dist.php
edit test/bootstrap-dist.php:
#    'TESTSUITE_PASSWORD' => 'mysql_root_password',
#    'TESTSUITE_SELENIUM_HOST' => '127.0.0.1',

ant

You should see browser windows popping in and out.
Takes ~10mn per run.

Cheers!
Sylvain

Accepted freedink-dfarc 3.12-1+deb8u1 (source amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 24 Feb 2019 12:35:35 +0100
Source: freedink-dfarc
Binary: freedink-dfarc freedink-dfarc-dbg
Architecture: source amd64
Version: 3.12-1+deb8u1
Distribution: jessie-security
Urgency: high
Maintainer: Debian Games Team 
Changed-By: Sylvain Beucler 
Description:
 freedink-dfarc - frontend and .dmod installer for GNU FreeDink
 freedink-dfarc-dbg - debugging symbols for dfarc
Changes:
 freedink-dfarc (3.12-1+deb8u1) jessie-security; urgency=high
 .
   * Fix directory traversal in D-Mod extractor (CVE-2018-0496)
Checksums-Sha1:
 013a321e1fd3b2a44b3f7ac62ca71e73001a66a6 1747 freedink-dfarc_3.12-1+deb8u1.dsc
 d597f6203dec3db4e3f4199c64ec2113d20018bb 329925 freedink-dfarc_3.12.orig.tar.gz
 4c66cb2bdc2adc28c162afe1c9fc575169e3e6a1 7812 
freedink-dfarc_3.12-1+deb8u1.debian.tar.xz
 b7bc7176cd65df1625534edf61db07b4a47bd890 192684 
freedink-dfarc_3.12-1+deb8u1_amd64.deb
 a05f37bfc837873d3638bb933d84459595dcf7ec 1832502 
freedink-dfarc-dbg_3.12-1+deb8u1_amd64.deb
Checksums-Sha256:
 f8363b6cfada4d959906011ffc77fcefbbda9bbf2873a4269eb16f112ab094f3 1747 
freedink-dfarc_3.12-1+deb8u1.dsc
 222a84cc91967abce4d86fb4ed8ba43455b818aecdb8487b0fe52d76ade29a83 329925 
freedink-dfarc_3.12.orig.tar.gz
 4beea5dc3efab2c7230e9af986548439c17a0e7f3cb78acb40617243ce502eaa 7812 
freedink-dfarc_3.12-1+deb8u1.debian.tar.xz
 bc04e22f7efe214c9fd4a16e3463cb71c081d3ab53533323b89f2a30bb6b8810 192684 
freedink-dfarc_3.12-1+deb8u1_amd64.deb
 422ee97a30073e5db9268bccf4b74797e2a996365bde0b028c7cd85fd913a153 1832502 
freedink-dfarc-dbg_3.12-1+deb8u1_amd64.deb
Files:
 8684df53327eafc22e42c8376581e69e 1747 games extra 
freedink-dfarc_3.12-1+deb8u1.dsc
 1c24ba41cf1ef532415f13a04f279099 329925 games extra 
freedink-dfarc_3.12.orig.tar.gz
 6d5035ed135080e1deb8d33ebc037bf2 7812 games extra 
freedink-dfarc_3.12-1+deb8u1.debian.tar.xz
 ccdb01d1f4b4f1a62a7109aee797d802 192684 games extra 
freedink-dfarc_3.12-1+deb8u1_amd64.deb
 f9da1d58fd4104d3aa6387b676bf7b94 1832502 debug extra 
freedink-dfarc-dbg_3.12-1+deb8u1_amd64.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlxynEcACgkQj/HLbo2J
BZ9nbQf+Mzjv1MvXKpjcG7ykzFcZ32GdCgKwRupTKntcSbHGQmHzSYSZlCWz7QrT
xPC9PpJqiTB/c/bxuhkWc4X6ULV04tt77+7S6l3hhlIIVd9l5y9KouSPTEGlLQgm
KfWKQ9oVshLWTqmXFNZ2qQoFDlcYzBOUQFyHxh24lptWMb5NYrUJXdV79bHqSI53
3gSXY4nBjUgsS0122sLshtTYd+Q5x/TARBvhK5WPtzPDXapwlLkS87rAFZYyuZuj
YpF7KiI4ZTu9820rW0HBD4/M18B6n7KxkSMfB/K444AZsVPT5d6cYkRaAUx6fV6Z
sSanqxkBh9DDva3969lPyF7nDnPKpA==
=KnHt
-END PGP SIGNATURE-

[SECURITY] [DLA 1686-1] freedink-dfarc security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: freedink-dfarc
Version: 3.12-1+deb8u1
CVE ID : CVE-2018-0496

Sylvain Beucler and Dan Walma discovered several directory traversal
issues in DFArc, a frontend and extensions manager for the Dink
Smallwood game, allowing an attacker to overwrite arbitrary files on
the user's system.

For Debian 8 "Jessie", this problem has been fixed in version
3.12-1+deb8u1.

We recommend that you upgrade your freedink-dfarc packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlxyrz8ACgkQj/HLbo2J
BZ+1FAf/QUOLJxtFgixRukQ2xs9v1YewkRWNvfZx0e+4x698vC8U8DxNumBsMH42
Lphzwfvaxf7iVYFVty6IT+XNTfsC72qQw8hrk02bAWsjAKWEuER41shzCSLx0rOo
meC83XrCSN+ITfTc2VPnn7x/CKSk3ivAzhPPxZ9lG5q/oSjt4YP+v/pYC7P2i/fs
R8owrh2kkCcP6cxGgO/mKjHdX2VS6JcskUwiOoMAPskDE+01WFmj+xNj5OnYeFF1
F39Nvqe4LyhSr02X2Wvbd1KMPzu8TVdFOVxUkEG0FUEBVGAlgM/sxDEF8c1Dq7pS
y5QgIcqjKsgKR/J/Uac06jHfu9sSVw==
=SW7v
-END PGP SIGNATURE-

Re: phpmyadmin: CVE-2019-6799: PMASA-2019-1

[Sylvain Beucler]

Uploaded to jessie-security.

[SECURITY] [DLA 1692-1] phpmyadmin security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: phpmyadmin
Version: 4:4.2.12-2+deb8u5
CVE ID : CVE-2019-6799
Debian Bug : 920823


An information leak issue was discovered in phpMyAdmin. An attacker
can read any file on the server that the web server's user can
access. This is related to the mysql.allow_local_infile PHP
configuration. When the AllowArbitraryServer configuration setting is
set to false (default), the attacker needs a local MySQL account. When
set to true, the attacker can exploit this with the use of a rogue
MySQL server.

For Debian 8 "Jessie", this problem has been fixed in version
4:4.2.12-2+deb8u5.

We recommend that you upgrade your phpmyadmin packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlx2ll4ACgkQj/HLbo2J
BZ9uwwgAioP4kzTcsHE2yIA4ZdW96aszHsyv8vqReg+ir4MtRodhRvlA/tAszdz2
ov0DThc43uUEGBYCASpUYY8r5lD8EeCLLKkrZwanW4zvNF7m4few4JwfvZoWIMRw
PeB1mnkSF7dg0qPC+4OLRuaYgfyMeLSDIVJbmNlFfUYxK/0t1XvqTBUpPupgjPnv
uZw8OJzhjdaq5R/FaCR+gs5fD9f3CNy4lKPoGv0MVOCqaMW/2/AqvIEMTkjbNDmp
hzQfS/n8k5FPkfev8KfBaWBDn+y78FbZZQ81oqwzK5bRyyU2PMa8SnJldJgITOo7
oq2uNscdwfJnhTpIvbPfxKCrSFJ5kQ==
=CJqr
-END PGP SIGNATURE-

Accepted phpmyadmin 4:4.2.12-2+deb8u5 (source all) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 27 Feb 2019 13:09:09 +0100
Source: phpmyadmin
Binary: phpmyadmin
Architecture: source all
Version: 4:4.2.12-2+deb8u5
Distribution: jessie-security
Urgency: high
Maintainer: Thijs Kinkhorst 
Changed-By: Sylvain Beucler 
Description:
 phpmyadmin - MySQL web administration tool
Changes:
 phpmyadmin (4:4.2.12-2+deb8u5) jessie-security; urgency=high
 .
   * Non-maintainer upload by the Debian LTS team.
   * Fix CVE-2019-6799: information leak (arbitrary file read) using SQL
 queries.
Checksums-Sha1:
 351659176393e08582f3c2b5a8e48c7410715051 1622 phpmyadmin_4.2.12-2+deb8u5.dsc
 7e010bd059192c3aab5ed634f0c5faf080762621 71740 
phpmyadmin_4.2.12-2+deb8u5.debian.tar.xz
 191b89b3e0e88091d96ae26de42f201df4e497c8 3862686 
phpmyadmin_4.2.12-2+deb8u5_all.deb
Checksums-Sha256:
 030b3a93e6c6fda6bc3a39e8738c652006d1abdd98a24aac8da7e00d44f463cc 1622 
phpmyadmin_4.2.12-2+deb8u5.dsc
 4b12244e03ffb3608530281cabc4a3a9a2e45e60069fe6251eeb7124d4d95407 71740 
phpmyadmin_4.2.12-2+deb8u5.debian.tar.xz
 d6fc73b3a9a345a7903a9bba4aab2edd15470f31bd31802b4822eac48e5a68d1 3862686 
phpmyadmin_4.2.12-2+deb8u5_all.deb
Files:
 6335f57542db9b145be8f8b785df6a8e 1622 web extra phpmyadmin_4.2.12-2+deb8u5.dsc
 3e0d95e1e39abd5203f461f23d8c75af 71740 web extra 
phpmyadmin_4.2.12-2+deb8u5.debian.tar.xz
 949caa174e321a5fcc09198cd22b4c3e 3862686 web extra 
phpmyadmin_4.2.12-2+deb8u5_all.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlx2jRwACgkQj/HLbo2J
BZ9n6ggAtIz/SzWFw8h1Soct+eMrUgavg3fOHTWL2rQy1o31G9+PSsIfhww0yu6u
7O1KI582EJRkSdsCwp7MoMQ4Or7Bw/yheJsBW0nrA+tJ+STdwYS56epLzFuLljDa
KY8J8HzwztYsOevZXRB5ansDClStxOG4qtWYBcje1tseLKqSoESPyN4llv9iB0P0
j+U+K3lwZeyKy6FLvAgbXLq5feagUkf6jWCkwl1hcYrm/umXCe7DQ3hdSSKhgRQG
nIyx+gXCH1rFpDNgGhDGDFqrCl0eTwq9YO9cucOag2yQI7K4ocAdw1mMpOtyEqzH
JxNtq3EWaO/x+g9EgnGrouI8dlneJA==
=1LTz
-END PGP SIGNATURE-

Re: Request for testing - symfony

[Sylvain Beucler]

Hi,

On 02/03/2019 18:46, Roberto C. Sánchez wrote:
> I have prepared an update to symfony (version 2.3.21+dfsg-4+deb8u4)
> which is need of testing.  I intend to upload in one week's time if I do
> not receive any reports of problems.  Read on for details if you are in
> a position to help with testing these packages.
>
> I attempted to test the changes myself (I am familiar with PHP) but it
> turns out that Symfony an entirely different sort of matter.  In
> particular, the Debian package itself contains no documentation about
> how to setup even a basic Symfony app and all of the online
> documentation is geared toward the upstream preferred installation
> method which, among other things requires downloading an installer
> script and ends up creating a symfony executable binary.
>
> In any event, my attempts at testing have so far been unable to overcome
> these obstacles and I fear that continuing to try to figure this out for
> myself will only result in lots of wasted time and effort.
>
> To that end, I am requesting that anyone out there using Symfony on
> jessie and familiar with it please consider installing this upload
> candidate and report any issues encountered.
>
> Note that upstream has a very robust unit test suite and I made sure to
> include any new or updated unit tests with each upstream commit that I
> backported.
>
> The packages may be downloaded here: https://people.debian.org/~roberto/
>
> symfony (2.3.21+dfsg-4+deb8u4) jessie-security; urgency=high
>
>   * Non-maintainer upload by the LTS Team.
>   * Cherry-pick upstream commit to fix unit test regression caused by PHP
> 5.6.27 (specifically, the fix for PHP bug 72972)
>   * Fix additional unit test failures resulting from dates too far in the past
>   * Cherry-pick upstream commits to fix security issues
> + Fix CVE-2017-16652: [Security] Validate redirect targets using the
>   session cookie domain
> + Fix CVE-2017-16654: prevent bundle readers from breaking out of paths
> + Fix CVE-2018-11385: Adding session strategy to ALL listeners to avoid
>   *any* possible fixation
> + Fix CVE-2018-11408: [SecurityBundle] Fail if security.http_utils cannot
>   be configured
> + Fix CVE-2018-14773: [HttpFoundation] Remove support for legacy and risky
>   HTTP headers
> + Fix CVE-2018-19789: [Form] Filter file uploads out of regular form types
> + Fix CVE-2018-19790: [Security\Http] detect bad redirect targets using
>   backslashes
>
>  -- Roberto C. Sanchez   Fri, 01 Mar 2019 09:20:42 -0500


I haven't touched Symfony in a while, but I can contribute a few bits:

- The symfony installer is not packaged in Debian
https://github.com/symfony/symfony-installer
I tried to run an old version from git but couldn't find the appropriate
tag matching symfony 2.3.21 (which the Symfony installers depends on (sic))
This makes me wonder if the Symfony Framework is used in Debian, or if
only some of its sub-packages are useful.
Alternatively one could use composer which is not in oldstable (composer
create-project symfony/framework-standard-edition 
).

- The closest I could get to a test environment is:
curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony
apt install php5-mysql
symfony new myproject 2.3.22  # .21 N/A - we'll ditch this one anyway
cd myproject/
mv vendor/symfony/symfony/src/Symfony vendor/symfony/symfony/src/Symfony.bak
ln -s /usr/share/php/Symfony vendor/symfony/symfony/src/
# edit IP in web/app_dev.php
rm -rf app/bootstrap.php.cache
vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php
php app/console server:run 0.0.0.0:8000

This gives access to a default application and its web control panel.

Not sure if you need people to test for regressions or for the security
fix (or both) :)

Hope this helps,
Sylvain

gnutls/nettle (CVE-2018-16868/CVE-2018-16869)

[Sylvain Beucler]

Hi,

I'm working on CVE-2018-16868/CVE-2018-16869, a side-channel attack that
affects gnutls and nettle, disclosed 2018-12, tagged low/local.

Unlike what I read in data/CVE/list, I understand that the nettle fix is
not just a new function - it's a rewrite of the RSA functions,
completemented by a new 'rsa_sec_decrypt' function.
https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007363.html
Consequently the diff is large, and based on a new major version
(conflicts, missing files).

I note that the patch was written by RedHat (Simo Sorce), and that
gnutls is also maintained by a RedHat employee (Nikos Mavrogiannopoulos).
Despite this, RHEL (all releases) issued a "Will not fix" for both:
https://access.redhat.com/security/cve/cve-2018-16869
https://access.redhat.com/security/cve/cve-2018-16868
It's not in EPEL either after 3 months:
https://bugzilla.redhat.com/show_bug.cgi?id=1654930
https://bugzilla.redhat.com/show_bug.cgi?id=1654929
https://apps.fedoraproject.org/packages/nettle
https://apps.fedoraproject.org/packages/gnutls

I see this as a strong signal that we should not attempt to backport the
fix, and go with a  (minor).

Alternatively we could upgrade nettle (libnettle4->libnettle6) which
doesn't break gnutls28's test suite, though it's likely to introduce
other issues (e.g. #789119).

Thoughts?

Cheers!
Sylvain

Re: gnutls/nettle (CVE-2018-16868/CVE-2018-16869)

[Sylvain Beucler]

Hi,

On 04/03/2019 16:55, Markus Koschany wrote:
> Am 04.03.19 um 16:33 schrieb Sylvain Beucler:
> [...]
>> I see this as a strong signal that we should not attempt to backport the
>> fix, and go with a  (minor).
>>
>> Alternatively we could upgrade nettle (libnettle4->libnettle6) which
>> doesn't break gnutls28's test suite, though it's likely to introduce
>> other issues (e.g. #789119).
>>
>> Thoughts?
> I also worked on nettle/gnutls26 for Wheezy. There are too many changes
> and just backporting rsa_sec_decrypt in nettle would be an incomplete
> fix for CVE-2018-16869 because they introduced more hardening against
> those side-channel attacks in other functions. An upgrade of nettle
> would require a rebuild of all reverse-dependencies and that is probably
> too intrusive.


Thanks for your input Markus.

Instead of upgrading I was thinking of providing libnettle6 /in addition
to/ libnettle4, but that still sounds like more troubles than it solves.

Cheers!
Sylvain

Re: Contacting maintainers about no-dsa

[Sylvain Beucler]

Hi,

On 08/03/2019 15:54, Holger Levsen wrote:
> On Fri, Mar 08, 2019 at 12:22:40PM +0100, Sylvain Beucler wrote:
>> I was about do contact the nettle and gnutls maintainers, but after
>> discussing with Emilio on IRC it appears that we do not contact
>> maintainers for this anymore.
>>
>> Should we delete the section?
> yes, please. Maybe it should however mention that its possible to fix
> non-dsa issues if one wants to?

A few days passed, I assume we reached consensus :)

I rephrased to explain this is not required. Also added the "no-dsa"
keyword in the previous section and clarified that one can fix a no-dsa
if they want to.

Cheers!
Sylvain

Re: Debian/LTS newbie question

[Sylvain Beucler]

Hi,

On 09/03/2019 11:44, th.pitsc...@uni.de wrote:
> Hello list members,
>
> is it correct to assume that in Debian versions entering "obsolete"
> state, any "aptitude safe-upgrade" will stop upgrading to newer
> packages other than for the reason of security fixes?
>
> When exactly would also the security related upgrades stop?
>
> In other words: what are the exact assertions given by the specific
> release states "stable", "oldstable", "obsolete" with regards to
> packet upgrades? (when the system is left "as is"; i.e. no adjustment
> to the /etc/apt/sources.list)
>
> I searched the general Debian Release info pages, but could not find a
> definite answer.

Actually "stable" is frozen, and only offers security updates
(responsively) and major bug fixes (every few months).
When it becomes "oldstable"/"obsolete stable" it gets fewer support over
time, see the details and dates at:
https://wiki.debian.org/DebianReleases
https://wiki.debian.org/LTS
https://wiki.debian.org/LTS/Extended

Cheers!
Sylvain

Re: DLAs in the website: some updates and issues

[Sylvain Beucler]

Hi,

On 18/03/2019 09:55, Brian May wrote:
> Laura Arjona Reina  writes:
>
>> Other option is, instead of looking at the html code, doing
>>
>> make dla-123-1.en.html
>>
>> and open the resulting html file with a web browser.
> This command did not work for me, I had to use "make -C 2019
> dla-1716.en.html" instead.
>
> Which leads me to a 2nd point, after reading the wiki page
> 
> I was expecting a filename like:
>
> 2019/dla-1716-1.*
>
> but parse-dla.pl gave me instead:
>
> 2019/dla-1716.*
>
> I notice this seems to match the existing convention, so maybe this is
> an error in the wiki?
I confirm.

These instructions are pretty new. I made fixes a few weeks ago but I
overlooked this "-1".

Fixed the wiki page when testing for my work today :)

Cheers!
Sylvain

Accepted sqlalchemy 0.9.8+dfsg-0.1+deb8u1 (source all amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 18 Mar 2019 13:37:16 +0100
Source: sqlalchemy
Binary: python-sqlalchemy python-sqlalchemy-ext python-sqlalchemy-doc 
python3-sqlalchemy python3-sqlalchemy-ext
Architecture: source all amd64
Version: 0.9.8+dfsg-0.1+deb8u1
Distribution: jessie-security
Urgency: high
Maintainer: Piotr Ożarowski 
Changed-By: Sylvain Beucler 
Description:
 python-sqlalchemy - SQL toolkit and Object Relational Mapper for Python
 python-sqlalchemy-doc - documentation for the SQLAlchemy Python library
 python-sqlalchemy-ext - SQL toolkit and Object Relational Mapper for Python - 
C extension
 python3-sqlalchemy - SQL toolkit and Object Relational Mapper for Python 3
 python3-sqlalchemy-ext - SQL toolkit and Object Relational Mapper for Python3 
- C extensio
Changes:
 sqlalchemy (0.9.8+dfsg-0.1+deb8u1) jessie-security; urgency=high
 .
   * Non-maintainer upload by the Debian LTS Team.
   * Fix CVE-2019-7164 and CVE-2019-7548: SQL injection in order_by()
 and group_by().  Upstream warns that this breaks the seldom-used
 text coercion feature.
Checksums-Sha1:
 7af7b09c601484e2de64bdf2d3b200b7a026a685 2259 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.dsc
 06daf537f9de34a2fdaf60c9752568086962b8c8 4046697 
sqlalchemy_0.9.8+dfsg.orig.tar.gz
 dd4cc74d02361304f3751c3aa74dad6313d6803e 14880 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.debian.tar.xz
 406f20eec097a5895d95db03fd3830fa171eeeb8 605028 
python-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 1ae3e2642d4b01006717c367bcdd631fe0bb78f4 1252150 
python-sqlalchemy-doc_0.9.8+dfsg-0.1+deb8u1_all.deb
 325028e61a068b6cc6cdde56b7dd6a8cacc3224c 600836 
python3-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 b3d69d90f6f9d7eb4a2ea6bcd121f73d1aa15255 18878 
python-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb
 9e0e8dbb24e34210ea9bf7fb207e76c15e43 19024 
python3-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb
Checksums-Sha256:
 e5da06049e47e8ca61e845f8de3bef2e9584059881283f22f7442c026814f8ce 2259 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.dsc
 0371ca90d1abadb109c73f1ac096c17f0bbff9fb43d66f3346806f6d6b9c110d 4046697 
sqlalchemy_0.9.8+dfsg.orig.tar.gz
 f59040e2f5bf79b5c370cae3f4c2f236513ba706731f67e32834cd620d90bdc5 14880 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.debian.tar.xz
 2fecf43ffe517fd9be4b66c745e4dfa98cea4dc7b62cfcd9c7385d58461dd6ed 605028 
python-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 2287e0f736e1bdbf266e7d0419fc3e690e06ec171471831b48d05264e479bc6f 1252150 
python-sqlalchemy-doc_0.9.8+dfsg-0.1+deb8u1_all.deb
 5b30d4f84f0b9ef952c5a0121e33d355e32c3b524987ff2894749f77c3b05ea5 600836 
python3-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 b58bb8085db43332b4f6d8a3f413264117d48bb0110a6b7b46aeb030e0ad6b99 18878 
python-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb
 70c5ed7d383f40727516a4fe879c6ece027516380b1b2e635e8038e30898e03a 19024 
python3-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb
Files:
 f7a4ca0046cb16b67d9d11ecaf76e0ac 2259 python optional 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.dsc
 9064e03b4ec453ef7f181b8bf7ddaa9c 4046697 python optional 
sqlalchemy_0.9.8+dfsg.orig.tar.gz
 03422aff739ffc9312d12672b325401b 14880 python optional 
sqlalchemy_0.9.8+dfsg-0.1+deb8u1.debian.tar.xz
 fe63296bd572d5a4aded8e760b26b866 605028 python optional 
python-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 c287764d65d83b9e52736d5a593cfbe2 1252150 doc extra 
python-sqlalchemy-doc_0.9.8+dfsg-0.1+deb8u1_all.deb
 6eb8662bcdadb0d6594d3c0bed49f596 600836 python optional 
python3-sqlalchemy_0.9.8+dfsg-0.1+deb8u1_all.deb
 d245257b24621d703f31d00c117b0057 18878 python optional 
python-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb
 6516f1d09bb2a957af334575315e5765 19024 python optional 
python3-sqlalchemy-ext_0.9.8+dfsg-0.1+deb8u1_amd64.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlyPl/cACgkQj/HLbo2J
BZ8RwQf9EzfO8c39QD4VtZnSykgh6fzgQ3T2tiq5SFL4RW3J8N3wl4RGzQbNOyLL
o38MLN9uogvaZVvmTBxgDf+lB7uf48o+xYwuNAspSn8gxcmCY2TfKBtmKf99Y0YP
oHrCMpy3eai+fCQEy/N2Rvhm92aQqXZhVBkW/kuJVgyiPOZAp9OGxNqUUmN8iUd0
iLjF6qZiO7QFwxgMgAE7glWiOsaomsXtRtVQwuqRlTcPPToPS8jekL7k/kUl315P
OT1nu7uqc8P1GVlCpucEV3lfM77lc9ee4q/te3tQMpsRGbmVnegKwMm7L45jaVNC
GrIKxazVKASL9gj/SsTgTIZEwJCxqg==
=sBX6
-END PGP SIGNATURE-

Re: DLAs in the website: some updates and issues

[Sylvain Beucler]

Hi,

On Thu, Mar 07, 2019 at 08:02:18PM +0100, Laura Arjona Reina wrote:
> El 5/3/19 a las 16:07, Markus Koschany escribió:
> > thank your for your work on our website. Ideally we would like to make
> > the whole process fully automatic without the need for any manual
> > interaction. 
> 
> This is being discussed in #859123: automate import of DLAs and DSAs in
> www.debian.org
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123
> 
> In particular, I think this message from Lev Lamberov is relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123#20
> 
> > Can you tell us more about the current work flow of our DSA
> > announcements on the front page? 
> 
> DSAs are manually imported by a web team member or a security team
> member, using the parse_advisory.pl script.
> 
> > Does someone from the webteam reviews
> > the generation by hand? 
> 
> Usually yes, but also, as it is noted in Lev's message, I think the
> format of DSA is more standard.

I had a look at parse-dla.pl / parse-advisory.pl, and let's face it:
it's a bunch of ad-hoc regexps that happen to work. Most of the times.

I couldn't find a satisfying way to fix the trailing 
recurring bug.


> > I'm sure we can improve the current parse-dla.pl
> > script and fix those markup bugs. We also thought about downloading the
> > announcements from  https://lists.debian.org/debian-lts-announce/ and
> > then create the DLA on the web page automatically. Is this a viable plan?
> > 
> 
> I don't know.
> 
> I guess that if the security team does not that already it's probably
> because of a reason (or maybe because nobody in the web team could find
> the time+skills+motivation needed to make it possible...).

So the core issue is taking a text mail and automagically generate a
HTML equivalent.

Lev suggested 4 months ago that LTS and DebSec work on a common
mark-up format.  We could attempt to switch to MarkDown, but from
experience it breaks easily, especially wrt newlines.

Alternatively, a simple answer would be to keep the headers parsing
(Package/Version/CVE ID/Debian Bug) but import the free-form
description text verbatim as a monospace block (such as ).
i.e. stop coping with ul/li, just auto-link https://... bits.

I don't suggest merely linking the list archives, since AFAIU there is
demand for advisories translations (if there isn't, though, a link
would be enough IMHO).

What do you think?

Cheers!
Sylvain

[SECURITY] [DLA 1718-1] sqlalchemy security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sqlalchemy
Version: 0.9.8+dfsg-0.1+deb8u1
CVE ID : CVE-2019-7164 CVE-2019-7548
Debian Bug : 922669


Two vulnerabilities were discovered in SQLALchemy, a Python SQL
Toolkit and Object Relational Mapper.

CVE-2019-7164

SQLAlchemy allows SQL Injection via the order_by parameter.

CVE-2019-7548

SQLAlchemy has SQL Injection when the group_by parameter can be controlled.

The SQLAlchemy project warns that these security fixes break the
seldom-used text coercion feature.

For Debian 8 "Jessie", these problems have been fixed in version
0.9.8+dfsg-0.1+deb8u1.

We recommend that you upgrade your sqlalchemy packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlyPnDwACgkQj/HLbo2J
BZ/qqgf9HVfWEeJd9mN/NcJ2/6VILPt7lyDNKuAircBJt4Ya9wTxGpvN3Vknt2ry
Z0oCMBz/z8EHNnlDyJHP4QGKrKXK2obwwVFfaOeel1b4OK6Aj3UMBzbEGypCn7y/
4GzWeQhJcejbhIc8xgJc8/NSqdjeJ7buxV2fny/L+3RNy3UDmLkTqKOaPn0vOau1
N5cOaazYhUvfBmdQCF5cebI5CCOWmpreOGm8QDbwHJAxO6VFtZyMdByQOOYCv80r
kQRuon9ia1qwqyVK8WjkDcV9pZxEI5dH7UN6+Eaum+ZAF+sJ/A3oNcc3iWB9N6JV
KXcPBxTWcIIQJTK+zWOvU1TJ0VTSww==
=JGde
-END PGP SIGNATURE-

sqlalchemy security fix available for testing

[Sylvain Beucler]

Hi,

I made a fix for sqlalchemy available for testing (CVE-2019-7164/7548):
https://people.debian.org/~beuc/lts/sqlalchemy/

Upstream author Mike Bayer warns that this might break applications,
hence if you are depend on sqlalchemy you are encouraged to test:
https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1165/

I'll update it if upstream makes more fine-tuning.
I plan to push it next week unless users/testers report breakage.

Cheers!
Sylvain

sqlalchemy testsuite

[Sylvain Beucler]

Hi,

Here are some notes about running the sqlalchemy test suite on jessie.
The document leaves a lot of the setup up to the user.
I still have some failures with MySQL and Unicode, even when configuring
everything in utf8...

I'm aggregating test suite notes at https://wiki.debian.org/LTS/TestSuites


# Base doc in README.unittests.rst

apt install python-pytest python-mock python-setuptools python-dev
python-mysqldb python-psycopg2
# python-pysqlite1.1 python-pysqlite2 # -> replaced by built-in sqlite3
module

# sqlite tests
apt install python-nose
./sqla_nose.py -v --write-profiles
# Ran 6054 tests in 123.179s
# OK (SKIP=198)

# sqlite tests
python setup.py test
# 5939 passed, 727 skipped in 157.86 seconds

# more DBs
apt install mysql-server
sed -i -e 's/\[mysqld\]/[mysqld]\ndefault_storage_engine=MyISAM/'
/etc/mysql/my.cnf # -> documented but doesn't change test results
#sed -i -e 's/\[mysqld\]/[mysqld]\ncharacter_set_server=utf8/'
/etc/mysql/my.cnf # -> doesn't change test results (still 4
unicode-related failures)
service mysql restart
mysql -e "DROP DATABASE test;"
mysql -e "DROP DATABASE test_schema;"
mysql -e "CREATE DATABASE test;"
mysql -e "CREATE DATABASE test_schema;"
mysql -e "GRANT ALL PRIVILEGES ON test.* TO 'scott'@'localhost'
IDENTIFIED BY 'tiger';"
mysql -e "GRANT ALL PRIVILEGES ON test_schema.* TO 'scott'@'localhost'
IDENTIFIED BY 'tiger';"
apt install postgresql
echo 'max_prepared_transactions = 100' >>
/etc/postgresql/9.4/main/postgresql.conf
sed -i -e 's/^lc_.*/#&/' /etc/postgresql/9.4/main/postgresql.conf
service postgresql restart
echo -e 'tiger\ntiger' | su - postgres -c 'createuser scott -l -P'
su - postgres -c 'dropdb test'
su - postgres -c 'createdb test'
#su - postgres -c "psql -c 'GRANT ALL PRIVILEGES ON DATABASE test to scott;'
su - postgres -c "psql -c 'CREATE SCHEMA test_schema AUTHORIZATION
scott;' test"
su - postgres -c "psql -c 'CREATE SCHEMA test_schema_2 AUTHORIZATION
scott;' test"
su - postgres -c 'psql -c "ALTER DATABASE test SET
default_text_search_config = '\''pg_catalog.english'\'';"'
py.test --db sqlite --db postgresql --db mysql
# Note: apparently one needs to drop/recreate the pgsql DBs due to some
test leftovers

# MySQL: py.test --db mysql
# 4 failed, 5967 passed, 695 skipped in 288.81 seconds
# PostgreSQL: py.test --db postgresql
# 6354 passed, 312 skipped in 333.16 seconds
# All: py.test --db sqlite --db postgresql --db mysql
# 4 failed, 8904 passed, 341 skipped in 312.66 seconds

Re: gnutls/nettle (CVE-2018-16868/CVE-2018-16869)

[Sylvain Beucler]

Hi,

On 04/03/2019 17:37, Sylvain Beucler wrote:
> On 04/03/2019 16:55, Markus Koschany wrote:
>> Am 04.03.19 um 16:33 schrieb Sylvain Beucler:
>> [...]
>>> I see this as a strong signal that we should not attempt to backport the
>>> fix, and go with a  (minor).
>>>
>>> Alternatively we could upgrade nettle (libnettle4->libnettle6) which
>>> doesn't break gnutls28's test suite, though it's likely to introduce
>>> other issues (e.g. #789119).
>>>
>>> Thoughts?
>> I also worked on nettle/gnutls26 for Wheezy. There are too many changes
>> and just backporting rsa_sec_decrypt in nettle would be an incomplete
>> fix for CVE-2018-16869 because they introduced more hardening against
>> those side-channel attacks in other functions. An upgrade of nettle
>> would require a rebuild of all reverse-dependencies and that is probably
>> too intrusive.
>
> Thanks for your input Markus.
>
> Instead of upgrading I was thinking of providing libnettle6 /in addition
> to/ libnettle4, but that still sounds like more troubles than it solves.

(and indeed, when testing gnutls28+libnettle6, "git clone" now fails.)
# git clone https://github.com/symfony/symfony-installer
Clonage dans 'symfony-installer'...
fatal: unable to access 'https://github.com/symfony/symfony-installer/':
gnutls_handshake() failed: Public key signature verification has failed.


Also, the stable security team didn't answer my mail but reached the
same conclusion ( minor).
I'll mark these CVE-s as  and fix the CVE/list incomplete
assessment.


Cheers!
Sylvain

Contacting maintainers about no-dsa

[Sylvain Beucler]

Hi,

At the wiki process page we say:
https://wiki.debian.org/LTS/Development#Contact_the_maintainer
  When we tag issues as "no-dsa", and don't plan to take care of the
updates by ourselves, then we use it in this way:
  $ bin/contact-maintainers --lts --no-dsa sudo CVE-2014-9680 CVE-2014-0106

I was about do contact the nettle and gnutls maintainers, but after
discussing with Emilio on IRC it appears that we do not contact
maintainers for this anymore.

Should we delete the section?

(incidentally I fixed the remaining wheezy references in the template)

Cheers!
Sylvain

Re: LTS, no-dsa reasoning and sponsored packages

[Sylvain Beucler]

Hi,

On 08/04/2019 21:56, Holger Levsen wrote:
> On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote:
>> Recently I noticed that for a no-dsa (either for no-dsa or the
>> stronger ignored) as explanation was started to be used e.g. "not used
>> by any sponsor".

That sounds related to my triage of libpodofo today.

Firstly, as an aside, it seemed to me that  was not stronger,
but more precise than  (a "sub-state" as documented at
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
).
Let me know if you prefer we use 


>> If LTS is meant as Debian project, then I would suggest not to start
>> to use those formulations, which I think are fine for ELTS, which is a
>> dedicated project not on Debian directly. Saying something is not DSA
>> worthy or is going to be ignored, because it's not used by a LTS
>> sponsor will give a signal to others that indeed, Debian LTS is not a
>> generic Debian project.
> thanks for bringing this up. FWIW, I agree with you.
Secondly, being my first go at triaging, I looked at past triages, and
the first occurrence of "not used by any sponsor" is from last August,
so I believed that was a good reason to document it as an additional
reason (the main reason being it's a caught exception / basic DoS, not a
crash with memory overwrite & cie, plus a low popcon for Jessie).

But I'll leave that out from now on.


>> Just stick to "Minor issue" in such cases if something is not DSA
>> worthy because the issue is minor, but do not make it depdendent on if
>> a paying LTS sponsor is using it or not.
> (or dont mark it "Minor issue" if it's not minor. This should also
> hopefully make it more likely someone picks it up as a volunteer efford,
> eg when proofing one is captable of lts work...)

FWIW I like when we justify why it is minor.

Cheers!
Sylvain

Re: LTS, no-dsa reasoning

[Sylvain Beucler]

Hi Salvatore,

On 08/04/2019 22:18, Sylvain Beucler wrote:
> On 08/04/2019 21:56, Holger Levsen wrote:
>> On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote:
>>> Recently I noticed that for a no-dsa (either for no-dsa or the
>>> stronger ignored) as explanation was started to be used e.g. "not used
>>> by any sponsor".
> Firstly, as an aside, it seemed to me that  was not stronger,
> but more precise than  (a "sub-state" as documented at
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
> ).
> Let me know if you prefer we use 

Ping? :)

- Sylvain

LTS report for March

[Sylvain Beucler]

Hi,

I had posted my monthly report on my blog, which is aggregated at Planet
Debian:
https://blog.beuc.net/posts/Debian_LTS_-_March_2019/
https://planet.debian.org/

In case some of this list members left the RSS world, I reference it
here as well :)

Cheers!
Sylvain

Time allocation per CVE

[Sylvain Beucler]

Hi,

I spent the day reproducing (unbreaking) the sqlalchemy exploit,
figuring out how to run the test suite, attempting a backport of the
upstream fix, plus some communication.

I did about the same for the gnutls/nettle issue last week (only to
conclude with a no-dsa T_T).

While I believe those were tricky (there's a reason why they were
sitting for weeks), this still costs time.
Does the above sounds a legitimate use of our sponsored time, or should
I call it quits earlier when a fix is not straightforward?

Cheers!
Sylvain

Accepted glib2.0 2.42.1-1+deb8u1 (source all amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 18 Jun 2019 21:27:05 +0200
Source: glib2.0
Binary: libglib2.0-0 libglib2.0-tests libglib2.0-udeb libglib2.0-bin 
libglib2.0-dev libglib2.0-0-dbg libglib2.0-data libglib2.0-doc libgio-fam 
libglib2.0-0-refdbg
Architecture: source all amd64
Version: 2.42.1-1+deb8u1
Distribution: jessie-security
Urgency: high
Maintainer: Debian GNOME Maintainers 

Changed-By: Sylvain Beucler 
Description:
 libgio-fam - GLib Input, Output and Streaming Library (fam module)
 libglib2.0-0 - GLib library of C routines
 libglib2.0-0-dbg - Debugging symbols for the GLib libraries
 libglib2.0-0-refdbg - GLib library of C routines - refdbg library
 libglib2.0-bin - Programs for the GLib library
 libglib2.0-data - Common files for GLib library
 libglib2.0-dev - Development files for the GLib library
 libglib2.0-doc - Documentation files for the GLib library
 libglib2.0-tests - GLib library of C routines - installed tests
 libglib2.0-udeb - GLib library of C routines - minimal runtime (udeb)
Changes:
 glib2.0 (2.42.1-1+deb8u1) jessie-security; urgency=high
 .
   [Michael Biebl]
   * debian/patches/tests-gdatetime-Use-a-real-rather-than-invented-time.patch:
 Cherry-pick a patch from upstream to fix GDateTime tests when tzdata ≥
 2017a is in use. (#858214)
 .
   [Simon McVittie]
   * debian/patches/gfile-Limit-access-to-files-when-copying.patch:
 Backport patch from upstream to ensure files don't temporarily have
 less restrictive permissions during copying
 (#929753, CVE-2019-12450).
 .
   [Sylvain Beucler ]
   * Non-maintainer upload by the Debian LTS team.
   * Apply FTBFS fix for jessie.
   * Apply CVE-2019-12450 fix for jessie.
Checksums-Sha1:
 0b2ed987ba720d233cae5612b9323211b602620b 2816 glib2.0_2.42.1-1+deb8u1.dsc
 6983dd1585c5f3d1968c144ed94144961d45abf0 69480 
glib2.0_2.42.1-1+deb8u1.debian.tar.xz
 b8774638b0e9c797e4962337098fc5f164f24049 2173080 
libglib2.0-data_2.42.1-1+deb8u1_all.deb
 1258697bb15d73b9f2118e4a4eb8c8961dcc060e 2660342 
libglib2.0-doc_2.42.1-1+deb8u1_all.deb
 8c76d444a624b0c15b46e74833962e9d565b4a28 2399746 
libglib2.0-0_2.42.1-1+deb8u1_amd64.deb
 dd9f39043731534ef7eb906d5ad75f1daee4ddf5 2247310 
libglib2.0-tests_2.42.1-1+deb8u1_amd64.deb
 917750847d1c5f984867714bdd51b5a00b3e2940 1836358 
libglib2.0-udeb_2.42.1-1+deb8u1_amd64.udeb
 6cf22c94750b0bfa09ec3fd71b013ad235796824 1336258 
libglib2.0-bin_2.42.1-1+deb8u1_amd64.deb
 ff76671e673d9bd7f98d1d033271b97ce6174803 2642746 
libglib2.0-dev_2.42.1-1+deb8u1_amd64.deb
 10e9d913ec0fb2c42a176897686331ae3d2d0931 6802726 
libglib2.0-0-dbg_2.42.1-1+deb8u1_amd64.deb
 e232e62270c98795ca0a33c46685d496f0e5130f 1674552 
libglib2.0-0-refdbg_2.42.1-1+deb8u1_amd64.deb
Checksums-Sha256:
 15bd402d05b88c53e8dc2cd88fa140e765e1da5213ae493ba6aeb1317dab612b 2816 
glib2.0_2.42.1-1+deb8u1.dsc
 274c2cb87d6b72d2c8e8bfcd340bea004c0c33b7cec06517e47172aea23a3598 69480 
glib2.0_2.42.1-1+deb8u1.debian.tar.xz
 0afdf92b8b6c8eb84705b384fc92479f63a16966952f39643b3c2e9516923c30 2173080 
libglib2.0-data_2.42.1-1+deb8u1_all.deb
 1aa353d9ea6d8c97684d489c4cc542826a7a7df45cecaa31ce20a5dfa70881c5 2660342 
libglib2.0-doc_2.42.1-1+deb8u1_all.deb
 f6ffeea31244a9da7255f7e4525bcd0d65868649d615d33b7f95623f7f6f4cf8 2399746 
libglib2.0-0_2.42.1-1+deb8u1_amd64.deb
 27d1c42867fb0c2fa4d32f3d3a0b6e297010666e0d7d836c59df729c2b7f4c38 2247310 
libglib2.0-tests_2.42.1-1+deb8u1_amd64.deb
 eb29945b29a8fbb010f9f237126d65782398eab9a21a561b11055d37417ba567 1836358 
libglib2.0-udeb_2.42.1-1+deb8u1_amd64.udeb
 cfb3a51f5df9587b4b68798efa07fcd66ac0db660de23527dcc420cf9b85 1336258 
libglib2.0-bin_2.42.1-1+deb8u1_amd64.deb
 f8111c59b6177bbeb6ea81065782d85bc81cd940aa7e37d1f3d57abf71ee002e 2642746 
libglib2.0-dev_2.42.1-1+deb8u1_amd64.deb
 66111b9c0409d8ac15d633420867257c41e3b836cea1676aa9406826fce4ca81 6802726 
libglib2.0-0-dbg_2.42.1-1+deb8u1_amd64.deb
 56c2077aec0b86368ff21d089ba281dd4f8fc499d8dc144ece1d46b55b8a7e40 1674552 
libglib2.0-0-refdbg_2.42.1-1+deb8u1_amd64.deb
Files:
 3cb699d749f925012097d40711260642 2816 libs optional glib2.0_2.42.1-1+deb8u1.dsc
 fcb89f828b2b561b70069de0f4feb3e6 69480 libs optional 
glib2.0_2.42.1-1+deb8u1.debian.tar.xz
 f3197f73701690d5663452f8e761927f 2173080 libs optional 
libglib2.0-data_2.42.1-1+deb8u1_all.deb
 42c7b16d03f1ea6686e1d302f947fa5d 2660342 doc optional 
libglib2.0-doc_2.42.1-1+deb8u1_all.deb
 433dec0c350f5706a7a6604a67285b29 2399746 libs optional 
libglib2.0-0_2.42.1-1+deb8u1_amd64.deb
 5472d11314fe409e7a19c4bf6f130449 2247310 libs optional 
libglib2.0-tests_2.42.1-1+deb8u1_amd64.deb
 c74bb1769d0d36d6a01b0175d5998d22 1836358 debian-installer optional 
libglib2.0-udeb_2.42.1-1+deb8u1_amd64.udeb
 3f80ee55afa6cb380a6e9b0b95ca65d0 1336258 misc optional 
libglib2.0-bin_2.42.1-1+deb8u1_amd64.deb
 946a1fe07575561d5de1922a345f394d 2642746 libdevel optional 
libglib2.0-dev_2.42.1-1+deb8u1_amd64.deb
 b0607aceea76514c9532f5bf5d5db9f9 6802726 debug extra 
libglib2.0-0-dbg_2.42.1-1+deb8u1_amd64.deb

[SECURITY] [DLA 1826-1] glib2.0 security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: glib2.0
Version: 2.42.1-1+deb8u1
CVE ID : CVE-2019-12450
Debian Bug : 929753

It was discovered that GLib does not properly restrict some file
permissions while a copy operation is in progress; instead, default
permissions are used.

For Debian 8 "Jessie", this problem has been fixed in version
2.42.1-1+deb8u1.

We recommend that you upgrade your glib2.0 packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl0JRsYACgkQj/HLbo2J
BZ9LeAgAqF07CippbX9GzuX119Jh/48Y0oO8rLX2FgmM34FOVtSVEGnDUUXdM4SH
6gD1PBr39CTR2JPzmn/cKWWe0jhBUHrEuFWQDaZ/xWki3lkzg7RDZs809C2toTFe
l1+KN80MoXOgMcFhY3Ok/AFpgDTYFjr6EJ5xX3BpouEhF7ZwWMtlY2K4lGxTArhu
Dt1RVh0U6JlFu1P+ILZMJIkcBC5IYuk07CyITf1y66OTYxtxE3EqQX3irQ9Ld8rv
M3Ce6F1JLcfIxNsM1chzCOkN6UYFlDJH9Tp7wL8Z0BBUev+wiu2b6fpw85WD3QlR
RTJYT2miOZIMpfZOEgxxNtgfSOn2KQ==
=28uP
-END PGP SIGNATURE-

Accepted kdepim 4:4.14.1-1+deb8u2 (source all amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 18 Jun 2019 10:55:26 +0200
Source: kdepim
Binary: kdepim kdepim-mobile akregator kaddressbook kaddressbook-mobile kalarm 
kdepim-kresources storageservicemanager kleopatra kmail kmail-mobile knode 
knotes notes-mobile konsolekalendar kontact tasks-mobile korganizer 
korganizer-mobile ktimetracker libcalendarsupport4 libcomposereditorng4 
libeventviews4 libincidenceeditorsng4 libpimcommon4 libkdepim4 
libkdepimdbusinterfaces4 libkdgantt2-0 libkleo4 libkpgp4 libksieve4 
libkmanagesieve4 libksieveui4 libmailcommon4 libmailimporter4 
libmessagecomposer4 libmessagecore4 libmessagelist4 libmessageviewer4 
libsendlater4 libfollowupreminder4 libtemplateparser4 libkdepimmobileui4 
kdepim-mobileui-data kjots blogilo akonadiconsole libnoteshared4 kdepim-dbg
Architecture: source all amd64
Version: 4:4.14.1-1+deb8u2
Distribution: jessie-security
Urgency: high
Maintainer: Debian Qt/KDE Maintainers 
Changed-By: Sylvain Beucler 
Description:
 akonadiconsole - management and debugging console for akonadi
 akregator  - RSS/Atom feed aggregator
 blogilo- graphical blogging client
 kaddressbook - address book and contact data manager
 kaddressbook-mobile - address book and contact data manager for mobile 
environments
 kalarm - alarm message, command and email scheduler
 kdepim - Personal Information Management apps from the official KDE releas
 kdepim-dbg - debugging symbols for kdepim
 kdepim-kresources - KDE PIM resource plugins
 kdepim-mobile - Personal Information Management apps for mobile environments
 kdepim-mobileui-data - common data files for KDE PIM mobile applications
 kjots  - note-taking utility
 kleopatra  - certificate Manager
 kmail  - full featured graphical email client
 kmail-mobile - email client for mobile environments
 knode  - graphical news reader
 knotes - sticky notes application
 konsolekalendar - konsole personal organizer
 kontact- integrated application for personal information management
 korganizer - calendar and personal organizer
 korganizer-mobile - calendar and personal organizer for mobile environments
 ktimetracker - time tracker tool
 libcalendarsupport4 - calendar support library
 libcomposereditorng4 - compose editor library
 libeventviews4 - event viewing library
 libfollowupreminder4 - follow up reminder library
 libincidenceeditorsng4 - incidence editors library
 libkdepim4 - KDE PIM library
 libkdepimdbusinterfaces4 - KDE PIM D-Bus interfaces library
 libkdepimmobileui4 - user interface library for KDE PIM mobile applications
 libkdgantt2-0 - Gantt chart library
 libkleo4   - certificate based crypto library
 libkmanagesieve4 - Sieve script remote management library
 libkpgp4   - gpg based crypto library
 libksieve4 - Sieve, the mail filtering language, library
 libksieveui4 - Sieve, the mail filtering language, GUI library
 libmailcommon4 - email utility library
 libmailimporter4 - mailimporter library
 libmessagecomposer4 - message composer library
 libmessagecore4 - message core library
 libmessagelist4 - message list library
 libmessageviewer4 - message viewer library
 libnoteshared4 - notes support library
 libpimcommon4 - library for common bits of KDEPIM
 libsendlater4 - send later library
 libtemplateparser4 - KMail template parser library
 notes-mobile - notes application for mobile environments
 storageservicemanager - KDE PIM storage service
 tasks-mobile - task management application for mobile environments
Changes:
 kdepim (4:4.14.1-1+deb8u2) jessie-security; urgency=high
 .
   * Non-maintainer upload by the Debian LTS team.
   * Fix CVE-2019-10732: reply-based decryption oracle.
Checksums-Sha1:
 5c929f4ff7d8d67620410e5732d896567fca2cac 5253 kdepim_4.14.1-1+deb8u2.dsc
 a2a8d36407446546ac0fab66e0742ea2d1288ec8 14461256 kdepim_4.14.1.orig.tar.xz
 371c144d4ec51c293b7523e17e3010acf883ef2a 32436 
kdepim_4.14.1-1+deb8u2.debian.tar.xz
 ca90843d4e90463805c44b3a0d89f4583ec19ed4 19828 kdepim_4.14.1-1+deb8u2_all.deb
 926edbb31b0d8007ad4562d505b73bfc8cdcf044 18700 
kdepim-mobile_4.14.1-1+deb8u2_all.deb
 ff5a0023a46c6ff0f1a08c771dde12d2d60e43fa 1467034 
akregator_4.14.1-1+deb8u2_amd64.deb
 305b62b56fce1e9f7dd8e947758dbc9f9a0ea8be 449514 
kaddressbook_4.14.1-1+deb8u2_amd64.deb
 0a81902df599b7312e3bf639eabbabb07bb5e848 793076 
kaddressbook-mobile_4.14.1-1+deb8u2_amd64.deb
 d45b1bdb7d1da14e5ef99b2b7d596507c3f2fa4f 982370 
kalarm_4.14.1-1+deb8u2_amd64.deb
 a614d048c3ca78f89e4ed07e888aef59cb3efce8 48312 
kdepim-kresources_4.14.1-1+deb8u2_amd64.deb
 934aacc53bf08cdb3837f770c4561177cdc4241b 165274 
storageservicemanager_4.14.1-1+deb8u2_amd64.deb
 8ba537283a7f33d47fe22bb95774cd2702defe0f 1436912 
kleopatra_4.14.1-1+deb8u2_amd64.deb
 bd7e94e871859bfd84d6d25b5f83f0dfa50b69a3 2962152 
kmail_4.14.1-1+deb8u2_amd64.deb
 93589a946f1e631276f29a431d508ad160ad3acc 235852 
kmail-mobile_4.14.1-1+deb8u2_amd64.deb
 294f1937969e27ccc41aa820d3af3137038429f4 1799560 
knode_4.14.1-1+deb8u2_amd64.deb

[SECURITY] [DLA 1825-1] kdepim security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: kdepim
Version: 4:4.14.1-1+deb8u2
CVE ID : CVE-2019-10732
Debian Bug : 926996

A reply-based decryption oracle was found in kdepim, which provides
the KMail e-mail client.

An attacker in possession of S/MIME or PGP encrypted emails can wrap
them as sub-parts within a crafted multipart email. The encrypted
part(s) can further be hidden using HTML/CSS or ASCII newline
characters. This modified multipart email can be re-sent by the
attacker to the intended receiver. If the receiver replies to this
(benign looking) email, they unknowingly leak the plaintext of the
encrypted message part(s) back to the attacker.

For Debian 8 "Jessie", this problem has been fixed in version
4:4.14.1-1+deb8u2.

We recommend that you upgrade your kdepim packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl0ItNgACgkQj/HLbo2J
BZ/+yAgAmLvf2+02Tpnn/RD0xCAePqvhZ0S6dAmpKOs0RD1VJH/3iOT+rCOBKxYl
bMFbP6pjaPg4/fQI7OgwJqCGXBWr9HdyJWHD7VGJEPYavWGFF+pJccwY3wSD4qS9
SBzcy/uSbx/2yf7xfuY4kbJ9bIVnnQVyHvEg46w5YGeoLYScZyvqcY7l1bV1Z/dY
SqTA03rLclweIIvbTcyeNA3N5LIi2Gp7yNA5nEzuhNs848IrrBkpzLFDtBhGR21o
Vj0cLCxyFlMCZE+r6papacHqega4vRFfzkJkE1wcH7ccuWcXC6kvpUsL0BWNr7Do
+0IzO3+4SurRmfM13Y76Y55KVXkPvw==
=yraI
-END PGP SIGNATURE-

openjdk-7 status

[Sylvain Beucler]

Hi,

openjdk-7 is back in dla-needed.txt with the commit message "Sounds
serious enough".
However it was re-added the day after DLA-1782-1 and there's no new CVE
since.

Was it an oversight, or was it meant to reconsider
https://security-tracker.debian.org/tracker/CVE-2019-2697 which wasn't
addressed by that DLA?

Cheers!
Sylvain

Re: dns-root-data in Jessie LTS

[Sylvain Beucler]

Hi,

AFAICS dns-root-data has no reverse-dependency in Jessie (I ran the
script in a more recent box and got confused).
Does it make sense to update it after all?

bind9 ships 3 keys in /etc/bind/bind.keys with the comment "Servers
which were already using the old key (19036) should roll seamlessly to
this new one via RFC 5011 rollover" - hmm, so isn't this working as
intended?

unbound doesn't seem to ship any key (I only see the old 19036 in
testdata/ in the source package).
However it populated /var/lib/unbound/root.key with 20326 on install.

Cheers!
Sylvain

On 13/05/2019 20:45, Ondřej Surý wrote:
> Hi Sylvain,
>
> I am actually not sure whether BIND 9 in Jessie already uses dns-root-data,
> so maybe same procedure will be needed for bind9 package.
>
> Could you perhaps also check unbound?
>
> This is the most probable cause of the weird traffic with old key that DNS 
> Root Operators
> see at root servers.
>
> Just make sure it contains only the new DNSKEY (2017) and not both.
>
> Thanks,
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
>> On 14 May 2019, at 01:38, Sylvain Beucler  wrote:
>>
>> Hi,
>>
>> On 13/05/2019 05:43, Ondřej Surý wrote:
>>> could you please update dns-root-data package in Jessie LTS to latest 
>>> version from Unstable/Stretch?
>> I'll backport it following dkg's stretch update.
>>
>> Besides setting up a bind9, anything we should test?
>>
>> Cheers!
>> Sylvain
>>

Re: dns-root-data in Jessie LTS

[Sylvain Beucler]

Hi,

On 13/05/2019 05:43, Ondřej Surý wrote:
> could you please update dns-root-data package in Jessie LTS to latest version 
> from Unstable/Stretch?

I'll backport it following dkg's stretch update.

Besides setting up a bind9, anything we should test?

Cheers!
Sylvain

Re: improving https://wiki.debian.org/LTS/Development

[Sylvain Beucler]

Hi,

On 16/05/2019 09:40, Christoph Berg wrote:
> Re: Holger Levsen 2019-05-15 <20190515130831.qcgsaiig3bh3b...@layer-acht.org>
>> Should we maybe put just this on a page called 
>> https://wiki.debian.org/LTS/Development/TLDR
>> which then people can look at when they occasionally do a DLA?
>>
>> (and link to that TLDR page promininently from our other pages?)
> I'd recommend keeping that on the same page, or they will diverge.

I personally like the page the way it is.

Though if we want a TLDR we can easily add another "checklist" section
like we did for the Front-Desk duties:
https://wiki.debian.org/LTS/Development#Checklist
at the end of the packaging section.

Note that the root issue is missing the "please also update webml" step.
People who missed this are doing DLAs occasionally (there are countless
mails about it on the mailing list). Would they remember to check
documentation anyway? Or should we focus on a way to announce process
changes once every other year? Or should we simply notify people
individually like Holger just did? :)

- Sylvain

Re: dns-root-data in Jessie LTS

[Sylvain Beucler]

Ping ? :)

On 13/05/2019 21:14, Sylvain Beucler wrote:
> Hi,
>
> AFAICS dns-root-data has no reverse-dependency in Jessie (I ran the
> script in a more recent box and got confused).
> Does it make sense to update it after all?
>
> bind9 ships 3 keys in /etc/bind/bind.keys with the comment "Servers
> which were already using the old key (19036) should roll seamlessly to
> this new one via RFC 5011 rollover" - hmm, so isn't this working as
> intended?
>
> unbound doesn't seem to ship any key (I only see the old 19036 in
> testdata/ in the source package).
> However it populated /var/lib/unbound/root.key with 20326 on install.
>
> Cheers!
> Sylvain
>
> On 13/05/2019 20:45, Ondřej Surý wrote:
>> Hi Sylvain,
>>
>> I am actually not sure whether BIND 9 in Jessie already uses dns-root-data,
>> so maybe same procedure will be needed for bind9 package.
>>
>> Could you perhaps also check unbound?
>>
>> This is the most probable cause of the weird traffic with old key that DNS 
>> Root Operators
>> see at root servers.
>>
>> Just make sure it contains only the new DNSKEY (2017) and not both.
>>
>> Thanks,
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>
>>> On 14 May 2019, at 01:38, Sylvain Beucler  wrote:
>>>
>>> Hi,
>>>
>>> On 13/05/2019 05:43, Ondřej Surý wrote:
>>>> could you please update dns-root-data package in Jessie LTS to latest 
>>>> version from Unstable/Stretch?
>>> I'll backport it following dkg's stretch update.
>>>
>>> Besides setting up a bind9, anything we should test?
>>>
>>> Cheers!
>>> Sylvain

LTS report for April

[Sylvain Beucler]

Hi,

My report for April is available:
https://blog.beuc.net/posts/Debian_LTS_-_April_2019/

Cheers!
Sylvain

Accepted firefox-esr 60.6.2esr-1~deb8u1 (source amd64 all) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 6 May 2019 21:52:00 +0200
Source: firefox-esr
Binary: firefox-esr iceweasel firefox-esr-dbg iceweasel-dbg 
firefox-esr-l10n-all iceweasel-l10n-all firefox-esr-l10n-ach iceweasel-l10n-ach 
firefox-esr-l10n-af iceweasel-l10n-af firefox-esr-l10n-an iceweasel-l10n-an 
firefox-esr-l10n-ar iceweasel-l10n-ar firefox-esr-l10n-as iceweasel-l10n-as 
firefox-esr-l10n-ast iceweasel-l10n-ast firefox-esr-l10n-az iceweasel-l10n-az 
firefox-esr-l10n-be iceweasel-l10n-be firefox-esr-l10n-bg iceweasel-l10n-bg 
firefox-esr-l10n-bn-bd iceweasel-l10n-bn-bd firefox-esr-l10n-bn-in 
iceweasel-l10n-bn-in firefox-esr-l10n-br iceweasel-l10n-br firefox-esr-l10n-bs 
iceweasel-l10n-bs firefox-esr-l10n-ca iceweasel-l10n-ca firefox-esr-l10n-cak 
iceweasel-l10n-cak firefox-esr-l10n-cs iceweasel-l10n-cs firefox-esr-l10n-cy 
iceweasel-l10n-cy firefox-esr-l10n-da iceweasel-l10n-da firefox-esr-l10n-de 
iceweasel-l10n-de firefox-esr-l10n-dsb iceweasel-l10n-dsb firefox-esr-l10n-el 
iceweasel-l10n-el firefox-esr-l10n-en-gb iceweasel-l10n-en-gb 
firefox-esr-l10n-en-za
 iceweasel-l10n-en-za firefox-esr-l10n-eo iceweasel-l10n-eo 
firefox-esr-l10n-es-ar iceweasel-l10n-es-ar firefox-esr-l10n-es-cl 
iceweasel-l10n-es-cl firefox-esr-l10n-es-es iceweasel-l10n-es-es 
firefox-esr-l10n-es-mx iceweasel-l10n-es-mx firefox-esr-l10n-et 
iceweasel-l10n-et firefox-esr-l10n-eu iceweasel-l10n-eu firefox-esr-l10n-fa 
iceweasel-l10n-fa firefox-esr-l10n-ff iceweasel-l10n-ff firefox-esr-l10n-fi 
iceweasel-l10n-fi firefox-esr-l10n-fr iceweasel-l10n-fr firefox-esr-l10n-fy-nl 
iceweasel-l10n-fy-nl firefox-esr-l10n-ga-ie iceweasel-l10n-ga-ie 
firefox-esr-l10n-gd iceweasel-l10n-gd firefox-esr-l10n-gl iceweasel-l10n-gl 
firefox-esr-l10n-gn iceweasel-l10n-gn firefox-esr-l10n-gu-in 
iceweasel-l10n-gu-in firefox-esr-l10n-he iceweasel-l10n-he 
firefox-esr-l10n-hi-in iceweasel-l10n-hi-in firefox-esr-l10n-hr 
iceweasel-l10n-hr firefox-esr-l10n-hsb iceweasel-l10n-hsb firefox-esr-l10n-hu 
iceweasel-l10n-hu firefox-esr-l10n-hy-am iceweasel-l10n-hy-am 
firefox-esr-l10n-ia
 iceweasel-l10n-ia firefox-esr-l10n-id iceweasel-l10n-id firefox-esr-l10n-is 
iceweasel-l10n-is firefox-esr-l10n-it iceweasel-l10n-it firefox-esr-l10n-ja 
iceweasel-l10n-ja firefox-esr-l10n-ka iceweasel-l10n-ka firefox-esr-l10n-kab 
iceweasel-l10n-kab firefox-esr-l10n-kk iceweasel-l10n-kk firefox-esr-l10n-km 
iceweasel-l10n-km firefox-esr-l10n-kn iceweasel-l10n-kn firefox-esr-l10n-ko 
iceweasel-l10n-ko firefox-esr-l10n-lij iceweasel-l10n-lij firefox-esr-l10n-lt 
iceweasel-l10n-lt firefox-esr-l10n-lv iceweasel-l10n-lv firefox-esr-l10n-mai 
iceweasel-l10n-mai firefox-esr-l10n-mk iceweasel-l10n-mk firefox-esr-l10n-ml 
iceweasel-l10n-ml firefox-esr-l10n-mr iceweasel-l10n-mr firefox-esr-l10n-ms 
iceweasel-l10n-ms firefox-esr-l10n-my iceweasel-l10n-my firefox-esr-l10n-nb-no 
iceweasel-l10n-nb-no firefox-esr-l10n-ne-np iceweasel-l10n-ne-np 
firefox-esr-l10n-nl iceweasel-l10n-nl firefox-esr-l10n-nn-no 
iceweasel-l10n-nn-no firefox-esr-l10n-oc iceweasel-l10n-oc firefox-esr-l10n-or
 iceweasel-l10n-or firefox-esr-l10n-pa-in iceweasel-l10n-pa-in 
firefox-esr-l10n-pl iceweasel-l10n-pl firefox-esr-l10n-pt-br 
iceweasel-l10n-pt-br firefox-esr-l10n-pt-pt iceweasel-l10n-pt-pt 
firefox-esr-l10n-rm iceweasel-l10n-rm firefox-esr-l10n-ro iceweasel-l10n-ro 
firefox-esr-l10n-ru iceweasel-l10n-ru firefox-esr-l10n-si iceweasel-l10n-si 
firefox-esr-l10n-sk iceweasel-l10n-sk firefox-esr-l10n-sl iceweasel-l10n-sl 
firefox-esr-l10n-son iceweasel-l10n-son firefox-esr-l10n-sq iceweasel-l10n-sq 
firefox-esr-l10n-sr iceweasel-l10n-sr firefox-esr-l10n-sv-se 
iceweasel-l10n-sv-se firefox-esr-l10n-ta iceweasel-l10n-ta firefox-esr-l10n-te 
iceweasel-l10n-te firefox-esr-l10n-th iceweasel-l10n-th firefox-esr-l10n-tr 
iceweasel-l10n-tr firefox-esr-l10n-uk iceweasel-l10n-uk firefox-esr-l10n-ur 
iceweasel-l10n-ur firefox-esr-l10n-uz iceweasel-l10n-uz firefox-esr-l10n-vi 
iceweasel-l10n-vi firefox-esr-l10n-xh iceweasel-l10n-xh firefox-esr-l10n-zh-cn 
iceweasel-l10n-zh-cn
 firefox-esr-l10n-zh-tw
 iceweasel-l10n-zh-tw
Architecture: source amd64 all
Version: 60.6.2esr-1~deb8u1
Distribution: jessie-security
Urgency: medium
Maintainer: Maintainers of Mozilla-related packages 

Changed-By: Sylvain Beucler 
Description:
 firefox-esr - Mozilla Firefox web browser - Extended Support Release (ESR)
 firefox-esr-dbg - Debugging symbols for Firefox ESR
 firefox-esr-l10n-ach - Acoli language package for Firefox ESR
 firefox-esr-l10n-af - Afrikaans language package for Firefox ESR
 firefox-esr-l10n-all - All language packages for Firefox ESR (meta)
 firefox-esr-l10n-an - Aragonese language package for Firefox ESR
 firefox-esr-l10n-ar - Arabic language package for Firefox ESR
 firefox-esr-l10n-as - Assamese language package for Firefox ESR
 firefox-esr-l10n-ast - Asturian language package for Firefox ESR
 firefox-esr-l10n-az - Azerbaijani language package for Firefox ESR
 firefox-esr-l10n

[SECURITY] [DLA 1780-1] firefox-esr new upstream version

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: firefox-esr
Version: 60.6.2esr-1~deb8u1
Debian Bug : 928415 928449 928509

Firefox 60.6.2 ESR repairs a certificate chain issue that caused
extensions to be disabled in the past few days.  More information, and
details of known remaining issues, can be found at
https://www.mozilla.org/firefox/60.6.2/releasenotes/ and
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/

Installing this update will re-enable any extensions that were disabled
due to this issue.

Extensions installed from Debian packages were not affected.

For Debian 8 "Jessie", this problem has been fixed in version
60.6.2esr-1~deb8u1.

We recommend that you upgrade your firefox-esr packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAlzQ0nYACgkQj/HLbo2J
BZ+OOQgArZOatJ05dmqz4yPmaNgdAlyscgTQNwW4IhWq+eGB1Pyn5MgbDTSpcS8t
+6+P13uV5cwsaSrJj3u/kZyIdM5i9GHkfm8l2jxmtDnoXnrgMbyhmJi9ZUqOGPG/
XeRM11aox63ZN9G0auxPvV8i0kxSofOdTS3z7KF0il1NLC3lApSXos07wqcL48Ie
acupvV3WKGAcoElpIw9Q5VGzrOIbvVnontSuIWWpSsTcJYMPleULpoXuiH1v/L5U
Iosv3wnV0CWX6D9P9pS9RnQ5+Tsyywz2LHj9msPrUDikG92G9ptmWYA0L0/akz0M
/X9Ur50z38q48cfYZ/1Ffqu/sbJTOw==
=X1Uv
-END PGP SIGNATURE-

Re: Firefox insecure because of missing extensions

[Sylvain Beucler]

Hi,

On 06/05/2019 23:33, Sylvain Beucler wrote:
> On 06/05/2019 15:47, Hideki Yamane wrote:
>> On Mon, 6 May 2019 15:04:09 +0200 Karsten  wrote:
>>> Package: firefox-esr
>>> Version: 60.6.1esr-1~deb8u1
>>  It was already done in unstable and stable-proposed-updates, and
>>  reporter asks about oldstable, so CC:ed to lts mailing list.
>>  
>>  LTS maintainers, could you build it for oldstable, please?
> I'm rebuilding the new version with the previous oldstable changes.
> (any estimated time for parallel build 4CPU/SSD?)
>
> If the build succeeds and if I can install extensions again, I'll upload
> to LTS.


https://lists.debian.org/debian-lts-announce/2019/05/msg9.html

Packages should be building now :)

Cheers!
Sylvain

Re: Firefox insecure because of missing extensions

[Sylvain Beucler]

Hi,

On 06/05/2019 15:47, Hideki Yamane wrote:
> On Mon, 6 May 2019 15:04:09 +0200 Karsten  wrote:
>> Package: firefox-esr
>> Version: 60.6.1esr-1~deb8u1
>  It was already done in unstable and stable-proposed-updates, and
>  reporter asks about oldstable, so CC:ed to lts mailing list.
>  
>  LTS maintainers, could you build it for oldstable, please?
I'm rebuilding the new version with the previous oldstable changes.
(any estimated time for parallel build 4CPU/SSD?)

If the build succeeds and if I can install extensions again, I'll upload
to LTS.

Cheers!
Sylvain

Reference nodejs in debian-security-support?

[Sylvain Beucler]

Hi,

I just discovered this while triaging node-fstream:
https://www.debian.org/releases/oldstable/amd64/release-notes/ch-information.en.html#libv8
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#libv8

"Unfortunately, this means that libv8-3.14, nodejs, and the associated
node-* package ecosystem should not currently be used with untrusted
content, such as unsanitized data from the Internet.
In addition, these packages will not receive any security updates during
the lifetime of the Jessie release."

I'm surprised that `grep -ir node` doesn't find any match in the
'debian-security-support' repo.
Did I miss something or is it something we should do?

Cheers!
Sylvain

Re: Free Frontdesk slots this month

[Sylvain Beucler]

Hi,

On 05/07/2019 12:29, Abhijith PA wrote:
> On 04/07/19 3:53 pm, Sylvain Beucler wrote:
>> Hi,
>>
>> There are 2 free Frontdesk slots in the upcoming weeks.
>> Volunteers wanted :)
>>
>> >From 08-07 to 14-07:Chris Lamb 
>> >From 15-07 to 21-07:
>> >From 22-07 to 28-07:Thorsten Alteholz 
>> >From 29-07 to 04-08:
>>
>> https://wiki.debian.org/LTS/Development#Frontdesk_duties
> I took those slots.

This is an *everyday* triage job, and this is your first shift AFAICS.
I would recommend starting with 1 slot, or you're risking running out of
sponsored time.

Cheers!
Sylvain

Re: [SECURITY] [DLA 1826-1] glib2.0 security update

[Sylvain Beucler]

Hi Mike,

On Mon, Jun 24, 2019 at 08:28:11AM +, Mike Gabriel wrote:
> On  Di 18 Jun 2019 22:47:44 CEST, Sylvain Beucler wrote:
> 
> > Package: glib2.0
> > Version: 2.42.1-1+deb8u1
> > CVE ID : CVE-2019-12450
> > Debian Bug : 929753
> > 
> > It was discovered that GLib does not properly restrict some file
> > permissions while a copy operation is in progress; instead, default
> > permissions are used.
> > 
> > For Debian 8 "Jessie", this problem has been fixed in version
> > 2.42.1-1+deb8u1.
> > 
> > We recommend that you upgrade your glib2.0 packages.
> > 
> > Further information about Debian LTS security advisories, how to apply
> > these updates to your system and frequently asked questions can be
> > found at: https://wiki.debian.org/LTS
> 
> I wonder, if it would be good to have this upstream patch backported to
> jessie's glib2.0, too, to have the file permission stuff complete:
> 
> ```
> From 5e4da714f00f6bfb2ccd6d73d61329c6f3a08429 Mon Sep 17 00:00:00 2001
> From: Matthias Clasen 
> Date: Tue, 22 Jan 2019 13:26:31 -0500
> Subject: [PATCH] keyfile settings: Use tighter permissions
> 
> When creating directories, create them with 700 permissions,
> instead of 777.
> 
> Closes: #1658
> ---
>  gio/gkeyfilesettingsbackend.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> --- a/gio/gkeyfilesettingsbackend.c
> +++ b/gio/gkeyfilesettingsbackend.c
> @@ -89,7 +89,8 @@
> 
>contents = g_key_file_to_data (kfsb->keyfile, , NULL);
>g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
> -   G_FILE_CREATE_REPLACE_DESTINATION,
> +   G_FILE_CREATE_REPLACE_DESTINATION |
> +   G_FILE_CREATE_PRIVATE,
> NULL, NULL, NULL);
> 
>compute_checksum (kfsb->digest, contents, length);
> @@ -640,7 +641,7 @@
> 
>kfsb->file = g_file_new_for_path (filename);
>kfsb->dir = g_file_get_parent (kfsb->file);
> -  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
> +  g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);
> 
>kfsb->file_monitor = g_file_monitor (kfsb->file, 0, NULL, NULL);
>kfsb->dir_monitor = g_file_monitor (kfsb->dir, 0, NULL, NULL);
> 
> ```
> 
> The patch was not explicitly mentioned in the CVE, but I stumbled over it
> when fixing glib2.0 for wheezy ELTS last month. (Unfortunately, the
> g_mkdir_with_parents() symbol is not in jessie, for wheezy I skipped the
> safe directory creation part).

This looks like another vulnerability, not related to copying files
from a non-unix VFS, but to the creation of key/value files and their
directory (mitigated by umask and the strict permissions of e.g. ~/.config).

Do you know if this has a CVE?
Maybe we can ask pkg-gnome-maintainers's point?
(I didn't see this applied in other distros but I may have missed it.)

Feel free to take over btw, I won't be much available until next week :)

Cheers!
Sylvain

Re: On (semi-)automated testing and improved workflow of LTS uploads

[Sylvain Beucler]

Hi,

On 11/07/2019 15:20, Jonas Meurer wrote:
>> Many packages are packaged in Git already (probably on Salsa) and have a
>> repo location of their own. With applying GitLab based CI to the
>> workflow, the LTS team would add an extra Git repo, just for the LTS
>> uploads done by the paid contributors.
> Yeah, I agree that this is a downside. An ideal workflow would probably
> look like this:
>
> 1a: for packages on salsa, fork the repo to lts-team/packages/
> 1a.1: if repo doesn't provide a 'jessie' branch, 'gbp import-dsc' the
>   jessie sources into a new branch
> 1b: for packages not on salsa, push the latest package version there
> 2: apply the package updating workflow, as discussed above
> 3a: file a merge request against the official package repo that asks
> to merge back the changes
>
> 99: whenever support for a LTS release ends, cleanup our team workspace
> and remove packages that no longer exist in the next LTS release(s).

I have my doubts about enforcing Git. Large packages such as Firefox can
take several GB once extracted and are time-consuming enough to handle
as-is, without an extra layer of storage, you see what I mean?

Beware that packages stored in Git may not use git-build-package.

TBH I don't understand much how Salsa-CI is to be used, are will it
(re)build massive packages from source, or will we commit pre-built
packages?


> We could use a dedicated private subgroup and move the working repos
> there whenever we need to handle embargoed issues.

Yes, embargoed issues are very rare and special-casing them sounds
better than making everything private (especially from a transparency PoV).


> One advantage of Gitlab/Salsa is that reviewing changes is very
> convenient in the Gitlab UI, especially if we used merge requests for
> new security uploads and require a second developer to merge them.

Note that some issues are purely compilation-related (e.g. building the
source package with a more recent Debian release) and won't appear in a
Salsa source diff view.
debdiff is my authoritative source :)

Cheers!
Sylvain

Free Frontdesk slots this month

[Sylvain Beucler]

Hi,

There are 2 free Frontdesk slots in the upcoming weeks.
Volunteers wanted :)

>From 08-07 to 14-07:Chris Lamb 
>From 15-07 to 21-07:
>From 22-07 to 28-07:Thorsten Alteholz 
>From 29-07 to 04-08:

https://wiki.debian.org/LTS/Development#Frontdesk_duties

- Sylvain

Re: change in LTS procedures: publish DLAs on www.debian.org

[Sylvain Beucler]

How about following the earlier instructions?

/!\ We recommend you request membership to the salsa webmaster-team group.

:)

- Sylvain

On 22/04/2019 19:33, Ola Lundqvist wrote:
> Great. Now I think I can follow the instructions. :-)
>
> On Mon, 22 Apr 2019 at 15:34, Holger Levsen  > wrote:
>
> On Mon, Apr 22, 2019 at 12:54:45PM +, Holger Levsen wrote:
> > On Mon, Apr 22, 2019 at 02:41:27PM +0200, Ola Lundqvist wrote:
> > > Thank you. I think I have successfully made a merge request now.
> > indeed you have. thank you, will merge in a bit.
>
> in the mean time someone else did the merge. :) I clarified
> https://wiki.debian.org/LTS/Development#Prepare_an_update_for_the_website
> further, review welcome.
>
>
> -- 
> tschau,
>         Holger
>
> 
> ---
>                holger@(debian|reproducible-builds|layer-acht).org
>        PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856
> 069A AA1C
>
>
>
> -- 
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.com                  
>   o...@debian.org             |
> |  http://inguza.com/                Mobile: +46 (0)70-332 1551 |
>  ---
>

Accepted ghostscript 9.26a~dfsg-0+deb8u2 (source all amd64) into oldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 23 Apr 2019 12:15:13 +0200
Source: ghostscript
Binary: ghostscript ghostscript-x ghostscript-doc libgs9 libgs9-common 
libgs-dev ghostscript-dbg
Architecture: source all amd64
Version: 9.26a~dfsg-0+deb8u2
Distribution: jessie-security
Urgency: high
Maintainer: Debian Printing Team 
Changed-By: Sylvain Beucler 
Description:
 ghostscript - interpreter for the PostScript language and for PDF
 ghostscript-dbg - interpreter for the PostScript language and for PDF - Debug 
symbo
 ghostscript-doc - interpreter for the PostScript language and for PDF - 
Documentati
 ghostscript-x - interpreter for the PostScript language and for PDF - X11 
support
 libgs-dev  - interpreter for the PostScript language and for PDF - Development
 libgs9 - interpreter for the PostScript language and for PDF - Library
 libgs9-common - interpreter for the PostScript language and for PDF - common 
file
Closes: 925256 925257
Changes:
 ghostscript (9.26a~dfsg-0+deb8u2) jessie-security; urgency=high
 .
   [Sylvain Beucler]
   * Non-maintainer upload by the LTS team.
   * Backport 9.26a~dfsg-0+deb9u2 to jessie.
 .
   [Salvatore Bonaccorso]
   * Have gs_cet.ps run from gs_init.ps
   * Undef /odef in gs_init.ps
   * Restrict superexec and remove it from internals and gs_cet.ps
 (CVE-2019-3835) (Closes: #925256)
   * Obliterate "superexec". We don't need it, nor do any known apps
 (CVE-2019-3835) (Closes: #925256)
   * Make a transient proc executeonly (in DefineResource) (CVE-2019-3838)
 (Closes: #925257)
   * an extra transient proc needs executeonly'ed (CVE-2019-3838)
 (Closes: #925257)
Checksums-Sha1:
 60d1fc1c53fe770beeb61ea2050421a44d1cfd08 2540 
ghostscript_9.26a~dfsg-0+deb8u2.dsc
 7982b872c82de6fd2512f13438c3990c2b734155 117296 
ghostscript_9.26a~dfsg-0+deb8u2.debian.tar.xz
 aaa6c1b5e8785fd52559a761f3a71616aabf7674 3488450 
ghostscript-doc_9.26a~dfsg-0+deb8u2_all.deb
 d20cfa66472529e47ece36cdc1fb3ceec314b469 5143630 
libgs9-common_9.26a~dfsg-0+deb8u2_all.deb
 7d12f3c79ac3c61aa0f26470f278792a5cd36141 98914 
ghostscript_9.26a~dfsg-0+deb8u2_amd64.deb
 96ffd05ac35d75b990167c98fd29bb8b6ad4da54 93856 
ghostscript-x_9.26a~dfsg-0+deb8u2_amd64.deb
 fe68c324becda211569bc121e9092b6f48a9b5d6 2214600 
libgs9_9.26a~dfsg-0+deb8u2_amd64.deb
 301ff258c53db66d8da5ae90fb0b8cfbae5b63f3 76278 
libgs-dev_9.26a~dfsg-0+deb8u2_amd64.deb
 9315ea8208b1fea84c8b8a42d64645e23157d2af 5764408 
ghostscript-dbg_9.26a~dfsg-0+deb8u2_amd64.deb
Checksums-Sha256:
 ca98bee7fb23fe68bc8d289f44d165041521655b428a0a4039961a98e310fd75 2540 
ghostscript_9.26a~dfsg-0+deb8u2.dsc
 4ae1b0ae0e84fc32198f8d05cd91d14a6c9feef83b5ab1e9022734708a31c15a 117296 
ghostscript_9.26a~dfsg-0+deb8u2.debian.tar.xz
 70832f41eaa3edeb48627d36b137458cd2d910695dfe119f16d8de5762cbf3a3 3488450 
ghostscript-doc_9.26a~dfsg-0+deb8u2_all.deb
 c5b5d167c5b732dd157ed262752fdb65cbb535db436cfe97cffc023ba57970df 5143630 
libgs9-common_9.26a~dfsg-0+deb8u2_all.deb
 374939c77028c71210efd42b9fec2f1f89cffedbe2891799246f717cd4babee6 98914 
ghostscript_9.26a~dfsg-0+deb8u2_amd64.deb
 dcd6a18054a2d5557f5541f91d2585c7273263d8d822d0286af76f0e48e9228b 93856 
ghostscript-x_9.26a~dfsg-0+deb8u2_amd64.deb
 fd87b4408d7a63fc4d45a83b9f26ff09385142b6261dbfefd68aa5cb110b7f3a 2214600 
libgs9_9.26a~dfsg-0+deb8u2_amd64.deb
 2f24986789e075796a301dbdd59f4870353e7dc105c11b59dc64d1617fcc9d80 76278 
libgs-dev_9.26a~dfsg-0+deb8u2_amd64.deb
 d205c69e0a6eb2c25f0f756fe2e67a413234c83d60146f4c43d2451ea3076e54 5764408 
ghostscript-dbg_9.26a~dfsg-0+deb8u2_amd64.deb
Files:
 11a01cef9f11d97f2c09d52d554797a6 2540 text optional 
ghostscript_9.26a~dfsg-0+deb8u2.dsc
 d278fae7ca83824f997480fce171d30e 117296 text optional 
ghostscript_9.26a~dfsg-0+deb8u2.debian.tar.xz
 73fea6b3e511b44197f91c915696f894 3488450 doc optional 
ghostscript-doc_9.26a~dfsg-0+deb8u2_all.deb
 cfacbf5d34f72680482a93b9ce9436c8 5143630 libs optional 
libgs9-common_9.26a~dfsg-0+deb8u2_all.deb
 b09ad8126ce727ebb11d51cd73d30559 98914 text optional 
ghostscript_9.26a~dfsg-0+deb8u2_amd64.deb
 7a2d5688d898b2aa571cd273f09c0b7e 93856 text optional 
ghostscript-x_9.26a~dfsg-0+deb8u2_amd64.deb
 e383a93dde54db1fbaa553ef6afa63cb 2214600 libs optional 
libgs9_9.26a~dfsg-0+deb8u2_amd64.deb
 0887718d0ffa6febf15df491c8732dd3 76278 libdevel optional 
libgs-dev_9.26a~dfsg-0+deb8u2_amd64.deb
 769dac4f8a3aeb1df162c5b7281b4d91 5764408 debug extra 
ghostscript-dbg_9.26a~dfsg-0+deb8u2_amd64.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAly+8B4ACgkQj/HLbo2J
BZ9deAgAg50Ly49mLXMcenSgFktGZUoJvMkn/oMgyuWJfnL3VIQ9WHz5sYYwxlhb
oAB90BuuS6L9nW2c/I+yoXIzeVc2jTq28/fnFkbaTIk96NodigsmdxTmAuwAli4j
8DGQP2YOD6wq/mk3seug6pWvOYRdkhFRM01FhZVtN14BGIRuTpEykJSsmEk9+UI1
zonzdf57Cm2zDNL37N6pKwrCHsl/lhlQxoq7N/b5GVjCZsOHGtawf+gODqjtEAwm
yXWY0T1p0briqmFxm4m1Zq0K9qG4i24sp8emMPmS8pJTt8GNH6gk5MJW4FRPPF5S
kA8zgmJ46z7GHLWk/w/AbiAyMdCCcA==
=lSOE
-END PGP SIGNATURE-

[SECURITY] [DLA 1761-1] ghostscript security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: ghostscript
Version: 9.26a~dfsg-0+deb8u2
CVE ID : CVE-2019-3835 CVE-2019-3838
Debian Bug : 925256 925257

Cedric Buissart discovered two vulnerabilities in Ghostscript, the GPL
PostScript/PDF interpreter, which could result in bypass of file system
restrictions of the dSAFER sandbox.

For Debian 8 "Jessie", these problems have been fixed in version
9.26a~dfsg-0+deb8u2.

We recommend that you upgrade your ghostscript packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAly+/PsACgkQj/HLbo2J
BZ/tewgAoNoQW58dj7dRrmtmuKklwTZ+kQcsTsjrJ3zM5TB+lVM3YyCbBlEOoIg5
/tpDtDPHItkBTPIQAav7n8JaSp2+A61j/VKQ4M21Er7YxsRrM6oHLTTeWXr0+AXR
OHs7Ywa6W/ys2tl5DNvvFkoC8qriNGdZigm0b/qLOUErlFEEYwb0EXJpaOXjhuIW
t67Gqs9wY+eM1+AOhXsW9vfy0ICkmkc/584D1D2XOQfs6JoWiwmL8DErTNZhUd3P
+XXKpz0luDt8O/RQ7QtCU73nENtp5bgo7mx1ojWMDxX4Oxb0X4+CXsPzyQ53FXma
tj+wyIt7viWK3SfL1iJaUNcSXKPbjw==
=wRFI
-END PGP SIGNATURE-

Re: LTS, no-dsa reasoning and sponsored packages

[Sylvain Beucler]

Hi,

On 09/04/2019 09:50, Ingo Wichmann wrote:
> labeling it "minor issues" when the real reason is "sponsors needed"
> sounds wrong to me.

That's never been the real reason so far AFAICS, only a complementary
reason.

    [jessie] - libpodofo  (DoS, not used by any sponsor)
    [jessie] - hoteldruid  (low popcon, not used by any sponsor)
    [jessie] - hoteldruid  (low popcon, not used by any sponsor)
    [jessie] - hoteldruid  (low popcon, not used by any sponsor)
    [jessie] - hoteldruid  (low popcon, not used by any sponsor)
    [jessie] - tcpreplay  (not used by any sponsor, hard to exploit)
    [jessie] - tcpreplay  (not used by any sponsor, hard to exploit)
    [jessie] - edk2  (non-free, not used by any sponsor)
    [jessie] - edk2  (non-free, not used by any sponsor)
    [jessie] - edk2  (non-free, not used by any sponsor)
    [jessie] - edk2  (non-free is not supported, not used
by any sponsor)
    [jessie] - edk2  (non-free is not supported, not used
by any sponsor)

Cheers!
Sylvain

Re: Wheezy/ELTS samba update broken for i386 arch

[Sylvain Beucler]

Hi,

On 10/04/2019 13:00, john wrote:
> Hi,
> Samba update for ELTS is broken on i386 arch as some packages remain
> at old version and therefore there are broken dependencies:
>
> #  aptitude -V install samba samba-common samba-common-bin tdb-tools
> The following NEW packages will be installed:
>   libtalloc2{a} [2.0.7+git20120207-1]  libtdb1{a} [1.2.10-2]
> libwbclient0{a} [2:3.6.6-6+deb7u17]  samba{b} [2:3.6.6-6+deb7u17]
> samba-common [2:3.6.6-6+deb7u19]  samba-common-bin [2:3.6.6-6+deb7u17]
>   tdb-tools [1.2.10-2]
> 0 packages upgraded, 7 newly installed, 0 to remove and 1 not upgraded.
> Need to get 8,598 kB/8,663 kB of archives. After unpacking 43.9 MB
> will be used.
> The following packages have unmet dependencies:
>  samba : Depends: samba-common (= 2:3.6.6-6+deb7u17) but
> 2:3.6.6-6+deb7u19 is to be installed.
> The following actions will resolve these dependencies:
>
>  Keep the following packages at their current version:
> 1) samba [Not Installed]
>
>
>
>
>
> AMD64 arch looks fine:
>
> # aptitude -V install samba samba-common samba-common-bin tdb-tools
> The following NEW packages will be installed:
>   libfile-copy-recursive-perl{a} [0.38-1]  libtalloc2{a}
> [2.0.7+git20120207-1]  libtdb1{a} [1.2.10-2]  libwbclient0{a}
> [2:3.6.6-6+deb7u19]  samba [2:3.6.6-6+deb7u19]  samba-common
> [2:3.6.6-6+deb7u19]  samba-common-bin [2:3.6.6-6+deb7u19]  tdb-tools
> [1.2.10-2]  update-inetd{a} [4.43]
> 0 packages upgraded, 9 newly installed, 0 to remove and 4 not upgraded.

AFAICS the u19 update for pushed for amd64 but not for i386 (yet?).
Mike?

Cheers!
Sylvain Beucler
Debian LTS

Re: LTS, no-dsa reasoning and sponsored packages

[Sylvain Beucler]

Hi,

On 16/04/2019 09:20, Raphael Hertzog wrote:
> On Tue, 09 Apr 2019, Sylvain Beucler wrote:
>> On 09/04/2019 09:50, Ingo Wichmann wrote:
>>> labeling it "minor issues" when the real reason is "sponsors needed"
>>> sounds wrong to me.
>> That's never been the real reason so far AFAICS, only a complementary
>> reason.
> Ok, still to not encourage this bad practice, please remove those
> "complementary reasons" from the existing entries.

Already did for mine, just removed the others (pointing to your mail in
the commit message).

- Sylvain

Accepted tomcat8 8.0.14-1+deb8u15 (source all) into oldoldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 13 Aug 2019 16:22:22 +0200
Source: tomcat8
Binary: tomcat8-common tomcat8 tomcat8-user libtomcat8-java libservlet3.1-java 
libservlet3.1-java-doc tomcat8-admin tomcat8-examples tomcat8-docs
Architecture: source all
Version: 8.0.14-1+deb8u15
Distribution: jessie-security
Urgency: high
Maintainer: Debian Java Maintainers 

Changed-By: Sylvain Beucler 
Description:
 libservlet3.1-java - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API 
classes
 libservlet3.1-java-doc - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java 
API documenta
 libtomcat8-java - Apache Tomcat 8 - Servlet and JSP engine -- core libraries
 tomcat8- Apache Tomcat 8 - Servlet and JSP engine
 tomcat8-admin - Apache Tomcat 8 - Servlet and JSP engine -- admin web 
application
 tomcat8-common - Apache Tomcat 8 - Servlet and JSP engine -- common files
 tomcat8-docs - Apache Tomcat 8 - Servlet and JSP engine -- documentation
 tomcat8-examples - Apache Tomcat 8 - Servlet and JSP engine -- example web 
applicati
 tomcat8-user - Apache Tomcat 8 - Servlet and JSP engine -- tools to create user
Changes:
 tomcat8 (8.0.14-1+deb8u15) jessie-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Fix flacky FTBFS by improving fix for CVE-2017-5647.
   * Refresh the expired SSL certificates used by the tests from
 freshly-renewed upstream Tomcat and adapt the test user DN.
   * Fix CVE-2019-0221:
 The SSI printenv command in Apache Tomcat echoes user provided
 data without escaping and is, therefore, vulnerable to XSS. SSI is
 disabled by default. The printenv command is intended for
 debugging and is unlikely to be present in a production website.
   * Fix CVE-2018-8014:
 The defaults settings for the CORS filter provided in Apache
 Tomcat are insecure and enable 'supportsCredentials' for all
 origins. It is expected that users of the CORS filter will have
 configured it appropriately for their environment rather than
 using it in the default configuration. Therefore, it is expected
 that most users will not be impacted by this issue.
   * Fix CVE-2016-5388:
 Apache Tomcat, when the CGI Servlet is enabled, follows RFC 3875
 section 4.1.18 and therefore does not protect applications from
 the presence of untrusted client data in the HTTP_PROXY
 environment variable, which might allow remote attackers to
 redirect an application's outbound HTTP traffic to an arbitrary
 proxy server via a crafted Proxy header in an HTTP request, aka an
 "httpoxy" issue.  The 'cgi' servlet now has a 'envHttpHeaders'
 parameter to filter environment variables.
Checksums-Sha1:
 fe27608a17a27924d52db098d9609afa691a7694 2517 tomcat8_8.0.14-1+deb8u15.dsc
 5641f2ec4b8e89276ad614cba3bd154802fa1a3c 92272 
tomcat8_8.0.14-1+deb8u15.debian.tar.xz
 f6d74cfbf3dfc83a23e3e6c074e1fae9265d0b16 60006 
tomcat8-common_8.0.14-1+deb8u15_all.deb
 f46f66c25347eb38f78279531236dea4e5cdcaec 49564 tomcat8_8.0.14-1+deb8u15_all.deb
 521836a26bf198eafb1ae86517f1084bc29d1f86 37050 
tomcat8-user_8.0.14-1+deb8u15_all.deb
 7d2cb1f17f1cc5b6c2973d12e1f4e4c59854d727 4594576 
libtomcat8-java_8.0.14-1+deb8u15_all.deb
 f9e44c59af699e57d418e2f85440decdda7c271f 394400 
libservlet3.1-java_8.0.14-1+deb8u15_all.deb
 79fc470fe8d20d4d721bf8c4710445c8153280da 250548 
libservlet3.1-java-doc_8.0.14-1+deb8u15_all.deb
 1e7f9bc6c6e743b8a73c12b8673338e735a0c9f8 38388 
tomcat8-admin_8.0.14-1+deb8u15_all.deb
 42cdd479ca7f71dae04ceeff47f721063d3dd89f 196858 
tomcat8-examples_8.0.14-1+deb8u15_all.deb
 ccd0f46e45c9329b54ff7ee631361c9247450cd1 692406 
tomcat8-docs_8.0.14-1+deb8u15_all.deb
Checksums-Sha256:
 e654d15fcb648124fe2b65efc35992565895683b998058bf4a5852ba85766cbf 2517 
tomcat8_8.0.14-1+deb8u15.dsc
 b2d01e501c0d738befa1abf95d988c01112acbb62d1adbeb7f65901e7d7b4cee 92272 
tomcat8_8.0.14-1+deb8u15.debian.tar.xz
 791eff670cb1e0177bb3dd0958528836ea8dd345502450c4003a81d67d54f50d 60006 
tomcat8-common_8.0.14-1+deb8u15_all.deb
 dfe22f4b6fce1e38128cce6b87a770c32ae464cc9667b06d1fe5910ff5ab45c9 49564 
tomcat8_8.0.14-1+deb8u15_all.deb
 d07ee0c79bf07ba93f7cf47c9747a9fb231edb7230e58d2942914357999f42f5 37050 
tomcat8-user_8.0.14-1+deb8u15_all.deb
 ae5d19db78b5d7540c95ab22f9456758a08be9426e952e3bf0b01f0338672376 4594576 
libtomcat8-java_8.0.14-1+deb8u15_all.deb
 c480aa39e2896cf43a9ccd433242bcef7b03da11b14089eb85f70ce415e3683b 394400 
libservlet3.1-java_8.0.14-1+deb8u15_all.deb
 93b0aa28890ca0f8c48a8e5ec68cd6c366854ccf8c469940d252b49a2ed7596f 250548 
libservlet3.1-java-doc_8.0.14-1+deb8u15_all.deb
 f620aba9a6b8cd65feb6ae4689546c9ba73297087dd52672e403ca653c3e4f70 38388 
tomcat8-admin_8.0.14-1+deb8u15_all.deb
 75de37a1fe40dc3661ee4a1f3df6aac97529f4b9791f45223a0bc3ca7203e385 196858 
tomcat8-examples_8.0.14-1+deb8u15_all.deb
 db8dcd994f5981e4a16409efa39ade4f17b3cb1a523cac2513b23f53c1e056c0 692406 
tomcat8-docs_8.0.14-1+deb8u15_all

[SECURITY] [DLA 1883-1] tomcat8 security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: tomcat8
Version: 8.0.14-1+deb8u15
CVE ID : CVE-2016-5388 CVE-2018-8014 CVE-2019-0221
Debian Bug : 929895 898935


Several minor issues have been fixed in tomcat8, a Java Servlet and
JSP engine.

CVE-2016-5388

Apache Tomcat, when the CGI Servlet is enabled, follows RFC 3875
section 4.1.18 and therefore does not protect applications from
the presence of untrusted client data in the HTTP_PROXY
environment variable, which might allow remote attackers to
redirect an application's outbound HTTP traffic to an arbitrary
proxy server via a crafted Proxy header in an HTTP request, aka an
"httpoxy" issue.  The 'cgi' servlet now has a 'envHttpHeaders'
parameter to filter environment variables.

CVE-2018-8014

The defaults settings for the CORS filter provided in Apache
Tomcat are insecure and enable 'supportsCredentials' for all
origins. It is expected that users of the CORS filter will have
configured it appropriately for their environment rather than
using it in the default configuration. Therefore, it is expected
that most users will not be impacted by this issue.

CVE-2019-0221

The SSI printenv command in Apache Tomcat echoes user provided
data without escaping and is, therefore, vulnerable to XSS. SSI is
disabled by default. The printenv command is intended for
debugging and is unlikely to be present in a production website.

For Debian 8 "Jessie", these problems have been fixed in version
8.0.14-1+deb8u15.

We recommend that you upgrade your tomcat8 packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl1TATsACgkQj/HLbo2J
BZ81XggAirEezVJhu43Xzgx6tIfoH9eSRw+hFqODGlr64aRjbuE1+SeWiyceporc
fM83uPbm4rOxZVjAYkqs6tJJVlvJ4C7NC+/4U8tM1QNXJC9Ee1oraV0mIBLN+QA1
mUVsJI/yCSbDdO/RoVwXwD7t6nhTF7cshWDNxzchhpdWBgR/Qez3KgOHg+eAmoRm
/3NPm5+ZcXS2TN1CtvKdohQxN8Ak8tMxdGAbRBOMySBq/wHvyPlffRxq1aGNO3Ic
8mGFeJXOo0/y1URg2/S1i6MUpH4tVtRwcb+4/glMynTcWTbvlGR43Wo5moSh1zh4
g6N2lrOxvSduMEKW++bZxwdw/0TFhw==
=FGrR
-END PGP SIGNATURE-

Re: On tomcat FTBFS.

[Sylvain Beucler]

Hi,

On Thu, Aug 08, 2019 at 02:15:52PM +0200, Markus Koschany wrote:
> Am 08.08.19 um 00:50 schrieb Sylvain Beucler:
> > So I reworked CVE-2017-5647, which involved 5 new commits related to
> > non-blocking I/O (NIO2 and COMET).
> > Stable build.
> > 
> > Then I got upstream to renew their new certs that were expiring tomorrow (!)
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=63648
> > and had to fix-up the SSL client tests accordingly (new client DN).
> > 
> > At last we have a working package that passes the testsuite.
> > How would you smoke-test it?
> > https://www.beuc.net/tmp/debian-lts/tomcat8/
> 
> You can safely ignore all SSL test failures. I suggest you compare the
> output of the current Tomcat release with the output after you have
> fixed the newly reported CVE. If you discover new test failures
> unrelated to the current ones, then it deserves further investigation.
> After that you can simply run DEB_BUILD_OPTIONS=nocheck to avoid the
> FTBFS.

There's no more FTBFS, but I now understand how the previous uploads
"passed" the test suite :)

> Another option is to upgrade to the latest stable release in case
> the changes are too complex and a backport is becoming more and more
> time consuming. Please note that I have fixed CVE-2017-5647 2,5 years
> ago as a member of the Java team. I don't believe that the new commits
> are directly related to CVE-2017-5647. This appears to be a bug that was
> always present and was only fixed after Jessie became stable.

Well, following the advice above, I tested with and without the
CVE-2017-5647 patch, and observed a regression in TestSendFile, which
I fixed with the new commits.


Incidentally the failures Roberto experienced at
https://lists.debian.org/debian-lts/2018/07/msg00056.html were likely
caused by building with no network, which seems to break a few tests
requiring a fully-functional local network (I just experienced the
same tests failing within pbuilder).

Cheers!
Sylvain

Re: firefox-esr 60.8.0esr-1 still missing for jessie

[Sylvain Beucler]

Hi,

(taking upon myself to answer since nobody else did)

On 29/07/2019 20:12, Hoshi Hoshimoto wrote:
> firefox-esr 60.8.0esr-1 is still missing for jessie-security.
>
> Is there a special reason behind this, or is this just an oversight?
>
> Thanks for looking into this.
>
> References:
> https://www.debian.org/security/2019/dsa-4479
> https://security-tracker.debian.org/tracker/source-package/firefox-esr

Emilio volunteered to fix it ~1 week ago:
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dla-needed.txt

There should be some progress by next week (otherwise another LTS member
will take care of it).

Cheers!
Sylvain Beucler - Debian LTS Team

Re: firefox-esr 60.8.0esr-1 still missing for jessie

[Sylvain Beucler]

Hi,

(taking upon myself to answer since nobody else did)

On 29/07/2019 20:12, Hoshi Hoshimoto wrote:

> firefox-esr 60.8.0esr-1 is still missing for jessie-security.
>
> Is there a special reason behind this, or is this just an oversight?
>
> Thanks for looking into this.
>
> References:
> https://www.debian.org/security/2019/dsa-4479
> https://security-tracker.debian.org/tracker/source-package/firefox-esr

Emilio volunteered to fix it ~1 week ago:
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dla-needed.txt

There should be some progress by next week (otherwise another LTS member
will take care of it).

Cheers!
Sylvain Beucler - Debian LTS Team

Re: unzip CVE-2019-13232

[Sylvain Beucler]

Hi,

On Sat, Aug 03, 2019 at 09:12:32AM +0200, Salvatore Bonaccorso wrote:
> On Fri, Aug 02, 2019 at 06:48:05PM +0200, Markus Koschany wrote:
> > Hello Salvatore,
> > 
> > my last email regarding unzip, CVE-2019-13232, apparently remained
> > unanswered [1] but I feel it needs a clarification hence I am resending it.
> > 
> > I don't understand why CVE-2019-13232 was marked as
> > unimportant. According to the security tracker documentation the
> > definition for unimportant is [2]. The reason for marking it as
> > unimportant is currently
> > 
> > "No security impact, crash in CLI tool, any server implementing
> > automatic extraction needs to apply resource limits anyway"
> > 
> > First of all there is no crash in unzip, unpacking a specially crafted
> > zip file may lead to a denial-of-service by consuming all available disk
> > space which in turn my stop certain services from working correctly.
> > 
> > In my opinion the assumption that "any server implementing automatic
> > extraction needs to apply resource limits anyway" is like assuming that
> > all server operators always implement adequate security protections for
> > all scenarios that may arise from running the services. We all know this
> > is not true in real life. Also it is perfectly possible that someone
> > sends out spam emails with a (concealed) zip bomb attached or a link
> > pointing to it which may be opened by an unsuspecting user. Non
> > tech-savvy people quickly run into troubles when they unpack such a file
> > and don't realize that their entire hard disk will fill-up in minutes.
> > If at all no-dsa would be more appropriate than unimportant in my opinion.
> 
> The classification was done here: 
> 
> https://salsa.debian.org/security-tracker-team/security-tracker/commit/0891eec1447b20c9f45d18754f733df2081bbda3
> 
> I though agree with Moritz's classification on this. Should users
> randomly unzip untrusted zip files? A better example: take a virus
> scanning engine, which extracts untrusted zip files. If this engine
> does not pose resource limits they will be out of luck very soon.
> 
> There are different view on the issue it and I could agree that the
> classification is borderline between unimportant and no-dsa.
> 
> The above btw, corresponds as well to upstream point of view:
> 
> https://www.bamsoftware.com/hacks/zipbomb/ -> UnZip 6.0
> 
> > UnZip 6.0
> >
> > Mark Adler wrote a patch for UnZip to detect this class of zip bomb.
> >
> > 2019-07-05: I noticed that CVE-2019-13232 was assigned for UnZip.
> > Personally, I would dispute that UnZip's (or any zip parser's)
> > ability to process a zip bomb of the kind discussed here necessarily
> > represents a security vulnerability, or even a bug. It's a natural
> > implementation and does not violate the specification in any way
> > that I can tell. The type discussed in this article is only one type
> > of zip bomb, and there are many ways in which zip parsing can go
> > wrong that are not bombs. If you want to defend against resource
> > exhaustion attacks, you should not try to enumerate, detect, and
> > block every individual known attack; rather you should impose
> > external limits on time and other resources so that the parser
> > cannot misbehave too much, no matter what kind of attack it faces.
> > There is nothing wrong with attempting to detect and reject certain
> > constructions as a first-pass optimization, but you can't stop
> > there. If you do not eventually isolate and limit operations on
> > untrusted data, your system is likely still vulnerable. Consider an
> > analogy with cross-site scripting in HTML: the right defense is not
> > to try and filter out bytes that may be interpreted as code, it's to
> > escape everything properly.
> >
> > Mark Adler's patch made its way into Debian in bug #931433. There
> > were some unanticipated consequences: problems parsing certain Java
> > JARs (bug #931895) and problems with the mutant zip format of
> > Firefox's omni.ja file (bug #932404). SUSE decided not to do
> > anything about CVE-2019-13232. I think both Debian's and SUSE's
> > choices are defensible.
> 
> Take into acount as well regressions in any of such software (look for
> instance at a very similar stance of a regression for bzip2 which did
> affect both the unstable upload and as well the jessie LTS upload).
> They are very "fragile" and thus needs very extra care.
> 
> > It is quite simple to create such zip files. One can also just download
> > a 10 MB example file with an output size of 281 TB from the original
> > advisory page. Given that unzip is basically installed on every Debian
> > system and it is also the backend for popular front-ends like xarchiver,
> > I consider it to be likely that at least some users will run into issues
> > at some point. Buster will be supported for another five years and a fix
> > is available. Why don't we just 

[SECURITY] [DLA 1871-1] vim security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: vim
Version: 2:7.4.488-7+deb8u4
CVE ID : CVE-2017-11109 CVE-2017-17087 CVE-2019-12735
Debian Bug : 867720 930020


Several minor issues have been fixed in vim, a highly configurable
text editor.

CVE-2017-11109

Vim allows attackers to cause a denial of service (invalid free)
or possibly have unspecified other impact via a crafted source
(aka -S) file.

CVE-2017-17087

Vim sets the group ownership of a .swp file to the editor's
primary group (which may be different from the group ownership of
the original file), which allows local users to obtain sensitive
information by leveraging an applicable group membership.

CVE-2019-12735

Vim did not restrict the `:source!` command when executed in a
sandbox.

For Debian 8 "Jessie", these problems have been fixed in version
2:7.4.488-7+deb8u4.

We recommend that you upgrade your vim packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl1FX5YACgkQj/HLbo2J
BZ89qgf8CoBW+7zggqjjTCsK4uFDShdFdpT3jqGhAsZt+N/j5J2BasHH9d00hidJ
c/gT8Mx5yZJ7+nvws7ysQ2wSk9WLqQ6cm5O5nN4GpAE6TE/Gzoxa0niTYniGDAwO
Fau+xxpNiCeXnTc5L1UeXNs6SQhnYFIdTo47BI957F4mJPW3WR0ka0tExgDTAdhY
yLh0lZLe6/8/3/e+xVaAkNW8y0NXcKbEJH2uNB0//VgeLhSQaM2vTo9hlkoASDyU
Ibase1K5FHYFziU0y+zRtvTySoJV1XQ8etiI7PwU59rLeWmyQy6W8drMgpzZXEaq
VSQJ3SjXXYQulK0Y+SqaiUuxHN5dqw==
=yqrh
-END PGP SIGNATURE-

Re: unzip CVE-2019-13232

[Sylvain Beucler]

On 03/08/2019 14:05, Markus Koschany wrote:
> Am 03.08.19 um 10:55 schrieb Sylvain Beucler:
> [...]
>> When an early fix is more likely to introduce regressions than protect
>> users from real-world attacks, don't we mark it as 'postponed'?
> We only postpone a fix if there is a minor issue and it is not worth
> fixing via a standalone update. Every fix has in theory the potential to
> introduce a regression because we change something. The answer can't be
> to stop fixing bugs but to evaluate the possible impact of a change and
> if necessary correct the patch in another step. If the risk of a
> regression outweighs the benefit of a fix we usually mark the CVE as
> "ignored", e.g. when upstream introduces a new security option that
> requires a lot of code refactoring but only improves the security for
> non-default setups in rather uncommon scenarios.

That was more addressed at security-team@, I was just going your way to
say that marking zip-bomb 'unimportant' just because it was likely to
introduce important regressions conveyed the wrong message.

- Sylvain

Re: (minor) vs. ($not-fixable-because) (was: Re: gnutls/nettle (CVE-2018-16868/CVE-2018-16869))

[Sylvain Beucler]

Hi,

On 30/08/2019 10:28, Mike Gabriel wrote:
> Hi Sylvain, hi all,
>
> On  Fr 08 Mär 2019 11:03:49 CET, Sylvain Beucler wrote:
>
>> Hi,
>>
>> On 04/03/2019 17:37, Sylvain Beucler wrote:
>>> On 04/03/2019 16:55, Markus Koschany wrote:
>>>> Am 04.03.19 um 16:33 schrieb Sylvain Beucler:
>>>> [...]
>>>>> I see this as a strong signal that we should not attempt to
>>>>> backport the
>>>>> fix, and go with a  (minor).
>>>>>
>>>>> Alternatively we could upgrade nettle (libnettle4->libnettle6) which
>>>>> doesn't break gnutls28's test suite, though it's likely to introduce
>>>>> other issues (e.g. #789119).
>>>>>
>>>>> Thoughts?
>>>> I also worked on nettle/gnutls26 for Wheezy. There are too many
>>>> changes
>>>> and just backporting rsa_sec_decrypt in nettle would be an incomplete
>>>> fix for CVE-2018-16869 because they introduced more hardening against
>>>> those side-channel attacks in other functions. An upgrade of nettle
>>>> would require a rebuild of all reverse-dependencies and that is
>>>> probably
>>>> too intrusive.
>>>
>>> Thanks for your input Markus.
>>>
>>> Instead of upgrading I was thinking of providing libnettle6 /in
>>> addition
>>> to/ libnettle4, but that still sounds like more troubles than it
>>> solves.
>>
>> (and indeed, when testing gnutls28+libnettle6, "git clone" now fails.)
>> # git clone https://github.com/symfony/symfony-installer
>> Clonage dans 'symfony-installer'...
>> fatal: unable to access 'https://github.com/symfony/symfony-installer/':
>> gnutls_handshake() failed: Public key signature verification has failed.
>>
>>
>> Also, the stable security team didn't answer my mail but reached the
>> same conclusion ( minor).
>> I'll mark these CVE-s as  and fix the CVE/list incomplete
>> assessment.
>
> I am currently going through all CVEs listed by bin/lts-cve-triage.py
> (in security-tracker Git repo (for those not acquainted to the
> sectracker toolchain).
>
> Marking such CVEs (such as CVE-2018-16868/gnutls28/jessie) as
> " (minor issue)" is technically correct, I guess, but such
> CVEs don't get explicitly marked by the output of lts-cve-triage.py.
> When doing frontdesk work, you get drawn to those issues to at least
> take another look. What was that CVE about, has there been some
> communication regarding it, etc.
>
> However, if we tagged such CVEs as " (too invasive to fix)",
> the  tag would be shown in lts-cve-triage.py output and
> "ignore" explains better what we should do with such CVEs when triaging.
Glad to see my contribution to lts-cve-triage.py is being useful :)
> I am inclined to adapt CVE-2018-16868 accordingly, unless people
> contradict.

Sure, I now avoid the vague  as much as I can,  sounds
adequate for this CVE resolution.

Cheers!
Sylvain

qemu status

[Sylvain Beucler]

Hi Gabriel, hi all :)

We have a prepared QEMU update from 3 months ago that needs attention:
https://packages.sunweavers.net/debian/pool/main/q/qemu/

It fixes:
CVE-2017-9375 CVE-2019-12155 CVE-2017-15124 CVE-2016-5403 CVE-2016-5126

Since then we got:
CVE-2019-14378 CVE-2019-13164 CVE-2019-12068 CVE-2019-12067
and possibly CVE-2018-19665 to reconsider.

I can take the time to setup a physical box and provide more testing /
more patching.
Before doing so, I thought I'd first check:
what are you plans for this month regarding this update? :)

Cheers!
Sylvain

Accepted freetype 2.5.2-3+deb8u4 (source amd64) into oldoldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 04 Sep 2019 11:48:40 +0200
Source: freetype
Binary: libfreetype6 libfreetype6-dev freetype2-demos libfreetype6-udeb
Architecture: source amd64
Version: 2.5.2-3+deb8u4
Distribution: jessie-security
Urgency: high
Maintainer: Steve Langasek 
Changed-By: Sylvain Beucler 
Description:
 freetype2-demos - FreeType 2 demonstration programs
 libfreetype6 - FreeType 2 font engine, shared library files
 libfreetype6-dev - FreeType 2 font engine, development files
 libfreetype6-udeb - FreeType 2 font engine for the debian-installer (udeb)
Changes:
 freetype (2.5.2-3+deb8u4) jessie-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * CVE-2015-9381: FreeType before 2.6.1 has a heap-based buffer
 over-read in T1_Get_Private_Dict in type1/t1parse.c.
   * CVE-2015-9382: FreeType before 2.6.1 has a buffer over-read in
 skip_comment in psaux/psobjs.c because ps_parser_skip_PS_token is
 mishandled in an FT_New_Memory_Face operation.
   * CVE-2015-9383: FreeType before 2.6.2 has a heap-based buffer
 over-read in tt_cmap14_validate in sfnt/ttcmap.c.
   * Remove spurious quilt .pc/ directory from debian diff
 (introduced in 2.5.2-2)
Checksums-Sha1:
 dc454250adf18ca98cc2976a23881012da1b2185 1783 freetype_2.5.2-3+deb8u4.dsc
 b44b8fb1ecd1aeb4671c0aac6e779a316cf97505 72104 freetype_2.5.2-3+deb8u4.diff.gz
 0cbee1704e82d616d3ef60bc91f9cdb613ed4a1d 467422 
libfreetype6_2.5.2-3+deb8u4_amd64.deb
 2b35bec8219169c4d2ad90ba42077b537fcba764 639740 
libfreetype6-dev_2.5.2-3+deb8u4_amd64.deb
 cb31e5e8f970bccefe9ffe9cb943c4d146b6928d 94002 
freetype2-demos_2.5.2-3+deb8u4_amd64.deb
 c93bd870f5582a27abd34d8d05d9955d7f9d3713 294788 
libfreetype6-udeb_2.5.2-3+deb8u4_amd64.udeb
Checksums-Sha256:
 ba32ac993642ed5e1712b064b6072f0f67c95c01eafcaa3d5a1d63b2c03c9e5d 1783 
freetype_2.5.2-3+deb8u4.dsc
 9160b5c1069c763e2b3b55a8e825fa46f054764bf37d8d2d4df3b003859b7e21 72104 
freetype_2.5.2-3+deb8u4.diff.gz
 7e15413b1e2c5d6e762a9ef6755459f47536435397cd5cc6f48de50f688fd2af 467422 
libfreetype6_2.5.2-3+deb8u4_amd64.deb
 36ec5496231d708ad304c4d9c6be357c63d9ba4a600c04a04604311a13445426 639740 
libfreetype6-dev_2.5.2-3+deb8u4_amd64.deb
 2a71609dfdaa2d49c19d6d717c642be00c22b7ec0879da2cfaf899237a72c998 94002 
freetype2-demos_2.5.2-3+deb8u4_amd64.deb
 ef4f6a45a4deb682c2e8dcacbfd9c26eeadcf65bf1f35e10e9adefe0575256de 294788 
libfreetype6-udeb_2.5.2-3+deb8u4_amd64.udeb
Files:
 74924ba8ee528b0f22bd87ed44e44b6a 1783 libs optional freetype_2.5.2-3+deb8u4.dsc
 effed3161cb08cd46efd3c055a028c25 72104 libs optional 
freetype_2.5.2-3+deb8u4.diff.gz
 56f9fad698bdb6c45ace416fa51ca8d0 467422 libs optional 
libfreetype6_2.5.2-3+deb8u4_amd64.deb
 42c70dc1895505a39fd884e5660eb0df 639740 libdevel optional 
libfreetype6-dev_2.5.2-3+deb8u4_amd64.deb
 f84b23bf14ccafaa781df329b6712be0 94002 utils optional 
freetype2-demos_2.5.2-3+deb8u4_amd64.deb
 86487c6461e36718c757f03ea7bb1ded 294788 debian-installer extra 
libfreetype6-udeb_2.5.2-3+deb8u4_amd64.udeb
Package-Type: udeb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl1vrFQACgkQj/HLbo2J
BZ/82ggAqZNCk4/GEUoUIZ/c5RyESYYjipLVny7D2V2FQLZ0RF2ZUJtlkCk1Xsv2
OmnZzhOKaC1cjsOgQ5RNNcx3NENqivSJ9UvrRqp47L2N+knJONUgS7y+emziwaUz
u62aUYGe6M2lOje7CD/o8TM5TfSlPDnkODXsEjN39HZRQigp8KtkXrDCwrZREP2I
H1knsjRDOkg4S3KXy1O1WUPlX5kH6NqlittrLOaKy6mwhTeRkCsLNnBBE9XI00Ey
14Q6KCxppH7FNs3zS3ZAUB/tPbVL9ZKXllMK2B/eHl+Na+rFRdEZSieGl9qqdlQO
ftGrMC+OxuICy01Lhvf+SPk1twY/zA==
=iggT
-END PGP SIGNATURE-

[SECURITY] [DLA 1909-1] freetype security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: freetype
Version: 2.5.2-3+deb8u4
CVE ID : CVE-2015-9381 CVE-2015-9382 CVE-2015-9383


Several newly-referenced issues have been fixed in the FreeType 2 font
engine.

CVE-2015-9381

  heap-based buffer over-read in T1_Get_Private_Dict in
  type1/t1parse.c

CVE-2015-9382

  buffer over-read in skip_comment in psaux/psobjs.c because
  ps_parser_skip_PS_token is mishandled in an FT_New_Memory_Face
  operation

CVE-2015-9383

  a heap-based buffer over-read in tt_cmap14_validate in
  sfnt/ttcmap.c

For Debian 8 "Jessie", these problems have been fixed in version
2.5.2-3+deb8u4.

We recommend that you upgrade your freetype packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl1vsDIACgkQj/HLbo2J
BZ99vwf/dhn8Cc2ypa3wHUPHzs5vk6Y1RLQexTgWloSxpG9yVZyrjOVKE4VKNAEz
MDg4B27vmW7aMvILHGgP5HQ5gnUQVkveKtU2vHQMB1ZPHbWDLBT88niQ0HQP8Yct
F/dCK88x6+/32I+O8H+irEZXj94wbK023AvKUHXHjkX7cHh9Xbn2y9TT9iQxnwrD
pjENycIp63Kfayk+iMHZaDoZfsyIGB3DZbEnoDICQWgzt+bCxcLkBSPbLgrF2o0j
zTpY2h8f6reMGEW/hEUxyh+yJEE8jjd7go04EZmjhCWArav6tPt0ByrSFfYIMkbF
mDWOhZ64MrQyP6op+/+0DGE0uNYN3g==
=MSV8
-END PGP SIGNATURE-

Accepted libonig 5.9.5-3.2+deb8u3 (source amd64) into oldoldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 11 Sep 2019 15:30:09 +0200
Source: libonig
Binary: libonig2 libonig2-dbg libonig-dev
Architecture: source amd64
Version: 5.9.5-3.2+deb8u3
Distribution: jessie-security
Urgency: high
Maintainer: Jörg Frings-Fürst 
Changed-By: Sylvain Beucler 
Description:
 libonig-dev - Development files for libonig2
 libonig2   - Oniguruma regular expressions library
 libonig2-dbg - Debugging symbols for libonig2
Changes:
 libonig (5.9.5-3.2+deb8u3) jessie-security; urgency=high
 .
   * Non-maintainer upload by the LTS team.
   * Backport recursion monitoring (with a fixed limit to avoid
 changing the API; higher limit exhausts the default stack size)
   * Fix CVE-2019-16163: Oniguruma before 6.9.3 allows Stack Exhaustion
 in regcomp.c because of recursion in regparse.c.
Checksums-Sha1:
 a6c9820bd35f4e59c91585b64c312067dc391df7 1559 libonig_5.9.5-3.2+deb8u3.dsc
 c988f0f21d5d32510210a4dcb2deb86e70465443 10636 
libonig_5.9.5-3.2+deb8u3.debian.tar.xz
 5aa359feda7a2008218058dbddc0cf74f3fa3c8e 117756 
libonig2_5.9.5-3.2+deb8u3_amd64.deb
 6552842ae347b3b589a32987c0fb680ef57e4b6f 201112 
libonig2-dbg_5.9.5-3.2+deb8u3_amd64.deb
 c4f52811d7a91dcefb0d7e0705722fde2efb9027 79628 
libonig-dev_5.9.5-3.2+deb8u3_amd64.deb
Checksums-Sha256:
 6d86b3a5524f08262e68e9a6fe6c8e601427b4303e53880d7a78142214e1f1f2 1559 
libonig_5.9.5-3.2+deb8u3.dsc
 088289008e7f63d6eb5e347277f75d04b5e6825bcf3cbb4cc758c45beb5fbd85 10636 
libonig_5.9.5-3.2+deb8u3.debian.tar.xz
 7e82d5b089d123dfb1eff699b9e8cca8dd41ff9665906f00cf9b38a4afada2c0 117756 
libonig2_5.9.5-3.2+deb8u3_amd64.deb
 8f2e792e5194aacba6f964c0b2beb7c4367f0b5224ec9b4ce6771b84d23d647f 201112 
libonig2-dbg_5.9.5-3.2+deb8u3_amd64.deb
 4ef1d29d6173271dd0b31d9971ea78f6c602785eb88e0451d3f722c5507e78fc 79628 
libonig-dev_5.9.5-3.2+deb8u3_amd64.deb
Files:
 1b84a8b079991bfca75df4159a06103d 1559 libs extra libonig_5.9.5-3.2+deb8u3.dsc
 d98726e472bee8d4992cf0c993a2e8a0 10636 libs extra 
libonig_5.9.5-3.2+deb8u3.debian.tar.xz
 d087b8813af79582c42af9a3444ea9cb 117756 libs optional 
libonig2_5.9.5-3.2+deb8u3_amd64.deb
 d3469c4643b1c963d72838e7ccb36acc 201112 debug extra 
libonig2-dbg_5.9.5-3.2+deb8u3_amd64.deb
 1865c23fb2a7c3d707485685190bc94e 79628 libdevel optional 
libonig-dev_5.9.5-3.2+deb8u3_amd64.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl16Df8ACgkQj/HLbo2J
BZ+bRwgAp//oHoNQVwM9RZ9YNqyzm2BWw+JPwb1CrRQFBMFz49AjEP/TgVHLe1r8
HR5+lZQSHp6KX+ga0dAMA+Tzv3/LHZ3qr4MgeFDToOBmMzo+KaSGeMBEnBiS1YiO
3QbVuFuk9JLPjZ1Ku9JAaSxQ2bHJyVJRcE6ZTn5wHHq9dErejW3aH+LIHxDOfzHW
WanflHqDDQUoivS/k1HVda+JmhW9yJEBoQFDXfWIEMUAFJdDnymteWCN2n9wBFWN
cpsnyb8TXQgflUI+MWLM9NDP2Nm2QgcSg1vJFZ58J+HtBaw7zReneIUQJylFWWs6
DMWhmSgW5r9aa/hdNrC5qaivMChRJw==
=zQ5X
-END PGP SIGNATURE-

[SECURITY] [DLA 1918-1] libonig security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: libonig
Version: 5.9.5-3.2+deb8u3
CVE ID : CVE-2019-16163
Debian Bug : 939988


The Oniguruma regular expressions library, notably used in PHP
mbstring, is vulnerable to stack exhaustion.  A crafted regular
expression can crash the process.

For Debian 8 "Jessie", this problem has been fixed in version
5.9.5-3.2+deb8u3.

We recommend that you upgrade your libonig packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl16EwoACgkQj/HLbo2J
BZ+eJgf+OU8NBd0fwtVEmF2UgU66npBCYlsoO62ZVFXg3NuDo37+c5VKaw8JLxA5
q4/TageYMoBPDOAxb3aMaizPPW3Tcon4eFHaZ1rV6l/4rWTB7jp8ru+BwsdObIoz
TIq4zGXlsYmMTC3S+u8UH1rsYkAANB5q5+Vy85BKuG8HOyxwassxgjmgW1quGfJ/
u8XB6unxSp/SzqZxH5+UFBu2dssP4o1GyNAZjcpf9naTiriyMk/AO1RU+tucRHMo
6USE5gNzFhoCiSQZRzjff2cYqd/88w/AsKq8G2gV1rAs1A0qcXSemFxA9iwD9q4A
39zRUUYSqosIBnv5aeOykQ2YQBVvnA==
=oiDK
-END PGP SIGNATURE-

qemu: request for testing

[Sylvain Beucler]

Hi,

A proposed security upload is available at:
https://www.beuc.net/tmp/debian-lts/qemu/

I would welcome testing, even if just one feature you use (qemu's
feature set is large).
I intend to upload within a week.

Cheers!
Sylvain

 qemu (1:2.1+dfsg-12+deb8u12) UNRELEASED-security; urgency=medium
 .
   * Non-maintainer upload by the LTS team.
 .
   [Mike Gabriel]
   * CVE-2017-9375: Track xhci_kick_ep processing being active in a
variable.
 Check the variable at the beginning of xhci_kick_ep. Add an assert
right
 before processing the kick.
   * CVE-2019-12155: qxl: Check release info object. When releasing spice
 resources in release_resource() routine, if release info object
 'ext.info' is null, it leads to null pointer dereference. Add check
 to avoid it.
   * CVE-2016-5403: virtio: error out if guest exceeds virtqueue size. Plus
 set vq->inuse correctly at various places.
   * CVE-2016-5126: block/iscsi: avoid potential overflow of acb->task->cdb.
   * Remove unused/redundant patch files.
 .
   [Sylvain Beucler]
   * CVE-2019-12068: scsi: lsi: exit infinite loop while executing script
   * CVE-2019-13164: qemu-bridge-helper.c in QEMU 4.0.0 does not ensure
 that a network interface name (obtained from bridge.conf or a
 --br=bridge option) is limited to the IFNAMSIZ size, which can
 lead to an ACL bypass.
   * CVE-2019-14378: ip_reass in ip_input.c in libslirp has a
 heap-based buffer overflow via a large packet because it
 mishandles a case involving the first fragment.
   * CVE-2019-15890: libslirp has a use-after-free in ip_reass in
ip_input.c.

Re: qemu status

[Sylvain Beucler]

Hi,

I have an updated package at:
https://www.beuc.net/tmp/debian-lts/qemu/

The packages appears globally stable with KVM and Xen.

I found 1 regression: connecting to qemu's VNC server crashes the process.
This means there's probably an issue among CVE-2017-15124's 10 patches :/
(on a positive note the memory exhaustion issue is definitely fixed ;))

I'm interested in backport details about this?

Cheers!
Sylvain

Re: qemu status

[Sylvain Beucler]

Ping?

- Sylvain

On 04/09/2019 15:41, Sylvain Beucler wrote:
> Hi Mike, hi all :)
>
> We have a prepared QEMU update from 3 months ago that needs attention:
> https://packages.sunweavers.net/debian/pool/main/q/qemu/
>
> It fixes:
> CVE-2017-9375 CVE-2019-12155 CVE-2017-15124 CVE-2016-5403 CVE-2016-5126
>
> Since then we got:
> CVE-2019-14378 CVE-2019-13164 CVE-2019-12068 CVE-2019-12067
> and possibly CVE-2018-19665 to reconsider.
>
> I can take the time to setup a physical box and provide more testing /
> more patching.
> Before doing so, I thought I'd first check:
> what are you plans for this month regarding this update? :)
>
> Cheers!
> Sylvain
>

Re: qemu status

[Sylvain Beucler]

Hi!

On Mon, Sep 09, 2019 at 06:35:37PM +, Mike Gabriel wrote:
> On  Mo 09 Sep 2019 11:23:59 CEST, Sylvain Beucler wrote:
> > On 04/09/2019 15:41, Sylvain Beucler wrote:
> > > We have a prepared QEMU update from 3 months ago that needs attention:
> > > https://packages.sunweavers.net/debian/pool/main/q/qemu/
> > > 
> > > It fixes:
> > > CVE-2017-9375 CVE-2019-12155 CVE-2017-15124 CVE-2016-5403 CVE-2016-5126
> > > 
> > > Since then we got:
> > > CVE-2019-14378 CVE-2019-13164 CVE-2019-12068 CVE-2019-12067
> > > and possibly CVE-2018-19665 to reconsider.
> > > 
> > > I can take the time to setup a physical box and provide more testing /
> > > more patching.
> > > Before doing so, I thought I'd first check:
> > > what are you plans for this month regarding this update? :)
> > Ping?
> 
> Thanks for pinging. And: sorry, I did not get any work on this done on
> Saturday.
> 
> Did you get any testing work done on this already? If not, I'd suggest to
> meet on IRC on Friday this week, after 10am (CEST) and get to work on this
> together. Is that a plan? Let me know, if you are available then.

No extensive testing yet.  I setup a physical Jessie machine (an
AMD/svm, btw) and started triaging the pending issues.

I plan to integrate more issues and prepare some tests (e.g. LVM so as
to test partition disk images and possibly install an old ProxMox).

I can make myself available on Friday 10AM, that sounds good.

Cheers!
Sylvain

Re: On tomcat FTBFS.

[Sylvain Beucler]

Hi,

It appears that the CVE-2017-5647 fix lacked this pre-requisite:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
https://svn.apache.org/viewvc?view=revision=1712081

The test case is not flacky anymore, I'm going to test full builds again.

Cheers!
Sylvain

On 07/08/2019 00:45, Sylvain Beucler wrote:
> Hi Markus,
>
> I'm investigating tomcat8's FTBFS and I confirm Abhijith's findings in a
> Jessie VM:
>
> - test catalina/connector/TestSendFile.java fails with nio2 connector
> but is not reliable and will report success ~1 out of 10 even with lots
> of exceptions; catalina.log will report header parsing error and return 400
>
> - it passes reliably without CVE-2017-5647.patch
>
> - the test certificate did expire on 2019-02-27 but changing the date to
> 2019-01-01 and rebuilding does not impact these results
> (incidentally the test certs seems to depend on an external CA
> ca-test.tomcat.apache.org, fixing the certs will require switching to
> the new-style local CA in tomcat8 - if fixing the certs is needed)
>
> As you fixed CVE-2017-5647 as well as generated the last jessie upload,
> I would be interested in your take on this :)
> TestSendFile only got trivial changes, so I guess I'll look for a fix in
> later changes affecting files modified by CVE-2017-5647.
> Still, I'm surprised updates were built given this situation - did
> everybody got lucky with the flacky test or did I miss something?
>
> Cheers!
> Sylvain
>
> On 27/07/2019 20:30, Abhijith PA wrote:
>> Hi,
>>
>>
>> I don't think the link you gave on commit [fe932dd39d] is the reason for
>> FTBFS. I tried building on a VM that matches the certificate date and it
>> was successful. I also tried disabling all ssl related tests and was fine.
>>
>> While doing these all I found TestSendFile test is the culprit. In
>> CVE-2017-5647 security patch a good amount of changes is applied for
>> SendFile*.java and *Nio2*.java. These are mostly about conditions on how
>> long the socket of sendfile keep active and to take away from it. But I
>> couldn't see any those change in its test file. Please take a look on
>> the attached patch. :)
>>
>>
>> --abhijith

Re: On tomcat FTBFS.

[Sylvain Beucler]

Hi,

So I reworked CVE-2017-5647, which involved 5 new commits related to
non-blocking I/O (NIO2 and COMET).
Stable build.

Then I got upstream to renew their new certs that were expiring tomorrow (!)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63648
and had to fix-up the SSL client tests accordingly (new client DN).

At last we have a working package that passes the testsuite.
How would you smoke-test it?
https://www.beuc.net/tmp/debian-lts/tomcat8/

(Now maybe I can start working on the actual CVEs :))

Cheers!
Sylvain

On 07/08/2019 12:29, Sylvain Beucler wrote:
> Hi,
>
> It appears that the CVE-2017-5647 fix lacked this pre-requisite:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
> https://svn.apache.org/viewvc?view=revision=1712081
>
> The test case is not flacky anymore, I'm going to test full builds again.
>
> Cheers!
> Sylvain
>
> On 07/08/2019 00:45, Sylvain Beucler wrote:
>> Hi Markus,
>>
>> I'm investigating tomcat8's FTBFS and I confirm Abhijith's findings in a
>> Jessie VM:
>>
>> - test catalina/connector/TestSendFile.java fails with nio2 connector
>> but is not reliable and will report success ~1 out of 10 even with lots
>> of exceptions; catalina.log will report header parsing error and return 400
>>
>> - it passes reliably without CVE-2017-5647.patch
>>
>> - the test certificate did expire on 2019-02-27 but changing the date to
>> 2019-01-01 and rebuilding does not impact these results
>> (incidentally the test certs seems to depend on an external CA
>> ca-test.tomcat.apache.org, fixing the certs will require switching to
>> the new-style local CA in tomcat8 - if fixing the certs is needed)
>>
>> As you fixed CVE-2017-5647 as well as generated the last jessie upload,
>> I would be interested in your take on this :)
>> TestSendFile only got trivial changes, so I guess I'll look for a fix in
>> later changes affecting files modified by CVE-2017-5647.
>> Still, I'm surprised updates were built given this situation - did
>> everybody got lucky with the flacky test or did I miss something?
>>
>> Cheers!
>> Sylvain
>>
>> On 27/07/2019 20:30, Abhijith PA wrote:
>>> Hi,
>>>
>>>
>>> I don't think the link you gave on commit [fe932dd39d] is the reason for
>>> FTBFS. I tried building on a VM that matches the certificate date and it
>>> was successful. I also tried disabling all ssl related tests and was fine.
>>>
>>> While doing these all I found TestSendFile test is the culprit. In
>>> CVE-2017-5647 security patch a good amount of changes is applied for
>>> SendFile*.java and *Nio2*.java. These are mostly about conditions on how
>>> long the socket of sendfile keep active and to take away from it. But I
>>> couldn't see any those change in its test file. Please take a look on
>>> the attached patch. :)
>>>
>>>
>>> --abhijith

Re: MariaDB uploaders: Please use Salsa and Salsa-CI

[Sylvain Beucler]

Hi,

On 25/07/2019 22:03, Otto Kekäläinen wrote:
> Hello Emilio and anybody else who might at some point upload MariaDB
> to jessie-security or stretch-security!
>
> Please use as the starting point the latest version in the MariaDB
> team Salsa repos
> - mariadb-10.0 branch 'jessie'
> - mariadb-10.1 branch 'stretch' (from 2020 onwards LTS)
>
> I have prepared there Gitlab-CI automation that does not affect the
> package itself in any way, but does help quite a bit in ensuring that
> whatever you upload is well tested and unlikely to cause regressions.
>
> Do not just checkout the latest version in Jessie or Stretch, but work
> using the repository instead. Also, please push to the branch when you
> are done. I am happy to include LTS maintainers in the mariadb-team so
> you can use the official repository. (Emilio is already there.)
>
> Repo and example of pipeline:
> - https://salsa.debian.org/mariadb-team/mariadb-10.0/pipelines
> - https://salsa.debian.org/mariadb-team/mariadb-10.1/pipelines
>
> Slides on my talk on MariaDB packaging and Salsa-CI/Gitlab-CI use in
> case you are interested in the longer story:
> https://www.slideshare.net/ottokekalainen/how-mariadb-packaging-uses-salsaci-to-ensure-smooth-upgrades-and-avoid-regressions
>
>
> - Otto
>
> PS. I've done this all assuming the security uploads in this case do
> allow changes to the debian/gitlab-ci.yml file since it does not cause
> functional changes to the package itself and is perfectly safe.

Thanks for improving security by providing easier testing :)
I referenced your e-mail at:
https://wiki.debian.org/LTS/TestSuites

Cheers!
Sylvain

Re: On tomcat FTBFS.

[Sylvain Beucler]

Hi Markus,

I'm investigating tomcat8's FTBFS and I confirm Abhijith's findings in a
Jessie VM:

- test catalina/connector/TestSendFile.java fails with nio2 connector
but is not reliable and will report success ~1 out of 10 even with lots
of exceptions; catalina.log will report header parsing error and return 400

- it passes reliably without CVE-2017-5647.patch

- the test certificate did expire on 2019-02-27 but changing the date to
2019-01-01 and rebuilding does not impact these results
(incidentally the test certs seems to depend on an external CA
ca-test.tomcat.apache.org, fixing the certs will require switching to
the new-style local CA in tomcat8 - if fixing the certs is needed)

As you fixed CVE-2017-5647 as well as generated the last jessie upload,
I would be interested in your take on this :)
TestSendFile only got trivial changes, so I guess I'll look for a fix in
later changes affecting files modified by CVE-2017-5647.
Still, I'm surprised updates were built given this situation - did
everybody got lucky with the flacky test or did I miss something?

Cheers!
Sylvain

On 27/07/2019 20:30, Abhijith PA wrote:
> Hi,
>
>
> I don't think the link you gave on commit [fe932dd39d] is the reason for
> FTBFS. I tried building on a VM that matches the certificate date and it
> was successful. I also tried disabling all ssl related tests and was fine.
>
> While doing these all I found TestSendFile test is the culprit. In
> CVE-2017-5647 security patch a good amount of changes is applied for
> SendFile*.java and *Nio2*.java. These are mostly about conditions on how
> long the socket of sendfile keep active and to take away from it. But I
> couldn't see any those change in its test file. Please take a look on
> the attached patch. :)
>
>
> --abhijith

[SECURITY] [DLA 1868-1] squirrelmail security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: squirrelmail
Version: 2:1.4.23~svn20120406-2+deb8u4
CVE ID : CVE-2019-12970

A XSS vulnerability was discovered in SquirrelMail.  Due to improper
handling of RCDATA and RAWTEXT type elements, the built-in
sanitization mechanism can be bypassed.  Malicious script content from
HTML e-mails can be executed within the application context via
crafted use of (for example) a NOEMBED, NOFRAMES, NOSCRIPT, or
TEXTAREA element.

For Debian 8 "Jessie", this problem has been fixed in version
2:1.4.23~svn20120406-2+deb8u4.

We recommend that you upgrade your squirrelmail packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl1C4F8ACgkQj/HLbo2J
BZ/kBggAmwy9ffidiiylbERfzs/mMJS+5vQvAN3UomC30ZyHSXkQp1gWFxxWmAUG
bEyP7tvjqvRZRy69Ltmn1YIDrL7Vp5/Ub4ese6Jq3KO905mwjaA67Yy5EizQNluf
CITss1tlGTIq9ip1khYWomFmv25gwDpwyKVP/LCR4gtdTlCsAeq7sdAgGpkJG/Rv
ZSkS4USD6vnNJuyVDwERGYTYdo2A795DlRB/OI9mV4kwtOl0Xxpl/z0X0I/3USP5
sOZNW1w022/J4pwcoqR7hFsU5f2nNu04YdxUfAs7uh0qBoAJxxcGJNHBhjMUqlt7
GJJYlyZw1XfvVU5n5ToQCTsFMLqe5w==
=RxBX
-END PGP SIGNATURE-

Upload good practices

[Sylvain Beucler]

Hi,

I added a couple mementos at https://wiki.debian.org/LTS/Development about 
building and testing security uploads.
Let me know if this can be improved :)

Copy/paste:

- pbuilder usage:
# Init (note: jessie->jessie buggy 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806377)
sudo pbuilder --create --basetgz /var/cache/pbuilder/base-jessie.tgz \
  --distribution jessie \
  --othermirror 'deb http://security.debian.org/ jessie/updates main contrib'
sudo pbuilder --update --basetgz /var/cache/pbuilder/base-jessie.tgz
# Rebuild source and binary packages from Jessie (in extracted source)
pdebuild --use-pdebuild-internal --buildresult .. -- --basetgz 
/var/cache/pbuilder/base-jessie.tgz
# Rebuild binary packages from Jessie
sudo pbuilder --build --basetgz /var/cache/pbuilder/base-jessie.tgz 
--debbuildopts '-sa' package+deb8u1.dsc
sudo pbuilder --build --basetgz /var/cache/pbuilder/base-jessie.tgz 
package+deb8u2.dsc

- testing:
# check for common packaging issues in last build
# from extracted source after build, jessie host (only check new errors)
lintian -i
# inspect source changes
debdiff package+deb8u3.dsc package+deb8u4.dsc
# inspect binary changes
debdiff --from deb8u3/*.deb --to deb8u4/*.deb
# test package upgrade
sudo piuparts -d jessie \
  --extra-repo='deb http://security.debian.org/ jessie/updates main contrib' \
  -l piuparts-package.log \
  -I :etc/buggy-dep \
  package+deb8u4_amd64.changes \
  | grep -P '(INFO|ERROR):'

Cheers!
Sylvain

Re: New list: lts-do-call-me

[Sylvain Beucler]

Hi Markus,

On 17/07/2019 17:16, Markus Koschany wrote:
> Am 17.07.19 um 16:46 schrieb Roberto C. Sánchez:
>> On Wed, Jul 17, 2019 at 11:26:56AM -0300, Markus Koschany wrote:
>>> lts-do-call-me contains all maintainers and/or source
>>> packages that should be handled by the maintainer. Please contact all
>>> maintainers in this list before starting to work on the package. There
>>> are some other maintainers who regularly provide updates themselves,
>>> please update the list as needed and share any information you have.
>>>
>> Is it correct to assume that packages will be noted with this
>> information when triaged into dla-needed.txt?  I've seen some that have
>> a note like, "maintainer will handle update," so I assume that it is
>> part of the front desk procedure. 
> Yes, ideally this should be managed by frontdesk. So if you are not
> already aware of it take a look at both files and then add the package
> with a note.
>
>> Likewise, I would expect a note
>> indicating that the maintainer has been contacted and stating either
>> that no response has been received yet, or a response has been received
>> saying that we should go ahead or let the maintainer handle it (as
>> appropriate).
>>
>> Do I understand correctly?
> I think that works as before. We already do it this way. For the
> majority of packages nothing will change but for those packages in
> lts-do-call-me we should take extra care and note any responses of the
> maintainer and follow-up as necessary.
Would you be so kind as to update the wiki
https://wiki.debian.org/LTS/Development
to clarify what front-desk needs to do / not to do?

I'm not sure what the workflow is (notify maintainer and add to
dla-needed.txt stating so? not add to dla-needed until maintainer acked?
also how to detect when a package maintainer changed and hence
lts-do-call-me needs to be updated / new maintainer asked for their
preference?).

Last, do we drop 'lts-do-no-call'?

Cheers!
Sylvain

Re: [SECURITY] [DLA 1942-1] phpbb3 security update

[Sylvain Beucler]

Hi Gabriel,

I see you reverted affectation for CVE-2019-13376.

CVE-2019-13376 is an follow-up fix to CVE-2019-16993 (2016) which I
registered just yesterday toclarify that we've been missing this earlier
fix (AFAICS unsuccessfully ;)).

CVE-2019-13376 applies to 3.2.7 which already has the fix that you
thought was related (phpbb's SECURITY-231), which is a different
"vulnerability" (with quotes, as it just disables a feature by default,
which is expected to be re-enabled for CVE-2019-13376 to apply, as
mentioned in the write-up: "in the ACP, go to General > Avatar settings
and enable remote avatars").

Consequently DLA 1942-1 fixes CVE-2019-13376 and CVE-2019-16993.
SECURITY-231 doesn't have a CVE assigned.

Cheers!
Sylvain

On 01/10/2019 01:44, Mike Gabriel wrote:
> Package: phpbb3
> Version: 3.0.12-5+deb8u4
> CVE ID : CVE-2019-16993
>
>
> In phpBB, includes/acp/acp_bbcodes.php had improper verification of a
> CSRF token on the BBCode page in the Administration Control Panel. An
> actual CSRF attack was possible if an attacker also managed to retrieve
> the session id of a reauthenticated administrator prior to targeting
> them.
>
> The description in this DLA does not match what has been documented in
> the changelog.Debian.gz of this package version. After the upload of
> phpbb3 3.0.12-5+deb8u4, it became evident that CVE-2019-13776 has not yet
> been fixed. The correct fix for CVE-2019-13776 has been identified and
> will be shipped in a soon-to-come follow-up security release of phpbb3.
>
> For Debian 8 "Jessie", these problems have been fixed in version
> 3.0.12-5+deb8u4.
>
> We recommend that you upgrade your phpbb3 packages.
>
> Further information about Debian LTS security advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://wiki.debian.org/LTS
>

Re: [SECURITY] [DLA 1942-1] phpbb3 security update

[Sylvain Beucler]

Hi Mike,

On Wed, Oct 02, 2019 at 02:01:25PM +, Mike Gabriel wrote:
> On  Di 01 Okt 2019 13:32:25 CEST, Sylvain Beucler wrote:
> > I see you reverted affectation for CVE-2019-13376.
> > 
> > CVE-2019-13376 is an follow-up fix to CVE-2019-16993 (2016) which I
> > registered just yesterday toclarify that we've been missing this earlier
> > fix (AFAICS unsuccessfully ;)).
> > 
> > CVE-2019-13376 applies to 3.2.7 which already has the fix that you
> > thought was related (phpbb's SECURITY-231), which is a different
> > "vulnerability" (with quotes, as it just disables a feature by default,
> > which is expected to be re-enabled for CVE-2019-13376 to apply, as
> > mentioned in the write-up: "in the ACP, go to General > Avatar settings
> > and enable remote avatars").
> > 
> > Consequently DLA 1942-1 fixes CVE-2019-13376 and CVE-2019-16993.
> > SECURITY-231 doesn't have a CVE assigned.
> 
> Are you 100% sure on this?

That's what I conclude by reading the write-up and the code (and
requesting the new CVE).  I didn't exploit the vulnerability.

If you wish to fix SECURITY-231 though you could request a CVE and fix
it independently.

> Let me collect my todos for this, then:
> 
>   * Uploaded package is ok (3.0.12-5+deb8u4), even the debian/changelog
> entry(?)

The changelog entry looks OK.

>   * security-tracker (data/DLA/list) needs to be adapted and CVE-2019-13376
> needs to be re-added to DLA-1942-1(?)

I did so yesterday.

>   * the dla-announcement needs to be re-done / replied to, and it needs to be
> declared that CVE-2019-13376 is in fact already fixed by +deb8u4
>   * furthermore, I referenced  CVE-2019-13776 in the announcement,
> rather than CVE-2019-13376 (typo, g...)
> 
> Correct?

That sounds right.

> Thanks for spotting this!

NP, I was just doing FrontDesk :)

Cheers!
Sylvain

Re: firefox-esr 60.9.0esr-1~deb8u1 i386 build

[Sylvain Beucler]

Hello,

On 27/09/2019 23:12, Pascal Hambourg wrote:
> Sorry to insist again, but is there any hope that the i386 build will
> be available ?

It seems this is a memory issue on the builder:

virtual memory exhausted: Operation not permitted
/<>/config/rules.mk:1054: recipe for target 
'Unified_cpp_protocol_http1.o' failed
make[5]: *** [Unified_cpp_protocol_http1.o] Error 1

Is there a simple way to restart the build, possibly without parallelism?

Emilio?

Cheers!
Sylvain Beucler - Debian LTS Team

Accepted qemu 1:2.1+dfsg-12+deb8u12 (source amd64) into oldoldstable

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 11 Sep 2019 11:56:13 +0200
Source: qemu
Binary: qemu qemu-system qemu-system-common qemu-system-misc qemu-system-arm 
qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-user 
qemu-user-static qemu-user-binfmt qemu-utils qemu-guest-agent qemu-kvm
Architecture: source amd64
Version: 1:2.1+dfsg-12+deb8u12
Distribution: jessie-security
Urgency: medium
Maintainer: Debian QEMU Team 
Changed-By: Sylvain Beucler 
Description:
 qemu   - fast processor emulator
 qemu-guest-agent - Guest-side qemu-system agent
 qemu-kvm   - QEMU Full virtualization on x86 hardware
 qemu-system - QEMU full system emulation binaries
 qemu-system-arm - QEMU full system emulation binaries (arm)
 qemu-system-common - QEMU full system emulation binaries (common files)
 qemu-system-mips - QEMU full system emulation binaries (mips)
 qemu-system-misc - QEMU full system emulation binaries (miscelaneous)
 qemu-system-ppc - QEMU full system emulation binaries (ppc)
 qemu-system-sparc - QEMU full system emulation binaries (sparc)
 qemu-system-x86 - QEMU full system emulation binaries (x86)
 qemu-user  - QEMU user mode emulation binaries
 qemu-user-binfmt - QEMU user mode binfmt registration for qemu-user
 qemu-user-static - QEMU user mode emulation binaries (static version)
 qemu-utils - QEMU utilities
Changes:
 qemu (1:2.1+dfsg-12+deb8u12) jessie-security; urgency=medium
 .
   * Non-maintainer upload by the LTS team.
 .
   [Mike Gabriel]
   * CVE-2017-9375: Track xhci_kick_ep processing being active in a variable.
 Check the variable at the beginning of xhci_kick_ep. Add an assert right
 before processing the kick.
   * CVE-2019-12155: qxl: Check release info object. When releasing spice
 resources in release_resource() routine, if release info object
 'ext.info' is null, it leads to null pointer dereference. Add check
 to avoid it.
   * CVE-2016-5403: virtio: error out if guest exceeds virtqueue size. Plus
 set vq->inuse correctly at various places.
   * CVE-2016-5126: block/iscsi: avoid potential overflow of acb->task->cdb.
   * Remove unused/redundant patch files.
 .
   [Sylvain Beucler]
   * CVE-2019-12068: scsi: lsi: exit infinite loop while executing script
   * CVE-2019-13164: qemu-bridge-helper.c in QEMU 4.0.0 does not ensure
 that a network interface name (obtained from bridge.conf or a
 --br=bridge option) is limited to the IFNAMSIZ size, which can
 lead to an ACL bypass.
   * CVE-2019-14378: ip_reass in ip_input.c in libslirp has a
 heap-based buffer overflow via a large packet because it
 mishandles a case involving the first fragment.
   * CVE-2019-15890: libslirp has a use-after-free in ip_reass in ip_input.c.
Checksums-Sha1:
 4acefb7d871bc0d17f87c7970d2fcf560a3d971f 5193 qemu_2.1+dfsg-12+deb8u12.dsc
 964a44f2db3bc24ebe0e1cb4e445ea14dd54e9ad 223924 
qemu_2.1+dfsg-12+deb8u12.debian.tar.xz
 fa3a787fe60a85d5d3dfba8ea05439bb5b719809 126996 
qemu_2.1+dfsg-12+deb8u12_amd64.deb
 5ed3b13f43d2e55d0f31972c163d22d1da0ad5ed 56230 
qemu-system_2.1+dfsg-12+deb8u12_amd64.deb
 3cc4435e0aa76321a87630d7bf09b10eee75675b 286938 
qemu-system-common_2.1+dfsg-12+deb8u12_amd64.deb
 07dbe5deecd3800e0848ff36e2a8446e8767a182 4795244 
qemu-system-misc_2.1+dfsg-12+deb8u12_amd64.deb
 9295641efd9cfd44694eb1e423e075f84f0e23ab 2240822 
qemu-system-arm_2.1+dfsg-12+deb8u12_amd64.deb
 a5eae3703d9f833ffa5b8ee476fff37c61c52f9b 2841670 
qemu-system-mips_2.1+dfsg-12+deb8u12_amd64.deb
 b332d823ae8c9cb05d144e72c3ad5112fcb65088 2750384 
qemu-system-ppc_2.1+dfsg-12+deb8u12_amd64.deb
 112d0b66616a81ad7989ee9867672261a8afcca2 1673754 
qemu-system-sparc_2.1+dfsg-12+deb8u12_amd64.deb
 3c28434b3a212c8f10f1c75b79c9b0c69b2c47c9 2050640 
qemu-system-x86_2.1+dfsg-12+deb8u12_amd64.deb
 1c3cdde2d2f54761263c9166fba43200d4c6505c 6114562 
qemu-user_2.1+dfsg-12+deb8u12_amd64.deb
 ea0ef1aaafb429abe81946a93d07d466b99f6a60 8393026 
qemu-user-static_2.1+dfsg-12+deb8u12_amd64.deb
 d3ad6dd0db93f0236f5bf05bc71bcb34c7170a99 2932 
qemu-user-binfmt_2.1+dfsg-12+deb8u12_amd64.deb
 f85bab6b6c469efd0208da378e025c8f45cf885b 487968 
qemu-utils_2.1+dfsg-12+deb8u12_amd64.deb
 5ffd889d65f4fdc57d5773d15818738da88fd1ea 140284 
qemu-guest-agent_2.1+dfsg-12+deb8u12_amd64.deb
 3a326759e3eb4e7e41c8cc02fe085e176806899f 56894 
qemu-kvm_2.1+dfsg-12+deb8u12_amd64.deb
Checksums-Sha256:
 9798c54b3cc0e1aa5baac8c5269ecf989ab65c091647c283d747141ad7440f41 5193 
qemu_2.1+dfsg-12+deb8u12.dsc
 7fed0281e9e41bb1cd1517223ce57c95cf69765551a070f457653c859802bbf6 223924 
qemu_2.1+dfsg-12+deb8u12.debian.tar.xz
 1197c0aeec9a512101dfbf723414c39c6c65e995eb4b7cfddba1e6436e05b349 126996 
qemu_2.1+dfsg-12+deb8u12_amd64.deb
 39729d2e28265e1612cb861e762771dbb703431bb0aee083a6afc743f1e45bb9 56230 
qemu-system_2.1+dfsg-12+deb8u12_amd64.deb
 6533502e56c381d08cb2e7a84594fa57cb3e1b5be6bea65e417874c3abaebd4b 286938 
qemu-system-common_2.1+dfsg-12+deb8u12_

[SECURITY] [DLA 1927-1] qemu security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: qemu
Version: 1:2.1+dfsg-12+deb8u12
CVE ID : CVE-2016-5126 CVE-2016-5403 CVE-2017-9375 CVE-2019-12068 
 CVE-2019-12155 CVE-2019-13164 CVE-2019-14378 CVE-2019-15890
Debian Bug : 826151 832619 864219 929353 931351 933741 933742 939868 939869


Several vulnerabilities were found in QEMU, a fast processor emulator
(notably used in KVM and Xen HVM virtualization).

CVE-2016-5126

Heap-based buffer overflow in the iscsi_aio_ioctl function in
block/iscsi.c in QEMU allows local guest OS users to cause a
denial of service (QEMU process crash) or possibly execute
arbitrary code via a crafted iSCSI asynchronous I/O ioctl call.

CVE-2016-5403

The virtqueue_pop function in hw/virtio/virtio.c in QEMU allows
local guest OS administrators to cause a denial of service (memory
consumption and QEMU process crash) by submitting requests without
waiting for completion.

CVE-2017-9375

QEMU, when built with USB xHCI controller emulator support, allows
local guest OS privileged users to cause a denial of service
(infinite recursive call) via vectors involving control transfer
descriptors sequencing.

CVE-2019-12068

QEMU scsi disk backend: lsi: exit infinite loop while executing
script

CVE-2019-12155

interface_release_resource in hw/display/qxl.c in QEMU has a NULL
pointer dereference.

CVE-2019-13164

qemu-bridge-helper.c in QEMU does not ensure that a network
interface name (obtained from bridge.conf or a --br=bridge option)
is limited to the IFNAMSIZ size, which can lead to an ACL bypass.

CVE-2019-14378

ip_reass in ip_input.c in libslirp 4.0.0 has a heap-based buffer
overflow via a large packet because it mishandles a case involving
the first fragment.

CVE-2019-15890

libslirp 4.0.0, as used in QEMU, has a use-after-free in ip_reass
in ip_input.c.

For Debian 8 "Jessie", these problems have been fixed in version
1:2.1+dfsg-12+deb8u12.

We recommend that you upgrade your qemu packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEQic8GuN/xDR88HkSj/HLbo2JBZ8FAl2EkSsACgkQj/HLbo2J
BZ8/AQf6AmErhOVKqKi+8HVX5GIdlfM25ZPGP1Qi6FDMTsHxqeWNJQZ8zceoZAnq
8/y+UTvpnHiwegB5rQCE5p7hf/dkVkVqqHMwSChdxtuBw9wZc6Wa9oPwwZFX84Hv
gC2q0rHIfBL1m9t0yO0OhWPwxd9ReizeLI6GmLGZNAlob7jKDPi4hzvDtZx4Pnwb
jYDNVihhepdYcVmTbIh9c9bSboHatsbLTySgltN8pTkW1zmCeBauqntwS8P5S1YO
9UqpIAbpfpnIiUwv/0mZSLJAd7100gyl2OcdhAe+y3/RK8jfc/6vCUhJE9a2gYBB
eamzL+01LkHnGrBssrvO2rXoR1tA+w==
=tnrb
-END PGP SIGNATURE-

Re: CVE-2019-16935/python*

[Sylvain Beucler]

Hi,

On 28/09/2019 22:36, Ola Lundqvist wrote:
> I have looked a little into CVE-2019-16935. My conclusion is that the
> package is vulnerable but I could not really judge its severity. I have
> a question though. If we find that we should correct it, shouldn't we
> correct also jython and pypy-lib in that case?
> 
> The problem is in DocXMLRPCServer.py and that file exist also in the
> other two packages. Or should we assume there will be a different CVE
> for those packages?
> 
> https://packages.debian.org/search?searchon=contents=DocXMLRPCServer.py=exactfilename=oldstable=any
>   

I would reference python and pypy-lib in data/CVE/list, indeed.
Do you want to do that?

As for the severity, from what I read this is a reflected XSS, that is
also hypothetical as this would affect an unknown third-party app making
use of DocXMLRPCServer and setting the server title from untrusted input.
So low IMHO.

Cheers!
Sylvain

Training process

[Sylvain Beucler]

Hi,

First, welcome to Utkarsh Gupta in the team :)

>From what I understand there was a training during July and August,
resulting in active status this month.
I saw zero traces of this training besides a passing anonymous
mention in Raphael's reports.
Possibly we can clarify this a lil' bit? Or did I miss an information
source?

This would also help welcome new members, I myself remember a solid
silence when I joined (while I explicitly introduced my application at
debian-lts@l.d.o).

Cheers!
Sylvain

Re: Training process

[Sylvain Beucler]

Hi,

Team ACME gets a new member. No reaction.
When asked what happened:
- team member A: no time
- team member B: not a documented process
- team member C: maybe new member did something wrong
- team member D: will be introduced in 3 weeks with the report
- team member E: I thought it was a user
- other members: ...

No judgement, I guess I love team ACME as it is :)

Cheers!
Sylvain

Re: cpio and CVE-2019-14866 for testing

[Sylvain Beucler]

Hi,

On 29/10/2019 23:12, Ola Lundqvist wrote:
> Hi LTS contributors
>
> I have built a cpio package with CVE-2019-14866 corrected.
> According to my testing it is no longer possible to reproduce the
> problem reported in this CVE.
>
> You can find the packages I have produced here:
> http://apt.inguza.net/jessie-security/cpio
>
> The (so far rather limited) testing I have done can be found in
> README.testresult
> How to reproduce the problem can be found in the patch. It is easy to
> reproduce the problem on both jessie and wheezy.
>
> The debdiff is found in cpio.debdiff.
>
> Since cpio is a rather crucial package I would like some more people
> to test this package. At least for regression.

I got contacted by cpio maintainer Sergey Poznyakoff 
who told me he was in process of fixing it.

You could coordinate with him and/or watch the upstream git repo for a
sanctioned patch, which should help with your testing requirements :)

Cheers!
Sylvain

Re: Security issues in standards (ruby-openid / CVE-2019-11027)

[Sylvain Beucler]

Hi,

On 06/11/2019 21:14, Utkarsh Gupta wrote:
> On 06/11/19 11:47 am, Brian May wrote:
>> Utkarsh Gupta  writes:
>>
>>> I am not quite sure about what should we do here because the update (DLA
>>> 1956-1) doesn't quite fix the CVE completely and also brings some login
>>> problems as reported in #125.
>>> Because for now, #121 + #126 = actual CVE fix. But the login problem
>>> remains.
>> I guess we have three options:
>>
>> 1. Do nothing.
>> 2. Revert the #121 patch, because it could break. I haven't seen any
>> complaints however...
> Whilst that is true, I'd rather not want someone to face an "unexpected
> response" error.
> Though I hope no one is using that feature yet :)
>
>> 3. Apply the #126 patch too. Not 100% convinced this is a justified
>> change for LTS, but it "looks right".
>> 4. Wait longer for possible upstream solution to #125.
>>
>> Any opinions?
> I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd.
Do the package maintainers have an opinion on this?
This can help.

Raphael, given that this package is low popcon and the vulnerability is
fuzzy, do you know if the sponsor for this package would be willing to
test fixes?

Cheers!
Sylvain

Re: Introduction new LTS trainee

[Sylvain Beucler]

Hi,

On 06/11/2019 12:22, Dylan Aïssi wrote:
> After several emails exchanged with Holger and Raphaël, I am now a LTS
> trainee :-).
> I am still learning how to deal with the LTS workflow, so you can
> expect some questions from my side.
>
> Otherwise, I am DD since September 2018 and mainly involved in the
> Debian Med team and in the Debian R Packages team. Why these teams?
> Because IRL, I am an academic data scientist / bioinformatician
> working in biomedical research. And before that, I started to
> contribute to Debian in 2014 through the "New Contributor Game" from
> Raphaël.
Welcome!

Having on board somebody who understands R sounds good ;)

Any past encounters with computer security?

Cheers!
Sylvain

Re: (E)LTS report for October

[Sylvain Beucler]

Hi,

On 10/11/2019 21:41, Brian May wrote:
> Holger Levsen  writes:
>
>> then, just for the record, this was discussed with Raphael and me. Please
>> don't do more hours than assigned without coordination. See "What should
>> I do if I work more than the hours allocated?" in debian-lts.git for
>> more info.
> Huh? I don't see anything about requiring coordination here. Just bill
> the hours for your next month. Did I miss something?

I believe it's a matter of magnitude: the doc's example is about a 10%
excess, while this was about a ~200% excess.

Coordination allows to average the workload and reactivity, for instance
by adding more people to a task, reassigning the task, reconsidering the
task's scope, etc.
In this particular case it seems they decided to move the hours, but
that's not something one can decide on their own, at this scale.
(There may also be legal issues with billing hours while no hours were
done that particular month, AINAL.)

Cheers!
Sylvain