8 ms·

Is it just me or would it be a good time to learn a bigger lesson from Heartbleed and Shellshock: Minimalism is seriously a good idea. "Features" are not harml

by 1wd 12y ago

Is it just me or would it be a good time to learn a bigger lesson from Heartbleed and Shellshock: Minimalism is seriously a good idea. "Features" are not harmless and cost way more than you think. Providing more flexibility or functionality than absolutely necessary should really be considered and called out as defective, smelly and a bad practice.

Corrado 12y ago
Which brings to mind the latest push for systemd as an init replacement. :/
- shaurz 12y ago
  Of course systemd theoretically allow systems to boot without any shell installed.
- lambda 12y ago
  One thing to recall is that much of the complexity in systemd comes from replacing a whole bunch of dodgy, special purpose code written in shell scripts (init scripts) and in the daemons it manages (daemonization code, various kinds of racy startup dependencies, etc). Just saying "systemd is complex" is fairly sloppy thinking; the question is, is it more or less complex than re-implementing that functionality poorly and incompatibly several dozen other times in various other daemons and startup scripts?
  - vertex-four 12y ago
    There's significantly less complex ways to do this sort of thing, though. One that I've been looking at implementing into a distro lately is nosh[0] (and execline[1]). Every bit of code is implemented as a separate, independent utility that can be chained together through the nosh/execlineb "shell", which does no parsing and only a tiny bit of lexing. This way, it's easy to pick and choose what features and complexity each script needs, and the features that you don't use can't affect you. Nothing is running on your system that you don't know about, and there's no complex "magic" anywhere unless you explicitly ran a command which does magic things. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... [1] http://skarnet.org/software/execline/ http://skarnet.org/software/execline/
    - pmahoney 12y ago
      Execline is a little mindbending at first, but a really nice way to write scripts for launching other programs.
- zorked 12y ago
  You will be shocked to learn that the Linux kernel is actually much bigger :/
  - SixSigma 12y ago
    Which, in itself, is another disaster.
    - vhost- 12y ago
      Erm what? Can you elaborate a bit on this?
      - SixSigma 12y ago
        Massive kernel, loads of code. Impossible to read and understand.
  - jude- 12y ago
    You seem to be committing Systemd Logical Fallacy #12: "The Linux kernel is complex, and you use the Linux kernel, therefore you are okay with systemd being complex too" Full list of fallacies: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...
- illumen 12y ago
  We should put pulseaudio in the init too. That never crashes.
SixSigma 12y ago
The plan9 community have been bashing bash for years. "It's got to much code, a shell should just execute shellscript not handle input" Perhaps they'll listen now - haha as if
- 1wd 12y ago
  Maybe we need a catchy name for this "anti-pattern".
  - SixSigma 12y ago
    we do : GNU
- dllthomas 12y ago
  "It's got to much code, a shell should just execute shellscript not handle input" Honestly, I'd sooner go the other way.
  - SixSigma 12y ago
    In plan9 the two functions are totally split. rc doesn't handle any input apart from stdin, stdout and stderr. The window manager handles input/output and sends bytes to stdout for processing. The environment is a per process filesystem in /proc/$pid/env/ . Keeping the TTY around is a dumb move. Kill it with fire.
    - dllthomas 12y ago
      So... not really any difference, in any sense that is remotely relevant. My point was that the shell interface is a much better UI than it is programming language.
      - SixSigma 12y ago
        We totally disagree. The ad-hoc nature of unplanned and ill disciplined thrashing away at readline is a terrible interface. Dave Presotto put it best "Linux: by amateurs, for amateurs"
fmavituna 12y ago
Schneier said it best : "Complexity is the worst enemy of security"
jingo 12y ago
Send me sales people (or anyone for that matter) who want to market and sell "minimalism". All the ones I know only want to sell "features". Your words are absolutely 100% true, 1wd. But I have become cynical that the world of software developers and their best customers (e.g., the ones who love "features") will never, ever follow your advice. Personally, I prefer minimalism irrespective of the security benefits. But "engineering", a term many HN readers might attribute to their own work, like to speak of "trade-offs". All engineering involves trade-offs. When you go without "features", sometimes you actually get something in return. What you "get" might not always be obvious. This week, it should be obvious. At least to everyone who chooses a more minimal shell without surplus features. http://mywiki.wooledge.org/Bashism http://mywiki.wooledge.org/Bashism http://news.ycombinator.com/item?id=6866696p http://news.ycombinator.com/item?id=6866696p
jameshart 12y ago
Arguably an insistence on stitching together systems out of 'do one thing and one thing only' minimalist components is precisely why Shellshock is so bad, though. That so many things delegate setting environment variables to the system shell is what allows a vulnerability like this to be so pervasive. Why does a DHCP client pass server-originated data to a full shell? In some ways, it's a form of minimalism.
- SixSigma 12y ago
  In band signalling = bad
- Florin_Andrei 12y ago
  No, it's a form of laziness.
