LWN: Comments on "Bash 5.0 released"

Bash 5.0 released

dualbus — Mon, 21 Jan 2019 06:40:24 +0000

> The difference is that most of these acknowledge that their code is used in security critical areas anyway, and have started to adapt their practices accordingly. Apparently, Chet has not. (...)

What does git have to do with security? I read the weekly change sets when they're pushed, and I have no trouble understanding what's being changed or why. Sure, it might not be the commit /style/ you prefer, but has little to do with the quality of the software, or its security characteristics.

Also, perhaps ask Chet to provide more detailed / specific commits instead of just assuming he doesn't want to?

Bash 5.0 released

dualbus — Mon, 21 Jan 2019 06:32:35 +0000

The initial git migration was discussed here: http://lists.nongnu.org/archive/html/bug-bash/2011-11/msg...

And the only time I'm aware of it being brought up as a specific discussion topic is here: https://lists.gnu.org/archive/html/bug-bash/2015-03/msg00... (spoiler alert: I gave up really quickly on maintaining that mirror)

Bash 5.0 released

pabs — Mon, 21 Jan 2019 02:29:14 +0000

Has anyone talked to Chet about changing to a more fine grained revision history before?

Bash 5.0 released

pizza — Sun, 20 Jan 2019 22:30:39 +0000

> but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.

No argument from me there!

...but whether or not it is possible to convince him to change his ways, denigrating him and his work is not the way to accomplish it.

Bash 5.0 released

smurf — Sun, 20 Jan 2019 20:48:01 +0000

No, I'm saying that c.e. applies to everything. Bash dash openssh kernel libreoffice windows msoffice – doesn't matter, they all say that, they only differ in how many words they use.

The difference is that most of these acknowledge that their code is used in security critical areas anyway, and have started to adapt their practices accordingly. Apparently, Chet has not. As I wrote, his choice, just as mine is to hack on any script I come across until it no longer says #!/bin/bash on top.

Bash 5.0 released

mjg59 — Sun, 20 Jan 2019 20:41:15 +0000

Two things that can simultaneously be true:

1) Chet's work is a great gift to the free software community and we have benefited hugely from it over decades

2) Over that time we've learned that there are ways to maintain software that make it easier for others to consume that work, contribute code back and identify and fix issues. Now that we're aware that there are better ways to do it, we're also aware of the additional costs imposed on consumers by not having a fine grained revision history. Overall people still seem to feel that the benefits provided by bash outweigh the drawbacks, but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.

Bash 5.0 released

pizza — Sun, 20 Jan 2019 13:43:56 +0000

So you're saying that, somehow, "caveat emptor" doesn't apply here?

If Bash's development practices are somehow unacceptable to you, there are three ways to proceed. Convince its author to do what you want, fork it and do a better job, or switch to something "better". Either way it's going to cost you time, effort, and a non-trivial amount of hard currency.

(And yes, some distributions have switched away from bash for system scripts, primarily for reasons that have since been rendered irrelevant by systemd...)

Bash 5.0 released

pizza — Sun, 20 Jan 2019 13:30:49 +0000

> Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

If *I* am building infrastructure, then *I* will make plans to handle "unspecified stuff going wrong"

What I don't do is expect other folks to do any (additional) unpaid work on behalf of my infrastructure, and I certainly don't denigrate the folks whose work I am already taking advantage of -- because, speaking personally about the Free Software I have released, I'm far more inclined to promptly help out folks that are respectful of the work I have already done, acknowledge that I owe them nothing, and who have not been publicly badmouthing me.

Is *that* so difficult to understand?

Bash 5.0 released

flussence — Sun, 20 Jan 2019 13:27:22 +0000

You might be in for a rude awakening if you continue to feel entitled to infinite return on investment from all the software you use.

Bash 5.0 released

smurf — Sun, 20 Jan 2019 11:13:48 +0000

Yeah. We all know the boilerplate in those licenses. All programs have them. So does the kernel. So what?

The code is, effectively, less auditable and thus less secure when all you see is a sequence of tarballs. Chet appears not to care about any of that. His choice – but it confirms the decision to switch away from Bash which some (most?) distributions took, years ago, for performance/memory usage reasons.

Bash 5.0 released

Cyberax — Sun, 20 Jan 2019 04:13:47 +0000

> So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!
Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

Bash 5.0 released

pizza — Sun, 20 Jan 2019 04:10:38 +0000

So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!

Meanwhile, this little statement is worth repeating:

"Bash is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details."

Bash 5.0 released

Cyberax — Sun, 20 Jan 2019 03:30:34 +0000

No it's not. Because eventually somebody else will have to dig through the history in order to find out the source of the next vulnerability.

It also increases the chances of the next MD_Update disaster.

Bash 5.0 released

dualbus — Sun, 20 Jan 2019 02:54:23 +0000

It is mind boggling how dismissive you're being of other people's work and effort, just because they don't make commits in a specific way.

Appropriate use of version control

rleigh — Fri, 18 Jan 2019 15:21:37 +0000

