You can clone with
Background: in the process image argv and envp are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.
These days these "privileged ps hacks" are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked.
However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to, running as a non-root user:
$ ps ewwwax | grep cron | grep -v grep
352378 - A 0:20 /usr/sbin/cron _=/usr/sbin/cron LANG=en_US PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/home/java14/jre/bin:/home/java14/bin LC__FASTMSG=true LOCPATH=/usr/lib/nls/loc ODMDIR=/etc/objrepos PWD=/ TZ=PST8PDT NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat
Today, mosh seems to be only on Linux/OSX/FreeBSD but if it catches on I'm afraid it will end up on some platform that still uses the old-school UNIX "everybody can see anybody's environment variables" model. Since $MOSH_KEY is basically the keys-to-the-kingdom this would be a humungous hole.
There's a well established pattern for dealing with this: send the key over a pipe. So the call looks like:
$ mosh-client --key-fd=3 10.1.2.3 60001
...and the parent process has a pipe open on fd=3 when it exec's mosh-client which it can write the key to.
We're aware of this issue, but thank you for giving us a report about AIX. We've been discussing what to do about it; at minimum we will add a warning in the build instructions.
I guess one question would be is it worth to have the client split into separate perl and C++ halves at all? Just glancing at the perl script it doesn't look like it's doing anything that would be heinous to implement in C++. Then you could possibly roll the whole thing up into one binary (even the server could be just a command line flag like "--run-as-server" similar to how tools like rdist/rsync work)
Anyway -- great tool guys. Solves a real problem in a creative way. I'm looking forward to seeing its evolution.
Indeed, we have a prototype of the wrapper in C++, and we've discussed merging it with mosh-client. It would solve this problem among others.
We're considering merging the wrapper with mosh-client in Mosh 1.3. That would eliminate the env var key passing in the common case. I expect we would still support it for those users who launch mosh-server by some means other than SSH. But I'm uneasy about turning env var key passing into a more obscure, less tested alternative. Maybe we should also implement --key-fd=3 or such.