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.

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:-)

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.

It’s just a git repo, so it does not replace a forge. A forge provides a lot of services around the repo and makes the project discoverable for potential users. None of that is covered by this thing.

I frankly see little value wrapping a decentralized version control system into layers of cryptography that hides where the data is actually stored (and how long it is going to be stored). Just mirror the repo a couple of times and you have pretty good protection against the code going offline again and you are done. No cryptography needed, and you get a lot of extras, too.

If you do not like github: Use other forges. Self-host something, go to Codeberg or sourcehut, use something other than git like pijul or fossil, or whatever tickles your fancy. Unfortunately you will miss out on a lot of potential contributors and users there :-(

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.

Then how do you not see the point of a distributed sourceforge?

But this is no forge, it is just a git repo.

Again, have you even opened the webpage?

Yeap, I even put a repo into it. That’s why I am so certain that it is useless.

Hosting a git repo is not a problem. Having an discoverable forge is. And this does not help with that in any way.

So github is not a problem?

Something can not be a solution independent of whether or not something else is another problem or not.

And regarding crypto, show me where in the code it forces you to use crypto. Show me the rad command that inhibits you from doing a normal git operation by bringing up crypto.

There is lots of needless crypto(graphy) going on all over the place. It is entirely useless for code hosting in a git repo.

No, I would prefer a world where not everything is concentrated on github, but that is the world we have to work with:-)

But how does this address any of the problems you brought up?

Do you think a project will be more discoverable when you say: “Clone foo/bar from github” or when you say “install this strange crypto-BS, then clone rad:xyhdhsjsjshhhfuejthhh just like you normally would”?

Apart from discoverability you get a known workflow for contributors, a CI and a bug tracker. Coincidently those make it hard for projects to switch away from github… how does this address any of that? “Use this workflow, which is even wierder than any of the other github alternatives!” and “just set up a server yourself”?

Sorry, this is just yet another crypto-bro solution in search of a problem. Technically interesting, I’m give you that, but useless.

Serious question: What is the point?

Just push into half a dozen mirrors and you are pretty censorship resident without the crypto voodoo put on top of git.

Github has one huge value: Discoverability of a project. This is even worse than hiding your project in one of the smaller forges… nobody can remember the mess of letters you need for this.

The quote above covered exactly what you just said: “yet were also more likely to rate their insecure answers as secure compared to those in our control group” at work :-)

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.

I am looking forward to follow up articles like “woodworking as a career isent right for me”, “bookkeeping as a career isent right for me” and the really enlightening “any job sucks when your boss is shit”.

An update is only truly done once no remnants of the old code is in memory. Code can stick around in the form of binaries (restart the binaries), libraries (restart all binaries that use this library) and the kernel (reboot or use kexec).

One very simple way to make sure no old code sticks around is to reboot:-)

The problem is that you lose out on dev attention when moving away from github.

I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).

If you want your project to be visible, it needs to be on github at this point in time:-(

Librewolf

Maintaining a browser is a huge endeaver. Using some random browser that is maintained by a a lone person or maybe even a handful of developers basically guarantees that the whole thing is insecure. This is especially true when keeping functionality around that was removed in the “main” browser to improve security there. One example is the old plugin system that firefox replaced with a more secure one with less hooks into the core engine, breaking some old plugins.

Stay with mainstream browsers folks and install some plugins to improve them that way. At least you get patches asap.

What is actually meassured there? “Line goes down” is not necessary a bad thing:-)

What do you mean by “system support”? The system is mostly pushing bytes along, the programming languages/UI ovaries tend to do all the hard work. So it is usually more interesting to see what those support.