thanks GNU!

[legacy]

- sys-libs/glibc-2.22-r4::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Micha? Górny <mgorny@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>,
# Matthias Maier <tamiko@gentoo.org> (21 May 2017)
# These old versions of toolchain packages (binutils, gcc, glibc) are no
# longer officially supported and are not suitable for general use. Using
# these packages can result in build failures (and possible breakage) for
# many packages, and may leave your system vulnerable to known security
# exploits.

Thus I have to waste 1 day to sync a new rootfs 

[legacy]

thus, two affected compilers which I happen to use a lot

sys-devel/gcc-4.4.7
dev-lang/gnat-gcc-4.3.5

 

[Kalvin]

Use virtualized environment and do not update the tools.

[RGB255_0_0]

Use virtualized environment and do not update the tools.

Then what do you do when your software gets hacked because of some exploit?

[ataradov]

Don't use Gentoo if you want stable system. I've been using Linux since 2001. Debian -> Ubuntu -> Mate. Never had a real problem.

[Kalvin]

Use virtualized environment and do not update the tools.

Then what do you do when your software gets hacked because of some exploit?

Compilers get exploited when they are not updated any more? Keep your host updated. Backup your stuff. Use the virtualized environment for compilation and development stuff only. Use multiple virtualized containers if you need to support multiple legacy tool-chains.

[Kalvin]

Don't use Gentoo if you want stable system. I've been using Linux since 2001. Debian -> Ubuntu -> Mate. Never had a real problem.

Pretty much similar path here too.

[RGB255_0_0]

Use virtualized environment and do not update the tools.

Then what do you do when your software gets hacked because of some exploit?

Compilers get exploited when they are not updated any more? Keep your host updated. Backup your stuff. Use the virtualized environment for compilation and development stuff only. Use multiple virtualized containers if you need to support multiple legacy tool-chains.

https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html
https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html

Not all exploits result in compiled applications being exploitable but it doesn't mean you can be ignorant by thinking that just because you've isolated your build machine that your apps you've compiled using them are not.

[Kalvin]

Use virtualized environment and do not update the tools.

Then what do you do when your software gets hacked because of some exploit?

Compilers get exploited when they are not updated any more? Keep your host updated. Backup your stuff. Use the virtualized environment for compilation and development stuff only. Use multiple virtualized containers if you need to support multiple legacy tool-chains.

https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html
https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html

Not all exploits result in compiled applications being exploitable but it doesn't mean you can be ignorant by thinking that just because you've isolated your build machine that your apps you've compiled using them are not.

Good points.

[legacy]

Don't use Gentoo

Unfortunately I need it for several reasons.

[legacy]

Use virtualized environment

Yup, I have created a miniroot of the old rootfs as well as a full backup.
Also I have already moved stuff into a VirtualBox machine as well as a UML.
(user mode linux)

I prefer the UML-way for toolchains, but VirtualBox is the simplest way, and my customers prefer it.

[legacy]

in the meanwhile I am moving the new rootfs to gcc-v5.4.0 

[legacy]

I mean, it's highly suggested, and I suggest you to do the same, guys
in order to avoid future problems 

[bd139]

Sounds like fun!

Use a stable distribution (CentOS/Debian or something) and build your own cross toolchain on top of it. It's the only way this doesn't come and bugger you randomly one day. I speak from experience. If you build a cross toolchain then make sure you automate the build via make or something. Takes a few hours to get it right the first time but you can build individual compiler/binutils/valgrind versions as and when they drop or do the opposite and never patch a damn thing.

I have two environments, one with LLVM and one with GCC in it so we can test each in isolation.

Not a fan of virtualizing/containerising it. It's difficult to make that build repeatable in the future unless you build the environment with docker/vagrant and those require more effort than the above.

[legacy]

If you build a cross toolchain then make sure you automate the build

Man, I have 15 years of experience with gentoo.

Everything (including experimental stuff) I do for whatever architecture I have to support { MIPS32BE, HPPAv2, POWERPC, X86} is done by Overlay recipes, while the whole rootfs is under Catalyst, and Catalyst compiles every new rootfs as chroot.

