Re: git should not use a default user.email config value

Jeff King [off-list ref] writes:

Yeah, there are basically three levels of ident:

  1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.

  2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
     but use it.

  3. It looks obviously bogus (e.g., we do not have a domain name).
     Reject it.

We can move some cases from (2) down to (3), like ...

Judging from Thorsten's earlier response, I am afraid no amount of
autodetection would help the users of that site.  If we were to do
something, /etc/gitconfig as you outlined below would be the way to
go, even though it makes me feel dirty.

Another option could to add an option to control the strictness. We
usually have a chicken-and-egg problem here with individual installs
(i.e., any person who could set "user.trustHostname = false" could just
as easily have set "user.email"). But in an institutional setting, the
admin could set such a config in /etc/gitconfig for everybody. Or for a
system like Debian, the packager could include the option, knowing that
any reasonably configured system should have /etc/mailname set up (which
is not something we can necessarily count on for other operating
systems).

-Peff

On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

Yeah, there are basically three levels of ident:

  1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.

  2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
     but use it.

  3. It looks obviously bogus (e.g., we do not have a domain name).
     Reject it.

We can move some cases from (2) down to (3), like ...

Judging from Thorsten's earlier response, I am afraid no amount of
autodetection would help the users of that site.  If we were to do
something, /etc/gitconfig as you outlined below would be the way to
go, even though it makes me feel dirty.

It was not clear to me whether his site has /etc/mailname. If it does
not, then the new rule could be to leave "/etc/mailname" in group 2, and
put "gethostname/gethostbyname" into group 3 (right now we do so only
when the results from those functions are obviously not
fully-qualified).

But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.

Even if it worked, though, I am not sure it would be worth such a rule.
The /etc/mailname file is not a standard, so you would effectively be
cutting off the auto-ident behavior for people on every other system. If
we are going to do that, we might as well do it uniformly.

-Peff

Jeff King wrote:

Even if it worked, though, I am not sure it would be worth such a rule.
The /etc/mailname file is not a standard, so you would effectively be
cutting off the auto-ident behavior for people on every other system. If
we are going to do that, we might as well do it uniformly.

I don't fully follow.  Do you mean that because other operating
systems choose not to make full use of an /etc/mailname file when it
is present (and instead use per-MTA configuration), git should not
take advantage of it to choose an appropriate email address?

Or do you mean that on non-Debian systems, the FQDN for localhost is
reliably the mailname, just like on Debian systems /etc/mailname is
supposed to be?

Confused,
Jonathan

On Fri, Aug 09, 2013 at 11:40:56PM -0700, Jonathan Nieder wrote:

Jeff King wrote:

quoted

Even if it worked, though, I am not sure it would be worth such a rule.
The /etc/mailname file is not a standard, so you would effectively be
cutting off the auto-ident behavior for people on every other system. If
we are going to do that, we might as well do it uniformly.

I don't fully follow.  Do you mean that because other operating
systems choose not to make full use of an /etc/mailname file when it
is present (and instead use per-MTA configuration), git should not
take advantage of it to choose an appropriate email address?

Or do you mean that on non-Debian systems, the FQDN for localhost is
reliably the mailname, just like on Debian systems /etc/mailname is
supposed to be?

Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic "if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
/etc/mailname is the accepted way to do so on Debian)".

But such logic would not extend to other operating systems, where
/etc/mailname does not have such a status.

I am guessing, too, about what people even put in /etc/mailname. If they
relay mail from the machine to a smarthost, do they put the individual
hostname into /etc/mailname? Or do they put in the domain name that
represents a real deliverable address? If the former, then it is no
better than gethostname anyway.

-Peff

Jeff King wrote:

Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic "if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
/etc/mailname is the accepted way to do so on Debian)".

But such logic would not extend to other operating systems, where
/etc/mailname does not have such a status.

I thought that on other operating systems people typically don't have
an /etc/mailname.  How does trusting the file when present hurt?

I am guessing, too, about what people even put in /etc/mailname. If they
relay mail from the machine to a smarthost, do they put the individual
hostname into /etc/mailname? Or do they put in the domain name that
represents a real deliverable address? If the former, then it is no
better than gethostname anyway.

Debian policy explains:

	If your package needs to know what hostname to use on (for
	example) outgoing news and mail messages which are generated
	locally, you should use the file /etc/mailname. It will contain
	the portion after the username and @ (at) sign for email
	addresses of users on the machine (followed by a newline).

	Such a package should check for the existence of this file when
	it is being configured. If it exists, it should be used without
	comment, although an MTA's configuration script may wish to
	prompt the user even if it finds that this file exists. If the
	file does not exist, the package should prompt the user for the
	value (preferably using debconf) and store it in /etc/mailname as
	well as using it in the package's configuration. The prompt
	should make it clear that the name will not just be used by that
	package.

So on a properly configured Debian system, /etc/mailname contains
something appropriate to put after the @ sign in an email address
and the sysadmin expects it to be used for that.

As far as I can tell, to the extent that other distros support
/etc/mailname, it is only as a side effect of handling that Debian
requirement.  I don't think e.g. Fedora or Solaris systems typically
will have a /etc/mailname file.

I *am* a bit worried about what people might put in /etc/mailname on
Debian systems when there is no appropriate host to put there (as on
Thorsten's machine).

Jonathan

On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote:

Jeff King wrote:

quoted

Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic "if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
/etc/mailname is the accepted way to do so on Debian)".

But such logic would not extend to other operating systems, where
/etc/mailname does not have such a status.

I thought that on other operating systems people typically don't have
an /etc/mailname.  How does trusting the file when present hurt?

I guess I am not explaining myself well. Trusting the file when present
does not hurt at all. But the logic above is making assumptions about
the state when the file is _not_ present (i.e., the "if you do not..."
clause above). On Debian, we might assume that if /etc/mailname is not
present that this is a clue that the machine cannot produce a useful
address.  But on other operating systems, that is not a useful clue (it
is simply that /etc/mailname is not used on that system). Dying on such
a system when /etc/mailname is not present would be a regression.

Does that make more sense?

I *am* a bit worried about what people might put in /etc/mailname on
Debian systems when there is no appropriate host to put there (as on
Thorsten's machine).

Yeah. Or even in a split-horizon setup where the mail is deliverable but
does not reflect the public identity of the user. I think we are getting
down to the question I mentioned elsewhere: it is not about whether we
have a deliverable address or not, but what users want to cement in
history for all time as their identity.

So thinking too much about /etc/mailname versus gethostname is probably
not useful. Either it is worth breaking the few (if any) users who
depend on the auto ident in favor of fewer accidental implicit idents
making their way into the wild, or it is not.

-Peff