PGP keysigning at LPC/OSSE 2026

PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

Hello,

I will organize a PGP keysigning event for the participants of Linux
Plumbers and Open Source Summit Europe in Prague this October.

The idea is to meet during the two conferences and exchange/verify PGP
fingerprints and (depending on how you practise keysigning) ID checking. 
Then each participant back at home can sign the verified certificates to
improve the web of trust. (Current state of the web of trust (as of
commit f8c2189fb65f in the kernel's pgpkeys repo):

 - 654 certificates, among them 12 invalid
 - 8088 signatures, 3613 of them invalid
 - 9 certificates are not reachable from Greg's stable key
   (38DBBDC86092693E).
 - 317 certificates are not reachable from Linus's cert
   (79BE3E4300411886). (That's why Greg is used as trust root since some
   time.)
 - strong set size: 289
 - average distance in the strong set: 4.85
 - maximal distance in the strong set: 13
 - Best connected certificate is Daniel Wagner's 587C5ECA5D0A306C which
   can reach the other strong set certs with an average of 3.89 steps.
)

The gatherings will be on Tue 2026-10-06 and Thu 2026-10-08 (that is on
the second day of each conference) after the official program.

I don't know the conference location and also don't have any idea yet
how many people will participate, so I will communicate the location and
exact time later. (If you have insights about the possibilities there,
please reach out.)

While it's not mandatory, please register by sending your PGP
certificate ("public key") to lpcosse-keysigning@baylibre.com until
2026-09-27 08:00 UTC. Your certificate doesn't need to be in the kernel
pgpkeys repo for that. I will prepare a text file with all the
registered certificates to speed up the event using the
Zimmermann–Sassaman key-signing protocol[1]. You can join without
sending your certificate, but then you have to care yourself about how
to share your fingerprint. (Probably use gpg-key2ps to prepare paper
slips with your certificate data. Having some of these even if you're on
the list might be a good idea.)

Note I will provide the text file (and thus all the personal information
contained in the certificates I receive) in this mail thread to allow
late joining (without being on the list then though). If you don't agree
to that, don't send in your certificate.

If you have questions, don't hesitate to ask (using above email
address).

Best regards
Uwe

[1] https://en.wikipedia.org/wiki/Zimmermann%E2%80%93Sassaman_key-signing_protocol

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Hello,

On Tue, Aug 04, 2026 at 05:43:43PM +0200, Uwe Kleine-König wrote:
>  - 654 certificates, among them 12 invalid
>  - 8088 signatures, 3613 of them invalid
>  - 9 certificates are not reachable from Greg's stable key
>    (38DBBDC86092693E).
>  - 317 certificates are not reachable from Linus's cert
>    (79BE3E4300411886). (That's why Greg is used as trust root since some
>    time.)
>  - strong set size: 289
>  - average distance in the strong set: 4.85
>  - maximal distance in the strong set: 13
>  - Best connected certificate is Daniel Wagner's 587C5ECA5D0A306C which
>    can reach the other strong set certs with an average of 3.89 steps.

I just noticed that the strong set facts were created with the SHA1
stuff that is still in the pgpkeys repo. With these dropped the
statistic looks as follows:

 - 410 certs are not reachable from Linus's cert
 - 148 certs are not reachable from Greg
 - strong set size: 152
 - average distance: 4.07
 - maximal distance: 12
 - Best connected certificate is Greg's 38DBBDC86092693E which can reach
   the other certs with an average of 3.08 steps.

So hopefully the keysigning improves the situation ...

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: PGP keysigning at LPC/OSSE 2026

[Krzysztof Kozlowski]