- clarry 12y ago
  > That so many things delegate setting environment variables to the system shell I think you've completely misunderstood the problem. The environment variable isn't and doesn't need to be set by a shell for shellshock to happen. Why shouldn't a DHCP client pass server-originated data to a shell? Or any other program? There is nothing wrong with passing data. The only problem here is that a specific shell had a bug.

by 1wd 12y ago

Corrado 12y ago

Which brings to mind the latest push for systemd as an init replacement. :/

shaurz 12y ago
Of course systemd theoretically allow systems to boot without any shell installed.
lambda 12y ago
One thing to recall is that much of the complexity in systemd comes from replacing a whole bunch of dodgy, special purpose code written in shell scripts (init scripts) and in the daemons it manages (daemonization code, various kinds of racy startup dependencies, etc). Just saying "systemd is complex" is fairly sloppy thinking; the question is, is it more or less complex than re-implementing that functionality poorly and incompatibly several dozen other times in various other daemons and startup scripts?
- vertex-four 12y ago
  There's significantly less complex ways to do this sort of thing, though. One that I've been looking at implementing into a distro lately is nosh[0] (and execline[1]). Every bit of code is implemented as a separate, independent utility that can be chained together through the nosh/execlineb "shell", which does no parsing and only a tiny bit of lexing. This way, it's easy to pick and choose what features and complexity each script needs, and the features that you don't use can't affect you. Nothing is running on your system that you don't know about, and there's no complex "magic" anywhere unless you explicitly ran a command which does magic things. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... [1] http://skarnet.org/software/execline/ http://skarnet.org/software/execline/
  - pmahoney 12y ago
    Execline is a little mindbending at first, but a really nice way to write scripts for launching other programs.
zorked 12y ago
You will be shocked to learn that the Linux kernel is actually much bigger :/
- SixSigma 12y ago
  Which, in itself, is another disaster.
  - vhost- 12y ago
    Erm what? Can you elaborate a bit on this?
    - SixSigma 12y ago
      Massive kernel, loads of code. Impossible to read and understand.
- jude- 12y ago
  You seem to be committing Systemd Logical Fallacy #12: "The Linux kernel is complex, and you use the Linux kernel, therefore you are okay with systemd being complex too" Full list of fallacies: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...
illumen 12y ago
We should put pulseaudio in the init too. That never crashes.

SixSigma 12y ago

The plan9 community have been bashing bash for years. "It's got to much code, a shell should just execute shellscript not handle input" Perhaps they'll listen now - haha as if

1wd 12y ago
Maybe we need a catchy name for this "anti-pattern".
- SixSigma 12y ago
  we do : GNU
dllthomas 12y ago
"It's got to much code, a shell should just execute shellscript not handle input" Honestly, I'd sooner go the other way.
- SixSigma 12y ago
  In plan9 the two functions are totally split. rc doesn't handle any input apart from stdin, stdout and stderr. The window manager handles input/output and sends bytes to stdout for processing. The environment is a per process filesystem in /proc/$pid/env/ . Keeping the TTY around is a dumb move. Kill it with fire.
  - dllthomas 12y ago
    So... not really any difference, in any sense that is remotely relevant. My point was that the shell interface is a much better UI than it is programming language.
    - SixSigma 12y ago
      We totally disagree. The ad-hoc nature of unplanned and ill disciplined thrashing away at readline is a terrible interface. Dave Presotto put it best "Linux: by amateurs, for amateurs"

fmavituna 12y ago

Schneier said it best : "Complexity is the worst enemy of security"

jingo 12y ago

Send me sales people (or anyone for that matter) who want to market and sell "minimalism". All the ones I know only want to sell "features". Your words are absolutely 100% true, 1wd. But I have become cynical that the world of software developers and their best customers (e.g., the ones who love "features") will never, ever follow your advice. Personally, I prefer minimalism irrespective of the security benefits. But "engineering", a term many HN readers might attribute to their own work, like to speak of "trade-offs". All engineering involves trade-offs. When you go without "features", sometimes you actually get something in return. What you "get" might not always be obvious. This week, it should be obvious. At least to everyone who chooses a more minimal shell without surplus features. http://mywiki.wooledge.org/Bashism http://mywiki.wooledge.org/Bashism http://news.ycombinator.com/item?id=6866696p http://news.ycombinator.com/item?id=6866696p

jameshart 12y ago

Arguably an insistence on stitching together systems out of 'do one thing and one thing only' minimalist components is precisely why Shellshock is so bad, though. That so many things delegate setting environment variables to the system shell is what allows a vulnerability like this to be so pervasive. Why does a DHCP client pass server-originated data to a full shell? In some ways, it's a form of minimalism.

SixSigma 12y ago
In band signalling = bad
Florin_Andrei 12y ago
No, it's a form of laziness.
clarry 12y ago
> That so many things delegate setting environment variables to the system shell I think you've completely misunderstood the problem. The environment variable isn't and doesn't need to be set by a shell for shellshock to happen. Why shouldn't a DHCP client pass server-originated data to a shell? Or any other program? There is nothing wrong with passing data. The only problem here is that a specific shell had a bug.