All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Willy Tarreau <w@1wt.eu>
Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>, keys@linux.kernel.org
Subject: Re: SHA1 bindings in your PGP key 4E386D9C9C61702F
Date: Wed, 10 Sep 2025 09:16:14 -0400	[thread overview]
Message-ID: <20250910-finicky-famous-wolverine-ee51dd@lemur> (raw)
In-Reply-To: <20250910064058.GB30457@1wt.eu>

On Wed, Sep 10, 2025 at 08:40:58AM +0200, Willy Tarreau wrote:
> > The issue is that the proofs about your UID and your subkey
> > 014180C7E8419672 belonging to your main key 4E386D9C9C61702F rely on
> > SHA-1 hashes which is considered weak since at least 2005[1]. Practical
> > breakage is not known yet, but still I recommend to update your key to a
> > safer hash algorithm to reduce attacking surface.
> 
> Hmmm unless I'm missing something, these serve to sign tags designating
> a commit that itself relies on SHA-1, no ? So in this case if we don't
> trust the keys anymore because we consider them weak, we shouldn't trust
> the tags nor the commits either ?

Well, there is collision detection code in git to prevent a lot of badness
associated with that attack, and nothing like that in PGP (not sure that's
even possible). So, I wouldn't treat these two problems as the same.

> > Find more details at
> > https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
> > which also describes a procedure to (hopefully) fix your key.
> 
> Thank you. I must admit I'm a bit lost by the complexity of these
> operations, especially since I don't understand their impact. Does
> this mean that my key that was previously signed will change if I
> do that, and that as such it will have to be signed again ? What
> should I backup before entering these operations in case things go
> wrong or if I simply do a mistake ? I never understand even the
> questions in GPG, so I tend to randomly respond until it works.

It should not impact your signatures in any way, it will just recreate the
certificate that pairs your identity to your primary key.

If you want to feed to birds with one scone, you can just add your kernel.org
identity to your key and then reset your 1wt.eu identity as primary:

    gpg --quick-add-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <wtarreau@kernel.org>'
    gpg --quick-set-primary-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <w@1wt.eu>'

This will make your key discoverable via the kernel.org WKD and fix the
problem with the SHA1 signature.

You then just need to send me the updated key export.

Hope that helps!

-K

  reply	other threads:[~2025-09-10 13:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 10:03 SHA1 bindings in your PGP key 4E386D9C9C61702F Uwe Kleine-König
2025-09-10  6:40 ` Willy Tarreau
2025-09-10 13:16   ` Konstantin Ryabitsev [this message]
2025-09-10 13:23     ` Willy Tarreau
2025-09-11  8:36   ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250910-finicky-famous-wolverine-ee51dd@lemur \
    --to=konstantin@linuxfoundation.org \
    --cc=keys@linux.kernel.org \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.