3 ms·

This is Fine

58 points by behnamoh 3y ago

justinsaccount 3y ago
This is from the python-cryptography package: https://cryptography.io/en/latest/faq/#why-does-cryptography-require-rust https://cryptography.io/en/latest/faq/#why-does-cryptography...
- dehrmann 3y ago
  Is there a C replacement language that's lightweight and provides just enough guardrails to avoid buffer overflows? Or some sort of static analysis on top of modern C++ that can give you Rust-like safety?
  - nneonneo 3y ago
    People have been developing “safer” C/C++ extensions for literally decades. Very few of them have caught on, and those that did are usually in niche applications. Rust is the best shot at a safe C/C++ replacement language. Buffer overflows should be relatively easy to avoid in modern code, but some C programmers insist on doing handrolled calculations for buffer sizes that wind up being wrong (the WebP vuln was a great example of this), and not having buffer length checks because they assume their calculations are right (it’s faster!). But buffer overflows are a small part of the vulnerability space. For instance, memory allocation bugs, like double free/use-after-free are much more insidious with large codebases, and harder to detect due to problems like unclear or undocumented ownership. C doesn’t provide any mechanism for communicating ownership or lifetime information for all but the simplest objects, leaving this up to the programmer to manage.
thelastparadise 3y ago
Yikes. TBH, I'd much rather have the regular 1-package C dependency, warts and all.
pas 3y ago
Obviously this means it's time for RPython. Also, considering this is a mac, with known CPU and kernel and whatnot, why is this built from source?
throw0101b 3y ago
People wonder why I like using the shell-based ACME client like dehydrated (or acme.sh): * https://packages.debian.org/search?keywords=dehydrated https://packages.debian.org/search?keywords=dehydrated * https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh Versus the official client certbot: * https://packages.debian.org/search?keywords=python3-certbot https://packages.debian.org/search?keywords=python3-certbot A kludgy as very long shell scripts are (thought to be), I probably have a better chance of being able to go through all the that code and understand it than a dozen(+) Python libraries. And if there's an update/s, a diff of one shell script easier to parse than multiple libraries that may be updated.
jiggawatts 3y ago
To the people that like to make the argument that it’s the developers’ individual responsibility to regularly check their dependencies and transient dependencies… … explain to me how many hours per month you dedicate to this task yourself. Now go look at this list. This isn’t even “code”, it’s a utility. Tell me again how “this is fine”. Large standard libraries exist for a reason, and this is it: so that we can have one dependency instead of thousands. So that reviewing non-standard dependencies is tractable. So that upgrades don’t break because of NP-complex rules violations even computers can’t resolve let alone humans.
- nneonneo 3y ago
  This isn’t a great article, tbh. Most of the complexity is from compiling the Rust compiler (and its “large standard library”) from source. Of course that’s going to be a complicated affair, because a production-quality compiler is not a simple bit of code. Normally this would just be a binary package, but it looks like MacPorts didn’t have said package for the author’s platform at the time. Second, the upgrade didn’t fail at all. The author has misinterpreted the log. This is understandable given the wording (“Unable to uninstall…Uninstall forced”), but all it’s saying is that it is forcibly uninstalling a package that’s being depended on, because the depending package is also being upgraded. The upgrade process completes fully, despite taking a very long time.
  - Bogdanp 3y ago
    I would agree with you had I (the author) intentionally wanted to install Rust, but I didn’t. This was a Python dependency randomly bringing all of Rust along with it and that is insane no matter how you slice it.
    - jiggawatts 3y ago
      My real-world example of this is that the ASP.NET Session State module for SQL Server pulls in basically half of the Azure client libraries… in case you’re using Azure SQL with Azure Entra identity authentication. Don’t use those things? Tough! Your 500 kB web app now has 500 MB of dependencies shovelled into it whether you like it or not.
