I don't know why you think this; the asn1-rust crate is in fact used to implement not only X.509 certificate decoding[1] but also path validation[2].
Edit: Here's an example of a CHOICE implemented with rust-asn1 that has more than three variants[3].
[1]: https://cryptography.io/en/latest/x509/reference/
[2]: https://cryptography.io/en/latest/x509/verification/
[3]: https://github.com/pyca/cryptography/blob/be6c53dd03172dde6a...
In A New ASN.1 API for Pythonpyca
cryptography
Python2014–2025
pyca / cryptography
cryptography
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
29Distinct people
35Mentions
0Explicit recommenders
7.8KGitHub stars
What to know before exploring
What it is
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year35 dated mentions
Observed mentions: 2014-04-09 22:06:12 UTC to 2025-04-19 02:11:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 19 | 6 | 13 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
pyca/cryptography
cryptography is a package which provides cryptographic recipes and
primitives to Python developers. Our goal is for it to be your "cryptographic
standard library". It supports Python 3.9+ and PyPy3 7.3.11+.
cryptography includes both high level recipes and low level interfaces to
common cryptographic algorithms such as symmetric ciphers, message digests, and
key derivation functions. For example, to encrypt something with
cryptography's high level symmetric encryption recipe:
>>> from cryptography.fernet import Fernet
>>> # Put this somewhere safe!
>>> key = Fernet.generate_key()
>>> f = Fernet(key)
>>> token = f.encrypt(b"A really secret message. Not for prying eyes.")
>>> token
b'...'
>>> f.decrypt(token)
b'A really secret message. Not for prying eyes.'
You can find more information in the documentation.
You can install cryptography with:
$ pip install cryptography
For full details see the installation documentation.
Discussion
If you run into bugs, you can file them in our issue tracker.
We maintain a cryptography-dev mailing list for development discussion.
You can also join #pyca on irc.libera.chat to ask questions or get
involved.
Security
Need to report a security issue? Please consult our security reporting
documentation.
Read the full README on GitHubWhat Hacker News says
35 sourcesWill this bring support for "streaming" output from SHAKE?
Here's the (recently closed!) issue for pyca/cryptography regarding this feature, although I can't find an equivalent issue for the python stdlib: https://github.com/pyca/cryptography/issues/9185
Edit: Found a relevant issue, "closed as not planned": https://github.com/python/cpython/issues/82198
In 15,000 lines of verified cryptography now in PythonHaving the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771.
I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing
Read the rest
offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features.
Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.
Congratulations to the authors, this was a feature that was dearly missing from pyca/cryptography. It took a long time to get right.
For the history: https://github.com/pyca/cryptography/issues/2381
In We build X.509 chains so you don't have to> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.
One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap", Jupyter notebooks, and in many other domains, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and without the plumbing libraries none of the higher-level applications can function.
[1]: ht
Read the rest
> I am curious. Could you give some more context?
Probably talking about this: https://github.com/pyca/cryptography/issues/5771
In It's time to halt starting any new projects in C/C++> I don't see how memory safety adds anything [to algos in cryptography] as memory issues are an insignificant problem.
I'm not terribly experienced in cryptography either, but I'm pretty sure that memory safety is a HUGE deal in cryptography as a whole. Heartbleed[0] was a memory safety issue. Python's cryptography package switched to Rust specifically because of memory safety [1].
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160
[1] https://github.com/pyca/cryptography/issues/5771
In Zig, the Small LanguageThe modes of operation aren't the main reason people use OpenSSL; it's the support for all the gnarly (and less gnarly) protocols and wire formats that show up when doing applied cryptography.
Progress is being made on replacing OpenSSL in a lot of contexts (specifically, the RustCrypto[1] folks are doing excellent work and so is cryptography[2]), but there are still plenty of areas where OpenSSL is needed to compose the mostly algebraic cryptography with the right wire format.
Edit: I forgot to mention rustls[3], which uses ring[4] under the hood.
[1]: https://github.com/RustCrypto
[2]: https://github.com/pyca/cryptography
[3]: https://github.com/rustls/rustls
[4]: https://github.com/briansmith/ring
In OpenSSL Security AdvisoryFWIW Linux does support s390 (n.b., not to be confused with s390x), which is a 31 bit arch. Rust does not support it (and I'd guess LLVM doesn't either). So Linux does support some "weird" arches still.
This is partially what caused the shitstorm when the python Cryptography library took a hard dependency on rust to compile:
https://github.com/pyca/cryptography/issues/5771
In Rust support in the Linux kernel> Iirc, the dependency was rolled back.
I am fairly certain it was not, e.g. see this comment (or just notice that there's still rust code in the codebase)
https://github.com/pyca/cryptography/issues/5771#issuecommen...
(Edit: Changed link to a better one)
In Alpine Linux: Proposal to move Rust to mainDoes it depend on the cryptography library? https://github.com/pyca/cryptography/issues/5771
In Show HN: A simple lazy Python calculation engine, with spreadsheet demoNot in core Python, but in a widely-used library, yes. https://github.com/pyca/cryptography/issues/5771
In The kernel has 6 separate ASN.1 parsers> So either that's still valid (and not too much of rust will come in to make a real difference security-wise) or they have revisited their position and will re-implement a bunch of openssl logic (in rust apparently though
Looks like it's the former. From the initial (?) GitHub issue discussing the move to Rust [0]:
> We do not plan to move any of the crypto under the scope of FIPS-140 from OpenSSL to cryptography. We do expect to move a) our own code that's written in C (e.g. unpadding), b) ASN.1 parsing. Neither of those are in scope for FIPS-140.
> and not in Python as it would be more logical
Is Python actually suitable for cryptographic code, especially if constant-time operations are needed?
> I don't see how it would have been an excessive burden to maintain such a small logic as an opt in for a period.
And then when said logic sto
Read the rest
ps being opt-in, why wouldn't the same problem arise?
[0]: https://github.com/pyca/cryptography/issues/5381#issuecommen...
Alright, let's do some digging...
On 2013-03-21, urllib3 added an optional dependency to pyopenssl for SNI support on python2 - https://github.com/urllib3/urllib3/pull/156
On 2013-12-29, pyopenssl switched from opentls to cryptography - https://github.com/pyca/pyopenssl/commit/6037d073
On 2016-07-19, urllib3 started to depend on a new pyopenssl version that requires cryptography - https://github.com/urllib3/urllib3/commit/c5f393ae3
On 2016-11-15, requests started to depend on a new urllib3 version that now indirectly requires cryptography - https://github.com/psf/requests/commit/99fa7bec
On 2018-01-30, portage started to enable the +rsync-verify USE flag by default, which relies on the gemato python library maintained by mgorny himself, and gemato depended on requests. So 5-6 levels of indirection at this point? I lost count.
On 2020-01-0
Read the rest
1, python2 was sunset. A painful year to remember, and a painful migration to forget. And just when the year was about to end...
On 2020-12-22, cryptography started to integrate rust in the build process, and all hell broke loose - https://github.com/pyca/cryptography/commit/c84d6ee0
Ultimately, I think mgorny only has himself to blame here, by injecting his own library into the critical path of gentoo, without carefully taking care of its direct and indirect dependencies. (But of course it is also fair game to blame it on the 2to3 migration)
In comparison, few months before this, the librsvg package went through a similar change where it started to depend on rust, and it was swift and painless without much drama - https://bugs.gentoo.org/739820 and https://wiki.gentoo.org/wiki/Project:GNOME/3.36-notes
> I feel like this really only makes sense if pyca/cryptography had planned on adding the Rust dependency from the very beginning (or from very early on). Is there any indication that was the case?
I am sure this idea surfaced several times in IRC or possibly in the mailing lists. Certainly, the authors have been toying with handling ASN.1 in rust since 2015 [1], which I guess will be the next logical step.
I do agree that this is mostly a political stance. pyca/cryptography is a wrapper sandwiched between a gigantic runtime written in C (CPython/PyPy) and a gigantic library written in C (openssl).
The addition of Rust as dependency enables the inclusion of just 90 lines of Rust [2] where the only part that really couldn't be implemented in pure Python is a line copied from OpenSSL [3] (i.e. it was already available), and which is purely
Read the rest
algebraic, therefore not mitigating any real memory issue at all (the reason to use rust in the first place).
The change in this wrapper (pyca/cryptographic) does not move the needle of security in any significant way, and it is really only meant to send the signal that adding Rust in all other Python packages and especially in the runtime itself will now come at no (political) cost.
[1] https://github.com/alex/rust-asn1
[2] https://github.com/pyca/cryptography/blob/main/src/rust/src/...
[3] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/inclu...
Showing the 15 most recent of 35 sources. Enable JavaScript to search and browse every indexed mention.