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

Re: PGP keysigning at LPC/OSSE 2026

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 2119 bytes --]

Hello,

now that the registration deadline is over here comes the list
containing the registered participants in the attachment. In case of
transfer issues (e.g. MTAs reencoding the text file), the list is also
available at

	https://openpgpkey.baylibre.com/Fei9keem/keysigning-lpcosse26.txt

.

In reply to Krzysztof's concern about how trustworthy a statement
"yesyes, the fingerprint of my certificate on the list that this
suspicious guy created is correct" I dropped the two middle nibbles from
each fingerprint. So you can support your statement about your
fingerprint by providing these two.

Please print out the list, fill in the hash sums (which we will verify
when we meet), verify your fingerprint and memorize (or write down) the
missing nibbles (if you're on the list) and bring the list to the
meetings together with a pen and a proof of identity (as most people
will probably want to see such a document before certifying your UIDs).
If your hand writing is poor, I recommend filling in the hash sum before
printing. Note that the start of the SHA256 hash sum is already
prefilled, that prefill has to be kept as is when generating the hashes.

For people having missed the registration deadline: You can still bring
the prepared list and at least benefit partly from the simplification it
yields. For getting signatures I recommend bringing paper slips with
your UIDs and fingerprint. gpg-key2ps can create such paper slips. It
might be sensible to bring a few of those even if you're on the list for
those who attend the events without preparation.

We'll meet on Tue (2026-10-06) and Thu (2026-10-08) after the scheduled
conference events (Tue: ~ 19:50, Thu: ~ 18:30). We will meet outside the
conference venue, in case I manage to organise a room, someone at the
main exit will know.

For the procedure to actually sign the certificates, see
https://baylibre.com/blog/pgp-keysigning-2/. A bundle of all
certificates on the list is available at

	https://openpgpkey.baylibre.com/Fei9keem/keysigning-lpcosse26.pgp

If questions arise, don't hesitate to ask.

Looking forward to see you in Prague!
Uwe

[-- Attachment #1.2: keysigning-lpcosse26.txt --]
[-- Type: text/plain, Size: 11591 bytes --]

     K E Y S I G N I N G   A T   L P C   A N D   O S S E   2 0 2 6 

                     List of Participants  (v 1.0)


Here's what you have to do with this file:

(1) Print this UTF-8 encoded file to paper.

(2) Verify your own fingerprint and know the two skipped nibbles.

(3) Compute this file's SHA256 and RIPEMD160 checksums.

      gpg --print-md SHA256 keysigning-lpcosse26.txt
      gpg --print-md RIPEMD160 keysigning-lpcosse26.txt

(4) Fill in the hash values on the printout.

(5) Bring the printout, a pen, and proof of identity to the key signing event.


SHA256 Checksum: 4E4F BA__   ____ ____   ____ ____   ____ ____

                 ____ ____   ____ ____   ____ ____   ____ ____              [ ]

RIPEMD160 Checksum: ____ ____ ____ ____ ____    ____ ____ ____ ____ ____    [ ]



001  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2026-09-15 [SC] [expires: 2030-09-14]
      FDFB 31C6 6E06 9650 D4A_  _096 B796 1F12 E964 645C
uid                      Albert Esteve <aesteve@redhat.com>

_______________________________________________________________________________

002  [ ] Fingerprint OK        [ ] ID OK
pub   ed25519 2025-09-03 [SC]
      A46D 3270 5865 AA3D DED_  _904 B7D2 DD27 5D7E C087
uid                      Brian Masney <bmasney@redhat.com>
uid                      Brian Masney <masneyb@gmail.com>
uid                      Brian Masney <masneyb@kernel.org>
uid                      Brian Masney <masneyb@onstation.org>

_______________________________________________________________________________

003  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2017-03-14 [SC] [expires: 2027-09-07]
      B3F2 469D 78D7 8BD0 9D3_  _F37 C940 35C2 1B4F 2AEB
uid                      Chen-Yu Tsai <wens@csie.org>
uid                      Chen-Yu Tsai <wens@freedesktop.org>
uid                      Chen-Yu Tsai <wens@kernel.org>
uid                      Chen-Yu Tsai <wenst@chromium.org>

_______________________________________________________________________________

004  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2021-05-17 [C] [expires: 2029-09-12]
      3B0A 53B1 D9DF 6AAC 59C_  _032 2A82 1C5A D66A B03F
uid                      David Gow <david@davidgow.net>
uid                      David Gow <david@ingeniumdigital.com>

_______________________________________________________________________________

005  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2013-07-01 [SCEA] [expires: 2027-06-25]
      528E 04A3 85E1 7DE8 6C1_  _384 9190 FDF5 234F E25C
uid                      David Gstir <david@sigma-star.at>

_______________________________________________________________________________

006  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2018-07-20 [SC] [expires: 2029-01-18]
      EB39 7C1F F130 EC7D 01E_  _445 02C7 A73D 84B0 447C
uid                      Eric Biggers <ebiggers@kernel.org>
uid                      Eric Biggers <ebiggers3@gmail.com>
uid                      Eric Biggers <ebiggers@google.com>

_______________________________________________________________________________

007  [ ] Fingerprint OK        [ ] ID OK
pub   ed25519 2026-07-29 [C] [expires: 2029-07-28]
      3CBC 2E67 5950 5DDD 089_  _514 E5DD 4DD9 6618 E621
uid                      Eric Chanudet <echanude@redhat.com>

_______________________________________________________________________________

008  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2026-09-17 [C] [expires: 2029-09-16]
      957E E65D 815B F6AF 886_  _467 0FEA 804F 4B07 2450
uid                      Francois Dugast <francois.dugast@intel.com>
uid                      François Dugast <francois@dugast.eu>

_______________________________________________________________________________

009  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2011-10-09 [SC] [expires: 2027-10-10]
      750D 82B0 A781 5431 5E2_  _25B 4804 B4BC 3F55 EEFB
uid                      Geert Uytterhoeven <geert@linux-m68k.org>
uid                      Geert Uytterhoeven (Glider bv) <geert@glider.be>
uid                      Geert Uytterhoeven (Glider bvba) <geert@glider.be>
uid                      Geert Uytterhoeven <Geert.Uytterhoeven@gmail.com>

_______________________________________________________________________________

010  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2017-03-04 [SC] [expires: 2028-09-18]
      F29F 26CF 27BA E1A9 719_  _6BD C3C9 2AAF 3E60 AED9
uid                      Jerome Brunet <jerome.brunet@gmail.com>
uid                      Jerome Brunet <jbrunet@baylibre.com>
uid                      Jerome Brunet <jbrunet@kernel.org>
uid                      Jerome Brunet <jerome@liltaz.com>

_______________________________________________________________________________

011  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2015-02-05 [SC] [expires: 2029-07-21]
      EC38 9CAB C2C4 F25D 860_  _0D0 0393 969D 2D76 0850
uid                      Johannes Thumshirn <jth@kernel.org>
uid                      Johannes Thumshirn <johannes@thumshirn-home.de>
uid                      Johannes Thumshirn <morbid@erlangen.ccc.de>
uid                      Johannes Thumshirn <morbidrsa@gmail.com>

_______________________________________________________________________________

012  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2026-06-05 [C] [expires: 2029-06-04]
      AB4C 460A 88D9 2792 88E_  _F93 29C9 3EA3 499D 9626
uid                      Joshua Crofts <joshua.crofts1@gmail.com>

_______________________________________________________________________________

013  [ ] Fingerprint OK        [ ] ID OK
pub   ed25519 2026-09-04 [C] [expires: 2028-09-03]
      DEF5 E89D 3A6C 6B7C 394_  _AA9 0664 101D 2FC2 52D1
uid                      Julian Braha <julianbraha@gmail.com>

_______________________________________________________________________________

014  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2011-10-04 [SC]
      7B87 460E 1692 7FA9 F5B_  _10C 5937 189A D3FB C665
uid                      Kevin Hilman <khilman@kernel.org>
uid                      Kevin Hilman <khilman@baylibre.com>
uid                      Kevin Hilman <khilman@gmail.com>

_______________________________________________________________________________

015  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2020-08-21 [SC]
      536E 227F DA02 2F6C DD0_  _415 4787 0172 0E5D 7C58
uid                      Konrad Dybcio <konradybcio@gmail.com>
uid                      Konrad Dybcio <konrad.dybcio@linaro.org>
uid                      Konrad Dybcio <konradybcio@kernel.org>

_______________________________________________________________________________

016  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2014-10-09 [C]
      9423 1B98 0100 EC61 9AC_  _E10 F045 C2B9 6991 256E
uid                      Laurent Pinchart <laurent.pinchart@ideasonboard.com>

_______________________________________________________________________________

017  [ ] Fingerprint OK        [ ] ID OK
pub   rsa2048 2017-06-13 [SC]
      F47B 9A62 76E6 0E1A BF5_  _0C8 256A EA18 47BD 5684
uid                      Miquel RAYNAL <mraynal@kernel.org>
uid                      Miquel RAYNAL <miquel.raynal@bootlin.com>
uid                      Miquel RAYNAL <miquel@bootlin.com>
uid                      Miquel RAYNAL <raynal.miquel@gmail.com>

_______________________________________________________________________________

018  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2019-03-18 [SC]
      AE5D 7188 6C73 A299 FB8_  _6F3 BFDC 09C1 F24D FA45
uid                      Miquel RAYNAL <miquel.raynal@bootlin.com>

_______________________________________________________________________________

019  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2014-11-10 [SC] [expires: 2027-03-09]
      18ED 52DB E34F 860E E9F_  _82B 7D97 0932 55A0 CE7F
uid                      Nicolas Schier <nicolas@fjasle.eu>
uid                      Nicolas Schier <nicolas.schier@linux.dev>
uid                      Nicolas Schier <nicolas.schier@yahoo.no>
uid                      Nicolas Schier <nsc@kernel.org>

_______________________________________________________________________________

020  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2011-09-29 [SC]
      BF73 94DF F6F2 31A0 342_  _589 7647 E1A4 4BC0 E4BA
uid                      Peter Zijlstra <peterz@infradead.org>

_______________________________________________________________________________

021  [ ] Fingerprint OK        [ ] ID OK
pub   ed25519 2026-07-28 [SC]
      9BE0 4FAA A235 EFE7 CDE_  _22F AC2F A78C 94A9 17EC
uid                      Rafael J. Wysocki (Other) <rjw@rjwysocki.net>
uid                      Rafael J. Wysocki (Linux Kernel) <rafael@kernel.org>
uid                      Rafael J. Wysocki (Personal) <rjwysocki@gmail.com>

_______________________________________________________________________________

022  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2010-10-11 [SC]
      EF66 0D07 463F 8B72 6A7_  _413 D8EE D7F3 C83B FA9A
uid                      Sebastian Reichel <sre@ring0.de>
uid                      Sebastian Reichel (xmpp) <sre@xmpp.ring0.de>
uid                      Sebastian Reichel <elektranox@gmail.com>
uid                      Sebastian Reichel <sebastian.reichel@collabora.com>
uid                      Sebastian Reichel <sre@debian.org>
uid                      Sebastian Reichel <sre@kernel.org>
uid                      Sebastian Reichel <sre@mainframe.io>

_______________________________________________________________________________

023  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2024-11-19 [C] [expires: 2026-11-19]
      A3A9 D4BD AB10 6981 1F4_  _30E B0D5 89D4 6708 EC99
uid                      Trevor Gamblin <tgamblin@baylibre.com>
uid                      Trevor Gamblin <tgamblin@ecocode.ca>
uid                      Trevor Gamblin <tvgamblin@gmail.com>

_______________________________________________________________________________

024  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2010-06-15 [SC] [expires: 2027-06-21]
      0D25 11F3 22BF AB1C 1580  266B E2DC DD91 3266 9BD6
uid                      Uwe Kleine-König <uwe@kleine-koenig.org>
uid                      Uwe Kleine-König <u.kleine-koenig@baylibre.com>
uid                      Uwe Kleine-König <ukleinek@debian.org>
uid                      Uwe Kleine-König <ukleinek@kernel.org>
uid                      Uwe Kleine-König <ukleinek@lug-freiburg.de>
uid                      Uwe Kleine-König <ukleinek@strlen.de>
uid                      Uwe Kleine-König <uwe@kleine-könig.de>

_______________________________________________________________________________

025  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2015-12-01 [SC] [expires: 2030-03-04]
      A940 D434 992C 2E8E 991_  _D50 224F A7E7 CC82 A664
uid                      Vlastimil Babka <vbabka@suse.com>
uid                      Vlastimil Babka <vbabka@kernel.org>
uid                      Vlastimil Babka <vbabka@suse.cz>

_______________________________________________________________________________

026  [ ] Fingerprint OK        [ ] ID OK
pub   rsa4096 2026-09-03 [C]
      2582 F5D6 BC86 8798 0F3_  _CF1 FEAF 321A 8F08 C9B3
uid                      Waqar Hameed <whame@whame.dev>
uid                      Waqar Hameed <waqar.hameed@axis.com>

_______________________________________________________________________________

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