I'd go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.
It's a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.
Rustfmt is not very configurable. That is a wonderful thing: People don't waste time on discussing different formatting options and every bit of rust code looks pretty identical.
Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.
It gets rid of one more SUID binary. That's always a win for security.
Sudo probably is way more comfortable to use and has way more configurable, too -- that usually does not help to make a tool secure either:-)
When I last checked (and that is a long time ago!) it ran everywhere, but did only sandbox the application on ubuntu -- while the website claimed cross distribution and secure.
That burned all the trust I had into snaps, I have not looked at them again. Flatpaks work great for me, there is no need to switch to a wannabe walled garden which may or may not work as advertised.
“I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,”
My impression is that they are very aware of the state of C++ and the efforts to provide strong safety guarantees. That's why they keep raising the pressure.
That depends a lot on how you define "correct C".
It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.
The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.
That depends on how you decide which bucket something gets thrown into.
The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.
These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.
There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the "right" direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)
All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.
Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.
I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.
Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.
GPL effects "derived works". So if your code is derived from proprietary code, you can not use GPL, as you would need to re-license the proprietary code and you can't do that (assuming you do not hold the copyright for the proprietary code). LGPL and permissive licenses are probably fine though.
Now what exactly is a "derived work"? That is unfortunate up to interpretation and different organizations draw the line in slightly different places. We'd need people to go to court to get that line nailed down more firmly.
Those evil companies block random users, just because their government made some laws about it.