search for: footgun

raf wrote: > Not knowing the details of each user's login shell is > precisely the reason that ssh couldn't ever do the > quoting itself. The footgun is unrelated to shells. The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254) channels which are used to run a single remote command contains exactly one string for the command. sshd (see bottom of do_child() in session.c) runs that command string as: remote_users_shell -c...

On Mon, May 29, 2023 at 06:35:34PM +0000, Peter Stuge <peter at stuge.se> wrote: > raf wrote: > > Not knowing the details of each user's login shell is > > precisely the reason that ssh couldn't ever do the > > quoting itself. > > The footgun is unrelated to shells. > > The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254) > channels which are used to run a single remote command contains > exactly one string for the command. > > sshd (see bottom of do_child() in session.c) runs that command str...

On 27/05/2023 01:45, Thorsten Glaser wrote: >> ssh user at host "ls -l a\ b" > This one, incidentally, sends 'ls -l a b' to the remote shell. > ssh user at host "ls -l a\\ b" > has the effect you want; the first backslash is eaten by the > local shell. > Or is it? $ echo "ls -l a\ b" ls -l a\ b $ This is with bash 5.2.15. From the

Hi, ssh(1) currently affords an argument-passing functionality, but as the manpage states, all arguments are simply concatenated by space. This behavior is non-obvious for those reading only the synopsis: one would expect something that takes argv input to somehow preserve the argument boundary and not, say, let a semicolon ruin all the fun. This is probably old news for all of you. I have

On 27.05.23 00:08, Thorsten Glaser wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: >> The less modest one is we throw out the "[argument ...]" part altogether. It > > Absolutely not. This will break about all uses of ssh in existence. You are confusing "ssh(1) does (not) distinguish between 'command' and 'argument(s)'" with

On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > > > ssh(1) currently affords an argument-passing functionality, but as the manpage > > states, all arguments are simply concatenated by space. > > How else would it do that? The arguments are processed by the > shell

On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > ssh(1) currently affords an argument-passing functionality, but as the manpage > states, all arguments are simply concatenated by space. How else would it do that? The arguments are processed by the shell first then passed as an array of NUL-terminated strings. > The modest proposal is that we put a giant CAVEATS section in the

On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Sat, 27 May 2023, raf wrote: > > >So, perhaps this could be added to the existing > >sentence/paragraph: > > > > "so any spaces in individual arguments must be > > Must they? No, a single space will do just fine. They do if you want the receiving shell

On Sat, 27 May 2023, raf wrote: >So, perhaps this could be added to the existing >sentence/paragraph: > > "so any spaces in individual arguments must be Must they? No, a single space will do just fine. > quoted using the syntax of the destination > user's login shell". ? keeping in mind the source shell?s quoting as well. >If an example were needed,

https://bugzilla.mindrot.org/show_bug.cgi?id=3660 Bug ID: 3660 Summary: Prevent disastrous unintended local copying Product: Portable OpenSSH Version: 9.6p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: scp Assignee: unassigned-bugs at

...lues, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that the compiler forced users to deal with this when using intrinsics. This is a real nasty footgun -- if you get this wrong, your program doesn't crash -- no, that would be too easy! Instead, every x87 instruction will simply result in a NaN value. Even more unfortunately than all that, it is currently impossible to correctly use _mm_empty() to resolve the problem, because the compiler has...

...t; required to call _mm_empty() before using any x87 floating point > instructions or leaving the function. I was aware that this was required at > the assembly-level, but not that the compiler forced users to deal with > this when using intrinsics. > > > > This is a real nasty footgun -- if you get this wrong, your program > doesn't crash -- no, that would be too easy! Instead, every x87 instruction > will simply result in a NaN value. > > > > Even more unfortunately than all that, it is currently impossible to > correctly use _mm_empty() to resolve the...

https://bugzilla.mindrot.org/show_bug.cgi?id=2081 Bug ID: 2081 Summary: extend the parameters to the AuthorizedKeysCommand Classification: Unclassified Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd