Dash As The Default Shell For Fedora?

[gens]

It is never a good excuse to say there are security bugs in other software, so this isn't a big deal. The default system shell is far more critically important than say Pidgin is for Linux users. Also the discussion wasn't merely about security but also size, performance etc.

it is not an excuse... it is a reality check
for you pidgin is not a security hole,
but fun fact is i found out about that hole from a presentation on practical hacking
pidgin was the link from outside to a networked computer and from there a bug in a network card driver (caused by a patch for a bug in the chip, patch being from intel copied by red-hat into mainline) allowed for hacking together custom packages
funny thing that security, it's not always obvious

[kringel]

Wait... Red Hat and its "independent/community" devolpers of Fedora who are pushing systemd now are pushing for a user shell *without* feature bloat?

Isn't Ironic?

(great... now I have an earworm)

[GreatEmerald]

And yet having two different shells means it's an increased attack surface. I'd say it's best to use whatever is most audited. Though probably none of the shells really are audited much...

[xeekei]

Wait... Red Hat and its "independent/community" devolpers of Fedora who are pushing systemd now are pushing for a user shell *without* feature bloat?

Isn't Ironic?

(great... now I have an earworm)

Well, I don't think they follow your definition of bloat.

[makomk]

It is interesting to see how people suddenly are fleeing towards other shells. But does that really make sense? Nobody can assure you that other shells don't have similar problems. After some mass use they might exhibit also flaws and defects. Or does any of those have regular code audits?
I'm not into any shell bashing (no pun ) but it's interesting to see people's reactions.

The Android security team supposedly gave mksh some level of auditing before allowing it into Android, but I've no idea how in-depth it was - they may only have checked that it didn't cause a security issue for Android as a whole which makes very limited use of it.

[Luke_Wolf]

And yet having two different shells means it's an increased attack surface. I'd say it's best to use whatever is most audited. Though probably none of the shells really are audited much...

a good half a dozen shells are installed by default on pretty much any Linux distro anyway including ksh, tcsh, zsh, and bash, in openSUSE's case sash is also included

[Delgarde]

I've never even (still don't) know anything about Dash other than years ago seeing a switch to it in a HowToForge article where switch the shell from Bash. Perhaps an article on the differences. Is it really any more secure? and what other (viable)options are available?

Debian/Ubuntu mostly use it because it starts up quicker than bash, which makes a big difference to boot times when your init process consists of hundreds of little shell scripts constantly forking and exiting - but that's not very relevant to distros that use systemd (or upstart). There's no real security benefits I can see - true, the dash codebase is smaller (and therefore easier to audit), but that doesn't automatically make it more secure. A point made on the Fedora mailing list was while dash and bash are of similar age, more security-related bugs have been found in the former - for all the drama of this recent bug in bash, it's also an extremely rare event.

[Delgarde]

Personally I like the idea of a system with interchangeable parts and where there are several independently developed variants of just about every component. This requires that communications between the parts (including shell scripts) adhere to a strict minimal common standard.

Oh, it's a lovely idea. It's just really difficult to do well in practice, because as you say - all those swappable components are constrained to work with the minimal common standard.

Take the shell, for example - you can write scripts that will run on /bin/sh on any machine, regardless of what POSIX-compliant package is providing that interpreter. But the cost of that is that you're limited to the minimum capabilities specified in the standard - you can't use any of the bash-specific features that might make your job a thousand times easier. That's pretty much a no-brain decision, so all my shell-scripts begin #!/bin/bash... if they need to run on non-Linux systems (as they often do), it's easier to require bash be installed on those systems than to work without the bash features.

[interested]

Personally I like the idea of a system with interchangeable parts and where there are several independently developed variants of just about every component. This requires that communications between the parts (including shell scripts) adhere to a strict minimal common standard. "Network effects" - aka "lock-in" is generally a bad thing I think because it reduces choice (compare this to the whole debate surrounding systemd assimilating desktop-critical functions like udev, logind, ... creating a "network effect" prodding distributions to adopt to it).

You are contradicting yourself here; If you really believe in an OS of interchangeable parts, stop looking enviously at either udev or logind, and start making alternatives. Logind was always a part of systemd. The old alternative to logind was ConsoleKit, but that have been deprecated a long time ago.

Despite years of warning, the non-systemd camp in Linux have utterly failed to make any real alternative to systemd's core functions, like logind or udev. At the moment the only Linux alternative to logind is a code fork of logind, same with udev.

It looks like no one really is interested in making an OS like you describe. People may _want_ such an OS, but when it comes to the actual work, they don't seem to bother.

[Scimmia]

a good half a dozen shells are installed by default on pretty much any Linux distro anyway including ksh, tcsh, zsh, and bash, in openSUSE's case sash is also included

No, that's only on huge, bloated systems.