ChrisArchitect 3y ago
(2022)
GorsyGentle 3y ago
I ran into this on FreeBSD when cryptography started using a rust core for its work. Suddenly my jails needed a full rust build environment just to install this one package. It was a frustrating day. Every time I upgrade that jail/venv I cry a little inside.
nneonneo 3y ago
To be completely clear: most of the long install process and crazy list of crate dependencies is due to building the Rust compiler toolchain and Cargo tool from source, which MacPorts does when it cannot find corresponding binary packages. As far as I can tell, MacPorts is now shipping binary packages for the latest version of Rust (https://packages.macports.org/rust/ https://packages.macports.org/rust/), so this issue probably won’t crop up for most users. It’s likely that a package for the latest Rust wasn’t available at the time the post was made (or in any case, not for Darwin 22 on ARM64).

58 points by behnamoh 3y ago

This is from the python-cryptography package: https://cryptography.io/en/latest/faq/#why-does-cryptography-require-rust https://cryptography.io/en/latest/faq/#why-does-cryptography...

dehrmann 3y ago
Is there a C replacement language that's lightweight and provides just enough guardrails to avoid buffer overflows? Or some sort of static analysis on top of modern C++ that can give you Rust-like safety?
- nneonneo 3y ago
  People have been developing “safer” C/C++ extensions for literally decades. Very few of them have caught on, and those that did are usually in niche applications. Rust is the best shot at a safe C/C++ replacement language. Buffer overflows should be relatively easy to avoid in modern code, but some C programmers insist on doing handrolled calculations for buffer sizes that wind up being wrong (the WebP vuln was a great example of this), and not having buffer length checks because they assume their calculations are right (it’s faster!). But buffer overflows are a small part of the vulnerability space. For instance, memory allocation bugs, like double free/use-after-free are much more insidious with large codebases, and harder to detect due to problems like unclear or undocumented ownership. C doesn’t provide any mechanism for communicating ownership or lifetime information for all but the simplest objects, leaving this up to the programmer to manage.

thelastparadise 3y ago

Yikes. TBH, I'd much rather have the regular 1-package C dependency, warts and all.

pas 3y ago

Obviously this means it's time for RPython. Also, considering this is a mac, with known CPU and kernel and whatnot, why is this built from source?

throw0101b 3y ago

People wonder why I like using the shell-based ACME client like dehydrated (or acme.sh): * https://packages.debian.org/search?keywords=dehydrated https://packages.debian.org/search?keywords=dehydrated * https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh Versus the official client certbot: * https://packages.debian.org/search?keywords=python3-certbot https://packages.debian.org/search?keywords=python3-certbot A kludgy as very long shell scripts are (thought to be), I probably have a better chance of being able to go through all the that code and understand it than a dozen(+) Python libraries. And if there's an update/s, a diff of one shell script easier to parse than multiple libraries that may be updated.

jiggawatts 3y ago

To the people that like to make the argument that it’s the developers’ individual responsibility to regularly check their dependencies and transient dependencies… … explain to me how many hours per month you dedicate to this task yourself. Now go look at this list. This isn’t even “code”, it’s a utility. Tell me again how “this is fine”. Large standard libraries exist for a reason, and this is it: so that we can have one dependency instead of thousands. So that reviewing non-standard dependencies is tractable. So that upgrades don’t break because of NP-complex rules violations even computers can’t resolve let alone humans.

nneonneo 3y ago
This isn’t a great article, tbh. Most of the complexity is from compiling the Rust compiler (and its “large standard library”) from source. Of course that’s going to be a complicated affair, because a production-quality compiler is not a simple bit of code. Normally this would just be a binary package, but it looks like MacPorts didn’t have said package for the author’s platform at the time. Second, the upgrade didn’t fail at all. The author has misinterpreted the log. This is understandable given the wording (“Unable to uninstall…Uninstall forced”), but all it’s saying is that it is forcibly uninstalling a package that’s being depended on, because the depending package is also being upgraded. The upgrade process completes fully, despite taking a very long time.
- Bogdanp 3y ago
  I would agree with you had I (the author) intentionally wanted to install Rust, but I didn’t. This was a Python dependency randomly bringing all of Rust along with it and that is insane no matter how you slice it.
  - jiggawatts 3y ago
    My real-world example of this is that the ASP.NET Session State module for SQL Server pulls in basically half of the Azure client libraries… in case you’re using Azure SQL with Azure Entra identity authentication. Don’t use those things? Tough! Your 500 kB web app now has 500 MB of dependencies shovelled into it whether you like it or not.

ChrisArchitect 3y ago

(2022)

GorsyGentle 3y ago

I ran into this on FreeBSD when cryptography started using a rust core for its work. Suddenly my jails needed a full rust build environment just to install this one package. It was a frustrating day. Every time I upgrade that jail/venv I cry a little inside.

nneonneo 3y ago

To be completely clear: most of the long install process and crazy list of crate dependencies is due to building the Rust compiler toolchain and Cargo tool from source, which MacPorts does when it cannot find corresponding binary packages. As far as I can tell, MacPorts is now shipping binary packages for the latest version of Rust (https://packages.macports.org/rust/ https://packages.macports.org/rust/), so this issue probably won’t crop up for most users. It’s likely that a package for the latest Rust wasn’t available at the time the post was made (or in any case, not for Darwin 22 on ARM64).