Comment by zimmerfrei | Hacker News Reader

Comment by zimmerfrei | Hacker News Reader

Parent Full thread

> 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 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...

> The addition of Rust as dependency enables the inclusion of just 90 lines of Rust

My understanding is that this is just the beginning, and the whole reason it's only a small amount is precisely to do it in small steps, correctly, rather than re-writing the entire world in one go.

And why should they re-write the entire world? It's just a wrapper library to openssl and it was marketed heavily to the community (at the beginning) as one where maintainers would follow good practices and not try to write security-sensitive code as they are not security experts, but just rely on openssl so that all focus go into the same place.

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, and not in Python as it would be more logical, and as golang does successfully). And in the latter case, why just not focus on wrapping rustls instead?

In either case, the hand is being forced: it's a small amount, and 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. It makes much more sense to read this as a move to forcefully push rust into the python ecosystem.

> 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 stops being opt-in, why wouldn't the same problem arise?

[0]: https://github.com/pyca/cryptography/issues/5381#issuecommen...

> Is Python actually suitable for cryptographic code, especially if constant-time operations are needed?

No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much).

For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of).

> And then when said logic stops being opt-in, why wouldn't the same problem arise?

Some friction will certainly remains, but it will be nothing compared to the current breakage.

> No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much).

That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately.

> For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of).

I'm curious why this has to be done in C/Rust. Performance?

> Some friction will certainly remains, but it will be nothing compared to the current breakage.

What would be different then compared to now that would reduce breakage to such an extent?

> That's fair, though if some other part of the codebase is ported to Rust anyways sticking to C doesn't save you, unfortunately.

This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference.

> I'm curious why this has to be done in C/Rust. Performance?

ASN.1 is only used during handshakes and I/O of files (the chunk of rust added covers loading of PKCS#7 files which are typically quite small, and not typically dealt with in massive numbers). I doubt the performance hit would be so high. Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast.

> What would be different then compared to now that would reduce breakage to such an extent?

The ability to try the feature out and still have a plan B if it doesn't work out, and the possibility to have a smooth, long, relaxed upgrade plan with good warnings and more time to prepare. But to be honest, while writing all this chain of comments, I really doubt there was a real need to add rust into the mix (other than the political angle I already mentioned).

> This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference.

I was thinking that if the maintainers were planning on porting some other larger part of the codebase, then starting with something small/relatively inconsequential would be a good first step, and keeping it in C wouldn't provide much benefit once said other larger part were ported.

> Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast.

Interesting! I'm curious why the maintainers didn't opt for that approach instead.

> The ability to try the feature out and still have a plan B if it doesn't work out

Would people have tried this feature out if it were made opt-in? It's clear that the initial announcements reached far fewer people than one might like, and I honestly have no idea how many people would see a build-time warning.

Reply on news.ycombinator.com