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.
I’d agree that a hardware solution would be best. Something designed specifically to do it. I’ve been eyeing up the biometric yubikey for a while.
I do this for ssh keys, VPN certs and pgp keys. My solution is pretty budget, I generate the keys on a LUKS encrypted USB and run a script that loads them in to agents, and flushes them on sleep. The script unlocks and mounts the LUKS partition, adds the keys to agents, unmounts and locks the USB. The passwords I just remember for the unlock and load into memory, but they’re ripe for stuffing in to keepass-xc - I need to look at the secret service api and incorporate that in to the script to fetch the unlock passwords directly from keepass.
I have symlinks in the default user directories to the USB’s mount points, like
~/.ssh/id_ed25519 -> /run/media/<user>/<mount>/id_ed25519. By default, when you run ssh-agent, it tries to add keys in the default places.The way it works for me is:
I keep break-glass spares in a locked cabinet in my house and office, both with different recovery keys
I do this because it’s my historical solution, and I haven’t evaluated the hardware options seriously yet.