Hi Andrew,
No, I'm NOT against to fix this "potential" risk at all. Just tried to
point out that this
might not be an "immediate" breach.
It was a mistake to drop the list.
-Sherman
On 08/01/2012 01:11 PM, Andrew Hughes wrote:
----- Original Message -----
On 08/01/2012 06:52 AM, Andrew Hughes wrote:
Also if you read the old mails then you'll see that we were
scratching
our heads as to an example that would demonstrate the original issue.
I
suspect it may have been something that someone spotted rather than
someone running with a locale of this length. Well, the locale can be
set be an environment variable, so it could potentially
be anything of any length...
The Debian bug posted above has an example, though I couldn't
replicate it.
The spec says
" If the value of any of these environment variable searches yields a
locale that is not supported (and non-null), setlocale () shall
return a null pointer and the locale of the process shall not be
changed..."
So basically setLocale() should not return whatever you set in your
corresponding environment variable, it only
returns if such a "supported"/installed locale exists. I doubt there
is a such a locale anywhere on a real platform.
But in theory that could happen, if you try to config a locale with
name> 64 and successfully install it.
-Sherman
I still don't see any reason not to just close the hole. AFAICS, it's
also feasibly possible for a variant to appear in the future that takes
the length over 63 characters.
Any reason you didn't reply on list?
Thanks,
