Yes, technically. As always, it depends on your threat model.

They suggest a separation of TOTP and the rest in two different files

I use a synced kbdx file on Linux (keepass-xc) and Android (KeePassDX) daily with the same keepass file. It handles all my logins, TOTP, passwords, passkeys no problem. I synchronize it using syncthing. When the two machines are on the same WiFi (or on a meshed VPN like tailscale) and can talk to each other, they sync freely.

I know someone who has it set up the same way who also uses Windows in the mix.

I haven’t checked the code, but it seems the writes the file is not actively being held open for reading and writing, with constant updates happening, updates appear to be transactional. I’ve only ended up with two sync errors in 3 years of daily syncing and I was able to merge the two files with the keepass-xc cli merge options.

The key distinction here is the program keepass-xc is not keepass the standard, just a program for reading the kbdx vault. A really good, externally audited, well coded, security first program for reading the vault!

If you’re concerned about the sync, it might be worth checking out how the original program expects DB sync to be done.

If you’re concerned about the manager working across os’s, don’t be. The primary use case, in the browser, is cross-platform by way be being a browser add-on. The brains of the operation are bundled in the keepass-xc app as a local server that only gets enabled when you switch on browser integration in the manager. The browser add-on sends web addresses to that server, and then the manager looks up the response, and sends back the correct credential. This interchange is encrypted during the pairing process.

On Android, KeePassDX hooks in to the built-in passwords, passkeys, and accounts ‘preferred service’ and offers password autofill in the keyboard suggestions bar, and comes with a credential-fill keyboard you can switch to on the fly if needed. It also saves passwords in normal apps, by storing the app id in the credential under a custom field ‘AndroidApp’ to help narrow down hinting. E.g. com.hjiansu.thunder for my Lemmy app, or com.android.settings for WiFi SSIDs and PSKs.

FYI, scrcpy can be an excellent tool for remote support, but you’d better trust the network the interface is on

I would dearly love to know how many if statements are between me and the brakes.

Also, being able to prove that that the CAN bus and RTOS system was air-gapped from whatever bullshit uplink to the internet ends up in there would be worth ~20K extra to me.

You can never be vulnerable to an exploit if you never reuse the same code twice

You shut your mouth that song is great. It’s no Favorite Game, but it’s still good!

tl;dr:

If you think something is blocking DNS traffic, you could try configuring DNS-over-HTTPs or DNS- over- TLS and picking a reputable upstream. This should obfuscate the traffic somewhat and get past common DNS interference issues and tactics.

So building on what yourself and everyone else has said, it does seem to be a DNS issue.

I found that at select times my local ISP was up to shenanigans with DNS.

I live in a very small country and work in IT. The NOC for all three ISPs and I have met. It would surprise me if they were competent enough to do this intentionally for malicious purposes.

If you can get access out to the internet via ping, see if you can do other things - get on a VPS and test with tcpdump at both ends. There’s a few free ones or trials great for disposable purposes like this. Set it up in advance…

You won’t know what it is til you troubleshoot.

I’ve had huawei firewalls reaching some simultaneous connection limit and fail, reversing their ruleset - blocking everything except ICMP, tr069 and ssh (concerning) outbound…

I’ve had problems with specific DNS servers, through the ISP’s network.

I’ve seen regular BGP changes causing outages all over the place (the ISPs locally don’t peer with each other…)

Post your findings, would love to help/hear!

An interesting argument would be to require the training data to be shared to prove it was never exposed to the original source it’s ripping off.

It might help set a precedent that would make this sort of thing less attractive

Do you subscribe to karakeep lists? Are they of infinite length?

I was trying to finalize a backup device to gift to my dad over Christmas. We’re planning to use each other for offsite backup, and save on the cloud costs, while providing a bridge to each other’s networks to get access to services we don’t want to advertise publicly.

It is a Beelink ME Mini running arch, btrfs on luks for the os on the emmc storage and the fTPM handling the decryption automatically.

I have built a few similar boxes since and migrated the build over to ansible, but this one was the proving ground and template for them. It was missing some of the other improvements I had built in to the deployed boxes, notably:

• zfs on luks on the NVMe drives
• the linux-lts kernel (zfs compatibility)
• UKI for the secureboot setup

I don’t know what possessed me, but I decided that the question marks and tasks I had in my original build documentation should be investigated as I did it up, I was hoping to export some more specific configuration to ansible to the other boxes once done. I was going to migrate manually to learn some lessons.

I wasn’t sure about bothering with UKI. I wanted zfs running, and that meant moving to the linux-lts kernel package for arch.

