On the "critical infrastructure" front, I'd like to see a few "hard nuts" built. Not many. Just a few special purpose boxes, to start:
- A BGP server.
- A DNS/DNSSEC server.
- A WiFi/home network gateway.
Those are critical infrastructure. They're self-contained units which talk well-defined protocols. Their functions don't change much. The first two aren't that price-sensitive. They should be verified down to the bare metal.
Apply to DARPA or NIST or DHS for funding for such a project. You might get it.
We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!
I get why BGP sounds like a good target, since it's self-contained and high-importance, but I'd assume the most important BGP4 deployments on the Internet aren't in systems that can replace their BGP4 servers with anything that Cisco isn't itself shipping. Lots of people run little `birds` to advise their upstreams, but they're not running full-feed defaultless; they're minimally exposed. I think the win from a community-driven BGP4 project might be small compared to the investment. But you've been thinking about this already, so I'd love to hear about how wrong I am. :)
What you are describing matches my impression of things. It has been on the back burner because even if we had a great memory safe version of, say, openbgpd, I am not sure that would have particularly widespread impact. You are probably right that we would need to convince Cisco and friends to move to memory safe code.
we would need to convince Cisco and friends to move to memory safe code.
For BGP and DNS, probably. But a few big buyers pushing on that might get it.
An all-Rust home router with WiFi, cable, fiber. and DSL would be useful. The trouble is, if it's written by open source people, it will have zillions of versions and be configured by editing a text file.
A bigger problem would probably be that consumer routers are built as quickly and as cheaply as possible. Every megabyte of additional storage costs cents on the dollar extra and even that gets shaved off if possible. All the router security research I've seen done by well-intending academics got turned away by manufacturers because they don't want to ship additional software in their already-constrained images.
Rust, on the other hand, has all the downsides of static compilation combined with the library bloat we see in nodejs.
For a home router to run Rust, you'd probably need to compile the entire router into a single firmware image doing everything or you'd need to build an extensive dynamic linking system on top of the existing Rust infrastructure. Or, alternatively, convince the router manufacturers to spend another dollar or two on their EEPROM, but good luck getting them to do that.
Finally, the core parts of the system (the drivers running the DSL/cable/fiber/wifi hardware) are all closed source blobs that the manufacturers (be it Broadcom, Intel, Cisco, or Qualcom) need you to load and execute, usually written in a language like C with none of the benefits of Rust. Unless you want to rewrite the drivers in Rust (and good luck to you reverse engineering all of those and fighting the cease and desist letters you receive), the core parts of the system are still vulnerable as all hell.
The configuration can be made reasonably simple; OpenWRT has a GUI that can easily be dumbed down enough so normal folk can use it. Even in consumer routers, a lot of configuration is still dumped to text files already, anyway.
Rust can work with dynamically linked code. It's just limited to the C ABI in most cases because Rust itself doesn't have an ABI that's stable across compiler versions.
Many Chinese companies are building their own authoritative NS based on code from miekg/dns :)
Writing one importing that library is really simple, we should do it more often in the West too.
Right, I just ported our Rust DNS server (built with the equally excellent NLNet crate) to miekg/dns. It's great. But people tend to be writing "interesting" DNS servers, which is not the thing you actually need if you're trying to get rid of BIND and nsd; you need stuff that behaves exactly like BIND and nsd, just minus the memory corruption.
Big Internet BGP servers also aren't super exposed due to the common use of TCP MD5 (RFC 2385) or TCP AO (RFC 5925). The userspace daemon won't even see packets from attackers who don't have the shared secret for that peer link.
It cannot be that they do all the marketing sales speech about about Azure Sphere is the future of security in IoT devices, and then offer a C only SDK as option.
They even went to the effort to try to turn this into a positive thing, when the obvious questions started raining on them, given the marketing sales pitch.
For the home router? What becomes Rust? The DNS/NTP/DHCP stuff? That is some mature code, is it really a problem? Or those web-interfaces to set your WiFi passwords? Wouldn't you still use iptables/ipset for blocking/routing? Or do you rewrite kernel modules too?
This doesn't deserve the downmods; when one assumes good faith all we have here is a straightforward question.
Here is the answer; When you wish to provide a library that you intend for use in diverse applications[1] -- and OpenSSL is a excellent example of exactly this case -- you cannot choose a language with a complex runtime. Go has a complex runtime. There is no getting around this; any non-trivial software implemented in Go will require a number of runtime facilities and accommodating that becomes a burden for the library user.
Rust has about the same runtime burden as C/C++. It links the same way as C/C++ and imposes the minimum possible burden on the library user.
[1] diverse as in essentially all platforms, from microcontrollers to high performance systems at scale, over decades of evolution.
Go's TLS is the right choice if you're working on a project that uses Go. Go is often a good choice if you're rewriting a whole project to be memory-safe. But if you're retaining a lot of your C/C++ code, and trying to surgically replace the attack-surfacey bits with memory-safe code, that's Rust's job, not Go's.
C -> Go FFI is a lot harder. Per their website, they are a big on a modular approach where libraries can be made memory safe concurrently.
Languages with non-trivial runtimes like Go or Haskell just don't support that same model. You would want to convert your libraries in a certain order so there is one continuous C vs non-C boundary.
I would guess because Go, having a garbage collector and green threads, has a heavier runtime than Rust and is therefore harder to embed into programs written primarily in other languages. Can anyone else speak more authoritatively on this?
Because these people are Rust partisans, who are hiding behind generalized language and confusing "About" pages to push their partisanship under the guise of benevolence, since shaming everyone who disagreed with them backfired.
They have more information on their website about how to give them money than they do about who they actually are. This makes it easier to route cash to rewrite-it-in-Rust efforts without having to defend these decisions.
Finishing Firefox oxidation[1] should become a priority too. Also, combining all separate modern alternatives[2] to coreutils and such in Rust, like exa, dust, etc into one umbrella project.
I love that Rust has become a successful systems language with memory safety. And while I use many of these "coreutils replacements" frequently, they are mostly not equivalent to the originals, and I think it's disingenuous to claim that they are.
They aren't drop-in replacements, but I think "equivalents" is fair.
Your existing bash scripts don't work in an alternate universe where computers come with ripgrep not grep, but that universe isn't very different otherwise. Some things are a little easier to do, some things are a little harder to do, there are different bugs than in our universe, but it's way less strange than a universe where Lisp Machines still dominate, or even one where the Network uses X.25 rather than IP.
I don’t understand this at all. MISRA C, model checkers and theorem provers all exist to provide some of these guarantees that are, to my knowledge, widely recognized in applications where “safety” actually entails life safety. F* is a very modern tool, I think, developed for precisely these use cases. I’m not aware that the rust compiler is proven or even specified. Avoiding its mechanisms for validating use-once memory isn’t even that uncommon, especially in low-level library code.
That Google is the man behind the curtain here also comes off as weird since they have not, to my knowledge, standardized their own critical infrastructure on Rust.
> MISRA C, model checkers and theorem provers all exist to provide some of these guarantees that are, to my knowledge, widely recognized in applications where “safety” actually entails life safety.
So, where do I get the version of curl or similar that in fact provides "some of these guarantees" ? Because ISRG isn't spending money on developing software for the Ford Bronco or US aircraft carriers, it is spending money on curl.
MISRA C like a long list of other projects for C or C++ including Bjarne's "Core Guidelines", goes like this:
1. Classify things people will end up needing to do as sinful.
2. Offer them a mechanism to obtain an indulgence, knowing this mechanism will quickly be exhausted.
3. When inevitably this results in tragedy point back at item (1) which absolves you of responsibility.
Example #1, MISRA says you mustn't have any unreachable code. Of course deciding whether code is actually reachable requires solving the Halting Problem, so your automated tooling doesn't do that and will either just flag code that might or might not really be unreachable (useless noise that reduces development velocity) or ignore MIRSA here and just leave your programmers to try not to do this, the status quo ante.
MISRA often needs to dish out "permits" to violate their guidelines because, in practice, the guidelines are too strict to be usable and somebody's workplace requires the guidelines so... the alternative is incredibly creaky and likely unsafe code that's "compliant" - or a "permit" to just ignore a guideline. This is most common when the language doesn't provide a sane way to do something.
Example #2, MISRA forbids hiding variables. If the inner scope has a variable named 'counter' and so does the outer scope, programmers are likely to get confused and mean one when the other is actually in scope, the language compiler won't stop this. But MISRA has to issue a permit because C macros routinely do this and so if your static analysis tool looks at the code it sees lots of such re-use that was (hopefully) harmless.
But if you have hygienic macros (Rust declarative macros) then this isn't a problem, the hygienic macro can't accidentally shadow variables. So you don't need these acrobatics in Rust, if you want to ban shadowing, you can do that and not have weird knock-on effects in macros.
Example #3 MISRA forbids invariants from appearing as conditionals. MISRA reasons that you couldn't possibly have meant to check that buffer != NULL because you know you set buffer in the constructor, and so this is a coding error. But of course you wrote that because you're worried that a bug elsewhere might null out the buffer and blow up the whole system... So now your static analysis tool is screaming that your defensive coding violate MISRA. Do you go ask the Boss for authority to ignore this rule? Or do you rip out the defensive checks?
Tools like F* and WUFFS are different because they've intentionally set their sights low. If you say you want to write the software for your Jet Fighter in WUFFS its authors will carefully explain that this can't be done, and they don't want to help you try. They solve small, well-specified problems in a constrained problem space. They do it very well, you should use them when they're appropriate. They can't be used to replace curl.
MISRA C is just a standard and developing a codebase in it can still result in memory safety issues. Rust has the guarantees built into the compiler, so if it compiles you have a reasonable standard of memory safety.
You would have to sanitize your entire dependency tree for unsafe invocations and also demonstrate that valid rust programs do, in fact, guarantee memory safety, which might be invalidated by previous or future compiler versions. That also ignores known soundness holes, compiler errors, and silliness like how rust binaries leak the file structure they were built on. I don’t see why that’s reasonable, but auto industry standards are not reasonable or a language with a garbage collector is not reasonable. The work happening in model checking is really incredible. Project Everest is focused on addressing exactly the same problems, and I don’t think the rust compilers guarantees have undergone nearly the rigor of that of F*.
Firstly, for any of the 4 projects that have been announced by Prossimo so far, a garbage collected language would be unsuitable as it would be rejected by almost all current users of the respective projects.
Given that, as you correctly point out there are still lots of options that could be used; for example, Ada/SPARK has been around and freely available via GNAT for a long time.
Latest download is 5 years old - can you find a single instance of IRONSIDES running in the wild?
IMHO the main advantage that Rust has over other approaches that would technically work to create sufficiently secure software is that it has much lower barriers to entry and a much larger community - the hardest part of getting a technology adopted is marketing, and Rust is currently the only option that can compete with C/C++ here.
> That also ignores known soundness holes, compiler errors, and silliness like how rust binaries leak the file structure they were built on
All these issues I've encountered, or heard of, while working on MISRA-compliant code which is expected to run in cars for years without updates. We make do with C, and extensive tests + ASAN/UBSAN/TSAN can take us a long way, but my point is that Rust is a nice incremental step compared to C. I'm not excluding F* from the list of nice incremental steps, and if the developer ecosystem is there maybe that is a compelling option.
My other point is that MISRA C helps enforce standards in some of the nasty codebases that run in cars, and trust me they can be scary, but it is only a band-aid and I believe that Rust is generations ahead of it.
> but auto industry standards are not reasonable or a language with a garbage collector is not reasonable.
We avoided garbage collection because the run-time is harder to predict, and at the same time Java/Android is used a lot in the infotainment units which are now also running some safety-critical code - with a back-up computer thank you standards - and it makes it harder to allocate resources on the embedded system accordingly.
I will admit I'm all for Rust and will likely try to seek out jobs which I get to use it in.
That is reasonable. Rust is not the only safe option.
Re everything else....Rust should be seen as the beginning not the end. All those model checking and other "post-hoc" analyses come with major productivity pitfalls. (Wrestling with some solver that may or may not be happy for spooky reasons is profoundly disheartening compared to wrestling with something elegant and compositional like a type system.
Just as there is the ML family of languages and then SML with CakeML, Rust should continue being a fast-moving target where the occasional mistake might happen, but there is academic work revolving around the language which should create a CompCert/CakeML with time.
Some aviation/auto software regulation is a legit, but frankly a some of it doubles as regularity ossification the industry secretly like as it creates a mote around existing businesses that have "evolved" compliance from the get-go. In that case, unproductivity is a feature, not a bug.
I would not hold it up as a realistic model for these sorts of projects to aspire to. Without drastic changes to the way we found unprofitable FOSS foundation infrastructure, whenever productivity and security are at odds, the former will win over the latter.
Using a mode checker on existing software is unproductive, but rewriting existing, working software that you have to shoehorn into a shape rustc (which had a miscompilation bug until 1.52.1, has no specifications or alternative implementations, right?) will compile is productive? Rust’s type system is elegant, but Agda, OCaml F#, F* and Haskell, which are in a whole different league of sophistication, are not? Furthermore, I’m not aware of any progress in “sealed rust” or “rust belt” other than raising grant money. I don’t think a certification is coming anytime soon. There are other verified compilers that could be used now, though.
> Using a mode checker on existing software is unproductive, but rewriting existing, working software that you have to shoehorn into a shape rustc .... will compile is productive?
The rewrite is a 1-time cost.
> Rust’s type system is elegant, but Agda, OCaml F#, F* and Haskell, which are in a whole different league of sophistication, are not?
I am primarily a Haskell user, and I already said I have nothing against GC. Those other languages (except for F#) are great!
> has no specifications or alternative implementations
That is a major downside (I work on GHC and wish it wasn't the only game in town) and affects all of those. That's why I put out SML and the CakeML implementation. SML lacks shiny new stuff but the grunt work has been done.
I would certainly use SML over any variant of C for anything that needs dynamic allocation.
All compilers have miscompilation bugs. Even ones that are proven correct.
> has no specifications or alternative implementations, right?
There is one alternative implementation that is good enough to bitwise reproduce rustc, there are a few other in-progress alternate implementations.
> I’m not aware of any progress in “sealed rust” or “rust belt”
That doesn't mean they haven't progressed. By the way, "Sealed Rust" is now called "Ferrocene" and is expected to GA in late 2022. https://ferrous-systems.com/ferrocene/
> There are other verified compilers that could be used now, though.
This is true, for sure. A compiler being verified is not a panacea.
The stated goal of the grant program is to rewrite stable software many people use in Rust with the implied context being that C can’t be trusted, but Rust can be. I’m surprised that a language with no specified guarantees is favored over well established methods of verification. When you poopoo formal methods and verified compilers, it’s very hard to find a coherent logic behind RIIR, which offers much less in terms of security.
Unless the exercise is a pretext to rationalize the grant money (which would be the real purpose).
The formal verification researchers I've worked with love Rust, because its type system nails the basics so they can focus on proving more interesting properties.
Rust and formal verification work really well together. You can formally verify properties in a small section of critical code, then use the type and lifetime systems to expand those properties to the whole codebase. It's not an either/or, it's a both/and.
All I keep seeing, is how rust is perfect for everything, will fix everything, should be everywhere, etc, etc. There's gotta be a profit motive involved. There must.
There is absolutely a profit motive involved! The less time you spend dealing with segfaults and inexplicable double-frees because you have no idea where the first free is, the more time you can spend working on features that impact the business's bottom line. The fewer emergency patches you have to deploy, the more uptime you have and the less you spend on the required ops work. The fewer zero-days you suffer, the fewer existential threats to your business. And so forth.
None of this would be happening if the market didn't care. I was one of the people who started the Linux kernel modules in Rust project (I'm credited in the announcement), but I started it because I thought it would be fun, and I have a day job that isn't related to Rust at all. So I've spent almost no time on it recently.
The corporate sponsors behind this effort are interested in this because they use Linux (and curl and so forth) at a large enough scale where this sort of thing matters. I would guess that, for instance, Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days (see e.g. https://googleprojectzero.blogspot.com/p/0day.html).
So that's their profit motive, and I'm very happy it exists, because this work is too important to rely on the free time of people like me.
(To be abundantly clear: I am not paid by any of the involved organizations, and I had no advance knowledge of this before the public announcement.)
> Google cares about getting Rust into Android's kernel because they want to credibly claim that Android has fewer zero-days than iOS, and they have a clear public agenda of wanting to get rid of zero-days
It is going to be very hard to achieve this when iOS is moving into the direction to have 100% of userspace API available to Swift, while Android team forces us to use C and C++ for anything related with real time audio, machine learning and 3D API.
Now in Android 12 even Renderscript was replaced with C and C++ alongside Vulkan compute shaders.
The kernel can even be 100% Rust, it won't help those of us that are cloning Oboe or Vulkan github repo, dealing with JNI boilerplate, C and C++ toolchain issues on NDK.
Well, Google probably doesn’t control all the C++ standards committees. I don’t know how much control they have over commit rights to the Rust compiler. Given Mozilla’s client-patron relationship with Google, then I’d guess it’s possible.
But, yeah, a company whose business model is tricking old people into buying junk and surveilling their users probably shouldn’t be implicitly trusted.
Google employs a few people who have a commit bit, but they are handed out via consensus among the whole team, not by a single company or its employees.
Right, and at one point the whole team were all or mostly Mozilla employees (which, financially, is a client company of Google). So the core team is a group of Mozilla alumni and their friends. Unlike, say, C++ which is under diverse committees across multiple countries.
Please keep unsubstantive comments and flamebait off HN. Programming language flamewars are particularly tedious and particularly avoidable, so please avoid them.
That made me laugh. Can people treat such people seriously when they obviously aren't?
Dumb, aggressive promotion is characteristic of "trendy hipster projects" usually abandoned once the "cred" harvest is finished, and people involved go on.
I used to advertise my worth in how good my C++ is. Until I had a dumb after free error after git merging two adjacent line in the wrong order. A simple vector push done after capturing vector.begin instead of before. Nobody saw that in code review. Even reviews from C++ experts at the company. Of course it took 6 months until the first segfault. Invalidating 6 months of work. Rust would have not compiled. As simple as that.
Now imagine if you could write code without living in fear of making everything blow up because of a single moment of weakness. That's Rust for me.
It’s just another of many testimonials of projects that will not be named at companies that will not be disclosed with implausible circumstances or unlikely details here to convince you that you had better switch your tech stack to this brand new thing before you too become a cautionary tale.
Google. Backup of filers. Conversion from NetApp filer dumps to tarball. I did open source a prototype of the tool. I don't know if it has the bug. The final version was to Google standard of C++ and maybe some cleaner abstractions. https://github.com/bombela/dump2tar
It would be funny if they couldn't cite an endless stream of evidence for their argument. They can, however.
And it's not going to stop. That's the thing about the memory safety argument; the people making it have an endless supply of ammunition, resupplied daily.
> TIL: That there's an ORG to effectively harass people like Daniel Stenberg to rewrite popular stuff in Rust.
This is both inflammatory and wrong. ISRG isn't harassing Stenberg; they're paying him to do the work they want done. And he's not rewriting curl or libcurl in Rust; he's adding optional new backends for key pieces like the HTTP and TLS implementations.
The comment is inflammatory and over-the-top, but I can definitely relate to the sentiment and comparison with fascism. For the software industry, "memory safety" is the new form of authoritarianism in disguise. No more jailbreaking, rooting, or running what you want on hardware you rightfully "bought". All in the name of "safety and security". They want to proclaim everything else to be "unsafe" to further their goals of total control.
As the infamous quote says, "Those who give up freedom for security deserve neither."
IMO a secure system with a developer mode switch is a better tradeoff than "please don't fix bugs because I need them to jailbreak". Unfortunately almost everybody is leaving out the developer mode switch.
Memory safety system programming languages exist since early 1960's and already by 1980 it was known that UNIX and C were a disservice to mankind, sadly profit and free beer OS was more appealing than security.
The only thing we are giving up is cowboy programming.
Isn't the authoritarianism in the fact that the hardware you buy doesn't let you just install your own firmware?
"Memory safety" has the word "safety" in it, but really it's just a tool to help developers avoid bugs. I want to be able to install whatever I like on my hardware, but I certainly don't want other people to be able to install whatever they want on my hardware.
Let me rephrase your comment:
“Saving people from suicides is come kind of fascism and authoritarianism - no more freedom to make decisions related to your own life.”
"Here's Daniel a guy who struggle to keep his open source project used by millions working in very important big tech projects. Despite the fact that big companies use its project, he mostly get funded by ordinary people who can pay a few bucks"
"But Daniels destiny is about to change, a ORG that funnels capital from big tech companies to make software more secure is about to give him a grant"
"Here Daniel, we have a grant so you can fix your security bugs"
"Oh great, now i can invest in more unit test and have people to fix them.. and.. "
"But you will only receive the money if you or someone we pay for write those parts in Rust"
While Daniel is being payed, this is not actually/only focusing on security as an end goal, but is using security as a pitch to rewrite popular software in Rust which in the end will probably have more bugs giving the older software were much more battle tested..
So we have people with foot on big tech collect money through an org to rewrite software in Rust and not to ACTUALLY help the people doing software with very low resources to fix their software.
Daniel is saying he will still keep doing it in C. So why do this org tried this approach giving i bet whatever you want that this money invested for them to focus on security even in C would make it have less bugs, because the real problem here is economics and less the language.
Its a pity that an ORG is being used as a facade to create implants of Rust in popular projects, instead of helping out open source developers with money that would probably reach them if they did not act as the middle man to those important projects.
See their goals here, is not even about security as a whole, but memory safety, and while they cite other languages, this is clearly biased towards Rust.
Please dear ORG take the money from big tech, invest part of it for new projects in Rust if you wish, but really help the open source maintainers to fix their security bugs in the technology they use. Note that you are receiving this money using their projects to receive the grants. Really help them make their software more secure.
If you are really into the Rust hype, so create a fork in Rust, show that you were right.. or at least be open when collect the money to invest what your real goals.
But its a pitty, a project like OpenSSL for instance wont see a dime of this money. So sorry if i dont feel happy about this..
Again, Stenberg himself seems to feel differently about what's going on than you do. From his blog post "What goes into curl?" [1]:
> I’m the lead developer of the curl project but I also offer commercial support and curl services to allow me to work on curl full-time. This means that paying customers can get a “priority lane” into landing new features or bug-fixes in future releases of curl. They still need to suit the project though, we don’t abandon our principles even for money.
> I don't believe in rewrites, no matter which language. I believe in replacing code and fixing components gradually over time. That could mean that we have a curl written mostly in rust in 10 years. Or in 20 years. Or not.
> We recognize the amount of work it will take to move significant portions of the Internet’s C and C++ software infrastructure to memory safe code, but the Internet will be around for a long time. There is time for ambitious efforts to pay off. By being smart about our initial investments, focusing on the most critical components, we can start seeing significant returns within 1-2 years.
> We encourage projects to replace libraries or modular functionality with memory safe libraries, rather than embark upon ground-up rewrites. This allows us to break up the work into manageable pieces and deliver value incrementally.
> Since many projects will end up using the same memory safe libraries, this approach also allows us to invest and build confidence in a particular set of libraries. Investments in a library for one project will add value across multiple projects. For example - the curl project will use the Hyper and Rustls libraries. The work we do to build excellent C API wrappers and improve the integration experience will help with many projects that will use the libraries in the future.
Yes exactly, it's an org that attempts to creates trojan horse implants into popular projects for gradual takeover and control of projects in the long term by the virtue of the amount of people working on it.
They should be more open about it, and stop using generic words like security and memory safety for the actual corruption of those values in the form of rewriting popular stuff in Rust (apparently Apple is making followers using the safe word 'security' like politicians use 'terror' to manipulate public opinion).
If it was really about security and memory safety, other memory safe languages would be among the projects and also attempts to fix memory safety issues in C and C++ would also receive grants.
What is inflammatory is the way a part of the Rust community deals with other languages.
You are right is not just ISRG, but it is part of this big masonry-like movement forming to replace C++, not by virtue, but by force and politics. Unlike any other language out there that is trying to do it in a clean manner.
Android for instance was the last asset with a takeover in this hostile manner, no other language out there ever did before. Despite we have tons of other safe memory languages out there.
I cheer for Rust the technology, to grow, but lets care about the language, because its not enough we work so hard to make things work, we still need to feel miserable, no matter the things you have done, because you are not using a pink t-shirt (one vector on a multivector of preferences and goals).
Is the end there is much more details into why we choose X and Y.
A lot of C and C++ code are out there, and with them a lot of great knowledge. man-years of work, of life into them.. they are wonderful pieces of engineering, and yet, just because they are "not written in the right language ™" it will force by culture and not by virtue that they get kicked off like garbage.
This is totally disrespectful, and most of the time is pure marketing and salesman pitch. Rust has yet to prove itself in a lot of fronts, and this will only happen with time.
I've seen Daniel being constantly bullied to feel miserable for having its tool in C, in Twitter, in mailing lists.. and he is just a sample..
To be blunt, the security of the software that runs so much of the world is way more important than the feelings of some programmers who feel that their beloved languages are under attack.
With ransomware and other online attacks on the rise, the stakes are too high to allow safer alternatives to be developed at a leisurely pace by volunteers. That's why ISRG is paying to have the work done, and why corporate projects like Android are putting financial resources into this as well. It's not a sinister attack on your favorite language, just an effort to make software more secure.
Getting back to something you said in your previous comment:
> you will take my C++ out of my dead cold hands.
Is this really the hill you want to die on? To me this suggests a lack of perspective on what really matters. A programming language is just a tool, not something to get attached to. When a better tool comes along, be open to using it when you can. Especially if someone pays you to do so. I used to be a big fan of both Python and Lua. Now I usually don't use them for new projects, though I may still if I think one of them is the right tool for the job.
> To be blunt, the security of the software that runs so much of the world is way more important than the feelings of some programmers who feel that their beloved languages are under attack.
As someone that have created software in at least 7 programming languages, including Rust, I agree with you, i only disagree with the recipe and the tactics used.
The bugs will happen, and contrary to the constant hammering sales pitch, Rust will not escape from them. Its like saying we are free from uncertainty. Its a false promise and anyone with real life experience in big software that are not neurotic about security like someone that only see software under this perspective would do.
Now, i believe Rust will likely have less bugs in the end? It depends most of the coder, but taking that variable out of the way, its more likely because its design is more strong into that direction.
Cant people fix security bugs once they happen? this will be the approach be it in Rust, C++.. Rust still will have to wrap insecure parts in unsafe{} blocks anyway, the same way a C++ coder do only that its not a keyword.
Im all for Rust having the right to tell its strenghts, i like the tech and what its offering, i can see why it can be better, but lets take care of the language used and the ideology behind our wording, its all i'm asking here..
Its time for the Rust community to grow up and stop pitching by shaming other languages, projects and communities, as if its the only reasonable answer like as if was some sort of master-race of programming languages and everything else should be replaced because its garbage.
This is not true, and while i like the tech, im worried about how a culture formed around bullying "inferior" languages will become with time.
The Rust community tries extremely hard not to shame other languages, projects, and communities. If you're talking about ideology, you will not see any ideology from the Rust project saying "This other language sucks." You'll just see "We're trying to build a high-quality technical product."
In fact, the Rust compiler itself depends heavily on LLVM (C++), Cargo fetches crates using libgit2 (C), rustup downloads updates using libcurl (C), Rust uses the C standard library (C) instead of directly making syscalls like Go/Zig/etc. do, memory allocation used to use jemalloc (C) until they switched to using the platform's C standard library for compatibility, etc. If there were any belief in the Rust community that other languages are garbage, those dependencies would have been replaced long ago.
If outsiders are saying that other languages are inferior, it is because they've examined the evidence and made up their minds, not because anyone is organizing a bullying campaign. Most of the people saying that do, in fact, have extensive "real life experience" with C and C++ and have come to their conclusions based on that experience.
Which is to say, I don't know any way that the Rust project could try harder to steer the language and ideology to be more respectful of other languages other than by making Rust a less compelling language.
I mean, I'm a fan of this project and happy about Rust's emerging role in the world, but that first sentence is obviously not true. Maybe they're trying harder lately.
It has been longstanding policy of the project itself to take this stance. That doesn’t mean that every single community member follows our example, though, or that everyone involved is perfect. But we made a deliberate decision to try and avoid this as much as possible.
I mean, come on. Are you on a bunch of Slacks? At least one of them has a :resf: emoji. It's not just random Rust users; there are people deeply involved in Rust itself that disparage other languages. Maybe that's gotten better recently, but, again, come on: look at the "About" section on this project --- which is a great project! --- and how it talks about C/C++. I happen to think Rust people are correct about C/C++, despite loving in my bones how it feels to write C code. But that doesn't mean I have to pretend that there's a real norm in the Rust community of respecting other languages.
To me, this whole thing about Rust and its decorum in language debates reminds me of those projects that don't have codes of conducts, but instead a "be excellent to each other" policy. I believe what you're saying is something the Rust project wants to be true. But that doesn't make it so!
I say this with love as someone looking forward to the next couple thousand lines of Rust I'm going to have to write at my job.
I'm not on basically any Slacks, no. "RESF" is a meme, and it's a meme for a reason. There is far more complaining about it than it actually existing. I actually got halfway to publishing a quantitative analysis on this...
What do you think is disrespectful about the about page? Maybe this is like, part of where we differ. Stating facts plainly, and talking about tradeoffs isn't disparaging. This is an engineering discussion. This isn't contempt culture. This isn't some sort of "JavaScript is shit and anyone that uses it is an idiot," which is an attitude that is a problem and is corrosive. The about page doesn't even say C and C++ are bad languages! It says that characteristics of them make it unsuitable for a specific kind of application, due to requirements that they believe are important. That's it.
And yes, I do believe that it is something that the project and project leadership wants to be true, that is less true the further you get away from the project itself. We do not have the power (nor the desire) to control what every single person says on the internet. It is about leading by example. We do not make language comparisons in official marketing or documentation, when people show up and are flamebait-y and disparaging of other languages, we tell them "hey we don't do that here" and ask them to cut it out. To me, this feels very, very different and better than a lot of language spaces. YMMV.
The page literally includes the words "Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers." This is not a good hill to die on.
The complaint isn't about the semantics, but about it furthering an image of the Rust community that's working against it when it comes to actually fixing this. Being "right" is less effective if you are being insufferable about it.
Actually it is the security community, Rust isn't alone on this endeavour.
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
C.A. Hoare stated on his Turing award speech done in 1981.
I can relate to other remarks or papers from memory safe systems programming all the way back to 1961, when Burroughs B5500 was released.
Yet many keep not paying attention, like Microsoft bosting 70% memory corruption issues on one side, while selling Azure Sphere security pitch having only C as available language, or bosting the use of C++ on WinUI, among many other examples.
70% of CVEs (bugs detected) being memory related does not mean that 70% of all software bugs are memory errors (bugs that exist). See survivors bias. Memory errors can be detected with the assistance of programs, so they are much easier to find than other bugs like logic errors, which require knowing what a program ought to do. I think the latter is much more insidious.
Sure, but not particularly relevant to how the Rust community is perceived. Well, maybe, if people think you are more insufferable about any topic than the infosec community, that is actually kind of impressive.
I think it is far too broad to be taken literally. I also think, regardless if it's true or not, it's phrased in too combative of a way to be actually useful. Even if one does believe that this is true in all cases, presenting it this way isn't likely to help achieve that goal, and thus, it's a terrible statement. Finally, talking like this about technologies tends to beget an attitude and culture that ends up being unable to evenhandedly evaluate engineering tradeoffs. This makes you miss certain advantages, even in new technologies you may not like overall, which means you can't take advantage of the good parts.
> With ransomware and other online attacks on the rise
Yeah we really need to show the world better defense is possible, or the US military, always hungry for mission creepy, is just going to subsidize critical infrastructure that should have never been private in the first place with free counter attacks or whatever.
The non-technical policy consensus is already "defense is hard", not "we're incredibly sloppy and we should be ashamed of ourselves", and so changing norms is really important and already an uphill battle that's just going to get harder.
You seem to like C++. Look at the C++ direction of travel. Lifetime annotation? Rust has it, Bjarne now wants it in C++. Volatile access? Rust has it as methods read_volatile and write_volatile, and C++ is moving away from "cv qualfier" towards that same approach. Modules? Rust has them. C++ is now getting them. Backwards compatibility? Rust has editions, C++ is trying to do epochs.
C++ has spent years trying to argue that "Good" C++ won't have all the terrible problems, and so far it just hasn't worked out that way. I think the backward compatibility nightmare will consume C++ faster than it can try to dig itself out.
Here's the biggest problem: The people who can't leave C++ for Rust are also most invested in the features that prevent C++ from evolving to compete with Rust. If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway, you'd be excited about a C++23 with lifetime annotation and epochs, but not so excited that you will throw effort at helping that to happen rather than Rust. Whereas if you're programming a specialist DSP and you're looking forward to getting C++ 17 next year when your vendor offers it, you can't move to Rust easily because there is no Rust for your DSP (yet?) but you also don't care about C++23 because your compiler vendor hasn't even announced a C++20 compiler yet.
> If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway...
No I won't, because the ecosystem that makes me reach out for C++ when not using either Java or .NET based languages doesn't exist for Rust.
Unreal/Unity class game tooling, CUDA/SYSCL class GPGPU programming, WinUI/QT/VCL class GUI frameworks, JUCE/openFrameworks/Cinder creative coding tools, LLVM/Gimple,...
So C++ with static analysers is still the way to go for those of us that don't care about building an ecosystem from scratch and rather focus on deliverables.
Just a correction: Im not implying that Rust have no virtues, it has a lot, and its a very strong candidate to write new projects into whenever you think you need C++.
I would and will consider Rust always, and it probably will make sense to use instead. If my former post implied that i dont like Rust, im correcting here, because i like it and i thinks its cool technology and that it have virtues C++ don't have.
I was saying that, specially now that the language is more mature theres a thriving community around it, it can go by virtue..
C++ is where it is now because of its "killer apps". OS's, Browser, Games, a great amount of complex software with millions of lines of code.
And they are not garbage that need to be replaced. Rust taking over by virtue will be by creating killer apps in it. Showing itself as a great replacement for projects that can also be coded in C++.
Security folks invested in Rust saying that all new code in Android will now be coded in Rust its not replacing by virtue as important things like domain knowledge and getting used to a tool is also very important, and it will probably go away. Security is just one thing that is important in a project, its not the only one. But of course if you let the security folks decide, other important aspects will not be taken into account (I tought it was a really bad move by the way, as other problems not linked to security will appear with time).
Nobody with influence agrees with this assessment. Without taking the bait on this "C++ software is garbage" stuff: there's general acceptance that some significant chunk of memory-unsafe software, particularly the stuff most exposed to attack, or that runs on the systems we're most concerned with being attacked, needs to be replaced with memory-safe alternatives.
It is simply not the case that Rust's only role is in "new killer apps". Replacing C++ code is part of the raison dêtre of Rust.
You knew this was a pointless dead argument the moment Linus Torvalds began entertaining Rust kernel modules. The debate is over. That doesn't mean --- regardless of what any website says --- that all C++ software is "garbage", or that anyone is going to pry C++ out of your cold, dead hands. But it does make arguing about whether the maintainer of curl should accept funds to replace some of their code with Rust tedious and unproductive.
There is, yet WinUI selling point is that it is written in C++, just like macOS DriverKit and Metal.
I am betting with you how Microsoft will tout the C++ trumpet on the Windows 11 Developer talks next week, despite their timid approach to Rust on some of their tools now.
So the marketing message goes something like this,
Microsoft Security Response Center puts out a guideline that states:
1 - Use .NET languages, Java, Go if you can afford a GC
2 - Adopt Rust otherwise
3 - If C++ must be used, take care and adopt C++ Core Guidelines
WinUI team,
"WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease."
I should also note that .NET is migrating their C++ code into C#, as they improved the language to add the features available on Sing# and System C#.
" In this release, we’ve continued, and even accelerated, the process of porting native implementations in the coreclr runtime from C/C++ to instead be normal C# managed code in System.Private.Corelib."
C++ force is too strong on WinDev, the very fact that Windows is the only mainstream OS that still doubles down on a C++ based GUI framework kind of proves it.
I am really curious if Windows 11 will finally be more like Apple and Google platforms, or keep going down this path of making certain APIs only available in C++, while forcing .NET devs to manually wrap them.
Force and politics are how you get shit done when people's minds are closed to virtue. Another example is the climate: we've had decades to solve the climate crisis voluntarily, and people did relatively nothing. Now it will take drastic measures to prevent the crisis from becoming a catastrophe, and believe me, governments WILL implement these measures to much hemming and hawing from the public, especially Americans. But it will happen because it has to, and the public twiddled their thumbs back when solutions were relatively easy.
Same with software. If you write critical infrastructure and are not actively involved in writing it in a memory-safe manner at the language level, then you are complicit in every hack that involves a buffer overflow, UAF, or other boondoggle inherent to C and C++ programming. C is the internal combustion engine of software: we've known about its dangers for decades but done nothing to fix it, and now the crisis has reached the point of catastrophe and we have to use coercion or shame in order to fix it.
Very tangential, but the very slight angle on the “Memory Safety” highlight threw me for a loop. For a moment I wasn’t sure if it was actually slanted or not until I zoomed way in to confirm the slant.
That’s distracting as heck and I can’t think of a good reason to have such a weird highlight…
Eh, memory safety hasn't ever really been the problem with mod_tls, or curl, but it would be nice to have some solid examples for other projects to build on.
The Linux kernel project sounds interesting. It would be nice if there was an effort to purge as much C code as possible from the core of the kernel and really enforce standards such that even a maliciously designed kernel module should not be vulnerable to memory corruption bugs.
Here[1] is the ongoing list of "curl security problems." Note the several memory safety related issues. The two most recent are:
May 26, 2021 CWE-416: Use After Free
May 26, 2021 CWE-457: Use of Uninitialized Variable
There are numerous others that follow including out-of-bounds reads, overflows, etc. I can't imagine where you got the idea that this somehow "hasn't ever really been" a problem for curl.
Memory safety hasn't been a problem with mod_tls because mod_tls is the module written in Rust.
But likely you were thinking of mod_ssl. Except, mod_ssl is how Apache ends up using OpenSSL, where the famous Heartbleed bug is literally exactly the sort of memory unsafety that you'd never do in Rust.
Why not have all this Rust energy focused on a new kernel (not a toy/experiment), a kernel architect ed not evolved.
You would get better results and if you need Linux compatibility add support for it from the start in soem kind of emulation/compatibility layer.
Putting Rust into kernel seems to me that is a lot of effor for microscopic gains.
Because ISRG is trying to direct funds to projects that will actually protect current Internet users; notably, this isn't a research project, but rather a funded engineering project, focusing on things that are already in wide use.
I know, but Linux will not be forever, someone will start a new kernel that will replace it. All this giant tech companies could afford to pay some experienced people to start working on it. The initial scope would be limited but if the architecture and the language combo would give it a performance and security boost then for sure it will be adopted and new contributors would appear. If the performance/security would be similar to Linux/BSD then for sure the progress would be very slow.
Linux is thirty years old. And Linux isn't something from whole cloth, it's a Unix, it didn't have some legal and technical baggage that UNIX® brand Unix had but it's a Unix. And Unix is over sixty years old.
We may very well be done. Unix isn't the best conceivable Operating System, but it seems like it's good enough, and in being good enough it became so enormously popular that any new alternative has to be night-and-day better or why bother?
I'm reminded of the Two's Complement Integer thing. Historically it was unclear if this was the "best" way for integers to work. Hardware existed, and sold well decades ago, with some other ideas for how integers could be represented and calculated. But, gradually, over time, even if Two's Complement wasn't clearly the best, it was clearly the most popular, and the others weren't clearly better so why fight it? Sure enough, "Two's Complement Integers" get to just be how integers work by default in newer languages.
If Linus and all the subsystems people were screaming "Nothing but C, under any circumstances" then perhaps you could imagine a competitor to Linux comes along in ten, twenty, thirty years. But so long as they remain open to changes that actually have good results, they're going to stay on top.
Li et al., "An Incremental Path Towards a Safer OS Kernel," HotOS 2021 (two weeks ago), is an academic paper arguing that putting Rust into an existing kernel will deliver you much more than microscopic gains and will yield better results than starting from scratch. https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s...
On aspect of the Rust-on-Linux worked I've helped out with is trying to make sure standard
library abstractions aren't just suitable for userspace. I hope the medium term result of this is more comparability between bare metal projects on axes where they aren't trying to differentiate.
Longer term, I hope that means a corpus of driver that can be shared between kernels, revolutionizing kernel diversity the same way LLVM revolutionized programming language diversity.
- A BGP server.
- A DNS/DNSSEC server.
- A WiFi/home network gateway.
Those are critical infrastructure. They're self-contained units which talk well-defined protocols. Their functions don't change much. The first two aren't that price-sensitive. They should be verified down to the bare metal.
Apply to DARPA or NIST or DHS for funding for such a project. You might get it.