The main rootfs is safe and never update until things have passed the stable level (whose severity level is more fussy than on Debian-stable, I mean I am fussier than those guys).

Things are under control, but GNU sucks a lot, and their FSK software is always broken, indeed even guys behind Ubuntu, Centos, etc, have the same problems I have every FSK time we need to update something.

Now the whole GlibC is ... fragile 

[ataradov]

What's the point of complaining? Don't like it - don't use it. Since you keep using it, there must be no better option, so GNU guys did pretty well, I would say.

Everyone can complain, if you think  you can do better - contribute, and everyone will be better for it.

[bd139]

If you build a cross toolchain then make sure you automate the build

Man, I have 15 years of experience with gentoo.

Everything (including experimental stuff) I do for whatever architecture I have to support { MIPS32BE, HPPAv2, POWERPC, X86} is done by Overlay recipes, while the whole rootfs is under Catalyst, and Catalyst compiles every new rootfs as chroot.

The main rootfs is safe and never update until things have passed the stable level (whose severity level is more fussy than on Debian-stable, I mean I am fussier than those guys).

Things are under control, but GNU sucks a lot, and their FSK software is always broken, indeed even guys behind Ubuntu, Centos, etc, have the same problems I have every FSK time we need to update something.

Now the whole GlibC is ... fragile 

That sounds painful but it's not a terrible solution.

Agree with glibc being shit. So many WTFs and GNUisms in there. Why do you think we've got an LLVM build going? Hopefully libc++ will be usable at some point

[legacy]

What's the point of complaining? Don't like it - don't use it.

Man, I don't like it, but it's my job.
Likes dislikes, they don't matter with your customers.

[legacy]

That sounds painful but it's not a terrible solution.

Nah, it's common routine once you have mastered Catalyst and written some hundred Overlays

Why do you think we've got an LLVM build going? Hopefully libc++ will be usable at some point

Yup, the best idea ever

Unfortunately I have some ebuilds (gentoo-way to say "building recipes") which needs C++, and some problem supporting LLVM under HPPA and MIPS (they are both experimental with LLVM), but it's a MUSTbeDONE point in my todo list.

[legacy]

also be warned about this problem, caused by cmake!

[bd139]

Argh cmake is just shit. We use BSD make.

[bingo600]

What's the point of complaining? Don't like it - don't use it. Since you keep using it, there must be no better option, so GNU guys did pretty well, I would say.

Everyone can complain, if you think  you can do better - contribute, and everyone will be better for it.

 

/Bingo

[bd139]

Thats something that someone who hasn't contributed to an open source piece of software says. The reality is it's a nightmare. I've made hundreds of pull requests, patches via email over the years and the accept rate is around 5%. Most are ignored, deleted or closed silently or result in a flame war because some little big man's ego has been damaged by the idea that someone wants to contribute. So I gave up, maintain patch forks of some things we use.

[legacy]

Thats something that someone who hasn't contributed to an open source piece of software says. The reality is it's a nightmare. I've made hundreds of pull requests, patches via email over the years and the accept rate is around 5%. Most are ignored, deleted or closed silently or result in a flame war because some little big man's ego has been damaged by the idea that someone wants to contribute. So I gave up, maintain patch forks of some things we use.

Exactly the point! GNU has the lowest quality of guys to deal with!
Their EGO ...

Have you ever tried to read and study the GCC internals?
have you ever tried to point out that ... some piece of code is too obscure (thus, it might be hide a bug)? If you point out this to someone in the maillist you will be considered an inferior idiot until someone in the CLUB blesses you.

Well, they can have a basket of pine cones attached to my bug-reports 

[bd139]

Yep exactly that.

Some of the shit it spews out when you crank up optimisation is funny. I could a few years ago actually get it to eliminate live code and optimise out a loop so it only ran once. I think it was Theo De Raadt who explained that only the basic x86/x64 back ends are actually even slightly tested. Ugh it's just horrible.