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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
