News at 11: Senior C++ committee member still does not understand what memory safe means.

Seriously: C++ does not “archive parity with other memory-safe languages” (emphasis mine) since it is not a memory safe language itself, even if profiles deliver on everything they promise today.

I use cargo-dist to generate the binaries.

As a user I definitely want flatpaks and use them over distribution packages whereever possible. First I can sandbox the flatpak, but not the native package. Why would my browser need to be able to read my ssh keys?

Secondly I just have seen too many distro packagers sabotaging packages in the most braindead ways possible. Debian removing almost all the random data during key generation because some static analysis tool did not like the code. To this day there are servers using one of the 32k keys debian could produce during that time (they are of course all brute forced by now). Fedora removing Codecs from a video encoder, dependencies that upstream knows are broken and listsmas such in its documentation being used anyway. Random patches being applied, or versions years out of date getting shipped…

If you find a reliable way to allow for people to use data without being able to copy it: Patent it right away, the entertainment industry will be paying big time for it.

Same for erasing the laptop: You can only erase something as long as you can talk to the machine in some way to instruct it to clean itself up. The guy with the machine in hand can just turn off wifi to stop it from receiving the message…

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.

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

“They” did not go anywhere yet. This is a proposal, nothing more. It will take serious discussions over years to get this into C++.

Prominent figures already said they prefer safety profiles as a less intrusive and more C++ approach at conferences It will be fun to watch this and the other safety proposals going forward.

Well, its a brand new standard library. A fresh start.

Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, …), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.

The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.

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.

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.

sigh

All build tools are simple as long as nobody uses it. Even CMake was simple before KDE and Co. started to rely on it.

A build tool can be simple, if you use conventions over configuration. Unfortunately that ship has sailed for the C and C++ eco system decades ago… Every project is widely different from every other project out there. Heck, we can not even agree on file extensions for c++ files, let alone a directory structure for project source code to live in or the tooling we want to be available.

So you need to have every little detail configurable… and since all projects are so very different, users will need to tweak all those settings… as the first bigger project adopting abcs will dictate their defaults into your code (where you have not gone with your defaults before).

Seriously, you need a language leadership team that considers tooling as important from the very start or you will not have a simple build tool ever. See rust: There the leaders pushed for tooling from the start. Every rust project looks basically the same because of that. These strong conventions enable the language to have a simple build tool.

C++ is on thenfar side of that. Even in 2020 when introducing modules the committee choose not to mandate even the most basic interoperability features like file extensions. The cmake people had to get several compiler developers to add things to make modules toolable. And even with that effort the meson people seem to say c++ modules are entirely untoolable still.

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.