Re: Podman 3.0 and Debian bullseye
On Monday, 25 January 2021 12:02:26 PM AEDT Reinhard Tartler wrote: > - Podman 3 drops the legacy varlink interface. To the best of my > knowledge, there are no packages in debian/testing that would require > varlink (please correct me if I'm wrong here). Not having to support > varlink in Debian seems a support benefit, there is little to no love > for it upstream. Varlink is needed by Nomad/nomad-driver-podman. Unfortunately "nomad-driver-podman" is not ready for new HTTP API due to some problems with it (strangely enough Varlink interface is more mature at this point). I'm running some of my infrastructure on "nomad-driver-podman" and loss of Varlink is not acceptable to me until Podman and nomad-driver-podman resolve some of the issues. I might happen soon, let's hope, but we wouldn't know until it happen... -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- The very same people who say that government has no right to interfere with sexual activity between consenting adults believe that the government has every right to interfere with economic activity between consenting adults. -- Thomas Sowell signature.asc Description: This is a digitally signed message part.
Podman 3.0 and Debian bullseye
Dear release-team, I'm proposing to have podman 3.0 in debian/bullseye. As maintainer of the package, I'm convinced this is a good step for Debian because: - podman 3.0 will be included in RHEL 8.4, which will be released in May 2021. I expect security support for podman in Debian to become significantly simpler than let's say podman 2.2 - users have expressed interest in podman 2.2 or late (cf. #978650 and others) - podman 3.0 implements enough of docker's REST API to support docker-compose (cf. https://www.redhat.com/sysadmin/podman-docker-compose) - the salsa team has expressed interest in exploring podman to facilitate gitlab maintenance. I'd expect this update to make their lives significantly easier if included in the next stable release Current concerns/risk: - Podman 3.0.0~rc1 was only just released, but I expect it to be released soon. After all, RHEL 8.4 is scheduled for May 2021 - Podman 3 drops the legacy varlink interface. To the best of my knowledge, there are no packages in debian/testing that would require varlink (please correct me if I'm wrong here). Not having to support varlink in Debian seems a support benefit, there is little to no love for it upstream. - I've just uploaded podman 3.0 to debian/experimental, and is ready for wider testing. Uploading to unstable requires a couple of additional package updates in sid: - golang-github-containers-storage - golang-github-containers-image - golang-github-containers-common - golang-github-containers-buildah I'm not really sure if this update required formal approval by the release team, but I'd really appreciate your input in any case. Best, -rt
Re: Perl 5.32.1 RC1
Adding the release team. See comment below. On Mon, Jan 18, 2021 at 12:31:12AM +, Dominic Hargreaves wrote: > Today I packaged up 5.32.1~rc1 and have uploaded it to experimental. > > I would like to include the relevant changes into bullseye, by > cherry picking the following 27 patches listed at the end of this > email. As usual the changes are minimal and generally meet out > stable release policy criteria, so I am happy to ask for an exception > to the soft freeze (a similar rationale was used in #822336, for a > stable point release). I would only do the upload once the final 5.32.1 > release is out, expected on 23rd Jan. (Of course, there is a chance > there will be additional patches to include from the final release). > > They include all relevant code changes, excluding platform-specific changes. > User documentation is included, but developer documentation is not. > Module::Corelist changes are also omitted. > > Like with previous updates of this sort, I will prepare a "debdelta" > file with the relevant changes. Hi release team, As you can see there are some miscellaneous bugfixes in the latest point release of perl. In general we'd like to keep up to date with these in stable releases. My suggestion above was to indvidually cherry pick all the relevant fixes for bullseye, but another option would be to ship bullseye with 5.32.1 directly which is a slightly bigger change to unstable now, but with the benefit of less maintenance work and less risk of mistakes being introduced. Thoughts? Cheers Dominic [full list of proposed commits below] > commit fa1bc2e4ea514f81f75551539092e7bf6226e8f5 > Author: John Lightsey > Date: Sat Jan 9 12:16:08 2021 + > > Make security warnings in the Safe and Opcode modules more direct. > > The current "no warranty" text warning against the use of Safe or > Opcode for "security purposes" is somewhat ambiguous. These modules > are not effective sandboxing mechanisms for evaluating untrusted > perl code and should not be used in that manner. > > Safe and Opcode are, at best, hardening measures that could be used > in combination with operating system level sandboxing of the perl > interpreter. > > (cherry picked from commit c150e7c040454515c5acfb8416f2acdb2c0a2bb4) > > commit 4190e73eba88675cc39af83a5c4ac5905e42c7e5 > Author: Karl Williamson > Date: Wed Nov 25 18:20:28 2020 -0700 > > Avoid deadlock with PERL_MEM_LOG > > This fixes GH #18341 > > The Perl wrapper for getenv() was changed in 5.32 to allocate memory to > squirrel safely away the result of the wrapped getenv() call. It does > this while in a critical section so as to make sure another thread can't > interrupt it and destroy it. > > Unfortunately, when Perl is compiled for debugging memory problems and > has PERL_MEM_LOG enabled, that allocation causes a recursive call to > getenv() for the purpose of checking an environment variable to see how > to log that allocation. And hence it deadlocks trying to enter the > critical section. > > There are various solutions. One is to use or emulate a general semaphore > instead of a binary one. This is effectively what > PL_lc_numeric_mutex_depth does for another mutex, and the code for that > could be used as a template. > > But given that this is an extreme edge case which requires Perl to be > specially compiled to enable this feature which is used only for > debugging, a much simpler, if less safe if it were to ever be used in > production, solution should suffice. Tony Cook suggested just avoiding > the wrapper for this particular purpose. > > (cherry picked from commit 0cc28fe31b0d416e9c67ecd18b8f38c5833a455a) > > commit bdd419192a8b2ab26be9cf5b4b8d7fe6f66b144c > Author: Tony Cook > Date: Tue Dec 8 14:28:29 2020 +1100 > > skip trying to constant fold an incomplete op tree > > This code would try to constant fold an op tree like > > relop > +- null > +- constant > > which would underflow the stack, potentially crashing perl. > > This is intended as a quick fix rather than as a complete > solution. > > Fixes #18380 > > (cherry picked from commit 08be3ef7f1190d94279ad0b3e13519ac8dc3b0ec) > > commit 9aff587fd2011ad85668efc30ed29e794fdb484e > Author: Leon Timmermans > Date: Thu Dec 17 21:02:46 2020 +0100 > > Correctly set LC_CTYPE back in POSIX/t/time.t > > (cherry picked from commit 1cd5f0d5fa70621757c327e1f6ff04bcb220e0a1) > > commit 4493dfd4aef2b89c0516020ea0914ae02dfff863 > Author: Leon Timmermans > Date: Wed Jan 6 17:43:15 2021 + > > Make DynaLoader on MacOS check library existence with dlopen > > A number of system libraries no longer exist as actual files, even > though dlopen will pretend they do, so now we fall back to dlopen if > a
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu I'd like to update the intel-microcode package in Debian Buster. This is a security-related update, but since it had a larger potential for regressions, I coordinated with the security team and we agreed that it would be best done in a slow pace, through a stable update. Regressions were indeed reported (as expected). A few days ago, Intel published relevant information pinpointing the regression on Skylake D0 and Skylake R0 processors to specific conditions (detailed below for completeness). The 3.20201118.1~deb10u1 version of the package (the one I am proposing for the stable update) contains changes not (yet?) in unstable to address the Skylake D0/R0 issue: they had their updates frozen to the same revision currently in Debian stable. For the record, that does mean these two Skylake processor models are _NOT_ receiving security updates in Debian stable at this time, and still lack SRBDS mitigations as well as newer mitigations that require newer microcode. Here's the full details about the Skylake D0/R0 microcode update regression, as disclosed by Intel. Problem Statement: Intel has identified an issue when performing OS patch loading of MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when the existing Microcode Update (MCU) version is earlier than 0x80 Issue description: When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL D0 (406e3), may lead to unexpected failures in the following conditions: * The system has a BIOS containing MCU version earlier than 0x80 (MCU < 0x80) * The user tries to load via OS load mechanism a new MCU version 0xD8 or greater Workaround: Update affected systems to a BIOS containing MCU version 0x80 or greater. A few other regressions might exist, but the situation there is either unclear thus far, or appear to be restricted to specific systems where the vendor likely did something unconvencional in their firmware. Debdiff does not work well with intel-microcode due to symlinks, so I used git diff (attached). Diffstat (from git diff): b/README.md| 106 +++ b/changelog| 60 b/debian/changelog | 87 ++ b/debian/intel-microcode.docs |3 b/intel-ucode/06-3f-02 |binary b/intel-ucode/06-4e-03 |binary b/intel-ucode/06-55-03 |binary b/intel-ucode/06-55-04 |binary b/intel-ucode/06-55-06 |binary b/intel-ucode/06-55-07 |binary b/intel-ucode/06-55-0b |binary b/intel-ucode/06-5c-09 |binary b/intel-ucode/06-5c-0a |binary b/intel-ucode/06-5e-03 |binary b/intel-ucode/06-7a-01 |binary b/intel-ucode/06-7a-08 |binary b/intel-ucode/06-7e-05 |binary b/intel-ucode/06-8a-01 |binary b/intel-ucode/06-8e-09 |binary b/intel-ucode/06-8e-0a |binary b/intel-ucode/06-8e-0b |binary b/intel-ucode/06-8e-0c |binary b/intel-ucode/06-9e-09 |binary b/intel-ucode/06-9e-0a |binary b/intel-ucode/06-9e-0b |binary b/intel-ucode/06-9e-0c |binary b/intel-ucode/06-9e-0d |binary b/intel-ucode/06-a5-02 |binary b/intel-ucode/06-a5-03 |binary b/intel-ucode/06-a5-05 |binary b/intel-ucode/06-a6-00 |binary b/intel-ucode/06-a6-01 |binary b/releasenote.md | 536 + b/s000406E3_m00C0_r00D6.fw |binary b/s000506E3_m0036_r00D6.fw |binary releasenote| 96 -- 36 files changed, 791 insertions(+), 97 deletions(-) Thank you! -- Henrique Holschuh diff --git a/README.md b/README.md new file mode 100644 index 000..47e49c4 --- /dev/null +++ b/README.md @@ -0,0 +1,106 @@ +# Intel Processor Microcode Package for Linux + +## About + +The Intel Processor Microcode Update (MCU) Package provides a mechanism to release updates for security advisories and functional issues, including errata. In addition, MCUs are responsible for starting the SGX enclave (on processors that support the SGX feature), implementing complex behaviors (such as assists), and more. The preferred method to apply MCUs is using the system BIOS. For a subset of Intel's processors, the MCU can also be updated at runtime using the operating system. The Intel Microcode Package shared here contains updates for those processors that support OS loading of MCUs. + +## Why update the microcode? +Updating your microcode can help to mitigate certain potential security vulnerabilities in CPUs as well as address certain functional issues that could, for example, result in
Bug#980939: nmu: xmobar_0.36-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu xmobar_0.36-2 . ppc64el . unstable . -m "Rebuild with newer binutils to fix #973623" Please rebuild xmobar on ppc64el to fix #973623. autopkgtest currently fails on ppc64el, and I believe #973623 is responsible for that. Thanks, -- Ilias
Bug#980938: buster-pu: package atftp/0.7.git20120829-3.2~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org
Hi SRM
The 0.7.git20120829-3.2 to unstable fixed CVE-2020-6097 for atftp. I
propose to address the same (no-dsa marked) issue as well for buster
in an upcoming point release.
Attached is the proposed debdiff. Since there were no other changes
apart the fix to between buster and bullseye, I choosed to make it a
'rebuild for buster' version instead of 0.7.git20120829-3.1+deb10u1.
Regards,
Salvatore
diff -u atftp-0.7.git20120829/debian/changelog
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,17 @@
+atftp (0.7.git20120829-3.2~deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for buster.
+
+ -- Salvatore Bonaccorso Sun, 24 Jan 2021 17:22:14 +0100
+
+atftp (0.7.git20120829-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix for DoS issue CVE-2020-6097 (Closes: #970066)
+
+ -- Salvatore Bonaccorso Sun, 27 Dec 2020 21:28:40 +0100
+
atftp (0.7.git20120829-3.1) unstable; urgency=high
* Non-maintainer upload.
diff -u atftp-0.7.git20120829/tftp_def.c atftp-0.7.git20120829/tftp_def.c
--- atftp-0.7.git20120829/tftp_def.c
+++ atftp-0.7.git20120829/tftp_def.c
@@ -180,6 +180,15 @@
return OK;
}
+int
+sockaddr_family_supported(const struct sockaddr_storage *ss)
+{
+ if (ss->ss_family == AF_INET || ss->ss_family == AF_INET6)
+ return 1;
+ else
+ return 0;
+}
+
char *
sockaddr_print_addr(const struct sockaddr_storage *ss, char *buf, size_t len)
{
@@ -189,7 +198,7 @@
else if (ss->ss_family == AF_INET6)
addr = &((const struct sockaddr_in6 *)ss)->sin6_addr;
else
- assert(!"sockaddr_print: unsupported address family");
+ return "sockaddr_print: unsupported address family";
return (char *)inet_ntop(ss->ss_family, addr, buf, len);
}
diff -u atftp-0.7.git20120829/tftp_def.h atftp-0.7.git20120829/tftp_def.h
--- atftp-0.7.git20120829/tftp_def.h
+++ atftp-0.7.git20120829/tftp_def.h
@@ -54,6 +54,7 @@
inline char *Strncpy(char *to, const char *from, size_t size);
int Gethostbyname(char *addr, struct hostent *host);
+int sockaddr_family_supported(const struct sockaddr_storage *ss);
char *sockaddr_print_addr(const struct sockaddr_storage *, char *, size_t);
#define SOCKADDR_PRINT_ADDR_LEN INET6_ADDRSTRLEN
uint16_t sockaddr_get_port(const struct sockaddr_storage *);
diff -u atftp-0.7.git20120829/tftpd.c atftp-0.7.git20120829/tftpd.c
--- atftp-0.7.git20120829/tftpd.c
+++ atftp-0.7.git20120829/tftpd.c
@@ -644,6 +644,11 @@
}
#ifdef HAVE_WRAP
+ if (!abort && !sockaddr_family_supported(>client_info->client))
+ {
+ logger(LOG_ERR, "Connection from unsupported network address family
refused");
+ abort = 1;
+ }
if (!abort)
{
/* Verify the client has access. We don't look for the name but
diff -u atftp-0.7.git20120829/tftpd_mtftp.c atftp-0.7.git20120829/tftpd_mtftp.c
--- atftp-0.7.git20120829/tftpd_mtftp.c
+++ atftp-0.7.git20120829/tftpd_mtftp.c
@@ -393,6 +393,11 @@
_size, data->data_buffer);
#ifdef HAVE_WRAP
+ if (!sockaddr_family_supported())
+ {
+logger(LOG_ERR, "mtftp: Connection from unsupported
network address family refused");
+continue;
+ }
/* Verify the client has access. We don't look for the name but
rely only on the IP address for that. */
sockaddr_print_addr(, addr_str, sizeof(addr_str));
Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote: > Assuming that a patched m2crypto will also build fine against openssl > 1.1.1d, then there's no reason that the two shouldn't proceed in > parallel (i.e. feel free to file the m2crypto request already). Yes, it does. Bug filled. Thank you. > Regards, > > Adam Sebastian
Bug#980919: buster-pu: package m2crypto/0.31.0-4+deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal
This is the proposed update for Buster to fix a build failure against
openssl 1.1.1i which is proposed for Buster.
The patch touches only the testsuite.
The m2crypto issue is tracked upstream
https://gitlab.com/m2crypto/m2crypto/-/issues/289
and I aligned the patch name and description (in debian/changelog) with
what has been applied for unstable as 0.37.1-1.
The package did not yet migrate to testing because it FTBFS on an IPv6
only buildd (unrelated issue, just built but has this RC bug).
I verified that the proposed m2crypto package builds against the
proposed openssl package.
Sebastian
diff -Nru m2crypto-0.31.0/debian/changelog m2crypto-0.31.0/debian/changelog
--- m2crypto-0.31.0/debian/changelog 2019-06-09 09:42:32.0 +0200
+++ m2crypto-0.31.0/debian/changelog 2021-01-24 12:01:15.0 +0100
@@ -1,3 +1,11 @@
+m2crypto (0.31.0-4+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/MR261.patch
+- fix compatibility with openssl/1.1.1i+; Closes: #954402
+
+ -- Sebastian Andrzej Siewior Sun, 24 Jan 2021 12:01:15 +0100
+
m2crypto (0.31.0-4) unstable; urgency=medium
* Add a few patches from upstream to avoid a testsuite
diff -Nru m2crypto-0.31.0/debian/patches/MR261.patch m2crypto-0.31.0/debian/patches/MR261.patch
--- m2crypto-0.31.0/debian/patches/MR261.patch 1970-01-01 01:00:00.0 +0100
+++ m2crypto-0.31.0/debian/patches/MR261.patch 2021-01-24 11:55:01.0 +0100
@@ -0,0 +1,46 @@
+From: Casey Deccio
+Date: Fri, 8 Jan 2021 12:43:09 -0700
+Subject: [PATCH] Allow verify_cb_* to be called with ok=True
+
+With https://github.com/openssl/openssl/commit/2e06150e3928daa06d5ff70c32bffad8088ebe58
+OpenSSL allowed verificaton to continue on UNABLE_TO_VERIFY_LEAF_SIGNATURE
+---
+ tests/test_ssl.py | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/tests/test_ssl.py b/tests/test_ssl.py
+index 92b6942c729a3..7a3271aa3dbc2 100644
+--- a/tests/test_ssl.py
b/tests/test_ssl.py
+@@ -59,8 +59,13 @@ srv_host = 'localhost'
+
+
+ def verify_cb_new_function(ok, store):
+-assert not ok
+ err = store.get_error()
++# If err is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE, then instead of
++# aborting, this callback is called to retrieve additional error
++# information. In this case, ok might not be False.
++# See https://github.com/openssl/openssl/commit/2e06150e3928daa06d5ff70c32bffad8088ebe58
++if err != m2.X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
++assert not ok
+ assert err in [m2.X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT,
+m2.X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY,
+m2.X509_V_ERR_CERT_UNTRUSTED,
+@@ -618,7 +623,12 @@ sleepTime = float(os.getenv('M2CRYPTO_TEST_SSL_SLEEP', '1.5'))
+
+ def verify_cb_old(self, ctx_ptr, x509_ptr, err, depth, ok):
+ try:
+-self.assertFalse(ok)
++# If err is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE, then instead of
++# aborting, this callback is called to retrieve additional error
++# information. In this case, ok might not be False.
++# See https://github.com/openssl/openssl/commit/2e06150e3928daa06d5ff70c32bffad8088ebe58
++if err != m2.X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
++self.assertFalse(ok)
+ self.assertIn(err,
+ [m2.X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT,
+m2.X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY,
+--
+2.30.0
+
diff -Nru m2crypto-0.31.0/debian/patches/series m2crypto-0.31.0/debian/patches/series
--- m2crypto-0.31.0/debian/patches/series 2019-06-09 09:42:08.0 +0200
+++ m2crypto-0.31.0/debian/patches/series 2021-01-24 12:00:36.0 +0100
@@ -4,3 +4,4 @@
0004-Limit-tests.test_rsa.RSATestCase.test_public_encrypt.patch
0005-tests.test_rsa-Fix-typo-to-match-for-proper-exceptio.patch
0006-Be-resilient-against-the-situation-when-no-erorr-hap.patch
+MR261.patch
Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-22 16:38:28 [+], Adam D. Barratt wrote:
> Both would be good, please.
here is the with the two additional patches.
Sebastian
diff --git a/debian/changelog b/debian/changelog
index 088c914a3dd4a..56a950734f01d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,8 +4,9 @@ openssl (1.1.1i-0+deb10u1) buster; urgency=medium
- CVE-2019-1551 (Overflow in the x64_64 Montgomery squaring procedure),
(Closes: #947949).
* Update symbol list.
+ * Apply two patches from upstream to address x509 related regressions.
- -- Sebastian Andrzej Siewior Wed, 06 Jan 2021 21:04:15 +0100
+ -- Sebastian Andrzej Siewior Sun, 24 Jan 2021 11:22:16 +0100
openssl (1.1.1d-0+deb10u4) buster-security; urgency=medium
diff --git a/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
new file mode 100644
index 0..4e6a391da269d
--- /dev/null
+++ b/debian/patches/X509_cmp-Fix-comparison-in-case-x509v3_cache_extensions-f.patch
@@ -0,0 +1,232 @@
+From: "Dr. David von Oheimb"
+Date: Wed, 30 Dec 2020 09:57:49 +0100
+Subject: X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed
+ to due to invalid cert
+
+This is the backport of #13755 to v1.1.1.
+Fixes #13698
+
+Reviewed-by: Tomas Mraz
+(Merged from https://github.com/openssl/openssl/pull/13756)
+---
+ crypto/x509/x509_cmp.c| 18 ++
+ crypto/x509/x_all.c | 2 +-
+ crypto/x509v3/v3_purp.c | 3 ++-
+ doc/man3/X509_get_extension_flags.pod | 9 +++--
+ include/openssl/x509v3.h | 5 +++--
+ test/certs/invalid-cert.pem | 19 +++
+ test/recipes/80-test_x509aux.t| 13 -
+ test/x509aux.c| 17 +++--
+ 8 files changed, 61 insertions(+), 25 deletions(-)
+ create mode 100644 test/certs/invalid-cert.pem
+
+diff --git a/crypto/x509/x509_cmp.c b/crypto/x509/x509_cmp.c
+index ad620af0aff4..c9d89336406f 100644
+--- a/crypto/x509/x509_cmp.c
b/crypto/x509/x509_cmp.c
+@@ -133,19 +133,21 @@ unsigned long X509_subject_name_hash_old(X509 *x)
+ */
+ int X509_cmp(const X509 *a, const X509 *b)
+ {
+-int rv;
++int rv = 0;
+
+ if (a == b) /* for efficiency */
+ return 0;
+-/* ensure hash is valid */
+-if (X509_check_purpose((X509 *)a, -1, 0) != 1)
+-return -2;
+-if (X509_check_purpose((X509 *)b, -1, 0) != 1)
+-return -2;
+
+-rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
+-if (rv)
++/* try to make sure hash is valid */
++(void)X509_check_purpose((X509 *)a, -1, 0);
++(void)X509_check_purpose((X509 *)b, -1, 0);
++
++if ((a->ex_flags & EXFLAG_NO_FINGERPRINT) == 0
++&& (b->ex_flags & EXFLAG_NO_FINGERPRINT) == 0)
++rv = memcmp(a->sha1_hash, b->sha1_hash, SHA_DIGEST_LENGTH);
++if (rv != 0)
+ return rv;
++
+ /* Check for match against stored encoding too */
+ if (!a->cert_info.enc.modified && !b->cert_info.enc.modified) {
+ if (a->cert_info.enc.len < b->cert_info.enc.len)
+diff --git a/crypto/x509/x_all.c b/crypto/x509/x_all.c
+index aa5ccba44899..bec850af5797 100644
+--- a/crypto/x509/x_all.c
b/crypto/x509/x_all.c
+@@ -363,7 +363,7 @@ int X509_digest(const X509 *data, const EVP_MD *type, unsigned char *md,
+ unsigned int *len)
+ {
+ if (type == EVP_sha1() && (data->ex_flags & EXFLAG_SET) != 0
+-&& (data->ex_flags & EXFLAG_INVALID) == 0) {
++&& (data->ex_flags & EXFLAG_NO_FINGERPRINT) == 0) {
+ /* Asking for SHA1 and we already computed it. */
+ if (len != NULL)
+ *len = sizeof(data->sha1_hash);
+diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
+index 2b06dba05398..93b5ca4d4283 100644
+--- a/crypto/x509v3/v3_purp.c
b/crypto/x509v3/v3_purp.c
+@@ -391,7 +391,8 @@ static void x509v3_cache_extensions(X509 *x)
+ }
+
+ if (!X509_digest(x, EVP_sha1(), x->sha1_hash, NULL))
+-x->ex_flags |= EXFLAG_INVALID;
++x->ex_flags |= (EXFLAG_NO_FINGERPRINT | EXFLAG_INVALID);
++
+ /* V1 should mean no extensions ... */
+ if (!X509_get_version(x))
+ x->ex_flags |= EXFLAG_V1;
+diff --git a/doc/man3/X509_get_extension_flags.pod b/doc/man3/X509_get_extension_flags.pod
+index 43c9c952c6b7..cca72c71fcab 100644
+--- a/doc/man3/X509_get_extension_flags.pod
b/doc/man3/X509_get_extension_flags.pod
+@@ -78,12 +78,17 @@ The certificate contains an unhandled critical extension.
+
+ =item B
+
+-Some certificate extension values are invalid or inconsistent. The
+-certificate should be rejected.
++Some certificate extension values are invalid or inconsistent.
++The certificate should be rejected.
+ This bit may also be raised after an out-of-memory error while
+ processing the X509 object, so it may not be related to the processed
+ ASN1 object
Bug#977520: buster-pu: package steam/1.0.0.59-4+deb10u1
On Sat, 23 Jan 2021 at 15:55:54 +, Adam D. Barratt wrote: > Based on the descriptions, I'd be > happy to defer to your judgement as to which of the two options you'd > be happiest to support for the future. Thanks! I'll do some more testing on 1.0.0.68-1~deb10u1 and plan to upload that one if I can, with 1.0.0.59-4+deb10u1 as a contingency plan. smcv
Bug#980875: marked as done (buster-pu: package gst-plugins-bad1.0/1.14.4-1+deb10u1)
Your message dated Sun, 24 Jan 2021 09:19:02 +0100 with message-id and subject line Re: Bug#980875: buster-pu: package gst-plugins-bad1.0/1.14.4-1+deb10u1 has caused the Debian Bug report #980875, regarding buster-pu: package gst-plugins-bad1.0/1.14.4-1+deb10u1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 980875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980875 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: car...@debian.org Hi SRM, As pointed out by Adam, since there was a binNMU for gst-plugins-bad1.0, the version from the DSA DSA-4833-1 had a lower version (usually the suffix would be choosen +debXuY for that, but this was an oversight for the DSA). Attached is the no-change change proposed to make the sorting work (and is a no change rebuild of the DSA version). Can you accept this for the next point release? Regards, Salvtore diff -Nru gst-plugins-bad1.0-1.14.4/debian/changelog gst-plugins-bad1.0-1.14.4/debian/changelog --- gst-plugins-bad1.0-1.14.4/debian/changelog 2021-01-18 16:52:16.0 +0100 +++ gst-plugins-bad1.0-1.14.4/debian/changelog 2021-01-23 16:37:59.0 +0100 @@ -1,3 +1,11 @@ +gst-plugins-bad1.0 (1.14.4-1+deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * No-change re-upload with version bumped to 1.14.4-1+deb10u1 to sort after +binNMUs for 1.14.4-1 in buster (1.14.4-1+b1). + + -- Salvatore Bonaccorso Sat, 23 Jan 2021 16:37:59 +0100 + gst-plugins-bad1.0 (1.14.4-1deb10u1) buster-security; urgency=high * debian/patches/02_ref_pic_markings_overflow.patch: --- End Message --- --- Begin Message --- On Sat, Jan 23, 2021 at 04:47:39PM +0100, Salvatore Bonaccorso wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: car...@debian.org > > Hi SRM, > > As pointed out by Adam, since there was a binNMU for > gst-plugins-bad1.0, the version from the DSA DSA-4833-1 had a lower > version (usually the suffix would be choosen +debXuY for that, but > this was an oversight for the DSA). > > Attached is the no-change change proposed to make the sorting work > (and is a no change rebuild of the DSA version). > > Can you accept this for the next point release? As discussed offlist: As this affects all the binary packages produced, so as well the actual fixes for the DSA, we should release a followup via a DSA. Closing this bugreport. Regards, Salvatore--- End Message ---
Bug#980875: buster-pu: package gst-plugins-bad1.0/1.14.4-1+deb10u1
On Sat, Jan 23, 2021 at 04:47:39PM +0100, Salvatore Bonaccorso wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: car...@debian.org > > Hi SRM, > > As pointed out by Adam, since there was a binNMU for > gst-plugins-bad1.0, the version from the DSA DSA-4833-1 had a lower > version (usually the suffix would be choosen +debXuY for that, but > this was an oversight for the DSA). > > Attached is the no-change change proposed to make the sorting work > (and is a no change rebuild of the DSA version). > > Can you accept this for the next point release? As discussed offlist: As this affects all the binary packages produced, so as well the actual fixes for the DSA, we should release a followup via a DSA. Closing this bugreport. Regards, Salvatore
