Unmaintained dependency: JWKest

A library we are using (JWKest) is not being actively maintained. This is a dependency inherited from Django-OIDC-Provider

mentioned in issue #1 (closed)

@plup should we be switching to pyjwt ?

Also an option that we ask the author if we can maintain it ourselves

I see pyjwt supports signature verification.. I prefer the implementation in JWKest personally because it looks very modular

I don't see the point of maintaining a library on our own (even if it looks cool) when there is an alternative actively maintained. pyjwt had a release 8 days ago. Assuming it covers our need I think we should invest time on this project.

OK I think that makes sense - we will need to make an estimation on how much time it will take us to replace the dependency on this issue then

Yes I would agree with @plup that we don't want to do that at first. Let's estimate what it cost to switch and remember, we have budget under the Trust funding agreement.

@plup okay to assign this to you for estimation ?

yep, I'll have a look this weekend.

Ok, it's a bit difficult to say at first glance. But I can start by proposing 2 days of works.

This is also a good opportunity for me to make a better integrtion of my test code in the project.

assigned to @plup

changed time estimate to 2d

@plup here is the list of algorithms currently supported by pyjwt https://pyjwt.readthedocs.io/en/stable/algorithms.html#specifying-an-algorithm

Is the coverage of pyjwt ok as-is do you think ?

@calummackervoy Yes we'll be alrigth but I just discovered that PyJWT is relying on cryptography and won't let you use another cryptographic backend. That means when switching to PyJWT we also need to switch from cryptodome to cryptography.

For example: https://github.com/jpadilla/pyjwt/blob/master/jwt/algorithms.py#L47

@balessan This might require some more time than estimated in the first place.

@balessan This might require some more time than estimated in the first place.

No worries we need to keep track of those difficulties then.

Are we able to open an issue with PyJWT on the off chance that they're willing to support another cryptographic backend, or is this unlikely ?

@calummackervoy you can still try and submit them something then. But we need it done :-)

@plup are you okay to open the issue with them? I understand your comment but not how it is that they block the use of Cryptodome

mentioned in issue djangoldp-account#71

Just opened a related issue in DjangoLDP-Account: djangoldp-account#71

mentioned in merge request !10 (merged)

mentioned in issue djangoldp#236

mentioned in merge request djangoldp!210 (merged)