Bug#1067953: marked as done (transition: flint)
Your message dated Fri, 3 May 2024 07:37:34 +0200 with message-id and subject line Re: Bug#1067953: transition: flint has caused the Debian Bug report #1067953, regarding transition: flint 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.) -- 1067953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Control: affects -1 + src:flint X-Debbugs-Cc: fl...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: dtorra...@piedmont.edu Severity: normal Dear Release Team, I would like to request a transition slot for flint. The recent upstream release 3.1.0 introduced the new soversion flint 19. A new binary package, libflint19, was introduced in the source package flint 3.1.2-1~exp1, which cleared the NEW queue on March 28 and is now in experimental. flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in the libflint18t64 binary package. However, flint 3.0.1-3.1 had been previously uploaded for the t64 transition, shipping libflint.so.18 in the same binary package. This is RC bug #1067226 and has resulted in several other RC bugs in reverse dependencies. An auto-flint tracker already exists for the t64 transition, but it doesn't take the new libflint19 package into account. (Although perhaps this will update automatically at some point?) binNMU's should be sufficient for each of flint's reverse dependencies: * e-antic * gyoto * macaulay2 * msolve * normaliz * polymake * singular Ben file: title = "flint"; is_affected = (.build-depends ~ /\blibflint-dev\b/) | (.depends ~ /\blibflint(?:18|18t64|19)\b/); is_good = .depends ~ /\blibflint19\b/; is_bad = .depends ~ /\blibflint18(?:t64)?\b/; Thank you! signature.asc Description: PGP signature --- End Message --- --- Begin Message --- On 2024-04-02 21:50:32 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2024-03-29 12:46:50 +, Torrance, Douglas wrote: > > Package: release.debian.org > > Control: affects -1 + src:flint > > X-Debbugs-Cc: fl...@packages.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: dtorra...@piedmont.edu > > Severity: normal > > > > Dear Release Team, > > > > I would like to request a transition slot for flint. The recent upstream > > release 3.1.0 introduced the new soversion flint 19. A new binary package, > > libflint19, was introduced in the source package flint 3.1.2-1~exp1, which > > cleared the NEW queue on March 28 and is now in experimental. > > > > flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in > > the libflint18t64 binary package. However, flint 3.0.1-3.1 had been > > previously uploaded for the t64 transition, shipping libflint.so.18 in > > the same binary package. This is RC bug #1067226 and has resulted in > > several other RC bugs in reverse dependencies. > > Please go ahead so that reverse dpeendencies can actually build again. The old binaries got removed. Closing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1056574: marked as done (transition: ppp)
Your message dated Fri, 3 May 2024 07:35:35 +0200 with message-id and subject line Re: Bug#1056574: transition: ppp has caused the Debian Bug report #1056574, regarding transition: ppp 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.) -- 1056574: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056574 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:ppp Hello Release Team friends, I uploaded ppp-2.5.0-1+1 to experimental back in September, and I think it's time to unleash it on unstable, ideally in the next few days. This is an ABI break both due to the new upstream version but there are also significant changes in this release that may break dependent packages. The upload I'm planning, 2.5.0-1+2, only has a minor fix for loong64 and a changelog fix. As usual this isn't a traditional library package upload so the Ben file looks a bit foreign. See #890204 for a previous time we did this. Thanks, Chris Ben file: title = "ppp"; is_affected = .build-depends ~ /ppp-dev/; is_good = .depends ~ /ppp \(>= 2\.5\.0-1\+~\)/ | .breaks ~ /ppp \(<< 2\.5\.0-1\+~\)/; is_bad = .depends ~ /ppp \(>= 2\.4\.9-1\+~\)/ | .breaks ~ /ppp \(<< 2\.4\.9-1\+~\)/; --- End Message --- --- Begin Message --- On 2024-04-20 10:29:44 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2024-04-19 17:11:44 +0100, Chris Boot wrote: > > On 26/11/2023 11:36, Chris Boot wrote: > > > On 26/11/2023 10:56, Chris Boot wrote: > > > > > Any way to reduce possible breakage, or to detect and fix it > > > > > before the transition starts? Like rebuilding rdeps, or checking > > > > > rdep autopkgtests? > > > > > > > > I'll go an do some rebuilds now and see how they go. If any breakage > > > > occurs it will be obvious at build time. > > > > > > The status of the rdeps (list taken from the tracker): > > > > > > connman: OK > > > network-manager: OK > > > pptpd: https://bugs.debian.org/1056898 > > > sstp-client: https://bugs.debian.org/1056900 > > > > > > network-manager-fortisslvpn: https://bugs.debian.org/1056901 > > > network-manager-l2tp: OK > > > network-manager-pptp: OK > > > network-manager-sstp: https://bugs.debian.org/1056903 > > > > All that's left now is pptpd (with an offer from Christoph to upload when > > ready) and network-manager-fortisslvpn (with commits fixing the issues > > upstream, but no upstream release). > > > > In the mean time, #1065940 has become a blocker for the time_t transition. I > > think I'd rather upload 2.5.0 and break network-manager-fortisslvpn than > > just the patch to fix the breakage. > > > > Would the release team be happy to continue with this transition? > > Please go ahead with the upload to unsable. ppp and reverse dependencies migrated. Closing Cheers -- Sebastian Ramacher--- End Message ---
Bug#1070271: marked as done (nmu: 64-bit time_t rebuilds for experimental)
Your message dated Fri, 3 May 2024 07:26:31 +0200 with message-id and subject line Re: Bug#1070271: nmu: 64-bit time_t rebuilds for experimental has caused the Debian Bug report #1070271, regarding nmu: 64-bit time_t rebuilds for experimental 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.) -- 1070271: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070271 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The package in sid had a renaming t64 transition, but experimental already has a different SOVERSION, so only a binNMU is needed. nmu openmm_8.1.0+dfsg-2 . ANY . experimental . -m "Rebuild for time_t" nmu opensubdiv_3.6.0-1 . ANY . experimental . -m "Rebuild for time_t" nmu protobuf_3.25.2-1 . ANY . experimental . -m "Rebuild for time_t" nmu opencascade_7.7.1+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild for time_t" Andreas --- End Message --- --- Begin Message --- On 2024-05-03 05:20:31 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > The package in sid had a renaming t64 transition, but experimental > already has a different SOVERSION, so only a binNMU is needed. > > nmu openmm_8.1.0+dfsg-2 . ANY . experimental . -m "Rebuild for time_t" > nmu opensubdiv_3.6.0-1 . ANY . experimental . -m "Rebuild for time_t" > nmu protobuf_3.25.2-1 . ANY . experimental . -m "Rebuild for time_t" > nmu opencascade_7.7.1+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild for > time_t" Scheduled Cheers -- Sebastian Ramacher--- End Message ---
Bug#1070266: marked as done (nmu: chromium_124.0.6367.118-1)
Your message dated Fri, 3 May 2024 07:26:19 +0200 with message-id and subject line Re: Bug#1070266: nmu: chromium_124.0.6367.118-1 has caused the Debian Bug report #1070266, regarding nmu: chromium_124.0.6367.118-1 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.) -- 1070266: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070266 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: serious Hello, Snappy 1.2.0-1 was uploaded with broken symbols (see https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but chromium in sid had already built against the broken version of snappy. Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol dependencies. Because this chromium release has CVE fixes (and there's 20-something pending CVEs in trixie already that would be fixed by chromium migration), I'm filing this with a higher severity than usual. nmu chromium_124.0.6367.118-1 . ANY . -m 'Rebuild against libsnappy1v5 to fix broken symbols (#1070217)' OpenPGP_0x645D0247C36E7637.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- On 2024-05-02 18:54:20 -0400, Andres Salomon wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: binnmu > Severity: serious > > Hello, > > Snappy 1.2.0-1 was uploaded with broken symbols (see > https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but > chromium in sid had already built against the broken version of snappy. > > Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol > dependencies. Because this chromium release has CVE fixes (and there's > 20-something pending CVEs in trixie already that would be fixed by chromium > migration), I'm filing this with a higher severity than usual. > > nmu chromium_124.0.6367.118-1 . ANY . -m 'Rebuild against libsnappy1v5 to > fix broken symbols (#1070217)' Scheduled. Cheers -- Sebastian Ramacher--- End Message ---
Processed: Re: Bug#1070266: nmu: chromium_124.0.6367.118-1
Processing control commands: > tags -1 +moreinfo Bug #1070266 [release.debian.org] nmu: chromium_124.0.6367.118-1 Added tag(s) moreinfo. -- 1070266: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070266 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1070266: nmu: chromium_124.0.6367.118-1
Control: tags -1 +moreinfo On Fri, May 3, 2024 at 12:57 AM Andres Salomon wrote: > Snappy 1.2.0-1 was uploaded with broken symbols (see > https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but > chromium in sid had already built against the broken version of snappy. Nope, the symbols were _not_ broken, some were missing as of the 1.1.10-1 version. I have added those back in the 1.2.0-2 package version. > Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol > dependencies. Because this chromium release has CVE fixes (and there's > 20-something pending CVEs in trixie already that would be fixed by > chromium migration), I'm filing this with a higher severity than usual. It is _not_ needed. the ABI of 1.2.0-1 is not changed in 1.2.0-2, I've even installed the new snappy library version and can still use chromium without problems. Do you experience any odd behaviour? Regards, Laszlo/GCS
Bug#1070271: nmu: 64-bit time_t rebuilds for experimental
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The package in sid had a renaming t64 transition, but experimental already has a different SOVERSION, so only a binNMU is needed. nmu openmm_8.1.0+dfsg-2 . ANY . experimental . -m "Rebuild for time_t" nmu opensubdiv_3.6.0-1 . ANY . experimental . -m "Rebuild for time_t" nmu protobuf_3.25.2-1 . ANY . experimental . -m "Rebuild for time_t" nmu opencascade_7.7.1+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild for time_t" Andreas
Bug#1070266: nmu: chromium_124.0.6367.118-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: serious Hello, Snappy 1.2.0-1 was uploaded with broken symbols (see https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but chromium in sid had already built against the broken version of snappy. Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol dependencies. Because this chromium release has CVE fixes (and there's 20-something pending CVEs in trixie already that would be fixed by chromium migration), I'm filing this with a higher severity than usual. nmu chromium_124.0.6367.118-1 . ANY . -m 'Rebuild against libsnappy1v5 to fix broken symbols (#1070217)' OpenPGP_0x645D0247C36E7637.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061645: marked as done (transition: poco)
Your message dated Thu, 2 May 2024 23:39:05 +0200 with message-id and subject line Re: Bug#1061645: poco: NMU diff for 64-bit time_t transition has caused the Debian Bug report #1061645, regarding transition: poco 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.) -- 1061645: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061645 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Control: affects -1 poco X-Debbugs-Cc: p...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Control: forwarded -1 https://release.debian.org/transitions/html/auto-poco.html poco is available in experimental with the libraries' SOVERSIONs at 100. This transition is from SOVERSION 80. The auto-generated Ben file is okay and all reverse dependencies build fine. --- End Message --- --- Begin Message --- On 2024-05-02 22:45:57 +0200, Bastian Germann wrote: > This has essentially happened because I have accidentally uploaded to > unstable. > The only reverse dependency that still depends on the old SONAME is > clickhouse, which FTBFS due to unrelated issues. > I think this can be closed. It is not in testing anyway. Closing Cheers -- Sebastian Ramacher--- End Message ---
Bug#1061645: poco: NMU diff for 64-bit time_t transition
This has essentially happened because I have accidentally uploaded to unstable. The only reverse dependency that still depends on the old SONAME is clickhouse, which FTBFS due to unrelated issues. I think this can be closed.
Bug#1070249: bookworm-pu: package python-jwcrypto/1.1.0-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: steve.mcint...@pexip.com, Timo Aaltonen
Hi,
[ Reason ]
I've backported the upstream fix for CVE-2024-28102 (#1065688) to
bookworm. It's not considered critical as a security fix by the
security team, but would still be good to have in bookworm.
Ready to upload if you're happy.
Timo is happy for me to upload this - see the conversation in
#1065688.
[ Impact ]
Minor security issue.
[ Tests ]
The patch comes from upstream, and includes a unit test.
[ Risks ]
The changes are straightforward, cherry-picked from current upstream
and just massaged to fit the older version in bookworm.
[ 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 debdiff here just contains trivial metadata changes from my
initial debdiff in #1065688
python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium
* Apply and tweak upstream security fix for CVE-2024-28102
Address potential DoS with high compression ratio
diff -Nru python-jwcrypto-1.1.0/debian/changelog
python-jwcrypto-1.1.0/debian/changelog
--- python-jwcrypto-1.1.0/debian/changelog 2022-03-29 08:33:50.0
+0100
+++ python-jwcrypto-1.1.0/debian/changelog 2024-04-26 17:18:31.0
+0100
@@ -1,3 +1,10 @@
+python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium
+
+ * Apply and tweak upstream security fix for CVE-2024-28102
+Address potential DoS with high compression ratio
+
+ -- Steve McIntyre <93...@debian.org> Fri, 26 Apr 2024 17:18:31 +0100
+
python-jwcrypto (1.1.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
--- python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 1970-01-01
01:00:00.0 +0100
+++ python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 2024-04-26
17:18:31.0 +0100
@@ -0,0 +1,72 @@
+commit 90477a3b6e73da69740e00b8161f53fea19b831f
+Author: Simo Sorce
+Date: Tue Mar 5 16:57:17 2024 -0500
+
+Address potential DoS with high compression ratio
+
+Fixes CVE-2024-28102
+
+Signed-off-by: Simo Sorce
+
+Index: os-python-jwcrypto/jwcrypto/jwe.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/jwe.py
os-python-jwcrypto/jwcrypto/jwe.py
+@@ -9,6 +9,9 @@ from jwcrypto.common import base64url_de
+ from jwcrypto.common import json_decode, json_encode
+ from jwcrypto.jwa import JWA
+
++# Limit the amount of data we are willing to decompress by default.
++default_max_compressed_size = 256 * 1024
++
+
+ # RFC 7516 - 4.1
+ # name: (description, supported?)
+@@ -387,6 +390,10 @@ class JWE:
+
+ compress = jh.get('zip', None)
+ if compress == 'DEF':
++if len(data) > default_max_compressed_size:
++raise InvalidJWEData(
++'Compressed data exceeds maximum allowed'
++'size' + f' ({default_max_compressed_size})')
+ self.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)
+ elif compress is None:
+ self.plaintext = data
+Index: os-python-jwcrypto/jwcrypto/tests.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/tests.py
os-python-jwcrypto/jwcrypto/tests.py
+@@ -1716,6 +1716,32 @@ class ConformanceTests(unittest.TestCase
+ check.decrypt(key)
+ self.assertEqual(check.payload, b'plain')
+
++def test_jwe_decompression_max(self):
++key = jwk.JWK(kty='oct', k=base64url_encode(b'A' * (128 // 8)))
++payload = '{"u": "' + "u" * 4 + '", "uu":"' \
+++ "u" * 4 + '"}'
++protected_header = {
++"alg": "A128KW",
++"enc": "A128GCM",
++"typ": "JWE",
++"zip": "DEF",
++}
++enc = jwe.JWE(payload.encode('utf-8'),
++ recipient=key,
++ protected=protected_header).serialize(compact=True)
++with self.assertRaises(jwe.InvalidJWEData):
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++
++defmax = jwe.default_max_compressed_size
++jwe.default_max_compressed_size = 10
++# ensure we can eraise the limit and decrypt
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++jwe.default_max_compressed_size = defmax
++
+
+ class JWATests(unittest.TestCase):
+ def test_jwa_create(self):
diff -Nru python-jwcrypto-1.1.0/debian/patches/series
python-jwcrypto-1.1.0/debian/patches/series
---
Bug#1068082: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1
On Mon, Apr 22, 2024, at 13:58, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote: >> As requested by the security team, I would like to bring the microcode >> update level for Intel processors in Bullseye and Bookworm to match what >> we have in Sid and Trixie. This is the bug report for Bullseye, a >> separate one will be filled for Bookmorm. > > Please go ahead. Uploaded! Thank you! -- Henrique de Moraes Holschuh
Re: Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1
Ping! Could someone please have a look at and approve the bookworm-pu for cjson?
The debdiff was changed a while back, and it is attached in this mail.
Kind regards,
Maytham
On Mon, 2024-04-08 at 12:27 +0300, Maytham Alsudany wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: cj...@packages.debian.org
> Control: affects -1 + src:cjson
>
> [ Reason ]
> CVE-2023-50472, CVE-2023-50471
>
> [ Impact ]
> Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c
>
> [ Tests ]
> Upstream's test continue to pass, and they have also added new tests to
> cover this security issue.
>
> [ Risks ]
> Minimal, no change to API. Only minimal changes were made to fix this
> security issue.
>
> [ 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 ]
> - Set myself as Maintainer (I am adopting the package, #1067510)
> - Bump Standards-Version to 4.6.2
> - Add Build-Depends-Package to symbools
> - Backport upstream's patch to 'add NULL checkings'.
> Upstream adds a few more if statements to avoid the segmentation
> fault, and thus resolve the security vulnerability.
>
> [ Other info ]
> If you can spare the time, could you please upload this for me? (I need
> a sponsor, #1068624.) I'm also still waiting for someone to give me
> access to the Salsa repo.
>
> Thanks,
> Maytham
diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
--- cjson-1.7.15/debian/changelog 2021-08-29 23:30:06.0 +0300
+++ cjson-1.7.15/debian/changelog 2024-04-09 04:30:29.0 +0300
@@ -1,3 +1,11 @@
+cjson (1.7.15-1+deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
+(Closes: #1059287)
+
+ -- Maytham Alsudany Tue, 09 Apr 2024 04:30:29 +0300
+
cjson (1.7.15-1) unstable; urgency=medium
* New upstream release 1.7.15.
diff -Nru cjson-1.7.15/debian/gbp.conf cjson-1.7.15/debian/gbp.conf
--- cjson-1.7.15/debian/gbp.conf 1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/gbp.conf 2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru cjson-1.7.15/debian/patches/0001-add-null-checkings.patch cjson-1.7.15/debian/patches/0001-add-null-checkings.patch
--- cjson-1.7.15/debian/patches/0001-add-null-checkings.patch 1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/patches/0001-add-null-checkings.patch 2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,101 @@
+Origin: backport, https://github.com/DaveGamble/cJSON/commit/60ff122ef5862d04b39b150541459e7f5e35add8
+From: Peter Alfred Lee
+Bug: https://github.com/DaveGamble/cJSON/issues/803
+Bug: https://github.com/DaveGamble/cJSON/issues/802
+Bug-Debian: https://bugs.debian.org/1059287
+Acked-by: Maytham Alsudany
+Subject: [PATCH] add NULL checkings (#809)
+ * add NULL checks in cJSON_SetValuestring
+ Fixes #803(CVE-2023-50472)
+ .
+ * add NULL check in cJSON_InsertItemInArray
+ Fixes #802(CVE-2023-50471)
+ .
+ * add tests for NULL checks
+ add tests for NULL checks in cJSON_InsertItemInArray and cJSON_SetValuestring
+
+--- a/cJSON.c
b/cJSON.c
+@@ -401,7 +401,12 @@
+ {
+ char *copy = NULL;
+ /* if object's type is not cJSON_String or is cJSON_IsReference, it should not set valuestring */
+-if (!(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++if ((object == NULL) || !(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++{
++return NULL;
++}
++/* return NULL if the object is corrupted */
++if (object->valuestring == NULL)
+ {
+ return NULL;
+ }
+@@ -2260,7 +2265,7 @@
+ {
+ cJSON *after_inserted = NULL;
+
+-if (which < 0)
++if (which < 0 || newitem == NULL)
+ {
+ return false;
+ }
+@@ -2271,6 +2276,11 @@
+ return add_item_to_array(array, newitem);
+ }
+
++if (after_inserted != array->child && newitem->prev == NULL) {
++/* return false if after_inserted is a corrupted array item */
++return false;
++}
++
+ newitem->next = after_inserted;
+ newitem->prev = after_inserted->prev;
+ after_inserted->prev = newitem;
+--- a/tests/misc_tests.c
b/tests/misc_tests.c
+@@ -353,6 +353,19 @@
+ {
+ char buffer[10];
+ cJSON *item = cJSON_CreateString("item");
++cJSON *array = cJSON_CreateArray();
++cJSON *item1 = cJSON_CreateString("item1");
++cJSON *item2 = cJSON_CreateString("corrupted array item3");
++cJSON *corruptedString = cJSON_CreateString("corrupted");
++struct cJSON *originalPrev;
++
++add_item_to_array(array, item1);
++add_item_to_array(array, item2);
++
++originalPrev = item2->prev;
++item2->prev =
Bug#1070230: marked as done (nmu: osmo-msc_1.9.0+dfsg1-2 osmo-sgsn_1.9.0+dfsg1-3)
Your message dated Thu, 2 May 2024 14:18:14 +0200 with message-id and subject line Re: Bug#1070230: nmu: osmo-msc_1.9.0+dfsg1-2 osmo-sgsn_1.9.0+dfsg1-3 has caused the Debian Bug report #1070230, regarding nmu: osmo-msc_1.9.0+dfsg1-2 osmo-sgsn_1.9.0+dfsg1-3 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.) -- 1070230: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070230 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu osmo-msc_1.9.0+dfsg1-2 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." nmu osmo-sgsn_1.9.0+dfsg1-3 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." libosmo-sccp has been restricted to 64-bit architectures and therefore the t64 renaming has been reverted. The reverse dependencies (which have been removed from the 32-bit architectures) now need another binNMU. Andreas --- End Message --- --- Begin Message --- On 02/05/2024 12:35, Andreas Beckmann wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu osmo-msc_1.9.0+dfsg1-2 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." nmu osmo-sgsn_1.9.0+dfsg1-3 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." libosmo-sccp has been restricted to 64-bit architectures and therefore the t64 renaming has been reverted. The reverse dependencies (which have been removed from the 32-bit architectures) now need another binNMU. Scheduled. Though note there's a patch in #1065790 which seems sensible. Cheers, Emilio--- End Message ---
Processed: bookworm-pu: package python3.11/3.11.2-6+deb12u2
Processing control commands: > affects -1 + src:python3.11 Bug #1070232 [release.debian.org] bookworm-pu: package python3.11/3.11.2-6+deb12u2 Added indication that 1070232 affects src:python3.11 -- 1070232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1070230: nmu: osmo-msc_1.9.0+dfsg1-2 osmo-sgsn_1.9.0+dfsg1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu osmo-msc_1.9.0+dfsg1-2 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." nmu osmo-sgsn_1.9.0+dfsg1-3 . ANY . unstable . -m "Rebuild against libosmo-sccp with t64 renaming reverted." libosmo-sccp has been restricted to 64-bit architectures and therefore the t64 renaming has been reverted. The reverse dependencies (which have been removed from the 32-bit architectures) now need another binNMU. Andreas
