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.
This release adds the "oct admin signing-pin-validity" subcommand, to configure if a card requires User PIN presentation for each signature operation, or if User PIN presentation is valid for the full duration of a connection to the card.
Proton Mail automatically encrypts/decrypts messages between Proton Mail accounts via OpenPGP/PGP.
Proton Mail supports automatically encrypting/decrypting messages between Proton Mail accounts and external email accounts that support OpenPGP/PGP or GnuPG/GPG.
I moved to a Thinkpad w541 with coreboot so I needed to set up my email encryption on Thunderbird again.
It took me more time to reconfigure it again - as usual - so I decided to take notes this time and create a blog post about it. As this might be useful for somebody else … or me in the future :-)
"how can anyone trust sources signed by an unsigned-gnupg-key committer? In 2024. Really?"
Poster would clearly prefer if some citizens of the Transnational Republic could have signed Jia Tan's keys. I understand that in 2006 this was good enough for 90% of Debian Developers surveyed. Really.
This version comes with substantial updates to the openpgp-card-state dependency (which handles User PIN storage for OpenPGP card devices, see https://codeberg.org/openpgp-card/state).
It now supports selecting different PIN storage backends, including one to store the User PIN directly in the config file.
PIN verification error cases are now handled more defensively
Sie rufen von deinem e-Perso den Namen ab, du lädst deinen Public Key hoch, wählst eine der User-IDs des Keys aus (wenn du mehrere hast), und wenn der Name der UID mit dem Namen auf dem Perso übereinstimmt, bekommst du an die Mailadresse in der UID eine Signatur von 0xA4BF43D7 "Governikus OpenPGP Signaturservice (Neuer Personalausweis)".
Did someone say encryption? Encryption helps protect the privacy of people you communicate with, and makes life difficult for bulk surveillance systems. Learn more with our Email Self Defense guide: https://u.fsf.org/1df#GPG#PGP#E2E#encryption
Did someone say encryption? Encryption helps protect the privacy of people you communicate with, and makes life difficult for bulk surveillance systems. Learn more with our Email Self Defense guide: https://u.fsf.org/1df#GPG#PGP#E2E#encryption
I think it's telling that #GitHub, #GitLab, and even #Forgejo all don't have a workflow for "renew an #OpenPGP key", i.e. extend its validity before (or after) expiry. On all of them, you have to delete and re-add the key. It's as if nobody is following OpenPGP best practices and everyone is using keys without an expiry date.
#UnpopularOpinion The current spam wave supports one of my suspicions that federated networks should be built as a web of trust, Friends of a Friend style. Open registrations invite abuse and there's only so much algorithmic stuff you can throw at that. An invitation based system is also not a perfect solution as it creates artificial scarcity. A solution somewhere in-between is needed but I am still pondering how that could look like. Will continue my thoughts as a thread starting here.
This crate paves the way for convenient handling of #OpenPGP card User PINs, for users whose threat model allows persisting the PIN locally on the host computer.
If a User PIN is stored, applications can obtain it via this crate, and perform cryptographic operations without prompting the user for PIN entry.
Currently org.freedesktop.Secret is supported for storage.