Re: Please add key for Vineet Gupta (ARC maintainer)

Uwe Kleine-König <[email protected]> Mon, 16 Jun 2025 10:46:45 +0200
Newsgroups	org.kernel.linux.keys
Message-ID	<2bcs4mgkrycgqfydfxt3cucw2cd6vvbpq3snbsprf27fyc72hd@ihikzjxerftf>
Hello Vineet,

On Fri, Jun 13, 2025 at 11:09:26AM -0700, Vineet Gupta wrote:
> On 6/13/25 02:49, Uwe Kleine-König wrote:
> > On Thu, Jun 12, 2025 at 02:52:52PM -0700, Vineet Gupta wrote:
> >>
> >> On 6/12/25 14:08, Konstantin Ryabitsev wrote:
> >>> On Thu, 12 Jun 2025 at 16:59, Vineet Gupta <[email protected]> wrote:
> >>>>> Before creating your next UID is suggest you read
> >>>>> https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html
> >>>> Thx for the pointer. It makes sense.
> >>>> Shall I remove them from existing key and send it over again (I see it hasn't
> >>>> been pushed yet to the repo)
> >>> Yes, if you want to do that, I will hold off on processing this request.
> >> Thx, here you go !
> >>
> >> pub   rsa4096 2013-02-16 [SC] [expires: 2029-12-08]
> >>       397A6E0AE47A85E76B74B08969D7F1DDE28AC25E
> >> uid           [ultimate] Vineet Gupta <[email protected]>
> >> uid           [ultimate] Vineet Gupta <[email protected]>
> >> uid           [ultimate] Vineet Gupta <[email protected]>
> >> uid           [ultimate] [jpeg image of size 24452]
> > That looks better now. The scripts used to maintain the kernel keyring
> > will accept that key update, however your new primary UID has no
> > 3rd-party signatures. And also note that the signatures on your older
> > UIDs are all done using SHA-1 so they will be discarded on reimport. In
> > sum there is no valid trust path from Linus to your key.
> >
> > It would be great if you could get a few fresh signatures on your
> > kernel.org UID. The guys who signed your other UIDs earlier might be
> > good candidates to sign that without the need to arrange a meeting in
> > real live.
> 
> Sure thing. I was thinking of asking a couple of my current colleagues (Bjorn,
> Alex) to do that instead. As long as signers are in the web of trust it should
> be fine ?

From the POV of the kernel pgpkeys repo yes, signatures from people
within the keyring are preferable. Still better from those who are
"near" Linus. The graphs generated in the pgpkeys repo only consider
paths of length four, so ideally let it sign by someone with distance <=
3. Not knowing which Bjorn and wich Alex you mean, see e.g.
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/graphs/E2DCDD9132669BD6.svg,
my key has depth 3 as there is a path of length 3 (John Hawley -> Ben
Hutchings -> me) and no shorter.

> > Also your key is affected by SHA-1 self signatures on the older UIDs.
> > The respective output of `sq cert lint` is:
> >
> > 	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (alias) <[email protected]>) protected by SHA-1
> > 	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (official) <[email protected]>) protected by SHA-1
> > 	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (personal) <[email protected]>) protected by SHA-1
> >
> >
> > See
> > https://www.kleine-koenig.org/~uwe/resign-sha1/?certid=69D7F1DDE28AC25E
> > for some details. Also
> > https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/
> > might be good to understand.
> 
> I tried to fix the sha-1 concern, but ran into some issues.
> 
> First up I presume this is all pgp2 as I have that alias in my bashrc from an
> early/old users.kernel.org recommendation.

Not sure what you mean by "pgp2". My links above assume that you use gpg
2.2 or 2.4 which today is usually installed as "gpg" in your PATH.

I'm not entirely sure that the indicated command (i.e.

	gpg --force-sign-key --quick-sign-key 397A6E0AE47A85E76B74B08969D7F1DDE28AC25E "Vineet Gupta (alias) <[email protected]>" "Vineet Gupta (official) <[email protected]>" "Vineet Gupta (personal) <[email protected]>";

) also works for self-signatures. The test is:

	$ sq cert lint --cert=69D7F1DDE28AC25E
	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (alias) <[email protected]>) protected by SHA-1
	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (official) <[email protected]>) protected by SHA-1
	Certificate 69D7F1DDE28AC25E contains a User ID (Vineet Gupta (personal) <[email protected]>) protected by SHA-1
	Examined 1 certificate.
	  0 certificates are invalid and were not linted. (GOOD)
	  1 certificate was linted.
	  1 of the 1 certificates (100%) has at least one issue. (BAD)
	0 of the linted certificates were revoked.
	  0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
	0 of the linted certificates were expired.
	1 of the non-revoked linted certificate has at least one non-revoked User ID:
	  1 has at least one User ID protected by SHA-1. (BAD)
	  0 have all User IDs protected by SHA-1. (GOOD)
	0 of the non-revoked linted certificates have at least one non-revoked, live subkey:
	  0 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (GOOD)
	0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
	  0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)

	  Error: 1 certificate have at least one issue

If the above command doesn't work, `sq cert lint --fix
--cert=69D7F1DDE28AC25E` should do the trick for sure.

> Per your link [1] above I was able to refetch the keys of others, force sign
> them and --send-key
> However my refetched key brought back the locally deleted old UIDs: was it
> because I had not uploaded it to Ubuntu key server, and MIT server where I did,
> is no longer functional / used ?

No, the "problem" is that keyservers don't forget. So you need to revoke
the UIDs if you really want to get rid of them. It's a feature that you
got it back. If I fetch your key after you added the UIDs I want the new
UIDs just added to your key. That's what happend for you, too, as there
is no way to distinguish between "the fetcher doesn't know the new UIDs
yet" and "oopsie, the fetcher thought these UIDs are wrong and deleted
them".

> Anyhow do the older/deleted UIDs need to be sha-1 fixed  and then re-deleted and
> --send-key to ubuntu key server?

When you re-sign a UID, the old signature doesn't go away, it is just
not considered any more as there is a newer one.

> Or is there a different order of things to do - apologies for these noob questions.

No problem. I bet you're not the only one who will have such questions
while fixing their keys.

Also I don't understand all the things about your key yet either.

Best regards
Uwe
signature.asc (application/pgp-signature, 488 B)