On 04/08/2026 17:43, Uwe Kleine-König wrote:
> Hello,
> 
> I will organize a PGP keysigning event for the participants of Linux
> Plumbers and Open Source Summit Europe in Prague this October.
> 
> The idea is to meet during the two conferences and exchange/verify PGP
> fingerprints and (depending on how you practise keysigning) ID checking. 
> Then each participant back at home can sign the verified certificates to
> improve the web of trust. (Current state of the web of trust (as of
> commit f8c2189fb65f in the kernel's pgpkeys repo):
> 
>  - 654 certificates, among them 12 invalid
>  - 8088 signatures, 3613 of them invalid
>  - 9 certificates are not reachable from Greg's stable key
>    (38DBBDC86092693E).
>  - 317 certificates are not reachable from Linus's cert
>    (79BE3E4300411886). (That's why Greg is used as trust root since some
>    time.)
>  - strong set size: 289
>  - average distance in the strong set: 4.85
>  - maximal distance in the strong set: 13
>  - Best connected certificate is Daniel Wagner's 587C5ECA5D0A306C which
>    can reach the other strong set certs with an average of 3.89 steps.
> )
> 
> The gatherings will be on Tue 2026-10-06 and Thu 2026-10-08 (that is on
> the second day of each conference) after the official program.
> 
> I don't know the conference location and also don't have any idea yet
> how many people will participate, so I will communicate the location and
> exact time later. (If you have insights about the possibilities there,
> please reach out.)
> 
> While it's not mandatory, please register by sending your PGP
> certificate ("public key") to lpcosse-keysigning@baylibre.com until
> 2026-09-27 08:00 UTC. Your certificate doesn't need to be in the kernel
> pgpkeys repo for that. I will prepare a text file with all the
> registered certificates to speed up the event using the
> Zimmermann–Sassaman key-signing protocol[1]. You can join without
> sending your certificate, but then you have to care yourself about how
> to share your fingerprint. (Probably use gpg-key2ps to prepare paper
> slips with your certificate data. Having some of these even if you're on
> the list might be a good idea.)

While as much as I like key signing, I do not believe in
Zimmermann–Sassaman protocol to work, because of people's negligence. It
requires the participants to check if THEIR key is correct, but based on
my recent practice (people generated new key and week later they lost
password to it; people received my signed keys and could not decrypt the
message because they never used encrypted email, people sent me emails
asking to send their keys) I think it has significant risk of this not
happening. People just do not understand the security principles here
thus they do not think certain steps are an absolute requirement.

IOW, I do not believe people will check their key fingerprints and email
IDs, they will gladly accept what you prepared on the server and that
could have been modified by an attacker or mischievous actor wanting to
prank us.

That's why I require that the keys to be given to me must be prepared by
that owner, not by a third party. I have some proofs that at least that
key was in the possession of the owner, when he was preparing it. I will
be happy to sign keys of developers given to me that way.

I know that you want to speed it up, but honestly korg keysigning should
not have that many participants, so exchanging key slips should be fine
as I was doing in the past.

Best regards,
Krzysztof

Re: PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

Hello Krzysztof,

On Wed, Aug 05, 2026 at 08:32:22AM +0200, Krzysztof Kozlowski wrote:
> While as much as I like key signing, I do not believe in
> Zimmermann–Sassaman protocol to work, because of people's negligence. It
> requires the participants to check if THEIR key is correct, but based on
> my recent practice (people generated new key and week later they lost
> password to it; people received my signed keys and could not decrypt the
> message because they never used encrypted email, people sent me emails
> asking to send their keys) I think it has significant risk of this not
> happening. People just do not understand the security principles here
> thus they do not think certain steps are an absolute requirement.

I see your point. However if Bob confirms his fingerprint on the
Zimmermann–Sassaman list is right while he didn't actually checked and
as an effect a forged certificate is signed, that's mostly Bob's
problem.

Also if Bob doesn't check his own fingerprint, he probably also doesn't
check the certificates he signs carefully and thus his signatures
shouldn't be trusted.

That's why a keysigning is about a *web* of trust where the (little?)
trust in each individual path between me and a given other person sums
up.

> IOW, I do not believe people will check their key fingerprints and email
> IDs, they will gladly accept what you prepared on the server and that
> could have been modified by an attacker or mischievous actor wanting to
> prank us.
> 
> That's why I require that the keys to be given to me must be prepared by
> that owner, not by a third party. I have some proofs that at least that
> key was in the possession of the owner, when he was preparing it. I will
> be happy to sign keys of developers given to me that way.

Last time I talked to Greg about these paper slips, he had trouble
finding gpg-key2ps on Arch and I prepared the postscript file for him :-D

> I know that you want to speed it up, but honestly korg keysigning should
> not have that many participants, so exchanging key slips should be fine
> as I was doing in the past.

I think even if we're only 10 in the end, the speedup is noticeable. And
it also simplifies the actual signing process for everyone, as I will
provide a keyring of all the handed in certificates.

If you still want a paper slip from each participant before being ok to
sign their certificate, that's fine. I'm still convinced that preparing
the Zimmermann–Sassaman list is a net win. And you're welcome to
participate no matter if your cert is on the list or not.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: PGP keysigning at LPC/OSSE 2026

[Krzysztof Kozlowski]

On 05/08/2026 12:29, Uwe Kleine-König wrote:
> Hello Krzysztof,
> 
> On Wed, Aug 05, 2026 at 08:32:22AM +0200, Krzysztof Kozlowski wrote:
>> While as much as I like key signing, I do not believe in
>> Zimmermann–Sassaman protocol to work, because of people's negligence. It
>> requires the participants to check if THEIR key is correct, but based on
>> my recent practice (people generated new key and week later they lost
>> password to it; people received my signed keys and could not decrypt the
>> message because they never used encrypted email, people sent me emails
>> asking to send their keys) I think it has significant risk of this not
>> happening. People just do not understand the security principles here
>> thus they do not think certain steps are an absolute requirement.
> 
> I see your point. However if Bob confirms his fingerprint on the
> Zimmermann–Sassaman list is right while he didn't actually checked and
> as an effect a forged certificate is signed, that's mostly Bob's
> problem.
> 
> Also if Bob doesn't check his own fingerprint, he probably also doesn't
> check the certificates he signs carefully and thus his signatures
> shouldn't be trusted.
> 
> That's why a keysigning is about a *web* of trust where the (little?)
> trust in each individual path between me and a given other person sums
> up.

I am rather thinking of someone planting their key in place of the
person's one, thus of course Bob will have a problem, but bigger problem
is that I would sign malicious actor's key.

> 
>> IOW, I do not believe people will check their key fingerprints and email
>> IDs, they will gladly accept what you prepared on the server and that
>> could have been modified by an attacker or mischievous actor wanting to
>> prank us.
>>
>> That's why I require that the keys to be given to me must be prepared by
>> that owner, not by a third party. I have some proofs that at least that
>> key was in the possession of the owner, when he was preparing it. I will
>> be happy to sign keys of developers given to me that way.
> 
> Last time I talked to Greg about these paper slips, he had trouble
> finding gpg-key2ps on Arch and I prepared the postscript file for him :-D

1. gpg --fingerprint your-name
2. Paste it to a TXT file without the "sub" parts
3. Copy+paste to fill up the page
4. Print and cut

No need for gpg-key2ps.


> 
>> I know that you want to speed it up, but honestly korg keysigning should
>> not have that many participants, so exchanging key slips should be fine
>> as I was doing in the past.
> 
> I think even if we're only 10 in the end, the speedup is noticeable. And
> it also simplifies the actual signing process for everyone, as I will
> provide a keyring of all the handed in certificates.

And now I have one more doubt because Bob, who I did not trust that he
understands security principles of key signing (see my previous email
why), might not verify that keys in above keyring are the ones from the
paper. IOW, Bob will happily sign whatever you send him, to speed things
up. Otherwise there is no speed up comparing to:

$ gpg --recv-key <here goes keyID, which one has to manually type, thus
it is 100% verified>

> 
> If you still want a paper slip from each participant before being ok to
> sign their certificate, that's fine. I'm still convinced that preparing
> the Zimmermann–Sassaman list is a net win. And you're welcome to
> participate no matter if your cert is on the list or not.



Best regards,
Krzysztof

Re: PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 5382 bytes --]

