certbot/josepy

JOSE protocol implementation in Python using cryptography

Certbot is part of EFF’s effort to encrypt the entire Internet. Secure communication over the Web relies on HTTPS, which requires the use of a digital certificate that lets browsers verify the identity of web servers (e.g., is that really google.com?). Web servers obtain their certificates from trusted third parties called certificate authorities (CAs). Certbot is an easy-to-use client that fetches a certificate from Let’s Encrypt—an open certificate authority launched by the EFF, Mozilla, and others—and deploys it to a web server.

Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting and maintaining a certificate is. Certbot and Let’s Encrypt can automate away the pain and let you turn on and manage HTTPS with simple commands. Using Certbot and Let's Encrypt is free.

Getting Started

The best way to get started is to use our interactive guide. It generates instructions based on your configuration settings. In most cases, you’ll need root or administrator access to your web server to run Certbot.

Certbot is meant to be run directly on your web server on the command line, not on your personal computer. If you’re using a hosted service and don’t have direct access to your web server, you might not be able to use Certbot. Check with your hosting provider for documentation about uploading certificates or using certificates issued by Let’s Encrypt.

Contributing

If you'd like to contribute to this project please read Developer Guide.

This project is governed by EFF's Public Projects Code of Conduct.

Links

Documentation: https://certbot.eff.org/docs

Software project: https://github.com/certbot/certbot

Changelog: https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md

For Contributors: https://certbot.eff.org/docs/contributing.html

For Users: https://certbot.eff.org/docs/using.html

Main Website: https://certbot.eff.org

Let's Encrypt Website: https://letsencrypt.org

Community: https://community.letsencrypt.org

ACME spec: RFC 8555

ACME working area in github (archived): https://github.com/ietf-wg-acme/acme

Current Features

• Supports multiple web servers:
  • Apache 2.4+
  • nginx/0.8.48+
  • webroot (adds files to webroot directories in order to prove control of domains and obtain certificates)
  • standalone (runs its own simple webserver to prove you control a domain)
  • other server software via third party plugins
• The private key is generated locally on your system.
• Can talk to the Let's Encrypt CA or optionally to other ACME compliant services.
• Can get domain-validated (DV) certificates.
• Can revoke certificates.
• Supports ECDSA (default) and RSA certificate private keys.
• Can optionally install a http -> https redirect, so your site effectively runs https only.
• Fully automated.
• Configuration changes are logged and can be reverted.

josepy's Issues

New release for the sake of Python 3.7

I'm blocked on upgrading my project to 3.7 because of josepy.
I suspect the commit: 289f674 will resolve this.

Sorry if this isn't really a bug or a feature request but it's nice to have some ticket about this piece of work. Thanks in advance and thank you for all your hard work!

Update pyopenssl in poetry.lock

👋

Over on pyca/cryptography we're trying to ween ourselves off some deprecated OpenSSL APIs (pyca/cryptography#6948). The last blocker is that the josepy tests still use an older pyOpenSSL.

pyproject.toml already allows these versions, so they work fine for users, its just a matter of what the tests are run with.

Pin flake8/all Python dependencies in tests

Travis tests are failing due to tholo/pytest-flake8#66.

We can fix this and avoid issues like this in the future by providing a constraints file to pip pinning our dependencies.

Unless that pytest-flake8 issue is resolved and a release is put out in the next few hours, I think we should do this today.

When we do, I think it'd be nice to also submit a PR to cryptography updating https://github.com/pyca/cryptography/blob/2f2f3d2e414a0167ae3a98b9b608904b2c76a35f/.travis/downstream.d/certbot-josepy.sh to use this constraints file.

@alex & @reaperhulk, I'll make sure the Travis failures here and on cryptography's repo are fixed today one way or another.

EDIT: If we add a constraints file and configure cryptography to use it, I think we should add comments to that file reminding us that cryptography is relying on it so we can help them if we move it.

to_partial_json() is unstable in python3.5

Hello,

