7 ms·

> It is not possible for xargs to be used securely Eh... That is taken out of context quite a bit, that sentence does continue. Just do `cat "$HOME/changed_f

> It is not possible for xargs to be used securely Eh... That is taken out of context quite a bit, that sentence does continue. Just do `cat "$HOME/changed_files" | xargs -r editorconfig-checker --` and this specific problem is fixed.

woodruffw 11mo ago
Yeah, I don't think the specific reason for that sentence in the manpage applies here. But the general sentiment is correct: not all programs support `--` as a delimiter between arguments and inputs, so many xargs invocations are one argument injection away from arbitrary code execution. (This is traditionally a non-issue, since the whole point is to execute code. So this isn't xargs' fault so much as it's the undying problem of tools being reused across privilege contexts.)
- ishouldbework 11mo ago
  Well, anything POSIX or GNU does support the --. I think most golang libraries as well? And if the program does not, you can always pass the files as relative paths (./--help) to work around that. For sure though, this can get tricky, but I am not really aware of an alternative. :/ Since the calling convention is just an array of strings, there is no generic way to handle this without knowing what program you are calling and how it handles command line. This is not specific to xargs... Well, I guess FFI would be a way, but it seems like a major PITA to have to figure out how to call a golang function from bash shell just to "call" a program.
  - woodruffw 11mo ago
    > This is not specific to xargs... Right, it's just that xargs surfaces it easily. I suspect most people don't realize that they're fanning arbitrary arguments into programs when they use xargs to fan input files.
hombre_fatal 11mo ago
Though that's like adding `<div>{escapeHtml(value)}</div>` everywhere you ever display a value in html to avoid xss. If you have to opt in to safe usage at every turn, then it's an unsafe way of doing things.
- stonogo 11mo ago
  I don't disagree but "it's not possible for xxx to be used securely" is a long way from "it's cumbersome and tedious to use xxx securely"
  - JasonSage 11mo ago
    But "it's not possible for xxx to be used securely" is a better premise if it deflects people who can't do it correctly.
    - stonogo 11mo ago
      Lying to people because you think you're smarter than them is bad policy.
  - rendaw 11mo ago
    If using it securely requires you to never ever forget, even once, I'd agree with GP.

woodruffw 11mo ago

Yeah, I don't think the specific reason for that sentence in the manpage applies here. But the general sentiment is correct: not all programs support `--` as a delimiter between arguments and inputs, so many xargs invocations are one argument injection away from arbitrary code execution. (This is traditionally a non-issue, since the whole point is to execute code. So this isn't xargs' fault so much as it's the undying problem of tools being reused across privilege contexts.)

ishouldbework 11mo ago
Well, anything POSIX or GNU does support the --. I think most golang libraries as well? And if the program does not, you can always pass the files as relative paths (./--help) to work around that. For sure though, this can get tricky, but I am not really aware of an alternative. :/ Since the calling convention is just an array of strings, there is no generic way to handle this without knowing what program you are calling and how it handles command line. This is not specific to xargs... Well, I guess FFI would be a way, but it seems like a major PITA to have to figure out how to call a golang function from bash shell just to "call" a program.
- woodruffw 11mo ago
  > This is not specific to xargs... Right, it's just that xargs surfaces it easily. I suspect most people don't realize that they're fanning arbitrary arguments into programs when they use xargs to fan input files.

hombre_fatal 11mo ago

Though that's like adding `<div>{escapeHtml(value)}</div>` everywhere you ever display a value in html to avoid xss. If you have to opt in to safe usage at every turn, then it's an unsafe way of doing things.

stonogo 11mo ago
I don't disagree but "it's not possible for xxx to be used securely" is a long way from "it's cumbersome and tedious to use xxx securely"
- JasonSage 11mo ago
  But "it's not possible for xxx to be used securely" is a better premise if it deflects people who can't do it correctly.
  - stonogo 11mo ago
    Lying to people because you think you're smarter than them is bad policy.
- rendaw 11mo ago
  If using it securely requires you to never ever forget, even once, I'd agree with GP.