Bug#780797: openssh-server: modifies the user configuration
Control: tag 765633 wontfix
Control: tag 780797 pending
On Sat, Mar 21, 2015 at 11:13:54AM +0100, Vincent Lefevre wrote:
> On 2015-03-21 07:12:08 +0100, Christoph Anton Mitterer wrote:
> > On Sat, 2015-03-21 at 00:51 -0400, Chris Knadle wrote:
> > > § 10.7.3 Behavior
> > > Configuration file handling must conform to the following behavior:
> > > • local changes must be preserved during a package upgrade
> > Well, strictly speaking, if the user had let that option at it's Debian
> > default, than there wasn't a local change.
>
> The configuration consists of a full file, and the choice for some
> option may depend on others. For instance, the admin could have
> chosen to enable empty passwords because port 22 is filtered from
> the Internet, but if there were an automatic change of the port
> (which hasn't been modified), there would be a serious problem.
> So, as soon as the file is modified, it must be considered that
> the configuration has been chosen by the admin and mustn't be
> modified automatically. This is at least how debconf behaves.
I don't at all agree with this premise in general. Firstly, debconf
does no such thing; perhaps you mean dpkg. But more importantly, plenty
of changes in sshd_config in fact are not dependent on other parts of
the same file in any significant way, and I do actually in general
possess the judgement required to tell the difference when implementing
this kind of change. I consider it a very significant improvement in
the experience for Debian users for openssh-server to cope with
syntax/keyword-name changes in sshd_config automatically rather than
requiring them to do things manually that could trivially have been done
automatically, and in other cases that has not been a problem. You
probably didn't even notice the previous changes.
Furthermore, as elaborated upon elsewhere, there isn't in fact an
obvious pristine state for sshd_config that could be used to determine
whether local changes have been made, so getting to the state you
request would take very considerable effort. I'd like to at some point,
but it will be fiddly work that I'm not looking forward to, and so I'm
certainly not promising any kind of timescale.
That said: I am persuaded that this particular change was a mistake, and
I will be reverting it, although I will not compound the problem by
automatically reverting the changes to installed sshd_config files,
since it is too difficult to tell whether somebody who shares
Christoph's opinions made the change manually. I'll probably just write
a NEWS.Debian entry to warn people who upgraded through 1:6.7p1-4 that
they may need to change things back manually.
I initially accepted this change because it seemed relatively simple and
uncontroversial, and even though I couldn't really see the point I often
accept simple changes that other people want because I have no desire to
be pointlessly obstructive. But, even though I admit that I can't find
chapter and verse that explicitly states this, LC_* is blatantly
obviously an open set: POSIX defines six members of it, and glibc
defines several more, all of which constitute parts of the user's
locale. I've never once heard of anything that wasn't locale-relevant
occupying that namespace, and I'm not in the least persuaded that this
is a realistic problem rather than a theoretical one. Furthermore,
since it's been an open set to date, it's quite plausible that it might
be extended further in future, and tracking that in sshd_config is not
appealing.
Now that it's evident that this change to AcceptEnv causes problems for
some people, its already extremely marginal utility is entirely swamped,
and I have no further interest in sustaining it. Better to revert.
Finally, I will absolutely defend my decision to accept locale
environment variables by default as one that is a reasonable default;
people are welcome to disagree for their own systems, of course, but I
think Debian as a whole is better off with this default.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: