Weekly Edition
Return to the Security page
| |||||||||||||
Security implications for user interface changes?Free software users are not generally known for their quiet acceptance of user interface changes. Many changes to the UI of desktop environments or popular applications lead to long and loud threads from users—with some percentage of those users claiming they will move to an alternative rather than "put up" with the change. But what happens if the alternative is to stick with an earlier, unsupported version of the application? That's the question that came up in a short, but interesting, thread on the Mozilla security mailing list. Plans for Firefox to remove the "tabs on bottom" feature have so incensed a vocal subset of users (see this bug report or this lengthy thread on the mozilla.dev.apps.firefox group) that they don't plan to upgrade the browser once this change is implemented. For many releases now, Firefox has had its tabs below the controls and "awesome bar", which is the behavior called "tabs on bottom". More recent versions have had a "Tabs on top" toggle in the toolbar configuration, which moves the tabs to just below the menu (and above the controls and awesome bar). The toggle is slated for removal, with tabs on top becoming the default. The old behavior will still be available by setting browser.tabs.onTop to false in about:config, but users are concerned that will eventually disappear as well. The ferocity of the arguments against moving the tabs (and removing the toggle) led Zack Weinberg to suggest keeping the toggle and feature:
Obviously, refusing to upgrade Firefox opens up these users to serious
security risks. I would like to suggest that we put that toggle back in,
and commit to preserving tabs-on-bottom mode for the foreseeable future,
*just because* it will encourage this upset minority of users to continue
upgrading. Remember that the actual size of the upset minority here is
probably at least 100x larger than the number of people who have gone to
the trouble of complaining about it in the newsgroups and/or the bug
report.
Web browsers, by their nature, need frequent updates. Because browsers face the often hostile internet and can provide a portal to users' documents, photos, passwords, and so forth, it is critically important for users to keep up with browser updates. Anything that gets in the way of that process is (and should be) worrisome. That is the main reason that Chrome and Firefox have moved to automatic updates, for example. But there is a tradeoff to be made here. Mozilla's VP of Firefox Engineering Johnathan Nightingale argues that, over the years, too much attention has been paid to the most vocal user contingent. There is code that is "in desperate need of clean up", he said, so Firefox developers cannot necessarily afford to heed the negative feedback:
[...] but on balance I believe we bias far too much towards letting vocal, conservative complaint chill the evolution of our products.
Every community has conservative elements. They are helpful; they remind us who we are when we forget. But conservative forces prevent change (by definition!) and we have important aspects of our code that need changing. Weinberg is not convinced that cleaning up the code base overrides the security issue, however. He is concerned that the "tabs on bottom" issue is really just the straw that broke the camel's back for some segment of users. Even a small percentage of the Firefox install base can make for a rather large problem:
But with my security hat on, even a small minority of our users is still
tens or hundreds of thousands of people, and if their computers are 0wned
because they refused security updates because they didn't like our UI
changes, that potentially has cascading fallout upon a much larger
population (as the 0wned machines become malware sources
themselves). That's not something I think is justifiable by code
cleanliness concerns on our end.
Drawing a clear line is difficult, though. If any change to the UI can be seen as a "security problem" because users might decide not to upgrade, it will be difficult for Firefox to make any changes. Users have to take some responsibility for their choices. As Curtis Koenig put it:
While it is
concerning when users choose to resist change in hazardous manners we
cannot and should not halt forward movement due to the real or perceived
threat that some portion of the user base will make ill conceived
choices. This would allow anyone to hold up anything with the cry of "I
won't update" and then we get nowhere.
Users will make poor choices at times, and it is certainly possible that some change will drive some of them to make those choices. Is there a "moral responsibility", as Weinberg claimed, for Firefox (and, by implication, other applications, desktops, etc.) to continue to deliver a user experience that its users have become accustomed to? Are UI changes always potential security problems? There are obviously some kinds of UI changes that are security flaws, but simply changing the way the user interacts with the program likely doesn't really reach that level. Both Koenig and Nightingale do not see the "tabs on bottom" change as a security issue. There may be design or development issues that need to be resolved—though Nightingale seems confident that those have largely been dealt with—but changing some UI elements around is not cause for a security red flag. In fact, Nightingale called the security concern "a red herring (or a slippery slope, take your pick)". There is only so much that a project can do to protect its users. Part of the problem with this particular case is that the other "major" free alternative, Chrome/Chromium, also has its tabs at the top. One guesses that the uproar would be good deal more subdued if there were an "easy" alternative that behaved the way the "vocal conservatives" want. There may be good reasons to consider leaving the "tabs on bottom" feature alone; security isn't really one of them. But it is always good to see projects thinking about and debating where these lines are. (Log in to post comments)
Security implications for user interface changes? Posted Nov 29, 2012 2:07 UTC (Thu) by krakensden (subscriber, #72039) [Link]
I sympathize with the argument, but on the other hand... this looks like a great way to weaponize naysaying.
Security implications for user interface changes? Posted Nov 29, 2012 10:15 UTC (Thu) by hummassa (subscriber, #307) [Link]
That is GOOD. Naysaying is not weaponized enough as it is. And yes, for many reasons, UI changes *are* security issues /per se/, especially if the user gets irritated or confused. The process of security is dependent on the usability of the tools, and usability *is* dependent on some interface conservadorism in 99% of the cases, the other 1% being exactly /exceptio probat regulam in casibus non exceptis/ :-D...
Security implications for user interface changes? Posted Nov 29, 2012 17:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Why do security tools have the *worst* interfaces then? The nss and openssl command line tools use crazy abbreviations and acronyms without explanation and then the manpages approach uselessness via terseness.
Security implications for user interface changes? Posted Nov 29, 2012 18:06 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
because the people writing them are too close to the problem. As a result, they write things that are obvious to them and so they don't see a need for more documentation.
It also hurts that in many cases, the problem is actually hard, and if you tried to explain when you would want to use each option, as opposed to the terse explanations that they have, it's a very slippery slope to having books on the subject (with significant disagreements between the books over what the 'right' way to do things is)
Security implications for user interface changes? Posted Nov 29, 2012 18:21 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I'm fine if they put "Beware: dissertations recommended" on some commands and options, but trying to find out what domain a certificate is for? If I hadn't remembered "x509" being so familiar, things would have taken a lot longer than they did (which was already too long, IMO). The certutil commands for inserting things into your nssdb are also crazy. AFAICT, you can't add the 'u' (a client-side certificate) flag to entries without actually using it as a client certificate. It's also sad when the easiest interface to your tool is the configuration pane of a browser (the Chromium family in this case).
Security implications for user interface changes? Posted Dec 3, 2012 2:25 UTC (Mon) by giraffedata (subscriber, #1954) [Link] ... it's a very slippery slope to having books on the subject You didn't finish the thought. The problem with having books on the subject is that people don't have time to read books on the subject. It's actually impossible to explain some things - the time it takes to explain it is more than a person has to listen.
Security implications for user interface changes? Posted Nov 29, 2012 10:32 UTC (Thu) by epa (subscriber, #39769) [Link]
From the outside it all looks rather perverse. The developers have started discussing an imagined security threat, rather than simply considering that it might be worth keeping the feature because users appreciate it. If they have considered that and still decided that the feature is to be dropped, there isn't anything more to discuss unless someone wants to pay for it.
When it was announced that Firefox 64-bit nightly builds on Windows would be discontinued, I stopped using them and dropped back to Waterfox (a third-party Win64 build) instead, which is usually a bit behind the latest upstream release. But I wouldn't expect the Firefox developers to take the slightest notice of that as some kind of threat to the Internet. They can just produce the best software and then it's up to everyone else whether to run it or not.
Security implications for user interface changes? Posted Nov 29, 2012 12:26 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
Everyone knows that building complex software is about making things that are neat, not about serving the needs of users.
Or, if it's about serving the needs of users it's about serving the needs that we don't hear about from actual users, not the needs users go out of their way to express.
Or, if it's about serving the needs we hear about from actual users, it's important to focus in on one or two corner cases (like grandma) and not the vocal minority; you see, the ones who talk very little are representative of a much larger group who, we assume, have similar needs.
The ones who do not talk at all are such a huge group that their needs obviously trump the needs of the vocal minority and the not-very-vocal minority. The best part about the silent majority is that since they express no needs at all *any change whatsoever* that seems neat can be justified as a service to them, the most important group.
Security implications for user interface changes? Posted Nov 29, 2012 15:03 UTC (Thu) by epa (subscriber, #39769) [Link]
In the case of Firefox, statistics on web browser usage are collected by several sources (not least Google, who want to see whether the money they pay for search bar placement is well spent), so there exists a quantitative way to test how well the project is serving its audience.
In your analysis you forgot about one important audience: those who do not use the program at all yet. (When starting a new project everyone falls into this category, and even for Firefox the majority of the world's population does not use it.)
Security implications for user interface changes? Posted Dec 2, 2012 10:04 UTC (Sun) by man_ls (guest, #15091) [Link] Statistics on browser usage are not exactly quality feedback. Consider this scenario: Firefox 85 comes out with 10 new end-user features, 5 new enterprise features and with a new advertising campaign. Usage goes down 0.1%. Who is to blame? What did they do wrong? Is the world moving on? Are there any features in the competition which Firefox did not implement? Did MS or Google come up with a (possibly dirty) strategy to steal users? In the absence of detailed feedback it is impossible to know.Statistics are good only to check whether things go broadly according to plan or there is a need to dig deeper into why.
Security implications for user interface changes? Posted Nov 29, 2012 3:20 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Don't forget the third[1] choice: no tabs at all!
/me ducks
[1]Not that there's only three either.
Security implications for user interface changes? Posted Nov 29, 2012 8:18 UTC (Thu) by ghane (subscriber, #1805) [Link]
Do we need an address bar at all?
The use case I see all around me is that people start their browser, which opens to Google, MSN, or similar. They then use the search bar all day long. They open a new window for each task.
Say "No" to tabs! Open each new window with google.com.sg?affiliate=mozilla, and let people use the search bar within that page.
So the choices are:
Please do not vote yet, my Patent Application is on the way (need to beat Apple).
--
Security implications for user interface changes? Posted Nov 29, 2012 11:04 UTC (Thu) by zdzichu (subscriber, #17118) [Link]
Google, for their browser, contemplated it last year: http://www.conceivablytech.com/7485/products/google-is-se...
Security implications for user interface changes? Posted Nov 29, 2012 20:19 UTC (Thu) by dashesy (subscriber, #74652) [Link]
I use DuckDuckGo as homepage and search bar, there you can use "Feeling Ducky" bang to navigate to websites, for example "\lwn" directly opens here.
Security implications for user interface changes? Posted Dec 3, 2012 15:40 UTC (Mon) by mina86 (subscriber, #68442) [Link]
I use Opera with address bar hidden and have a key shortcut for showing a “Go to page” dialogue. In fact, apart from a Windows panel (basically a tab bar on the left) I don't uses any toolbars.
Security implications for user interface changes? Posted Dec 6, 2012 23:15 UTC (Thu) by cyanit (guest, #86671) [Link]
Well, you definitely need a line with the URL always on screen, so that you can know whether you are indeed on example.com rather a site that mimics example.com.
And once you have the text visible, making it editable can be done without consuming further screen space.
So, not having an address bar is dumb.
Security implications for user interface changes? Posted Dec 9, 2012 23:22 UTC (Sun) by Baylink (subscriber, #755) [Link]
Oh, sure; having Google know every website I manually navigate to is *right up at the top* of my list of RFEs.
A long time ago, I used to set Google up as people's browser home page... until I discovered none of them understood their browser well enough to type URLs into the location box. Hey; the cursor's in a box and if I type a URL there, I get where I'm going... why does it matter?
<facepalm />
Security implications for user interface changes? Posted Dec 11, 2012 16:30 UTC (Tue) by bronson (subscriber, #4806) [Link]
Being able to use internet technology without understanding how it actually works? That's awesome! It's a bright future for everybody.
Why the facepalm? I'm sure the information they leak to Google is nothing compared to what they're leaking to Facebook.
Security implications for user interface changes? Posted Nov 29, 2012 8:19 UTC (Thu) by ncm (subscriber, #165) [Link]
Tabs just take up valuable space when you're looking at page contents. Probably self-hiding tabs that explode out of the left edge of the window under some provocation would be best. That would allow lots more room for page titles in the tabs. (East Asian users might prefer they explode from the top edge instead; southwest Asians might prefer the right edge.)
As it is, those of us who keep a gross or more of tabs open at once, distributed among dozens of windows, (I do not kid) don't get to see much of page titles in the tabs.
A better way of dealing with tabs Posted Nov 29, 2012 13:37 UTC (Thu) by stevem (subscriber, #1512) [Link]
Tree Style Tab is a lovely add-on to fix this - I've got a much better tab interface than the default, and it's on the left of my browser window rather than eating valuable vertical space... \o/
A better way of dealing with tabs Posted Dec 7, 2012 0:01 UTC (Fri) by JanC_ (guest, #34940) [Link]
My tabs are at the right, but +1 million votes for Tree Style Tab from me too.
A better way of dealing with tabs Posted Dec 17, 2012 14:54 UTC (Mon) by wookey (subscriber, #5501) [Link]
Do I understand that 'tabs on bottom' does not mean 'at the bottom of the screen' but 'below the address/status bars'? I didn't realise that 'above the address/status bars' was an option - it's seems a pretty stupid one to me - why would I want that?
I use either 'normal' aka: 'tabs on bottom' tabs or tree-style tabs. I typically have 200-odd pages open in 20-something browser windows of between 1 and 30 tabs each. I really miss the xterm feature of giving windows subject names which is what my browser windows actually are (is there a way to do that?). The tear-off tab is what made this way of working nice - before that things would get in the 'wrong' window and it was all crappy.
Will the 'tabs on top' concept break tree-style tabs? If so I am firmly in the 'this is anathema' camp. Presumably not as this 'ere firefox is 15.something and this seems to be a 3.6->4.0 change?. I'm certainly pretty unhappy about having horizontally-arranged tabs move further up the screen -that a load of extra mousing I could do without. However when I look at my browser on my laptop (Iceweasel 10.something, no tree-tabs there) I find it's already like this, and presumably has been for some time. As I had apparently not noticed I guess it's not that bad really, although now I think about it seems a very poor choice.
I suppose this is an interesting case of the natural conservative reaction. I start a moan about how terrible this new thing is, then find out halfway through that I've already had it for months and not even noticed...That must teach me something.
A better way of dealing with tabs Posted Dec 17, 2012 18:35 UTC (Mon) by hummassa (subscriber, #307) [Link]
> Will the 'tabs on top' concept break tree-style tabs?
AFAICR tree-style tabs are already "on top" in the sense that "the toolbar and address bar are contained in the container switched by the tabs".
A better way of dealing with tabs Posted Dec 18, 2012 8:01 UTC (Tue) by micka (subscriber, #38720) [Link]
Not at all, as far as I can see.
In my current browser with tree style tabs, I see "back", "forward" and "reload" buttons and the address bar on top, and below are the tab headers (on the left) with the contents.
Security implications for user interface changes? Posted Nov 29, 2012 9:17 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Ok, GNOME developers, confess who of you have penetrated the Mozilla project security and is working to undermine it?
Security implications for user interface changes? Posted Nov 29, 2012 12:47 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Suggest to do some kind of sports or something to get the frustration out.
Security implications for user interface changes? Posted Nov 29, 2012 16:09 UTC (Thu) by jreiser (subscriber, #11027) [Link]
Some part of this is an argument about mere placement of UI elements. That should be left for the end user to customize, perhaps similar to the way that buttons at the top (Back, Forward, Stop, Refresh, Home, etc.) can be ordered or deleted by Button3 > Customize.... More generally, layout could be arranged by a TeX description, a tree map with constraints (minimum pixels, percentage of width or height, ...), or a loadable Python module.
Security implications for user interface changes? Posted Nov 29, 2012 20:22 UTC (Thu) by dashesy (subscriber, #74652) [Link]
Or a simple drag-n-drop in a special mode with wobbly controls. Seriously CSS should be used to give users exactly the layout they want, one may prefer the tabs to be centered with two lines of them and split the screen like Vim does.
Security implications for user interface changes? Posted Nov 30, 2012 16:22 UTC (Fri) by keeperofdakeys (subscriber, #82635) [Link]
Firefox's UI is written in XUL, which actually does use CSS for layout. There is an extension called Stylish to allow you to change this.
holy cow Posted Nov 29, 2012 20:18 UTC (Thu) by yodermk (subscriber, #3803) [Link]
Whenever this change to Firefox happened, I didn't even *notice* it until now!
holy cow Posted Nov 29, 2012 22:47 UTC (Thu) by jmclnx (subscriber, #72456) [Link]
I never noticed it either, I did move it to the "bottom" to see what it would look like. Seems a more logical place, but I changed it back to the default (top) because I really do not care
And the reason is? Posted Nov 30, 2012 23:17 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] In all this conversation I see nothing about why the tabs were/should be moved. (When the change took place, I poked around until I found the ``Tabs on top'' box, and unchecked it. I'd forgotten its existence until just now.)What's the thinking behind putting the address bar (is that what they call the ``awsome'' bar?) between tabs and the content they control? Also, what vast pot of code spaghetti is going to be drained by removing a binary switch?
And the reason is? Posted Nov 30, 2012 23:33 UTC (Fri) by hummassa (subscriber, #307) [Link]
> What's the thinking behind putting the address bar (is that what they call the ``awsome'' bar?) between tabs and the content they control?
1. yes, the address bar is what they call the "awesome" bar because now it's also a search bar that can start searches on the text of the already-visited pages and you can also start searches on your favorite search provider (google, bing, duckduckgo, imdb...)
2. the rationale (started with Chrome IIRC) is that the address stated in the address bar belongs to the page being displayed (imagine if you had windows instead of tabs, each window has its address bar and toolbar... so does each "tab page" when you are using tabs. The address is not "between the tabs and the content", it is a part of the content.
And the reason is? Posted Dec 1, 2012 13:28 UTC (Sat) by IkeTo (subscriber, #2122) [Link]
Then should the menu bar be below the tab bar? Perhaps the tab bar should really replace the title bar drawn by the WM. :-)
And the reason is? Posted Dec 1, 2012 17:57 UTC (Sat) by hummassa (subscriber, #307) [Link]
> Perhaps the tab bar should really replace the title bar drawn by the WM
That's where it is in chrome...
And the reason is? Posted Dec 2, 2012 2:46 UTC (Sun) by Max.Hyre (subscriber, #1054) [Link] Thank you—now I understand. I don't agree, mind you...
holy reload Posted Dec 2, 2012 23:37 UTC (Sun) by pboddie (guest, #50784) [Link]
I notice every time when I switch between home and work desktops that the reload button was moved from its traditional place next to the back and forward buttons to the right-hand side of the address bar (alongside the "bookmark star" and pull-down menu control), apparently causing the forward button to retire, too.
I'm sure that people put forward great reasons for changing all this stuff, but change apparently for change's sake can be really annoying, and it is why a lot of people stick with things like Windows XP (even going to the lengths of installing it over other Windows versions on newer hardware and also paying the Microsoft Tax) instead of just going with the "latest and greatest".
So the security argument is actually relevant because it references a widely observed phenomenon that continues to have security and maintenance implications.
holy reload Posted Dec 2, 2012 23:45 UTC (Sun) by ABCD (subscriber, #53650) [Link] I notice every time when I switch between home and work desktops that the reload button was moved from its traditional place next to the back and forward buttons to the right-hand side of the address bar (alongside the "bookmark star" and pull-down menu control), apparently causing the forward button to retire, too. The reload/stop buttons can be moved back to their traditional location by using the built-in toolbar customization. The forward button now only appears if there is something to move forward to (that is, you have used the back button).
holy reload Posted Dec 3, 2012 8:23 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> The reload/stop buttons can be moved back to their traditional location by using the built-in toolbar customization.
Or they can be made completely irrelevant by using keyboard shortcuts :)
holy reload Posted Dec 3, 2012 16:34 UTC (Mon) by pboddie (guest, #50784) [Link]
I'll try and figure this out, thanks. Another problem I keep having is that Firefox 10 ESR periodically forgets things like the most commonly visited URLs or the open tabs, and occasionally just gets upset by some focus change and disappears spontaneously. I have the impression that it's just a lot less stable than the supposedly ancient version I use on Ubuntu "Historical Heron".
holy cow Posted Dec 4, 2012 12:08 UTC (Tue) by jwakely (subscriber, #60262) [Link]
Ha, I hadn't noticed it change either. Keep up the good work, FireFox devs
Security implications for user interface changes? Posted Dec 6, 2012 9:13 UTC (Thu) by engla (guest, #47454) [Link]
A fitting story for our time. Making up false security concerns and trying to address them with large but useless processes (in this case, backwards compatibility for everything...).
Security implications for user interface changes? Posted Dec 8, 2012 11:20 UTC (Sat) by steffen780 (guest, #68142) [Link]
How exactly does hiding a config option free up time to clean other code? How many lines does having a proper GUI toggle for this feature take? I woud guess about 3? And maintaining those 3 lines prevents Mozilla from cleaning up other code? Are they actually serious?
Security implications for user interface changes? Posted Dec 8, 2012 16:31 UTC (Sat) by intgr (subscriber, #39733) [Link]
They're not talking about "hiding" the option -- it's already hidden in recent Firefox versions. They're talking about removing the (hidden) option to relocate tabs on top/bottom entirely. That's certainly more than "3 lines of code".
Security implications for user interface changes? Posted Dec 9, 2012 23:19 UTC (Sun) by Baylink (subscriber, #755) [Link]
Mozilla *has* a VP Engineering for Firefox?
Well, that guy should clearly have gotten fired when he let "new major revision number every 6 weeks" get past him out the door, anyway, cause he's clearly professionally incompetent.
This is just more evidence; the change they wish to make -- of which I too am intolerant -- is one that they should not make for a *very good reason* -- a reason which I would place bets lots of the people who are naysaying have mentioned, but which I note none of this coverage seems to mention:
It's *wrong*.
The items they wish to move "inside" the framing of the tabs *are not items which are different on a per-tab basis*; those items *do not belong inside the tabs*.
So, what they're doing is violating one of the standard WIMP design/layout metaphors, which was done that way for very good reason: because it's intuitive the way it is.
But then, it doesn't surprise me much to find that Firefox, like Android, is in pretty dire need of adult supervision.
Security implications for user interface changes? Posted Dec 10, 2012 0:24 UTC (Mon) by cortana (subscriber, #24596) [Link]
> The items they wish to move "inside" the framing of the tabs *are not items which are different on a per-tab basis*; those items *do not belong inside the tabs*.
They don't? The state of the back/forward/refresh buttons and address bar are different for each tab.
Security implications for user interface changes? Posted Dec 10, 2012 0:57 UTC (Mon) by hummassa (subscriber, #307) [Link]
Yeah, they are not "the global addressbar, stop/refresh button, back/forward button"... they are "that tab's addressbar and buttons".
Just imagine: if instead of opening a lot of tabs you just opened a lot of windows, each window would have its addressbar and buttons. Then, if you use a tabbing window manager (that groups windows of the same program in tabs), then you would have exactly what Firefox and Chrome has today.
Security implications for user interface changes! Posted Dec 13, 2012 16:47 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
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.
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
|
|||||||||||||