Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This stubborn attitude to refuse to consult the documentation at all and then expect the tool to work according to your preconceptions.

Tools do have rough edges, if you don't want to learn about them, you will get bitten.



This statement can be true without contradicting anything anyone said upstream. Otherwise could use it to justify just about any bad design decision.

Yes it’s in the docs. Yes people who carefully read the docs won’t get bitten. Also yes the design could be improved so people don’t make this mistake even without reading the docs.

Both things can be true. We’re currently only talking about the latter, though.


> We’re currently only talking about the latter, though.

I'm surprised, as i started this subthread explicitly to contest that the argv join is "hidden".


It’s a design mistake because it adds exactly zero functionality.

The only thing it adds is insecurity.

If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.


[flagged]


I think you missed the original point, which is that joining argv is equivalent to

    sh -c "$1 $2 $3 $4 ..."
This is a form of shell injection, just like

    sh -c "ls $dir"
because there's interpolation WITHOUT escaping.

That should be:

    dir=$(escape "$dir")
    sh -c "ls $dir"
Or simply

    ls "$dir"
It's not my preconception -- it's a security problem.

It's similar to ShellShock -- you can argue it was documented behavior, but it's still a security problem.


The interpolation is not the security problem, the problem is the user not quoting their data.

It's similar to curl CWE-93[1], where it was documented and in-use behavior and consequently was rejected as a security problem.

Example for ssh:

  ssh host ls "$(quote "$dir")"
[1] https://hackerone.com/reports/3133379


No, the problem is that even if you quote your data, ssh unquotes it, so you have to quote it twice.


> ssh unquotes it

ssh does not unquote. Its the local shell, if you are invoking ssh via execv, this does not apply.


So instead of unquoting your data itself, ssh invokes another program to unquote it. That's a distinction without a difference.


No, ssh is called by the local shell. ssh never gets to see the quoted value that you typed in your shell. This mechanism is unrelated to ssh, at all:

  $ printf "%s\n" "asdf"
  asdf
You see the double quotes go missing.

This happens as part of the shell turning the command string into argument vectors to pass to execv().


When I run:

ssh foo@bar "echo 'hello world'"

ssh chooses to unquote the string: echo 'hello world'

splitting it into two parts (echo, and hello world), and then running the program echo with the argument hello world.

The fact it does this via a separate program is irrelevant.


> ssh chooses to unquote the string > splitting it into two parts

wrong, ssh does no argument splitting

> then running the program echo

wrong, it passes the string to the users login shell, whatever program that is. See sshd(8).

> The fact it does this via a separate program is irrelevant

just gently caress yourself.


the fact that ssh chooses to invoke another program to split arguments instead of splitting arguments itself is a distinction without a difference.


And yet it keeps happening. An engineering field grows up when people stop assigning blame, and start searching for solutions.


I just posted one way how to do it correctly.

And research (aka: consulting the manpage) is an essential part of engineering. Doing that would also solve the problem.


This very stubborn attitude to defend a bad design because it's documented.

Bugs can be fixed.


It is bad design, but your idea of something does not make anything non-conforming a bug.


> Tools do have rough edges, if you don't want to learn about them, you will get bitten.

I presume you consider INTERCAL to be a sanely designed programming language.


I'm not defending SSH's design, im criticizing peoples unwillingness to learn about the design as it is so they can work around it.

Edit: The INTERCAL handbook is a great read, and despite being satirical, it is more detailed and qualified than the documentation of some other popular projects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: