Mailing List Archive

Hi everyone,

Can I get feedback regarding the subproject page at

http://www.gentoo.org/proj/en/hardened/uclibc/

before I link it up and announce it to the rest of the world.

BTW, newer stage3's for amd64 and x86 uclibc are on the tree now under
experimental.

--Tony


On 10/27/2012 06:17 AM, Anthony G. Basile wrote:
> Hi everyone,
>
> Either today or tomorrow, there will be two new experimental hardened
> profiles, one on amd64 and the other x86. These will be:
>
> hardened/linux/uclibc/amd64
>
> and
>
> hardened/linux/uclibc/x86
>
> Please be careful with them! Do not try to switch to these profiles from
> a glibc system. portage will complain about blocking and not let you
> proceed, but for the truly stubborn who will hack away until it does
> work, trust me, it will not work. It will utterly break everything.
>
> Aside: while this is an extreme case, switching profiles is never to be
> taken lightly. Eg. hardened <-> non-hardened or selinux <-> non-selinux.
>
> For the curious, you can play with these using the stage3's at
>
> http://http://67.151.215.237/
>
> Notice there are 4 combinations
>
> amd64 hardened
> amd64 vanilla
>
> i686 hardened
> i686 vanilla
>
> The amd64 are completely done. I'm working on i686 now so you may want
> to wait on those. Any stage marked on or later than oct 25 should be good.
>
> Note: the vanilla is just hardened with USE="-hardened" set in
> make.conf. They are being built as a comparison to the hardened.
>
>
>


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Hey, cool!

Sorry, bit slow keeping up with the list. Great work though! I have
been using x86 uclibc for a year now on an embedded router distro, so
completely behind this. With new uclibc+nptl there are generally very
few build problems. Main problem is builds which exclude iconv and
gettext... (eg glib needs some hacking)

Just a couple of random thoughts:

- You pull in libiconv as a required package? Wasn't the complaint that
this could cause problems with GCC upgrades later? Note I have some
patches that I submitted in the past which allow uclibc to build a
partly working iconv (almost certainly got bugs, but seems to pass the
obvious tests)

- You have -iconv as a git use, but I think most git ebuilds are forcing
it back on again no matter what you say?

- You appear to mask nls? How about defaulting it to off rather than
forcing it off? I'm still unclear what problems are actually caused by
installing gettext? Seems like it can cause a permanent dep with gcc
linking to it, but for some situations that is probably not the end of
the world? Surely some people want nls on... (not me)


It would definitely be good to try and get people building uclibc with
iconv - as in, hopefully people will file bugs and fix them and quickly
we might end up with a proper working iconv in uclibc. Also canvasing
for a mini gettext implementation for runtime use...


Thanks for your work on this!

Ed W


On 02/11/2012 11:24, Anthony G. Basile wrote:
> Hi everyone,
>
> Can I get feedback regarding the subproject page at
>
> http://www.gentoo.org/proj/en/hardened/uclibc/
>
> before I link it up and announce it to the rest of the world.
>
> BTW, newer stage3's for amd64 and x86 uclibc are on the tree now under
> experimental.
>
> --Tony
>
>
> On 10/27/2012 06:17 AM, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> Either today or tomorrow, there will be two new experimental hardened
>> profiles, one on amd64 and the other x86. These will be:
>>
>> hardened/linux/uclibc/amd64
>>
>> and
>>
>> hardened/linux/uclibc/x86
>>
>> Please be careful with them! Do not try to switch to these profiles from
>> a glibc system. portage will complain about blocking and not let you
>> proceed, but for the truly stubborn who will hack away until it does
>> work, trust me, it will not work. It will utterly break everything.
>>
>> Aside: while this is an extreme case, switching profiles is never to be
>> taken lightly. Eg. hardened <-> non-hardened or selinux <-> non-selinux.
>>
>> For the curious, you can play with these using the stage3's at
>>
>> http://http://67.151.215.237/
>>
>> Notice there are 4 combinations
>>
>> amd64 hardened
>> amd64 vanilla
>>
>> i686 hardened
>> i686 vanilla
>>
>> The amd64 are completely done. I'm working on i686 now so you may want
>> to wait on those. Any stage marked on or later than oct 25 should be
>> good.
>>
>> Note: the vanilla is just hardened with USE="-hardened" set in
>> make.conf. They are being built as a comparison to the hardened.
>>
>>
>>
>
>

On 12/14/2012 05:31 AM, Ed W wrote:
> Hey, cool!
>
> Sorry, bit slow keeping up with the list. Great work though! I have been
> using x86 uclibc for a year now on an embedded router distro, so
> completely behind this. With new uclibc+nptl there are generally very
> few build problems. Main problem is builds which exclude iconv and
> gettext... (eg glib needs some hacking)

Recent >glib-2.30.3 + uclibc is a real pita and breaking everything that
links against glib. I'm busy with other stuff but glib is the major
stumbling block now. I think the problem is in pthreads. I haven't had
time to git bisect it down to the breaking commit.

>
> Just a couple of random thoughts:
>
> - You pull in libiconv as a required package? Wasn't the complaint that
> this could cause problems with GCC upgrades later? Note I have some
> patches that I submitted in the past which allow uclibc to build a
> partly working iconv (almost certainly got bugs, but seems to pass the
> obvious tests)

In cross compiling with CHOST= a glibc system, uclibc iconv code builds
fine. But it does not build fine on a native uclibc system. Lots of
things need iconv now, even coreutils. See bug #445716.

>
> - You have -iconv as a git use, but I think most git ebuilds are forcing
> it back on again no matter what you say?

That's an old workaround. It should work now. Let me know.

>
> - You appear to mask nls? How about defaulting it to off rather than
> forcing it off? I'm still unclear what problems are actually caused by
> installing gettext? Seems like it can cause a permanent dep with gcc
> linking to it, but for some situations that is probably not the end of
> the world? Surely some people want nls on... (not me)

Okay but please test and open a bug. Tell me what arch you tested on,
exactly what change was made to the profiles etc.

>
>
> It would definitely be good to try and get people building uclibc with
> iconv - as in, hopefully people will file bugs and fix them and quickly
> we might end up with a proper working iconv in uclibc. Also canvasing
> for a mini gettext implementation for runtime use...
>
>
> Thanks for your work on this!

Pay me in beer or patches :)


>
> Ed W
>
>
> On 02/11/2012 11:24, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> Can I get feedback regarding the subproject page at
>>
>> http://www.gentoo.org/proj/en/hardened/uclibc/
>>
>> before I link it up and announce it to the rest of the world.
>>
>> BTW, newer stage3's for amd64 and x86 uclibc are on the tree now under
>> experimental.
>>
>> --Tony
>>
>>
>> On 10/27/2012 06:17 AM, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> Either today or tomorrow, there will be two new experimental hardened
>>> profiles, one on amd64 and the other x86. These will be:
>>>
>>> hardened/linux/uclibc/amd64
>>>
>>> and
>>>
>>> hardened/linux/uclibc/x86
>>>
>>> Please be careful with them! Do not try to switch to these profiles from
>>> a glibc system. portage will complain about blocking and not let you
>>> proceed, but for the truly stubborn who will hack away until it does
>>> work, trust me, it will not work. It will utterly break everything.
>>>
>>> Aside: while this is an extreme case, switching profiles is never to be
>>> taken lightly. Eg. hardened <-> non-hardened or selinux <-> non-selinux.
>>>
>>> For the curious, you can play with these using the stage3's at
>>>
>>> http://http://67.151.215.237/
>>>
>>> Notice there are 4 combinations
>>>
>>> amd64 hardened
>>> amd64 vanilla
>>>
>>> i686 hardened
>>> i686 vanilla
>>>
>>> The amd64 are completely done. I'm working on i686 now so you may want
>>> to wait on those. Any stage marked on or later than oct 25 should be
>>> good.
>>>
>>> Note: the vanilla is just hardened with USE="-hardened" set in
>>> make.conf. They are being built as a comparison to the hardened.
>>>
>>>
>>>
>>
>>
>


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197