mathstodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance for maths people. We have LaTeX rendering in the web interface!

Server stats:

2.8K
active users

#gpg

4 posts3 participants0 posts today

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

and get something like this:
/home/user/.gnupg/pubring.kbx
------------------------------
sec   ed25519/1H89FHO4MGAJTJ9Z 2024-01-15 [SC] [expires: 2026-01-15]
    0A41C9F6335DBF47A1A186FAC82F22229FCCE1BF

While on GH, you can identify your key either through the 1) name you gave it or 2) the "short key" i.e.
1H89FHO4MGAJTJ9Z, on GL you identify it through its "long key" i.e. 0A41C9F6335DBF47....

Likewise, on GH, it
tags each "Key ID" and "Subkey" as 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 : github.com/sanjayankur31/calli

Simple script for journal writing using LaTeX. Contribute to sanjayankur31/calliope development by creating an account on GitHub.
GitHubGitHub - sanjayankur31/calliope: Simple script for journal writing using LaTeXSimple script for journal writing using LaTeX. Contribute to sanjayankur31/calliope development by creating an account on GitHub.
Replied in thread

@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 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: crypto.stackexchange.com/quest).

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.

keys.openpgp.orgkeys.openpgp.org

1. S/MIME - centralized trust model with certificates
2. PGP/MIME- decentralized "web of trust"
3 - 0 trust model
Is there something like best choice in these?

#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 : sr.ht/~ivilata/gwit/

#gpg #offline

1/2

sr.htgwit: gwit - Web sites over Git
Continued thread

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-----