Bug#1033670: unblock: xwayland/2:22.1.9-1
n > (cherry picked from commit 511d1686a6ac3e3e0d66fb67b62620ba2a6575c8) > > hw/xwayland/xwayland-output.c | 16 > hw/xwayland/xwayland-output.h | 1 + > 2 files changed, 17 insertions(+) > > commit 7d039914ff5baf1ebd5dca1ddcb8d3a74ba3587e > Author: Minh Phan > Date: Tue Nov 29 19:35:13 2022 +0700 > > randr: introduce rrCrtcGetInfo DDX function > > This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo > reply. One use case is to allow Xwayland to return the current emulated > mode for the specific client instead of the global mode. > > Signed-off-by: Minh Phan > Acked-by: Olivier Fourdan > (cherry picked from commit 5145742fb6e3d108b05db1521b51112e0dbfb95a) > > randr/randrstr.h | 8 > randr/rrcrtc.c | 3 +++ > 2 files changed, 11 insertions(+) > > commit cedf933c7cbbc0285e7f9ddb17706b9a8d84f6aa > Author: Doğukan Korkmaztürk > Date: Tue Nov 22 13:43:16 2022 -0500 > > GLX: Free the tag of the old context later > > In CommonMakeCurrent() function, the tag of the old context is freed > before the new context is made current. This is problematic because if > the CommonMakeNewCurrent() function fails, the tag of the old context > ends up being removed, even though it is still active. This causes > subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to > generate a GLXBadContextTag error. > > This change moves the function call that frees the old tag to a location > where the result of CommonMakeNewCurrent() call is known and it is safe > to free it. > > Signed-off-by: Doğukan Korkmaztürk > (cherry picked from commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3) > > glx/vndcmds.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > commit e982ca4420a6003c97cb076ee40172e904ce290a > Author: Doğukan Korkmaztürk > Date: Tue Nov 8 10:05:59 2022 -0500 > > xwayland/glx: Mirror all EGLConfigs > > Updated the for-loop that iterates over the received EGLConfigs to > include the very first EGLConfig with index 0. > > Signed-off-by: Doğukan Korkmaztürk > Fixes: 8469241592 - xwayland: Add EGL-backed GLX provider > (cherry picked from commit 3852b0d10a061348ea8214fbcbef3c5c08cac0b6) > > hw/xwayland/xwayland-glx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > commit 4303ddfbf98023f33c1067007543df345c68b459 > Author: Corentin Noël > Date: Mon Aug 1 16:03:38 2022 +0200 > > glamor: Only check for llvmpipe renderer > > The virgl driver exposes the name of the host renderer which might be > llvmpipe. > In this case we still need glamor to be initialized. > > Only check if the renderer starts with llvmpipe (which is what llvmpipe > exposes). > > Signed-off-by: Corentin Noël > Reviewed-by: Adam Jackson > (cherry picked from commit fdebbc60d89cdc1b3353424b6568b25a61dcf372) > > glamor/glamor_egl.c | 2 +- > hw/xwayland/xwayland-glamor-gbm.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > commit bc288f59a4d6bf5e713f1473e42d9cdb20d879bf > Author: Lucas Stach > Date: Sun Jul 10 17:51:14 2022 +0200 > > xwayland: properly get FDs from multiplanar GBM BOs > > Multiplanar GBM buffers can point to different objects from each plane. > Use the _for_plane API when possible to retrieve the correct prime FD > for each plane. > > Signed-off-by: Lucas Stach > Reviewed-by: Simon Ser > Tested-by: Guido Günther > (cherry picked from commit 7d5ad2d372cc88648f6744c318a4bee18443689d) > > hw/xwayland/xwayland-glamor-gbm.c | 66 > +-- > 1 file changed, 57 insertions(+), 9 deletions(-) > > commit 57db30e637192df0600999cd40ec14edbeb1c68a > Author: Lucas Stach > Date: Thu Jul 28 22:44:59 2022 +0200 > > xwayland: handle fd export failure in glamor_egl_fds_from_pixmap > > Check the fd for validity before giving a success return code. > > Signed-off-by: Lucas Stach > Reviewed-by: Simon Ser > Tested-by: Guido Günther > (cherry picked from commit 951502e49797ab4c5db047e9df32c93d050d64af) > > hw/xwayland/xwayland-glamor-gbm.c | 7 +++ > 1 file changed, 7 insertions(+) unblock xwayland/2:22.1.9-1 diff -Nru xwayland-22.1.8/composite/compwindow.c xwayland-22.1.9/composite/compwindow.c --- xwayland-22.1.8/composite/compwindow.c 2023-02-07 08:30:43.0 +0100 +++ xwayland-22.1.9/composite/compwindow.c 2023-03-29 14:22:52.0 +0200 @@ -620,6 +620,11 @@
Bug#1033668: unblock: xorg-server/2:21.1.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: jcris...@debian.org Please unblock package xorg-server [ Reason ] CVE-2023-1393 [ Risks ] Simple patch to reset a pointer to freed memory. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock xorg-server/2:21.1.7-2 diff --git a/composite/compwindow.c b/composite/compwindow.c index 73a1871a0b..9a651636e3 100644 --- a/composite/compwindow.c +++ b/composite/compwindow.c @@ -620,6 +620,11 @@ compDestroyWindow(WindowPtr pWin) ret = (*pScreen->DestroyWindow) (pWin); cs->DestroyWindow = pScreen->DestroyWindow; pScreen->DestroyWindow = compDestroyWindow; + +/* Did we just destroy the overlay window? */ +if (pWin == cs->pOverlayWin) +cs->pOverlayWin = NULL; + /*compCheckTree (pWin->drawable.pScreen); can't check -- tree isn't good*/ return ret; } diff --git a/debian/changelog b/debian/changelog index 0949487831..f7e8a40cb5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +xorg-server (2:21.1.7-2) unstable; urgency=high + + * composite: Fix use-after-free of the COW +ZDI-CAN-19866/CVE-2023-1393 + + -- Julien Cristau Wed, 29 Mar 2023 15:11:07 +0200 + xorg-server (2:21.1.7-1) unstable; urgency=medium * New upstream release
Bug#1032886: unblock: ca-certificates/20230311
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ca-certifica...@packages.debian.org, jcris...@debian.org Control: affects -1 + src:ca-certificates Please unblock package ca-certificates [ Reason ] Update root CA store, and fix RC FTBFS bug. [ Impact ] Key package FTBFS, root store data is 2 years out of date. [ Tests ] N/A, the changes are 1) update to data files, 2) FTBFS fix by updating a build-time script, 3) trivial compat fix for update-ca-certificates. [ Risks ] Changes are reasonably minimal. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock ca-certificates/20230311 Thanks, Julien
Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1
Control: tag -1 confirmed On Sun, Mar 27, 2022 at 09:04:03PM +0200, Salvatore Bonaccorso wrote: > Okay attached the alternative, and only cherry-pick the 014 patch > upstream to address #1003012. Would that be acceptable instead? > That's fine, thanks. Cheers, Julien
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
Hi, Specifically, we were hoping to better understand the risk of openssl changes breaking existing setups. It's possible the issues with gnutls and libnet-ssleay-perl tests were narrowly scoped enough that that risk is low, but we're just not sure right now. Other input would be welcome. Thanks, Julien On Mon, Mar 21, 2022 at 08:23:20PM +, Adam D. Barratt wrote: > On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote: > > Dear Sebastian, Kurt, > > > > On 19-03-2022 12:33, Adam D Barratt wrote: > > > Upload details > > > == > > > > > > Package: openssl > > > Version: 1.1.1n-0+deb10u1 > > > > > > Explanation: new upstream release > > > > We're seeing a regression in buster in the autopkgtest of gnutls28 > > with > > the new version of openssl on all tested architectures. Can you > > please > > have a look and advise? (bullseye doesn't seem to have the test > > anymore, > > hence it doesn't fail). > > Thanks to both Kurt and Sebastian for quickly identifying the issue > here, and to Adrian Bunk for the libnet-ssleay-perl fix. > > There's been some continued discussion today as to whether we feel > comfortable releasing the update with the 10.12 point release when we > have only been finding such issues during the week leading up to the > point release. > > I fully appreciate that the large delays in getting to this point were > mostly on our part, and that postponing the release until 10.13 would > likely be frustrating, but the worry is that we don't have a good view > of the changes that might be user-affecting in order to be comfortable > with potential behaviour changes landing in oldstable - for example, > the libnet-ssleay-perl issue appears to be related to 1024-bit keys no > longer being accepted by default; while in general this is obviously a > desirable behaviour, it is nonetheless a change in the behaviour > compared to the current package in buster. > > The situation is also slightly complicated by the fact the debian- > installer uses OpenSSL internally, so we are also under internal time > pressure to reach a conclusion, in order to be able to proceed with the > installer build for the point release, rather than being able to leave > the decision until the end of the week. > > Thank you for bearing with us. > > Regards, > > Adam >
Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1
On Mon, Mar 21, 2022 at 03:46:01PM +0100, Michael Biebl wrote: > > Am 21.03.22 um 15:36 schrieb Julien Cristau: > > > Yes. Thanks for the due diligence. > > Just a quick question: > Which version number should I pick? > > a/ 1.30.6-1~deb11u1 > b/ 1.30.6-1+deb11u1 > c/ 1.30.6-2 > > > I think, now that I have made changes (with the revert of the WPA3 bits) > compared to 1.30.6-1, b/ is the most suitable one. But I wanted to double > check before I upload. > b/ sounds good :) Thanks, Julien
Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1
Control: tag -1 confirmed On Mon, Mar 21, 2022 at 03:28:48PM +0100, Michael Biebl wrote: > > Hi Julien > > Am 18.03.22 um 16:46 schrieb Julien Cristau: > > Control: tag -1 moreinfo > > > > Hi Michael, > > > > Sorry it took so long to get to this. I've got a couple of questions > > from the NEWS file; will keep looking at the actual diff though. > > > > On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote: > > > === > > > NetworkManager-1.30.6 > > > Overview of changes since NetworkManager-1.30.4 > > > === > > > > > > * By default, don't touch existing traffic control (TC) configuration > > >on devices. > > > > This sounds like it could cause unexpected changes. Unsure about the > > risk here. > > The relevant bug report is > https://bugzilla.redhat.com/show_bug.cgi?id=1928078 > > From the git commit > " > core,libnm: don't touch device TC configuration by default > [...] > > So, the new default behavior seems better than the previous one. > > " > > I'd say the above reasoning makes sense to me. > I wasn't arguing that any of these changes were bad, they do sound like improvements, my question was around the potential for unexpected side effects, which we try to avoid in stable, even when it means having to live with known bugs. I'm happy to trust your judgement there, just wanted to raise this. [...] > > > * Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK > > > > What's the regression risk here, of things working without WPA3 but not > > with it enabled? > > That one I indeed missed. Thanks for spotting it. It has indeed the > potential to break existing setups (as evidenced by [1]), although I think > that would also need a newer wpasupplicant in stable. > > The relevant upstream issue is > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638 > > I think reverting these commits for stable would make sense. > > Julien, if I revert the three commits from this MR, would you be ok with the > upload? > Yes. Thanks for the due diligence. Cheers, Julien
Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1
Control: tag -1 moreinfo On Sat, Feb 26, 2022 at 03:25:09PM +0100, Salvatore Bonaccorso wrote: > There was a request in #1003012 to fix an issue in bash corrupting > multibyte characters in command substitutions. > > While looking at it I'm proposing here instead of only picking the 014 > patch, to pick up all the changes done since from the bullseye release > on top and so proposing a rebuilding of 5.1-6 which was expoed in > testing for awhile now. Only change reverted would be the bump of > standards version but still including the drop of the pre-wheezy > preinst for the "dash-as-sh"-transition. > > Attached is the resulting debdiff as proposed with the rebuild. > > Matthias, Stable release managers what do you think on the update? > I'm unconvinced. Dropping the preinst seems way out of scope for a stable update, as for the other changes it's unclear to me what their impact/risk is. Cheers, Julien
Bug#1003948: bullseye-pu: package systemd/247.3-7
Control: tag -1 confirmed On Tue, Jan 18, 2022 at 02:46:06PM +0100, Michael Biebl wrote: > * Demote systemd-timesyncd from Depends to Recommends. > This avoids a dependency cycle between systemd and systemd-timesyncd and > thus makes dist upgrades more predictable and robust. > It also allows minimal, systemd based containers where no NTP client is > strictly necessary. > To ensure that systemd-timesyncd is installed in a default installation > created by d-i, bump its priority to standard. > (Closes: #986651, #993947) > > This one is probably the trickiest (and possibly also the simplest) > change. It simply breaks a dependency loop between systemd and > systemd-timesyncd resulting in a more predictable upgrade sequence which > in turn ensures that modifications of systemd-timesyncd's conffiles are > preserved on upgrades. > Difficult to predict the side effects this might have, but on the whole it's probably better to do this than not. Go ahead. Cheers, Julien
Bug#1004580: bullseye-pu: package logrotate/3.18.0-2
On Sun, Jan 30, 2022 at 07:23:20PM +0100, Christian Göttsche wrote: > [ Reason ] > Logrotate does not reject invalid files as configuration files and > tries to parse at least parts of them. > Those files for example might be crafted coredumps, placed in > /etc/logrotate.d/ via an unsafe core dump handler. > Be more strict while parsing configuration files. See > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002022 > https://github.com/logrotate/logrotate/pull/427 > https://www.openwall.com/lists/oss-security/2021/10/20/2 > > Also include two other fixes, one using the correct stat information > when verifying an olddir configuration after creating the olddir, the > other advancing pointer in full_write on incomplete write to avoid > data corruption. > Go ahead, thanks. Cheers, Julien
Bug#1003713: bullseye-pu: package telegram-desktop/3.1.1+ds-1~deb11u2
Control: tag -1 confirmed On Fri, Jan 14, 2022 at 09:00:40AM +0300, Nicholas Guriev wrote: > [ Reason ] > Telegram migrated from 32-bit user identifiers to 64-bit introducing > backward > incompatible changes in their API. Because of that, a version of the > package > currently in bullseye almost cases to work. > Then I was asked several times to propose an update of the package. > > [ Impact ] > Users cannot login. And the package in stable is unusable. > > [ Tests ] > This update was already uploaded to backports some time ago. And no > significant > issues have been reported about that version. > > [ Risks ] > Many. There is a huge amount of new code. But alternative would be to > delete > the package entirely. Although this is leaf package, any issues do not > affect > other software. > Unfortunate, but I guess we don't have much of a choice, so go ahead. How often do such incompatible changes happen, historically? Cheers, Julien
Bug#1003261: bullseye-pu: package postfix/3.5.6-1
Control: tag -1 confirmed On Fri, Jan 07, 2022 at 12:37:35AM -0500, Scott Kitterman wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > > I've put together my usual postfix post-release update. Because I'm > behind, it's rather larger than usual. Also, a number of packaging bugs > that apply to bullseye have been recently fixed in Bookworm, so the low > risk changes there have been backported too. > > The diff is rather large, so I don't include it in the original bug > report to increase the chances this makes it to the mailing list. > Go ahead, thanks. I noticed a typo in postfix.postinst: + # If the user has picked something other than sntp, keep it s/sntp/smtp/ :) Cheers, Julien
Bug#1002563: bullseye-pu: package gbonds/2.0.3-16+deb11u1
Control: tag -1 confirmed On Thu, Dec 23, 2021 at 10:58:17PM -0600, Richard Laager wrote: > [ Reason ] > gbonds is a program to track U.S. Savings Bonds and show their current > redemption value. To do so, it needs updated valuation data from the > U.S. Treasury twice a year. For nearly 30 years, Treasury has > released this data in flat file format. These were recently > discontinued in favor of an HTTP JSON API. The old files were removed > from Treasury's FTP site and I have it on good authority that they are > not coming back. > > This is Debian bug #1001610. > Seems fair, thanks. Cheers, Julien
Bug#1000355: bullseye-pu: package nano/5.4-2+deb11u1
Control: tag -1 confirmed On Mon, Nov 22, 2021 at 01:29:56AM +0100, Jordi Mallach wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > > As we did early during the freeze, nano's upstream Benno Schulenberg has > been maintaining a series of patches against nano 5.4, which backport > crashes fixes and other big impact fixes for Debian's version of nano. > > [ Impact ] > > We will miss several crash (and general bugs) fixes in different > situations and scenarios. > > [ Tests ] > > Patches have been tested individually against 5.4, and have had a wider > testing in the newer nano versions in which the fixes were introduced. > > [ Risks ] > > There is a big amount of patches, but most of them are one or > two-liners. Of course, the risk of any of them introducing new bugs is > real, but given Benno's knowledge of the codebase, it is unlikely. > > [ Checklist ] > [X] *all* changes are documented in the d/changelog > - I've only mentioned the addition of a bundle of patches, not > each one of them in detail. I can add a list of patches like in > the changes section below, if that's preferred. > [X] I reviewed all changes and I approve them > [X] attach debdiff against the package in (old)stable > [X] the issue is verified as fixed in unstable > Go ahead, thanks. Cheers, Julien
Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1
On Fri, Mar 18, 2022 at 04:46:47PM +0100, Julien Cristau wrote: > Control: tag -1 moreinfo > > Hi Michael, > > Sorry it took so long to get to this. I've got a couple of questions > from the NEWS file; will keep looking at the actual diff though. > Nothing else jumps out at me from the diff, so while I'd welcome more details on the risk analysis for the below, feel free to upload. Cheers, Julien > On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote: > > === > > NetworkManager-1.30.6 > > Overview of changes since NetworkManager-1.30.4 > > === > > > > * By default, don't touch existing traffic control (TC) configuration > > on devices. > > This sounds like it could cause unexpected changes. Unsure about the > risk here. > > > * Prefer the IPv4 address to determine the system hostname via address > > lookup. > > Likewise. What's the reasoning to do this in a stable update? > > > * Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK > > What's the regression risk here, of things working without WPA3 but not > with it enabled? > > Cheers, > Julien
Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1
Control: tag -1 moreinfo Hi Michael, Sorry it took so long to get to this. I've got a couple of questions from the NEWS file; will keep looking at the actual diff though. On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote: > === > NetworkManager-1.30.6 > Overview of changes since NetworkManager-1.30.4 > === > > * By default, don't touch existing traffic control (TC) configuration > on devices. This sounds like it could cause unexpected changes. Unsure about the risk here. > * Prefer the IPv4 address to determine the system hostname via address > lookup. Likewise. What's the reasoning to do this in a stable update? > * Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK What's the regression risk here, of things working without WPA3 but not with it enabled? Cheers, Julien
Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2
Control: severity -1 normal
Control: retitle -1 bullseye-pu: package glewlwyd/2.5.2-2+deb11u3
Control: tag -1 moreinfo
On Thu, Mar 17, 2022 at 09:17:12PM -0400, Nicolas Mora wrote:
> [ Reason ]
> Possible buffer overflow on signature verification during webauthn assertion
>
> [ Impact ]
> Possibility of denial of service
>
> [ Checklist ]
> [X] *all* changes are documented in the d/changelog
> [X] I reviewed all changes and I approve them
> [X] attach debdiff against the package in (old)stable
The below is not a debdiff, and doesn't include a changelog entry. :(
> [X] the issue is verified as fixed in unstable
>
> [ Changes ]
> Check the length of the signature before verifying it
>
What's the change of o_base64url_decode to o_base64_decode about?
Cheers,
Julien
> [ Other info ]
> CVE ID request pending
> Description: Fix buffer overflow
> Author: Nicolas Mora
> Forwarded: not-needed
> --- a/src/scheme/webauthn.c
> +++ b/src/scheme/webauthn.c
> @@ -2336,12 +2336,24 @@
> break;
>}
>
> - if (!o_base64url_decode((const unsigned char
> *)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")),
> json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")), sig, _len)) {
> -y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Error
> o_base64url_decode signature");
> + if (!o_base64_decode((const unsigned char
> *)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")),
> json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")), NULL, _len)) {
> +y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Invalid
> signature format");
> ret = G_ERROR_PARAM;
> break;
>}
>
> + if (sig_len > 128) {
> +y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Invalid
> signature");
> +ret = G_ERROR_PARAM;
> +break;
> + }
> +
> + if (!o_base64_decode((const unsigned char
> *)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")),
> json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
> "credential"), "response"), "signature")), sig, _len)) {
> +y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Error
> o_base64_decode signature");
> +ret = G_ERROR;
> +break;
> + }
> +
>memcpy(data_signed, auth_data, auth_data_len);
>memcpy(data_signed+auth_data_len, cdata_hash, cdata_hash_len);
>
Bug#1006293: bullseye-pu: package plasma-desktop/4:5.20.5-4
Control: tag -1 moreinfo On Tue, Feb 22, 2022 at 10:45:21PM +0100, Patrick Franz wrote: > A bug in plasma-discover causes a Denial of Service attack > against the KDE servers. 3 packages needs to be patch to > mitigate the attack: knewstuff, plasma-desktop and > plasma-discover. > This update fixes bug #1006125 for bullseye and has been > fixed in unstable. > Can you clarify the issue and how the 3 affected packages interact? The mailing list links seem to talk about plasma-discover's KNS backend so I guess I understand that part, how are plasma-desktop and knewstuff involved?
Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3
Control: tag -1 confirmed On Tue, Feb 22, 2022 at 10:38:05PM +0100, Patrick Franz wrote: > [ Reason ] > A bug in plasma-discover causes a Denial of Service attack > against the KDE servers. 3 packages needs to be patch to > mitigate the attack: knewstuff, plasma-desktop and > plasma-discover. > This update fixes bug #1006124 for bullseye and has been > fixed in unstable. > > [ Impact ] > Running the old version causes considerable load for the KDE > servers. > > [ Tests ] > No manual tests have been performed. > > [ Risks ] > The risks are rather low as the update is a single patch. > The patch has been created by KDE upstream specifically for the > version in bullseye. > > [ Checklist ] > [x] *all* changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in (old)stable > [x] the issue is verified as fixed in unstable > > [ Changes ] > The update contains a single patch to help ease the load on > KDE servers. > > [ Other info ] > It would be good if users of KDE plasma could receive the update > as quick as possible. Thanks, go ahead. Cheers, Julien
Bug#1004483: bullseye-pu: package xserver-xorg-video-intel/2:2.99.917+git20200714-1+deb11u1
On Fri, Jan 28, 2022 at 05:38:02PM +0100, Julien Cristau wrote: > +xserver-xorg-video-intel (2:2.99.917+git20200714-1+deb11u1) bullseye; > urgency=medium I should have said, this is currently in pu-new. Cheers, Julien
Bug#1004483: bullseye-pu: package xserver-xorg-video-intel/2:2.99.917+git20200714-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jcris...@debian.org
[ Reason ]
Due to an issue with the way it sets compiler flags for sse2 routines,
the intel Xorg driver was compiled with sse2 enabled for more than just
the code that's guarded by cpu checks, and as a result X crashed with
SIGILL on old CPUs.
[ Impact ]
No Xorg for users with those CPUs. This driver is dead upstream but is
still what we use for some old intel chips that may not work as well
with the generic modesetting driver.
[ Tests ]
3 users have confirmed the patched package fixes the issue for them.
[ Risks ]
Patch is fairly trivial, instead of
#pragma GCC push_options target("sse2,inline-all-stringops,fpmath=sse")
[sse2 code]
#pragma GCC push_options
[other code]
we replace the second push_options with a pop_options so the [other
code] isn't compiled to the wrong target.
(Now that I look at the code again I notice another bug where the sse2
use is guarded by "#if defined(sse2) && __x86_64__" where I think the &&
should be a ||, so even on CPUs with SSE2 the optimized code won't
get used anymore on i386. But I suspect the impact of that bug is a small
perf hit, so we're probably OK with that?)
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
Cheers,
Julien
debian/patches/sna-sse2.diff| 22
++
xserver-xorg-video-intel-2.99.917+git20200714/debian/changelog |7 +++
xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/series |2
3 files changed, 30 insertions(+), 1 deletion(-)
diff -u xserver-xorg-video-intel-2.99.917+git20200714/debian/changelog
xserver-xorg-video-intel-2.99.917+git20200714/debian/changelog
--- xserver-xorg-video-intel-2.99.917+git20200714/debian/changelog
+++ xserver-xorg-video-intel-2.99.917+git20200714/debian/changelog
@@ -1,3 +1,10 @@
+xserver-xorg-video-intel (2:2.99.917+git20200714-1+deb11u1) bullseye;
urgency=medium
+
+ [ Julien Cristau ]
+ * Fix SIGILL crash on non-SSE2 CPUs (closes: #979276)
+
+ -- Julien Cristau Wed, 26 Jan 2022 17:56:02 +0100
+
xserver-xorg-video-intel (2:2.99.917+git20200714-1) unstable; urgency=medium
* New upstream snapshot. (Closes: #959400)
diff -u xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/series
xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/series
--- xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/series
+++ xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/series
@@ -1 +1 @@
-#placeholder
+sna-sse2.diff
only in patch2:
unchanged:
---
xserver-xorg-video-intel-2.99.917+git20200714.orig/debian/patches/sna-sse2.diff
+++ xserver-xorg-video-intel-2.99.917+git20200714/debian/patches/sna-sse2.diff
@@ -0,0 +1,22 @@
+From 3d9f93d8bc5dfe2b79d4e16b8b5a6ce13b0792af Mon Sep 17 00:00:00 2001
+From: Julien Cristau
+Date: Fri, 21 Jan 2022 13:50:12 +0100
+Subject: [PATCH xf86-video-intel] Fix SIGILL crash on non-SSE2 CPUs (closes:
+ #979276)
+
+diff --git a/src/sna/blt.c b/src/sna/blt.c
+index afc719f6..803c5142 100644
+--- a/src/sna/blt.c
b/src/sna/blt.c
+@@ -631,7 +631,7 @@ memcpy_between_tiled_x__swizzle_0__sse2(const void *src,
void *dst, int bpp,
+ }
+ }
+
+-#pragma GCC push_options
++#pragma GCC pop_options
+ #endif
+
+ fast void
+--
+2.30.2
+
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
On Mon, Dec 06, 2021 at 02:20:16PM +0100, Hilko Bengen wrote: > * Julien Cristau: > > > Control: tag -1 confirmed > > > > On Wed, Dec 01, 2021 at 07:38:23PM +0100, Christoph Biedl wrote: > >> Christoph Biedl wrote... > >> > >> > About next steps, I would do the upload in the next days. Let me know if > >> > you prefer other things to happen first or instead. > >> > >> To avoid this gets lost I've just uploaded http-parser 2.8.1-1+deb10u2. > >> Updated debiff attached, only editorial changes since the previous mail. > >> > > Thanks. My only question is has anyone double checked none of the > > reverse deps access content_length (the patch comment suggests you have, > > but...)? > > I inspected the reverse dependencies for the following: > > - code relying on size of struct http_parser (all of them) > - code accesses http_parser.content_length (none found) > - code accesses some other fields that we might use for storing the > extra bit > > Christoph double-checked my findings and did more tests. > Sounds great, thank you! Cheers, Julien
Bug#993100: bullseye-pu: package udisks2/2.9.2-2+deb11u1
Control: tag -1 - moreinfo Control: tag -1 + confirmed On Sun, Dec 05, 2021 at 11:32:03PM +0100, Michael Biebl wrote: > Hi Sven, > > thanks for chiming in > > On 05.12.21 21:46, Sven Hoexter wrote: > > Regarding the patch proposed here, I would use an alternation for the > > recommends, exfatprogs | exfat-utils? > > If you (as maintainer of exfatprogs and exfat-utils) prefer that, I'm happy > to update the stable upload accordingly. > > Julien, would you be ok with that change? > That sounds good to me, thanks (as it should mean existing installs won't switch). Cheers, Julien
Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1
On Sat, Dec 04, 2021 at 12:28:27AM +0800, Shengjing Zhu wrote: > On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote: > > Control: tag -1 confirmed > > > > On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote: > > > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium > > > > This looks fine to me, go ahead. > > Thanks for the review. I'm not sure if it's too late to amend this > update. > Might be best to go with the original one first, and file a new bug for the new changes, because I don't know when I can get to reviewing more. Cheers, Julien
Bug#994064: bullseye-pu: package python-eventlet/0.26.1-7
Control: tag -1 confirmed Hi Thomas, A couple of comments on the diff below, otherwise fine to go ahead. On Fri, Sep 10, 2021 at 09:50:25PM +0200, Thomas Goirand wrote: > diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py > python-eventlet-0.26.1/debian/greendns.orig.py > --- python-eventlet-0.26.1/debian/greendns.orig.py2021-05-11 > 08:03:43.0 +0200 > +++ python-eventlet-0.26.1/debian/greendns.orig.py2021-09-10 > 21:42:12.0 +0200 That looks odd, this file probably shouldn't be there? [...] > diff -Nru python-eventlet-0.26.1/debian/greendns.py > python-eventlet-0.26.1/debian/greendns.py > --- python-eventlet-0.26.1/debian/greendns.py 2021-05-11 08:03:43.0 > +0200 > +++ python-eventlet-0.26.1/debian/greendns.py 2021-09-10 21:42:12.0 > +0200 [...] > def tcp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53, > @@ -794,7 +834,19 @@ > @type source: string > @param source_port: The port from which to send the message. > The default is 0. > -@type source_port: int""" > +@type source_port: int > +@type ignore_unexpected: bool > +@param one_rr_per_rrset: If True, put each RR into its own > +RRset. > +@type one_rr_per_rrset: bool > +@param ignore_trailing: If True, ignore trailing > +junk at end of the received message. > +@type ignore_trailing: bool > +@param sock: the socket to use for the > +query. If None, the default, a socket is created. Note that > +if a socket is provided, it must be a nonblocking datagram socket, > +and the source and source_port are ignored. > +@type sock: socket.socket | None""" > > wire = q.to_wire() > if af is None: The doc for sock here looks like a copy/paste error from the udp case, and should be a TCP socket instead. Looks like https://github.com/eventlet/eventlet/blob/master/eventlet/support/greendns.py#L861 still has it wrong. > @@ -810,7 +862,10 @@ > destination = (where, port, 0, 0) > if source is not None: > source = (source, source_port, 0, 0) > -s = socket.socket(af, socket.SOCK_STREAM) > +if sock: > +s = sock > +else: > +s = socket.socket(af, socket.SOCK_STREAM) > s.settimeout(timeout) > try: > expiration = compute_expiration(dns.query, timeout) Cheers, Julien
Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)
On Tue, Sep 07, 2021 at 12:27:05AM +0530, Nilesh Patra wrote:
> diff -Nru segemehl-0.3.4/debian/patches/arm64.patch
> segemehl-0.3.4/debian/patches/arm64.patch
> --- segemehl-0.3.4/debian/patches/arm64.patch 1970-01-01 05:30:00.0
> +0530
> +++ segemehl-0.3.4/debian/patches/arm64.patch 2021-09-06 23:43:50.0
> +0530
> @@ -0,0 +1,75 @@
> +Description: Change the signed-ness for several chars to fix segfault
> +Author: Nilesh Patra
> +Last-Update: 2021-08-24
> +--- a/libs/biofiles.c
> b/libs/biofiles.c
> +@@ -1916,7 +1916,7 @@
> + Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned
> char *maxq)
> + {
> +
> +- char ch;
> ++ signed char ch;
> + char idchar=0;
> + int ret=0;
> + off_t curseqoffset, lastindexoffset=0;
Shouldn't `ch` be an `int` instead, to match the return value of getc,
and type of EOF?
Anyway, I guess this is fine if it works...
Cheers,
Julien
Bug#993796: bullseye-pu: package knot-resolver/5.3.1-1
Control: tag -1 confirmed On Mon, Sep 06, 2021 at 04:21:15PM +, Jakub Ružička wrote: > [ Reason ] > Fixing bug #991463 (CVE-2021-40083) - potential DoS. > > [ Impact ] > Vulnerability to DoS attack. > > [ Tests ] > I've tested the fix manually by running the deckard (DNS test harness) > test sets/resolver/val_iter_high.rpl supplied with the upstream fix. > > It's not trivial to setup system for deckard so I've used upstream > Debian bullseye docker image from Knot CI: > > docker run -it --privileged > registry.nic.cz/knot/knot-resolver/ci/debian-11:knot-3.0 > > With current knot-resolver-5.3.1-1 the test failed. > With suggested knot-resolver-5.3.1-1+deb11u1 the test passed. > > [ Risks ] > This is a simple backport of upstream fix. > > Upstream tests run during package build so chances of something > breaking are small. > > [ Checklist ] > [*] *all* changes are documented in the d/changelog > [*] I reviewed all changes and I approve them > [*] attach debdiff against the package in (old)stable > [*] the issue is verified as fixed in unstable > Feel free to go ahead and upload, thank you. Cheers, Julien
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
Control: tag -1 confirmed On Wed, Dec 01, 2021 at 07:38:23PM +0100, Christoph Biedl wrote: > Christoph Biedl wrote... > > > About next steps, I would do the upload in the next days. Let me know if > > you prefer other things to happen first or instead. > > To avoid this gets lost I've just uploaded http-parser 2.8.1-1+deb10u2. > Updated debiff attached, only editorial changes since the previous mail. > Thanks. My only question is has anyone double checked none of the reverse deps access content_length (the patch comment suggests you have, but...)? Cheers, Julien
Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1
Control: tag -1 confirmed On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote: > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium This looks fine to me, go ahead. Cheers, Julien
Bug#993315: bullseye-pu: package im-config/0.46-1+deb11u1
Control: tag -1 confirmed On Tue, Aug 31, 2021 at 12:12:58AM +0800, Shengjing Zhu wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: z...@debian.org > > [ Reason ] > Two fixes related to Fcitx5, the Chinese/Japanese/Korean input method. > + 990742 > Fcitx5 should be preferred to Fcitx4. When upgrading from buster, which > installs Fcitx4 by default, the old version may still around. So when > both versions installed, the new one should be used. > > + 977203 > The input method related env for Fcitx5 should be "fcitx", not "fcitx5". > Some property software may not recognize the "fcitx5" env, and results > poor experience since they may fallback to legacy "xim" mode. > This looks fine, go ahead. Thanks, Julien
Bug#993100: bullseye-pu: package udisks2/2.9.2-2+deb11u1
Control: tag -1 moreinfo Hi Michael, On Fri, Aug 27, 2021 at 01:58:19PM +0200, Michael Biebl wrote: > I'd like to make a stable upload for udisks2, fixing #992152: > "udisks2: please update Recommends on exfat-utils to exfatprogs for Linux > kernel 5" > > This issue has already been fixed in unstable/testing and the relevant > changes for bullseye are an upstream cherry-pick and a packaging > cherry-pick. > How compatible are exfat-utils/exfatprogs? E.g. could this cause unexpected results (outside of udisks) for a user system that switched to exfatprogs as a result of this? Thanks, Julien
Bug#992518: bullseye-pu: package edk2/2020.11-2
Control: tag -1 confirmed On Thu, Aug 19, 2021 at 11:09:16AM -0600, dann frazier wrote: > [ Reason ] > Fixes a security issue, CVE-2019-11098. > > [ Risks ] > The most likely issue is that we introduce a regression that causes > some VMs to fail to boot. > Assuming no such issues have been reported in sid/testing or upstream from that change so far, that seems fine to me. Cheers, Julien
Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)
Control: tag -1 moreinfo
Hi Thomas,
On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote:
> Also, I would like to get Nova upgraded to the latest point
> release, to fix numerous small issues. The release notes for
> Nova are there:
>
> https://docs.openstack.org/releasenotes/nova/victoria.html
>
That looks incomplete? Please include a complete description of the
changes you want approved.
[...]
> [ Risks ]
> No risk during upgrade that I know of.
>
That is.. not reassuring.
> [ Checklist ]
> [x] *all* changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [ ] attach debdiff against the package in (old)stable
> [x] the issue is verified as fixed in unstable
>
> The debdiff being too big, please find it, together with the
> built packages, at:
> http://shade.infomaniak.ch/bullseye-pu/nova/
>
> [ Changes ]
> Here's the details of the debian/changelog explained.
>
>* Tune nova-api-{,metadata-}uwsgi.ini for performance.
>
> This is a minor tweak to the uwsgi.ini default configuration,
> which I've started pushing on all OpenStack packages in Debian.
> It's only better with it...
>
I don't think this is appropriate for stable. There's no information on
what environment(s) this is tuned for, or benchmarked in.
>* New upstream release.
>
> See above.
>
I'll reserve my opinion on that until we have a better description of
the changes. It seems plausible, broadly.
>* CVE-2021-3654: novnc allows open redirection. Added upstream patch:
> Reject_open_redirection_in_the_console_proxy.patch (Closes: #991441).
>
> This addresses the main issue that mandates the pu.
>
>* Do not maintain glance_api_servers through debconf (as the default of
> reading its URL in the Keystone catalogue is better).
>
> This avoids tweaking nova.conf on upgrades, which could otherwise
> potentially destroy one's deployment. Indeed, one very valid (and in
> fact recommended) way to deploy, is to *NOT* set the glance_api_servers
> directive. With the debconf code, this forces having something. After
> removing the debconf integration for this directive, upgrade to the
> proposed update isn't breaking deployments anymore, while leaving already
> configured glance_api_servers alone (so not destroying anyone setup).
>
Shouldn't nova/glance_api_servers be cleaned up from the debconf
database if it's no longer used? I'm also not convinced this is
appropriate for stable.
Cheers,
Julien
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
cc: rustc and firefox maintainers On Tue, Nov 23, 2021 at 03:20:45PM -0500, Roberto C. Sanchez wrote: > In preparing the rustc 1.51 upload/backport (to support backports of the > latest firefox-esr and thunderbird packages) it has been suggested that > to avoid some issues associated with providing a significant new version > of rustc in the rustc binary package (along with the associated library > packages), that I prepare the 1.51 rustc package with a different name. > Following the model of what was done for gcc, nasm, and nodejs, I was > considering source package rustc-mozilla with a single binary package > (also rustc-mozilla) to ensure that rdeps don't end up getting surprised > by a new rustc. Would this be considered acceptable for the bullseye > and buster uploads of rustc 1.51? 2 things: - I think we should pick 1.53 if possible, since that's what mozilla use for their esr91 binaries - I don't think we need to rename the packages unless there's evidence of breakage that can't be easily fixed by either simple patches or removing the affected packages. Renamed packages are acceptable but that seems like extra work and overhead that may not be necessary. Cheers, Julien
Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
On Mon, Nov 01, 2021 at 12:01:51AM +0100, Christoph Biedl wrote: > Adam D. Barratt wrote... > > > Do you already have a proposed new upload / debdiff? > > After many more tests and some more discussion with Hilko, find attached > a debdiff that in my opinion is ready for upload. The patch itself is > unmodified, I just enhanced the description for posterity. > > About next steps, I would do the upload in the next days. Let me know if > you prefer other things to happen first or instead. > Hi Christoph, Would you mind providing the old/new/proposed versions of http_parser.h? (this is me being lazy, sorry, if I'm being too much of a pain I can go and figure them out for myself, just let me know). Thanks, Julien
Re: Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:28:05PM +0200, Julian Andres Klode wrote: > On Mon, Apr 19, 2021 at 06:08:23PM +0200, Julien Cristau wrote: > > On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > > > I see. Nobody pinged me since then, but it is indeed fixed in the > > > 1.8.5 stable update that at least one release team member was > > > not exited about. > > > > > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > > > > > So it's up to the release team if they want 1.8.5 or whether we'll have > > > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > > > is clear - I don't want to maintain a 1.8.2.z branch, it's more work > > > compared > > > to just following the normal stable apt updates, and there's a lot less > > > testing going on. > > > > > Please upload just that fix to buster; I don't care too much about the > > version number you pick. > > Is there a buster point release before bullseye release, or should that > be in buster-updates? > I don't know. It needs to make its way to spu soon either way. > Given that buster is going to security support only soon anyway, I don't > mind where I apply security updates to that much :D > > > But I really do want to cherry-pick at least two other code fixes, and one > test > suite fix: > Can we defer these until after the AllowReleaseInfoChange change is out, please? Thanks, Julien > * > https://salsa.debian.org/apt-team/apt/-/commit/cfee71c6f2d1478ce4d4ed74ef690ae1350ea403 > > https://salsa.debian.org/apt-team/apt/-/commit/75f452c7309d66548c86a6526cbd65fc51a70039 > > (really just one change, but it was split over two releases, first > turned error to warning, next one ignores it completely; because it > was in 2 releases in main so I kept it separate :D) > > too, they'll make immediate configuration errors non-fatal. Currently > they are fatal in the sense that they are ignored and the upgrade runs > and then it just exits with 1 at the end. So it does not change the > outcome, it just makes the error reporting less silly. > > It is very likely that some upgrades on multi-arch systems fail erronously > without them. To be fair, the multi-arch aspect is also fixed by > > https://salsa.debian.org/apt-team/apt/-/commit/7f65fa3843abc476cbba65c808abc5dd77835815 > but that changes ordering results, and is not strictly necessary. > > * And I want > > https://salsa.debian.org/apt-team/apt/-/commit/cfc6870e9b8ad119219ce5dc1871531006bb2d71 > > to avoid people getting packages removed that stuff still depends on > because their prerm script failed. This might happen during an upgrade > to bullseye, and it's very very likely APT will not be able to recover from > it > - I've never successfully recovered a distribution upgrade that had a > failure in the > middle (and fwiw, all of them had, but they were my faults, really). > > * Also the testsuite-only change in > > https://salsa.debian.org/apt-team/apt/-/commit/730c5c861c32c9385dc862af8673984b12902343 > which makes things work reliably on debci armhf (no regression > potential, wheee) > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en >
Re: Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > I see. Nobody pinged me since then, but it is indeed fixed in the > 1.8.5 stable update that at least one release team member was > not exited about. > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > So it's up to the release team if they want 1.8.5 or whether we'll have > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > is clear - I don't want to maintain a 1.8.2.z branch, it's more work compared > to just following the normal stable apt updates, and there's a lot less > testing going on. > Please upload just that fix to buster; I don't care too much about the version number you pick. Thanks, Julien
Bug#986069: RM: protobuf2/2.6.1-4
Control: clone -1 -2 Control: reassign -2 protobuf2 2.6.1-4 Control: severity -2 serious Control: retitle -2 protobuf2: unsuitable for release Control: close -1 On Mon, Mar 29, 2021 at 10:48:28AM +0200, Emmanuel Bourg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Hi, > > Please remove protobuf2 from testing, that's an old version of protobuf > required to bootstrap Kotlin but this is still a work in progress, the > dependency shouldn't ship with Bullseye. > Done. Cheers, Julien
Re: 10.9 planning
On Fri, Mar 19, 2021 at 04:14:31PM +, Steve McIntyre wrote: > In fact, how about: we *could* go ahead with the 10.9 point release as > already planned, and expect to do a 10.10 a couple of weeks later with > basically *just* the shim/SB changes? I'm OK to go with that option if > that's our preferred route as a group. > Is there actually a rush to get 10.10 out? Are people eager to push out revocations? Or can we do it on our normal cadence, some time in May or thereabouts, without adverse consequences? Thanks, Julien
Bug#983526: buster-pu: package python-django/1:1.11.29-1+deb10u1
Control: tag -1 moreinfo On Thu, Feb 25, 2021 at 04:42:55PM +, Chris Lamb wrote: > Please consider python-django (1:1.11.29-1+deb10u1) for buster: > > python-django (1:1.11.29-1+deb10u1) buster; urgency=high > . > * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter > cloaking". Django contains a copy of urllib.parse.parse_qsl() which was > added to backport some security fixes. A further security fix has been > issued recently such that parse_qsl() no longer allows using ";" as a > query parameter separator by default. (Closes: #983090) > . > For more information, please see: > . > https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ > Hi Chris, I'm not convinced the regression risk here, of changing the longstanding behaviour, is worth it. People using a caching reverse proxy with a different config wrt query strings can just as well fix the issue on that end. Cheers, Julien
Re: Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote: > I've Cc'ed debian-release@ as it is already past soft freeze, but I > think just renaming the source packages would be unlikely to break > anything. > That makes sense to me, and seems worth it to make the security team and ftpmaster's life easier during bullseye. Cheers, Julien
Re: Don't ship gnupg1 with bullseye
On Tue, Feb 02, 2021 at 09:45:42AM +0100, Christoph Biedl wrote: > Dominic Hargreaves wrote... > > > Do the gnupg1 maintainers agree that it should be removed from bullseye? > > IMnsHO it's a bad idea to remove gnupg1 any time soon. While it > certainly should not be used for encryption, it's still needed when > dealing with older keys. Quoting the package description: "It is > provided mainly for people with the need to use archaic cryptographic > objects like PGPv3 keys to access archived messages." > > So unless it's really broken or likewise RC, it should be kept. > Agreed. It's great that no package uses it anymore, but that doesn't mean some users won't need it to deal with legacy bits. Cheers, Julien
Bug#971989: unblock: thunderbird/1:78.3.2-1
On Tue, Oct 20, 2020 at 05:54:19PM +0200, Michael Biebl wrote: > So I decided to do that, and NMU enigmail. > I used Gregors patches from [1] (thanks for that!) with some minor changes > - Updated to 2.2.4 (instead of 2.2.2) > - Marked the upload as NMU (versioned as 2:2.2.4-0.1) and removed Gregor > from Uploaders again. It seemed a bit controversial to add oneself to > Uploaders as part of an NMU > - Removed Files-Excluded from debian/copyright as the offending files > are no longer part of the dist tarball, so a repack is not necessary anymore > > I gave the package some light testing and the migration wizard did > properly show up and import my private and public keys (it skipped one > public key, haven't investigated yet, why) and the account settings. > > I've pushed my work to https://salsa.debian.org/biebl/enigmail and > uploaded to DELAYED/14. > In the interest of getting thunderbird updated in bullseye, I've just gone ahead and rescheduled the NMU from 5-day to 0-day. Cheers, Julien
Bug#971989: unblock: thunderbird/1:78.3.2-1
Hi Carsten, can you explain the jsunit situation a bit more? As far as I can tell the issue is: (thunderbird:2216): Gtk-WARNING **: 09:59:23.024: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg. showing up on stderr during the test, e.g. in https://ci.debian.net/data/autopkgtest/unstable/amd64/j/jsunit/6983431/log.gz Is a bug tracking this issue? Cheers, Julien On Sun, Oct 11, 2020 at 10:21:01AM +0200, Carsten Schoenert wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package thunderbird > > The automatic migration testing for Thunderbird is containing some tests > for the packages jsunit and enigmail which currently prevents the > automatic migration of the thunderbird package to testing because the > tests are failing. > > The enigmail package needs to be available in at least version 2.2 to > give a useful user experience. Thunderbird has included a version > requirement on enigmail that 2.2 is required. > This requirement can't get fulfilled currently in Debian unstable or > testing because the maintainers of the Enigmail package didn't prepared > and upoaded until now a new version. > There is s wishlist bug for updating enigmail to the most recent > version since a few weeks. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970111 > > The jsunit package is now also outdated and must fail against the > current Thunderbird versions. > > So far I've no feedback from the enigmail maintainers, they got involved > within the communication with the security team while the upload of > thunderbird for stable/security got prepared. > > The currently also reported uninstallability for the package > webext-exteditor/2.0.4-1 is intended as this version isn't working with > Thunderbird >= 78. > > So I'd like to suggest to remove (if this is possible) the auto > migration testing of enigmail and jsunit against thunderbird. At least > please allow the migration of the Thunderbird related packages into > testing. I'm condidering removal requests for enigmail and jsunit in > testing. > > Regards > Carsten > > unblock thunderbird/1:78.3.2-1 > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, aarch64, arm64 > > Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#970424: llvm-toolchain-7 7.0.1-8+deb10u1 flagged for acceptance
package release.debian.org tags 970424 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: llvm-toolchain-7 Version: 7.0.1-8+deb10u1 Explanation: fix bugs affecting rustc build
Bug#959723: RM: matrix-synapse/0.99.2-6 -- ROM; security issues; obsolete version
On Mon, May 4, 2020 at 18:30:23 +0200, Andrej Shadura wrote: > On Mon, May 04, 2020 at 03:35:25PM +0200, Julien Cristau wrote: > > On Mon, May 04, 2020 at 03:30:53PM +0200, Andrej Shadura wrote: > > > Synapse 0.99 was never meant to be a properly usable release in buster, > > > and it was only included as some sort of a plug to make upgrades a tiny > > > bit easier for users — they were supposed to upgrade the package to the > > > version from backports almost immediately. > > > > > > However, the time when this version was usable has definitely passed. It > > > has a bunch of security issues fixed in the newer releases, and the > > > effort of porting them back is significant, while most probably everyone > > > running synapse on buster is on the version from backports or the > > > version from the upstream. > > > > > > Please remove matrix-synapse from buster only. > > > That is terrible practice. Shipping something in stable is a commitment > > to support it throughout the release's lifetime. Removing it from > > stable doesn't remove it from user systems, doesn't communicate to them > > that it is not fit for purpose, or anything like that. Please > > reconsider your strategy here. > > I think in this case it’s okay because of this NEWS entry: > > https://sources.debian.org/src/matrix-synapse/0.99.2-6/debian/NEWS/ > I'm not sure how that makes it any better? NEWS is shown on upgrade at best, so anyone installing this on buster won't see it. Cheers, Julien
Bug#959723: RM: matrix-synapse/0.99.2-6 -- ROM; security issues; obsolete version
On Mon, May 04, 2020 at 03:30:53PM +0200, Andrej Shadura wrote: > Synapse 0.99 was never meant to be a properly usable release in buster, > and it was only included as some sort of a plug to make upgrades a tiny > bit easier for users — they were supposed to upgrade the package to the > version from backports almost immediately. > > However, the time when this version was usable has definitely passed. It > has a bunch of security issues fixed in the newer releases, and the > effort of porting them back is significant, while most probably everyone > running synapse on buster is on the version from backports or the > version from the upstream. > > Please remove matrix-synapse from buster only. > That is terrible practice. Shipping something in stable is a commitment to support it throughout the release's lifetime. Removing it from stable doesn't remove it from user systems, doesn't communicate to them that it is not fit for purpose, or anything like that. Please reconsider your strategy here. Cheers, Julien
Bug#953745: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u5
Control: tag -1 moreinfo
On Mon, Apr 13, 2020 at 05:40:43PM +0200, Hilmar Preuße wrote:
> Am 12.04.2020 um 23:45 teilte Adam D. Barratt mit:
>
> Hi Adam,
>
> > I'm afraid that I'm slightly confused on this point:
> >
> > adsb@coccia:~$ grep debconf
> > proftpd-dfsg-1.3.6c/debian/proftpd-basic.postinst
> > ucf --debconf-ok ${file}.proftpd-new $file
> > . /usr/share/debconf/confmodule
> >
> > That looks like the debconf modules are still be pulled in in unstable.
> >
> Seems, we did not remove all references to debconf back in 2017 and we
> still read the confmodule file. However we don't use that code any more
> since 2017:
>
> commit c02d6aa7e53180030150bcb7bafecb5bc65ce245
> Author: Francesco Paolo Lovergine
> Date: Fri Jan 27 17:28:24 2017 +0100
>
> Fixed residual debconf support.
>
> commit 81a40ed6042d63ea8593c1d04bcc2dcadd821592
> Author: Francesco Paolo Lovergine
> Date: Fri Jan 27 14:49:49 2017 +0100
>
> Updated NEWS file about new version without debconf support.
>
> commit b0acf6578dec55470659c80967b20d645c88c25b
> Author: Francesco Paolo Lovergine
> Date: Fri Jan 27 14:43:47 2017 +0100
>
> Removed debconf support and maintainer support for non-standalone mode.
>
> Therefore we don't change anything in the functionality if we stop
> reading /usr/share/debconf/confmodule .
>
This is still present in sid, so re-adding the moreinfo tag.
Cheers,
Julien
Bug#958850: stretch-pu: package gosa/2.7.4+reloaded2-13+deb9u3
Control: tag -1 moreinfo Hi Mike, On Sat, Apr 25, 2020 at 09:57:01PM +0200, Mike Gabriel wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > > Dear release team, > > this is a follow-up for #927433 (about +deb9u2). > > + * debian/patches/1047_CVE-2019-14466-1_replace_unserialize_with_json_ > +encode+json_decode.patch: > ++ Replace (un)serialize with json_encode/json_decode to mitigate PHP > object > + injection (CVE-2019-14466). > > Since I last uploaded the stretch-pu of gosa, one more CVE issue got > known and already addressed in the Git branch. > > I will follow-up with a +deb9u3 upload on the +deb9u2 upload. Luckily, > this one is not as massive as the +deb9u2 one. > Which package versions fix this for buster and sid? Cheers, Julien
Bug#898006: stretch-pu: package pcl/1.8.0+dfsg1-3
Control: tag -1 confirmed On Sat, May 05, 2018 at 06:38:25PM +0200, Jochen Sprickerhof wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > > Dear release team, > > in #894656 I was asked to add libvtk6-qt-dev as a dependency to > libpcl-dev in stretch. I would like to do this, except for armel and > armhf which fails due to OpenGLES, cf. #835292. > > The resulting debdiff is attached. > Please go ahead. Cheers, Julien
Bug#893439: stretch-pu: package gnucash/1:2.6.15-1+deb9u1
Control: reassign -1 pu: libdbi/0.9.0-4+deb9u2 Control: tag -1 confirmed On Fri, Nov 09, 2018 at 07:29:32AM +0100, László Böszörményi wrote: > On Sat, Oct 6, 2018 at 7:07 PM Adam D. Barratt > wrote: > > > > László: ping? > > > > On Mon, 2018-04-02 at 15:20 +0200, Julien Cristau wrote: > > > On Mon, Apr 2, 2018 at 14:51:54 +0300, Adrian Bunk wrote: > > > > On Mon, Apr 02, 2018 at 01:05:39PM +0200, Julien Cristau wrote: > > > > > On Sun, Mar 18, 2018 at 22:07:25 +0200, Adrian Bunk wrote: > > [...] > > > > > libdbi 0.9.0-4+deb9u1 broke gnucash tests, runtime issues > > > > > > with this backend were so far not reported but are not > > > > > > unlikely. > > [...] > > > So the other option here would be to revert the libdbi change. As > > > far as I can tell from #880896 it wasn't prompted by a specific > > > problem, so a revert there might be the safest course of action and > > > sidesteps the gnucash issue. László, any thoughts? > Indeed, that change is better reverted. I've proposed a patch on > #884119 [1]. Can I upload it to Stretch or should file a separate PU > proposal? > Please go ahead and upload to stretch. Repurposing this bug for the libdbi update. Cheers, Julien
Bug#893006: stretch-pu: package boost1.62/1.62.0+dfsg-4+deb9u1
Control: tag -1 moreinfo On Wed, Apr 04, 2018 at 10:25:30PM +0200, Philipp Huebner wrote: > Hi, > > Am 02.04.2018 um 12:57 schrieb Julien Cristau: > > On Thu, Mar 15, 2018 at 14:51:10 +0100, Philipp Huebner wrote: > >> I would like to fix #883987 in boost1.62 for Stretch. > >> The changes are basically the same as what is currently in testing and I > >> got the > >> maintainer's go-ahead in > >> http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2018-March/004184.html > >> > > What made these partial specializations not be necessary anymore? That > > seems like critical missing information if we are to make a decision > > here, to know if/what we might be breaking instead. > > my guess is that only upstream can really answer that. > > My work colleague confirmed that we're basically using the same code as > in the example at the upstream bug tracker and it fails when using gcc-6 > on Stretch: > https://svn.boost.org/trac10/ticket/12534 > > > Best wishes, > -- > .''`. Philipp Huebner > : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F > `. `'` > `- >
Bug#892932: stretch-pu: package websockify/0.8.0+dfsg1-7+deb9u1
Control: tag -1 confirmed
On Wed, Mar 14, 2018 at 06:48:51PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
>
> * Add runtime depends on python{3,}-pkg-resources (Closes: #879224).
Please go ahead.
Cheers,
Julien
Bug#891657: stretch-pu: package swt-gtk/3.8.2-3+deb9u1
Control: tag -1 confirmed On Tue, Feb 27, 2018 at 08:47:39PM +0200, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > >* libswt-webkit-gtk-3-jni: Add the missing dependency > on libwebkitgtk-1.0-0. (Closes: #879170) Go ahead. Cheers, Julien
Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6
Control: tag -1 confirmed On Sun, Mar 04, 2018 at 11:08:00AM +0100, Carsten Leonhardt wrote: > Control: tags -1 - moreinfo > > "Adam D. Barratt" writes: > > > - --oknodo --exec $DAEMON --chuid $BUSER:$BGROUP -- -c $CONFIG > > + --oknodo --exec $DAEMON -- -g $BUSER -g $BGROUP -c $CONFIG > > > > The first of those "-g" is presumably supposed to be "-u". I realise > > this may seem a small point, but it does make me wonder how it wasn't > > caught in testing. > > Thank you for your work and for catching this. A new version of the > patch is attached. > Sorry for the delay, please go ahead. Cheers, Julien
Bug#944099: CVE-2019-14433 / OSSA-2019-003: buster-pu: package nova/2:18.1.0-6 -> 18.1.0-6+deb10u1
On Sun, Nov 24, 2019 at 10:06:51AM +0100, Thomas Goirand wrote: > On 11/23/19 6:09 PM, Julien Cristau wrote: > > Control: tag -1 moreinfo > > > > On Mon, Nov 04, 2019 at 11:53:52AM +0100, Thomas Goirand wrote: > >> We would like to update Nova in Buster for 2 reasons. First, there's > >> OSSA-2019-003 / CVE-2019-14433 which we would like to fix. Second, > >> in non-interactive mode, upgrading Nova can lead to some configuration > >> changes, which is an RC bug. > >> > > This doesn't sound like it should require new debconf templates. What's > > the logic there? Why does upgrading touch the configuration at all? > > > > Cheers, > > Julien > > Same as for Heat for which I just replied. > > In the postinst, after consuming the password prompt in the .config > script, the password is forgotten using db_unregister. The only way to > avoid this is to have this other screen prompting for not handling this > through debconf, which is always the default. > This still doesn't make sense to me. Cheers, Julien
Bug#953155: buster-pu: package bind9/1:9.11.5.P4+dfsg+1-1
Control: tag -1 moreinfo On Thu, Mar 05, 2020 at 11:40:44AM +0100, Ondřej Surý wrote: > Hi, > > recently, there was a bug #952946 filled against BIND 9 (and other packages) > about license problem with OASIS PKCS#11 (pkcs11.h) that has incompatible > license. Upstream has already fixed that in the next upstream release to be > due > in March and the question here is whether we want to do the dfsg to dfsg+1 > bump > just because of the pkcs11.h header in both buster and stretch. > Can you provide more details as to exactly what the license problem is and what the change would look like? Cheers, Julien
Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1
On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote: > I failed to update wireless-regdb for some time, as it needed some > significant work to prepare for the regulatory database being directly > loaded by the kernel (instead of by crda). This was introduced in > Linux 4.15, but is currently disabled in all Debian suites. It will > be enabled starting with 5.5. > > The version now in unstable has: > > 1. regulatory.bin: loadable by crda, trusted by Debian crda > 2. regulatory.db-debian, regulatory.db.p7s-debian: >loadable by kernel, trusted by future Debian kernels > 3. regulatory.db-upstream, regulatory.db.p7s-upstream: >loadable by kernel, trusted by upstream and future Debian kernels > 4. regulatory.db, regulatory.db.p7s: alternative links for either >(2) or (3) > > So this should be backward-compatible with all supported Debian > releases, with one exception: > > On a system that has a recent kernel and (3) from elsewhere, *and* > also a currently unused wireless-regdb package, upgrading > wireless-regdb will effectively replace (3) with (2), which is not > trusted by their kernel. They will need to run update-alternatives to > fix this (this is documented in README.Debian). > Is this something that can be detected from e.g. maintainer scripts, to show some kind of hint to the affected user? > The update for (1) definitely should be delivered to all suites, but > I'm undecided whether the other files should be included. Please > advise what I should do. > I guess our options for stable are: a. ship 1/2/3/4 in a point release b. ship an update for 1 in a point release, ship 1/2/3/4 in backports For option b, can we reasonably have the backports kernel Break old wireless-regdb, to nudge apt into updating that to the backport too? Or is that more likely to get wireless-regdb removed than anything else? Cheers, Julien
Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1
On Sun, Feb 16, 2020 at 04:27:11PM +, Ben Hutchings wrote: > This was discussed on IRC with Julien Cristau, but unfortunately I > didn't save a log. The main points that came up were: > > * Executables built for the O32 FP64 ABI require this kernel config > change and older kernel versions will refuse to load them. So the > kernel needs to be upgraded before installing any binaries built > for the new FP ABI. > > * Normally the support for an additional ABI would be included in > release N.0 and used in N+1. Since this was not present in 10.0, it > would be possible for users to start upgrading to bullseye while > still running a kernel that does not support O32 FP64. We need to > prevent them getting a broken system. > > * Julien proposed that libc6 would have a preinst check on the kernel > when it is changed to use the new FP ABI. Presumably all binaries > built for the new FP ABI should also have a versioned dependency on > at least this version of libc6. > > So I don't see any reason not to update the kernel configuration > already, as it will remain compatible with the O32 FPXX binaries in > buster. Only the user-space changes in unstable (libc6 and toolchain) > need to be carefully coordinated. > Here's the irc log for the record: < bwh> jcristau: While you are here, could you have a quick look at #949259? < jcristau> that's kind of awkward < jcristau> maybe it's ok because it's only mips, but... < bwh> but what? < jcristau> well i'd normally expect bullseye to run on buster r0 < jcristau> what's the failure mode if the kernel doesn't support O32_FP64? < bwh> syq_: Can you answer? < bwh> jcristau: It looks to me like exec will fail for programs built for the new FP ABI < jcristau> so they'll need to get a dependency on a new libc with a preinst check? < bwh> jcristau: That seems like a reasonable approach < bwh> that + prominent notice in the release notes < syq_> jcristau: it will complain that not support such binary < syq_> jcristau: if kernel doesn't enable FP64 I think you can go ahead provided that: - enabling this support in the kernel doesn't break previously-supported userspace - Aurélien as glibc maintainer is OK with this plan Thanks, Julien
Bug#948375: buster-pu: package ceph/12.2.12+dfsg-1
Control: tag -1 moreinfo Hi Bernd, On Tue, Jan 07, 2020 at 11:37:45PM +0100, Bernd Zeimetz wrote: > I have a bit complicated idea for a buster-pu: ceph. > Buster shipped with 12.2.11 and last April upstream released 12.2.12 as > bugfix release. As usual with ceph, the diff is *huge*, but it is a > bugfix-only release. So here are a few facts: > > - upstream changes: https://ceph.io/releases/v12-2-12-luminous-released/ > > - proposed diff: > > https://salsa.debian.org/ceph-team/ceph/compare/luminous%2Funstable...debian%2Fbuster > That's kind of unreadable. We like to have the proposed diff directly in the p-u bug, along with a description of the changes, what they fix, what the risks are. Pointers to more information elsewhere are not bad, but they don't replace information that should be in the bug. In this case the upstream changelog doesn't really provide much context on which if any of the fixed issues are serious enough for us to want the update in stable. > - I've basically imported the changes the Ubuntu people have done in > Ubuntu together with 12.2.12. So I assume this should work well, I did > not yet test it properly as I want to wait for a reply from you. I'll > prepare a backport of 14.2.x as soon as it migrates to testing anyway. > A reply from us tends to not be forthcoming before the proposed changes have been tested, so there's a bit of a chicken and egg issue. > - The issue with ceph is that upstream doesn't do QA for 32bit and our > selection of unusual architectures. I don't know if it builds on all > buildds without trying... > There should be porterboxes available for all our release architectures. Cheers, Julien
Bug#946779: buster-pu: package logrotate/3.14.0-4
Control: tag -1 moreinfo On Sun, Dec 15, 2019 at 08:12:19PM +0100, Christian Göttsche wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > With version 3.14.0 [1] logrotate split the configuration for btmp and > wtmp into separate configuration files. > There are bug reports regarding this issue: 945932, 928516, 922045. > > Package version 3.14.0-4+deb10u1 adds a NEWS entry about this change. > > The packaging can be found at [2]. > An upload can be found at [3]. > I would suggest documenting this in the buster release notes instead of updating the package just for the NEWS entry. Cheers, Julien
Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1
On Fri, Feb 07, 2020 at 05:21:21PM -0500, Antoine Beaupré wrote: > [sorry for the dupe, hit send by mistake :(] > > On 2019-11-24 12:13:20, Antoine Beaupré wrote: > > On 2019-11-23 18:34:25, Julien Cristau wrote: > >> I'm a bit uneasy about a blanket "include all", to be honest. It's > >> probably harmless since it's all coming straight out of debootstrap, but > >> I'd have been happier with something like "include security.*" if that's > >> what we expect to see. > > > > What kind of problems would you expect with including too many ACLs? > > I'm still curious to hear what kind of problems you expect here. I've > been running this patch in production for months now and would really > like to see this land in buster (and hopefully stretch next). > I don't know, that's kind of the point. For changes in stable I tend to err on the side of "if there's no demonstrated need for a change then it shouldn't be done". Things like "because why not" tend to be red flags. Cheers, Julien
Bug#883346: release.debian.org: improve reportbug templates for pu and unblock bugs
Control: reassign -1 reportbug Yay me. On Fri, Mar 13, 2020 at 07:36:28PM +0100, Julien Cristau wrote: > On Sat, Dec 02, 2017 at 07:14:01PM +0100, Julien Cristau wrote: > > Package: release.debian.org > > Severity: wishlist > > > > I brought this up in Cambridge, filing here so we can discuss specifics. > > > > At Mozilla we're using a template in bugzilla [1] for requests to > > cherry-pick changes from trunk to a release branch, to help release > > management assess reward/risk from specific changes, and I thought > > something like that might be useful in Debian too. > > > [...] > > > > Ubuntu may have something in their SRU bug process too? > > > > Eventually we could reassign this to reportbug if/when we come to an > > agreement. > > > Paul ran with this (thanks!) and provided a template for unblocks: > https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/31 > and pu: > https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/53 > > Reassigning to reportbug so it can be closed there. >
Bug#883346: release.debian.org: improve reportbug templates for pu and unblock bugs
On Sat, Dec 02, 2017 at 07:14:01PM +0100, Julien Cristau wrote: > Package: release.debian.org > Severity: wishlist > > I brought this up in Cambridge, filing here so we can discuss specifics. > > At Mozilla we're using a template in bugzilla [1] for requests to > cherry-pick changes from trunk to a release branch, to help release > management assess reward/risk from specific changes, and I thought > something like that might be useful in Debian too. > [...] > > Ubuntu may have something in their SRU bug process too? > > Eventually we could reassign this to reportbug if/when we come to an > agreement. > Paul ran with this (thanks!) and provided a template for unblocks: https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/31 and pu: https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/53 Reassigning to reportbug so it can be closed there. Cheers, Julien
Bug#951209: transition: libgusb
On Wed, Feb 12, 2020 at 03:24:42PM +0100, Laurent Bigonville wrote: > libgusb is carrying in debian a patch[0] to revert/fix an after the fact > change that was done upstream in the versioning of the symbols. > > I don't think we should/can carry this patch forever and due to the fact > that the number of reverse-dependencies is quite limited, I was planning > to simply drop it, but that would require to binNMU them to be > certain they are using the correct version of the symbol. > IMO we should keep compatibility with the old version until the next upstream SONAME bump. That might mean keeping this patch, or something different, if we can add properly versioned aliases for the affected symbols? Cheers, Julien
Bug#948552: nmu: schroedinger-coordgenlibs_1.3-1
Control: severity -1 serious Control: reassign -1 libschroedinger-maeparser1 1.2.2-1 Control: retitle -1 libschroedinger-maeparser1: SONAME change without package name change On Fri, Jan 10, 2020 at 08:41:47PM +1100, Stuart Prescott wrote: > Hi Julien, > > On Friday, 10 January 2020 19:44:37 AEDT Julien Cristau wrote: > > On Fri, Jan 10, 2020 at 03:57:01PM +1100, Stuart Prescott wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: binnmu > > > > > > nmu schroedinger-coordgenlibs_1.3-1 . ANY . unstable . -m "Rebuild against > > > libschroedinger-maeparser-dev >= 1.2.2-1" > > > > > > The binNMU of rdkit (#946247) did not fix #945985; it appears that it is > > > schroedinger-coordgenlibs that actually needs rebuilding to pick up the > > > new > > > filename of libmaeparser: > > > > > > $ ldd /usr/lib/x86_64-linux-gnu/libcoordgen.so.1.3 > > > > > > linux-vdso.so.1 (0x7fff9f9bd000) > > > libmaeparser.so.1.2 => not found > > > libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 > > > (0x7f5445999000) > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5445854000) > > > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > > > (0x7f544583a000) > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f544567a000) > > > /lib64/ld-linux-x86-64.so.2 (0x7f5445c12000) > > > > > > (rebuilding the package has the linking pick up libmaeparser.so.1 instead) > > > > That sounds wrong. If libmaeparser.so.1.2 was renamed to > > libmaeparser.so.1 then its package name should have changed? > > Yes, I'd say so. I'm guessing that libschroedinger-maeparser1 was the wrong > name to begin with or more likely that the "1.2" suffix was incorrect and > then > fixed; they are right(ish) now for that soname; I assume this was an > accidental > transition. > > Since there is only source package with a dependency on libschroedinger- > maeparser1 (this one), a binNMU seems like the simplest solution; it fixes > the > current packages and then lets me get on to the RC bugs I was actually trying > to fix... > Yeah, no, let's fix this properly in schroedinger-maeparser. Cheers, Julien
Bug#948552: nmu: schroedinger-coordgenlibs_1.3-1
On Fri, Jan 10, 2020 at 03:57:01PM +1100, Stuart Prescott wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu schroedinger-coordgenlibs_1.3-1 . ANY . unstable . -m "Rebuild against > libschroedinger-maeparser-dev >= 1.2.2-1" > > The binNMU of rdkit (#946247) did not fix #945985; it appears that it is > schroedinger-coordgenlibs that actually needs rebuilding to pick up the new > filename of libmaeparser: > > $ ldd /usr/lib/x86_64-linux-gnu/libcoordgen.so.1.3 > linux-vdso.so.1 (0x7fff9f9bd000) > libmaeparser.so.1.2 => not found > libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f5445999000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5445854000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f544583a000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f544567a000) > /lib64/ld-linux-x86-64.so.2 (0x7f5445c12000) > > (rebuilding the package has the linking pick up libmaeparser.so.1 instead) > That sounds wrong. If libmaeparser.so.1.2 was renamed to libmaeparser.so.1 then its package name should have changed? Cheers, Julien
Re: Planning 10.3 and 9.12
On Mon, Jan 06, 2020 at 09:42:29PM +, Adam D. Barratt wrote: > Hi, > > It's (really past) time to consider a date for the next point releases > for buster and stretch. > > I've listed some suggested dates below; please indicate which you would > be available for. > > - January 25th > - February 1st > - February 8th > - February 15th > The first 3 should work for me. Feb 15 I'm not sure yet. Cheers, Julien
Re: rust ecosystem worries of a release team member
On Thu, Jan 09, 2020 at 01:38:53PM +, Ximin Luo wrote: > Paul Gevers: > > Hi all, > > > > On 05-01-2020 14:39, Ximin Luo wrote: > >> Paul Gevers: > >>> [..] > >>> > >>> [1] Now thunderbird is blocked by rust-cbindgen (last version migrated > >>> in September with uploads since October), which is blocked by rust-syn > >>> (last version migrated in July, with new uploads since August). Involved > >>> is rust-proc-macro2 (last version migrated in July, with new uploads > >>> since August (and currently triggers an autopkgtest regression)), > >>> rust-unicode-xid (which has been trying to migrate to testing since > >>> August), rust-quote (trying to migrate since August). And I may be > >>> missing others. rustc was involved at some moment, cargo was involved > >>> (and FTBFS for some time) etc... > > > > And today another firefox-esr, with CVE fixes, appeared, which is also > > blocked by this. > > > > I just had a look, and both firefox-esr and thunderbird still are vendoring > their own rust source code in third_part/rust/* and make no attempt to > integrate with dh-cargo or our cargo-debian-wrapper in d/rules in the way > that I prescribe here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907629#30 > > So their current build-dependencies on any librust-* packages are bogus, and > can simply be dropped to progress with migration. > > Likewise, rustc and cargo are purposefully designed to vendor their own > crates, and *not* depend on any librust-* packages, and so they shouldn't > affect migration either. > firefox-esr doesn't build-depend on any librust-* package. It build-depends on rustc, cargo, and cbindgen. But cbindgen is not in testing, and *it* build-depends on a bunch of librust-*-dev packages, which block its migration to testing. Cheers, Julien
Re: rust ecosystem worries of a release team member
On Sat, Jan 04, 2020 at 05:02:56PM +0100, Paul Gevers wrote: > As thunderbird should really migrate some time soon, are you aware of > the missing pieces for that to happen and share that with us? If > possible, can you please avoid uploading updates that can wait a bit and > that interfere with the required stack? > I think this is a case where it's OK to ignore missing build-dependencies in testing, and push thunderbird anyway. I'll be doing that for firefox-esr, in any case. Cheers, Julien
Bug#944865: buster-pu: package limnoria/2019.02.23-1+deb10u1
Control: tag -1 moreinfo On Sat, Nov 16, 2019 at 05:36:13PM +0100, Mattia Rizzolo wrote: > Limnoria is affected by a security issue the security team deemed not > DSA-worthy. See https://security-tracker.debian.org/tracker/CVE-2019-19010 > What's the test coverage like for this code, and what's the regression risk? Thanks, Julien
Bug#944856: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u2
Control: tag -1 confirmed On Sat, Nov 16, 2019 at 04:06:59PM +0300, Dmitry Shachnev wrote: > I would like to update qtbase-opensource-src in Buster, to fix the following > bugs: > > #911702 — okular does not print to network printer > #911844 — okular prints to the wrong printer > #935909 — segfault when removing rich content (like tables) from QLabel > #935627 — graphics tablet hover events (tooltips/mouse-over) broken > > The fix for the first two bugs has already been ACKed during the freeze in > #930669, but the fix did not reach bullseye because it was built against gcc-8 > from sid. > > All these bugs are already fixed in sid/bullseye. > > The debdiff against the current version in buster (which was a security > upload) is attached. > Looks OK to me, thanks. Cheers, Julien
Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1
On Mon, Nov 11, 2019 at 10:40:58AM -0500, Antoine Beaupre wrote: > diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog > ganeti-instance-debootstrap-0.16/debian/changelog > --- ganeti-instance-debootstrap-0.16/debian/changelog 2018-06-20 > 06:57:18.0 -0400 > +++ ganeti-instance-debootstrap-0.16/debian/changelog 2019-11-01 > 19:01:50.0 -0400 > @@ -1,3 +1,10 @@ > +ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium Version number and distribution don't look right. > + > + * Non-maintainer upload > + * add patch to respect linux caps (Closes: #942114) > + > + -- Antoine Beaupré Fri, 01 Nov 2019 19:01:50 -0400 > + > ganeti-instance-debootstrap (0.16-6) unstable; urgency=medium > >* Bump Standards-Version to 4.1.4; no changes needed > diff -Nru > ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch > > ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch > --- > ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch >1969-12-31 19:00:00.0 -0500 > +++ > ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch >2019-11-01 19:01:50.0 -0400 > @@ -0,0 +1,48 @@ > +From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001 > +From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= > +Date: Thu, 10 Oct 2019 11:07:51 -0400 > +Subject: [PATCH] respect Linux capabilities(7) in cache > + > +The default GNU tar configuration does not carry fancy extended > +attributes and that is where, among other things, stuff like Linux > +capabilities(7) are stored. This is kind of important because that's > +how ping(8) works for regular users. > + > +We shove --selinux and --acls in there while we're at it, because why > +not. We never know what the future might bring, and it seems > +silly *not* to create a complete archive. > + > +Note that --xattrs-include='*' is important because, by default, GNU > +tar will not include capabilities /even/ if --xattrs is specified on > +the commandline, see this bug report for details: > + I'm a bit uneasy about a blanket "include all", to be honest. It's probably harmless since it's all coming straight out of debootstrap, but I'd have been happier with something like "include security.*" if that's what we expect to see. Cheers, Julien
Bug#944594: buster-pu: package heat/1:11.0.0-6
Control: tag -1 moreinfo On Tue, Nov 12, 2019 at 11:12:17AM +0100, Thomas Goirand wrote: > I'd like to update heat in Buster to permit safe upgrades, as the current > version may remove the heat domain password. Attached is the proposed > debdiff for this fix. > I don't understand why this requires a new template. That seems wrong to me. Cheers, Julien
Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1
Control: tag -1 confirmed On Fri, Nov 08, 2019 at 10:57:51AM +, Georg Faerber wrote: > Schleuder in buster is affected by various problems, which I would like to fix > with this proposed update: > > - Schleuder fails to recognize keywords in mails with "protected headers" > and > empty subject. > (Ref: #940524) > > - Schleuder is vulnerable to signature-flooded keys. GPG does not cope well > with these keys. It will either refuse to import them, or during and after > the import become so slow to be effectively unusable (while hogging CPUs). > By default keys are regularly updated from the keyservers (in order to > receive extended expiry dates, or key revocations). Any list with an > attacked key in its keyring will become practically unusable and strain > the > server. This is a rather severe problem. > (Ref: #940526) > > - Schleuder doesn't report an error, if the argument provided to > `refresh_keys` is not an existing list, as if the job ran successfully. > (Ref: #940527) > > All of them are already fixed in unstable. The proposed version is in > use and was tested in production for the last two weeks. > That looks fine to me. Go ahead. Cheers, Julien
Bug#944099: CVE-2019-14433 / OSSA-2019-003: buster-pu: package nova/2:18.1.0-6 -> 18.1.0-6+deb10u1
Control: tag -1 moreinfo On Mon, Nov 04, 2019 at 11:53:52AM +0100, Thomas Goirand wrote: > We would like to update Nova in Buster for 2 reasons. First, there's > OSSA-2019-003 / CVE-2019-14433 which we would like to fix. Second, > in non-interactive mode, upgrading Nova can lead to some configuration > changes, which is an RC bug. > This doesn't sound like it should require new debconf templates. What's the logic there? Why does upgrading touch the configuration at all? Cheers, Julien
Bug#942201: buster-pu: package samba/2:4.9.11+dfsg-1~deb10u1
Control: tag -1 moreinfo On Mon, Jul 08, 2019 at 10:23:49AM +0200, Mathieu Parent wrote: > samba (2:4.9.11+dfsg-1~deb10u1) unstable; urgency=medium "unstable" seems like the wrong target. > > [ Mathieu Parent ] > * New upstream release > - Bump ldb Build-Depends to 2:1.5.1+really1.4.7 > - Fixes printing via smbspool backend with kerberos auth (Closes: #931481) > - Drop security patches, merged upstream > - libsamba-passdb.so bumped to 0.27.2 > * Enable vfs_nfs4acl_xattr (Closes: #930540) > > [ Rafael David Tinoco ] > * debian/rules: Make DEB_HOST_ARCH_CPU initialized through dpkg-architecture > (Closes: #931138) > * CTDB NFS fixes (Closes: #929931, LP: #722201): > - d/p/fix-nfs-service-name-to-nfs-kernel-server.patch: change nfs service > name from nfs to nfs-kernel-server > - ctdb-config: depend on /etc/ctdb/nodes file > - d/ctdb.install, d/rules: create ctdb run directory into tmpfiles.d to > allow pid file to exist > - added /var/lib/ctdb/* directories > - d/ctdb.postrm: remove leftovers from /var/lib/ctdb/* > - Add examples of NFS HA CTDB config files + helper script > > -- Mathieu Parent Mon, 08 Jul 2019 09:56:36 +0200 > > samba is the latest 4.9.x upstream release (4.9 is in maint mode until > mid-september, see [1]). It includes a lot of stability fixes, including > crashes, memory leaks and #931481. The included security fixes were already in > Debian. > > I added an useful vfs module (vfs_nfs4acl_xattr). No regression risk here > (#930540). > On its face this doesn't sound suitable for stable. > I also added the CTDB NFS improvements from Ubuntu. CTDB NFS was broken > before, > so no regression expected ;-). > Neither does this, unless the brokenness is a regression from stretch. > I only attach the diff of the debian directory. > We'd need to see the full set of changes, please. Also, before taking on a big set of changes, a description of what QA, automated or otherwise, is happening or has happened with these changes, would be useful. Both upstream and Debian-side. Cheers, Julien
Bug#931607: buster-pu: package samba/2:4.9.11+dfsg-1~deb10u1
Control: tag -1 moreinfo On Mon, Jul 08, 2019 at 10:23:49AM +0200, Mathieu Parent wrote: > ldb (2:1.5.1+really1.4.7-1~deb10u1) unstable; urgency=medium > > [ Salsa Pipeline ] > * Update salsa CI pipeline > > [ Mathieu Parent ] > * New upstream version 1.4.7 > - Update symbols (no change) > > -- Mathieu Parent Sun, 07 Jul 2019 10:06:38 +0200 > > ldb is actually a one line change, see attachements. > It seems to me this could easily be handled entirely on the samba side. I don't understand why a ldb bump is the thing to do here. Cheers, Julien
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Thu, Nov 14, 2019 at 08:15:36PM +0100, Santiago Vila wrote: > On Thu, Nov 14, 2019 at 07:10:08PM +0100, Julien Cristau wrote: > > On Fri, Nov 08, 2019 at 01:17:20PM +0100, Santiago Vila wrote: > > > I received this bug from one of the ansible upstream authors: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > > > > > asking to include information about minor version somewhere in > > > /etc/os-release. > > > > > What I'm missing from that bug is the actual use case. The minor > > version seems to me to be pretty meaningless. What problem does > > including it actually fix? > > I would call it marginally useful, but not meaningless. > Fair. > If it was really meaningless, we would not be providing such info in > /etc/debian_version to begin with. > > In this case we would be allowing ansible maintainers for a cleaner > implementation of something which they have already decided to > implement because some users consider it useful. > > As far as we don't break any standard, does a feature need to be > useful for everybody to be implemented, or does it suffice that some > people consider it useful? (for whatever reason). > I think if we're talking about changing things in stable the bar has to be higher than "someone asked for it", especially when it may break things for somebody else (which this very much can). Cheers, Julien
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Fri, Nov 08, 2019 at 01:17:20PM +0100, Santiago Vila wrote: > I received this bug from one of the ansible upstream authors: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > asking to include information about minor version somewhere in > /etc/os-release. > What I'm missing from that bug is the actual use case. The minor version seems to me to be pretty meaningless. What problem does including it actually fix? Cheers, Julien
Bug#944186: dehydrated 0.3.1-3+deb9u3 flagged for acceptance
package release.debian.org tags 944186 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: dehydrated Version: 0.3.1-3+deb9u3 Explanation: fix certificate renewal
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
Control: tag -1 moreinfo On Wed, Sep 25, 2019 at 10:59:58AM +0200, Mattia Rizzolo wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: stretch > > Hi SRM, > > It was brought to my attention that stretch's version of dehydrated has > a few issues. They could be resolved by adding a bunch of patches on > top of the current versions, but I'd like to propose to instead > backport the buster version as it is into stretch. > I think we need to fix #941414 first, regardless. As far as I can tell that has a straightforward fix. Cheers, Julien
Bug#942217: nmu: libapache2-mod-security2_2.9.3-1
On Tue, Oct 15, 2019 at 13:15:22 +0200, Alberto Gonzalez Iniesta wrote: > On Sat, Oct 12, 2019 at 05:01:38PM +0200, Alberto Gonzalez Iniesta wrote: > > On Sat, Oct 12, 2019 at 03:57:14PM +0100, Adam D. Barratt wrote: > > > Control: tags -1 + moreinfo > > > > > > On Sat, 2019-10-12 at 15:16 +0200, Alberto Gonzalez Iniesta wrote: > > > > nmu libapache2-mod-security2_2.9.3-1 . amd64 . buster . -m "Build > > > > with libapr-1.6.5" > > > > > > > > Looks like my build environment wasn't up to date when I built this. > > > > The amd64 package is linked with an older version of libapr1 than the > > > > one in Buster. > > > > Sorry for the mess. > > > > > > What practical issues does this cause? > > > > > > > It's probably just a warning, reported here: > > https://github.com/SpiderLabs/ModSecurity/issues/2139 > > > > Upstream commented on the issue: > https://github.com/SpiderLabs/ModSecurity/issues/2139#issuecomment-541590904 > That doesn't make sense. Shared library ABI changes are handled by shlibs/symbols updates when compatible, and SONAME bumps when incompatible. Version checks beyond that are actively harmful. Cheers, Julien
Bug#929214: release.debian.org - Add package constraint for cloud images
On Thu, Jun 13, 2019 at 07:57:58PM +0200, Bastian Blank wrote: > Hi > > On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote: > > On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote: > > > If you create such a package, having a binary per architecture as you > > > describe, should do what you want. It can be added to the list as soon as > > > it > > > is in testing. > > Okay, thank you. > > A quick question: > > Will britney choke if we list conflicting packages as dependencies? > > Something like this: > | Depends: exim4, postfix > Depends what you mean by "choke". Such a package wouldn't be installable, obviously. So it would never go in testing, and wouldn't help ensure any other package's presence or installability in testing. Cheers, Julien
Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1
Control: tag -1 - moreinfo Control: tag -1 + confirmed On Thu, Oct 03, 2019 at 04:58:23PM -0700, Josue Ortega wrote: > Hi, > > I've included the recommended changes for the fix: > > rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium > > * Add 00-rmt-calls.patch (Closes: #939877): > + Add command line option to enable remote calls at runtime > + Refresh debian/patches > * debian/control: Update maintainer information > * Add debian/README.debian explaining remote calls activation for > Debian systems > * Add debian/NEWS > This looks reasonable to me, go ahead. Cheers, Julien
Bug#939526: buster-pu: package inn2/2.6.3-1+deb10u1
Control: tag -1 - moreinfo Control: tag -1 + confirmed On Sun, Oct 06, 2019 at 01:34:19AM +0200, Marco d'Itri wrote: > Control: retitle -1 buster-pu: package inn2/2.6.3-1+deb10u2 > > Bug #931256 explains in detail why TLS is broken in inn2 in buster, due > to the policies of newer openssl versions. > > As noticed by Adam D. Barratt, the original patch had a bug: it was > then solved by the upstream maintainer and the fix has been one month in > testing now. > > > diff -Nru inn2-2.6.3/debian/changelog inn2-2.6.3/debian/changelog > --- inn2-2.6.3/debian/changelog 2019-02-17 17:52:36.0 +0100 > +++ inn2-2.6.3/debian/changelog 2019-10-06 00:51:59.0 +0200 > @@ -1,3 +1,11 @@ > +inn2 (2.6.3-1+deb10u2) buster; urgency=medium > + > + * Backported upstream changeset 10344 to fix negotiation of DHE > +ciphersuites. (See #931256.) > + * Backported upstream changeset 10348 to fix upstream changeset 10344. > + > + -- Marco d'Itri Sun, 06 Oct 2019 00:51:59 +0200 > + > inn2 (2.6.3-1) unstable; urgency=medium > >* New upstream release. Go ahead and upload, thanks. Cheers, Julien
Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1
Control: tag -1 - moreinfo Control: tag -1 + confirmed On Thu, Aug 08, 2019 at 02:47:55PM +0700, Arnaud Rebillout wrote: > The debdiff attached brings in an upstream patch to fix > CVE-2019-1020014, hence closes #933801. > > This is my first contribution to Debian Stable, please check for > beginners mistake ;) > Please go ahead with the upload. Thanks, Julien
Bug#940476: buster-pu: package tmpreaper/1.6.14+deb10u1
Control: tag -1 confirmed On Mon, Sep 16, 2019 at 11:28:11AM +0200, Thijs Kinkhorst wrote: > diff -Nru tmpreaper-1.6.14/debian/changelog > tmpreaper-1.6.14+deb10u1/debian/changelog > --- tmpreaper-1.6.14/debian/changelog 2019-01-11 13:27:15.0 +0100 > +++ tmpreaper-1.6.14+deb10u1/debian/changelog 2019-09-16 09:15:24.0 > +0200 > @@ -1,3 +1,11 @@ > +tmpreaper (1.6.14+deb10u1) buster; urgency=medium > + > + * Non-maintainer upload with maintainer approval. > + * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent > +breaking systemd services that have PrivateTmp=true (closes: #881725). > + > + -- Thijs Kinkhorst Mon, 16 Sep 2019 07:15:24 + > + > tmpreaper (1.6.14) unstable; urgency=medium > >* Upload to unstable to fix the race condition described in CVE-2019-3461: Go ahead. Cheers, Julien
Bug#940059: buster-pu: package publicsuffix/20190904.1802-0+deb10u1
Control: retitle -1 buster-pu: package publicsuffix/20190925.1705-0+deb10u1 Control: tag -1 confirmed On Wed, Sep 11, 2019 at 04:16:47PM -0400, Daniel Kahn Gillmor wrote: > Please consider an update to publicsuffix in debian buster. > Go ahead. Cheers, Julien
Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1
Control: tag -1 confirmed On Tue, Sep 03, 2019 at 09:49:51PM +0100, Samuel Henrique wrote: > Capistrano is a widely used tool for deployments, one of the steps > of a deployment is to remove the old releases, this consists in removing > the last Nth releases' folders. > > Recently a bug has been found when one had too many releases, as they > are removed with the "rm" command, having too many arguments on the > command triggers the "argument list too long" error. > > The fix[0] is a small change that splices the arguments in bulks of 100. > Note that the commit is also changing more things, but they're an extra > test and a changelog entry, thus I decided it would be better to add the > whole commit to the package. > Looks ok, go ahead. It would have been helpful to note that and when this was fixed in sid, since there's no corresponding debian bug. Cheers, Julien
Bug#939313: buster-pu: package swi-prolog/8.0.2+dfsg-3
Control: tag -1 confirmed On Tue, Sep 03, 2019 at 01:51:42PM +0500, Lev Lamberov wrote: > SWI-Prolog upsteam migrated to HTTPS (from HTTP). Unfortunately, > because of that package installation of SWI-Prolog packages doesn't > work now (please, see #939257). I've prepared a backport of an > upstream patch to fix this problem. Changes are tiny and harmless. > I've built the package for buster with the patch and tested it. > Please, find the debdiff between 8.0.2+dfsg-3 (currently in buster) > and 8.0.2+dfsg-3+deb10u1 attached. > > The changelog is > > swi-prolog (8.0.2+dfsg-3+deb10u1) stable; urgency=medium > > * Add patch to fix pack-server (Closes: #939257) > > -- Lev Lamberov Tue, 03 Sep 2019 00:15:43 +0500 > The changelog entry could do with more detail on the issue and the fix. And, use "buster" rather than "stable" as the target distribution. With that in mind, go ahead. Cheers, Julien
Bug#939120: buster-pu: package ircd-hybrid/1:8.2.24+dfsg.1-1+deb10u1
Control: tag -1 confirmed On Sun, Sep 01, 2019 at 12:40:52PM +0100, Dominic Hargreaves wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Per #932774, in its default configuration, ircd-hybrid does not start > up due to a missing dhparam.pem. I've attached a proposed fix. > Go ahead. Cheers, Julien
Bug#931607: buster-pu: package samba/2:4.9.11+dfsg-1~deb10u1
Control: clone -1 -2 Control: retitle -1 buster-pu: package ldb/2:1.5.1+really1.4.7-1~deb10u1 Control: block -2 with -1 On Mon, Jul 08, 2019 at 10:23:49AM +0200, Mathieu Parent wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Hello, > > I just uploaded ldb and samba to sid, I'm targeting buster-p-u with the > following changes: > Let's discuss them separately. Cheers, Julien
Bug#940170: buster-pu: package trapperkeeper-webserver-jetty9-clojure/1.7.0-2+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu A jetty9 update broke trapperkeeper-webserver-jetty9-clojure, and as a result puppetdb, in buster (bug#924005). This is a minimal fix on the trapperkeeper-webserver-jetty9-clojure side to work around the breakage. This has been confirmed to work in sid/bullseye (1.7.0-3). For the trapperkeeper-webserver-jetty9-clojure maintainers, I pushed the change to: https://salsa.debian.org/jcristau/trapperkeeper-webserver-jetty9-clojure/commits/debian/buster Cheers, Julien diff --git a/debian/changelog b/debian/changelog index 3bfef40..3d8b882 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1) buster; urgency=medium + + [ Manfred Stock ] + * Add patch for SSL compatibility with newer Jetty (closes: #930562). + + -- Julien Cristau Fri, 13 Sep 2019 11:00:50 +0200 + trapperkeeper-webserver-jetty9-clojure (1.7.0-2) unstable; urgency=medium * Fix compatibility with Jetty 9.4 diff --git a/debian/patches/0005-maint-Disable-EndpointIdentification.patch b/debian/patches/0005-maint-Disable-EndpointIdentification.patch new file mode 100644 index 000..39890d7 --- /dev/null +++ b/debian/patches/0005-maint-Disable-EndpointIdentification.patch @@ -0,0 +1,46 @@ +From 9db4170381e07165078e544340e12b38676c2613 Mon Sep 17 00:00:00 2001 +From: Justin Stoller +Date: Fri, 24 May 2019 16:10:44 -0700 +Subject: [PATCH] (maint) Disable EndpointIdentification + +Previously, Jetty disabled Endpoint Identification by default as it is a best +practice for most webservers who often cannot identify clients +connecting to it. However, in 9.4.15 Jetty changed this default to +"HTTPS", which is the best practice for _client_ SslContexts. This +caused serious breakages throughout the Jetty ecosystem and since 9.4.16 +Jetty introduced static inner classes of SslContextFactory, named Server +and Client, to create the correct contexts for each type of consumer. + +Unfortunately, because we subclass SslContextFactory with our own +InternalSslContextFactory that overrides CRL handling, using these static +inner class factories is problematic. Consequently, this patch takes the +approach of simply setting the Endpoint Identification Algorithm to null +as was previously the default (and necessary in most server +environments). + +This will cause a warning of overriding a deprecated method during +compilation in newer Java versions and our approach to handling CRLs +will need to be reworked should we use this codebase as a basis for a +trapperkeeper-webserver-jetty10 project. + +For more info see linked issues to the implementing PR here: +https://github.com/eclipse/jetty.project/pull/3480/files#diff-58640db0f8f2cd84b7e653d1c1540913 +--- + src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj +index 3a577bb..02e7c7d 100644 +--- a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj +@@ -197,6 +197,7 @@ + (.setKeyStore (:keystore keystore-config)) + (.setKeyStorePassword (:key-password keystore-config)) + (.setTrustStore (:truststore keystore-config)) ++ (.setEndpointIdentificationAlgorithm nil) + ;; Need to clear out the default cipher suite exclude list so + ;; that Jetty doesn't potentially remove one or more ciphers + ;; that we want to be included. +-- +2.20.1 + diff --git a/debian/patches/series b/debian/patches/series index cfdab48..1d6304e 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ jetty-9.4-compat 0001-SERVER-2213-Remove-call-to-MBeanContainer-resetUniqu.patch 0003-TK-369-Add-LifeCycleImplementingRequestLogImpl.patch 0004-Implement-LifeCycle-methods-missing-from-RequestLogI.patch +0005-maint-Disable-EndpointIdentification.patch
Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye
On Tue, Sep 3, 2019 at 15:29:49 +0100, Mark Hindley wrote: > On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote: > > I think your summary is fine. However, this is not my area of expertise and > > I'm rather hoping Julien or Ansgar will chime in with an update. > > > > It certainly wouldn't be appropriate for me to remove a block put in place > > by someone else without extenuating circumstances. > > Julien, > > I am still waiting for some constructive engagement over this. > > As Jonathan's comment above makes clear and is echoed by this exchange on > #debian-release yesterday: > > Hello. #934132 is still outstanding and is now preventing resolution >of RC bug in bullseye #939101. [12:13] > Can we find a resolution to #934132? Thanks. [12:17] > weasel: zwiebelbot is missing here [12:34] > jcristau: ^ (#934132) [13:12] > jmw: well i still think shipping this thing is a bad idea. but i'm > ok with somebody else removing the block. [13:21] > I don't know enough about it to make a call on that > but I think LeePen would appreciate some sort of response > > it is obvious and completely understandable that other members of the Release > Team will not overrule your hint blocking elogind migration to bullseye. So, > resolution of this bug (and the resulting FTBFS in bullseye) is down to you. > > I have tried to answer your concerns in detail. If you think my answers are > inadequate or still think there are issues that need to be addressed, please > specify them. If not, please remove your block of elogind's migration to > testing. > I don't think it's reasonable to ship this package with C/R/P libsystemd0. I think it opens you (and, more importantly, users) up to issues like #934491. Even if #935910 were to be fixed in the package manager in bullseye, it would still mean libelogind0 couldn't ship with the C/R/P until bullseye+1. But beyond that particular issue, I'm sorry to say I think fundamentally attempting to provide a drop-in replacement for libsystemd0 while conflicting with systemd is doomed. The replacement of sysvinit with systemd was careful to keep both init systems co-installable, and I think that's something to preserve to avoid providing users with a loaded footgun with alternative init systems. Anyway, I guess if #934491 is upgraded to RC then I can drop the block hint. Cheers, Julien
Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1
On Mon, Jul 8, 2019 at 11:54:18 +0200, Mattias Ellert wrote: > > Sorry for not getting back to you again sooner. > > > > The bug fix sounds OK. What's the d/rules change about? It's not > > mentioned in the changelog. > > > > + rm -rf debian/tmp/usr/share/doc/davix/html/.doctrees > > > > Regards, > > > > Adam > > Sorry for the delay. This is due to lintian. > > $ lintian-info -t package-contains-python-doctree-file > W: package-contains-python-doctree-file > N: > N: This package appears to contain a pickled cache of reStructuredText > N: (*.rst) documentation in a .doctree file. > N: > N: These are not needed to display the documentation correctly and as > N: they can contain absolute build paths can affect the reproducibility > N: of the package. > N: > N: Either prevent the installation of the .doctree file (or parent > N: doctrees directory if there is one) or pass the -d option to > N: sphinx-build(1) to create the caches elsewhere. > That doesn't sound needed nor indeed appropriate for a stable update. Cheers, Julien
Re: Bug#927674: CVE-2019-3902
On Sun, May 26, 2019 at 09:07:11PM +0200, Moritz Mühlenhoff wrote: > On Sun, Apr 21, 2019 at 12:32:13AM +0200, Moritz Muehlenhoff wrote: > > Source: mercurial > > Version: 4.8.2-1 > > Severity: grave > > Tags: security > > > > See https://www.mercurial-scm.org/wiki/WhatsNew from 4.9: > > > > This was assigned CVE-2019-3902: > > It was possible to use symlinks and subrepositories to defeat Mercurial's > > path-checking > > logic and write files outside a repository. This has been fixed. Users on > > older versions > > can either disable subrepositories with [subrepos] allowed=false in their > > configuration > > or by ensuring any cloned repositories don't contain malicious symlinks. > > > > This is fixed in sid, but buster still has 4.8.2. > > A month later this is still unfixed in buster. Does anyone care about having > this > in a stable release? Probably not, because noone cared about stretch already > either: > https://security-tracker.debian.org/tracker/source-package/mercurial > So initially my hope was to get 4.9 in buster, however that failed due to reverse deps (hg-git and tortoisehg) not being ready in time. And since I don't read bug mail I missed your messages here. > If that's the case, let's drop it from buster? > Let's not... I'll see what I can do. Cheers, Julien
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Control: tag -1 moreinfo Hi Matthias, On Mon, Apr 29, 2019 at 06:12:36PM +0200, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock openjdk-11/11.0.3+7-4. That's the quarterly security update and > should be released with buster. No more updates planned until the next > security > update in July. >From what I understand bug#926009 is a regression in that version. There's no explanation that I can see for that change, no associated bug, and it doesn't look appropriate. Please revert it. Thanks, Julien
Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us
On Sun, Mar 3, 2019 at 23:35:45 +, Steve McIntyre wrote: > So, we're looking at three hacky options options here to work our way > out of this hole. In (probably?) descending order of hackitude: > > 1. Ask the nice ftpmaster people to bodge the archive by hand: [...] > > OR > > 2. Upload new bodged versions of shim and shim-signed to get us >back to working with the previously-signed shimx64.efi.signed >binary [...] > > OR > > 3. Upload new version of the shim-signed source package and a >(lightly) bodged binary package [...] > > So, please - what do you think? > FWIW I also don't think 1 is reasonable, but whichever of 2 or 3 the people doing the work want to run with will be fine. Cheers, Julien
Bug#906258: stretch-pu: package yubico-piv-tool/1.4.2-2
On 2/23/19 7:56 PM, Nicolas Braud-Santoni wrote: > On Sat, Feb 23, 2019 at 02:27:04PM +0100, Nicolas Braud-Santoni wrote: >> On Fri, Feb 15, 2019 at 04:55:58PM +0100, Nicolas Braud-Santoni wrote: >>> On Wed, Feb 13, 2019 at 03:34:50PM +0100, Nicolas Braud-Santoni wrote: I assume I can't just dput this, as it already exists in stable-new. Could you reject the existing package first, and I will reupload? >>> >>> Uploaded a new revision at the request of jcristau. >> >> Ping? > > Nevermind, ftpmaster rejected the upload: > They did not; I did, as I told you in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906258#69 > On Sat, Feb 23, 2019 at 05:47:07PM +, Debian FTP Masters wrote: >> yubico-piv-tool - inappropriate changelog entry > > > Dear ftpmasters, could you clarify in which way the changelog entry is > inappropriate, and what would be an appropriate changelog entry? > An appropriate changelog entry is one that describes the changes made to the package. For example, "Remove cruft that was included in the source package by mistake" would be one way to describe the changes in your upload. Cheers, Julien
