| |||||||||||||
Security implications for user interface changes!Security implications for user interface changes!Posted Dec 13, 2012 16:47 UTC (Thu) by mirabilos (subscriber, #84359)Parent article: Security implications for user interface changes?
I *am* running outdated software because of one or more of the following reasons, roughly in the order of magnitude:
• Newer versions tend to depend on half the GNOME stack, or have Linuxisms making porting harder, or have much more insane dependencies than the predecessors (autoconf > 2.62 needs GNU m4, 2.62 could barely be patched), or something like that, or need Poettering crap
• Newer versions don’t work (as well) in compat_linux of the BSDs
• Interface changes (including loss of features)
• Bloat
• Newer versions use GPLv3 (or are otherwise less free)
For example, Opera 9.27 because newer 9.x versions don’t work on compat_linux as all, crash more often, or have those interface changes even though they occasionally may work on BSD. (My main browser is still Lynx though.) And indeed, Mozilla is at its end at the “old” company desktop too – recent versions refuse to start on Kubuntu 8.04… and I dislike KDE 4 a lot, and the “new” company desktop has Unity which is even worse.
(Log in to post comments)
Security implications for user interface changes! Posted Dec 17, 2012 20:52 UTC (Mon) by nix (subscriber, #2304) [Link]
It's curious that you think GNU m4 is an insane dependency. It has no mandatory dependencies at all (an optional dependency exists on libsigsegv), compiles almost everywhere, and works as well as any m4 out there. Why is it so terrible?
Security implications for user interface changes! Posted Dec 17, 2012 23:50 UTC (Mon) by mirabilos (subscriber, #84359) [Link]
No, GNU m4 has a build-time dependency on… modern autoconf!
Circular. (This is assuming you’re on a niche operating sy- stem which has to *always* regenerate autotools/libtool due to the requirement to use locally patched versions.)
Security implications for user interface changes! Posted Dec 18, 2012 1:20 UTC (Tue) by nix (subscriber, #2304) [Link]
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).
If you build from the version control system rather than a tarball, you are expected to have GNU autoconf, of course -- but you don't do that unless you're developing it or digging around in its version control system for smoething (i.e. probably debugging it). You certainly don't do that if you're bootstrapping -- and if you must, then you can run autoconf et al to generate the configure machinery on another host, and then run it on your bootstrap host. (This is nothing new: it is the whole reason autoconf generates a configure shell script in the first place, specifically so that people compiling the tools do not have to have the autoconfiscation machinery on their systems.)
Security implications for user interface changes! Posted Dec 18, 2012 14:01 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
“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.
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
|
|||||||||||||