My coworker used it till his HDD broke, taking his key into data heaven. The repository is still online thanks to radicale, but he has no way to ever get push access to it again.
So it is useless as any misstep can potentially kill your access to the repo.
Yes, I should not have said "impossible": nothing is ever impossible to breach. All you can donis to make a breach more expensive to accomplish.
Those separate tpm chips are getting rare... most of the time they are build into the CPU (or firmware) nowadays. That makes sniffing harder, but probably opens other attack vectors.
Anyway: Using a TPM chip makes it more expensive to extract your keys than not using such a chip. So yoj win by using one.
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 :-(
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.
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 :-)
One more reason to run the steam flatpak: At least I can sandbox away things steam does not need to concern itself with.
The point of using the TPM is that it does not unlock the drive unless it has a certain set of software is loaded in a certain sequence on the machine with that specific TPM chip.
So if somebody breaks grub and makes it load a shell, then that results in different software loaded (or at least loaded in a different sequence) and will prevent the TPM to unlock the system. The same is true if somebody boots from a rescue disk (different software loaded) or when you try to unlock the disk in an unexpected phase of the boot process (same software but different sequence of things loaded, e.g. after boot up to send the key to some server on thr network. The key is locked to one TPM, so removing the drive and booting it in a different machine also does not work.
The TPM-locked disk is pretty secure, even more so than that USB idea of yours -- if the system you boot into is secure. It basically stops any attacker from bringing extra tools to help them in their attack. All they have available is what your system has installed. Do not use auto-login or run some root shell in some console somewhere...
None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.
So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.
Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.
What is actually meassured there? "Line goes down" is not necessary a bad thing:-)
I use cargo-dist to generate the binaries.