Re: ld.elf_so sources [was Re: HEADS-UP: temporary security problem in today's NetBSD-current]

[christos%astron.com@localhost (Christos Zoulas)]

In article <201011150733.49603.nick.hudson%gmx.co.uk@localhost>,
Nick Hudson  <nick.hudson%gmx.co.uk@localhost> wrote:
>On Sunday 14 November 2010 22:40:11 Matthias Scheler wrote:
>> On Sun, Nov 14, 2010 at 11:35:41PM +0100, Marc Balmer wrote:
>> > > I'm sorry for the problem but I wasn't expecting that internal
>> > > "libc" functions get used outside of "libc".
>> >
>> > now you owe us beers... ;)
>> 
>> No, the person(s) who committed code that uses internal "libc" function
>> all over the source tree deserve a beating^H^H^H^H^H^H^H lecture in
>> good software development practices.
>
>ld.elf_so has done this since it was committed back in 1996 and there are also 
>lots of examples of "cross over" source file usage.

This is not entirely correct in the unsetenv() case. This was recently
added to fix a locking issue.

>That said...
>
>Should someone(tm) move the stuff to src/common so that people don't keep 
>falling over this?
>
>Alternatively, I was thinking maybe src/libexec/ld.elf_so/libsmallc (name 
>suggestions, please) so that it had tight control on what is used from 
>src/libc. In this way ld.elf_so would fail to build if a src/libc change 
>dragged in more than it should

Well, we need something like that (small functions that don't depend on
locking or memory allocation or i18n or....) but the requirements are not
entirely clear to me just yet to justify a libsmallc.

christos