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... > 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? > 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: - either simply not change existing configs - or do so, but add a NEWS.Debian entry AFAIU Vincent and the others, their complain wasn't about the new value per se, but rather of this happening automatically respectively without announcement. Now it seems the worst of all choices has been made: - reverting back to the less save value - plus having a pretty useless NEWS entry which is just for those small number of users whose values got changed in that single version (from the already small set of users who care) > 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. Those are basically the one's I've collected for #765633. I guess one can be so bold to claim, that using anything beyond these is non-standard. > 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. Partially I agree, I've never heard of anything like that either. But recently we have simply seen far too many issues which were initially either not even identified as security issue, or just considered cosmetic/theoretical nature... and some of the biggest security issues we've had in the last years could have been prevented if people weren't to reluctant in the first place when they already had signs that something should be done. > 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? > 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?)... and the others rather just complained about the silent/automatic change. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature