I like it, this is clearly very enterprisey and solution focused, but I would like to suggest a couple of amendments if I may?

• Namespaces We should make full use of namespaces. Make the structural tags be in a language specific namespace (to be referenced in every function spec, obviously) but change the in an out params to use the parameter name as the tag, namespaced to the function they’re for, with a type attribute.

• In memory message queues Have all function invocations be marshaled as xml documents posted to an in memory message queue. Said documents should use a schema that validates the structure and a function specific schema to validate the types of arguments being passed. Namespace everything.

I reckon we could power a medium sided country if we could generate energy from the programmers despair.

If you’re talking about being able to regain access with no local backups (even just a USB key sewn into your clothing) your going to need to think carefully about the implications if someone else gets hold of your phone, or hijacks your number. Anything you can do to recover from the scenario is a way an attacker can gain access. Attempting to secure this via SMS is going to ne woefully insecure.

That being said, there are a couple of approaches you could consider. One option is to put an encrypted backup on an sftp server or similar and remember the login and passwords, another would be to have a trusted party, say a family member or very close friend, hold the emergency codes for access to your authentication account or backup site.

Storing a backup somewhere is a reasonable approach if you are careful about how you secure it and consider if it meets your threat model. The backup doesn’t need to contain all your credentials, just enough to regain access to your actual password vault, so it doesn’t need to be updated often, unless that access changes. I would suggest either an export from your authentication app, a copy of the emergency codes, or a text file with the relevant details. Encrypt this with gpg symmetric encryption so you don’t have to worry about a key file, and use a long, complex, but reconstructable passphrase. By this I mean a passphrase you remember how to derive, rather than trying to remember a high entropy string directly, so something like the second letter of each word of a phrase that means something to you, a series of digits that are relevant to you, maybe the digits from your first friend’s address or something similarly pseudo random, then another phrase. The result is long enough to have enough entropy to be secure, and you’ll remember how to generate it more readily than remembering the phrase itself. It needs to be strong as once an adversary has a copy of the file they jave as long as they want to decrypt it. Once encrypted, upload it to a reliable storage location that you can access with just a username and password. Now you need to memorize the storage location, username, password and decryption passphrase generator, but you can recover even to a new phone.

The second option is to generate the emergency, or backup, codes to your authentication account, or the storage you sync it to, and have someone you trust keep them, only to be revealed if you contact them and they’re sure it’s you. To be more secure, split each code into two halves and have each held by a different person.

I’ve found HSBC to be ok using Firefox on Linux. I don’t know if they have integrations with any accounting software, but the web access works well, and you can export your transactions for processing locally.

ETA: I’ve run small business accounting on Gnucash, I found the learning curve a bit steep, but once you ‘get it’ it’s handy.

Sorry for the slow reply, life occurred.

I think I understand where you’re coming from with the desired to be productive and not reinstall. I think I’ve been there too! One thing that I can suggest, if you do have the time, is to learn a system like Ansible and use it to setup and configure your machine. The discipline of keeping all of the config as source rather than making ad-hoc changes reduces the chance of thinking you’ll make just one little change and breaking something, and, if something does go wrong, you can get back to your working configuration quickly.

Bearing in mind that there really isn’t anything you can do to stop yourself if you’re really determined to not lose the data, because if you can read it at any time you can back it up, the closest you are likely to come is something like creating new key with GPG then using the TPM to wrap your secret key and deleting the original. That way the key is only usable on that specific machine. Then use the key-pair to encrypt your ‘guard’ files. You can still decrypt them because you have the wrapped secret keys and you’re on the same machine, but if you wipe the drive and lose those keys the data is gone. The TPM wrapping prevents you from taking the keys to a different machine to decrypt your data.

There’s an article with some examples here,

Having said all of that, this still doesn’t help if you just clone the disk as all of the data, including the wrapped key and the encrypted files will be cloned. The one difference there is that the serial number of the hard drive will be different. Maybe you could use that, combined with a passphrase as the passphrase for your GPG key, but we’re getting into pretty esoteric territory here. So you could generate a secret key with a command like:

( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40

Where /dev/sdb is the device your root partition is on. zenity is a handy utility for displaying dialogs, there are others available. In this use it just prompts for a passsword. We then concatenate the drive serial number from lsblk with the password you entered and hash the result. The hashing is really only a convenient way to mix the two without worrying about the newline lsblk spits out. Don’t record the result of this command, but use it to set the passphrase on your new GPG key. Wrapping the secret key in the manner the article above suggests is a nice extra step to make it harder to move the drive to another machine or mess around in that sort of way, but not strictly necessary as that wasn’t in the scope of your original question.

Now you can encrypt your file with: gpg -e -r <your key name> <your file>'. That will produce an encrypted version of <your file>called<your file>.gpg. To decrypt the file you can get gpg` to use the hashing command from above to get the passphrase with something like:

gpg -d --pinentry-mode=loopback --batch --passphrase-fd 3 <your file>.gpg 3< <( ( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40 )

Once you’ve tested that you can decrypt the file successfully you can remove the original, plaintext, file. Your data is now encrypted with a key that is secured with a passphrase made of a string you know and the serial number of your disk and optionally wrapped with a key from the TPM that is tied to your physical machine. If you change the disk or the machine the data is irretrievable (ignoring the caveats discussed above). I think that’s about as close to your original goal as you can get. It’s rough around the edges, and I’m not sure I’d trust my data to it, but I believe it’ll work. If you do something like this, please test it thoroughly, I can’t guarantee it!

Yes, yes, but now lets take that, make it dependent on the session management system and dns resolver for some reason, make the command longer and more convoluted and store the results in one or more of a dozen locations! It’ll be great!

/s

Dconf is bad, just imagine how bad a systemd version would be.

Yeah, I know there was one a while back, and if you don’t use ECC RAM, given enough time, it will eat your data as it tries to correct checksum errors due to memory corruption. That’s why we keep backups, right. Right?

I tend to assume that every storage system will eventually lose data, so having multiple copies is vital.

I think the difference is the level it’s happening at. As I said, I haven’t tried it yet, but it looks like a simple, unfussy and minimal distribution that you then add functionality to via configuration. Having that declarative configuration means it’s easy to test new setups, roll back changes and even easily create modified configuration for other servers.

cries It’s amazing how much damage they’ve done to the linux ecosystem. Not just badly thought out concepts, but the amount of frustration and annoyance they caused by ramming it into existence and the cynicism it’s created.

Having consistent interface names on servers that have several is useful, but we already had that option. The interface names they generate are not only hard to remember, but not terribly useful as they’re based on things like which PCI slot they’re in, rather than what their purpose is. You want interface names like wan0 and DMZ, not enp0s2. Of course, you can set it up to use useful names, but it’s more complicated than it used to be, so while the systemd approach looks like a good idea on the surface, it’s actually a retrograde step.

He may have taken some ideas from there, but I still see more windows like ideas. We’re one bad decision away from systemd-regedit. If that happens, I might just give up completely.

I try not to think about the things they’ve done, it’s not good for my blood pressure. They had a decent desktop distro, but they seem determined to trash it with terrible decisions.

In news that will shock no-one, dbus was, of course, initially created by a Redhat engineer. I get the idea of having a general purpose bus that everything can communicate on, but they somehow managed to even make that complex.

You make a compelling case for Void Linux. I use Debian or a RHEL derivative for work, primarily so there’s at least a chance to hand systems off to someone else to maintain, the less known distros seem to meet with blank looks.

I want to give NixOS a try sometime, as I like the idea of declaritively defining the system

I do use Ansible, partly because it’s easier to tell people that’s how you do it rather than “I wrote a shell script, it took half the time to write, it’s 20% the size and runs several times faster”. To be fair to Ansible, if you’re configuring a number of servers at the same time, it’s not too bad speedwise as it’ll do batches of them in parallel. Configuring one server at a time is agony though.

I’ve never actually tried BTRFS, there were a few too many “it loses all your data” bugs in the early days, and I was already using ZFS by then anyway. ZFS has more than it’s fair share of problems, but I’m pretty confident my data is safe, and it has the same upsides as BTRFS. I’m looking forward to seeing how BCachefs works now it’s in kernel, and I really want to compare all three under real workloads.

That’s fair, it does make sense to use it on a laptop, but it really should be the sort of thing you add when needed rather than having it jammed in whether it’s useful or not.

Every time I need to do something even slightly different to a basic setup I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations. Just give me vi and the basic configuration files and let me get on with it!

He’s definitely off my Christmas card list. He seems desperate to leave a legacy, but he keeps trying to turn Linux into windows instead.

Personally I’d do away with NetworkManager too and just configure the interfaces directly, but that might just be me being old and grumpy!

I think most distros go along because their upstream did. There are comparatively few ‘top level’ distributions, the main ones (by usage) being Redhat and Debian. Most everything else branches from those. Redhat’s got enough clout on the market that there’s a sort of pull towards complying with it just to not be left put.

I use Debian, but I think they’re crazy for swallowing everything Redhat pushes, they could easily stick to the cleaner options and have a better system for it. At least they let you opt out of systemd, so life is a little more tolerable.

No need for a custom solution, we already had ways to make predictable names that worked better than this. Giving each interface a name that represents it’s job makes life so much easier when you have several, naming them after which PCI bus they’re on does not.

I’m with our binary friend; the systems they try to replace tend to be time tested, reliable and simple (if not necessarily immediately obvious) to manage. I can think of a single instance where a Redhat-ism is better, or even equivalent, to what we already have. In eavh case it’s been a pretty transparent attempt to move from Embrace to Extend, and that never ends well for the users.

It’s amazing how many linux problems stem from ‘Redhat, however, found this solution too simple and instead devised their own scheme’. Just about every over complex, bloated bit of nonsense we have to fight with has the same genesis.