A Slint fanboy from Berlin.
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.
A TPM is a very slow and dumb chip: It can hash data somebody sends to it and it can encrypt and decrypt data slowly. That’s basically it. There is no privacy concern there that I can see. That chip can not read or write memory nor talk to the network.
Together with early boot code in the firmware/bootloader/initrd and later user space that chip can do quite a few cool things.
That code will use the TPM to measure data (create a hash) it loads before transfering control over and then unlock secrets only if the measurements match expected values. There is no way to extract that key on any system with different measurements (like a different computer, or even a different OS on the same computer). I find that pretty interesting and would love to use that, but most distributions do not offer that functionality yet :-(
Using the TPM to unlock the disks is just as secure as leaving the booted computer somewhere. If you trust the machine to not let random people log in, then TPM-based unlocking is fine. If you do not: Stay away.
Extracting the keys locked to an TPM is supposed to be impossible, so you do not need to worry about somebody stealing your keys. That alone makes TPMs very interesting… your own little FIDO tocken build right intomyour machine:-)
Not only that: It protects your data. The Unix security model is unfortunately stuck in the 1970s: It protects users from each other. That is a wonderful property, but in todays world you also need to protect the users from the applications they are running: Anything running as your user has access to all your data. And on most computer systems the interesting data is the one the users out there: Cryptogrqphic keys, login information, financial information, … . Typically users are much more upset to loose their data than about some virus infecting the OS files, those are trivial to fix.
Running anything as anlther user stops that application from having access to most of your data.
The same happens with any of the new immutable distributions. It’s just less effort as you do not need to do the nix configuration dance anymore.
Any of the many immutable distros (vanilla os, fedora silverblue, bluefin, aeon, endless os, pure os, …) will all obviously work.
Most of your customizations will live in your home directory anyway, so the details of the host OS do not matter too much. As long as it comes with the UI you like, you will be mostly fine. And yku said you like gnome, that installs many apps from flathub anyway and they work just fine from there.
For development work you just set up a distrobox/toolbox container and are ready to go with everything you need. I much prefer that over working on the “real system” as I can have different environments for different projects and do not have to polute my system with all kinds of dependencies that are useless to the functionality of my system.
NixOS is ofmcourse also an option and is quasi-immutable, but it is also much more complicated to manage.
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.
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.
Why don’t you download the latest release/nightly from github and unpack it somewhere?
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.
Yeap, -O3 is mostly voodoo. Berger has some measurements.
Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)
Ansible must examine the state of a system, detect that it is not in the desired state and then modify the current state to get it to the desired state. That is inheritently more complex than building a immutable system that is in the desired state by construction and can not get out of the desired state.
It’s fine as ,one as you use other people’s rules for ansible and just configure those, but it gets tricky fast when you start to write your own. Reliably discovering the state of a running system is surprisingly tricky.
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.
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.