Ayy looks like #gpg borked in #Devuan unstable (silently, too. No apt warnings). I now can't validate the signatures of the packages anymore which means apt upgrade stopped working. Oops? :devuannew: :blobfoxpat:
Damn yeah. Finally fixed the pin entry program to actually use the secret service on #linux#kde#plasma and to stop asking all the time for the password for signing commits.
It seems a somewhat recent breaking change, since this worked before. Anyway, someone had already written about it on #archlinux wiki.
Tldr: after setting the pin entry program on gpg-agent config to use the qt version, we need to change the gpg-agent service to have XDG_SESSION_DESKTOP as anything but "kde".
Anyway this seems all kinda ridiculous because it's about some potential problem when using kwallet as the secret service and kwallet configured to use #gpg as the backend? I never knew that was possible.
Anyway, currently I'm using #keepass with its secret service integration to make all this work.
#e2ee is a goal, not a promise. As far back as I can remember, forums like those supporting #Enigmail and #gpg were staffed with volunteers from the privacy community who repeatedly insisted on answering questions, like, "Is <this> (whatever this might be) totally secure?" with stock questions like, "What is it that you consider 'totally secure?" or answers such as, "Secure is a relative term, nothing is completely secure, how secure do you need your mission's communications to be?"
Phrases such as, reasonably secure should be indicators of how ridiculous it is to assume that any secure platform isEVERcompletely, and totally secure.
That begs the question, "Exactly how secure do you require your communications to be?" The answer is always, ... relative.
Which means that you should always believe Ellen Ripley when she says, "Be afraid. Be very afraid!"
oct-git focuses exclusively on ergonomic use with OpenPGP card-based signing keys
It is designed to be easy to set up, standalone (no long running processes), and entirely hands-off to use (no repeated PIN entry required, by default). It comes with desktop notifications for touch confirmation (if required)
Ich überlege gerade ernsthaft, für meine 3 #GPG-Keys (potentiell mehr) ein #HSM2 von #NitroKey zu besorgen... wie gut ist das unter GnuPG nutzbar? Wie sind Eure Erfahrungen?
I just released version 0.3.1 of https://crates.io/crates/rsop, a stateless #OpenPGP ("sop") card tool based on #rPGP.
rsop natively supports OpenPGP card (hardware cryptography) devices
rsop is featured in the "OpenPGP interoperability test suite" at https://tests.sequoia-pgp.org/ (under "rpgpie", which is rsop's high level OpenPGP library).
I have upgraded two systems to #Ubuntu 24.04 now and also tried #Thunderbird as snap (which is the default for Ubuntu 24.04) on another machine.
The system upgrades were incredibly smooth. Thunderbird in general also works fine, but it doesn't support #GPG with private keys on a #YubiKey yet (which is my usecase). (Yes,there is a workaround, although clunky.)
So it looks like I'll stay on 23.10 a bit longer on my main machine.
I spent a lot of time today trying to figure out #GNUPG / #GPG to encrypt and sign backups. I've used it occasionally for literally decades, but still struggle with it. I know if I used it more, I would get used to it and feel more comfortable, but I don't have the time or the need to use it more.
Is there another good open source program to symmetrically encrypt a file? But, for signing, you would still need to use key pairs, right?
My first troublesome hallucination with a #LLM in a while: #Claude3#Opus (200k context) insisting that I can configure my existing #Yubikey#GPG keys to work with PKINIT with #Kerberos and helping me for a couple of hours to try to do so — before realising that GPG keys aren't supported for this use case. Whoops.
No real bother other than some wasted time, but a bit painful and disappointing.