long story short, python3.5 (I know support got removed already) powered certbot 1.7 EAB validation fails.
The signature is wrong, changes for the same input.

import json
import josepy
import acme.jws
from cryptography.hazmat.primitives import serialization

kid,hmac_key = 'billythekid','wJA0-fHxYSlDQ-WFUvvlXQ'
url = "http://"


key = serialization.load_pem_private_key("""-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAyiKz8H/zu6Y0XIbF8Jl1m/dsLkTDlBFa/oG0gBFigAxIoDR0
a1/2CHrQht+VZNO6pfMhps0g67voVd0z+TZRhb6q1NAh2665ACrsvE/a3q4RHXuk
G5ZaiovVyiqlaH3c8IO3CT+j7XWAsmvmubDqld34/g75XnjIp2Wk/JlqeoUK7M2n
kuc2jfy3YKQvW771XmmI2i24B8K8lX2Yv49uLIKbpIAOjtHZ2RoUSc98HpgXOJ7B
MU/XftTEHcqzWrpCBwHPr0upHQL0fZJTSHKijkLvttYB1+DA1Blkdc9wjrcHKWsE
3SjHkuAs83rSFCDxTmsYUYjyLhctrtsrL84hDwIDAQABAoIBABVaQx3Vtl6NORzJ
E+HNpDHcmi3tD6f1iWI3O2UH8RrLsWRTBjVNhsTwjFSjC7oB78aV/2kKZD7is7FW
U6Ywyb3SHWOrtNfrBhnxbt6ZpOo/AwnVRMmxQVE/Yk8f4CdAnHU/xLcSZPOxpO20
HkRhXvaD40ibNlZ3deLRBvO0FR5p/VRqUOVmpZWHhLw3wm+/+TfbK4sc+PuR/dgc
Fi8+XoRsU64uI29jTRe8XyDS3EaYa+dUH6r0vK2Q301jFVaDLDlJeK29bb0p79vj
EmSlzFSCUnAT/G/qAFwR/gmAbcEsmdoRRnvgrC/Wy9Q4Hl0zsZZiKMphRbz+ByK0
8mXBvkkCgYEA752ciFC7hRRuLj3bcyga1170qVIXfVOoaQaEV0CkIq8rOz5bBpk0
hWIlnO7FNIiC7UGUw7PxslNtA4XJ2Gb3ORxByzmiF/QlXdBHixwZbyIvD3MXj2yx
uMAmCC0/sDXkeN+3Hblu71jlsZGWgkTBhbbfVKPYGQBnc6/PgE04y50CgYEA1/UD
4uIxNBy83Az8VR/qosGA80R4vFQ4JwhzFo1IfR880ogr2WvhbQ3FlToOV/NjzE74
3pKwb2kZ/ffMsHE1wDzj0EaMVihSqSKzTxR9jR6x9bJ6Wd5tsw/7HzbU7ZYCG9pI
Yww9MFOa3l9XoAp2NOX8bjOyi4O00ya4Wg/NbZsCgYBQXs9IMbwUERw7yme3InaO
Ur1BpdVXJh5Qy+zLz1S+hX68qlehyPWC3765+qSO0FMJ/XtGgS7Kn4zrJ47iVPcL
Ytz2q2ghHLUD2H6GvHAThKXAStxWMSETVO/swjCgjBMMMA2dnLsG8QxqGOkg3KsE
jKgwHZy4FhidBxVUdZJdSQKBgEaWGkAVaLm8zuoqAGwec4XhM7HP5pq/+F6hv2RW
p6PmCu5Rfeuh/Fu1zagaAsgykKMeCPBPCAZSVyGQ1kGxrzz3agsQlBwxL9uCsRMf
Am6W4toJDT7EmhyWE6G/PVeu2V+bOF/Ph0x9dzhJ940i/kIKDjlDAo/ha8A8frNJ
SP8TAoGBAK86ifnBC12FlWii+JyxOpGxyJoFD6g2W5jPKbxdRFmP8pxbyJAlyQsN
dnhptkXLpwavibzYQKFJu/wrZgvkH3PvCjfpWUpnK6461OjadZ6lP+OfsIY9n/+h
JDDMemafJNVjgy6pfpXGBsFCIdN4bekaNrWFw6DxBKLwUtBioant
-----END RSA PRIVATE KEY-----""".encode(), password=None)

