If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?

Even highly paid (and probably skilled) devs in the IT industry manage to mess that up pretty regularly. Even if it was: devs using memory safe languages make much fewer mistakes wrt. managing memory… so that tooling does seem to help them at least more than the C++ tooling helps the C++ devs.

Those evil companies block random users, just because their government made some laws about it.

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.

Github login does not help much… devs are on github, not on random forgjo instances. That’s where they see your project. Github is also where they put their fork of your project when they play with it. They will write comments using github markdown and won’t care whether that renders correctly or not in your forge.

And it is where they will report issues and open a PR. It is annoying, but it is how it is. When you ask them to open the PR elsewhere they complain sinde they need to set up an account there and copy ssh key and similar things. You need a very dedicated contributor to go through with all that… especially if it is just a few lines of drive-by fixes.

I never said that you can not run a project elsewhere, my point is that you will get way more interaction on github.

Try pushing your project to github and compare the interactions you get from both forges.

That unfortunately requires setting up email… I have not bothered doing so on my boxes in a very long time.

The biggest factor to me is developer attention. I had a project on gitlab and pushed a README.md with a link to the gitlab instance into github. I got about 10 times more reactions from github, incl. PRs (where the person had grabbed the code from gitlab and did a PR on github anyway) – even in this setup. Mirroring a project to github tilts that even further.

Not being present on github means a lot less users and contributors. As long as that stays this way there is no way around github.

I hope federated forges can move some attention away from github, making other forges more visible… but I am not too optimistic :-(

The blocking certain countries is a US legal thing. It effects any forge in the US and probably in more areas close to the US. As soon as a forge gets big enough to show up on the radar of government orge they will need to do similar blocking.

You can not really blame github for that part.

“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.

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.

That interface is let any random app take screenshots of anything running on the same server without any way for the user to know it happens.

I am so glad that interface is gone, especially when running proprietary apps.

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that’s due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.

Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

So I seriously doubt you loose out when using AGPL or GPL.

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It’s all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs – something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

It is all about whos freedom you care for: GPL protects the freedom of end users, MIT and other permissive licenses focus on the freedoms of developers instead.

GPL defines freedoms end users of software have. It has to limit the freedoms of developers between the GPL project and the end user so that those developers can not strip out any of the freedoms the GPL wants end users to have. The hope is to build a better society by enabling everybody to understand the machines they own.

MIT and other permissive license care for the freedoms of people using the project directly, granting freedoms to those users only. Those people are free to forward the same rights to their own users or to remove them as they see fit. Thatbis way simpler for developers to work with: Basically do whatever you want.

Guess which option is more popular with developers and the companies that employ many of those developers?