Hello Krzysztof,

On Thu, Aug 06, 2026 at 12:11:06PM +0200, Krzysztof Kozlowski wrote:
> On 05/08/2026 12:29, Uwe Kleine-König wrote:
> > On Wed, Aug 05, 2026 at 08:32:22AM +0200, Krzysztof Kozlowski wrote:
> >> While as much as I like key signing, I do not believe in
> >> Zimmermann–Sassaman protocol to work, because of people's negligence. It
> >> requires the participants to check if THEIR key is correct, but based on
> >> my recent practice (people generated new key and week later they lost
> >> password to it; people received my signed keys and could not decrypt the
> >> message because they never used encrypted email, people sent me emails
> >> asking to send their keys) I think it has significant risk of this not
> >> happening. People just do not understand the security principles here
> >> thus they do not think certain steps are an absolute requirement.
> > 
> > I see your point. However if Bob confirms his fingerprint on the
> > Zimmermann–Sassaman list is right while he didn't actually checked and
> > as an effect a forged certificate is signed, that's mostly Bob's
> > problem.
> > 
> > Also if Bob doesn't check his own fingerprint, he probably also doesn't
> > check the certificates he signs carefully and thus his signatures
> > shouldn't be trusted.
> > 
> > That's why a keysigning is about a *web* of trust where the (little?)
> > trust in each individual path between me and a given other person sums
> > up.
> 
> I am rather thinking of someone planting their key in place of the
> person's one, thus of course Bob will have a problem, but bigger problem
> is that I would sign malicious actor's key.