pub_key = key.public_key()
pub_key.public_bytes(encoding=serialization.Encoding.PEM,
format=serialization.PublicFormat.SubjectPublicKeyInfo)

key_json = json.dumps(josepy.jwk.JWKRSA(key=pub_key).to_partial_json()).encode()
decoded_hmac_key = josepy.b64.b64decode(hmac_key)
eab = acme.jws.JWS.sign(
    key_json,
    josepy.jwk.JWKOct(key=decoded_hmac_key),
    josepy.jwa.HS256,
    None,
    url,
    kid,
)
print(eab.signature.signature)
assert eab.signature.signature == b'<\xef\x87H\xcc\xa4\x16F\x04\xeb\xa5!d\xfe\x04\xdb\x1at\xdc\x06\x9c\x04\xda\xd9\x13\x90\x0bg\xf5\xe3\xfc\xf6'

I figured the HS256 used works fine. Deserializing the same RSA Key and Protected data generates different data, as the sorting order of elements returned by to_partial_json() is unstable (in python 3.5) as it uses dict().
One problem is

josepy.jwk.JWKRSA(key=pub_key).to_partial_json()

the other is serializing the protected data.

josepy/src/josepy/jws.py

Lines 218 to 224 in c95193d

	protected_params = {}
	for header in protect:
	if header in header_params:
	protected_params[header] = header_params.pop(header)
	if protected_params:
	# pylint: disable=star-args
	protected = cls.header_cls(**protected_params).json_dumps()

I know 3.6 changed things - https://docs.python.org/3.6/whatsnew/3.6.html#new-dict-implementation

Using the debian stretch docker image reproducing is easy, but not everything worth noting is worth fixing.

W504 warnings in new pycodestyle

=================================== FAILURES ===================================
_________________________ FLAKE8-check(ignoring E501) __________________________
/build/python-josepy/src/josepy-1.1.0/src/josepy/json_util.py:320:30: W504 line break after binary operator
/build/python-josepy/src/josepy-1.1.0/src/josepy/json_util.py:350:30: W504 line break after binary operator

_________________________ FLAKE8-check(ignoring E501) __________________________
/build/python-josepy/src/josepy-1.1.0/src/josepy/jwk.py:225:21: W504 line break after binary operator

_________________________ FLAKE8-check(ignoring E501) __________________________
/build/python-josepy/src/josepy-1.1.0/src/josepy/jws.py:186:17: W504 line break after binary operator
/build/python-josepy/src/josepy-1.1.0/src/josepy/jws.py:291:13: W504 line break after binary operator
/build/python-josepy/src/josepy-1.1.0/src/josepy/jws.py:292:13: W504 line break after binary operator
/build/python-josepy/src/josepy-1.1.0/src/josepy/jws.py:293:13: W504 line break after binary operator
/build/python-josepy/src/josepy-1.1.0/src/josepy/jws.py:294:13: W504 line break after binary operator

_________________________ FLAKE8-check(ignoring E501) __________________________
/build/python-josepy/src/josepy-1.1.0/src/josepy/util.py:94:17: W504 line break after binary operator

Maybe consider to ignore W504 or update code?

Better document how to contact the maintainers of this repo

There has been some confusion about who is maintaining this repository and how to reach us which we should try and avoid going forward.

you live on an isolated island filled with stones there are infinite number of stones of weight 1,2,3,till m the size of all the stones is an integer between 1to m

Support Ed25519

In preparation for this, can we get support for those keys?

Doesn't seem to be present in 1.1.0:

$ python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from cryptography.hazmat.backends import default_backend
>>> from cryptography.hazmat.primitives import serialization
>>> from cryptography.hazmat.primitives.asymmetric import rsa,x25519
>>> from josepy import jwk
>>> jwk.JWK.load(
...     rsa.generate_private_key(
...      public_exponent=0xFFFF+2,
...      key_size=2048,
...      backend=default_backend()
...     ).private_bytes(
...      encoding=serialization.Encoding.PEM,
...      format=serialization.PrivateFormat.PKCS8,
...      encryption_algorithm=serialization.NoEncryption()
...     )
... )
JWKRSA(key=<ComparableRSAKey(<cryptography.hazmat.backends.openssl.rsa._RSAPrivateKey object at 0xffff90832080>)>)
>>> jwk.JWK.load(
...     x25519.X25519PrivateKey.generate(
...     ).private_bytes(
...      encoding=serialization.Encoding.PEM,
...      format=serialization.PrivateFormat.PKCS8,
...      encryption_algorithm=serialization.NoEncryption()
...     )
... )
Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  File "/home/james/.local/lib/python3.6/site-packages/josepy/jwk.py", line 120, in load
    raise errors.Error('Unsupported algorithm: {0}'.format(key.__class__))
josepy.errors.Error: Unsupported algorithm: <class 'cryptography.hazmat.backends.openssl.x25519._X25519PrivateKey'>
>>>

