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