[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140712145525.GH179@brightrain.aerifal.cx>
Date: Sat, 12 Jul 2014 10:55:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Status towards next release (1.1.4)
On Sat, Jul 12, 2014 at 09:24:09AM +0200, u-igbb@...ey.se wrote:
> On Sat, Jul 12, 2014 at 01:10:35AM -0400, Rich Felker wrote:
> > - The Big Bikeshed: where to find locale files? These will be somewhat
> > musl-specific (to the extent that no other implementation uses the
> > design I have in mind, though it would be easy for others to use
> > it), so there's no existing practice to simply adopt. The files are
> > not machine-specific (we'll support either endianness .mo file) so
> > /usr/share (or other prefix variants) is the natural base location.
>
> For me it looks like you take a wrong kind of responsibility and try to
> make a decision which does not belong to a library developer.
>
> This is an "integrator" decision, the one who knows how the library will
> be used and what is the corresponding environment's policy of placing
> stuff around in the file system.
>
> In other words, as long as it is configurable, any "default" goes.
> You can not know (and imho do _not_ have to pretend to) what is best or
> sensible for the actual deployment.
I understand that configuring this matters for your usage case where
you're configuring ALL of the paths where configuration/data/etc. is
read from to isolate each program in its own bubble. However I don't
see any value in configuring this one location when other things (like
the place timezones are searched for) is fixed.
> As an "integrator" I am concerned in the following way:
>
> - If locale is mostly static (additions or changes to locale
> can be done at the same time as library recompilations/upgrades)
> then a "default" placement is totally irrelevant, but I must be
> able to choose the actual one at compilation time - I guess this is
> expected and hence a non-issue
No, the intent is that they're produced independently of musl, or at
least independently of my part of the development/maintenance process.
I don't want to be a locale maintainer. BTW, locale definitions are a
much bigger "imposing policy" issue than a standard pathname.
> With the paranoia-hat on:
>
> - if locale data is supposed to be available from more sources than the
> library upstream (then potentially even with different licenses)
> and/or if it is supposed to change often, then
>
> I'd badly need a possibility to tell an application at runtime where
> to look for the data (presumably via an environment variable specific
> to musl).
>
> Hope such kind of locale data is not expected to exist.
Runtime configuration of the path is a big problem for many usage
cases, possibly even if it's blocked for suid. The recent glibc
CVE-2014-0475 has me concerned and wanting to avoid any dubious
practices with how locales are searched out. This is potentially a
much bigger issue than timezones, because for timezones, invalid data
probably results in compromises no worse than a crash or information
leak. With locales, invalid data can result in full code execution
(via injection of %n into format strings, and possibly other ways).
On the other hand, runtime configuration is something I'd really like
to have, so that users can use locales that are not installed by the
system administrator and develop/test/debug locales without
installing. But this is a sufficiently big opening for environmental
state to alter the behavior of the program that I'm very concerned
about the safety of it and frustrated by the whole process...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