Version control serves several purposes. Most of them rely upon having a clean history. Firstly, having clear and appropriate commit messages helps to find changes in the history when you need to find when a particular change was made. Secondly, having discrete changes in each commit makes it easier to revert selected changes, as well as to review changes in isolation.

The existing approach may work for the maintainer, and that's fair enough. It's his project. But, it does greatly reduce the utility of the project history both for himself and for anyone else who wants to work upon it. There are existing good practices for using version control, and this approach violates many of them.

Bash 5.0 released

pizza — Tue, 15 Jan 2019 12:00:50 +0000

Make no mistake, the only reason most folks use F/OSS is because "someone else" pays for its development.

Yank bash, and a sizeable portion of the internet will break. It is "hobbyware" only in the sense that nobody other than its authors care about it sufficiently enough to meaningfully contribute to its upkeep.

Meanwhile, even "deprecating" bash requires a nontrivial amount ongoing effort that you're expecting "someone else" to do -- ie pay for.

Bash 5.0 released

cagrazia — Tue, 15 Jan 2019 11:28:12 +0000

I think there's no need to argue for one position or the other. It is crystal clear that bash should be deprecated as soon as possible by all distribution, as it is more a hobbyware than a real critical-mission software.

Bash 5.0 released

Wol — Mon, 14 Jan 2019 12:14:59 +0000

> Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

What value is that? Not what value do YOU place on it, but what value does CHET place on it.

You can't base your argument on your values. I regularly get peed of by BT adverts saying "we're sure you'll love our heavily discounted (yeah ...) SIMS at £10 each". That's if you buy 5 of them! I pay £9 for two sims, with more data, calls and texts than my wife and I ever use. £10/SIM may be great value from BT's point of view, but from mine it's a waste of money ...

Cheers,
Wol

Bash 5.0 released

Wol — Mon, 14 Jan 2019 12:09:18 +0000

> Basically, why should Chet be expected to change because other people like his work? Why can't his work be allowed to fade into historical obscurity?

Or, if people really do want to depend on his work, why can't they start paying him to do it!!!

I'm probably as much the cheapskate as anyone else, but I do try and give back in kind. If you're not prepared to "put your money where your mouth is" you have no right to moan, and if you are prepared then you probably have a far better view of the situation.

The reality is MUCH important software is in this sort of mess, because nobody is prepared to put their hand in their pocket. One piece of software I use has a sole dedicated developer, who is struggling to make ends meet and is also fighting illness. How's that fair? He's doing his best to support Free Software and not doing very well out of it ...

Cheers,
Wol

Bash 5.0 released

farnz — Sat, 12 Jan 2019 18:43:44 +0000

Why should Chet change a workflow that works for him just because other people have started to depend on his work without doing sufficient due diligence to ensure that what he's doing fits theit needs? Instead, why don't people who don't want to depend on Chet's workflow switch to one of dash, zsh or ksh (to name three Bourne shells that aren't bash). Alternatively, why don't people who care fork bash and work on it in ways that they think are better?

Basically, why should Chet be expected to change because other people like his work? Why can't his work be allowed to fade into historical obscurity?

Bash 5.0 released

pizza — Sat, 12 Jan 2019 15:29:46 +0000

Yes, today's world is not the same as the world 20 years ago. So why is today's world holding a solo coder to much higher (and time-consuming) standards while expecting said solo coder's compensation to be the same (ie nothing) as it was 20 years ago?

Bash 5.0 released

smurf — Sat, 12 Jan 2019 14:43:30 +0000

I'm not blaming him. I'm saying that the practices of 20 years ago (a solo coder who periodically surfaces to release a tarball with the next version) do not make sense in today's world.

Chet may or may not want that responsibilty – but the fact is, he does have it. If he doesn't want it, then inviting collaborators and setting up a decent auditable workflow would seem to be a good idea. If he does, well, setting up a decent auditable workflow still is a good idea. We all make mistakes, and bash isn't exactly a simple program.

Bash 5.0 released

rra — Sat, 12 Jan 2019 04:53:27 +0000

> Also, bash is security+mission critical software

Hmmm. I wonder if Chet is getting a paycheck proportionate to maintaining security and mission-critical software for the entire Internet. Or ever indicated any desire to be in that role or ever agreed to shoulder the responsibility for that. Or, in the absence of such a paycheck and agreement, why anyone should expect any particular workflow from him.

We certainly have a much larger problem here, namely that people have built critical infrastructure on top of free software without ever figuring out how to make this process rewarding, comfortable, and supportive for the people maintaining that free software. But then turning around and blaming them for not maintaining that software to the standards desired this critical infrastructure they were never involved in, never approved, aren't being paid for, and that never considered their feelings at all doesn't sit well with me.

Bash 5.0 released

rleigh — Fri, 11 Jan 2019 14:44:41 +0000

Commits containing only a single focussed change with descriptive log messages is not exactly new. Plenty of projects have been doing this for decades, right back to CVS/RCS. There's nothing git-specific about this practice. Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

Bash 5.0 released

smurf — Thu, 10 Jan 2019 17:56:05 +0000

This is not "best effort". Not by a very long shot. It's trivially easy to maintain a reasonable commit history.

Also, bash is security+mission critical software, if only by virtue of being the default login shell. While you don't exactly *need* a sensible change history for auditing the code, it'd make the job an order of magnitude easier.

Bash 5.0 released

smurf — Thu, 10 Jan 2019 17:52:07 +0000

Huh? It says "Sources and documentation". Of course it's code. And translations. And libreadline. And every other friggin' thing that is mentioned in that announcement, plus very likely a bunch that are not.

Yeah, Chet seems to be the sole developer. And with good reason. With that kind of commit history I wouldn't even dream of helping with bash development. I also wouldn't help with security-or-whatever audits – this would be plenty reason to switch to a different shell, except for the fact that Debian's default shell is dash. :-P

No, being a single developer is not an excuse for shoddy commit management. How do you find regressions in that kind of mess??

Bash 5.0 released

Wol — Thu, 10 Jan 2019 14:29:57 +0000

> Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.

This is why so many critical infrastructure programs are poorly maintained! How many developers does bash have!?

If it's just Chet, he has every right to do it however it suits him. If you want to call best efforts "criminal negligence" that says more about you than him! There's plenty of "best practice" that I completely ignore because I don't have a 48hr day to do it in ...

Cheers,
Wol

Bash 5.0 released

Cyberax — Thu, 10 Jan 2019 02:40:10 +0000

> If I'd been productive in a tarball+email workflow for 30 years and some slashdot/hn armchair developers showed up calling me out for not using their pet VCS, I'd be inclined to flash them a bit of malicious compliance too.
Pure BS.

Patch + email workflow is compatible with multiple VCSes, starting from the venerable CVS. It can certainly be done with SVN, Mercurial and pretty much anything else more advanced than Microsoft SourceSafe.

Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.

Bash 5.0 released

flussence — Wed, 09 Jan 2019 23:15:36 +0000

This git repo likely only exists to shut up demands from non-participating trophy collectors who expect every line of code on the internet to be compatible with github's “import” button.

If I'd been productive in a tarball+email workflow for 30 years and some slashdot/hn armchair developers showed up calling me out for not using their pet VCS, I'd be inclined to flash them a bit of malicious compliance too.

Bash 5.0 released

Cyberax — Wed, 09 Jan 2019 22:37:38 +0000

Be thankful they've upgraded from sbrk.

Bash 5.0 released

sb — Wed, 09 Jan 2019 17:35:08 +0000

Just to point out that they do document their changes (see http://git.savannah.gnu.org/cgit/bash.git/tree/CWRU/chang...). They just don't seem to want to do it in the commit messages.

Bash 5.0 released

k8to — Wed, 09 Jan 2019 17:26:51 +0000

Primarily I'm surprised by bash using its own malloc.

Bash 5.0 released

Wol — Wed, 09 Jan 2019 16:46:44 +0000

On the other hand, all the changes were to tiny filesets apart from the last one. Plus the last one said DOCUMENTATION, implying it was NOT code.

My reading of this is maybe it's just simpler to look at the patch and it's documented there - although I will admit that that's a pain when you're trying to find which patch did something.

For a sole developer - seeing as all the commits were Chet - this doesn't seem to me at all unreasonable. Unless of course Cyberax knows more than me, he certainly seems to think there's more than one person maintaining bash ("these guys" - plural) - actually I'd be surprised ...

Cheers,
Wol

Bash 5.0 released

Cyberax — Wed, 09 Jan 2019 09:53:41 +0000

Their git repo is basically just a list of tarball dumps. It's useless.

Compare this to zsh: https://sourceforge.net/p/zsh/code/commit_browser

Bash 5.0 released

XTerminator — Wed, 09 Jan 2019 09:52:30 +0000

Thanks for the explanation. :)

Bash 5.0 released

lobachevsky — Wed, 09 Jan 2019 09:51:42 +0000

Well, there are tiny commits with unhelpful commit messages that are the patch releases and gigantic squashed source dumps for the major releases; no history beyond that.

Bash 5.0 released

zdzichu — Wed, 09 Jan 2019 09:49:28 +0000

I gather it's rather obvious from looking at Cyberax' link. Commit messages in Bash repository are completely useless. They do not explain why the change is done (and what the change is about, which is often not clear), short messages do not convey any meaning and 5.0 commit was a big code drop of bundled unrelated changes.

As for being constructive: there are number of “good commit messages” guides (random searches: https://medium.com/compass-true-north/writing-good-commit... https://code.likeagirl.io/useful-tips-for-writing-better-...). Adopting *any* of the guidelines would increase quality of Bash repo.

Bash 5.0 released

XTerminator — Wed, 09 Jan 2019 09:11:14 +0000

What exactly are you talking about? Not possible to be constructive in your criticism?

Bash 5.0 released

sytoka — Wed, 09 Jan 2019 07:59:14 +0000

fork and extend ;-)

Bash 5.0 released

Cyberax — Wed, 09 Jan 2019 05:13:04 +0000

Ugh.

These guys SERIOUSLY need to change something in their development model. Just look at their git: http://git.savannah.gnu.org/cgit/bash.git/log/