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