Hi,

The following vulnerability was published for bouncycastle.

CVE-2026-5588[0]:
| : Use of a Broken or Risky Cryptographic Algorithm vulnerability in
| Legion of the Bouncy Castle Inc. BC-JAVA bcpkix on all (pkix
| modules).   PKIX draft CompositeVerifier accepts empty signature
| sequence as valid.   This issue affects BC-JAVA: from 1.49 before
| 1.84.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-5588
https://www.cve.org/CVERecord?id=CVE-2026-5588
[1] https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%905588

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Hi,

I prepared a candidate bullseye-security update for CVE-2026-5588:
bouncycastle 1.68-2+deb11u1.

Summary:
- backports upstream commit 656bae0dbd9b1521f840521ff786e78749fe3057
- adds a regression test for an empty composite signature sequence
- clean bullseye pbuilder build passed
- targeted runtime check against the built libbcprov/libbcpkix jars passed
- lintian reports only pre-existing doc-package embedded JavaScript warnings
- no autopkgtest exists for this source package

I am new to LTS contribution and not a DD, so I have not claimed
bouncycastle in dla-needed.txt or attempted any upload. I am planning to
ask debian-lts@lists.debian.org whether this is useful for review or
sponsorship.

The debdiff is attached.

Regards,
James

Hi Sylvain,

Thanks for taking the time to respond, really appreciate the guidance. I
figured 'just start working' and someone will poke their head in and point
me in the right direction :)
backport, but totally underestimated the emphasis on rdep regression coverage.
No more one-off debdiffs from me until I have that track record built up. I'll
focus on the NM process and working through Bug of the Day in the meantime.

One thing I'd like to check while I'm finding my footing: is contributing
supporting research to TODO entries in data/CVE/list still considered
worthwhile? My understanding is that adding NOTE: lines with upstream commit
references, CVSSv3 context, or "not-affected" rationale to existing TODO
stanzas helps whoever picks the CVE up next and can avoid duplicate research —
all without requiring any upload privileges. Is that a contribution the team
finds useful, or would you rather the tracker triage be left to established
contributors as well?

Thanks again for your time.

Best,
James