Once upon a time, the company I was working at was going through an acquisition and in part of the due diligence process the acquirer asked us for a complete list of all software and dependencies in our technology stack. The only one my team heard back about was ItsDangerous.
They were asking what it was for. I suspect the person reviewing the list had no idea what they were doing. If there's going to be security threat lurking in there its not going to be in the package named "itsdangerous", its going to in the one with a typo in the name.
on the other hand, just on the off chance that it is malware, you really don't want to be the guy who didn't ask about the package called "itsdangerous"
Nowhere in the HN guidelines[1] is it required (or even recommended) for a submission to be new or even recent - there are popular submissions going back to the 1900's and others that have hit the front page a dozen times because they're timeless or little-known.
The fact that the submission has 73 upvotes (as of this comment) and that I found it novel and interesting suggests that it's rather on-topic, and interesting and provides value to others, and it's certainly "Anything that good hackers would find interesting. [...] anything that gratifies one's intellectual curiosity."
Meanwhile, I don't find much value in your questioning why a popular post was submitted in the first place.
I am researching best practices for signing of data for web services (in JavaScript) and remembered that I was using a library with flask at a hackathon a few years ago and that it had a sword illustration on the website but couldn’t find it (but eventually did now).
It predates JWTs by several years.
In practice is is used the same way is as symmetrically signed JWTs though by default with HMAC-SHA-1 vs HMAC-SHA256. It can support a timestamp (`iat` for JWT) to implement expiry but not an actual `exp`; nor `aud` and the other common fields. It also dose not handle encryption or asymmetric signing.
Whilst these all sound like drawbacks they do give it simplicity which is also a useful feature.
This is much simpler than JWT; you'd have a hard time to implement this incorrectly as opposed to JWT. I'm not in the loop, but JWT also used to specify an entire tirefire for crypto algorithms. Probably still does.
The big problem was that JWTs specifies the signature algorithm alongside the signature. Some naive implementations allowed all supported algorithms by default... one of which is "none". So an attacker was able to create a key with no signature and the application would accept it. I think nowadays all implementations require you to specifically whitelist the allowed algorithms.
But yeah, JWTs (technically JWS) overlaps with ItsDangerous, but ItsDangerous is much simpler and has fewer footguns.
JWT specified all the crypto algorithms; even future ones. They did not intend people to accept more then a very small subset. This was insufficiently well communicated.
I don't think it means what you're suggesting, but maybe I'm misunderstanding you. The previous paragraph in the RFC says:
> Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").
In the next paragraph it says:
> Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations.
They're making the distinction here between JWT implementations (i.e. libraries) and applications that use JWT. Nothing mandates that applications must accept the "none" method. The earlier paragraph gives specific usage examples in which a small subset of options are allowed by the application. That is the intended use.
In this later paragraph they're just establishing a baseline of encryption support in libraries; i.e., what is the minimal set of choices that a library can offer to an application. Applications are still expected to actually choose.
It still does. In practice one of the first things you do is to only accept the specific crypto algorithms you actually need to use. Libraries don't get that luxury because they need to be generic, but at least you as the web service implementer can do it.
Surely for a web app dependency that is pretty much answered by how your app is deployed. For a Flask app it’s likely one line in your requirements.txt, probably a virtualenv in there too. Honestly, it’s not that hard
I use Python pretty regularly, and previously worked as a Python developer. I never had any issues using just pip and virtualenv. Both are bundled with Python and does exactly what I expect them to do.
Others praise the package managers of other languages, while I'm just left with the impressing that the combination of pip and virtualenv is the only solution that makes any sense.
Yeah, I stopped using Python regularly in about 2015, but even then I never had any significant problems with pip + virtualenv and I always was a bit mystified by everyone’s complaints about “Python package management”.
I've likewise been satisfied with virtualenv/pip for years, but I've also done a recent project with Poetry and been quite impressed with how it automates a bunch of the virtualenv bookkeeping. I think it will likely be my choice going forward, but I don't know if it's enough-better to actually want to go to the trouble of porting my plain setup.py/setup.cfg projects to it.
Going by https://explainxkcd.com/1987/ the problem seems to be half a dozen possible package managers that each manage their own python environment.
As a Linux user it was a bit weird, I use apt to install packages but for some reason I need pip for certain python packages? I barely use python so I am still not sure if there is anything ensuring that those don't conflict.
