I wonder how to best describe how #RustLang influences design, for better or worse. Here is some rambling...
It makes you avoid cyclical data structures, and you are far more aware of ownership. This makes surprising action at a distance harder. It also makes it more difficult to misuse globals or struct fields as globals just to pass data along to where it is needed no matter how.
Enums turn out to replace dynamic dispatch very often. Inheritance is just gone.
That’s often what #rustlang feels like. I started learning C in the late 80s and BASIC before that. Since then I’ve become an expert in several languages and proficient in several others. I’m an experienced #polyglot and though the rust compiler is by far the most helpful - and pushing other compilers to improve - there’s a lot of sharp edges in the grammar itself. Some other polyglots I’m getting into the language agree.
"cargo-buttplug: ensuring positive reinforcement during long, tiring code sessions". Yup, you guessed it right: 10 seconds of vibration if Rust compilation is successful 😅 Be careful: as you become fluent with the language compilation succeeds more often 🤣 #RustLanghttps://github.com/vmfunc/cargo-buttplug
say what you will about how "bloated" web platform-based desktop applications are, the web is still probably the most flexible and accessibility-minded toolkit for building GUIs out there. And as cool as it sounds to "just" write your UI in immediate-mode #Rust#RustLang, you're throwing away a LOT.
Super exciting to have the bandwidth to start putting my plans into motion. I decided that I want to do a daily status update in engine-dev, and let folks track my current areas of focus using a GitHub project board.
This was a really good summary of what Rust feels like in my opinion. I'm still a beginner myself but I recognize what this article is saying very much....
@kaffiene@asdfasdfasdf Its slow when you dont know what youŕe doing. For example, build a linked list in #rustlang is different then build one in java, because you can´t leave the variables in a wrong state. It's only a different approach, not a slow approach.
Auditing your dependencies, or relying on external audits, adds an important layer of protection.
It's not a silver bullet against bad dependencies as there's no such thing. However adding more layers of protection makes attackers' lives harder and this is one of them.
If #xz were a Go or Rust dependency, you wouldn’t have a single copy of xz library on your system, but many, #xzbackdoor hidden in every executable that uses it. Distros would have to rebuild all packages using that lib (not just the lib itself), which could take days or weeks, and users would have to update them all, downloading tens or hundreds of megabytes.
If you install binaries directly from vendors/devs, it’s even worse – you wouldn’t even know which ones are affected and you’d (1/3)
Now do you see the value of #Linux distros and dynamic linking? Please, stop this insane “single binary” mantra and work with distros, not against them.
If #rustlang wants to replace C, devs need to acknowledge this and start providing dynamically linkable libraries with stable ABI. (3/3)
My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. https://boehs.org/node/everything-i-know-about-the-xz-backdoor for a good timeline):
This is going to be an excellent teaching example for advanced supply chain attacks that I will definitely be using in the future - after much more in-depth analysis.
It seems to have been a long game, executed with an impressive sequence of steps and preparation, including e.g. disabling OSSFuzz checks for the particular code path and pressuring the original maintainer into accepting the (malicious) contributions.
Given the luck involved in this case, we need to assume a number of other, currently unknown supply chain backdoors that were successfully deployed with comparable sophistication and are probably active in the field.
Safe(r) languages like #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C++ for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner and automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian#OpenPGP#web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
Heya! I'm in need of a new job. My current gig is contract based, which I don't see as a sustainable option going forward.
I'm a software developer based in Pennsylvania. I enjoy taking on complex problems and finding solutions to them, especially close to the hardware. I've been teaching myself to code for about nine years now, gaining experience in a myriad of technologies.
So, if anyone is in need of a developer with extensive experience in Rust, C/C++, CI/CD, or webdev, please reach out!
I can be reached via email at julia AT insertdomain DOT name.
@BrodieOnLinux The pinned comment on your video is the good old "skill issue" argument. It completely ignores statistics and reports from the industry, here is one from Google:
Give @julian#Github comment some good reactions to show the folks of the #W3C Federated Identity CG that there's more than #BigTech#identity providers to take into account..
#rustlang is coming into @thunderbird now too! I loved Thunderbird back in the day but--as acknowledged in this talk--it has fallen behind its competitors over time. Excited to see it gaining ground again!
If someone wants a really cool rust project, port the algorithms in https://github.com/Facebook/ThreatExchange to rust, or write performant Node.js & Ruby bindings for them
Leaving Rust gamedev after 3 years ( loglog.games )
This was a really good summary of what Rust feels like in my opinion. I'm still a beginner myself but I recognize what this article is saying very much....