Re: failed armel build of wireshark 1.12.1+g01b65bf-4+deb8u19
On 30/05/2019 09:37, Hugo Lefeuvre wrote: > Hi, > > Apparently, wireshark 1.12.1+g01b65bf-4+deb8u19 failed to build on armel. I > have absolutely no idea of what happened. At first glance it looks like tar > segfaulted[0] :-) > > Is it possible to restart the build for armel?# Given back. Emilio
(E)LTS report for May
Hi, During the month of May, I spent 33h on LTS working on the following tasks: - openjdk-7 security update - qemu security update - security-tracker reviews - sqlite3 triage - sox: backported patches, run into stability bug in jessie not happening in sid, bisected it but fix was too invasive so released other fixes - jruby: investigated build issue reported by Abhijith - samba security update - firefox-esr security update - started to look at how to handle firefox-esr 68 for jessie - thunderbird security update - CVE triaging - php5: started with the new issues, but waited for official upstream release - backporting fixes for poppler issues For ELTS I spent 12h on the following: - openjdk-7 security update - intel-microcode: backported security update - php5: backported fixes but waited for upstream release - CVE triaging / frontdesk Cheers, Emilio
(E)LTS report for June & July
Hi, during the month of June I spent 16h (of 17 assigned) on LTS on the following tasks: - CVE triaging - php5 update - looked at vim update, coordinated with maintainer - poppler update - dbus update - thunderbird update - firefox-esr update - another thunderbird update During the month of July I spent 5h (of 18.5) on: - firefox and thunderbird updates (took longer than usual due to a problem on unzip caused by the last security update which I had to investigate to find the root cause) For ELTS, I spent 10h on June on the following tasks: - php5 update - mysql-5.5 EOL - CVE triaging - dbus update - intel-microcode update No work done on July. Cheers, Emilio
Re: Accepted firefox-esr 60.9.0esr-1~deb8u1 (source amd64 all) into oldoldstable
On 07/09/2019 10:01, Pascal Hambourg wrote: > Hello, > > It seems that the i386 build failed. Thanks for the notice. I'll take a look at it. Emilio
(E)LTS report for August
Hi, During the month of August I spent 31 hours on the following tasks: - php5 update - ghostscript update - CVE triaging - evince update - atril update - preparatory work for firefox ESR 68 and thunderbird 68 As for ELTS I spent 8.5h on the following: - php5 update - CVE triaging - Investigated gen-ELA version issue (the fix requires merge-conflicting-changes, hopefully to be addressed with some pending sec-tracker improvements) Cheers, Emilio
Re: firefox-esr 60.9.0esr-1~deb8u1 i386 build
On 30/09/2019 06:40, Sylvain Beucler wrote: > 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? That wouldn't help. Sorry it took me longer than I expected but the firefox build system is quite particular and I had trouble injecting build flags that wouldn't get overriden. This is fixed now as deb8u2, i386 binaries are already available. Cheers, Emilio
(E)LTS report for September
Hi, During the month of September I spent 30 hours on the following tasks: - firefox ESR 60 update - thunderbird ESR 60 update - ghostscript update - firefox ESR 68 preparations for jessie and stretch (LLVM 7, cargo, rust, cbindgen, nasm, nodejs) As for ELTS I spent 4 hours on frontdesk triage. Cheers, Emilio
(E)LTS report for October
Hi, During the month of October I spent 72 hours on finishing the Firefox ESR 68 update. That update took so much time due to the necessary toolchain updates, which included rust & cargo, LLVM, and GCC, and to several issues which were encountered with some of those components and with some old versions of packages in jessie, and with the Firefox build itself. The work was done for both Debian jessie and stretch, so that we can keep supporting Firefox when stretch becomes LTS a few months from now. In addition to that, I spent 3 hours updating tzdata and libdatetime-timezone-perl for LTS and ELTS. Since the hours spent on LTS were higher than my allotted time, my November hours will be used for that, as well as a few from ELTS, and I will work on the remaining tasks on my own time (finishing the Thunderbird update for jessie, as well as fixing the armhf build). Cheers, Emilio
Re: Drop support for libqb?
On 14/11/2019 19:51, Roberto C. Sánchez wrote: > On Thu, Nov 14, 2019 at 01:31:27PM -0500, Roberto C. Sánchez wrote: >> On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: >>> On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > We usually mark affected CVE as in data/CVE/list and just > add the package to security-support-ended.deb8 in > debian-security-support. We then upload new versions of the package > periodically and announce it via DLA. I believe now is a good time to do > it. Thanks for the information. I will start working on it today. >>> >>> As any DD can commit to debian-security-support.git and also can upload >>> that package, just make sure to call it a team upload in d/changelog to >>> appease lintian and possibly other tools. >>> >> I had not yet seen this message so I already submitted a MR. Should I >> close that and make a direct commit? >> >>> And then it would be ideal to upload the package to unstable and then >>> file a SRM bug to update the package in stretch, in addition to >>> uploading to jessie. (Probably this should also result in a DLA, not >>> 100% sure though. Thoughts & comments definitly welcome.) >>> >> >> Looking at the previous updates, a DLA seems appropriate. I am in the >> process of drafting the text. >> >>> I believe it's fine if the version contraints (package version in >>> unstable higher than testing higher than stable higher than oldstable) >>> are temporarily not met, but I also believe it's important that they are >>> in the long run & most of the time. >>> >>> If doing all this work is too much or tedious to you, please shout and I >>> will be happy to finish this. Please just do at least the initial >>> change in git to security-support-ended.deb8. >>> >> If I close the MR and commit directly, is it then a simple matter of >> build and upload to unstable? That is, no other special steps are >> required? >> > Some additional follow-up: > > - Can I go ahead and mark the CVE in question as in > data/CVE/list even before the update to debian-security-support is > complete? Yeah that should be alright. > - Any feedback on this proposed DLA text? > > Package: debian-security-support > Version: 2019.11.15~deb8u1 > > > debian-security-support, the Debian security support coverage checker, > has been updated in jessie. > > This marks the end of life of the libqb package in jessie. A recently > reported vulnerability against libqb which allows users to overwrite > arbitrary files via a symlink attack cannot be adequately addressed in > libqb in jessie. Upstream no longer supports this version and no > packages in jessie depend upon libqb, thus making it a leaf package. > > We recommend that if your systems or applications depend upon the libqb > package provided from the Debian archive that you upgrade your systems > to a more recent Debian release or find an alternate and up to date > source of libqb packages. Looks fine to me. I have also noticed that we didn't get a debian-security-support update for the mysql-5.5 EOL, so if you can add a paragraph about it in the announcement (the changes to the debian-security-support were already there) that'd be great. Something such as: In addition to that, MySQL 5.5 is no longer supported as upstream ended its support and we are unable to backport fixes from newer versions due to the lack of patch details. Options are to switch to MariaDB 10.0 in jessie or to a newer version in more recent Debian releases.
(E)LTS report for November
Hi, During the month of November I worked on the Thunderbird update after the toolchain update work for Firefox ESR 68 made that possible. I also spent time working on build fixes for Firefox (on armhf for jessie, as well as various other issues on stretch). Those will also benefit Thunderbird. That work was done on my own time. For ELTS, I have spent 21h improving the security tracker to not hardcode supported releases across the tracker code. That will improve the maintainability of the tracker, as well as make it easier for third parties to add their own releases (such as ELTS itself). This work is in its review phase at this stage. Cheers, Emilio
Re: ibus/CVE-2019-14822/glibc
On 13/12/2019 05:41, Brian May wrote: > Brian May writes: > >> Apparently the fix for ibus creates a regression in glibc that must get >> fixed also: >> >> https://gitlab.gnome.org/GNOME/glib/merge_requests/1176 >> >> However this patch patches GIO in glibc, and it looks like glibc in >> Jessie (2.19-18+deb8u10) doesn't have this directory. Or anything >> related to GIO that I can see. >> >> Hence, I am inclined to think maybe glibc doesn't need to be fixed in >> Jessie. > > i have back-ported the patches to the Jessie version. Hopefully this is > correct :-) > > https://gitlab.gnome.org/penguin_brian/glib/compare/2.42.1...fix_gio_auth > > If I incorporate the test patch into the Debian package, expecting a > test failure, instead I get the following results: > > SKIP: gdbus-server-auth 1 /gdbus/server-auth # SKIP Testing interop with > libdbus not supported > SKIP: gdbus-server-auth 2 /gdbus/server-auth/tcp # SKIP Testing interop with > libdbus not supported > SKIP: gdbus-server-auth 3 /gdbus/server-auth/anonymous # SKIP Testing interop > with libdbus not supported > SKIP: gdbus-server-auth 4 /gdbus/server-auth/external # SKIP EXTERNAL > authentication not implemented on this platform > SKIP: gdbus-server-auth 5 /gdbus/server-auth/sha1 # SKIP Testing interop with > libdbus not supported > SKIP: gdbus-server-auth 6 /gdbus/server-auth/anonymous/tcp # SKIP Testing > interop with libdbus not supported > SKIP: gdbus-server-auth 7 /gdbus/server-auth/sha1/tcp # SKIP Testing interop > with libdbus not supported > > This is something I would like to be able to test before uploading. At > least it does look like I enabled the test correctly. > > Not sure when I will get to look at this again, I haven't claimed it, if > somebody else wants to take over then go ahead. I have been looking at this, but building glib with only the two fix commits (not the tests one) makes the build hang on the network-monitor tests. I haven't investigated much yet, but I wonder if it may be an issue with my local configuration. Did you glib build succeed? If so can you publish the source and debs? I'd like to test that with some qt5 apps to verify the regression fix. Thanks, Emilio
Re: Bug#947045: undefined symbol in libpixbufloader-tiff.so: g_uint_checked_mul
On 20/12/2019 00:49, Simon McVittie wrote:
> (LTS team: full quote of bug report below)
>
> On Thu, 19 Dec 2019 at 21:41:59 +, McIntyre, Vincent (CASS, Marsfield)
> wrote:
>> Dear LTS Maintainer,
>
> If a bug is specific to a LTS package, please report it to the
> debian-lts mailing list (I'm sending this mail there to pass the message
> on). https://wiki.debian.org/LTS/FAQ#Where_can_bugs_be_reported.3F
>
> Ordinary bug reports via bugs.debian.org do not normally go to the
> LTS team.
reportbug was patched to copy -lts and -security bugs to the appropriate
addresses. However it looks like that didn't work this time.
>> I noticed this and thought I should report it.
>>
>> ...
>> The following packages will be upgraded:
>> libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common
>> 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 463 kB of archives.
>> After this operation, 2,048 B disk space will be freed.
>> Do you want to continue? [Y/n]
>> Get:1 http://:/security/ jessie/updates/main
>> libgdk-pixbuf2.0-0 amd64 2.31.1-2+deb8u8 [168 kB]
>> Get:2 http://:/security/ jessie/updates/main
>> libgdk-pixbuf2.0-common all 2.31.1-2+deb8u8 [295 kB]
>> Fetched 463 kB in 0s (3,072 kB/s)
>> Reading changelogs... Done
>> (Reading database ... 56214 files and directories currently installed.)
>> Preparing to unpack .../libgdk-pixbuf2.0-0_2.31.1-2+deb8u8_amd64.deb ...
>> Unpacking libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) over (2.31.1-2+deb8u7)
>> ...
>> Preparing to unpack .../libgdk-pixbuf2.0-common_2.31.1-2+deb8u8_all.deb ...
>> Unpacking libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) over (2.31.1-2+deb8u7)
>> ...
>> Setting up libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) ...
>> Setting up libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) ...
>> g_module_open() failed for
>> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so:
>>
>> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so:
>> undefined symbol: g_uint_checked_mul
>
> This looks like an incorrect backport: g_uint_checked_mul() was new in
> GLib 2.48, but Debian 8 only had GLib 2.42, so that won't work.
>
> The code path used for g_uint_checked_mul() on gcc >= 5 is implemented
> in terms of the __builtin_umul_overflow() compiler builtin, so a backport
> of these gdk-pixbuf patches could probably use __builtin_umul_overflow()
> directly, or wrap a macro around it to provide a simplified, gcc-specific
> version of g_uint_checked_mul().
Note that jessie has GCC 4.9, so this probably needs to use the explicit
version:
static inline gboolean _GLIB_CHECKED_MUL_U32 (guint32 *dest, guint32 a, guint32
b) {
*dest = a * b; return !a || *dest / a == b; }
#define g_uint_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U32(dest, a, b)
Cheers,
Emilio
Re: ibus/CVE-2019-14822/glibc
On 07/01/2020 07:36, Brian May wrote: > Brian May writes: > >> My build is still running the tests, but I don't expect any problems as >> the test was getting skipped anyway... > > Tests seem to be hanging, on the next test after: > > PASS: network-address 37 /gresolver/resolve-address/0 > PASS: network-address 38 /gresolver/resolve-address/1 > PASS: network-address 39 /gresolver/resolve-address/2 > PASS: network-address 40 /gresolver/resolve-address/3 > PASS: network-address 41 /gresolver/resolve-address/4 > PASS: network-address 42 /gresolver/resolve-address/5 > PASS: network-address 43 /gresolver/resolve-address/6 > PASS: network-address 44 /gresolver/resolve-address/7 > PASS: network-address 45 /gresolver/resolve-address/8 > PASS: network-address 46 /gresolver/resolve-address/9 > PASS: network-address 47 /gresolver/resolve-address/10 > PASS: network-address 48 /gresolver/resolve-address/11 > PASS: network-address 49 /gresolver/resolve-address/12 > > Running Command seems to be: > > /bin/bash /build/glib2.0-S2dcj2/glib2.0-2.42.1/./tap-driver.sh > --test-name network-monitor --log-file network-monitor.log --trs-file > network-monitor.trs --color-tests no --enable-hard-errors yes > --expect-failure no -- /build/glib2.0-S2dcj2/glib2.0-2.42.1/./tap-test > ./network-monitor > > This doesn't appear to be anything related to anything I have changed. > Will try building again without my patches. Yes, that's the failing test I mentioned in my email. Building without the patches works for me. I am still looking at whether upgrading ibus is worth it due to the regression risk. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity
On 06/01/2020 13:01, Chris Lamb wrote: > Hi Holger et al., > >> today I unclaimed for LTS: >> >> -ibus (Emilio) > > I was working under the assumption that adding a note would reset the > inactivity timer but this does not seem to be a case for at least > this unclai (I see a "20191230: work is ongoing"). > > Can you clarify? There was no such note for ibus. Maybe you could clarify which package you meant. Your assumption is right afaik, so perhaps there was a bug somewhere or you missed something. Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity
On 07/01/2020 15:44, Emilio Pozuelo Monfort wrote: > On 06/01/2020 13:01, Chris Lamb wrote: >> Hi Holger et al., >> >>> today I unclaimed for LTS: >>> >>> -ibus (Emilio) >> >> I was working under the assumption that adding a note would reset the >> inactivity timer but this does not seem to be a case for at least >> this unclai (I see a "20191230: work is ongoing"). >> >> Can you clarify? > > There was no such note for ibus. Maybe you could clarify which package you > meant. Your assumption is right afaik, so perhaps there was a bug somewhere or > you missed something. Sorry, I just saw that this was already discussed and clarified. Those mails went to a separate folder due to the cross-posting. Cheers, Emilio
(E)LTS report for December
Hi, During the month of December, I spent 16.5h on LTS on the following tasks: - firefox-esr update - thunderbird update - spamassasin update - libssh update - preparing and testing ibus and glib2.0 (there was a regression update on stretch so I'm being careful here) For ELTS I only spent 1h on frontdesk and triaging work. Cheers, Emilio
Re: Unable to announce the updates
On 10/01/2020 19:12, Utkarsh Gupta wrote: > Hi Chris, > > On 10/01/20 11:34 pm, Chris Lamb wrote: >>> I've been trying to send DLA-2063 (and now DLA-2060) announcement to >>> -lts-announce but for some reasons I can't seem to post there. >> >> This is invariably due to issues regarding the GPG signature. > > Ah, I am guessing that Thunderbird doesn't really work when a GPG > signature is sent as an attachment? > >> If it helps, I tend to BCC myself when making those announcements so >> that I can confirm that I used the correct key and (inline) signature >> scheme. > > Aha! Nice idea, I shall BCC myself, too. > Perhaps I shall look up the inline signature scheme, thanks! :) Using enigmail with PGP/mime has problems with debian lists for some reason. So that's most likely the cause. Just use inline PGP signatures when sending mails to -announce lists and you should be good. Cheers, Emilio
Re: [CVE-2019-17026] Firefox Security Advisory 2020-03
On 31/01/2020 08:10, Ola Lundqvist wrote:
> Hi
>
> I have added firefox-esr to dla-needed.txt file now.
>
> // Ola
>
> On Thu, 30 Jan 2020 at 01:06, Ben Hutchings wrote:
>
>> On Sun, 2020-01-26 at 16:17 +0100, Hugo Lefeuvre wrote:
>>> Hi,
>>>
It seems urgent to me to correct a flaw exploited in firefox:
https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/
Here are the changes:
>> https://raw.githubusercontent.com/HacKurx/public-sharing/master/firefox-68.4.0-1_js_src_jit_MIR.h.patch
>>>
>>> AFAIK this has already been addressed in jessie via DLA-2061-1[0]
>>> (firefox-esr) and DLA-2071-1 (thunderbird) on Jan, 09 2020.
>>
>> Upstream says this was fixed in 68.4.1esr, and DSA-4600-1 for
>> {stretch,buster}-security also references packages with an upstream
>> version 68.4.1esr.
>>
>> However DLA-2061-1 for jessie-security has a version of
>> 68.4.0esr-1~deb8u1.
>>
>> I think the wrong version was backported to jessie-security, leaving
>> this issue unfixed.
Ah, looks like I prepared the update when 68.4.0 came out and I didn't realise a
new version was released before the DSA. I'll update to 68.4.1 shortly.
Thanks,
Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 10/02/2020 03:25, Holger Levsen wrote: > hi, > > today I unclaimed > > for LTS: > > - xerces-c (Hugo Lefeuvre) > > and none for eLTS. > > Then, the monthly reports for January are due today. Please publish yours, if > you haven't already. > > > And, the following DLAs are missing on www.debian.org: > > ERROR: .data or .wml file missing for DLA 1713-2 > ERROR: .data or .wml file missing for DLA 1714-2 > ERROR: .data or .wml file missing for DLA 1949-1 > ERROR: .data or .wml file missing for DLA 1953-2 > ERROR: .data or .wml file missing for DLA 1983-1 > ERROR: .data or .wml file missing for DLA 1985-1 > ERROR: .data or .wml file missing for DLA 1993-1 > ERROR: .data or .wml file missing for DLA 2000-1 > ERROR: .data or .wml file missing for DLA 2017-2 > ERROR: .data or .wml file missing for DLA 2031-1 > ERROR: .data or .wml file missing for DLA 2043-2 > ERROR: .data or .wml file missing for DLA 2053-1 > ERROR: .data or .wml file missing for DLA 2079-1 > ERROR: .data or .wml file missing for DLA 2083-1 > ERROR: .data or .wml file missing for DLA 2097-1 > ERROR: .data or .wml file missing for DLA 2098-1 It would be useful if this info came with the person who reserved that DLA. If one of those were mine, it'd be easier if I could see that, then just update the website from the debian-lts-announce mails that I still have. Thanks, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 10/02/2020 12:07, Holger Levsen wrote: > On Mon, Feb 10, 2020 at 11:23:08AM +0100, Emilio Pozuelo Monfort wrote: > [...] >>> ERROR: .data or .wml file missing for DLA 2098-1 >> It would be useful if this info came with the person who reserved that DLA. > > sure. it's just not that easy to get that information programmatically... > >> If >> one of those were mine, it'd be easier if I could see that, then just update >> the >> website from the debian-lts-announce mails that I still have. > > and yes, we should automate this. Is this script living somewhere? I could take a look at extracting that information from data/DLA/list's git history. Cheers, Emilio
(E)LTS report for January
Hi, During January I spent 8 hours on LTS updating firefox, thunderbird, and firefox again, as well as fixing some problems with the VM. As for ELTS I spent 1.5h doing triaging work. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 13/02/2020 14:02, Holger Levsen wrote:
> Hi Emilio,
>
> On Mon, Feb 10, 2020 at 04:18:08PM +0100, Emilio Pozuelo Monfort wrote:
>>>>> ERROR: .data or .wml file missing for DLA 2098-1
>>>> It would be useful if this info came with the person who reserved that DLA.
>> Is this script living somewhere? I could take a look at extracting that
>> information from data/DLA/list's git history.
>
> the script is available in
> https://salsa.debian.org/webmaster-team/cron/merge_requests/1
> and has to be run in the directory of a clone of
> https://salsa.debian.org/webmaster-team/webwml/
> with "../cron/parts/10-check-advisories --mode DLA", so
> I'm running this in a script:
>
> cd ~/Projects/security-tracker
> git pull
> cd ~/Projects/debian-www/webwml
> git pull
> ../cron/parts/10-check-advisories --mode DLA 2>&1
>
> where ~/Projects/debian-www/cron is on the branch mr-origin-1...
The attached patch allows that script to also print author information when
using a local copy of the security-tracker repo with the --list option.
Otherwise it should fall back to the status quo. The current output is:
ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C.
Sánchez)
ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg)
ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen)
ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank)
ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)
ERROR: .data or .wml file missing for DLA 2043-2 (reserved by Thorsten Alteholz)
ERROR: .data or .wml file missing for DLA 2031-1 (reserved by Hugo Lefeuvre)
ERROR: .data or .wml file missing for DLA 2017-2 (reserved by Adrian Bunk)
ERROR: .data or .wml file missing for DLA 2000-1 (reserved by Hugo Lefeuvre)
ERROR: .data or .wml file missing for DLA 1993-1 (reserved by Sylvain Beucler)
ERROR: .data or .wml file missing for DLA 1985-1 (reserved by Chris Lamb)
ERROR: .data or .wml file missing for DLA 1983-1 (reserved by Thijs Kinkhorst)
ERROR: .data or .wml file missing for DLA 1714-2 (reserved by Hugo Lefeuvre)
ERROR: .data or .wml file missing for DLA 1713-2 (reserved by Hugo Lefeuvre)
ERROR: .data or .wml file missing for DLA 1953-2 (reserved by Hugo Lefeuvre)
ERROR: .data or .wml file missing for DLA 1949-1 (reserved by Bastian Blank)
btw I wonder if that script shouldn't leave elsewhere, such as in the webwml
repo or in the security-tracker.
Cheers,
Emilio
From bed41e8f79f1344c08fa8f9787c8bb3dcfcdd500 Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort
Date: Wed, 19 Feb 2020 10:38:05 +0100
Subject: [PATCH] 10-check-advisories: optionally fetch author info
---
parts/10-check-advisories | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/parts/10-check-advisories b/parts/10-check-advisories
index a2524c6..6353ccc 100755
--- a/parts/10-check-advisories
+++ b/parts/10-check-advisories
@@ -71,9 +71,18 @@ def main():
for adv in parse_advisories(response.iter_lines(decode_unicode=True)):
check_advisory(args.mode, args.directory, **adv)
else:
-with open(args.list) as text:
-for adv in parse_advisories(text):
-check_advisory(args.mode, args.directory, **adv)
+try:
+import git
+repodir = '/'.join(args.list.split('/')[:-3])
+repofile = '/'.join(args.list.split('/')[-3:])
+repo = git.Repo(repodir)
+for commit, lines in repo.blame('HEAD', repofile):
+for adv in parse_advisories(lines):
+check_advisory(args.mode, args.directory, **adv, author=commit.author)
+except:
+with open(args.list) as text:
+for adv in parse_advisories(text):
+check_advisory(args.mode, args.directory, **adv)
def parse_advisories(stream):
@@ -87,7 +96,7 @@ def parse_advisories(stream):
logging.warning('malformed line: "%s"', line)
-def check_advisory(mode, directory, year, number, errata):
+def check_advisory(mode, directory, year, number, errata, author=None):
if errata is None:
errata = '1'
logging.info('checking %s-%s-%s (%s)', mode, number, errata, year)
@@ -102,8 +111,11 @@ def check_advisory(mode, directory, year, number, errata):
logging.debug('both data and wml files found, without -1')
found = True
if not found:
-logging.error('.data or .wml file missing for %s %s-%s',
- mo
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 20/02/2020 12:40, Abhijith PA wrote: > Holger, > > On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote: > > >> The attached patch allows that script to also print author information when >> using a local copy of the security-tracker repo with the --list option. >> Otherwise it should fall back to the status quo. The current output is: >> >> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. >> Sánchez) >> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg) >> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen) >> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank) >> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb) >> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA) >> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA) > > DLA 2053-1 pushed to webmaster-team repo a month ago. > > https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d data/DLA/list says: [31 Dec 2019] DLA-2053-1 otrs2 - security update i.e. this was reserved in 2019. Thus the script that generates this report is looking in the 2019/ folder of the website, but it is actually living in the 2020/ folder, most likely due to parse-dla.pl placing it there because of the Date header of your email (which was sent in 2020). Normally reserving a DLA and sending it a few hours later wouldn't cause significant trouble (except for out of order announcements), but it did here due to the year offset and how things are archived in the website. Note how also the source link in [1] is broken. [1] https://security-tracker.debian.org/tracker/DLA-2053-1 We have three options here: - move the files in the website to 2019/, breaking the current link - change the date in data/DLA/list to Jan 1 2020 - keep the status quo (with the broken link in the tracker) and change the script to find the files even if they are in another year Given that commit dafc13ef in the security-tracker hasn't broken anything, I'll just update the date in data/DLA/list to fix the tracker link and getting that DLA off the report. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 20/02/2020 13:56, Sylvain Beucler wrote: > Hi, > > On 20/02/2020 13:35, Emilio Pozuelo Monfort wrote: >> On 20/02/2020 12:40, Abhijith PA wrote: >>> Holger, >>> >>> On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote: >>> >>> >>>> The attached patch allows that script to also print author information when >>>> using a local copy of the security-tracker repo with the --list option. >>>> Otherwise it should fall back to the status quo. The current output is: >>>> >>>> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. >>>> Sánchez) >>>> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph >>>> Berg) >>>> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger >>>> Levsen) >>>> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian >>>> Blank) >>>> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb) >>>> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA) >>>> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA) >>> DLA 2053-1 pushed to webmaster-team repo a month ago. >>> >>> https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d >> data/DLA/list says: >> >> [31 Dec 2019] DLA-2053-1 otrs2 - security update >> >> i.e. this was reserved in 2019. Thus the script that generates this report is >> looking in the 2019/ folder of the website, but it is actually living in the >> 2020/ folder, most likely due to parse-dla.pl placing it there because of the >> Date header of your email (which was sent in 2020). >> >> Normally reserving a DLA and sending it a few hours later wouldn't cause >> significant trouble (except for out of order announcements), but it did here >> due >> to the year offset and how things are archived in the website. Note how also >> the >> source link in [1] is broken. >> >> [1] https://security-tracker.debian.org/tracker/DLA-2053-1 >> >> We have three options here: >> - move the files in the website to 2019/, breaking the current link >> - change the date in data/DLA/list to Jan 1 2020 >> - keep the status quo (with the broken link in the tracker) and change the >> script to find the files even if they are in another year >> >> Given that commit dafc13ef in the security-tracker hasn't broken anything, >> I'll >> just update the date in data/DLA/list to fix the tracker link and getting >> that >> DLA off the report. > I committed DLA-1993-1 manually in the 2019 folder, fixed the date in > the .data file, but it looks like this wasn't enough, this is 404: > https://www.debian.org/lts/security/2019/dla-1993 > https://security-tracker.debian.org/tracker/DLA-1993-1 > https://salsa.debian.org/webmaster-team/webwml/commit/2f79c83e9dac20596a24f6b404cfa2ce1954e3d1 > > I guess the web build system has a limitation. Do the webmasters need to > intervene ? I still see this in 2019/dla-1993.wml: # do not modify the following line #include "$(ENGLISHDIR)/lts/security/2020/dla-1993.data" # $Id: $ Looks like you actually need to modify it :p Btw if you parse a file with a Date: header, parse-dla.pl will read that and place the files in the appropriate dir, so you don't need to do any fixups afterwards. Cheers, Emilio
Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content
On 20/02/2020 18:00, Salvatore Bonaccorso wrote: > Hi Holger, > > On Thu, Feb 20, 2020 at 04:49:09PM +, Holger Levsen wrote: >>> Does LTS provide updates for nodejs/nodejs-*, and is there a place where >>> we can document this decision? >> >> I'd lean to call it unsupported and document this in >> src:debian-security-support. > > I guess you will need to add it to the ended file instead, that is > declare it end-of-life because not supportable by backporting fixes -- > unsupported covers all suites, and this as you noticed was the reason > to remove it again from there as we tentatively want to be able to > support nodejs in buster. Yes, this was mentioned in the release notes for jessie and stretch: https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8 https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#libv8 So we should add it to security-support-ended for those releases, and let it be supported in buster. Cheers, Emilio
Re: ibus/CVE-2019-14822/glibc
On 22/01/2020 07:29, Brian May wrote: > Brian May writes: > >> commit 7cba800a84730c9c5843acdd775e42b8c1438edf (HEAD) >> Author: Alexander Larsson >> Date: Mon Jun 1 10:02:47 2015 +0200 > > This patch decreases the number of errors from 1 to 52. Thanks for the investigation Brian. However after some thinking, given the current issues and the risk of regressions, and that this bug requires a somewhat unusual setup to exploit, I've decided to mark it as ignored. Cheers, Emilio
Re: Bug#931376: debian-security-support: mention nodejs is not for untrusted content
On 20/02/2020 23:30, Holger Levsen wrote: > On Thu, Feb 20, 2020 at 07:50:30PM +0100, Markus Koschany wrote: >>> So we should add it to security-support-ended for those releases, and >>> let it be supported in buster. >> >> We currently also mention it here: >> https://wiki.debian.org/LTS/Jessie > > oh, ic, I wasn't aware of this page (which exists since 2018) and I'm not sure > I'm in favor of storing information in different places. > > I'm considering replacing the words about unsupported packages (in the > supported packages paragraph of that page) with a link to the > security-support-ended.deb8 file in debian-security-support.git... > > But I'll sleep over it first... :) Sounds reasonable. I wasn't aware of that page either, and having the same list of unsupported packages on multiple places is only going to lead to some of those lists getting outdated. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 21/02/2020 00:34, Holger Levsen wrote: > Hi Emilio, > > On Wed, Feb 19, 2020 at 10:45:36AM +0100, Emilio Pozuelo Monfort wrote: >>> cd ~/Projects/security-tracker >>> git pull >>> cd ~/Projects/debian-www/webwml >>> git pull >>> ../cron/parts/10-check-advisories --mode DLA 2>&1 >>> >>> where ~/Projects/debian-www/cron is on the branch mr-origin-1... >> >> The attached patch allows that script to also print author information when >> using a local copy of the security-tracker repo with the --list option. > > cool, many thanks! but it t doesn't work for me, maybe I'm doing it wrong: > > ~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA > --list ../../security-tracker/data/DLA/list > ERROR: .data or .wml file missing for DLA 2103-1 > ERROR: .data or .wml file missing for DLA 2101-1 > ERROR: .data or .wml file missing for DLA 2083-1 > [...] Do you have python3-git installed? I made that dependency optional, so that if you don't have it, the script will still work (but without the author info). Emilio
Re: Is it okay to bump dh-compat?
On 21/02/2020 17:42, Utkarsh Gupta wrote: > Hi all, > > Whilst working on libpam-radius-auth, I noticed that d/compat has > value "4" which throws the following error: > > dh_clean: error: Compatibility levels before 5 are no longer supported > (level 4 requested) > > Would it be okay to bump d/compat to 5 (or maybe 7) in such a case? Huh, that package shouldn't have made it into jessie in such a state. Sure, but better bump it to 5 and check the changes in v5 in the debhelper manpage. You can also debdiff the old and new .debs to see if there's any change in the installed files. Cheers, Emilio
Re: Is it okay to bump dh-compat?
On 21/02/2020 17:48, Emilio Pozuelo Monfort wrote: > On 21/02/2020 17:42, Utkarsh Gupta wrote: >> Hi all, >> >> Whilst working on libpam-radius-auth, I noticed that d/compat has >> value "4" which throws the following error: >> >> dh_clean: error: Compatibility levels before 5 are no longer supported >> (level 4 requested) >> >> Would it be okay to bump d/compat to 5 (or maybe 7) in such a case? > > Huh, that package shouldn't have made it into jessie in such a state. > > Sure, but better bump it to 5 and check the changes in v5 in the debhelper > manpage. You can also debdiff the old and new .debs to see if there's any > change > in the installed files. I didn't realise that jessie only has v4 as deprecated, not unsupported, and that's because you're building the source package in a newer release. So what Roberto said. No need to bump compat in this case (and that shouldn't be necessary in a security update). Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 19/02/2020 10:45, Emilio Pozuelo Monfort wrote: > btw I wonder if that script shouldn't leave elsewhere, such as in the webwml > repo or in the security-tracker. I have moved it to the security-tracker in [1]. I made it more useful for DSAs by ignoring regression updates, as those are not (currently) imported to the website. That let me found a few entries were data/DSA/list just had the wrong year, and by fixing those I got the list down to this: $ bin/check-advisories --website-path ../../webwml ERROR: .data or .wml file missing for DSA 4342-1 (reserved by Michael Gilbert) ERROR: .data or .wml file missing for DSA 3156-1 (reserved by Luciano Bello) ERROR: .data or .wml file missing for DSA 3043-1 (reserved by Moritz Muehlenhoff) ERROR: .data or .wml file missing for DSA 2360-1 (reserved by Michael Gilbert) ERROR: .data or .wml file missing for DSA 1975-1 (reserved by Stefan Fritsch) Cheers, Emilio [1] https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/52
Re: security upload imposing load on other parts of Debian
Hi all, I think we can all agree that the problem here is that there was an unexpected issue (a security upload getting rejected) that required sort of immediate work from a third party (an ftp-master). I don't think we should make a big deal of this, as this can happen with any other two teams in Debian. What we can and should do is to try to get this situation resolved (i.e. zsh accepted), which can be accomplished by either: - nicely asking an ftp-master to copy libcap2 into jessie-security and waiting patiently. Offering beer at DebConf or wherever may help ;) - or failing that, doing a no-change upload of libcap2 into jessie-security Also long term, we can help improve the archive situation wrt this issue (bug#823820), which is likely to occur more frequently in the future with Go and Rust packages that make use of static linking and thus heavily use Built-Using. This needs to be discussed with the ftp-team and see how this could be done. Perhaps with a dak module to sync packages to security-master on-demand. That would still need intervention from them, but at a reduced cost. I'll talk to them and see what we can do. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 01/03/2020 00:28, Holger Levsen wrote: > On Sat, Feb 29, 2020 at 10:46:48PM +, Holger Levsen wrote: >>> I have moved it to the security-tracker in [1]. >> hah. > > hah and now that I want to use it I realize you moved the MR only... grrr. > ok, we'll see how this goes. And it's finally merged into webwml. You can run it like this: emilio@andromeda:~/deb/webwml$ ./english/security/find-missing-advisories --mode DLA --tracker ../lts/security-tracker/ ERROR: .data or .wml file missing for DLA 2114-1 (reserved by Ben Hutchings) ERROR: .data or .wml file missing for DLA 2043-2 (reserved by Thorsten Alteholz) ERROR: .data or .wml file missing for DLA 2031-1 (reserved by Hugo Lefeuvre) ERROR: .data or .wml file missing for DLA 2000-1 (reserved by Hugo Lefeuvre) ERROR: .data or .wml file missing for DLA 1714-2 (reserved by Hugo Lefeuvre) ERROR: .data or .wml file missing for DLA 1713-2 (reserved by Hugo Lefeuvre) ERROR: .data or .wml file missing for DLA 1953-2 (reserved by Hugo Lefeuvre) Cheers, Emilio
(E)LTS report for February
Hi, During the month of February, I spent 29h on LTS on the following tasks: - firefox-esr update - thunderbird update - clamav update - spamassassin update - missing webwml script improvements - jackson-databind update - python-reportlab update - CVE triage - python-pysaml2 update - openjdk-7 update For ELTS I spent 7h on: - CVE triaging - distro-config branch - openjdk-7 update, including setting up and fighting autopkgtest to get it to work with wheezy Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 02/03/2020 12:57, Emilio Pozuelo Monfort wrote: > On 01/03/2020 00:28, Holger Levsen wrote: >> On Sat, Feb 29, 2020 at 10:46:48PM +, Holger Levsen wrote: >>>> I have moved it to the security-tracker in [1]. >>> hah. >> >> hah and now that I want to use it I realize you moved the MR only... grrr. >> ok, we'll see how this goes. > > And it's finally merged into webwml. You can run it like this: > > emilio@andromeda:~/deb/webwml$ ./english/security/find-missing-advisories > --mode DLA --tracker ../lts/security-tracker/ > ERROR: .data or .wml file missing for DLA 2031-1 (reserved by Hugo Lefeuvre) > ERROR: .data or .wml file missing for DLA 2000-1 (reserved by Hugo Lefeuvre) > ERROR: .data or .wml file missing for DLA 1714-2 (reserved by Hugo Lefeuvre) > ERROR: .data or .wml file missing for DLA 1713-2 (reserved by Hugo Lefeuvre) > ERROR: .data or .wml file missing for DLA 1953-2 (reserved by Hugo Lefeuvre) fwiw I took care of those, so we shouldn't have any remaining old ones anymore. Now it's just a matter of keeping up. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 09/03/2020 19:29, Chris Lamb wrote: > Hi Holger et al., > >> ERROR: .data or .wml file missing for DLA 2115-2 (reserved by Chris Lamb) >__^__ > > How does we announce a regression (ie. -2, -3) via the website? The > namespacing used here (captured in the filenames such as 2020/ > dla-2115.wml etc.) do not include the suffix, so it is not clear to me > how we are meant to append additional details. > > If we do not announce these via the website, I suppose the next course > of action would be to update the script to ignore these. Advice welcome. parse-dla.pl will dtrt, e.g.: emilio@andromeda:~/deb/webwml/english/lts/security$ ls 2020/*-2.* 2020/dla-1931-2.data 2020/dla-1931-2.wml 2020/dla-2131-2.data 2020/dla-2131-2.wml Cheers, Emilio
Re: amd64-microcode, test
On 11/03/2020 21:06, Salvatore Bonaccorso wrote: > Hi, > > A smaller comment on the update: > > On Wed, Mar 11, 2020 at 08:19:11PM +0100, Anton Gladky wrote: >> After discussion with the maintainer I decided to backport the latest >> upstream version, available in Debian (3.20191218.1). Prepared package >> is available here [1]. Debdiff is attached. > [...] >> [1] https://people.debian.org/~gladk/amd64-microcode/ > > If this is 3.20191218.1 upload backported/rebuild for jessie then > please use 3.20191218.1~deb8u1, rather than 3.20191218.1+deb8u1, which > will not correctly sort before 3.20191218.1 otherwise. This should also be coordinated with buster and stretch point updates, so that we avoid having a higher version in jessie. Cheers, Emilio
Re: amd64-microcode, test
On 12/03/2020 21:29, Anton Gladky wrote: > Thanks Emilio and Salvatore for very valuable comments! > > I think then, that it would be more proper way to upload the lower > upstream version 3.20181128.1 into the Jessie and Stretch to escape > higher versions on older releases. Well you used 3.20181128.1+deb8u1, which is higher than what is in buster. You should use ~ when backporting a version from a newer release. Cheers, Emilio
Re: phppgadmin / CVE-2019-10784
On 12/03/2020 22:02, Brian May wrote: > Ola Lundqvist writes: > >> I have ideas on how we can reduce the attack possibilities but I cannot >> find any perfect solution to this. > > What about setting samesite=Lax in the session Cookie? Wouldn't you need Strict rather than Lax? Otherwise if basite.com sends a POST request to your phppgadmin instance, the cookie will be sent and you won't have fixed anything. Cheers, Emilio
Re: Wheezy LTS not present in archive.debian.org
On 17/03/2020 03:58, Ben Hutchings wrote: > On Fri, 2020-03-13 at 16:29 +0100, Piviul wrote: >> Sylvain Beucler ha scritto il 06/03/20 alle 13:14: >>> [...] >>> Good question :) >>> >>> Snapshot saved the deb7u16 update as part of wheezy-security in 2018: >>> https://snapshot.debian.org/package/samba/2%3A3.6.6-6%2Bdeb7u16/ >>> >>> There's a modified copy of Wheezy LTS as part of the ELTS project >>> (deb7u19, 2019): >>> https://deb.freexian.com/extended-lts/ >>> https://deb.freexian.com/extended-lts/pool/main/s/samba/ >>> >>> I also see there's a copy of Squeeze LTS in the Debian archive: >>> http://archive.debian.org/debian/dists/squeeze-lts/ >>> and a copy of Wheezy pre-LTS (2016): >>> http://archive.debian.org/debian/dists/wheezy/ >>> but there's no copy of Wheezy LTS. >>> >>> Anybody knows if there's an archived copy of Wheezy LTS/pre-ELTS? >> I have to guess that nobody have to spend time to know why LTS/pre-ELTS >> packages are not gone in debian wheezy archive? >> >> ...I can understand. Any way "normally" when a distribution is archived >> all LTS security updates should be end in archived repos? > > During the full support period, all security updates are rolled up into > point releases of the corresponding suite in the main archive, and that > suite is copied to archive.debian.org later. > > During the extended support period covered by the LTS team, there are > no more point releases and so security updates are not copied to the > main archive, or from there to archive.debian.org. (But squeeze-lts > was on the main archive, so it was copied along with the main squeeze > suite.) > > So it seems that we are lacking a procedure for archiving a suite from > the security archive. Actually it was properly archived, but under /debian-security/, e.g.: http://archive.debian.org/debian-security/dists/wheezy/updates/ Cheers, Emilio
Re: Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken
Hi, On 19/03/2020 13:01, Simon McVittie wrote: > On Thu, 19 Mar 2020 at 12:33:09 +0100, Etienne Allovon wrote: >> Subject: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie >> (security) is broken > > Debian 8 'jessie' is no longer supported by the mainstream Debian > security team Etienne probably meant that the update comes from jessie-security, which is correct. > or by the maintainers of individual packages. Instead, it That's not necessarily correct. While many maintainers don't care about LTS, some others do and they help provide security updates in coordination with the LTS team. > is maintained by the Debian LTS subproject. Please contact the debian-lts > mailing list if you encounter regressions > in jessie or jessie-security packages. > > (LTS people: please see the bug for details, and please make sure the > message is getting out to LTS users that they should be contacting the > LTS team and not the bug tracking system.) Actually the bug tracker is a good place to report regressions in LTS, just like it's fine for stable. reportbug has a feature to Cc the security team or the LTS list if it detects that the package comes from such a suite. That probably didn't work here because it was a follow-up to an already opened bug, but in general I wouldn't see an issue with reporting a bug against the package. In any case, thanks Etienne for reporting this regression, and thank you Simon for letting us know. Cheers, Emilio
Re: Bug#946691: emacs25-common: expired GNU ELPA gpg key
Hi Rob, On 16/12/2019 02:33, Rob Browning wrote: > Thomas Sanders writes: > >> Package: emacs25-common >> Version: 25.1+1-4+deb9u1 >> Severity: normal >> File: /usr/share/emacs/25.1/etc/package-keyring.gpg >> >> Dear Maintainer (Rob Browning?), >> >> This problem in emacs 25 (in Debian old-stable) is the same as the >> problem that was fixed in Debian current stable (buster) emacs 26 >> with this changelog message: >> https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-3.2+deb10u1_changelog >> [START-QUOTATON] >> emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high >> >> * Update the EPLA packaging key (previous key expires 2019-09-23) via >> the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911. Add the >> old and new keyrings to debian/ and debian/source/include-binaries >> since debian/patches/ can't handle git binary diffs. Thanks to Stefan >> Monnier for reporting the problem and providing the patch. >> >> -- Rob Browning Wed, 04 Sep 2019 21:35:24 -0500 >> [END-QUOTATION] > > > Ahh, so it sounds like it we might want to try to fix this in LTS too. > Assuming so, and if no one else handles it before I get to it, I'll try > to see how that process works, and if the change would be acceptable. Sorry for the delay. Note that this bug report is talking about stretch, which is not handled by LTS (yet). You may still be able to fix this bug via a stretch point release update, see the reportbug release.debian.org template. Cheers, Emilio
tor EOL in jessie
On 28/12/2017 11:48, Emilio Pozuelo Monfort wrote: > On 04/12/17 13:31, Peter Palfrader wrote: >> Upstream is no longer maintaining the 0.2.4.x tree. Maybe it's time to >> terminate support for Tor in wheezy/oldoldstable? > > I think so. I have marked it as unsupported in debian-security-support. There's a new tor CVE. However upstream no longer supports 0.2.x.y, so stretch was EOL'ed. Given jessie has an even older version, I think we should follow suit. Thoughts? Cheers, Emilio
(E)LTS report for March
Hi, During the last month I spent 19.5 hours on LTS working on the following: - CVE triaging - firefox-esr security update - qemu security update - thunderbird security update - started to look at dak built-using problem - icu security update - started to backport bluez security issue to older version. pondering whether it's worth the regression risk. For ELTS I spent 6 hours on the following tasks: - openjdk-7 regression update - frontdesk - ensuring no supported packages were accidentally marked as EOL Cheers, Emilio
Re: libdatetime-timezone-perl need to wait?
On 20/06/2020 22:39, Ola Lundqvist wrote: > Thanks for the clarification. Would that really be an issue if they > got it? They will get the newer version later. > But I get the point. In any case it is not an urgent thing so we can > wait. I'll add notes about this too. Yes, it can be a problem, for example if the package has dependencies on libraries that have bumped the SONAME on the newer Debian release. That can cause apt to not be able to do a dist-upgrade. In this particular case, that's unlikely to be a problem, but we follow the more general rule of not having a higher version in an older release. Besides, this update is not urgent (the changes are scheduled to happen in October or so) so there's no rush and we can wait for the point release. If the changes were urgent, the stretch update would have happened quickly through a SUA rather than waiting for a point release. Cheers, Emilio > > // Ola > > On Sat, 20 Jun 2020 at 00:53, Sylvain Beucler wrote: >> >> Hi, >> >> On 19/06/2020 23:29, Ola Lundqvist wrote: >>> In the DLA needed entry for libdatetime-timezone-perl you have >>> mentioned that we need to wait for oldstable update via point release >>> before the LTS update is made. When looking at the version numbers for >>> the different releases I fail to see the necessity of that. >>> >>> Have I missed something? Or is this note false? >> >> From what I understand, we want to provide 2020a-0+deb8u1 but if we do >> before 2019c-0+deb9u1 -> 2020a-0+deb9u1 is done on stretch, people who >> upgrade jessie -> stretch will retain the jessie package (while they >> should use the stretch package). >> >> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958995 >> >> Cheers! >> Sylvain > > >
(E)LTS report for April/May
Hi, During April I spent 5h on LTS working on - firefox security update - thunderbird security update - triaging And 1.5h on ELTS on frontdesk duties. During May I didn't spend any time on LTS, and I spent 1h on ELTS on frontdesk. Cheers, Emilio
Re: stretch EOL point release (9.13) and 10.5 planning
On 22/06/2020 08:37, Salvatore Bonaccorso wrote: > Hi security team, LTS team members, > > On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam D. Barratt wrote: >> stretch transitions from oldstable-with-security-support to LTS support >> on Saturday July 4th. As usual, we should aim for the final point >> release to be soon after that, most likely pulling in any remaining >> updates from security.d.o that are still in oldstable-new. > > FTR, the current needing changes for the security-tracker part are > baking up in > https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/55 > (still keeping the WIP tag). > > LTS team, double check in particular the parts affecting the LTS > workflow. ftr I reviewed those changes and they look fine from a LTS perspective. Thanks! Cheers, Emilio
Re: Steps for Debian Jessie LTS end-of-life
Hi Ansgar, On 01/07/2020 11:27, Ansgar wrote: > Hi, > > since LTS for Jessie has ended according to [1], can we disable uploads > and prepare for archiving the release? Yes, let's do this. > > I want to: > > 1. Stop accepting anything. > 2. Have one Release with no Valid-Until for archive.d.o (to try to >make some people happy...). > 3. Have w-b/buildds no longer look at jessie. > 4. Revoke Jessie signing key (no effect for existing installations >as they won't get the revocation anyway). Same as other keys >listed on [2]. > 5. Import to archive.d.o > 6. Remove from security.d.o > > I can do (1), (2), (4) fairly quickly; the buildd team would need to > look at (3). Not sure when (5) and (6) happen, but it's never wrong to > free up some space. All sounds good. > Will there be an announcement that LTS support has ended? Yes. I guess it will go out together with the stretch security -> LTS one, at least for the one coordinated by the publicity team. Cheers, Emilio
(E)LTS report for June
Hi, During the month of June I spent 4h on LTS working on: - reviewed stretch-lts MR - prepared batik update - CVE triaging - started working on a lts no-dsa review script As for ELTS I spent 9h working on: - final changes to distro-config branch improvements, and deployment - prepared batik update, decided to mark it as no-dsa in the end as it requires changes to rdeps to be effective - nss update - frontdesk triage Cheers, Emilio
Re: Steps for Debian Jessie LTS end-of-life
On 01/07/2020 12:40, Emilio Pozuelo Monfort wrote: > On 01/07/2020 11:27, Ansgar wrote: >> 5. Import to archive.d.o >> 6. Remove from security.d.o >> >> I can do (1), (2), (4) fairly quickly; the buildd team would need to >> look at (3). Not sure when (5) and (6) happen, but it's never wrong to >> free up some space. > > All sounds good. btw it'd be good to not do 6 too soon. At least the security-tracker currently fetches jessie-security Packages files, and that will only stop when the stretch handover happens. I'd say a grace period of one month would be nice, unless you need to reclaim that space earlier, in which case we can work it out. Cheers, Emilio
Re: Steps for Debian Jessie LTS end-of-life
On 01/07/2020 19:26, Markus Koschany wrote: > > Am 01.07.20 um 19:14 schrieb Ansgar: >> On Wed, 2020-07-01 at 18:38 +0200, Markus Koschany wrote: >>> Am 01.07.20 um 11:27 schrieb Ansgar: since LTS for Jessie has ended according to [1], can we disable uploads and prepare for archiving the release? >> [...] >>> Please wait another week with the deactivation of jessie-security. This >>> ensures that we can still upload the last packages which received >>> security updates. >> >> After a chat on IRC, it's currently already configured to no longer >> accept new uploads. I think it's confusing to release security updates >> after security support supposedly ended, but if the LTS team wants that >> I can look at renabling it again. >> >>> Ideally the switch to Stretch LTS goes hand in hand >>> with the deactivation of jessie-security so we have no downtime at all. >> >> Which downtime? Stretch already has security support; with LTS it will >> get /less/ support (only a limited set of architectures). Anybody >> wishing to use Stretch LTS later, can already use Stretch today with no >> downsides. > > There are still packages which could be uploaded to jessie-security. > Even today there were three uploads. It is more efficient if the LTS > team can handle uploads by themselves. Now we can neither finish > jessie-security updates nor can we upload to stretch-security directly. > This is what I mean by downtime. Please re-enable jessie-security for now. jessie ELTS is already open (because jessie LTS should not). Having both receiving updates is actually more confusing, if you ask me. That means that those updates (at least the ones that are supported on ELTS) can still be uploaded there. Perhaps it would have made sense to not EOL jessie until stretch had actually become LTS. That could be something that we can think about for stretch, although it doesn't sound like too big a deal, particularly since we're aiming to do the stretch handover this weekend. Cheers, Emilio
Re: Debian 9 (Stretch) LTS: archive side should be done
On 06/07/2020 12:01, Ansgar wrote: > Hi, > > the archive side of switching Debian 9 (Stretch) to LTS should be done > now. The architectures amd64, arm64, armel, armhf and i386 remain. Thanks! The tracker has also been updated and the wanna-build config for stretch-security has been changed as well. In any case, please be careful with what you upload. There is a point release planned for the 18th (the final point release for stretch) so uploads are still going there, including some for minor security fixes. Anything urgent could go into stretch-security, but please ensure there are no stretch-pu updates planned in [1], and coordinate that with the maintainers in case they are planning one. stretch-pu will freeze on Sunday 12th, so after that there shouldn't be any clashes with pu, but still be careful until the point release actually happens. If in doubt, please ask frontdesk or myself. Cheers, Emilio [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=pu
Re: Draft: Debian 8 Long Term Support reaching end-of-life
Hi Markus, On 02/07/2020 17:42, Markus Koschany wrote: > I have drafted a new announcement, "Debian 8 Long Term Support reaching > end-of-life". I would like you to review the draft and the i18n teams to > translate the content when it is approved by you. You can find the text > here: > > https://salsa.debian.org/publicity-team/announcements/-/blob/master/en/2020/20200709.wml > > The new announcement is very similar to the previous one from 2018. I > believe this will also significantly ease translations. Are you going to send a jessie EOL DLA, similar to the one we did for wheezy? [1] Since that needs less coordination, I can prepare and send it if you haven't started with it yet, but wanted to check with you first to avoid any clashes. Thanks, Emilio [1] https://lists.debian.org/debian-lts-announce/2018/06/msg1.html
Re: Draft: Debian 8 Long Term Support reaching end-of-life
On 06/07/2020 15:30, Markus Koschany wrote: > Hi, > > Am 06.07.20 um 15:25 schrieb Emilio Pozuelo Monfort: >> Hi Markus, >> >> On 02/07/2020 17:42, Markus Koschany wrote: >>> I have drafted a new announcement, "Debian 8 Long Term Support reaching >>> end-of-life". I would like you to review the draft and the i18n teams to >>> translate the content when it is approved by you. You can find the text >>> here: >>> >>> https://salsa.debian.org/publicity-team/announcements/-/blob/master/en/2020/20200709.wml >>> >>> The new announcement is very similar to the previous one from 2018. I >>> believe this will also significantly ease translations. >> >> Are you going to send a jessie EOL DLA, similar to the one we did for >> wheezy? [1] >> >> Since that needs less coordination, I can prepare and send it if you haven't >> started with it yet, but wanted to check with you first to avoid any clashes. >> >> Thanks, >> Emilio > > Indeed, I wanted to send the same announcement to debian-lts-announce > but please go ahead. I've sent it now. I wanted to get it out before any stretch DLAs, but I've reused your text. Cheers, Emilio
DLA template and user signatures
Hi, Now that we're starting stretch LTS, I thought it was a good time to review and improve the DLA template. I made a couple of minor changes to it, but there's two bigger ones that the DSA template has and we could add: - The header. It looks like a bit too much for the DLA to me, so I'm unconvinced, however feedback on IRC was in favor of it. I'm bring it up here as well to get more feedback. - The paragraph pointing to the security-tracker. This seems non-controversial to me so if there are no objections I'll add it. - Also while talking about this, it was brought up that some DLAs include personal signatures at the end. They don't look very good on the announcements, so it'd be good to get rid of those. An alias for mutt has been added to [1], so feel free to check it out if you use mutt or one of its forks, or suggest similar options for other MUAs. Cheers, Emilio [1] https://wiki.debian.org/LTS/Development#Announce_the_update
Re: [Git][security-tracker-team/security-tracker][master] Triage CVE-2020-12675, CVE-2020-12691, CVE-2020-12690 and CVE-2020-12689 for stretch LTS.
Hi Chris,
On 07/07/2020 13:37, Chris Lamb wrote:
> CVE-2020-12692 (An issue was discovered in OpenStack Keystone before 15.0.1,
> and 16.0. ...)
> {DSA-4679-1}
> - keystone 2:17.0.0~rc2-1 (bug #959900)
> + [stretch] - keystone (Not supported in stretch LTS)
While I see keystone in security-support-ended.deb8, I don't see it in
security-support-ended.deb9. If the situation is still the same wrt openstack,
then I think we should add it security-support-ended and announce it.
Maybe we should in fact review all the packages in security-support-ended.deb8
and see if there are any that should also be in deb9.
Cheers,
Emilio
> [jessie] - keystone (Not supported in Jessie LTS)
> NOTE: https://bugs.launchpad.net/keystone/+bug/1872737
> NOTE: https://www.openwall.com/lists/oss-security/2020/05/06/4
> CVE-2020-12691 (An issue was discovered in OpenStack Keystone before 15.0.1,
> and 16.0. ...)
> {DSA-4679-1}
> - keystone 2:17.0.0~rc2-1 (bug #959900)
> + [stretch] - keystone (Not supported in stretch LTS)
> [jessie] - keystone (Not supported in Jessie LTS)
> NOTE: https://bugs.launchpad.net/keystone/+bug/1872733
> NOTE: https://www.openwall.com/lists/oss-security/2020/05/06/5
> CVE-2020-12690 (An issue was discovered in OpenStack Keystone before 15.0.1,
> and 16.0. ...)
> {DSA-4679-1}
> - keystone 2:17.0.0~rc2-1 (bug #959900)
> + [stretch] - keystone (Not supported in stretch LTS)
> [jessie] - keystone (Not supported in Jessie LTS)
> NOTE: https://bugs.launchpad.net/keystone/+bug/1873290
> NOTE: https://www.openwall.com/lists/oss-security/2020/05/06/6
> @@ -7016,6 +7019,7 @@ CVE-2020-12673
> CVE-2020-12689 (An issue was discovered in OpenStack Keystone before 15.0.1,
> and 16.0. ...)
> {DSA-4679-1}
> - keystone 2:17.0.0~rc2-1 (bug #959900)
> + [stretch] - keystone (Not supported in stretch LTS)
> [jessie] - keystone (Not supported in Jessie)
> NOTE: https://bugs.launchpad.net/keystone/+bug/1872735
> NOTE: https://www.openwall.com/lists/oss-security/2020/05/06/5
>
>
>
> View it on GitLab:
> https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/77de6285845fae7503a2f223c6165a61ee36db79
>
>
> ___
> debian-security-tracker-commits mailing list
> debian-security-tracker-comm...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-security-tracker-commits
>
script to review no-dsa packages fixed in LTS-1 and TLS+1
Hi, During an IRC meeting, Thorsten mentioned that he had noticed some packages that had been fixed in stretch and wheezy-elts, but not in jessie (this was before the jessie EOL), and that had been marked as no-dsa in jessie. Since the package had been fixed in the previous and next releases, it made sense to re-review the reason for that no-dsa tag, which might have been obsolete. I've worked on a script to find these cases so they can be reviewed. It doesn't consider packages that have been fixed in lts+1 via unstable, but only those that have been explicitly fixed there via DSA or point release. I could change that, but for now there's enough CVEs to review so let's start with that. If you find any false positive please let me know. Obviously there's no rush in triaging all of these this close to a point release, but I'm sending it anyway so you can give some feedback. Here's what I'm currently getting: emilio@andromeda:~/deb/lts/security-tracker$ ./bin/lts-no-dsa-needs-review.py data/security.db CVE-2019-9948/python2.7 fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-9947/python2.7 fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-9740/python2.7 fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-16056/python2.7 fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2018-20852/python2.7 fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-11187/gosa fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-12838/slurm-llnl fixed in jessie and buster but no-dsa in stretch (Too intrusive to backport) CVE-2019-5068/mesa fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2020-1712/systemd fixed in jessie and buster but no-dsa in stretch (Can be fixed via point release) CVE-2020-8130/rake fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2016-10894/xtrlock fixed in jessie and buster but no-dsa in stretch (Minor issue; can be fixed via point release) CVE-2020-3898/cups fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-8842/cups fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2020-5267/rails fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-16275/wpa fixed in jessie and buster but no-dsa in stretch (Minor issue; can be fixed via point release) CVE-2020-8518/php-horde-data fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-3866/mistral fixed in jessie and buster but no-dsa in stretch (Minor issue; can be fixed via point release) CVE-2019-15941/lemonldap-ng fixed in jessie and buster but no-dsa in stretch (Restrictions on OIDC federation added in 2.0) CVE-2019-9658/checkstyle fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2020-3123/clamav fixed in jessie and buster but no-dsa in stretch (ClamAV is updated via -updates) CVE-2020-0009/linux fixed in jessie and buster but no-dsa in stretch (Driver is not enabled or supported) CVE-2020-1711/qemu fixed in jessie and buster but no-dsa in stretch (Intrusive to backport, revisit later) CVE-2019-5008/qemu fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-12068/qemu fixed in jessie and buster but no-dsa in stretch (Minor issue, can be fixed along in future update) CVE-2019-3866/python-oslo.utils fixed in jessie and buster but no-dsa in stretch (Minor issue; can be fixed via point release) CVE-2020-8866/php-horde-form fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-9371/libvpx fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-13464/modsecurity-crs fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2020-8865/php-horde-trean fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-9892/otrs2 fixed in jessie and buster but no-dsa in stretch (Non-free not supported) CVE-2019-9751/otrs2 fixed in jessie and buster but no-dsa in stretch (Non-free not supported) CVE-2019-10067/otrs2 fixed in jessie and buster but no-dsa in stretch (Non-free not supported) CVE-2019-20788/libvncserver fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-15690/libvncserver fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-11729/nss fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-11719/nss fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-12900/bzip2 fixed in jessie and buster but no-dsa in stretch (Not exploitable; potential dangerous parts already guarded) CVE-2019-19949/imagemagick fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-15139/imagemagick fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-14981/imagemagick fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-13297/imagemagick fixed in jessie and buster but no-dsa in stretch (Minor issue) CVE-2019-132
Re: script to review no-dsa packages fixed in LTS-1 and TLS+1
On 07/07/2020 17:00, Roberto C. Sánchez wrote: > On Tue, Jul 07, 2020 at 04:37:30PM +0200, Emilio Pozuelo Monfort wrote: >> >> I've worked on a script to find these cases so they can be reviewed. It >> doesn't >> consider packages that have been fixed in lts+1 via unstable, but only those >> that >> have been explicitly fixed there via DSA or point release. I could change >> that, but >> for now there's enough CVEs to review so let's start with that. >> > > This sounds very close to the issue lts-team/lts-extra-tasks#11. You > made a preliminary comment a week ago saying you would likke into it. > Would you mind updating that issue with your work-in-progress? Done. That would be in [1] if anybody feels like reviewing it. > Also, > you should consider assigning it to yourself to ensure that there is not > duplication of effort. I think I did that :-) Cheers, Emilio [1] https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/57
Re: DLA template and user signatures
On 07/07/2020 18:58, Chris Lamb wrote: > Hi Abhijith, > >>> Not quite sure what you mean by this. I am assuming you mean something >>> along the lines of it being "too intense for a DLA" but if so I don't >>> understand what the concern is here. Isn't each of these a potentially- >>> important security release? >> >> I think Emilio meant or what I assumed and replied to IRC is having >> something like this on the top of every DLA >> >> - -- >> Debian LTS Advisory X @debian.org >> https://www.debian.org/ X >> July 06, 2020 https://www.debian.org//faq >> - -- > > Thanks for the reference although this does not resolve my confusion, it > simply refines it: what it is about this header that is "too much for the > DLA". (Too much what?) I just thought it was a bit too formal, but it's no big deal. Since there seems to be consensus in favor of it I'll look into adding it. Cheers, Emilio
Re: DLA template and user signatures
On 07/07/2020 19:05, Emilio Pozuelo Monfort wrote: > On 07/07/2020 18:58, Chris Lamb wrote: >> Hi Abhijith, >> >>>> Not quite sure what you mean by this. I am assuming you mean something >>>> along the lines of it being "too intense for a DLA" but if so I don't >>>> understand what the concern is here. Isn't each of these a potentially- >>>> important security release? >>> >>> I think Emilio meant or what I assumed and replied to IRC is having >>> something like this on the top of every DLA >>> >>> - -- >>> Debian LTS Advisory X @debian.org >>> https://www.debian.org/ X >>> July 06, 2020 https://www.debian.org//faq >>> - -- >> >> Thanks for the reference although this does not resolve my confusion, it >> simply refines it: what it is about this header that is "too much for the >> DLA". (Too much what?) > > I just thought it was a bit too formal, but it's no big deal. Since there > seems > to be consensus in favor of it I'll look into adding it. I have added both the header and the security-tracker link, and verified that the result looks as expected and that ./parse-dla.pl in the website does the right thing. I see one minor issue in the header dash lines due to the inline PGP signatures, but that also affects the DSAs. Cheers, Emilio
Re: [Git][security-tracker-team/security-tracker][master] data/dla-needed.txt: Claim gosa.
Hi Chris, On 09/07/2020 11:54, Chris Lamb wrote: > Commits: > 389b61df by Chris Lamb at 2020-07-09T10:54:19+01:00 > data/dla-needed.txt: Claim gosa. Please note that there's a gosa package in opu for the upcoming point release. So it'd be good to wait with this until after the point release to avoid any conflicts. Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 10/07/2020 19:49, Utkarsh Gupta wrote: > Hi, > > On Mon, Jul 6, 2020 at 1:40 PM Holger Levsen wrote: >> Three DLAs have been reserved but not yet been published on www.debian.org: >> LTS: >> >> - DLA 2269-1 (reserved by Utkarsh Gupta) >> - DLA 2270-1 (reserved by Utkarsh Gupta) >> - DLA 2271-1 (reserved by Utkarsh Gupta) > > This is weird. These DLAs were pushed on July 1st itself via [1][2][3]. > Not sure what went wrong!? They got reverted here: commit 41a5070e43be50edc80c35082caa1a5005b06131 Author: Branislav Makuch Date: Wed Jul 1 13:31:49 2020 + Revert "Merge branch 'master' of salsa.debian.org:webmaster-team/webwml" This reverts commit 6bcdcddbc8ba89d14541d46617fc456725f69b29 Probably a mistake as it mentions commit 6bcdcd. I'd say just re-add your changes, revert that revert :-) Cheers, Emilio > > > Best, > Utkarsh > --- > [1]: > https://salsa.debian.org/webmaster-team/webwml/-/commit/3fa826e876fd342ecabeeaa0da6f1d21dd6a6181 > [2]: > https://salsa.debian.org/webmaster-team/webwml/-/commit/16a084b6ad0a1fbe83ac7b57a162d83d0356a334 > [3]: > https://salsa.debian.org/webmaster-team/webwml/-/commit/e52b2777d771f308ecdb741698e624a5ce128745 >
Re: DLA template and user signatures
On 13/07/2020 11:24, Sylvain Beucler wrote: > Hi, > > On 07/07/2020 12:01, Emilio Pozuelo Monfort wrote: >> - it was brought up that some DLAs include personal signatures at the end > > In what context did you receive this feedback? It was mentioned in #debian-lts when I brought up the topic of updating the DLA template, and then I said I would send an email to the list so everyone would get a chance to give feedback. Cheers, Emilio
Re: script to review no-dsa packages fixed in LTS-1 and TLS+1
On 19/07/2020 11:52, Thorsten Alteholz wrote: > Hi Emilio, > > thanks a lot for working on this. > > On Tue, 7 Jul 2020, Emilio Pozuelo Monfort wrote: >> CVE-2019-11187/gosa fixed in jessie and buster but no-dsa in stretch (Minor >> issue) > > This seems to have been fixed via opu. > >> CVE-2019-3866/mistral fixed in jessie and buster but no-dsa in stretch (Minor >> issue; can be fixed via point release) >> CVE-2019-3866/python-oslo.utils fixed in jessie and buster but no-dsa in >> stretch (Minor issue; can be fixed via point release) > > mistral in buster has been fixed via unstable, so should not be mentioned > here, > shouldn't it? > python-oslo.utils is in jessie. Probably one CVE for two > different packages resolved differently confused your script? Yeah, looks like the script tripped on that special case. I'll have a look at it. Thanks, Emilio
Reclaiming packages with no status update
Hi, On 20/07/2020 12:04, Holger Levsen wrote: > today there were two packages unclaimed for LTS: > and four for ELTS: I often notice that after each round of these unclaims, people tend to reclaim their packages without adding a note on the progress or status. Could I ask that when you reclaim a package you add a note mentioning where things stand? Cheers, Emilio
Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
Hi, On 21/08/2019 07:45, Salvatore Bonaccorso wrote: > Hi Holger, hi Emilio, > > [dropping debian-devel list] > > On Mon, Aug 19, 2019 at 11:01:13PM +0200, Moritz Mühlenhoff wrote: >> On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: >>> Hi, >>> Firefox 68 will be the next ESR release series. With the release of Firefox >>> 68.2 >>> on October 22nd, support for ESR 60 will cease. >>> >>> ESR 68 will require an updated Rust/Cargo toolchain and build dependencies >>> not >>> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). >>> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at least >>> no >>> requirement to bootstrap stage0 builds this time. >>> >>> If we want to continue to have Firefox/Thunderbird supported in >>> oldstable-security >>> after October, someone needs to step up to take care of backports to a >>> Stretch point >>> release before October 22nd (or in case of poor timing, we can also release >>> build >>> dependency updates via stretch-security). >> >> There hasn't been any visible movement on this, so unless someone steps up >> RSN, >> there'll be a headsup about the EOL in the next ESR 60 DSA, so that people >> have some advance warning. > > That would be really bad I guess both for users running stretch on > workstations for a while (we are affected for instance at work) and > for LTS as there were work so far by emilio to keep up firefox-esr and > thunderbird as well updated in jessie LTS. We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3 comes out. We have some time still, but if we want FF and TB to keep being supported, we'll have to do some toolchain backports as usual. Has someone started to look at this? I have taken a quick look and it looks like we need rustc 1.41 and cargo 0.31. We currently have: rustc | 1.34.2+dfsg1-1~deb9u1 | oldstable rustc | 1.34.2+dfsg1-1| stable rustc | 1.44.1+dfsg1-1| unstable cargo | 0.35.0-2~deb9u2 | oldstable cargo | 0.35.0-2| stable cargo | 0.43.1-3| unstable We may need other deps after those (such as an updated cbindgen or other modules) or some packages in order to build those (possibly LLVM 9, I'm not sure yet). Any help in updating these would be welcome. Thanks, Emilio
Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
Hi, On 21/08/2019 07:45, Salvatore Bonaccorso wrote: > Hi Holger, hi Emilio, > > [dropping debian-devel list] > > On Mon, Aug 19, 2019 at 11:01:13PM +0200, Moritz Mühlenhoff wrote: >> On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: >>> Hi, >>> Firefox 68 will be the next ESR release series. With the release of Firefox >>> 68.2 >>> on October 22nd, support for ESR 60 will cease. >>> >>> ESR 68 will require an updated Rust/Cargo toolchain and build dependencies >>> not >>> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). >>> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at least >>> no >>> requirement to bootstrap stage0 builds this time. >>> >>> If we want to continue to have Firefox/Thunderbird supported in >>> oldstable-security >>> after October, someone needs to step up to take care of backports to a >>> Stretch point >>> release before October 22nd (or in case of poor timing, we can also release >>> build >>> dependency updates via stretch-security). >> >> There hasn't been any visible movement on this, so unless someone steps up >> RSN, >> there'll be a headsup about the EOL in the next ESR 60 DSA, so that people >> have some advance warning. > > That would be really bad I guess both for users running stretch on > workstations for a while (we are affected for instance at work) and > for LTS as there were work so far by emilio to keep up firefox-esr and > thunderbird as well updated in jessie LTS. We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3 comes out. We have some time still, but if we want FF and TB to keep being supported, we'll have to do some toolchain backports as usual. Has someone started to look at this? I have taken a quick look and it looks like we need rustc 1.41 and cargo 0.31. We currently have: rustc | 1.34.2+dfsg1-1~deb9u1 | oldstable rustc | 1.34.2+dfsg1-1| stable rustc | 1.44.1+dfsg1-1| unstable cargo | 0.35.0-2~deb9u2 | oldstable cargo | 0.35.0-2| stable cargo | 0.43.1-3| unstable We may need other deps after those (such as an updated cbindgen or other modules) or some packages in order to build those (possibly LLVM 9, I'm not sure yet). Any help in updating these would be welcome. Thanks, Emilio
(E)LTS report for July
Hi, During this month I spent 60h on LTS working on: - coordinating stretch-lts handover with various teams - sent jessie EOL DLA, updated LTS/Using wiki page for stretch, improvements to DLA template - lts no-dsa script - glib-networking update via opu, checked if balsa/stretch needed a compatibility fix - file-roller update via opu - evolution-data-server update - atril update via opu - batik update via opu - librsvg update - tracker service python3 improvements - poppler update - clamav update (pending stable point release) - CVE triaging - sent firefox-esr announcement for FF 68.11.0esr - started to look at upcoming updates to firefox and thunderbird 78 ESR, which will need toolchain updates - investigating librsvg regression - json-c update As for ELTS, I spent 13.25h working on: - frontdesk and CVE triage - jessie-elts preparations - wheezy-elts EOL, website updates for jessie - batik update - perl update - tzdata and libdatetime-timezone-perl updates - glib-networking update - librsvg update - investigated and addressed processing errors in our security-tracker Cheers, Emilio
Making stretch-security build logs public
Hi,
I was wondering if we could make old stretch-security build logs public. I
suppose there's nothing private there anymore (no more embargoed updates in
stretch) and it can help in debugging issues with updates (e.g. I just uploaded
a new thunderbird version there and I've noticed that the previous versions
failed to build on arm{hf,64} and I wanted to refresh my memory on why.
Thanks,
Emilio
Re: slirp / CVE-2020-7039 / CVE-2020-8608
On 12/08/2020 01:04, Roberto C. Sánchez wrote: > On Wed, Aug 12, 2020 at 08:55:43AM +1000, Brian May wrote: >> I am seriously thinking that slirp from unstable should be ported as is >> from sid to buster and stretch. This is not a new upstream version, it >> has bug fixes and security updates only. Probably the same changes I >> would have to make myself in fact. Such as replacing sprintf calls with >> snprintf calls for example. >> >> This would fix CVE-2020-7039 and provide the prerequisite to fixing >> CVE-2020-8608. >> >> Only thing, I am not sure what to do with the versioning: >> >> stretch 1:1.0.17-8 >> buster 1:1.0.17-8 >> sid 1:1.0.17-10 >> >> In fact, because stretch and buster has the same version, does this mean >> I can't make any security uploads to stretch? >> >> On the other hand the security team has marked both these as no-DSA, in >> buster meaning maybe I should do the same thing too? > > I would ask the Security Team if they are open to considering taking > 1:1.0.17-10 into buster. The version would be 1:1.0.17-10~deb10u1. If > they agree, then you could subsequently upload to stretch with version > 1:1.0.17-10~deb9u1. If they are not open to considering it, then it > seems that the only viable course of action is the mark them no-dsa. Even if it's no-dsa, it can still be updated in buster via stable-proposed-updates. Cheers, Emilio
Re: gb: ghostscript_9.26a~dfsg-0+deb9u7
On 21/08/2020 14:08, Sylvain Beucler wrote: > Hello, > > ghostscript failed to build on armhf for stretch-security: > https://buildd.debian.org/status/fetch.php?pkg=ghostscript&arch=armhf&ver=9.26a%7Edfsg-0%2Bdeb9u7&stamp=1597941103&raw=0 > "./soobj/dxmainc.o: file not recognized: File truncated" > > I cannot find an explanation for this error, and the package builds > fine on porterbox abel.debian.org (see > ~beuc/ghostscript_9.26a~dfsg-0+deb9u7_armhf.build), so I suppose a > transient buildd failure occurred. > > giveback.cgi rejects requests due to targetting a security suite. > > Please rebuild ghostscript for stretch-security. > > gb 9.26a~dfsg-0+deb9u7 . armhf . stretch-security Scheduled (with ghostscript_ added before the version). Cheers, Emilio
Re: Making stretch-security build logs public
On 27/08/2020 09:17, Salvatore Bonaccorso wrote:
> Hi Emilio,
>
> On Tue, Aug 25, 2020 at 10:35:08PM +0200, Aurelien Jarno wrote:
>> Hi,
>>
>> On 2020-08-02 23:54, Emilio Pozuelo Monfort wrote:
>>> Hi,
>>>
>>> I was wondering if we could make old stretch-security build logs public. I
>>> suppose there's nothing private there anymore (no more embargoed updates in
>>> stretch) and it can help in debugging issues with updates (e.g. I just
>>> uploaded
>>> a new thunderbird version there and I've noticed that the previous versions
>>> failed to build on arm{hf,64} and I wanted to refresh my memory on why.
>>
>> Unfortunately I don't think this is something doable. The build logs for
>> non-public security builds are not kept on the wanna-build side. They
>> are sent to the security team. If someone in the team has kept them, we
>> can arrange to reinject them.
>
> I injected some of the previous build logs for firefox-esr/thunderbird
> (that said I have not (yet), injected them systematically back).
Thanks, much appreciated! If there's anything that I can do to help with this
(e.g. to reinject them automatically) then let me know.
btw I wonder if wanna-build could keep the logs somewhere, and publish them once
the update is published too?
Cheers,
Emilio
(E)LTS report for August
Hi, During the month of August, I have spent 21.75h working on: - clamav security update - thunderbird 68.11 update - libx11 security update - gupnp security update, including finding a UAF (use-after-free) issue that led to a server crash - security-tracker improvements in the python3 work - firefox-esr 78 progress (llvm 10, wasi-libc) - openjdk-8 security update - postgresql-9.6 announcement - attended the debconf meeting - firefox-esr 68.12.0 update For ELTS, I spent 14.25h working on: - gupnp update - triaging / frontdesk - openjdk-8 update, including updates to jtreg and ca-certificates-java - giving support/feedback for other updates Cheers, Emilio
Re: [Git][security-tracker-team/security-tracker][master] 2 commits: data/dla-needed.txt: Triage python-django for stretch LTS.
Hi Chris, On 01/09/2020 13:12, Chris Lamb wrote: > Commits: > 346825dd by Chris Lamb at 2020-09-01T12:12:17+01:00 > data/dla-needed.txt: Triage python-django for stretch LTS. > > - - - - - > 08bd2296 by Chris Lamb at 2020-09-01T12:12:23+01:00 > data/dla-needed.txt: Claim python-django. Don't the new django vulneravilities only apply when running with Python 3.7 or newer? If so, shouldn't we mark them as ignored for stretch and older? Or do you think there may be users with their own Python installations and so we should still fix this just in case? Cheers, Emilio
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On 01/09/2020 14:05, Christoph Martin wrote: > Hi, > > I am not shure if I can help, but I can try and have a look at it. > > Yes please upload your LLVM9 and wasi-libc backports. fwiw I started to look at this and have an LLVM 10 backport ready. Should we go with that instead? It may be more future-proof, in case we need it for a future rustc for the next ESR bump. Cheers, Emilio > > Regards > Christoph > > Am 31.08.20 um 20:26 schrieb Moritz Mühlenhoff: >> >>> I think we can reuse the same approach as before, by staging uploads >>> in -proposed-updates (or on stretch-security respectively) and then >>> configure the security chroots to use -proposed-updates until 10.6 >>> is eventually released. >> >> I can upload my backports of LLVM and wasi-libc, but this still needs a >> volunteer for >> the remaining parts (rustc/cargo) if we want to have firefox-esr / >> thunderbird >> in Buster after the end of ESR68. >> > > Christoph >
Re: [Git][security-tracker-team/security-tracker][master] 2 commits: data/dla-needed.txt: Triage python-django for stretch LTS.
On 02/09/2020 12:46, Chris Lamb wrote: > Chris Lamb wrote: >> >>> Don't the new Django vulnerabilities only apply when running with Python >>> 3.7 or >>> newer? >> >> Replying quickly — possibly, have not looked into the (E)LTS angle yet. >> >> I was just ensuring that there was no duplicated effort in the LTS >> team as I am the 'regular' maintainer of Django. Will adjust the >> situation when I return to this, either later today or early >> tomorrow. > > Just to follow up on this on-list. Yes, you are absolutely right that > they require Python 3.7 to be vulnerable. However, I did consider that > people were using virtualenv (or a similar mechanism) to use a newer > version of Python. This is, after all, by far the most common way > people are deploying Python web applications. > > However, I believe it is extremely unlikely that someone is using a > newer version of Python with our Debian-packaged version of Django. > Far more likely is that people using Python 3.7 in LTS or ELTS will be > using an equally old version of Django itself or a newer one... but > they will be obtaining it via a different means (e.g. via > requirements.txt). > > Therefore I will not be updating Django in LTS or ELTS with respect to > CVE-2020-24583 or CVE-2020-24584 and have updated the repositories to > reflect this. Makes sense, and I fully agree. Cheers, Emilio
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On 01/09/2020 19:17, Moritz Muehlenhoff wrote: > On Tue, Sep 01, 2020 at 04:35:42PM +0200, Emilio Pozuelo Monfort wrote: >> On 01/09/2020 14:05, Christoph Martin wrote: >>> Hi, >>> >>> I am not shure if I can help, but I can try and have a look at it. >>> >>> Yes please upload your LLVM9 and wasi-libc backports. >> >> fwiw I started to look at this and have an LLVM 10 backport ready. Should we >> go >> with that instead? > > I'm fine either way. > >> It may be more future-proof, in case we need it for a future >> rustc for the next ESR bump. > > My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to > be proven wrong :-) So maybe let's directly move to 10 directly. > > Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against > LLVM, then. Status update: - I've got a rustc bootstrap build (using upstream binaries) ready for buster/stretch, using LLVM 7 and no wasi-libc. - cargo using the above rustc and buster/stretch's cargo (no bootstrap necessary) - cbindgen building with the above That avoids the LLVM 9/10 update for this round. I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that goes well I'll start uploading things to buster (coordinating with the SRMs). Cheers, Emilio
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On 20/09/2020 11:33, Félix Sipma wrote: > Hello Emilio and others, > > On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote: >> I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that >> goes >> well I'll start uploading things to buster (coordinating with the SRMs). > > Was the build successful? Did you also try to build Thunderbird? Is there > something else missing? Yes, the Firefox build was successful and my runtime tests have been good too. We're working on fixing the toolchain on mips* now (thanks to Aurelien), but other than that there shouldn't be anything missing at this point with the recent upload of rust-cbindgen. I haven't managed to bootstrap rustc 1.41 on armel, that's not an issue for FF/TB as they can't build on armel due to the lack of nodejs, but it's a problem for armel itself if at some point an update to rustc is needed (e.g. to fix a security bug). If someone can help with that front, please see the rustc pu bug (#970132) and get in touch. I haven't looked at Thunderbird yet (see Carsten's message) but the toolchain should be the same, so in that regard we should be good. Cheers, Emilio
Re: [SECURITY] [DLA 2386-1] libdbi-perl security update
Hi Sylvain, On 28/09/2020 15:38, Sylvain Beucler wrote: > - > Debian LTS Advisory DLA-2386-1debian-lts@lists.debian.org > https://www.debian.org/lts/security/ > September 28, 2020https://wiki.debian.org/LTS > - Looks like you're missing DEBFULLNAME in your environment, as needed by gen-DLA. Would you mind fixing that for the next updates? Thanks, Emilio
(E)LTS report for September
Hi, During the month of September I have spent 19.75h on the following tasks: - security-tracker MRs - thunderbird regression update - libx11 security update - Lots of work to get ready for the Firefox & Thunderbird ESR 78 updates, with the ESR 68 branch going end-of-life on September 22nd with the release of Firefox ESR 78.3.0. This work benefited stretch as well as buster, and included updates to: llvm-toolchain-7, rustc, cargo, rust-cbindgen, nodejs and GCC. For ELTS I spent 33h working on the following: - investigated issue with security-tracker wheezy/jessie versions - wrote a script to detect and fix sec-tracker "unknown" CVEs - frontdesk & CVE triaging - security-tracker improvements (apt-update-file xz support) - clamav review and testing, found a stack smashing bug and fixed it. finished and released the update - openjdk-7 security update - prepared and started testing a linux 4.9 update. looked into automated testing for kernel updates Cheers, Emilio
Re: golang-go.crypto / CVE-2019-11841
Hi, On 06/10/2020 23:42, Brian May wrote: Utkarsh Gupta writes: Ah, great. It'd nice to include this then! :) Done. See attached patch. I had to apply it manually, because patch was misapplying one of the hunks in the wrong place. There were several hunks that apply to SKEd25519 public key stuff I skipped also because this version does not have SKEd25519 public key stuff. I note that some of the ssh tests are skipped because sshd is not installed. So I added "openssh-server" to the build depends, and found that one of the tests hangs. Even if I revert my changes. The tests related to these change appear to pass, even without openssh-server installed, so I think this is good to go. Have you checked if any rdeps need to be rebuilt? Cheers, Emilio
Re: [security tracker role] Processing a16b55300564d69f4c3d37a0c84cc41bf9b5638b failed
On 08/10/2020 01:50, Brian May wrote: I have no idea what is wrong here, or why it is fixated on a commit that is 2 commits behind master... There's some corruption on the git checkout on soriano. I'm looking at it. Emilio
Re: golang-go.crypto / CVE-2019-11841
On 08/10/2020 10:08, Brian May wrote: Emilio Pozuelo Monfort writes: Have you checked if any rdeps need to be rebuilt? No. I imagine there might be some. How do I check? I can't remember right now how to check reverse build depends. root@andromeda:/# grep-dctrl -FBuild-Depends 'golang-golang-x-crypto-dev' -sPackage /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_source_Sources | sort -u Package: acmetool Package: chasquid Package: coyim Package: go-wire Package: gocryptfs Package: golang-github-azure-azure-sdk-for-go Package: golang-github-azure-go-autorest Package: golang-github-azure-go-ntlmssp Package: golang-github-bowery-prompt Package: golang-github-coreos-ioprogress Package: golang-github-coreos-pkg Package: golang-github-elithrar-simple-scrypt Package: golang-github-endophage-gotuf Package: golang-github-howeyc-gopass Package: golang-github-kisom-goutils Package: golang-github-pkg-sftp Package: golang-github-rackspace-gophercloud Package: golang-github-weaveworks-mesh Package: golang-github-xenolf-lego Package: golang-github-xordataexchange-crypt Package: golang-golang-x-net-dev Package: golang-gopkg-dancannon-gorethink.v2 Package: golang-gopkg-macaroon.v1 Package: govendor Package: influxdb Package: mongo-tools Package: packer Package: rclone Package: restic Package: snapd Package: syncthing Package: tendermint-ed25519 Package: tendermint-go-merkle root@andromeda:/# grep-dctrl -FBuild-Depends 'golang-go.crypto-dev' -sPackage /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_source_Sources | sort -u Package: golang-ed25519-dev Package: golang-github-bradfitz-http2 Package: golang-github-endophage-gotuf Package: golang-pault-go-debian Package: influxdb Package: obfs4proxy Package: pluginhook (That's only checking on stretch main, but that should probably be sufficient). Note that many of those are golang modules which only ship go code on the -dev package, and thus don't need a rebuild. OTOH, compiled binaries may need a rebuild if they use the affected code (directly or indirectly). Cheers, Emilio
Re: golang-go.crypto / CVE-2019-11841
On 08/10/2020 10:30, Brian May wrote: Emilio Pozuelo Monfort writes: Note that many of those are golang modules which only ship go code on the -dev package, and thus don't need a rebuild. OTOH, compiled binaries may need a rebuild if they use the affected code (directly or indirectly). How do I tell which ones need rebuilding? Maybe just the ones without the 'golang-` prefix? That go be a simplification. However there's a chance one of those golang- packages also has a bin package with a real binary, and then that may need to be rebuilt as well. Also, not all packages with compiled binaries necessarily need a rebuild. E.g. they may not use the affected code at all, just other parts of golang-go.crypto. How do I rebuild? Do I need to upload a new version? Unless they already are in stretch-security, then yes, sourceful uploads will be needed. Cheers, Emilio
Re: [security tracker role] Processing a16b55300564d69f4c3d37a0c84cc41bf9b5638b failed
On 08/10/2020 09:52, Emilio Pozuelo Monfort wrote: On 08/10/2020 01:50, Brian May wrote: I have no idea what is wrong here, or why it is fixated on a commit that is 2 commits behind master... There's some corruption on the git checkout on soriano. I'm looking at it. Should be fixed now.
Re: golang-go.crypto / CVE-2019-11841
On 09/10/2020 00:23, Brian May wrote: We probably need someway of keeping track of what packages have already been looked at and their status with respect to this rebuild. Not really convinced data/dla-needed.txt is up to this task. I would look for an automated way to do this. E.g. by downloading and inspecting the binaries to see if they have the affected code. I think Adrian handled a go update and its rdeps in the past. Adding him to Cc in case he has any ideas. [...] However now I also realise another limitation in the above list. It probably won't mention, for example, packages that build depend on golang-github-pkg-sftp-dev which depends on golang-golang-x-crypto-dev. IIRC there was a tool that would help you with recursive deps of build-deps. Indeed, at least reverse-build-depends has a --recursive switch. So you could combine this with an automated check for the above to find what needs to be built. You could also talk to the Go team. They may already have tools to find what packages need to be rebuilt after a module is updated, or at least some feedback on how to look for them. Cheers, Emilio
Re: Future of MariaDB in stretch-lts (was: Re: CVE-2020-15180: MariaDB)
On 03/11/2020 20:02, Holger Levsen wrote: Hi Otto, On Mon, Nov 02, 2020 at 09:15:32PM +0200, Otto Kekäläinen wrote: I don't have any particular plans. I'll keep updating the package for as long as upstream provides updates. For 10.1 the updates are indeed officially over now: https://mariadb.org/about/#maintenance-policy What options do we have anyway? Does the LTS team think they should be responsible for providing security updates beyond what upstreams do? yes, that's what we often do. Or are you thinking about providing backports? or we do this ;) During the 10.5 packaging cycle I have tested building backports for every commit (see e.g. https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/191851). The galera-4 dependency is already available in stretch-backports-sloppy. If you are interested in backports, that could be a viable option. how compatible are 10.1 and 10.5? buster has 10.3, so if anything, we should upgrade to 10.3. However that's a major upgrade, so before doing that, we should consider carefully consider whether we can get 10.1 supported for longer (perhaps with some upstream help). Cheers, Emilio
(E)LTS report for October
Hi, During the month of October, I spent 20.75h on LTS: - investigated and addressed security-tracker corruption - golang-go.crypto analysis and advice - thunderbird 78 ESR update - investigated and fixed thunderbird armhf build failure - investigated thunderbird l10n bug report - mariadb-10.1 announcement - firefox-esr 78.4.0 update - thunderbird 78.4.0 update - openjdk-8 update - lts meeting For ELTS I spent 32h on the following: - CVE triaging - openjdk-8 update - linux 4.9 update - prepared openjdk-7 update, pending release - prepared phpmyadmin update, found a regression while testing, still on it - various security-tracker improvements Cheers, Emilio
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
Hi, On 16/11/2020 11:31, Holger Levsen wrote: There are three DLAs which have been reserved but not yet been published: - (15 Nov 2020) (libvncserver) - (10 Nov 2020) (moin) - (04 Nov 2020) (jupyter-notebook) These used to include the DLA number. Maybe those could be back? fwiw the jupyter-notebook DLA is not in -announce either, so it's not just missing in the website. Cheers, Emilio
Re: cacti graph zoom bug
On 17/11/2020 10:31, Utkarsh Gupta wrote: Hi LTS team, On Tue, Nov 17, 2020 at 1:27 AM Utkarsh Gupta wrote: On Tue, Nov 17, 2020 at 1:01 AM Matus UHLAR - fantomas wrote: I have submitted a bug, containing fix for this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974926 I'm not sure if anyone is willing to fix this in the stretch version, but if it's the case, here you are... This indeed warrants a fix. I'll upload the fixed version with the attached patch if no one beats me to it :) On taking a closer look at this issue, it looks like it'd be a good thing to get this fixed (also already fixed in buster!) but I am not so sure if it warrants a DLA for this. So before I prepare, test, and push the update, I want to make sure that it is indeed DLA-worthy. Please let me know what you think. Probably something to include in the next DLA. Cheers, Emilio
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 10:06, Thorsten Glaser wrote: Hi (E)LTS-people, I’ve just uploaded an OpenJDK 8 regression update to sid, sponsored by my employer (as below). (I’m also building locally for buster, wheezy and various *buntu releases, so all possible systems I may encounter are covered, which is why I’m invested.) Would it help if I also prepared uploads to stretch-security and jessie-something, or do you prefer to continue doing so on your own? If you can send a debdiff I'd be happy to take a look. Thanks, Emilio
Re: openjdk-8 8u275-b01-1
On 02/12/2020 11:21, Thorsten Glaser wrote: Hi Emilio, If you can send a debdiff I'd be happy to take a look. the debdiff between sid and stretch would be trivial, just changelog and the regenerated debian/control file (attached). I’m building it at the moment so I can test it first. Do you also need a debdiff against the version currently in stretch? I can do that as well, but it’s going to be somewhat larger. No need for that. Let me know how those tests go and we can proceed from there. Thanks, Emilio
Re: How to handle an update that includes a regression fix and a new fix?
On 15/12/2020 02:16, Roberto C. Sánchez wrote: I am curious if there is a policy or best practice for how to handle a package update containing both a regression fix and also a fix for a new vulnerability. If such a thing is not advisable or permissible, then is it best to handle the regression as one update and then follow-up with the new vulnerability fix as a subsequent update? Just one update, and one announcement as a new DLA (-1) mentioning the regression fix. See e.g. https://lists.debian.org/debian-security-announce/2020/msg00139.html https://lists.debian.org/debian-lts-announce/2019/02/msg00032.html https://lists.debian.org/debian-lts-announce/2020/06/msg00012.html Cheers, Emilio
(E)LTS report for November
Hi, During the last month I have spent 22.75h on LTS working on: - thunderbird security updates - libproxy security update - security-tracker improvements - firefox-esr security update - drupal7 announcements - lts meeting - postgresql-9.6 announcement - xorg-server security update - preparations for openssl & openssl1.0 I also spent 40h on ELTS working on: - CVE triaging - openjdk-7 security update - phpmyadmin security update - python-werkzeug security update - php5: investigation of unapplied fixes - lxml security updates - xorg-server security update - security-tracker - openssl security update - phpldapadmin: backport and verification of upstream fix Cheers, Emilio
Regression in lxml in buster/stretch
Hi, There's a regression in both buster and stretch in the last update of lxml when running under Python 2: >>> import lxml.html.clean Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/lxml/html/clean.py", line 73, in r'>> The fix is [1]. I recently added support to run the tests to lxml (see #976148). When enabling the test suite, this bug is exposed (tested in stretch, should be similar in buster): python2.7 test.py -vv Traceback (most recent call last): File "test.py", line 625, in exitcode = main(sys.argv) File "test.py", line 562, in main test_cases = get_test_cases(test_files, cfg, cov=cov) File "test.py", line 268, in get_test_cases module = import_module(file, cfg, cov=cov) File "test.py", line 209, in import_module mod = __import__(modname) File "/build/lxml-3.7.1/src/lxml/html/tests/test_clean.py", line 6, in from lxml.html.clean import Cleaner, clean_html File "/build/lxml-3.7.1/src/lxml/html/clean.py", line 73, in r'And with the patch applied, the tests run, although some of the clean tests are failing, probably because the last patch didn't backport the test suite changes (which was not a problem as the tests weren't being run). Roberto, my changes for stretch are in [3]. Would you like to take a look at this and finish it (probably backporting the test changes from [2]) or should I? Moritz, if you want I can look at buster too. Cheers, Emilio [1] https://github.com/lxml/lxml/commit/4cb57362deb23bca0f70f41ab1efa13390fcdbb1 [2] https://github.com/lxml/lxml/commit/a105ab8dc262ec6735977c25c13f0bdfcdec72a7 [3] https://people.debian.org/~pochu/lxml_3.7.1-1+deb9u3.dsc
Re: Regression in lxml in buster/stretch
On 18/12/2020 00:05, Roberto C. Sánchez wrote: Uggh. If only I had waited a few more hours to upload. I have the advisory text ready but have not yet published the DLA. Your changes for deb9u3 look good. Would you go ahead and upload deb9u3 and I will publish the advisory once it is built. Done, it's building now (it may take a bit longer than previous builds due to the newly enabled test suite). I have verified (both through the test suite and through manual testing of the package) that the module can now be imported. On 17/12/2020 23:24, Moritz Muehlenhoff wrote: >> Moritz, if you want I can look at buster too. > > Ack, please do. The code is all quite similar across older distros from what > I remember. Same changes (test suite changes + fix) uploaded to buster-security as well. Cheers, Emilio
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 20:39, Thorsten Glaser wrote: On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote: Let me know how those tests go and we can proceed from there. It builds, with the usual “most tests pass”, and the test program I threw at it also works. I have released this to stretch and jessie (after some testing on the latter). Cheers, Emilio
Re: How to backport test binaries?
On 03/02/2021 07:45, Utkarsh Gupta wrote: Hello, On several occasions, I've seen that fixing commits of CVEs have some sort of binaries (either an image or some compressed file or whatever) added as a test to ensure that the fix is indeed working as expected. And whilst trying to backport, the patches don't seem to like git binaries and so they complain with: ```git binary diffs are not supported``` How do we work around that? Do we not backport these binaries and just test the upstream way? I'd like to backport such binaries but unsure how to. Let me know how do y'all deal with this. You can put the binary in the right location and add it to debian/source/include-binaries (assuming source format 3.0), then it will be shipped in the debian.tar. Cheers, Emilio
Re: CVE-2020-36193 php-pear vs drupal7
On 25/02/2021 10:09, Chris Lamb wrote: Morning Ola, Today I looked at CVE-2020-36193 since we have php-pear in dla-needed. Ths thing is that this CVE tells that drupal7 is also vulnerable but drupal7 is not in dla-needed.txt. It may be that drupal7 was not marked as being vulnerable to CVE-2020-36193 at the time of triage. After all, the code copy of Tar.php (in "system.tar.inc") is very slightly hidden. I would go ahead and add drupal7 as well -- a very quick glance suggests that it is, indeed, vulnerable. Also please coordinate with drupal7's maintainer (in Cc), who has been taking care of the package in stretch. Thanks, Emilio
Re: DLA 2550-1: CVE-2020-27844: Patch present in source but not applied?
Hi, On 15/03/2021 12:36, Salvatore Bonaccorso wrote: Hi Brian, LTS team, This was reported by the Ubuntu security team: The DLA 2550-1 update was aiming to fix CVE-2020-27844 as well, but it looks that whilst a patch is included in debian/patches the series files does not apply it. To be on safe side I have removed the listing for CVE-2020-27844 in the DLA 2550-1, but please double-check if this is correct? I have taken a look and that version is not vulnerable to CVE-2020-27844, so removing it from DLA-2550-1 is correct. Thanks! I have added some clarification in data/CVE/list, buster isn't affected either. Cheers, Emilio
