* [DISCUSS] validation on git config user.email
@ 2025-09-12 4:13 usharerose
2025-09-12 15:00 ` rsbecker
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: usharerose @ 2025-09-12 4:13 UTC (permalink / raw)
To: git
Hi, Git Community,
I'm a Git user and curious about a specific aspect of Git's design
regarding the 'user.email' configuration.
Git allows any kind of values without restriction when setting
'user.email' via 'git config' (e.g., `git config user.email
"not-a-valid-email-address"`).
I'm interested in understanding the design philosophy or historical
reasons behind this 'lack' of validation.
I've glanced through the documentations, archived emails, or forum
topics, but couldn't find a definitive or official statement.
Thanks for your time and insights.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [DISCUSS] validation on git config user.email
2025-09-12 4:13 [DISCUSS] validation on git config user.email usharerose
@ 2025-09-12 15:00 ` rsbecker
2025-09-12 16:29 ` Junio C Hamano
` (2 more replies)
2025-09-12 15:13 ` Konstantin Ryabitsev
` (2 subsequent siblings)
3 siblings, 3 replies; 14+ messages in thread
From: rsbecker @ 2025-09-12 15:00 UTC (permalink / raw)
To: 'usharerose', git
On September 12, 2025 12:13 AM, usharerose wrote:
>I'm a Git user and curious about a specific aspect of Git's design regarding the
>'user.email' configuration.
>
>Git allows any kind of values without restriction when setting 'user.email' via 'git
>config' (e.g., `git config user.email "not-a-valid-email-address"`).
>
>I'm interested in understanding the design philosophy or historical reasons behind
>this 'lack' of validation.
>
>I've glanced through the documentations, archived emails, or forum topics, but
>couldn't find a definitive or official statement.
>
>Thanks for your time and insights.
Some customers integrate single sign-on (SSO) via the user.email value. In the case
of one customer I helped, the value is an SSO token used by GitHub for their
integration. The token value does not conform to any valid email address format.
Adding an email validation will lock them out of using git.
--Randall
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 4:13 [DISCUSS] validation on git config user.email usharerose
2025-09-12 15:00 ` rsbecker
@ 2025-09-12 15:13 ` Konstantin Ryabitsev
2025-09-12 15:39 ` Thomas Guyot
2025-09-14 11:58 ` Kristoffer Haugsbakk
3 siblings, 0 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2025-09-12 15:13 UTC (permalink / raw)
To: usharerose; +Cc: git
On Fri, Sep 12, 2025 at 12:13:07PM +0800, usharerose wrote:
> Hi, Git Community,
>
> I'm a Git user and curious about a specific aspect of Git's design
> regarding the 'user.email' configuration.
>
> Git allows any kind of values without restriction when setting
> 'user.email' via 'git config' (e.g., `git config user.email
> "not-a-valid-email-address"`).
That's a valid email address on the local system. It will get expanded into
not-a-valid-email-address@localhost (or whatever domain is configured with the
local MTA).
> I'm interested in understanding the design philosophy or historical
> reasons behind this 'lack' of validation.
This may be insightful: https://e-mail.wtf
:)
-K
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 4:13 [DISCUSS] validation on git config user.email usharerose
2025-09-12 15:00 ` rsbecker
2025-09-12 15:13 ` Konstantin Ryabitsev
@ 2025-09-12 15:39 ` Thomas Guyot
2025-09-12 18:02 ` usharerose
2025-09-14 11:58 ` Kristoffer Haugsbakk
3 siblings, 1 reply; 14+ messages in thread
From: Thomas Guyot @ 2025-09-12 15:39 UTC (permalink / raw)
To: usharerose, git
On 2025-09-12 00:13, usharerose wrote:
>
> I'm interested in understanding the design philosophy or historical
> reasons behind this 'lack' of validation.
>
Hi usharerose,
To add to the other valid responses, email is something that can be
validated by hooks server-side to enforce not only proper formatting but
also valid users are being used, ex. validating against an LDAP directory.
This is much better that validating it at the command level (although
IIRC git-comit does warn about possibly unset/invalid email addresses).
In addition, unless git starts enforcing stricter rules on the commit
message format (which would be a breaking change), nothing else can
prevent someone from constructing commits with invalid emails, so checks
by git-commit alone can't be strictly enforceable.
Furthermore, imported commits from other SCMs may have odd user
name/email and it may be desirable to keep then in their original
formats rather than turning them into fake email addresses.
Regards,
--
Thomas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 15:00 ` rsbecker
@ 2025-09-12 16:29 ` Junio C Hamano
2025-09-12 18:06 ` usharerose
2025-09-12 16:52 ` usharerose
2025-09-14 11:17 ` Kristoffer Haugsbakk
2 siblings, 1 reply; 14+ messages in thread
From: Junio C Hamano @ 2025-09-12 16:29 UTC (permalink / raw)
To: rsbecker; +Cc: 'usharerose', git
<rsbecker@nexbridge•com> writes:
> Some customers integrate single sign-on (SSO) via the user.email value. In the case
> of one customer I helped, the value is an SSO token used by GitHub for their
> integration. The token value does not conform to any valid email address format.
> Adding an email validation will lock them out of using git.
That is a very good point. We need to remember that not all users
use the value of the field we define to be "email" to send emails
to, just like some people use "name" field to store something that
is not their name.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 15:00 ` rsbecker
2025-09-12 16:29 ` Junio C Hamano
@ 2025-09-12 16:52 ` usharerose
2025-09-12 17:23 ` rsbecker
2025-09-14 11:17 ` Kristoffer Haugsbakk
2 siblings, 1 reply; 14+ messages in thread
From: usharerose @ 2025-09-12 16:52 UTC (permalink / raw)
To: rsbecker; +Cc: git
On Fri, Sep 12, 2025 at 11:00 PM <rsbecker@nexbridge•com> wrote:
> Some customers integrate single sign-on (SSO) via the user.email value. In the case
> of one customer I helped, the value is an SSO token used by GitHub for their
> integration. The token value does not conform to any valid email address format.
> Adding an email validation will lock them out of using git.
Thanks for your reply, Randall.
I've fully understood the scenario you described. My follow-up
question is: was this use case something that was discovered and
utilized later because people found that Git doesn't validate the
email format, or was it a scenario that the architects anticipated
early on in the project's history, leading to the deliberate decision
to skip the validation for flexibility?
In other words, is this more of a case of "exploiting a perceived
backdoor that later became justified" or "a thoughtfully made design
decision from the beginning"?
Thanks again for sharing your insight.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [DISCUSS] validation on git config user.email
2025-09-12 16:52 ` usharerose
@ 2025-09-12 17:23 ` rsbecker
2025-09-12 17:44 ` usharerose
0 siblings, 1 reply; 14+ messages in thread
From: rsbecker @ 2025-09-12 17:23 UTC (permalink / raw)
To: 'usharerose'; +Cc: git
On September 12, 2025 12:52 PM, usharerose wrote:
>On Fri, Sep 12, 2025 at 11:00 PM <rsbecker@nexbridge•com> wrote:
>> Some customers integrate single sign-on (SSO) via the user.email
>> value. In the case of one customer I helped, the value is an SSO token
>> used by GitHub for their integration. The token value does not conform to any
>valid email address format.
>> Adding an email validation will lock them out of using git.
>
>Thanks for your reply, Randall.
>
>I've fully understood the scenario you described. My follow-up question is: was this
>use case something that was discovered and utilized later because people found
>that Git doesn't validate the email format, or was it a scenario that the architects
>anticipated early on in the project's history, leading to the deliberate decision to skip
>the validation for flexibility?
>
>In other words, is this more of a case of "exploiting a perceived backdoor that later
>became justified" or "a thoughtfully made design decision from the beginning"?
>
>Thanks again for sharing your insight.
I cannot answer decisively. The functionality was first used in this customer about
four years ago. I do not think any changes were required in git to accomplish this.
It is possible GitHub had to have an enhancement but only they can answer that.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 17:23 ` rsbecker
@ 2025-09-12 17:44 ` usharerose
0 siblings, 0 replies; 14+ messages in thread
From: usharerose @ 2025-09-12 17:44 UTC (permalink / raw)
To: rsbecker; +Cc: git
On Sat, Sep 13, 2025 at 1:23 AM <rsbecker@nexbridge•com> wrote:
> I cannot answer decisively. The functionality was first used in this customer about
> four years ago. I do not think any changes were required in git to accomplish this.
> It is possible GitHub had to have an enhancement but only they can answer that.
Appreciate you sharing what you know, Randall. My intention behind the
original question was not to suggest adding validation for email
legitimacy, but rather to inquire about and understand the rationale
behind the initial design decision to forgo strict validation when the
user identity feature (user.email) was implemented.
I will try to find answers from other sources of information.
Thank you again for your help.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 15:39 ` Thomas Guyot
@ 2025-09-12 18:02 ` usharerose
0 siblings, 0 replies; 14+ messages in thread
From: usharerose @ 2025-09-12 18:02 UTC (permalink / raw)
To: Thomas Guyot; +Cc: git
On Fri, Sep 12, 2025 at 11:39 PM Thomas Guyot <tguyot@gmail•com> wrote:
> To add to the other valid responses, email is something that can be
> validated by hooks server-side to enforce not only proper formatting but
> also valid users are being used, ex. validating against an LDAP directory.
>
> This is much better that validating it at the command level (although
> IIRC git-comit does warn about possibly unset/invalid email addresses).
> In addition, unless git starts enforcing stricter rules on the commit
> message format (which would be a breaking change), nothing else can
> prevent someone from constructing commits with invalid emails, so checks
> by git-commit alone can't be strictly enforceable.
>
> Furthermore, imported commits from other SCMs may have odd user
> name/email and it may be desirable to keep then in their original
> formats rather than turning them into fake email addresses.
Thanks for your detailed reply, Thomas. I've understood the scenarios
you mentioned.
My intention behind the original question was not to suggest adding
the feature of validation for email legitimacy, but rather to inquire
about and understand the rationale behind the initial design decision
to forgo strict validation when the user identity feature (user.email)
was implemented.
So, are the use cases above mentioned more of a case of "exploiting a perceived
backdoor that later became justified" or "a thoughtfully made design
decision from the beginning"?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 16:29 ` Junio C Hamano
@ 2025-09-12 18:06 ` usharerose
0 siblings, 0 replies; 14+ messages in thread
From: usharerose @ 2025-09-12 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: rsbecker, git
On Sat, Sep 13, 2025 at 12:29 AM Junio C Hamano <gitster@pobox•com> wrote:
> That is a very good point. We need to remember that not all users
> use the value of the field we define to be "email" to send emails
> to, just like some people use "name" field to store something that
> is not their name.
Thanks for your reply, Junio.
My intention behind the original question was not to suggest adding
the feature of validation for email legitimacy, but rather to inquire
about and understand the rationale behind the initial design decision
to forgo strict validation when the user identity feature (user.email)
was implemented.
So, is the case ("not all users use the value of the field we define
to be 'email' to send emails to") more of a case of "exploiting a
perceived backdoor that later became justified" or "a thoughtfully
made design decision from the beginning"?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 15:00 ` rsbecker
2025-09-12 16:29 ` Junio C Hamano
2025-09-12 16:52 ` usharerose
@ 2025-09-14 11:17 ` Kristoffer Haugsbakk
2025-09-14 16:59 ` rsbecker
2 siblings, 1 reply; 14+ messages in thread
From: Kristoffer Haugsbakk @ 2025-09-14 11:17 UTC (permalink / raw)
To: rsbecker, 'usharerose', git
On Fri, Sep 12, 2025, at 17:00, rsbecker@nexbridge•com wrote:
> On September 12, 2025 12:13 AM, usharerose wrote:
>>I'm a Git user and curious about a specific aspect of Git's design regarding the
>>'user.email' configuration.
>>
>>Git allows any kind of values without restriction when setting 'user.email' via 'git
>>config' (e.g., `git config user.email "not-a-valid-email-address"`).
>>
>>I'm interested in understanding the design philosophy or historical reasons behind
>>this 'lack' of validation.
>>
>>I've glanced through the documentations, archived emails, or forum topics, but
>>couldn't find a definitive or official statement.
>>
>>Thanks for your time and insights.
>
> Some customers integrate single sign-on (SSO) via the user.email value.
> In the case
> of one customer I helped, the value is an SSO token used by GitHub for
> their
> integration. The token value does not conform to any valid email
> address format.
> Adding an email validation will lock them out of using git.
That sounds unreasonable.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-12 4:13 [DISCUSS] validation on git config user.email usharerose
` (2 preceding siblings ...)
2025-09-12 15:39 ` Thomas Guyot
@ 2025-09-14 11:58 ` Kristoffer Haugsbakk
2025-09-15 13:40 ` usharerose
3 siblings, 1 reply; 14+ messages in thread
From: Kristoffer Haugsbakk @ 2025-09-14 11:58 UTC (permalink / raw)
To: 'usharerose', git
On Fri, Sep 12, 2025, at 06:13, usharerose wrote:
> I'm a Git user and curious about a specific aspect of Git's design
> regarding the 'user.email' configuration.
>
> Git allows any kind of values without restriction when setting
> 'user.email' via 'git config' (e.g., `git config user.email
> "not-a-valid-email-address"`).
>
> I'm interested in understanding the design philosophy or historical
> reasons behind this 'lack' of validation.
>
> I've glanced through the documentations, archived emails, or forum
> topics, but couldn't find a definitive or official statement.
What’s the positive case for email validation?
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [DISCUSS] validation on git config user.email
2025-09-14 11:17 ` Kristoffer Haugsbakk
@ 2025-09-14 16:59 ` rsbecker
0 siblings, 0 replies; 14+ messages in thread
From: rsbecker @ 2025-09-14 16:59 UTC (permalink / raw)
To: 'Kristoffer Haugsbakk', 'usharerose', git
On September 14, 2025 7:18 AM, Kristoffer Haugsbakk wrote:
>On Fri, Sep 12, 2025, at 17:00, rsbecker@nexbridge•com wrote:
>> On September 12, 2025 12:13 AM, usharerose wrote:
>>>I'm a Git user and curious about a specific aspect of Git's design
>>>regarding the 'user.email' configuration.
>>>
>>>Git allows any kind of values without restriction when setting
>>>'user.email' via 'git config' (e.g., `git config user.email
"not-a-valid-email-
>address"`).
>>>
>>>I'm interested in understanding the design philosophy or historical
>>>reasons behind this 'lack' of validation.
>>>
>>>I've glanced through the documentations, archived emails, or forum
>>>topics, but couldn't find a definitive or official statement.
>>>
>>>Thanks for your time and insights.
>>
>> Some customers integrate single sign-on (SSO) via the user.email value.
>> In the case
>> of one customer I helped, the value is an SSO token used by GitHub for
>> their integration. The token value does not conform to any valid email
>> address format.
>> Adding an email validation will lock them out of using git.
>
>That sounds unreasonable.
In what way, may I ask? I have personally seen this done. Their core.email
value is not a valid user name. It is a token with no @ or . characters. It
is an alphanumeric string.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [DISCUSS] validation on git config user.email
2025-09-14 11:58 ` Kristoffer Haugsbakk
@ 2025-09-15 13:40 ` usharerose
0 siblings, 0 replies; 14+ messages in thread
From: usharerose @ 2025-09-15 13:40 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
On Sun, Sep 14, 2025 at 7:58 PM Kristoffer Haugsbakk
<kristofferhaugsbakk@fastmail•com> wrote:
> What’s the positive case for email validation?
Thanks for your reply, Kris. My intention behind the original question
was not to suggest adding validation for email legitimacy, but rather
to inquire about and understand the rationale behind the initial
design decision to forgo strict validation when the user identity
feature (user.email) was implemented.
I've come across many explanations, but they mostly list the various
application scenarios for `user.email` value. I haven't found an
officially recognized answer regarding whether the above applications
were explicitly considered during the initial design phase. Therefore,
I would like to consult the official community here.
Thank you again for your help.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-09-15 13:40 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-12 4:13 [DISCUSS] validation on git config user.email usharerose
2025-09-12 15:00 ` rsbecker
2025-09-12 16:29 ` Junio C Hamano
2025-09-12 18:06 ` usharerose
2025-09-12 16:52 ` usharerose
2025-09-12 17:23 ` rsbecker
2025-09-12 17:44 ` usharerose
2025-09-14 11:17 ` Kristoffer Haugsbakk
2025-09-14 16:59 ` rsbecker
2025-09-12 15:13 ` Konstantin Ryabitsev
2025-09-12 15:39 ` Thomas Guyot
2025-09-12 18:02 ` usharerose
2025-09-14 11:58 ` Kristoffer Haugsbakk
2025-09-15 13:40 ` usharerose
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox