Andrew Gallagher

We have a reply - it's the specification that's wrong: lists.gnupg.org/pipermail/gn...

I've raised this issue on gnupg-devel: lists.gnupg.org/pipermail/gn...

I would definitely prefer to get a comprehensible spec out of gnupg before merging any changes, just in case we guess wrong. 🙃

Did you (or claude?) find a source for the offending format change btw?

Thanks! I think it would be more reliable to detect the novel format by length rather than the prefix byte, because of the risk of accidental collision. But otherwise the idea is reasonable. I’m going to raise this with gnupg because it’s yet another example of underdocumented novelty… 🫠

HKPv2 is WIP, but will probably be implemented first: datatracker.ietf.org/doc/draft-ga...

Key replacement is spec stable but lacks implementations: datatracker.ietf.org/doc/draft-ie...

There are of course many other missing bits, but I think these are critical for PQC transition.

The two main missing pieces IMO are HKPv2 and key replacement. HKPv2 allows us to safely serve certificate bundles that include v4 and v6 certs, and key replacement formalises a directed graph between the individual certs.

Yes, the whole thing is a mess, and there are bits everywhere. But also, the context has been fluid for a couple of years. But maybe the time has come for an opinionated summary.

The creation of the signed repo is configurable IIRC, but I’m not sure what ubuntu uses currently on launchpad. Probably best to stick with v4 keys until it’s clear that all the component parts of the pipeline have been updated…

Beware that Ubuntu PPAs can’t use v5 keys, because as of apt 2.9.19 they rely on sq rather than gnupg for openpgp. You would need to generate a v6 key instead (which can’t be done with gnupg). 😬

Did you consider talking to the maintainer first? 😇

Very clever. Now calculate it as a percentage of all transactions.

It's really important to note that not only was Watson a racist and misogynist but his contribution to the double helix was listening to a Rosalind Franklin lecture and getting mad because Francis Crick wouldn't invite him to his sex parties.

Gender in English - Wikipedia

It *mostly* doesn’t, but the corpse of its earlier life as a gendered language is still present. see e.g. en.wikipedia.org/wiki/Gender_...

@expresbro.bsky.social 👋

@donnachab.bsky.social how do

Searle's paper, titled "Dazed & Confused: A Large-Scale Real-World User Study of reCAPTCHAv2," found that Google's widely-used CAPTCHA system is primarily a mechanism for tracking user behavior and collecting data while providing little actual security against bots. The study revealed that reCAPTCHA extensively monitors users' cookies, browsing history, and browser environment (including canvas rendering, screen resolution, mouse movements, and user-agent data) — all of which can be used for advertising and tracking purposes. Through analyzing over 3,600 users, the researchers found that solving image-based challenges takes 557% longer than checkbox challenges and concluded that reCAPTCHA has cost society an estimated 819 million hours of human time valued at $6.1 billion in wages while generating massive profits for Google through its tracking capabilities and data collection, with the value of tracking cookies alone estimated at $888 billion.

Oh.

reCAPTCHA: 819 million hours of wasted human time and billions of dollars in Google profits New research reveals Google's reCAPTCHA system primarily serves as a tracking tool, generating billions in revenue while offering minimal protection against bots.

“…Google's widely-used CAPTCHA system is primarily a mechanism for tracking user behavior and collecting data while providing little actual security against bots.”

Wonderful story. Deservedly on the front page.

I've shared this quote before but I'll share it again, as it's one I've been thinking about a lot as I've watched how our oligarchs have been behaving over the past few months.

someone on tiktok said, “we’ve got 7 lex luthors and no superman,” and i can’t stop thinking about it

Being a person with deadly, incurable cancer who is nonetheless still alive for an indefinite timeframe gives me an interesting metaphor that helps me deal with things like large-scale corruption in government or commerce.

Bear with me for a second while I try to explain.

not Lynch's movie, I know, but god, what a sendoff

A Potential Modern Keyserver Network - Design Outline A Potential Modern Keyserver Network - Design Outline - modern_keyservers.md

What started with me trying to teach myself OpenPGP and GnuPG led to a spiral of research piecing together what on Earth happened to keyservers, and has now resulted in my attempt to propose a new design outline for a keyserver network. Feel free to provide feedback!

gist.github.com/McDaMastR/d4...

Another wrinkle is that email challenge/response only works for email userids. While this is by far the most common form of userid it’s not a strict requirement. It may be possible to still tie them to an email address to prevent spamming - but the question is how. 🤯

(Aside: if you’re using a random number in a challenge-response protocol you have to store the random number in order to verify the response - in which case you can just use the random number alone as the challenge, no need for hashing the other data)

I think your ideas about email verification are useful. keys.openpgp.org already verifies emails, the real trick has been designing a way of doing this robustly in the sks network, in particular how do you prevent *every* keyserver from trying to email-verify the same key… 😵‍💫

Also, abusive keys can be blocked by adding their fingerprint to a list; there’s no need to revoke them.

Since hockeypuck 2.2, hard-revoked keys have their userids automatically deleted, as you suggest (this is not yet implemented on keys.openpgp.org).

Re your four responsibilities of a keyserver, we believe both keys.openpgp.org and the sks/hockeypuck network are compliant: image attributes are banned, and legal deletion requests are obeyed (and in the case of sks, forwarded to other operators).