Yeah, I got that. And that probably helps the attacker that Alice has
confidence in Bob's alleged key and thus that's also bad for Alice and
might come with a loss of trust into your and my signature.

But note that this isn't unfixable for eternity. You can still revoke
your signature once the fraud becomes known to you.

> >> IOW, I do not believe people will check their key fingerprints and email
> >> IDs, they will gladly accept what you prepared on the server and that
> >> could have been modified by an attacker or mischievous actor wanting to
> >> prank us.

I already wondered if I should delete 2 or 3 random nibbles in each
fingerprint on the list (e.g. making my line

      0D25 11_3 22BF AB1C 1580  266_ E2DC DD91 _266 9BD6

instead of

      0D25 11F3 22BF AB1C 1580  266B E2DC DD91 3266 9BD6

such that I have to tell "F-B-3" additionally to convince the potential
signer that I really checked my fingerprint).

> >> That's why I require that the keys to be given to me must be prepared by
> >> that owner, not by a third party. I have some proofs that at least that
> >> key was in the possession of the owner, when he was preparing it. I will
> >> be happy to sign keys of developers given to me that way.
> > 
> > Last time I talked to Greg about these paper slips, he had trouble
> > finding gpg-key2ps on Arch and I prepared the postscript file for him :-D
> 
> 1. gpg --fingerprint your-name
> 2. Paste it to a TXT file without the "sub" parts
> 3. Copy+paste to fill up the page
> 4. Print and cut
> 
> No need for gpg-key2ps.

There is no *need* for gpg-key2ps, but it's convenient that you can just
do

1. gpg-key2ps ukleinek@kernel.org > mycert.ps
2. Print and cut

instead of your four steps above. (Actually I would recommend a step 1.5
in both your and my recipe to double check the output before further
processing, or at least use the fingerprint instead of your-name or the
email address.)

> >> I know that you want to speed it up, but honestly korg keysigning should
> >> not have that many participants, so exchanging key slips should be fine
> >> as I was doing in the past.
> > 
> > I think even if we're only 10 in the end, the speedup is noticeable. And
> > it also simplifies the actual signing process for everyone, as I will
> > provide a keyring of all the handed in certificates.
> 
> And now I have one more doubt because Bob, who I did not trust that he
> understands security principles of key signing (see my previous email
> why), might not verify that keys in above keyring are the ones from the
> paper. IOW, Bob will happily sign whatever you send him, to speed things
> up. Otherwise there is no speed up comparing to:
> 
> $ gpg --recv-key <here goes keyID, which one has to manually type, thus
> it is 100% verified>

`gpg --recv-key` has its own problems. You can use it with a full
fingerprint, but the Bob you talk about will probably use it with the
"long id", i.e. only the last 16 nibbles of the fingerprint (assuming
pgpv4). And it also doesn't give you 3rd party signatures which might
give a hint that the received certificate is valid without exposing you
to Certificate Flooding[1].

So getting the certificates to sign from a curated source (like the
keyring I'll provide, or WKD or the kernel pgpkeys repo or DNS) also has
its upsides. And I encourage you to not rely on my key collection, but
cross check it. But the effort to find a certain key and convince
yourself it's not forged obviously grows. So this is another trade-off
between security and comfort.

[1] https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [workflows]PGP keysigning at LPC/OSSE 2026

[Steven Rostedt]

On Tue, 4 Aug 2026 17:43:40 +0200
Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:

> The gatherings will be on Tue 2026-10-06 and Thu 2026-10-08 (that is on
> the second day of each conference) after the official program.

We will likely be having a memorial for Dan Williams after the official
program ends on Tuesday. Please have it after that.

Thanks,

-- Steve

Re: [workflows]PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Hello Steve,

On Thu, Aug 06, 2026 at 12:57:02PM -0400, Steven Rostedt wrote:
> On Tue, 4 Aug 2026 17:43:40 +0200
> Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:
> 
> > The gatherings will be on Tue 2026-10-06 and Thu 2026-10-08 (that is on
> > the second day of each conference) after the official program.
> 
> We will likely be having a memorial for Dan Williams after the official
> program ends on Tuesday. Please have it after that.

I defintively don't want to interfere with that. Thanks for letting me
know.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]