./www/py-jwcrypto, Implementation of JOSE Web standards

[ CVSweb ] [ Homepage ] [ RSS ] [ Required by ] [ Add to tracker ]


Branch: CURRENT, Version: 1.5.6, Package name: py311-jwcrypto-1.5.6, Maintainer: pkgsrc-users

An implementation of the JOSE Working Group documents:
* RFC 7515 - JSON Web Signature (JWS)
* RFC 7516 - JSON Web Encryption (JWE)
* RFC 7517 - JSON Web Key (JWK)
* RFC 7518 - JSON Web Algorithms (JWA)
* RFC 7519 - JSON Web Token (JWT)
* RFC 7520 - Examples of Protecting Content Using JSON Object Signing
and Encryption (JOSE)


Master sites:

Filesize: 85.125 KB

Version history: (Expand)


CVS history: (Expand)


   2024-03-07 11:01:52 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
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.
   2024-02-14 22:50:29 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
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
   2024-02-08 07:06:40 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-jwcrypto: updated to 1.5.3

v1.5.3

Drop python 3.6 and 3.7 and add 3.11 support
   2024-02-07 21:11:23 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-jwcrypto: updated to 1.5.2

Version 1.5.2

replace deprecated package with typing_extensions
   2024-01-20 17:19:14 by Thomas Klausner | Files touched by this commit (1)
Log message:
py-jwcrypto: add missing tools
   2024-01-04 23:29:23 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
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
   2023-08-26 13:56:44 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
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
   2023-05-29 10:51:08 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
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.