[MIR] pyjwt (b-d of python-oauthlib)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | pyjwt (Ubuntu) |
Undecided
|
Unassigned | ||
Bug Description
pyjwt (b-d of python-oauthlib), the packaging looks sane, no open issues, just one small python file. fine from the packaging point of view.
| Changed in pyjwt (Ubuntu): | |
| assignee: | nobody → Ubuntu Security Team (ubuntu-security) |
| Changed in pyjwt (Ubuntu): | |
| assignee: | Ubuntu Security Team (ubuntu-security) → Seth Arnold (seth-arnold) |
| Changed in pyjwt (Ubuntu): | |
| assignee: | Seth Arnold (seth-arnold) → Steve Beattie (sbeattie) |
| Steve Beattie (sbeattie) wrote : | #1 |
| Changed in pyjwt (Ubuntu): | |
| assignee: | Steve Beattie (sbeattie) → nobody |
| Michael Terry (mterry) wrote : | #2 |
python-cryptography actually does have a MIR: bug 1430082.
But as for pyjwt, sounds like it's fine, but it does need that team bug subscriber.
| Changed in pyjwt (Ubuntu): | |
| status: | New → Incomplete |
| Barry Warsaw (barry) wrote : | #3 |
Latest PyPI release: https:/
| Matthias Klose (doko) wrote : | #4 |
the problem with the PyPi tarball is the missing testsuite ... now uploaded 0.4.2 from the upstream repo, which includes the tarball. There doesn't seem to be a 0.4.3 release tagged ...
| Steve Beattie (sbeattie) wrote : | #5 |
A followup note: it was pointed out in https:/
We should either cherry pick that commit or pull in the 1.0.0 release, which was the first release to include it, and also includes the improvement that allows whitelisting which specific algorithms are permitted (commit https:/
| Steve Beattie (sbeattie) wrote : | #6 |
The issue with alg=none has als been filed with debian in https:/
| Adam Conrad (adconrad) wrote : | #7 |
The update to 1.0.0 seems to resolve all the issues raise in this MIR, promoting.
| Changed in pyjwt (Ubuntu): | |
| status: | Incomplete → Fix Released |
| Adam Conrad (adconrad) wrote : | #8 |
Reopening this MIR so it doesn't get lost, as the package was demoted again due to the oauthlib in proposed never making it into the release pocket.
| Changed in pyjwt (Ubuntu): | |
| status: | Fix Released → Confirmed |
| Michael Terry (mterry) wrote : | #9 |
So do we want this again for 15.10 or are we just dropping it for now? Maybe leaving as Fix Committed makes sense if we want it immediately in 15.10.
| Matthias Klose (doko) wrote : | #10 |
Override component to main
pyjwt 1.0.0-0ubuntu1 in wily: universe/misc -> main
python-jwt 1.0.0-0ubuntu1 in wily amd64: universe/
python-jwt 1.0.0-0ubuntu1 in wily arm64: universe/
python-jwt 1.0.0-0ubuntu1 in wily armhf: universe/
python-jwt 1.0.0-0ubuntu1 in wily i386: universe/
python-jwt 1.0.0-0ubuntu1 in wily powerpc: universe/
python-jwt 1.0.0-0ubuntu1 in wily ppc64el: universe/
python3-jwt 1.0.0-0ubuntu1 in wily amd64: universe/
python3-jwt 1.0.0-0ubuntu1 in wily arm64: universe/
python3-jwt 1.0.0-0ubuntu1 in wily armhf: universe/
python3-jwt 1.0.0-0ubuntu1 in wily i386: universe/
python3-jwt 1.0.0-0ubuntu1 in wily powerpc: universe/
python3-jwt 1.0.0-0ubuntu1 in wily ppc64el: universe/
13 publications overridden.
| Changed in pyjwt (Ubuntu): | |
| status: | Confirmed → Fix Released |


I reviewed pyjwt 0.2.1-1 as included in vivid via a sync from Debian.
- CVE history: no known CVEs as of time of review /github. com/jpadilla/ pyjwt/issues/ 36. Would be preferred to
- PyJWT provides a JSON Web Token implementation in python (2 & 3).
- Crypto dependencies: depends on hashlib and hmac, and PyCrypto for
RSA.
- no daemons
- pre/post inst/rm scripts: standard generated dh_python scripts
- no init scripts
- no dbus services
- no setuid executables
- Provides jwt and jwt3 binaries
- no sudo fragments
- no udev rules
- test suite: upstream has a test suite, but it's not included
in the orig tarball. This looks to have been an upstream issue:
https:/
have a newer version that includes the upstream tests and have them
run at build time (if possible).
- no cron jobs
- I didn't see any subprocesses being spawned
- no file operations, everything passed as either function arguments or
(for the binaries), command line arguments.
- no environment use
- no logging is done, either exceptions are raised or messages sent to
stdout via print()
- no privileged operations
- Crypto only does signature generation or verification, and uses
hashlib or pycrypto functions to do so, avoiding most TLS issues.
- Code does no handling of networking directly, is presumably handed
json from network services.
- no temporary file handling
Packaging /wiki.debian. org/Python/ LibraryStyleGui de#debian. 2Fwatch or
- no Ubuntu delta
- no team is subscribed to package bugs
- the package has a debian watch file, but is
currently broken and probably needs to be updated per
https:/
reference the github releases directly
- upstream releases seem to be relatively frequent and upstream
appears responsive to bug reports.
- debian package has had only one upload, 0.2.1-1, which lags the
current upstream version (0.4.2 as of time of review).
- no lintian warnings
- debian/rules is straightforward and uses dh_python + pybuild.
- no open bugs in Debian BTS or Launchpad (besides this MIR).
One packaging issue is that for an implementation to conform with self-issued. info/docs/ draft-jones- json-web- token-01. html, it
http://
needs to support RSA signatures; however, pyjwt will not do so unless
python-crypto is installed, and there are no Depends:, Recommends:,
or Suggests: on the python-crypto packages.
The codebase is small: the python library consists of one file with
a second for the binary driver. I'm not really happy that the debian
package is lagging so far behind the upstream releases; a bunch of
refactoring has occurred that may make backporting security issues
more difficult, though the codebase is small and simple enough such
that it shouldn't be a non-starter. Also, the more recent releases do
a bit more sanity checking to ensure inputs are valid, though nothing
that looks security sensitive.
Also, the v0.4.0 upstream release includes a switch to using cryptography. The listed reasons for doing so are that its a
python-
more actively maintained upstream and has performance improvements;
the downside for Ubuntu is that it also would need a MIR.
Security team ACK for promoting to main.