Bug#765633: Bug#780797: openssh-server: modifies the user configuration
On Mon, Mar 23, 2015 at 01:09:33AM +0100, Christoph Anton Mitterer wrote:
> On Sun, 2015-03-22 at 23:18 +0000, Colin Watson wrote:
> > Control: tag 765633 wontfix
> Ah it's really a shame... not that the issue is particularly critical,
> but it shows a general problem within Debian why we have so many fields
> where no progress is made - and if it it's made some people must just
> whine loud enough and people get scared enough to stop anything...
I disagree with this characterisation. Vincent is making a legitimate
complaint, not "whining". Please stop making personal attacks on them.
> > That said: I am persuaded that this particular change was a mistake, and
> > I will be reverting it
> Can you elaborate on that?
> What are the technical arguments that it's a good idea to allow a
> wildcard pattern of env vars being sent/accepted when this is known to
> be dangerous and there is the feature for just that reason in OpenSSH?
You claim it's dangerous, which is not the same thing as it being known
to be dangerous. I disagree that there is a realistic danger in
accepting LC_*.
> > 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.
> Wouldn't it then be better to leave it at the "better" value you've had
> before or even better using upstream's default of "" and:
The latter would not be "better" for most people: it would be very
significantly less convenient in practice. (Security isn't an absolute
thing.) And the reason that I'm not reverting it to the former for
upgraded-through systems is that I don't wish to end up with a similar
bug from people who share parts of your opinion and have manually
changed the configuration to accept LC_FOO individually.
> Now it seems the worst of all choices has been made:
You're of course entitled to your opinion, but I don't share it. I do
wish I hadn't applied your suggestion in the first place now, but aside
from that, it's not a particularly bad outcome in my book.
> > 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.
> Which is probably just another reason why at least for new installs
> upstream's default should be used.
> There are far too many situations where this causes technical issues,...
> ever connected to a old system without UTF-8 locales while your system
> has them enabled?
Sure. That doesn't cause any technical issues other than some spurious
error messages, and in my experience it's often been a reminder for
users to get their sysadmins to enable the relevant locales, which ends
up in a better place than doing nothing would have done.
> > Now that it's evident that this change to AcceptEnv causes problems for
> > some people
> Maybe I've missed that since the discussion got quite long, but I don't
> remember that Vincent actually explained what broke (i.e. I know nothing
> that would use LC_CHARMAP or CODPAGE?)...
I expect that this is part of some arrangements that Vincent has to work
around the rather more complex
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041, perhaps as
part of preparing a longer-term proper fix. I can imagine that such a
longer-term fix might well involve introducing something like LC_CHARMAP
globally, thus extending that open set I mentioned earlier.
--
Colin Watson [cjwatson@debian.org]
Reply to: