All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: redoste <redoste@redoste.xyz>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Fabian Stelzer <fs@gigacodes.de>,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] ssh signing: don't detach the filename strbuf from key_file tempfile
Date: Sat, 5 Jul 2025 20:07:38 +0000	[thread overview]
Message-ID: <aGmGCmkwC1HlSyog@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <20250705192113.GB2496172@coredump.intra.peff.net>

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

On 2025-07-05 at 19:21:13, Jeff King wrote:
> On Sat, Jul 05, 2025 at 01:08:28AM +0200, redoste wrote:
> 
> > Detaching the filename string from the tempfile structure used to cause
> > delete_tempfile() to fail and the temporary file was not cleaned up.
> 
> Good catch. I can reproduce this easily with:
> 
>   git -c gpg.format=ssh \
>       -c user.signingkey=key::does-not-exist \
>       commit --allow-empty -S -m foo
> 
> which creates /tmp/.git_signing_key_tmp* and never cleans it up.
> 
> I wonder if it is worth adding a test, or if it would be too weirdly
> focused on this obscure case to be very useful against future
> regressions.

I don't have a strong view either way, but I do wonder if it's a good
idea to have the testsuite poking around in `/tmp`, although maybe if we
honour `TMPDIR` then it would be possible to do in a tidy way.

> > Signed-off-by: redoste <redoste@redoste.xyz>
> 
> We look for a real name in the sign-off trailer, since it indicates an
> acceptance of the DCO and the ability to legally contribute the patch to
> the project. See the section of Documentation/SubmittingPatches starting
> with the '[[dco]]'. Or here:
> 
>   https://git-scm.com/docs/SubmittingPatches#sign-off
> 
> Looking at your web page, it looks like you may prefer not to associate
> your online identity with a legal name. I can't remember if we've dealt
> with this before. I'm adding brian to the cc, who has given a lot of
> thought to naming and privacy issues.

I don't know if we have a strict policy.  I do know that there are
developers who always go by a pseudonym, such as chromatic[0], the
contributor to Perl, and obviously we'd want to allow them to
contribute. We also let people use shortened forms of their names or
initials (for instance, Jeff King).

I also have some friends who are trans and have transitioned or are in
the process of transitioning but have simply not gotten around to
getting legal paperwork done[1].  Obviously they have a distinct and
identifiable name that they go by and we'd allow them to use a preferred
name.

There might also be good reasons that a contributor might not want to
use a legal name: harassment, threats, employer hostility, fame[2], or a
hostile government, to name a few.  I think those are legitimate reasons
to contribute pseudonymously.

So I would say that if someone has a distinct and identifiable identity
that is pseudonymous and that is generally used and visible in the
public sphere online, that's probably good enough.  While I'm not a
lawyer, it's my understanding that in many locales, making a legal
promise of sorts (such as a sign-off) is equally binding whether made
with one's real name or a pseudonym, so I don't see a problem with the
legal aspect of it.

[0] https://en.wikipedia.org/wiki/Chromatic_(programmer)
[1] In some locales this involves hiring an attorney, getting paperwork
from a doctor, and getting a court order, so it can be expensive and
kind of a hassle to do.  It may also not be legally possible to do that
in some places.
[2] Notably the frontman of the band Weezer, Rivers Cuomo, is involved
in coding under his real name (https://github.com/riverscuomo), but
perhaps a CEO, musician, actor, or other famous person might not want
their open-source contributions to be associated with their real name.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

  reply	other threads:[~2025-07-05 20:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-04 23:08 [PATCH] ssh signing: don't detach the filename strbuf from key_file tempfile redoste
2025-07-05 19:21 ` Jeff King
2025-07-05 20:07   ` brian m. carlson [this message]
2025-07-05 22:50     ` redoste
2025-07-05 23:04       ` redoste
2025-07-06  0:28       ` brian m. carlson
2025-07-06  3:13         ` Jeff King
2025-07-06 17:20           ` redoste
2025-07-06 17:14         ` redoste
2025-07-06 17:34 ` [PATCH v2] " redoste
2025-07-06 21:21   ` brian m. carlson
2025-07-07  9:02   ` Patrick Steinhardt
2025-07-07  9:35     ` Phillip Wood
2025-07-07 14:25       ` redoste
2025-07-07 15:26         ` Phillip Wood
2025-07-07 16:22           ` redoste
2025-07-07 16:42             ` Phillip Wood
2025-07-07 18:48 ` [PATCH v3] " redoste
2025-07-07 20:57   ` Junio C Hamano
2025-07-08  6:47     ` Patrick Steinhardt
2025-07-08 13:59       ` Phillip Wood

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=aGmGCmkwC1HlSyog@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=fs@gigacodes.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=redoste@redoste.xyz \
    /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.