Anyone using vscodium? I can't use it to commit. Committing works from the command line. It works using vscode.
In vscodium I get a gpg: signing failed: pinentry error.
Is there a config that I've forgotten?
Anyone using vscodium? I can't use it to commit. Committing works from the command line. It works using vscode.
In vscodium I get a gpg: signing failed: pinentry error.
Is there a config that I've forgotten?
Anyone open to help me test my GnuPG/KMail mail setup? (Sending me an encrypted mail, so I can test if I'm able to encrypt it and vice-versa)
My OpenPGP key is now attested by via the German federal ID card. At least that is something useful with the eID function, they introduced in 2010
Mein OpenPGP-Schlüssel ist jetzt über den deutschen Personalausweis (eID) beglaubigt. Zumindest ist das etwas Nützliches mit der eID-Funktion, die sie 2010 eingeführt haben
Messenger: Delta Chat
Obwohl es mehr als genug Messenger gibt, überzeugt Delta Chat durch Benutzerfreundlichkeit und erprobte Technik.
> apt-listchanges: News
> debian-archive-keyring
> Certificate (keyring) files in /usr/share/keyrings now have the file extension .pgp, rather than .gpg.
Boo
It's pretty stupid that you could neither name a #GPG key registered to #GitLab, or see which may have expired. My key has expired, I've renewed it locally, and now am updating it on both #GitHub and GitLab.
On GH, it's easy to know which key I'd have to replace since it lets you know which of them has expired, and when registering it for the first time, you have to give it an identifier. On GL, there's no (human) identifier whatsoever, and it doesn't tell you which of them has expired either.
Better find a way to identify it correctly tho or you might risk deleting the wrong GPG key, and potentially cause your verified commits to be deemed unverified.
---
Edit: Figured it out. When you list your GPG key on your system like this:
gpg --list-secret-keys --keyid-format long
/home/user/.gnupg/pubring.kbx
------------------------------
sec ed25519/1H89FHO4MGAJTJ9Z 2024-01-15 [SC] [expires: 2026-01-15]
0A41C9F6335DBF47A1A186FAC82F22229FCCE1BF
1H89FHO4MGAJTJ9Z
, on GL you identify it through its "long key" i.e. 0A41C9F6335DBF47...
.Expired
if they're expired - easy enough to understand, meanwhile on GL, it tags valid, non-expired keys as Verified
, which may be somewhat confusing or vague.. especially when users coming into this setting is either adding a new GPG key or renewing an outdated one.Quoting myself in a mood today at work
```#GPG keys have two parts: the private key (which is fiercely protected) and the public key (which is handed out like sleazy leaflets on a Las Vegas street corner.)```
Made a few updates and released a new version of #calliope , a #bash script based utility to write a journal using #LaTeX. Since it's #LaTeX based, you can pretty much add whatever you wish to your journal---images, other PDFs, beautiful maths, and of course, you can customise it as you wish to suit your needs. It's all managed by #Git and if you'd like you can encrypt your journal entries using #gpg
Check it out on #GitHub : https://github.com/sanjayankur31/calliope
Non, #Google ne proposera pas un vrai #chiffrement de bout en bout sur #Gmail. Le mécanisme proposé n'est pas considéré comme un véritable chiffrement "E2EE" par certains experts. En effet, il implique un serveur de gestion de clés interne à l'entreprise.
https://www.clubic.com/actualite-560031-non-google-ne-proposera-pas-un-vrai-chiffrement-de-bout-en-bout-sur-gmail.html
Mieux vaut utiliser soit #protonmail soit #thunderbird avec #gpg et une adresse mail chez un hébergeur non #gafam respectant les #donneespersonnelles
@Xeniax Totally nerdsniped :D I'd love to be a part of the study.
I don't think that #KeyServers are dead. I think they evolved into Verifying Key Servers (VKS), like the one run by a few folks from the OpenPGP ecosystem at https://keys.openpgp.org/about . More generally, I believe that #PGP / #GPG / #OpenPGP retains important use-cases where accountability is prioritized, as contrasted with ecosystems (like #Matrix, #SignalMessenger) where deniability (and Perfect Forward Secrecy generally) is prioritized. Further, PGP can still serve to bootstrap those other ecosystems by way of signature notations (see the #KeyOxide project).
Ultimately, the needs of asynchronous and synchronous cryptographic systems are, at certain design points, mutually exclusive (in my amateur estimation, anyway). I don't think that implies that email encryption is somehow a dead-end or pointless. Email merely, by virtue of being an asynchronous protocol, cannot meaningfully offer PFS (or can it? Some smart people over at crypto.stackexchange.com seem to think there might be papers floating around that can get at it: https://crypto.stackexchange.com/questions/9268/is-asynchronous-perfect-forward-secrecy-possible).
To me, the killer feature of PGP is actually not encryption per se. It's certification, signatures, and authentication/authorization. I'm more concerned with "so-and-so definitely said/attested to this" than "i need to keep what so-and-so said strictly private/confidential forever and ever." What smaller countries like Croatia have done with #PKI leaves me green with envy.
1. S/MIME - centralized trust model with certificates
2. PGP/MIME- decentralized "web of trust"
3 #tailscale - 0 trust model
Is there something like best choice in these?
#gpg #ssh
“Unless you are using #GPG, email is not end-to-end encrypted, & the contents of a message can be intercepted & read at many points, including on Google’s email servers,” said Eva Galperin, director of #cybersecurity at the Electronic Frontier Foundation.
#NationalSecurity experts have expressed alarm over the #Trump admin’s denial that the leaked #Signal chat contained #classified information.
among other thing #gitea does give something unique , armored #ssh sig , when they need not map to a #gpg key
https://www.techaddressed.com/tutorials/add-verify-ssh-keys-gitea/
#porkbun has #email with @protonprivacy, really affordably. So I switched my business mail to that, and I have it all setup in #emacs! :D @daviwil is a goddamned treasure. I would not be able to setup my workflow this well without Systems Crafters! I'm happy! I feel so #secure and #cozy, and I can do #gpg for a little extra. Just don't let crazy Christians on my e-mail chains. I don't want to pull a Hegseth.
#GitHub "enterprise" has some very weird properties:
* commits made with my email address not from the organization are not counted in statistics (oh how I despise these stats...)
* my #gpg signed commits are shown as unverified even though gh has my public key on my personal profile
* I can not add my public key nor my well known email address to my enterprise profile
All of this "enterprise"-junk just puts me off. No, #GitHub is not #git.
#Gwit est un protocole de publication de contenus textuels (sites, documentation, etc) simplissime, pensé pour fonctionner essentiellement hors-ligne. Il est basé sur #Git et #PGP. Il permet de repartager des sites (même hors ligne) sans risque que le contenu ait été modifié
Pour le moment, seuls deux sites existent à ma connaissance ^^. Mais n'importe quel site statique léger peut facilement être "hébergé" sur Gwit.
gwit : https://sr.ht/~ivilata/gwit/
1/2
07.03.2025: GnuPG announces release of 2.5.5 for public testing, finalized PQC algorithms are supported.
Source: https://lists.gnupg.org/pipermail/gnupg-announce/2025q1/000491.html
11.03.2025: NIST selects HQC as fifth algorithm for post-quantum encryption.
Source: https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
PQC: https://wikipedia.org/wiki/Post-quantum_cryptography
GnuPG: https://mastodon.online/@blueghost/111974048270035570
Harvest now, decrypt later: https://mastodon.online/@blueghost/111357939714657018
admin email public key #GPG
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEZ9LrwxYJKwYBBAHaRw8BAQdAR0WzceV3yBHwzyj0bgA4HxO5GXFjawU0+pfC
bbT2fD60L0J5emFudGluZSBOZXh1cyBBZG1pbiA8YWRtaW5AYnl6YW50aW5lbmV4
dXMuaW8+iJkEExYKAEEWIQTgTgBQhrPwCwUm6F+1hI+KU0bXdAUCZ9LrwwIbAwUJ
BaUBPQULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRC1hI+KU0bXdIneAP0c
o0oLZOm61kn/CTdB2Yzq70oJbY8MGSBiBS2UiAwQ9QEA5L68kYOr+C2m9pxUhzCa
So+MO3NTBhai2hfDyrw2LQq4OARn0uvDEgorBgEEAZdVAQUBAQdAn0f8K1jCFlXj
G7q1dJ1gmjJbslyxROW5epwul+lUOx8DAQgHiH4EGBYKACYWIQTgTgBQhrPwCwUm
6F+1hI+KU0bXdAUCZ9LrwwIbDAUJBaUBPQAKCRC1hI+KU0bXdMwIAP94/es2lb+1
6SXryet+HOmpY+U41/v9o8aLF7KAhCIA6QD/cGDfdFBBg1mEWEZdI+7tCEieaAgS
0qrnFZJeDgt/7AA=
=y1x/
-----END PGP PUBLIC KEY BLOCK-----