Bug#1010657: google-oauth-client-java: CVE-2021-22573 - IdTokenVerifier does not verify the signature of ID Token
tony mancill
tmancill at debian.org
Sun May 15 19:17:53 BST 2022
On Mon, May 09, 2022 at 09:23:36PM -0700, tony mancill wrote:
> On Fri, May 06, 2022 at 09:46:24AM +0100, Neil Williams wrote:
> > Source: google-oauth-client-java
> > Version: 1.28.0-2
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> >
> > Fixed in upstream release 1.33.3
> >
> > 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-2021-22573
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22573
> >
> > Please adjust the affected versions in the BTS as needed.
>
> Upstream version 1.33.3 requires a minor update to the Debian packaging
> of google-http-client-java that I am working on now.
>
> I will upload a package for 1.33.3 in the next day or so.
In order to backport this patch for bullseye, we will need a version of
google-http-client-java in bullseye that includes
google-http-client-gson.jar (as was added in [1]). I'm not sure how
this works if a security update for package requires an update to its
build-deps.
Based on the limited set of reverse-dependencies of
libgoogle-oauth-client-java in bullseye - that is:
$ reverse-depends --build --list --release=bullseye libgoogle-oauth-client-java
google-api-client-java
$ reverse-depends --list --release=bullseye libgoogle-oauth-client-java
(nothing)
$ reverse-depends --list --release=bullseye libgoogle-api-client-java
bazel-bootstrap
$ reverse-depends --build --list --release=bullseye libgoogle-api-client-java
bazel-bootstrap
$ reverse-depends --build --list --release=bullseye bazel-bootstrap
(nothing)
And the chain seems to end there. As I understand it, getting
bazel-bootstrap into bullseye was in preparation for bookworm, but there
aren't any packages with build-deps on it bullseye.
For that reason, I'm wondering whether we wouldn't be better off
updating instead backporting to address this CVE. Related to this,
Markus has already created a backport of google-http-client-java [2].
(That is, there are other reasons for a newer versions in bullseye.)
Any thoughts? It's a tad messy either way, but using current versions
simplifies the porting of patches.
Thank you,
tony
[1] https://tracker.debian.org/news/1323863/accepted-google-http-client-java-1418-2-source-into-unstable/
[2] https://tracker.debian.org/news/1292692/accepted-google-http-client-java-1401-1bpo111-source-all-into-bullseye-backports-bullseye-backports/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20220515/125b72db/attachment.sig>
More information about the pkg-java-maintainers
mailing list