Given systemd-boot’s superior (at current time) support for owner keys, boot time unlocking and direct efi boot, I’ve been using that. However, it works differently if you use plain kernels, compared to if you use UKI. Plain kernels use a loader file to point to the correct locations for the initramfs and the kernel, which existed on this box.

I installed the linux-lts package, all good. I removed the linux kernel package, and something in the pacman hooks failed. The autosigning process for the secure-boot setup couldn’t find the old kernel files when it regenerated my initramfs, but happily signed the new lts ones. Cool, I thought, I’ll remove the old ones from the database, and re-enroll my os drive with systemd-cryotenroll after booting on the new kernel (the PCRs I’m using would be different on a new kernel, so auto-decrypt wouldn’t work anyway.)

So, just to be sure, I regenerated my initram and kernel with mkinitcpio -p linux-lts, everything worked fine, and rebooted. I was greeted with:

Reboot to firmware settings

as my only boot option. Sigh.

Still, I was determined to learn something from this. After a good long while of reading the arch wiki and mucking about with bootctl (PITA in a live CD booted system) I thought about checking my other machines. I was hoping to find a bootctl loader entry that matched the lts kernel I had on other machines, and copy it to this machine to at least prove to myself that I had sussed the problem.

After checking, I realised no other newer machine had a loader configuration actually specifying where the kernel and initram were. I was so lost. How the fuck is any of this working?

Well, it turns out, if you have UKI set up, as described, it bundles all the major bits together like the kernel, microcode, initram and boot config options in to one direct efi-bootable file. Which is automatically detected by bootctl when installed correctly. All my other machines had UKI set up and I’d forgotten. That was how it was working. Unfortunately, I had used archinstall for setting up UKI, and I had no idea how it was doing it. There was a line in my docs literally telling me to go check this out before it bit me in the ass…

…

• [x] figure out what makes uki from archinstall work ✅ 2025-09-19
• It was systemd-ukify

…

So, after that sidetrack, I did actually prove that the kernel could be described in that bootctl loader entry, then I was able to figure out how I’d done the UKI piece in the other machines, and applied it to this one, so it matched and updated my docs…

…

• IT WASN’T ukify

UKI configuration is in mkinitcpio default configs, but needs changing to make it work.

vim /etc/mkinitcpio.d/linux-lts.preset 

…

Turns out my Christmas wish came true, I learned I need to keep better notes.

His instance and mine, “sh.itjust.works” was federated with lemm.ee

Mine (Thunder) doesn’t recognize tagging the code block as a specific syntax, it just shows it as preformatted block, with no highlighting.

If you’ve ever had to go through the audit process CAs are subjected to, not violating the compliance controls and ensuring audit compliance is a massive chunk of your attention for a lot of the year.

Can I ask what client you’re using?

You are right to be afraid. I had a similar story, and am still recovering and sorting what data is recoverable. Nearly lost age 0.5-1.5 years of media of my daughters life this way.

As others have said, don’t replicate your existing backup. Do two backups. Preferably on different mediums, spinning disk/ssd eg.

If one backup is corrupted or something nasty is introduced, you will lose both. This is one of the times it is appropriate to do the work twice.

I’ve built two backup mini PCs, and I replicate to them pretty continuously. Otherwise, look at something like Borg base/alternatives.

Remember, 3-2-1 and restore testing. It’s not a backup unless you can restore it.

I have never understood this fork argument. All it takes to make it work is a clear division for the project.

If you want to make something, and it requires modification of the source for a GPL project you want to include, why not contribute that back to the source? Then keep anything that isn’t a modification of that piece of your project separately, and license it appropriately. It’s practically as simple as maintaining a submodule.

I’d like to believe this is purely a communication issue, but I suspect it’s more likely conflated with being a USP and argued as a potential liability.

These wasteful practices of ‘re-writing and not-cloning’ are facilitated by a total lack of accountability for security on closed source commercialised project. I know I wouldn’t be maintaining an analogue of a project if there were available security updates from upstream.

Everything’s a trade off, as you already know. I still use lets encrypt, despite the fact that I know attackers watch CT logs, and they’ll know as soon as I mint a cert.

Also, according to the propaganda model, in developed democratic societies, the propaganda is assumed to be true, and if you’re not on board with that, you’re not part of the debate.

Fair enough, I did assume the target audience was selfhosters based on the question.

As for provider backups - well, you’d hope. But M$ doesn’t do user available backups, so I’d be surprised if that was bundled by the average SaaS provider.

And if you don’t know what database you’re running, how are you backing it up?

If you don’t know what database you’re running, are you bothering to do a full shutdown before backups? Are you doing backups at all…