(Yes I know there are shortcuts for the RSA keygen but I'm doing the verbose form to show exact comparability in the generation)

No support for alg="none" unsecured JWSes?

I'm using josepy 1.13.0 via mozilla-django-oidc, and I came across this problem: if provided with an "unsecured" JWS then it fails during parsing with the error shown below.

That is, a JWS with the header:

{"typ":"JWT","alg":"none"}

Unfortunately, Azure AD appears to provide these during part of OIDC authentication.

As far as I can tell from a relevant part of the specs that seems to be a valid (unsecured) JWT, but it causes an error in josepy, apparently because there's no none _JWARS.

Example:

from josepy.jws import JWS

import base64

header =  b'{"typ":"JWT","alg":"none"}'
content = b'{"some_value": "blah"}'

b64 = base64.b64encode

token = (b64(header) + b'.' +
         b64(content) + b'.')

j = JWS.from_compact(token)

Produces:

(expand traceback)

Traceback (most recent call last):
  File "/Users/itme/Code/josepy/test.py", line 17, in <module>
    j = JWS.from_compact(token)
        ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/jws.py", line 335, in from_compact
    sig = cls.signature_cls(
          ^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/jws.py", line 181, in __init__
    kwargs = self._with_combined(kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/jws.py", line 192, in _with_combined
    combined = header + cls.header_cls.json_loads(protected)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/interfaces.py", line 177, in json_loads
    return cls.from_json(loads)
           ^^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/json_util.py", line 331, in from_json
    return cls(**cls.fields_from_json(jobj))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/json_util.py", line 321, in fields_from_json
    fields[slot] = field.decode(value)
                   ^^^^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/json_util.py", line 110, in decode
    return self.fdec(value)
           ^^^^^^^^^^^^^^^^
  File "/Users/itme/Code/josepy/env/lib/python3.11/site-packages/josepy/jwa.py", line 59, in from_json
    return cls.SIGNATURES[jobj]
           ~~~~~~~~~~~~~~^^^^^^
KeyError: 'none'

I tried adding a dud entry, in

josepy/src/josepy/jwa.py

Line 188 in 79acf2f

like:

NO_ALG = JWASignature.register(_JWARS('none', None))

but I had trouble working out what properties that second argument was supposed to have that might make this work (and whether it was even a good idea), and I didn't have much luck trying to find a right place to work around it with special-cases elsewhere in the code.

I'd guessed that providing an object that resembled the others, that provided a function in place of a hashing one to take any input and return an empty string, might let it pretend to validate, but couldn't work out how to implement the correct interface successfully.

Are unsecured JWSes a deliberate omission? Have I misunderstood something here?

(I'm pretty unfamiliar with this collection of standards, so please forgive any incorrect terminology.)

Use Python 3 in the release script

tools/release.sh uses Python 2 but it should use Python 3 because Python 2 is going to become harder and harder to install. Doing this should be an easier version of certbot/certbot#7902.

Allow to run non-coverage tests

Hello josepy devs!

I'd love to be able to run the unit tests downstream as part of the Debian packaging process, but right now they don't get properly detected -- possibly because I'm not building against some of the coverage libraries that are needed.

Would it be possible to split the coverage dependencies out to the dev_extras like you currently do in the acme library?

`OpenSSL.crypto.X509Req` is deprecated in PyOpenSSL 24.2+

OpenSSL.crypto.X509Req is deprecated in pyOpenSSL 24.2+.

Thus, when importing josepy with that version of PyOpenSSL, the line

josepy/src/josepy/util.py

Line 26 in 87d798e

def __init__(self, wrapped: Union[crypto.X509, crypto.X509Req]) -> None:

raises a deprecation warning:

CSR support in pyOpenSSL is deprecated. You should use the APIs in cryptography.

Repro

$ docker run -it python:3.12 bash
root@603470314b20:/# pip install josepy
Successfully installed cffi-1.17.0 cryptography-43.0.0 josepy-1.14.0 pycparser-2.22 pyopenssl-24.2.1
root@603470314b20:/# python -Xdev -c 'import josepy'
/usr/local/lib/python3.12/site-packages/josepy/util.py:26: DeprecationWarning: CSR support in pyOpenSSL is deprecated. You should use the APIs in cryptography.

Should we deprecate this library in favor of python-jose/jwcrypto?

See certbot/certbot#8322.

I'm creating an issue here for more visibility. If people see this who know more about python-jose, I'd be interested to hear any concerns or support for this idea.

abstractclassmethod is indeed from Python abc

There's a comment at

josepy/src/josepy/util.py

Line 21 in b53a8c4

code, is stolen from

that says that the implementation was "stolen from" a StackOverflow post. That could be problematic, since StackOverflow currently uses a "copyleft" "Share Alike" license, except that the implementation does actually come from Python's abc library, as the StackOverflow post says. You can see and compare that implementation here: https://github.com/python/cpython/blob/7105319ada2e663659020cbe9fdf7ff38f421ab2/Lib/abc.py#L28

It would be nice if the "stolen from" language that implies this piece of code is under the "Share Alike" license was removed, possibly replaced with a comment noting that it's borrowed from Python, which has a more permissive license and is the original source of that snippet.

Support X509 objects from the cryptography package

There's some dissonance in the fact that ComparableKey accepts a key object created with the cryptography package, but ComparableX509 requires a OpenSSL.crypto.X509 object from the OpenSSL package.

It would be nice if josepy relied only on the cryptography package interfaces and let that package handle the implementation.

Remove #pylint disables

Using flake8 instead of pylint, so inline pylint disable comments should be removed

readthedocs still points to jezdez

I came across pointers to @jezdez on https://josepy.readthedocs.io/en/latest/ etc.

Probably just requires updating the repo name in the settings on rtd.

r

Add `acme.magic_typing` and `acme.magic_typing_test` to this repo

They should be exact copies of each other except any occurances of acme (in either case) should be replaced with josepy. We just need a copy of these files for use here.

Converting JWK Key to PEM

My certificate manager imports the certbot created JWK account keys. I recently updated it to use pure-python if available, instead of OpenSSL via subprocesses.

Converting JWK keys to PEM is a few lines of code, but was a hassle of searching through docs and playing with pdb until I found the right attributes and classes.

I don't know if it is worth extending any of the objects in josepy with the capability of exporting the key to other formats, but I wanted to open an issue with the relevant code so it pops up in the repository's search results.

import josepy
from cryptography.hazmat.primitives import serialization

pkey = josepy.JWKRSA.json_loads(pkey_jwk)
as_pem = pkey.key.private_bytes(encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.TraditionalOpenSSL,
    encryption_algorithm=serialization.NoEncryption(),
)

Deprecation warning when signing/verifying JWKRSA objects

The cryptography extension has deprecated [1] (since 2.0 - 2017-07-17) the signer and verifiier methods, which results in this warning:

/var/www/workaround/venv/lib/python3.5/site-packages/josepy/jwa.py:107: CryptographyDeprecationWarning: signer and verifier have been deprecated. Please use sign and verify instead.
  signer = key.signer(self.padding, self.hash)

Code I used to get this warning:

from acme import client
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric import rsa

import josepy as jose

private_key = rsa.generate_private_key(public_exponent=65537, key_size=4096, backend=default_backend())
acme_client = client.Client( 'https://acme-v01.api.letsencrypt.org/directory', jose.JWKRSA(key=private_key))
regr = acme_client.register()

Environment:

• acme-0.22.2
• josepy-1.0.1
• cryptography-2.2.1
• Python 3.5.3

[1] pyca/cryptography#3659

python setup.py test doesn't run tests

Perhaps I'm naive and there's a better way to do this, but many of our distro run python setup.py test to ensure the package is functioning properly on their system. Can this be fixed or is there another way to do this with the new structure?

Deprecate and then drop Python 3.4

After Certbot has deprecated Python 3.4 support, we can here as well.

After we've done that and Certbot has dropped support, we should drop support here too. Python 3.4 is no longer supported by CPython, pip, and requests and that list will continue to grow over time.

Remove pytest-cache from test requirements

It is part of pytest core since late 2015: https://docs.pytest.org/en/stable/changelog.html#id1406

Generated wheel includes files in top-level site packages directory.

When updating from 1.13.0 to 1.14.0 for Arch Linux, the generated (and installed) wheel includes CHANGELOG.rst and CONTRIBUTING.md in the top level directory /usr/lib/pythonX.XX/site-packages.

This is due to these lines in pyproject.toml and is one of many common issues with Poetry when packaging for Linux distributions. Is there any particular reason why this project has chosen to downgrade to poetry from setuptools, especially now that setuptools has full support for PEP-517?

JWKEC does not pad coordinates correctly when serializing to JSON

Reported at certbot/certbot#9026.

In the Certbot log file posted, the JWK serialization of the certificate's public key has a y value of:

e_iU54B5jUg8UVOmASZCh_YgT24mbov2m4MQk
123 248 148 231 128 121 141 72 60 81 83 166 1 38 66 135 246 32 79 110 38 110 139 246 155 131 16 145 25 25 59

This is not correct. The decoded value is only 31 bytes and should be zero-padded to 32 bytes (per JWA https://datatracker.ietf.org/doc/html/rfc7518#section-6.2.1.3).

The correct value would be:

AHv4lOeAeY1IPFFTpgEmQof2IE9uJm6L9puDEJEZGTs
0 123 248 148 231 128 121 141 72 60 81 83 166 1 38 66 135 246 32 79 110 38 110 139 246 155 131 16 145 25 25 59

Here's a reproduction that decodes correctly, encodes incorrectly, and fails to decode the thing it encoded:

#!/usr/bin/env python
from josepy import JWK
import json

# works okay
k = JWK.from_json(json.loads('{"crv":"P-256","kty":"EC", "x":"Mm8rR09M7biTklBxEEqyAi9NBZn69SgZNUNANFEsK3c","y":"AHv4lOeAeY1IPFFTpgEmQof2IE9uJm6L9puDEJEZGTs"}'))

# works, but incorrectly encodes the y coordinate
k_as_json = k.to_json()

# crashes
JWK.from_json(k_as_json)

resulting in:

josepy.errors.DeserializationError: Deserialization error: Expected parameter "y" to be range(32, 33) bytes after base64-decoding; got 31 bytes instead

Create dev3 extras in setup.py including mypy and typing

See setup.py in the root of the Certbot repo.

Don't upload to codecov on nightly

Codecov has a 100 uploads per commit limit. Since we don't update this package that frequently, we hit it, and that causes tests to fail. You can see that we're hitting the 100-upload limit here. We're really only worried about coverage for new code, so let's just not run that nightly.

Get mypy passing with check_untyped_defs set to True

#29 needs to be resolved before this.

Fix tests with updated constraints

When updating constraints.txt, importlib-metadata and mypy currently need to be pinned back for tests to continue to pass. I think this should ideally be fixed.

Also, importlib-metadata is only required by flake8 in Python < 3.8 so if you install josepy with pip using Python 3.8+, this package (and its dependency zipp) won't be included in the pip freeze output. I personally think it may be worth switching this repo to use something like poetry which better handles these cases. I think we could have a more traditional poetry setup here than what we current do in the Certbot repo. This is a larger project though.

prevent JOSE algorithm type confusion

Moved here from certbot/certbot#332.

This isn't an issue for Certbot but could be for other projects using josepy.

Set up mypy tests in tox

This should be somewhat based on Certbot's tox.ini, but will be a lot simpler because we don't have wrappers around pip and our tests here. You'll probably also have to add a mypy.ini to the root of the repo which again, should be based on the file in Certbot. You shouldn't add any check_untyped_defs for now.

You should make sure these tests pass and fix any errors that prevent them from doing so. After they're passing, .travis.yml should be configured to run them.

JWK.load does not work with a str as input type for data

Hi,

I'm trying to load a previously saved private key into a JWK instance using the JWK.load method.

The documentation (https://josepy.readthedocs.io/en/latest/api/jwk/) indicates that the load method expects a str to be passed to the data object, but whenever I do this, I'm getting an exception, resulting in the next stacktrace:

File "C:/Users/xxx/Desktop/xxx/certificate_requester.py", line 13, in __main__
    key = jose.JWK.load(data=private_key)
  File "C:\Users\xxx\Desktop\xxx\venv\lib\site-packages\josepy\jwk.py", line 108, in load
    key = cls._load_cryptography_key(data, password, backend)
  File "C:\Users\xxx\Desktop\xxx\venv\lib\site-packages\josepy\jwk.py", line 83, in _load_cryptography_key
    return loader(data, backend)
  File "C:\Users\xxx/\Desktop\xxx\venv\lib\site-packages\cryptography\hazmat\primitives\serialization.py", line 24, in load_pem_public_key
    return backend.load_pem_public_key(data)
  File "C:\Users\xxx/\Desktop\xxx\venv\lib\site-packages\cryptography\hazmat\backends\openssl\backend.py", line 1019, in load_pem_public_key
    mem_bio = self._bytes_to_bio(data)
  File "C:\Users\xxx\Desktop\xxx\venv\lib\site-packages\cryptography\hazmat\backends\openssl\backend.py", line 437, in _bytes_to_bio
    data_char_p = self._ffi.new("char[]", data)
TypeError: initializer for ctype 'char[]' must be a bytes or list or tuple, not str

However, when I pass in a bytes object (obtained by performing an encode('ascii') on the str instance, it's working out all fine.

Could this be due to a difference between python2 and python 3? I'm using the latter.

Environment:

• acme 0.21.1
• josepy 1.0.1
• python 3.6.3

Require fewer dependencies to run tests with setup.py

Many of those packages are useful during development, but can make running tests hard for OS packagers.

Declare Python 3.12 support and add tests

Python 3.12 is out now. See #146 where we did this for Python 3.11.

Should we preserve git history?

I think it'd be valuable if we did so maintainers can look at commit messages to provide more information about the code through commit messages, authors, etc.

AttributeError: 'bytes' object has no attribute 'verifier' , line 123 in jwa.py

Related to this issue Exception when calling /oidc/callback #204

Test dependency on acme should be removed

There's no real need to rush to do this, but ideally, this package shouldn't depend on our ACME module.