Log message:
py-jwcrypto: updated to 1.5.6

1.5.6
Address potential DoS with high compression ratio

1.5.5
This version fixes a pypi distribution problem introduced in 1.0 when pushing \ 
was automated.
With 1.5.5 a binary wheel is now also made available on pypi.

Log message:
py-jwcrypto: updated to 1.5.4

v1.5.4

One more release bump to address issues with typing_extensions minimum required \ 
version

Log message:
py-jwcrypto: updated to 1.5.3

v1.5.3

Drop python 3.6 and 3.7 and add 3.11 support

Log message:
py-jwcrypto: updated to 1.5.2

Version 1.5.2

replace deprecated package with typing_extensions

Log message:
py-jwcrypto: add missing tools

Log message:
py-jwcrypto: updated to 1.5.1

Version 1.5.1 - Security Release

This is a minor security release to fix a potential DoS for applications that \ 
allow the use of symmetric keys with pbkdf2.

What's Changed

Fix X22519 import/export from PEM
Read the Docs now requires a config file
chore: refactor for removing pdb symbols
Fix potential DoS issue with p2c header

Log message:
py-jwcrypto: updated to 1.5.0

v1.5.0

Raising the bar for minimum pyca/cryptography
Fix typos with codespell
Add codespell checks in CI
Add Brainpool EC-curves support
Fix error message
Fix assorted CI issue
Better support for algorithms that have different input keysize requirement

Log message:
py-jwcrypto: updated to 1.4.2

Version 1.4.2
Fix typo in new backwards JWT compat heuristics

Version 1.4.1
This is a minor release focused on improving backwards compatibility with \ 
applications after the API breaking changes introduced in 1.4
This patch adds a bunch of heuristics to be able to safely autodetect a token \ 
type. It has been tested to solve the compatibility issues (ie old code works \ 
without modifications and fully securely) with at least one large application.

Version 1.4
This is a security release to address CVE-2022-3102.

The JWT code can auto-detect the type of token being provided, and this can lead \ 
the application to incorrect conclusions about the trustworthiness of the token.
Quoting the private disclosure we received : "Under certain circumstances, \ 
it is possible to substitute a [..] signed JWS with a JWE that is encrypted with \ 
the public key that is normally used for signature validation."
This substitution attack can occur only if the validating application also have \ 
access to the private key, normally used to sign the tokens, available during \ 
validation of the received JWT.
The significance of this attacks depends on the use of the token, it may lead to \ 
authentication bypass or authorization bypass (respectively if claims are used \ 
to authenticate or authorize certain actions), because the attacker has full \ 
control of the data placed in the JWE and can inject any desired claim value.

Several mitigating factors exist that can protect applications from this issue:

If the private key corresponding to the public key used to encrypt the JWE is \ 
not available to the application an exception will be raised.
If the JWK is specified with the 'use' parameter set to 'sig' (as expected for \ 
keys used only for signing/verification) an exception will be raised.
If the JWK is specified with the 'key_ops' parameter set and it does not include \ 
the 'decrypt' operation an exception will be raised.
Applications may check the token type before validation, in this case they would \ 
fail to detect an expected JWS
Normally, signing and validation are done by different applications, so this \ 
scenario should be unlikely. However it is possible to have applications that \ 
both sign and validate tokens and do not separate JWKs in use, or do not set a \ 
JWK 'use' type.

Due to the mitigating factors, and the fact that specific operational \ 
constraints and conditions need to be in place to successfully exploit this \ 
issue to generate an authentication bypass, we rate this security issue as \ 
moderate. Other avenues may decide on a different rating based on use case, \ 
always verify what conditions apply to your use of the library to assess risk.