| |||||||||||||
Security implications for user interface changes!Security implications for user interface changes!Posted Dec 18, 2012 14:01 UTC (Tue) by mirabilos (subscriber, #84359)In reply to: Security implications for user interface changes! by nix Parent article: Security implications for user interface changes?
“No it doesn't. GNU m4, built from the distributed tarballs, has a dependency on nothing other than shell tools and a C compiler (which does not have to be GCC).”
That assumes you *can* build from the distributed tarball without regenerating the autoconf machinery with a locally patched autoconf. Which is not always true.
(Log in to post comments)
Security implications for user interface changes! Posted Dec 18, 2012 14:08 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
Though, one one point, you’re indirectly right.
I guess I could build the current version of GNU m4 with autoconf 2.62 once locally, then use that to port autoconf 2.69, then take the then-current GNU m4 distfile from the FSF, extract it, regenerate all the machinery with what we need and then publish my own GNU m4 distfile that can be used to solve this cycle. Meh.
It’s probably even doable since our own machinery for ports etc. doesn’t change any more, it’s pretty stable.
Or, of course, get the required changed into autotools and libtool. But that has been like wading through treacle and got worse when dfjoerg got involved. Plus, we do require a unique set of changes for libtool 1.5 (working with autoconf 2.13 and 2.5x/2.6x) and possibly libtool 2.x, since we do need to regenerate older softwares. (Right now, the amount of libtool 2.x using software can be counted on one hand, and we just patched it to use our patched 1.x instead of trying to grasp the 2.x series.)
Security implications for user interface changes! Posted Dec 18, 2012 18:00 UTC (Tue) by nix (subscriber, #2304) [Link]
Errr. You don't need to do all that. You just need a single built copy of GNU m4 and autoconf/automake/libtool *somewhere*. Point PATH through it, and bingo. No need to keep upgrading those copies.
Bootstrap loops are not even slightly unusual. Why you consider it so much worse for GNU autoconf and m4 (which is meant for execution by developers and packagers) than for, say, GCC (which is needed by everyone building software and is far, far more complex) is somewhat unclear.
Security implications for user interface changes! Posted Dec 18, 2012 18:12 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
“You just need a single built copy of GNU m4 and autoconf/automake/libtool *somewhere*.”
That assumes it’s fine to use binaries.
Which is not. That’s the whole point of BSD ports.
Besides, it doesn’t scale. You’d need “a single binary” times amount of OSes, versions (and possibly, in-between snapshots with differing libc versions, libm versions, etc.), and architectures supported. That’s a *lot*. Plus you’d need access to machines to build them all. I do not have access to, say, an OSX 10.3 machine any more, since it got upgraded, but somewhere out there, someone might still use it. And my Interix machine had hardware issues and went to the trash, and the only other Win2k machine I have already has Cygwin on it, which conflicts.
So, it does not work period.
Security implications for user interface changes! Posted Dec 18, 2012 20:14 UTC (Tue) by nix (subscriber, #2304) [Link]
Uuuuh... yeah, when you generate configure, you *do* need binaries to do it. You need binaries of the shell tools and a working sed as well as GNU m4. Why is GNU m4 so bad, yet a working sed not a problem? (Note that a lot of otherwise Unixlike operating systems don't ship a working sed, just as they don't ship a working m4.)
If your model depends on generating configure on every build platform, your model is *broken*. That's not how configure is meant to work. Generate once -- run everywhere.
Security implications for user interface changes! Posted Dec 18, 2012 20:38 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
We have a working sed *and* a working m4 on all platforms.
They’re just usually the BSD variants, not the GNU variants.
In fact, all target platforms (Interix to the lowest degree)
That model is *not* broken, and has worked with GNU tools for
|
|||||||||||||