6 ms·

> If pyca/cryptography was instead advertised as "python crypto library for rust lovers" I feel like this really only makes sense if pyca/cryptography had plan

> If pyca/cryptography was instead advertised as "python crypto library for rust lovers" 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? > but not just that, it depends on a custom-patched llvm! This doesn't seem to be true [0, 1]. [0]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.... [1]: https://news.ycombinator.com/item?id=26217182 https://news.ycombinator.com/item?id=26217182

ploxiln 6y ago
>> Strongly prefer to upstream all patches to LLVM before including them in rustc. > That is, this is already the case. We don't like maintaining a fork. We try to upstream as much as we can. > But, at the same time, even when you do this, it takes tons of time. A contributor was talking about exactly this on Twitter earlier today, and estimated that, even if the patch was written and accepted as fast as possible, it would still take roughly a year for that patch to make it into the release used by Rust. This is the opposite side of the whole "move slow and only use old versions of things" tradeoff: that would take even longer to get into, say, the LLVM in Debian stable, as suggested in another comment chain. > So our approach is, upstream the patches, keep them in our fork, and then remove them when they inevitably make it back downstream. ... so there are always some outstanding patches rust applies to the llvm codebase.
- aw1621107 6y ago
  For Rust's LLVM fork, sure. But as Steve Klabnik noted in the first comment I linked, unmodified LLVM is supported. In addition, later down in the comment chain: cycloptic: > Can't there be a build option to not use the LLVM submodule, and instead use the system LLVM? steveklabnik: > There is. We even test that it builds as part of our CI, to make sure it works, IIRC. For a more concrete example, Fedora supports choosing between system and bundled LLVM when building Rust [0, 1]. [0]: https://news.ycombinator.com/item?id=26222190 https://news.ycombinator.com/item?id=26222190 [1]: https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust...
  - deleted 6y ago
    [deleted]
zimmerfrei 6y ago
> 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 https://github.com/alex/rust-asn1 [2] https://github.com/pyca/cryptography/blob/main/src/rust/src/lib.rs https://github.com/pyca/cryptography/blob/main/src/rust/src/... [3] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/include/internal/constant_time.h#L120 https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/inclu...
- steveklabnik 6y ago
  > 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.
  - zimmerfrei 6y ago
    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.

ploxiln 6y ago

>> Strongly prefer to upstream all patches to LLVM before including them in rustc. > That is, this is already the case. We don't like maintaining a fork. We try to upstream as much as we can. > But, at the same time, even when you do this, it takes tons of time. A contributor was talking about exactly this on Twitter earlier today, and estimated that, even if the patch was written and accepted as fast as possible, it would still take roughly a year for that patch to make it into the release used by Rust. This is the opposite side of the whole "move slow and only use old versions of things" tradeoff: that would take even longer to get into, say, the LLVM in Debian stable, as suggested in another comment chain. > So our approach is, upstream the patches, keep them in our fork, and then remove them when they inevitably make it back downstream. ... so there are always some outstanding patches rust applies to the llvm codebase.

aw1621107 6y ago
For Rust's LLVM fork, sure. But as Steve Klabnik noted in the first comment I linked, unmodified LLVM is supported. In addition, later down in the comment chain: cycloptic: > Can't there be a build option to not use the LLVM submodule, and instead use the system LLVM? steveklabnik: > There is. We even test that it builds as part of our CI, to make sure it works, IIRC. For a more concrete example, Fedora supports choosing between system and bundled LLVM when building Rust [0, 1]. [0]: https://news.ycombinator.com/item?id=26222190 https://news.ycombinator.com/item?id=26222190 [1]: https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust...
- deleted 6y ago
  [deleted]

zimmerfrei 6y ago

> 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 https://github.com/alex/rust-asn1 [2] https://github.com/pyca/cryptography/blob/main/src/rust/src/lib.rs https://github.com/pyca/cryptography/blob/main/src/rust/src/... [3] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/include/internal/constant_time.h#L120 https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/inclu...

steveklabnik 6y ago
> 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.
- zimmerfrei 6y ago
  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.