A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…
Rust’s dependencies are starting to worry me
131–140 of 593 posts
Re: Rust’s dependencies are starting to worry me
#132A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…
Java and the .NET Framework had partial trust/capabilities mechanisms decades ago. No one really used them and they were deprecated/removed.
Re: Rust’s dependencies are starting to worry me
#133A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…
Is there anything in existence which has a version of this idea? It makes a ton of sense to me, but you are right that it would be practically impossible to do in a current language.
Re: Rust’s dependencies are starting to worry me
#134IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…
https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Re: Rust’s dependencies are starting to worry me
#135Earlier quoted context omitted.
Best way is to have CI/CD systems only connected to the official internal repos. Devs can add whatever they feel like on their workstations but it will be a sad build server if they get pushed without permission.
> Devs can add whatever they feel like on their workstations A compromised dev machine is also a problem.
Re: Rust’s dependencies are starting to worry me
#136In the past (not in Rust, but other languages), for important systems, I've instituted policies of minimizing dependencies from these language-specific package repositories, and for the ones you do use, having to copy it to our own repos and audit each update before use. But that's not practical for all situations. For example, Web frontend developer culture might be the worst environment, to the point you often can'…
The cool thing about rust is you can implement async yourself. You aren't tied to any specific implementation.
Re: Rust’s dependencies are starting to worry me
#137Earlier quoted context omitted.
Because most dependencies are either manually installed by the user, or are dynamic libraries that are provided and audited by the distro maintainers. The dependencies are there, they're just harder to see - https://wiki.alopex.li/LetsBeRealAboutDependencies
Sure, there are various dependencies, but it's nothing like "cargo install crate-name". Cargo makes it so effortless to joink the dumbest dependency for the simplest thing.
Re: Rust’s dependencies are starting to worry me
#138Re: Rust’s dependencies are starting to worry me
#139IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos. This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painsta…
> Go and Rust, for example, encourage everything for a single package/mod to go in the same file. Clarification: Go allows for a very simple multi-file. It’s one feature I really like, because it allows splitting otherwise coherent module into logical parts.
Historically Rust wanted that foo.rs to be renamed foo/mod.rs but that's no longer idiomatic although of course it still works if you do that.
Re: Rust’s dependencies are starting to worry me
#140> dotenv is unmaintained. How much maintenance could you possibly need to load secrets from .env into the environment.
The maintainers themselves give this warning in the repo's README, so even if it were maintained, it still wouldn't be production ready. > Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged! https://github.com/dotenv-rs/dotenv