Re: [mosh-devel] Bug#1072233: mosh: use wtmpdb to write wtmp entries

[Keith Winstein]

I think Mosh would be happy to support this transition, but Mosh doesn't
write to utmp/wtmp itself or with a PAM module; Mosh uses libutempter for
this. If libutempter is going to be updated to use wtmpdb, I don't think
Mosh itself has to change.

Sincerely,
Keith

On Thu, May 30, 2024 at 11:49 AM Chris Hofstaedtler  wrote:

> Source: mosh
> Severity: important
>
> Per the discussion on debian-devel, Debian will switch to wtmpdb for
> Y2038-safe wtmp recording. If your package writes wtmp entries,
> please switch to libwtmpdb.
>
> https://lists.debian.org/debian-devel/2024/04/msg00406.html
>
> Chris
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh website giving 404 not found

[Keith Winstein]

Update: I moved hosting for mosh.org over to GitHub Pages to get the site
back online. mosh.mit.edu is still giving a 404 for unclear reasons. :-/

Mosh folks: the "moshweb" repo is now an alias to the "
mosh-project.github.io" repo, and pushing there will go live on the
https://mosh.org website automatically.

On Wed, Apr 17, 2024 at 10:20 AM Keith Winstein 
wrote:

> Hi folks,
>
> Overnight, the mosh_project locker seems to have lost its associations on
> scripts.mit.edu. We're getting "404 Not Found" from http://mosh.mit.edu
> is (and http://mosh.org, which is served through Cloudflare), and
> https://pony.scripts.mit.edu:444/index?locker=mosh_project says "The
> 'mosh_project' locker is not signed up for scripts.mit.edu; sign it up
> first."
>
> Is there a known glitch today? If not, I wanted to put it on your radar.
> As always, thank you for hosting the Mosh website!
>
> Sincerely,
> Keith
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh.org

[Keith Winstein]

The site is back online. Thank you for the report!

On Wed, Apr 17, 2024 at 10:22 AM Keith Winstein  wrote:

> Thanks for the report -- I think there's just an issue today with our web
> host at MIT. I've sent email.
>
> Sincerely,
> Keith
>
> On Wed, Apr 17, 2024 at 9:58 AM Andrew C Aitchison 
> wrote:
>
>>
>> I see that the domain mosh.org is no longer in "the DNS"
>> (although whois still works).
>>
>> I would be sorry to lose this important tool.
>> Does it gave a new home ?
>>
>> Is there anything I can do to help ?
>>
>> Thanks,
>>
>> --
>> Andrew C. Aitchison  Kendal, UK
>> and...@aitchison.me.uk
>>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh.org

[Keith Winstein]

Thanks for the report -- I think there's just an issue today with our web
host at MIT. I've sent email.

Sincerely,
Keith

On Wed, Apr 17, 2024 at 9:58 AM Andrew C Aitchison 
wrote:

>
> I see that the domain mosh.org is no longer in "the DNS"
> (although whois still works).
>
> I would be sorry to lose this important tool.
> Does it gave a new home ?
>
> Is there anything I can do to help ?
>
> Thanks,
>
> --
> Andrew C. Aitchison  Kendal, UK
> and...@aitchison.me.uk
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] Mosh website giving 404 not found

[Keith Winstein]

Hi folks,

Overnight, the mosh_project locker seems to have lost its associations on
scripts.mit.edu. We're getting "404 Not Found" from http://mosh.mit.edu is
(and http://mosh.org, which is served through Cloudflare), and
https://pony.scripts.mit.edu:444/index?locker=mosh_project says "The
'mosh_project' locker is not signed up for scripts.mit.edu; sign it up
first."

Is there a known glitch today? If not, I wanted to put it on your radar. As
always, thank you for hosting the Mosh website!

Sincerely,
Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.4.0 released

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Mosh users and developers,

The Mosh team is pleased to announce the long-awaited 1.4.0 release.
This is our first release in five years and marks ten years since
Mosh 1.0.

The source code is at: https://mosh.org/mosh-1.4.0.tar.gz
(SHA-256: 872e4b134e5df29c8933dff12350785054d2fd2839b5ae6b5587b14db1465ddd)

Release managers were Alex Chernyakhovsky and Benjamin Barenblat, with
major contributions from Wolfgang Sanyer, John Hood, and Anders Kaseorg.

Compatability: Mosh 1.4.0 is backwards-compatible with mosh-clients
back to 0.96 and mosh-servers back to 1.0.9.

Bugs: Please let us know of any problems at the GitHub issue tracker,
at https://github.com/mobile-shell/mosh/issues. The developers can
also be found on IRC at .

Summary: This release has a mix of bug fixes and new features.

New features:

- -Support OSC 52 clipboard copy integration (Alex Cornejo)
- -Allow non-inserting prediction (--predict-overwrite) (John Hood)
- -Don't do prediction on large pastes into mosh-client (John Hood)
- -Add true color support (Kang Jianbin)
- -Add syslog logging of connections (Tom Judge)
- -If exec()ing the remote command fails, pause briefly (John Hood)

Bug fixes:

- -ignore unknown renditions (Keith Winstein)
- -Overlays were getting set to the wrong colors (John Hood)
- -Fix issue with incorrect true-color background erase colors (John Hood)
- -Use HAVE_UTEMPTER instead of HAVE_UPTEMPTER (Michael Jarvis)
- -Apply latest consecutive resize, not earliest (Peter Edwards)
- -Use CLOCK_MONOTONIC_RAW when available (Harry Sintonen)
- -Add tmux and alacritty to title_term_types (Naïm Favier)
- -Don't sometimes hang just after launching ssh (Kalle Samuels)

Internal changes:

- -Reformat printed strings in source (John Hood)
- -Code cleanups (John Hood, Anders Kaseorg, Benjamin Barenblat,
Alex Chernyakhovsky)
- -Always use non-blocking sockets for recvmsg() (John Hood)
- -Add Perl compile (John Hood)
- -Improvements to the test suite (John Hood)
- -Fixes to autoconf configure (Anders Kaseorg)
- -Cleanups to our cryptography code (Benjamin Barenblat, Alex
Chernyakhovsky)

Infrastructure changes:

- -Add support for OCLint static checker (John Hood)
- -Switch from Travis-CI to Github Actions (Wolfgang E. Sanyer,
Alex Chernyakhovsky)
- -Add code coverage and fuzzing infrastructure (Alex Chernyakhovsky)

For more details: https://github.com/mobile-shell/mosh/releases/tag/mosh-1.4.0

Legal: Mosh is distributed under the GNU General Public License
version 3 or later, with exceptions related to OpenSSL and iOS. Mosh
is a registered trademark.

Best regards on behalf of the Mosh team,
Keith Winstein
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEsaRwaRIfZkK7PX8+ILcoOv4lTGkFAmNfxjgACgkQILcoOv4l
TGkaKA//eWoI0bgZfvDRod99IugUF8sUORIvTFXKeVw23JyEaapK4/DPFZG0eTEM
z4Xx1Pydwpd6J7/a4T2/bwAt1R1+otvuN/4tal8Ri6ED4Qnk+1AxgzNCpx3Jzjc/
LDmT1nE2pjyEeTaWMDBTHkm0m52gAwk9Vw6SX6vhej4Xu8K2CkLS/4IpIpEWpAzi
//AZPyk/Xm5AJqRgwaQrPLYvqicTvgMdcAcA8ChvW8KjsU7K82l82CkpykO/VtLv
hWEYUk+Aqzr0JU2XBHuWC9clSJn89Vl4wCHZJLc4QQ3hXbW8YTeT5tGhbQOGXNdD
LmAcvCR88rgVzK2mkrdKxeoL0f0BO1QsRUGirYG4IW+/yKHAtfXvlEgwnOsa1Wqa
IfrBmiqCDmRXFej8I5MkJ3bj1ZRdIPUudbonAptRolDrME+e9xC2d2H9oGqbLiaD
MewsPcQg4NxbsCHwtyteFci+ttUnboaK9TQFSyh1qwbD04YL3W9P2Zly5DRo3yXL
2rxDxboB2jlPrJfc2dUvSXjODPixFwoPO0Xn0w9K55VaELCHaI5GEb+ZLAyceOnY
QiDqF3RKE0hGX8nygVEcoBQj2dyGQBDKI5F3HESU86Z2M2Dl7NeemqBdoIFcaNcT
4iKUMynCRENMRIhaW0g+oOfHgdFeKswhMLejGPsgtn96GlVNGQg=
=CQws
-END PGP SIGNATURE-

___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.4.0 is available on GitHub

[Keith Winstein]

Hmm, what's the best way to push the signed tag? In the past we've done an
"a" for last-minute release issues, so we could rev to mosh-1.4.0a...

On Thu, Oct 27, 2022 at 7:47 PM Alex Chernyakhovsky 
wrote:

> I don't think we should un-push the tag. I also don't think it's worth
> rev'ing the version over the changelog? But I'd definitely rev the version
> if we think we need to include it.
>
> Sincerely,
> -Alex
>
> On Thu, Oct 27, 2022, 10:42 PM Keith Winstein 
> wrote:
>
>> Thanks Ben. I didn't realize we had pushed an unsigned tag already. I
>> guess... my tentative thought would be let's un-push the "mosh-1.4.0" tag
>> since I'd rather maintain past practice and have that be a signed tag
>> anyway. Unless you think this will cause lots of problems (but I don't
>> think it will). I don't think we need to rev the version number unless you
>> do.
>>
>> And then I think sure, please do what you think is right with the
>> ChangeLog and the debian/changelog however you prefer, and then I can tag
>> and sign that and we can cut the source tarball from there. Sorry for the
>> last-minute friction here.
>>
>> -Keith
>>
>> On Thu, Oct 27, 2022 at 7:14 PM Benjamin Barenblat 
>> wrote:
>>
>>> On Wednesday, October 26, 2022, at  8:33 PM -0700, Keith Winstein wrote:
>>> > (1) Should we update the ChangeLog file for the source release? It
>>> looks
>>> > like you (and achin?) already wrote text for it.
>>>
>>> I completely forgot about the changelog. Yes, we should update that.
>>> What do you think – should we update the changelog and push a 1.4.1 tag,
>>> or should we update the changelog and replace the existing 1.4.0 tag
>>> with a new one that includes the changelog update?
>>>
>>> > (2) Should I make the final 1.4.0 debian/changelog entry (probably
>>> > including the same bullet points as we'll put into ChangeLog) or do you
>>> > want to make a PR for that?
>>>
>>> I can take care of the Debian work. Debian generally prefers to keep
>>> upstream changelog entries out of debian/changelog – debian/changelog is
>>> supposed to be a changelog for the packaging, not the package. But I’ll
>>> make sure the Mosh changelog is included in /usr/share/doc/mosh.
>>>
>>> > (3) In the past the release announcement email named/credited the
>>> "primary
>>> > developer and release manager" -- what do you want it to say this time?
>>> > (I.e who should be credited and in what order?)
>>>
>>> For developers, it looks like cgull, Anders, Alex, and I all contributed
>>> over 100 lines of diff to Mosh since the last release. It’s an arbitrary
>>> cutoff, but it seems as good as any to me. I think cgull should probably
>>> go first on the list, since they were making active contributions until
>>> 2021.
>>>
>>> As for release manager, I think that’s Alex. He was definitely the
>>> forcing function here. :)
>>>
>>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.4.0 is available on GitHub

[Keith Winstein]

Thanks Ben. I didn't realize we had pushed an unsigned tag already. I
guess... my tentative thought would be let's un-push the "mosh-1.4.0" tag
since I'd rather maintain past practice and have that be a signed tag
anyway. Unless you think this will cause lots of problems (but I don't
think it will). I don't think we need to rev the version number unless you
do.

And then I think sure, please do what you think is right with the ChangeLog
and the debian/changelog however you prefer, and then I can tag and sign
that and we can cut the source tarball from there. Sorry for the
last-minute friction here.

-Keith

On Thu, Oct 27, 2022 at 7:14 PM Benjamin Barenblat 
wrote:

> On Wednesday, October 26, 2022, at  8:33 PM -0700, Keith Winstein wrote:
> > (1) Should we update the ChangeLog file for the source release? It looks
> > like you (and achin?) already wrote text for it.
>
> I completely forgot about the changelog. Yes, we should update that.
> What do you think – should we update the changelog and push a 1.4.1 tag,
> or should we update the changelog and replace the existing 1.4.0 tag
> with a new one that includes the changelog update?
>
> > (2) Should I make the final 1.4.0 debian/changelog entry (probably
> > including the same bullet points as we'll put into ChangeLog) or do you
> > want to make a PR for that?
>
> I can take care of the Debian work. Debian generally prefers to keep
> upstream changelog entries out of debian/changelog – debian/changelog is
> supposed to be a changelog for the packaging, not the package. But I’ll
> make sure the Mosh changelog is included in /usr/share/doc/mosh.
>
> > (3) In the past the release announcement email named/credited the
> "primary
> > developer and release manager" -- what do you want it to say this time?
> > (I.e who should be credited and in what order?)
>
> For developers, it looks like cgull, Anders, Alex, and I all contributed
> over 100 lines of diff to Mosh since the last release. It’s an arbitrary
> cutoff, but it seems as good as any to me. I think cgull should probably
> go first on the list, since they were making active contributions until
> 2021.
>
> As for release manager, I think that’s Alex. He was definitely the
> forcing function here. :)
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.4.0 is available on GitHub

[Keith Winstein]

Great, and thank you -- this is awesome!

(1) Should we update the ChangeLog file for the source release? It looks
like you (and achin?) already wrote text for it.
(2) Should I make the final 1.4.0 debian/changelog entry (probably
including the same bullet points as we'll put into ChangeLog) or do you
want to make a PR for that? I'm pretty rusty so you might be more
reliable...
(3) In the past the release announcement email named/credited the "primary
developer and release manager" -- what do you want it to say this time?
(I.e who should be credited and in what order?)

-Keith


On Wed, Oct 26, 2022 at 7:05 PM Benjamin Barenblat 
wrote:

> Hello! Alex and I just tagged Mosh 1.4.0
> . Please
> feel free to sign the release artifacts and publish them to the mailing
> list at your leisure. Thanks for letting us help with this!
>
> Benjamin
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Termius + Mosh

[Keith Winstein]

Hello Roman,

In 2017 in this thread, we requested, and you agreed, that your company
would stop using "Mosh" to refer to Termius, and use a phrase like
"Mosh-compatible" if you want to explain its ability to interoperate with
mosh-server. (You have told us that Termius is a clean-room implementation
unrelated to the Mosh codebase.) Despite this, you are still using "Mosh"
in your marketing (https://www.termius.com/) and perhaps in your product.

This is continuing to confuse your users, resulting in a continuing support
burden on us.

Stop using "Mosh." It is a registered trademark referring to our software.
Please let us know when this is done.

-Keith

On Wed, Aug 30, 2017 at 6:12 PM Roman Kudiyarov  wrote:

> Hi Keith,
>
>
>
> On 9 August 2017 at 11:51:44 AM, Keith Winstein (kei...@cs.stanford.edu)
> wrote:
>
> Roman,
>
> In early May, we had this exchange (also below in this thread). I wrote:
>
> (3) We've had bad experiences in the past with people (especially iSSH on
>> iOS) attempting to implement the Mosh protocol, but with imperfect results,
>> and users blaming Mosh for the problems. As with these past cases, please
>> don't refer to your implementation as "Mosh." Please refer to it as
>> "Termius mosh-compatible mode," with your own name first and
>> "mosh-compatible" instead of "Mosh".
>
>
> You replied:
>
> Sure, no problem. We will make sure that it’s mentioned as
>> "mosh-compatible”.
>
>
> We expect your company to honor this agreement -- do you plan to do so?
>
>
>
> I'm happy to explain our position further, and maybe you can understand
> why this is important to us. Mosh is a piece of software, like OpenSSH or
> Chrome. The protocol is called SSP (State Synchronization Protocol). You
> have told us that your program is not derived from Mosh, so we really don't
> want your company to call it Mosh. It's nothing personal -- but users are
> better served knowing the difference. We had a bad experience with somebody
> writing what they thought was a compatible implementation, and users
> getting confused and blaming us. So we don't want users to think they are
> running Mosh when they are running somebody else's application.
>
> We would be fine with you making statements like, "Termius is
> mosh-compatible" or "Termius has a mosh-compatible client" or even "Termius
> works with Mosh servers." They key thing here is that it's fine for Termius
> to claim mosh-compatibility, or to work *with* Mosh servers. It shouldn't
> claim to *be* or to include Mosh, because it doesn't.
>
> Yes, the text "SSH, Telnet, and Mosh in your pocket" and "... with SSH,
> Telnet, and Mosh." appears on your current website, https://termius.com.
> You can visit it yourself to see.
>
> Thanks for your answer. I see your point.Please don’t worry about the
> support as we doing it ourselves. We have Mosh integrated into iOS and
> Android with around 500,000 users combined. At the moment we can see quite
> a big adoption of Mosh and some user requests in our Helpdesk system. At
> the same time I can see none of those in this mailing list.
>
> I believe that the idea/concept of Mosh is much bigger than it’s first
> implementation under the GPL license. The GPL license makes it’s hard to
> use in commercial apps so there will be more alternative and/or
> closed-sourced implementations of the protocol which most of the users call
> Mosh(not SSP).
>
> One of the solutions I can see is to name the current implementation Open
> Mosh and keep the name mosh for the protocol.
>
> Another topic that I would like to raise is the protocol collaboration so
> Termius can keep up with the new versions of the Mosh server and release
> updates together with other platforms. That would definitely benefits the
> users.
>
>
>
> -Keith
>
> On Mon, Aug 7, 2017 at 5:20 PM, Roman Kudiyarov  wrote:
>
>> Hi Keith,
>>
>> Could you please point me where “Mosh in your pocket” is. Honestly I
>> can’t find it. Btw, we’ve recently updated both of our websites so you
>> might refer to the old version.
>>
>> In terms of the naming, there are two entities called MOSH:
>> 1. *Mosh protocol*. Termius is keen to participate in the discussion of
>> the protocol development. We have some thoughts on improving UX, e.g live
>> sessions for quick switch between devices.
>> 2. *Server and client implementation* of the protocol which is available
>> on GitHub.
>>
>> In general, I find mosh-compatible pretty long and a little bit confusing
>> as it’s just a

Re: [mosh-devel] Introduction: Wolfgang E. Sanyer

[Keith Winstein]

On Thu, Jan 27, 2022 at 3:49 AM Wolfgang E. Sanyer <
wolfgangesan...@gmail.com> wrote:

> Keith,
>
> Thanks for the welcome, and thanks for your detailed and thoughtful
> response!
>
> I'm very thankful for the outline you've put together, as it gives me a
> clear strategy for what needs to be done to move forward.
>

Awesome. And (I should have said this before), but I'd be happy to put a
regular videochat on the calendar if that would be helpful to you and
Alex/Ben/Quentin in keeping track of blockers and giving advice. That's not
normally how we do things in FLOSS and maybe it's not necessary here, but
if 30 minutes synchronous every week or two would be helpful, I'd be happy
to commit to that.


> To answer your question "Are you interested inor...any other part of
> this process", my answer is "yes I'm interested in all of it".
>
> Let me summarize your email just to be sure I'm not missing anything:
>
> - Document the release process
> - this includes starting with a release candidate to allow for broader
> testing
> - "look over"/"scrutinize" any commits since the last release
> - I could use some clarity here: are you suggesting that I perform
> this in isolation? Or use some github feature to perform a more formal code
> review?
>

I think I would like you and Alex to tell me (and the rest of the
community), "Yes, we've looked over the recent commits, it looks good to
us, we don't see any buffer overflows, and [most importantly] we understand
them well enough to say that we're going to stick around and be here to fix
what needs fixing if the shit hits the fan after the release happens."

What I didn't want to do was step back in after years away and cut a
release lazily that has a bunch of cgull commits that I didn't review,
don't understand, and hadn't put the effort into scrutinizing -- that
seemed like a recipe for how we'd get our first real security hole.


> - Ensure oss-fuzz is _actually_ running against mosh
> - add fuzz targets as needed to cover commits since latest release
>
> Thanks again!
>
> Wolfgang E. Sanyer
>

Looks good to me. I'd love if you kept mosh-devel cc:ed on the conversation
between you and Alex/Ben/Quentin, but I will leave it to you to work out a
process with them for how you'd all like to get this done. (And if you want
me involved for an occasional call, let me know.) Welcome again!

Sincerely,
Keith


> El jue, 27 ene 2022 a la(s) 03:09, Keith Winstein (kei...@mit.edu)
> escribió:
>
>> Hello Wolfgang,
>>
>> Welcome, and thanks for writing! We're happy to have you involved. Let me
>> loop in Alex (our RPM package maintainer) who is willing to help get this
>> off the ground, as well as Quentin Smith (one of the Mosh authors) and Ben
>> Barenblat, who are also interested in helping make this happen. I know
>> Anders and Andrew (the other currently active stewards) would also support
>> this, and may want to contribute time to a release as well.
>>
>> I think one good goal would be to document the release process, which
>> should be gleaned pretty easily from what we've done in the past: put out
>> an "rc" (release candidate) release (with some care with the "~" to make
>> sure we don't accidentally clobber our Debian/Ubuntu versioning order) and
>> call for the community to test it rigorously.
>>
>> Since we've lost our previous maintainer, and because he had made some
>> commits after the last release, we're also starting from a bit of a deficit
>> here. Before we cut a release, I'd be most comfortable if we:
>>
>> (1) look over the commits that have been made since the previous release
>> pretty carefully. I would be unhappy if perhaps one of the commits that
>> introduced truecolor support introduced (e.g.) a buffer overflow
>> vulnerability in the terminal emulator. Not saying I think this has
>> happened, but given the transition in personnel, these commits deserve some
>> scrutiny.
>>
>> (2) wrote some fuzz targets, both pre- and post-decryption, and submitted
>> them to the oss-fuzz repo (
>> https://github.com/google/oss-fuzz/tree/master/projects/mosh), and made
>> sure that some fuzzing actually happened. We've been on oss-fuzz itself for
>> over five years but nobody has written fuzz targets for Mosh, so I don't
>> think any actual fuzzing has happened.
>>
>> Are you interested in helping write fuzz targets, or with any other part
>> of this process? I am happy (honestly, I'd prefer) to stay pretty hands-off
>> here -- I&#x

Re: [mosh-devel] Introduction: Wolfgang E. Sanyer

[Keith Winstein]

Hello Wolfgang,

Welcome, and thanks for writing! We're happy to have you involved. Let me
loop in Alex (our RPM package maintainer) who is willing to help get this
off the ground, as well as Quentin Smith (one of the Mosh authors) and Ben
Barenblat, who are also interested in helping make this happen. I know
Anders and Andrew (the other currently active stewards) would also support
this, and may want to contribute time to a release as well.

I think one good goal would be to document the release process, which
should be gleaned pretty easily from what we've done in the past: put out
an "rc" (release candidate) release (with some care with the "~" to make
sure we don't accidentally clobber our Debian/Ubuntu versioning order) and
call for the community to test it rigorously.

Since we've lost our previous maintainer, and because he had made some
commits after the last release, we're also starting from a bit of a deficit
here. Before we cut a release, I'd be most comfortable if we:

(1) look over the commits that have been made since the previous release
pretty carefully. I would be unhappy if perhaps one of the commits that
introduced truecolor support introduced (e.g.) a buffer overflow
vulnerability in the terminal emulator. Not saying I think this has
happened, but given the transition in personnel, these commits deserve some
scrutiny.

(2) wrote some fuzz targets, both pre- and post-decryption, and submitted
them to the oss-fuzz repo (
https://github.com/google/oss-fuzz/tree/master/projects/mosh), and made
sure that some fuzzing actually happened. We've been on oss-fuzz itself for
over five years but nobody has written fuzz targets for Mosh, so I don't
think any actual fuzzing has happened.

Are you interested in helping write fuzz targets, or with any other part of
this process? I am happy (honestly, I'd prefer) to stay pretty hands-off
here -- I'm sorry we lost our previous maintainer and hadn't planned on
returning to active duty. Alex, Ben, and Quentin have been around the block
here and have also been involved in Mosh basically since the beginning, and
are happy to mentor you in this. Please let me (and them) know your
interest.

Sincerely,
Keith

On Wed, Jan 26, 2022 at 7:05 AM Wolfgang E. Sanyer <
wolfgangesan...@gmail.com> wrote:

> Hello mosh development community!
>
> My name is Wolfgang E. Sanyer. I am a long-time programmer/open-source
> contributor, and a recent (very recent, just started Jan 10th) professional
> software engineer. If you'd like to take a look at some of my work, my
> github is https://github.com/ezzieyguywuf
>
> I am very interested in contributing to the development of mosh:
> specifically, I would like to help do the work necessary to cut a new
> release. From what I can see, the last release was v1.3.2 in July 2017.
> Since then, there have been a number of commits, most interesting to me
> being 6cfa4ae which adds true color support.
>
> While I do not have a lot of experience with the "Release Engineering"
> work necessary to do this successfully, I am very motivated to get this
> done as it will greatly improve my daily workflow. Also, I feel confident
> that given the appropriate learning resources, I can get up-to-speed on
> what is needed to successfully release a new version of mosh.
>
> Please let me know your thoughts on:
>
> 1) the general thoughts around cutting a new release (there seems to be
> some discussion against doing so)
> 2) any next steps needed to move forward with cutting a new release
>
> Thank You!
>
> Wolfgang E. Sanyer
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> https://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Including Mosh in our Software

[Keith Winstein]

Nobody has an exemption. My understanding was that JuiceSSH distributes a
mosh-client executable and just invokes it.

On Tue, Jan 4, 2022 at 6:24 AM Alan Kim  wrote:

> Hi Keith,
>
> Thank you for the information.
>
> According to GPL licensing, all code linked with GPL source code must be
> disclosed under a GPL compatible license.
> However, several software products which are similar to ours all have Mosh
> included, but do not seem to follow this rule. (Mobaxterm, Termius,
> JuiceSSH to name a few). Do they have some kind of special exemption?
>
> I'd appreciate any advice you can provide. Thank you!
>
> Regards,
>
> *Alan Kim *| NetSarang, Inc. | Director of Sales & Marketing
> 4701 Patrick Henry Dr. BLDG 22 Suite 137, Santa Clara, CA 95054, U.S.A.
>
> Tel: (669) 204-3301 | Email: a...@netsarang.com | Website:
> www.netsarang.com
>
>
> *FACEBOOK: *http://facebook.com/netsarang
> <https://tracking.cirrusinsight.com/25b7bb93-8a74-4813-a129-bd31a9e05784/facebook-com-netsarang>
>  | *TWITTER**: *http://twitter.com/netsarang
> <https://tracking.cirrusinsight.com/25b7bb93-8a74-4813-a129-bd31a9e05784/twitter-com-netsarang>
>
>
>
> On Wed, Dec 15, 2021 at 11:35 PM Keith Winstein  wrote:
>
>> Hello,
>>
>> Thank you for your inquiry. Mosh is free software, licensed under the GNU
>> GPL. The requirements would be similar to those of Linux, Git, GCC, Emacs,
>> OpenJDK, Blender, GIMP, VLC, Wordpress, etc. You are welcome to
>> redistribute Mosh under the terms of the license -- you may want to consult
>> your own counsel if uncertain about the GPL's requirements. (Please note
>> that Mosh is a registered trademark referring to the Mosh software.)
>>
>> Best regards,
>> Keith
>>
>> On Wed, Dec 15, 2021 at 7:50 AM Alan Kim  wrote:
>>
>>> Hello,
>>>
>>> My name is Alan Kim and I am the Director of Sales & Marketing at
>>> NetSarang.
>>> We are developing a new piece of software called PortX. You can see more
>>> here: https://portx.online/
>>>
>>> We'd like to include Mosh into PortX, but want to make sure we go about
>>> it correctly licensing wise.
>>> Are we able to incorporate Mosh into our commercial software? If so, are
>>> we required to purchase a license?
>>>
>>> If this is not the right contact for this type of question, can you
>>> point me in the right direction?
>>> Look forward to hearing from you. Thank you!
>>>
>>> Regards,
>>>
>>> *Alan Kim *| NetSarang, Inc. | Director of Sales & Marketing
>>> 4701 Patrick Henry Dr. BLDG 22 Suite 137, Santa Clara, CA 95054, U.S.A.
>>>
>>> Tel: (669) 204-3301 | Email: a...@netsarang.com | Website:
>>> www.netsarang.com
>>>
>>>
>>> *FACEBOOK: *http://facebook.com/netsarang
>>> <https://tracking.cirrusinsight.com/25b7bb93-8a74-4813-a129-bd31a9e05784/facebook-com-netsarang>
>>>  | *TWITTER**: *http://twitter.com/netsarang
>>> <https://tracking.cirrusinsight.com/25b7bb93-8a74-4813-a129-bd31a9e05784/twitter-com-netsarang>
>>>
>>> ___
>>> mosh-devel mailing list
>>> mosh-devel@mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/mosh-devel
>>>
>>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Including Mosh in our Software

[Keith Winstein]

Hello,

Thank you for your inquiry. Mosh is free software, licensed under the GNU
GPL. The requirements would be similar to those of Linux, Git, GCC, Emacs,
OpenJDK, Blender, GIMP, VLC, Wordpress, etc. You are welcome to
redistribute Mosh under the terms of the license -- you may want to consult
your own counsel if uncertain about the GPL's requirements. (Please note
that Mosh is a registered trademark referring to the Mosh software.)

Best regards,
Keith

On Wed, Dec 15, 2021 at 7:50 AM Alan Kim  wrote:

> Hello,
>
> My name is Alan Kim and I am the Director of Sales & Marketing at
> NetSarang.
> We are developing a new piece of software called PortX. You can see more
> here: https://portx.online/
>
> We'd like to include Mosh into PortX, but want to make sure we go about it
> correctly licensing wise.
> Are we able to incorporate Mosh into our commercial software? If so, are
> we required to purchase a license?
>
> If this is not the right contact for this type of question, can you point
> me in the right direction?
> Look forward to hearing from you. Thank you!
>
> Regards,
>
> *Alan Kim *| NetSarang, Inc. | Director of Sales & Marketing
> 4701 Patrick Henry Dr. BLDG 22 Suite 137, Santa Clara, CA 95054, U.S.A.
>
> Tel: (669) 204-3301 | Email: a...@netsarang.com | Website:
> www.netsarang.com
>
>
> *FACEBOOK: *http://facebook.com/netsarang
> 
>  | *TWITTER**: *http://twitter.com/netsarang
> 
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> https://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
https://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Defunct?

[Keith Winstein]

Hi -- I am the original creator of Mosh and use it every day. I don't think
the project is defunct -- we are very proud of our essentially perfect
decade-long track record on security and feel like that record gets longer
every day as hundreds of thousands of people, or maybe millions, continue
to use it.

It's true that the GitHub issue tracker is clogged with feature requests
(some of which would involve protocol design work and a decision to support
something long-term) and support requests. That is sort of an annoying
thing about GitHub... It's also true that our maintainer committed code and
then became inactive; for security reasons, I don't want to just jump in
and release what we have without really taking the time to re-assume the
role of active maintainer and re-understand where we are, and it hasn't
seemed like there is a compelling need for that to happen. A rushed release
by somebody no-longer-familiar with the codebase *is* exactly the way we
would screw up our security story.

Re: Oracle Linux, this sounds like a packaging question. We have a package
for Fedora and EPEL but have never had an package maintainer for Oracle
Linux. If you would like to take over this role, we'd be happy to work with
you, but your relationship would need to be mostly with Oracle, not us. Or
if your complaint is about the EPEL package and you think that should work,
please work with the EPEL package maintainer.

You can see a longer note I wrote on this topic here:
https://news.ycombinator.com/item?id=28151637

On Sat, Oct 2, 2021 at 7:48 AM Byron Hawkins 
wrote:

> Hi, it looks like mosh is no longer maintained. For example, it doesn't
> work on Oracle Linux anymore. Bugs in the tracker on github are ignored for
> years. Can you at least recommend an alternative with similar functionality
> and an active project maintainer? Thanks.
>
> Byron
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh bug without UTF-8

[Keith Winstein]

Hello,

Thanks for your email. As I wrote when you came on the IRC channel, we
don't think this behavior is a bug. The reason Mosh requires a UTF-8 native
locale has to do with terminal emulation. ANSI-style terminals operate on
an underlying state machine (https://vt100.net/emu/dec_ansi_parser).
Historically, the underlying symbols to the state machine can be 7-bit
ASCII or 8-bit octets (as was common in the case of physical terminals like
the vt220), or they can be Unicode scalar values, aka "USVs."

The underlying symbol type (especially the question of octet vs. USVs)
affects the lowest layer of the terminal emulator. For example, the C1
controls have the values 0x80..0x9f (per ISO/IEC 6429 and ECMA-48 as well
as ISO/IEC 10646), and then each one has a corresponding 7-bit
compatibility encoding. So, for example, the C1 control CSI has the value
0x9b, with a 7-bit encoding as <0x1b, 0x5b>.

On an 8-bit terminal (e.g. xterm when invoked in a "C" locale), you can run
this command to get a green "Hello": echo -e "\x9b32m Hello \x9bm"

But the same command just produces mojibake on a UTF-8 terminal emulator,
because the terminal emulator is *first* parsing the incoming bytes (as
UTF-8) into USVs and only then looking at their values; it never enters the
csi_entry state in the state transition diagram. The fact that Unicode
terminal emulators would work this way was made around 2003 or earlier; we
could argue about whether they made a wise choice back then, but this has
been the reality for almost 20 years (
https://www.cl.cam.ac.uk/~mgk25/unicode.html#term).

To get the same results on a UTF-8 terminal emulator, you could pipe that
command through a charset conversion, e.g.: echo -e "\x9b32m Hello \x9bm" |
iconv -f LATIN1 -t UTF8

or, equivalently:  echo -e "\xc2\x9b32m Hello \xc2\x9bm"

or, using the 7-bit encoding (which works everywhere because 7-bit ASCII
has the same encoding in UTF-8): echo -e "\x1b\x5b32m Hello \x1b\x5bm"

Anyway, these kinds of issues can lead to a lot of subtle bugs and
glitches, especially when connecting across incompatible systems, e.g. when
applications think they can send 8-bit (both for controls and printable
characters!) but the terminal emulator at the other side is interpreting it
as UTF-8 or vice versa. You say that ssh/telnet/rlogin/rsh don't have a
problem, but of course these programs aren't terminal emulators, and they
do *allow* charset incompabilities to exist and to flow through them, and
an ssh/telnet user can absolutely see glitches when using an 8-bit
application with a UTF-8 terminal emulator or vice versa. Programs like
screen and tmux (which Mosh is maybe more similar to when it comes to this
kind of thing) also have to worry about these problems.

Ten years ago, I decided that to keep my sanity, Mosh would only emulate
ONE kind of terminal emulator (and the one I picked was the kind whose
underlying symbols are USVs, parsed out of the incoming bytestream by
interpreting it as UTF-8). In practice, getting access to UTF-8 parsing
from libc requires being in a UTF-8 locale (and obviously you do also want
applications to be in the same charset). I used to feel, like you do, that
UTF-8 in Unix was needless complexity, but that was like 20 years ago --
I'm sorry to tell you the world moved on and that battle was lost by like
2005. Contrary to your message, UTF-8 locales and terminal emulators have
been the default for new Unix-like installations for roughly 15+ years (I
think it's the default on installation, and was around then, for most Linux
distributions, most flavors of BSD, MacOS, WSL, etc., and probably most
other things). We wanted to pick one horse, and essentially we made the
choice a decade ago that we'd rather enforce the expected preconditions
before letting Mosh start up, instead of allowing the user to run Mosh in a
situation where we'd have to support bug reports about subtle hard-to-debug
issues, knowing that people like you would complain (as many predecessors
have!) in the support forums.

To tell you the truth, I haven't even thought about this stuff for a long
time -- we made these choices like a decade ago, they have been good enough
for some millions of users, and obviously Mosh isn't for everybody. I had
to go back and refresh my memory even to write this email. But I think
we're pretty happy with the choice we made ("pedantic correctness") at
least in this aspect; the spirit is maybe similar to
https://www.jwz.org/gruntle/autobogotification.html , and you can see some
of that on the Mosh website as well where we quote the USENIX peer
reviewers; see also https://github.com/mobile-shell/mosh/issues/1112.
Compared with a lot of contemporary issues in computing, at least this one
sort of feels like you can get your head around it...

Best regards,
Keith

On Tue, Sep 7, 2021 at 6:55 AM Thomas Nachname <
onlywebmail.2...@googlemail.com> wrote:

> Hello, together
> Is the any chance, that you will fix this bug with the error message
> "mosh-clien

Re: [mosh-devel] Getting mosh on Android

[Keith Winstein]

Thanks! Would you mind sending us a pull request to the moshweb repo?

Best regards,
Keith

On Wed, Apr 7, 2021 at 1:27 PM Mark Urban  wrote:

> Hi,
>
> Just wanted to suggest that you should consider updating the "Getting
> Mosh" section of your web site. Termux is no longer being updated on the
> Play Store. The best way to get it now is through F-Droid. But the Mosh web
> site doesn't even mention F-Droid at all right now, much less the fact that
> it's the best way to get up to date versions of Termux.
>
> Thanks,
>
> Mark
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy

[Keith Winstein]

Thank you for looping us in -- my understanding is that "Mobile SSH" refers
to a freeware Android app based on OpenSSH (
https://play.google.com/store/apps/details?id=mobileSSH.feng.gao) and the
PuTTY terminal emulator. It's unrelated to Mosh (mobile shell).

Mosh doesn't implement any public-key cryptography.

Best regards all,
Keith

On Wed, Feb 10, 2021 at 9:55 PM Mark D. Baushke  wrote:

> [To+ Ron, Alexandre, mosh-devel, Simon] question on rsa2048-sha256 KeX for
> SSH
>
> Summary:
>
> Is anyone actively using rsa2048-sha256 for a Ssecure Shell Key
> exchange per RFC 4432.
>
> The Security Area Director Benjamin Kaduk has concerns regarding
> this Key Exchange Algorithm (see messagess below).
>
> The IETF Draft
>
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
> is presently in Last Call.
>
> This draft is in the process of suggesting "MUST NOT" for
> rsa1024-sha1.
>
> The question on the table is if the same rating should be appled to
> rsa2048-sha256 or if RFC 4432 should itself be moved to historical,
> or if this is still a useful key exchange being actively used.
>
> Ben desires data and it is my suggestion that the supporters for the
> implementations that provide for rsa2048-sha256 may information on
> this topic.
>
> Comments welcome.
>
> Hi Ben & Peter,
>
> To Peter's question, my straw poll was explicitly about the *-sha1 Key
> Exchanges which did not include the rsa2048-sha256 kex.
>
> If I go to https://ssh-comparison.quendi.de/comparison/kex.html
>
> I see that rsa2048-sha256 is supported by the following implementations:
>
>AsyncSSH   (maintained by Ron Frederick)
>libassh(maintained by Alexandre Becoulet)
>Mobile SSH (aka Mosh via mosh.org and )
>   (original paper authors
>Keith Winstein ,
>Hari Balakrishnan )
>PuTTY  (maintained by Simon Tatham)
>
> There may be other implementations that are not in the comparison chart,
> but I think this may be a good start.
>
> I have added both Ron, Alexandre, mosh-devel@mit.edu, and Simon to the
> TO line for this message.
>
> Thank you for your participation in this thread.
>
> Be safe, stay healthy,
> -- Mark
>
>  --- original messages ---
>
> Date: Wed, 10 Feb 2021 20:25:51 -0800
> From: Benjamin Kaduk 
> To: cur...@ietf.org
> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s>
> Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy
>
> While reviewing draft-ietf-curdle-ssh-kex-sha2, I followed many of the
> references, which included RFC 4432, which defines the "rsa1024-sha1"
> (getting deprecated for SHA-1 usage) and "rsa2048-sha256" (which is not)
> key exchange methods.  While the specific construction is claimed to still
> produce contributory behavior in practice (due to the client-contributed
> key only ever being used in combination with the hash of server-provided
> data), it seems to still be the case that if the RSA private key is
> revealed, the session key is revealed, which is mostly the standard
> non-forward-secret behavior.
>
> Things are perhaps better if you buy into the theory that "it may be a
> transient key generated solely for this SSH connection, or it may be
> re-used for several connections" is supposed to prevent indefinite reuse of
> the RSA keypair, which seems ... not very reassuring.
>
> While it's not clear to me that there's specific reason to (say) move the
> whole RFC to Historic status or claim that it is obsoleted by some
> more-modern key-exchange method, it does seem likely to me that we could
> get IETF consensus that actually using rsa2048-sha256 is generally a bad
> idea.  (Or maybe we could get consensus to move it to Historic.)  Perhaps
> an RFC 2026 Applicability Statement would be an appropriate tool for this
> case?
>
> But most likely the best place to start would be to ask how widely it's
> implemented and if it's known to be in use anywhere...does anyone have
> data?
>
> Thanks,
>
> Ben
>
> ___
> Curdle mailing list
> cur...@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>  --- message 2 ---
>
> From: Peter Gutmann 
> To: Benjamin Kaduk , "cur...@ietf.org" 
> Date: Thu, 11 Feb 2021 04:47:07 +
> Archived-At: <
> https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0>
> Subject: Re: [C

Re: [mosh-devel] mosh continuous fuzzing improvement suggestion

[Keith Winstein]

Hello Yevgeny,

Thanks for getting in touch. We were included in the oss-fuzz repository,
but I'm not sure anybody ever actually did the work of integrating Mosh or
fuzzing it. (People have separately fuzzed the terminal emulator and found
some overcautious assertions that we ended up removing; see
https://github.com/mobile-shell/mosh/issues/667 ). We certainly never heard
anything from them -- if we were supposed to do something on our end beyond
submitting the initial pull request to be included, we didn't do it.

If you want to fuzz Mosh, we'd love to help you. I think you probably want
to fuzz Mosh at several different layers, e.g.:

- raw datagram input
- network input after removing encryption and validation of the integrity
check
- network input after removing encryption, integrity validation, and
compression
- network input to the terminal emulator (e.g. arbitrary actions on the
CompleteTerminal object)
- user keyboard input

Best regards,
Keith



On Sun, Jun 23, 2019 at 8:16 PM Yevgeny Pats  wrote:

> Hi Keith,
>
> I'm Yevgeny Pats, founder of Fuzzit  - a continuous
> fuzzing as a service platform.
>
> We are providing free continuous fuzzing + PR sanity tests to OSS
> projects. I know you are using OSS-fuzz so I wanted to know what the
> current status of the integration and if you need additional resources or
> features.
>
> I'll be happy to help create an integration with Fuzzit. We provide
> continuous fuzzing for projects like systemd, radare, apache.
>
> You can read about systemd-fuzzit case study here
>  where
> they use our platform in addition to OSS-fuzz.
>
> Also, will be happy to discuss fuzzing in general and share ideas.
>
> Looking forward to hearing from you,
>
> Yevgeny Pats,
> Founder & CEO, Fuzzit
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] libutempter debugging

[Keith Winstein]

Hello Adrian,

Mosh's use of utempter is pretty orthodox -- we call utempter_add_record()
and utempter_remove_record() in mosh-server.cc and that's about it. You can
see all the calls here:
https://github.com/mobile-shell/mosh/blob/master/src/frontend/mosh-server.cc

You might try writing a very simple .c program (separate from Mosh) that
links with utempter and tries to utempter_add_record(), and see if the
entry gets created. That will help narrow down if the problem is with Mosh
or with utempter.

One thing to note is that the utempter helper executable
(e.g. /usr/lib/x86_64-linux-gnu/utempter/utempter) is typically installed
setgid "utmp", and then /var/run/utmp is owned by group "utmp" and is g+w.
That's how libutempter can modify utmp -- by invoking the helper
executable, which has permission to write to /var/run/utmp because of the
setgid bit. If you installed utempter yourself, you might make sure the
helper executable has permission to write to utmp.

Best regards,
Keith

On Fri, Jan 18, 2019 at 2:57 AM Adrian Carpenter 
wrote:

> Hi,
>
> I am currently working on getting the detached session notification
> working on a port of Mosh to the Synology NAS platform.
>
> I have built mosh with libutempter 1.1.6, it’s being linked in and being
> used.  However, I do not get the message about detached sessions.
>
> If I dump the the /var/run/utmp I can see that the mosh entries were not
> created, so I’m going to have to do some debugging.
>
> How would I go about debugging the mosh-server binary so that I can step
> through and see what is happening?  I’m not a unix developer by trade, so
> am not sure how I would achieve this given the client-server nature of mosh.
>
> Any ideas/tips/suggestions would be gratefully accepted.
>
> Many thanks
>
> Adrian
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Is there a way to tell if you are running inside mosh?

[Keith Winstein]

Hello -- I think the main issue here is that you are using ISO 2022 shift
sequences to switch to the "alternate character set" to draw those lines on
the screen. Mosh follows the practice of some (but not most) UTF-8 (ISO
10646) ANSI terminal emulators in refusing to interpret the "locking
shifts" of the older ISO 2022 standard. Hence all those "q"s on the screen.

Your options are probably:

a) Change your shell configuration to send real Unicode (UTF-8) characters
instead of switching into an alternate character set via ISO 2022
b) Use a program like "screen", "tmux", or "luit" to translate between ISO
2022 (input) and UTF-8 (output) for Mosh.
c) Detect if you are running inside a mosh-server with a command like
`pstree -plus $$ | grep mosh-server`

Would have happily answered this over IRC as well!

Best regards,
Keith

On Thu, Nov 15, 2018 at 7:47 AM TJ Luoma  wrote:

> > What's the value of TERM outside, without running ssh?
>
> same, "xterm-256color"
>
> TjL
>
> --
> TJ Luoma
> TJ @ MacStories
> Personal Website: luo.ma (aka RhymesWithDiploma.com)
> Twitter: @tjluoma
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh-based infrastructure for remote management of remote devices

[Keith Winstein]

Hello -- thanks for your kind words! It is probably possible to adapt
mosh-server to do what you propose here (basically allowing the server to
roam instead of the client), but we have not done this or shipped it. I
think most people probably do just use an auto-roaming VPN (e.g. OpenVPN or
probably Wireguard) and then run Mosh on top of that.

If you want to dig in, look at mosh-server.cc and
mosh-client.cc/stmclient.cc and flip around which one runs the "server"
side of the network connection...

Best regards,
Keith

On Thu, Nov 1, 2018 at 7:10 AM Christophe Mietlicki <
christophe.mietli...@bruitparif.fr> wrote:

> Hi to all
>
>
>
> Discovered mosh today (better now than never…) and very impressed ! Sure I
> will love it, as I’m sure also that internet would have been better if
> built over UDP than TCP ;-)
>
>
>
> I have a question for you…
>
>
>
> I deploy many devices (raspberry pi family) that are connected to the
> internet through cellular. I want to be able to manage them from anywhere
> in the world, even a PC connected to the internet over cellular.
>
>
>
> In that kind of situation, we often put in place some kind of vpn
> infrastructure which I don’t like so much…
>
>
>
> I wonder what must be added to mosh to make that work…
>
>
>
> I imagine that a mosh client session is opened from a PC anywhere
> (roaming) to a company’s UDP tunnel server, that can initiate a client
> session to the mosh server that runs on the device. But it is not so easy
> because I want to use standard cellular sim cards with non public IP and no
> opened port).
>
>
>
> Did you already built such network infrastuctures ? Do you have some
> advices to add mosh what’s missing to do the job ?
>
> Best regards
>
>
>
> *Christophe Mietlicki*
>
> Responsable Technologies et Systèmes d’information
>
>
>
> *[image: LOGO BRUITPARIF IDF pour signatures email]*
>
>
>
> Axe Pleyel 4 – B104
>
> 32 boulevard Ornano
>
> 93200 Saint-Denis
>
> Tél : +33 1 83 65 40 49 (poste direct)
>
> Tél : +33 1 83 65 40 40 (standard)
>
> Portable : +33 6 75 68 32 35
>
> Site internet : www.bruitparif.fr
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh on Kuberbnetes

[Keith Winstein]

I don't think Jim's message was quite a response to my earlier one -- if
you do use a proxy/NAT as I described, you do not need to use a bastion
host and you don't need the proxy to be aware of the internals of the SSP
protocol, or worry about keys, or decrypt anything. It can be pretty
oblivious to the inner workings of Mosh. It does have to rewrite the IP
addresses and UDP port numbers in each direction and it has to alter the
"MOSH CONNECT" message at the start.

-Keith

On Wed, Jul 18, 2018 at 9:19 PM, Thomas Buckley-Houston 
wrote:

> Thanks Jim,
>
> That really clears things up for me.
>
> So but you're saying that Keith's idea of having the outgoing
> datagram's source IP remapped is not possible?
>
> I totally agree about the traditional approach of the "bastion host",
> it's basically like having SSH act as the "load balancer" - as I'll
> have some shell script open up a connection to a random server on the
> bastion's CLI. The only problem there is that it doesn't take
> advantage of traditional cluster architecture so well. For instance
> I'll need to come up with a custom method of keeping a live list of
> the available internal IP addresses to which I can forward the
> session. Any idea how many connections an average 512MB VM could
> handle like this? I suspect so many that you'd only ever need one VM?
>
> Tom
>
> On 13 July 2018 at 12:54, Jim Cheetham  wrote:
> > Excerpts from Thomas Buckley-Houston's message of July 13, 2018 3:58 pm:
> >> So
> >> because UDP is a connectionless protocol, every datagram has to
> >> contain the source IP in order for the receiver to send responses?
> >
> > Every packet does have the source IP address in it, but not because it's
> a UDP packet, it's because that's what all *IP* packets have. UDP is a
> protocol built on top of IP, as is TCP - we're used to the "full name" of
> TCP being TCP/IP, but it's unusual to say "UDP/IP" :-)
> >
> >> It's not enough for either end to assume an IP based on the *initial*
> >> datagram's IP?
> >
> > Because UDP is connectionless, there's no concept of an initial packet
> in the first place; all packets that arrive are completely self-contained
> entities with no relation to any other packets that might arrive before or
> after. It's a bit like HTTP in that respect.
> >
> > The *application* that's using UDP may have a concept of a long-term
> session that involved multiple packets, but UDP itself doesn't. Again
> looking at HTTP, that's like using cookies to describe a session.
> >
> >> So based on that assumption, the best way for a
> >> datagram to get its IP:port is to query the OS. Which in our scenario
> >> is a privately networked container and so will be unreachable from the
> >> outside.
> >
> > You have a middle layer load balancer, which will be keeping track of
> the state of sessions going through; this is easy for TCP because the
> session identifiers are basically in every packet. However, in UDP they are
> not present at all - you have to be aware of the actual application using
> UDP; you have to be explicitly aware of mosh itself in order to be able to
> load-balance/proxy it correctly.
> >
> > A simple assumption for most protocols that want to have cheap
> lightweight sessions is to assume that the source IP address stays the same
> throughout. This happens to have been true for most of the network's
> history, but has never been guaranteed.
> >
> > In the case of mosh, this is explicitly not true; the protocol *expects*
> that the source IP address will change unannounced throughout the
> application's session.
> >
> > It is this issue that you need to be looking in to. You need a proxy/LB
> layer that looks at a UDP packet coming through, recognises that it is
> using SSP (State Synchronization Protocol), and keeps track of which
> backend system the packet should be forwarded to.
> >
> > Unfortunately, this will be very difficult; datagrams are encrypted, and
> your proxy will not be aware of the key in use. The only way I can see to
> make this happen will be to alter the mosh server to inform the proxy
> directly, and that's a lot of engineering that will introduce a number of
> security tradeoffs that might not be worthwhile.
> >
> > Overall, your better approach is to have a traditional "bastion host" in
> the middle, use mosh to connect to that, and from there make inbound ssh
> connections to your service hosts (because you can get away with ssh on an
> internal "reliable" network, and because you're using TCP for this, you can
> go through a load balancer if required).
> >
> > -jim
> >
> > --
> > Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
> > ✉ jim.cheet...@otago.ac.nz☏ +64 3 470 4670☏ m +64 21 279 4670
> > ⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
__

Re: [mosh-devel] Mosh on Kuberbnetes

[Keith Winstein]

Hello Thomas,

On Thu, Jul 12, 2018 at 8:58 PM, Thomas Buckley-Houston 
wrote:

> Forgive me for not fully learning about UDP, I've Googled a little
> bit, but I'm sure I still have a lot of gaps in my knowledge. So
> because UDP is a connectionless protocol, every datagram has to
> contain the source IP in order for the receiver to send responses?
>

IP is a connectionless protocol, and every IP datagram contains a source
and destination IP address in the IP header.

Both UDP and TCP put their data in IP datagrams -- so every TCP-in-IP
datagram and every UDP-in-IP datagram contains a source and destination IP
address.

TCP and Mosh both add connections on top of IP. (UDP is basically just a
thin layer on top of IP that adds a port number so that individual programs
can use it.)

It's not enough for either end to assume an IP based on the *initial*
> datagram's IP? So based on that assumption, the best way for a

datagram to get its IP:port is to query the OS.


Not quite sure what you mean here. When you write a program to receive a
UDP datagram, that program can learn the source IP and port of the datagram
by calling recvfrom() or recvmsg().


> Which in our scenario
> is a privately networked container and so will be unreachable from the
> outside.
>

For the datagrams flowing from the mosh-server to the mosh-client, yeah,
the mosh-server is going to send using a private source address. It will be
the job of the proxy server to change that source address (and port number)
into a publicly reachable one.


> From a brief research I couldn't find any docs on this, I'm hoping its
> possible with Nginx. But maybe it can only be done with something like
> iptables?
>

I think you're going to have to write your own program to do this (using
the logic I described on June 30) -- I don't think iptables is going to be
able to do exactly what I described out of the box. But it doesn't have to
know anything about the SSP protocol and it doesn't have to decrypt
anything. It does have to rewrite the "private" IP addresses and port
numbers into public ones as I described.

Cheers,
Keith

On a separate note I re-launched Texttop as Browsh this week to a big
> response: https://www.brow.sh The SSH servers (`ssh brow.sh`) held up
> really well, they've had thousands of sessions already without issue.
> So would be great to get Mosh working as well.
>
> So just another friendly reminder - I'm having to tell people to
> compile Mosh themselves to get true colour support.
>
> On 8 July 2018 at 11:56, Keith Winstein  wrote:
> > Hi Thomas,
> >
> > Hmm, let me try to see if I can say it better. For an outgoing UDP
> datagram
> > (from a containerized mosh-server to a mosh-client), the mosh-server
> will be
> > sending the datagram from some private IP address (the container's IP
> > address, e.g. 10.0.0.5) and a source port that is probably going to be
> the
> > same across all containers (like 60001), since each container will
> probably
> > only be running one mosh-server.
> >
> > The proxy will want to rewrite the source IP:port so that the source IP
> > address is the proxy's routable Internet address and the port number is
> > whatever unique port it assigned and sent to the client in the original
> MOSH
> > CONNECT message that the client saw.
> >
> > -Keith
> >
> > On Sat, Jul 7, 2018 at 8:32 PM, Thomas Buckley-Houston 
> > wrote:
> >>
> >> Thanks so much for this idea, I really think it's the one, simple and
> >> scalable.
> >>
> >> I haven't tried but I'm pretty sure the mosh-server's "MOSH CONNECT"
> >> can be wrapped in plain BASH. I'm already in control of the SSH
> >> connection as I'm using my own `ForceCommand` script.
> >>
> >> Also I can still use this method with extra Round-Robin balanced IP
> >> addresses giving me multiple sets of 65,000 ports.
> >>
> >> The only thing I don't understand is why the outgoing UDP datagram has
> >> to rewrite the container's source IP. Isn't the original MOSH CONNECT
> >> IP:port the canonical reference?
> >>
> >> On 1 July 2018 at 12:54, Keith Winstein  wrote:
> >> > How about a semi-smart (but mostly Mosh-oblivious) server-side
> proxy/NAT
> >> > that works like this:
> >> >
> >> > - The proxy service has one public IP address and like 65,000
> available
> >> > UDP
> >> > ports.
> >> > - The proxy service can itself be redundant with failover...
> >> > - When a user wants to open a new Mosh connection, they Mos

Re: [mosh-devel] Mosh on Kuberbnetes

[Keith Winstein]

Hi Thomas,

Hmm, let me try to see if I can say it better. For an outgoing UDP datagram
(from a containerized mosh-server to a mosh-client), the mosh-server will
be sending the datagram from some private IP address (the container's IP
address, e.g. 10.0.0.5) and a source port that is probably going to be the
same across all containers (like 60001), since each container will probably
only be running one mosh-server.

The proxy will want to rewrite the source IP:port so that the source IP
address is the proxy's routable Internet address and the port number is
whatever unique port it assigned and sent to the client in the original
MOSH CONNECT message that the client saw.

-Keith

On Sat, Jul 7, 2018 at 8:32 PM, Thomas Buckley-Houston 
wrote:

> Thanks so much for this idea, I really think it's the one, simple and
> scalable.
>
> I haven't tried but I'm pretty sure the mosh-server's "MOSH CONNECT"
> can be wrapped in plain BASH. I'm already in control of the SSH
> connection as I'm using my own `ForceCommand` script.
>
> Also I can still use this method with extra Round-Robin balanced IP
> addresses giving me multiple sets of 65,000 ports.
>
> The only thing I don't understand is why the outgoing UDP datagram has
> to rewrite the container's source IP. Isn't the original MOSH CONNECT
> IP:port the canonical reference?
>
> On 1 July 2018 at 12:54, Keith Winstein  wrote:
> > How about a semi-smart (but mostly Mosh-oblivious) server-side proxy/NAT
> > that works like this:
> >
> > - The proxy service has one public IP address and like 65,000 available
> UDP
> > ports.
> > - The proxy service can itself be redundant with failover...
> > - When a user wants to open a new Mosh connection, they Mosh to a single
> > hostname (which resolves to the IP address of the proxy service).
> > - Your code allocates the necessary container, etc., and also allocates a
> > unique UDP port on the proxy.
> > - Your code runs the new mosh-server process in the target container.
> > - The proxy intercepts the mosh-server's "MOSH CONNECT  "
> > message, replacing the port number with the unique public-facing UDP port
> > (and remembering the container's IP address and the original port
> number).
> > - When the proxy receives an incoming UDP datagram destined to a
> particular
> > UDP port, it forwards it to the appropriate container at its IP address
> and
> > at the original port number. It *preserves* the source IP and port of the
> > datagram when forwarding.
> > - When the container wants to send an outgoing UDP datagram, it sends it
> > normally (to whatever IP:port is associated with the client), except the
> > containers are not directly connected to the Internet; they use the
> > proxy/NAT as their next-hop router.
> > - For the outgoing UDP datagram, the proxy/NAT rewrites the container's
> > source IP:port to its own IP and the public port number.
> >
> > I think this will allow you to serve like 65,000 separate mosh
> connections
> > from a single public IP address...
> >
> > The added latency in forwarding a datagram is probably <1 ms, and you
> don't
> > really have to change anything about Mosh itself or its internals.
> >
> > Unfortunately there are no unencrypted identifying marks to a Mosh
> > connection, except the incrementing sequence numbers (which start at 0
> for
> > every connection).
> >
> > -Keith
> >
> > On Fri, Jun 29, 2018 at 12:17 AM, Thomas Buckley-Houston <
> t...@tombh.co.uk>
> > wrote:
> >>
> >> Hey Keith, John, everyone,
> >>
> >> Yeah the more this is looking like a quite a big hurdle. Especially
> >> your point Keith about roaming IPs (which I'd forgotten), it's a
> >> central feature of Mosh I don't want to lose.
> >>
> >> So the only 2 options seems to be exposing multiple IPs for Round
> >> Robin (or other smart DNS routing) or writing a new Mosh proxy that
> >> already has knowledge of the existing keys. Both seem like quite a
> >> challenge. Round Robin DNS seems more approachable and I can imagine
> >> integrating it with the Google Cloud DNS API I'm already using, but I
> >> just wonder how expensive Google (or anyone for that matter) will make
> >> thousands of static IP addresses? Apart from me having to learn Mosh
> >> internals, one difficulty that strikes me about a Mosh proxy is that
> >> it might introduce a non-trivial delay to each datagram arriving?
> >> Though surely only ever in the order of a handful 

Re: [mosh-devel] Mosh on Kuberbnetes

[Keith Winstein]

How about a semi-smart (but mostly Mosh-oblivious) server-side proxy/NAT
that works like this:

- The proxy service has one public IP address and like 65,000 available UDP
ports.
- The proxy service can itself be redundant with failover...
- When a user wants to open a new Mosh connection, they Mosh to a single
hostname (which resolves to the IP address of the proxy service).
- Your code allocates the necessary container, etc., and also allocates a
unique UDP port on the proxy.
- Your code runs the new mosh-server process in the target container.
- The proxy intercepts the mosh-server's "MOSH CONNECT  "
message, replacing the port number with the unique public-facing UDP port
(and remembering the container's IP address and the original port number).
- When the proxy receives an incoming UDP datagram destined to a particular
UDP port, it forwards it to the appropriate container at its IP address and
at the original port number. It *preserves* the source IP and port of the
datagram when forwarding.
- When the container wants to send an outgoing UDP datagram, it sends it
normally (to whatever IP:port is associated with the client), except the
containers are not directly connected to the Internet; they use the
proxy/NAT as their next-hop router.
- For the outgoing UDP datagram, the proxy/NAT rewrites the container's
source IP:port to its own IP and the public port number.

I think this will allow you to serve like 65,000 separate mosh connections
from a single public IP address...

The added latency in forwarding a datagram is probably <1 ms, and you don't
really have to change anything about Mosh itself or its internals.

Unfortunately there are no unencrypted identifying marks to a Mosh
connection, except the incrementing sequence numbers (which start at 0 for
every connection).

-Keith

On Fri, Jun 29, 2018 at 12:17 AM, Thomas Buckley-Houston 
wrote:

> Hey Keith, John, everyone,
>
> Yeah the more this is looking like a quite a big hurdle. Especially
> your point Keith about roaming IPs (which I'd forgotten), it's a
> central feature of Mosh I don't want to lose.
>
> So the only 2 options seems to be exposing multiple IPs for Round
> Robin (or other smart DNS routing) or writing a new Mosh proxy that
> already has knowledge of the existing keys. Both seem like quite a
> challenge. Round Robin DNS seems more approachable and I can imagine
> integrating it with the Google Cloud DNS API I'm already using, but I
> just wonder how expensive Google (or anyone for that matter) will make
> thousands of static IP addresses? Apart from me having to learn Mosh
> internals, one difficulty that strikes me about a Mosh proxy is that
> it might introduce a non-trivial delay to each datagram arriving?
> Though surely only ever in the order of a handful of milliseconds I
> suppose.
>
> Are there not any other identifying marks to a datagram, I don't know
> much about low level networking, but maybe something like a MAC
> address for example?
>
> Thanks,
> Tom
>
> On 27 June 2018 at 04:50, Keith Winstein  wrote:
> > Hi Thomas,
> >
> > Glad you could provoke a very interesting discussion! But I'm still
> confused
> > -- how is "sticky IP-based routing" going to work after the client roams
> to
> > a new IP address (or to a new UDP source port)? When your system seems an
> > incoming UDP datagram from a previously unseen source IP:port, how does
> it
> > know which mosh-server (on which server machine) to send it to?
> >
> > With off-the-shelf Mosh, you basically need a load-balancing strategy
> that
> > allows a destination IP:port to uniquely identify a particular
> mosh-server.
> > You can do this with multiple DNS A/ records (where the client picks
> the
> > winning one -- maybe you permute the list), or with a smart DNS server
> that
> > serves *one* A or  record to the client at the time of resolution
> (like
> > a CDN would use).
> >
> > Instead of using the mosh wrapper script, you could have your users use
> some
> > other scheme to figure out the IP:port of the server, but the point is
> that
> > once you launch the mosh-client, it's going to keep sending datagrams to
> the
> > IP:port of the mosh-server, and those datagrams need to get to the same
> > mosh-server process even if the client roams to a different
> publicly-visible
> > IP address or port.
> >
> > You could imagine writing a very smart mosh proxy that has the keys to
> all
> > the sessions and can figure out (for an incoming datagram coming from an
> > unknown source IP:port) which session it actually belongs to, and then
> makes
> > a sticky mapping and routes it to the proper mosh-server. But 

Re: [mosh-devel] Mosh on Kuberbnetes

[Keith Winstein]

Hi Thomas,

Glad you could provoke a very interesting discussion! But I'm still
confused -- how is "sticky IP-based routing" going to work after the client
roams to a new IP address (or to a new UDP source port)? When your system
seems an incoming UDP datagram from a previously unseen source IP:port, how
does it know which mosh-server (on which server machine) to send it to?

With off-the-shelf Mosh, you basically need a load-balancing strategy that
allows a destination IP:port to uniquely identify a particular mosh-server.
You can do this with multiple DNS A/ records (where the client picks
the winning one -- maybe you permute the list), or with a smart DNS server
that serves *one* A or  record to the client at the time of resolution
(like a CDN would use).

Instead of using the mosh wrapper script, you could have your users use
some other scheme to figure out the IP:port of the server, but the point is
that once you launch the mosh-client, it's going to keep sending datagrams
to the IP:port of the mosh-server, and those datagrams need to get to the
same mosh-server process even if the client roams to a different
publicly-visible IP address or port.

You could imagine writing a very smart mosh proxy that has the keys to all
the sessions and can figure out (for an incoming datagram coming from an
unknown source IP:port) which session it actually belongs to, and then
makes a sticky mapping and routes it to the proper mosh-server. But I don't
think anybody has actually done this yet and of course there's a challenge
in making this reliable/replicated.

-Keith

On Mon, Jun 25, 2018 at 3:10 AM, Thomas Buckley-Houston 
wrote:

> Thanks so much for the clarification.
>
> > UDP is connectionless
>
> That's the key here. So I have no choice but to use sticky IP-based
> routing. Round-robin DNS isn't an option I don't think, because I hope
> one day to be able to scale to thousands of servers.
>
> And thanks so much for the heads up about my DNSSEC records. I've sent
> a request for them to be deleted. I'd added them and some SSHFP
> records to explore automatically passing the StrictHostKey warning.
> But it's not entirely straight forward. Even with correct DNS records
> the SSH user still has to have VerifyHostKeyDNS enabled, which as I
> understand most people don't. And then on top of that my DNS provider
> (DNSSimple) automatically rotate the keys every 3 months, which means
> I have to manually send a request to my registrars by email to update
> the DNSSEC records. Is it all worth it do you think?
>
> On 24 June 2018 at 13:36, Anders Kaseorg  wrote:
> > You may have a misunderstanding about how a Mosh session is set up.  The
> > mosh script launches a mosh-server on the remote system via SSH;
> > mosh-server picks a port number and a random encryption key, and writes
> > them to stdout, where they go back over SSH to the mosh script; then the
> > mosh script launches mosh-client passing the IP address, port number, and
> > encryption key.  The newly launched mosh-client and mosh-server processes
> > exchange UDP packets encrypted with the shared key; communication is
> > successful if the packets can be decrypted.
> >
> > There’s no separate “key checking” step to be disabled.  And it doesn’t
> > make sense to “refuse more than 1 connection on the same port”, both
> > because UDP is connectionless, and because a new mosh-server is launched
> > on a new port for each Mosh session (it is not a daemon like sshd).
> >
> > The easiest way to put Mosh servers behind a load balancer is with
> > round-robin DNS where a single hostname resolves to many addresses, or to
> > different addresses for different clients and/or at different times.
> > We’ve already gone out of our way to make the mosh script resolve the
> > hostname only once and use the same address for the SSH connection and
> the
> > UDP packets, because that’s needed for MIT’s athena.dialup.mit.edu pool.
> >
> > If that’s not an option and you really need all connections to go through
> > a single load balancer address, you could try wrapping mosh-server in a
> > script that passes different disjoint port ranges (-p) on different
> > backends, and forwarding those ranges to the corresponding backends from
> > the load balancer.
> >
> > Unrelatedly, brow.sh doesn’t resolve with DNSSEC-enabled resolvers like
> > 1.1.1.1 or 8.8.8.8, seemingly due to some problem with the DS records set
> > with the registrar: https://dnssec-debugger.verisignlabs.com/brow.sh.
> >
> > Anders
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] How to support xterm modifier key setting (CSI > Ps; Ps m)

[Keith Winstein]

Hi Erik,

It looks reasonable to me -- please feel free to submit a pull request on
GitHub. One question will be, how does mosh-client know it's okay to send
these sequences to the local terminal (e.g. are they in the termios entry
or something), or if it's not possible to know, are we pretty sure nothing
bad comes from sending them to some other type of local terminal?

-Keith

On Mon, May 28, 2018 at 2:16 PM, Erik Hons  wrote:

> Hey, I tried it out and it worked! The patch needs more work, but is it on
> the right track?
>
>
>
> On Mon, May 28, 2018 at 11:16 AM, Erik Hons  wrote:
>
>> Hey Keith,
>>
>> Thanks for writing back! I think my situation is different than the bug
>> you linked to. Let me see if I have this right:
>>
>> Mosh always emulates and advertises itself to the application as an
>> xterm, regardless of what the user's terminal is. If the user's terminal
>> doesn't emulate an xterm exactly then there can be problems.
>>
>> In bug #178 the user's terminal is sending non-xterm sequences for
>> Home/End. When mosh forwards those sequences, the application gets
>> confused. Fixing this would require mosh to understand all the non-xterm
>> terminals and "translate" to xterm sequences. No wonder that's an open
>> issue!
>>
>> In my situation, I have a standard xterm sequence that is being sent by
>> the application to alter the user's xterm. This is almost the opposite
>> situation: mosh needs to forward that sequence from the application side to
>> the client side.
>>
>> The effect is the client's terminal sends a different sequence for
>> C-backspace which makes it seem related to #178. But in this case, the
>> weird sequence is desired; having a unique sequence for C-backspace allows
>> emacs to do something different for that keycode.
>>
>> Does that all make sense?
>>
>> If so, then I think I need mosh to replicate the application's sequence
>> on the client side, just like it does for the mouse reporting mode. I would
>> add a resource-values member to Terminal::DrawState for the xterm settings,
>> and then watch for changes in Display::new_frame() sending the correct
>> sequence to the user's terminal there. I'm not sure how the serialization
>> works: Would I have to make any other changes?
>>
>>
>> On Sun, May 27, 2018 at 9:14 PM, Keith Winstein 
>> wrote:
>>
>>> Hi Erik,
>>>
>>> I'm a little confused why you want this in general, and it may relate to
>>> a design weakness in Mosh, which is that it basically assumes that the
>>> client terminal acts like an xterm. By default, an xterm sends Ctrl-H
>>> (0x08) when the user types "Ctrl-Backspace" (and VTE seems to also follow
>>> this convention). Mosh advertises to the remote host that it is an xterm
>>> (or xterm-256color) and *basically* just sends bytes from the user's
>>> terminal through to the host unchanged. For terminals that act a little
>>> differently (e.g. rxvt), we have some long-lived bugs related to Mosh's
>>> failure to translate from the terminal-generated escape codes to what the
>>> application is (rightly) expecting from the advertised TERM type of
>>> xterm/xterm-256color.
>>>
>>> https://github.com/mobile-shell/mosh/issues/178
>>>
>>> Maybe mintty and Ctrl-Backspace are in the same boat? If you want to
>>> help us fix this bug overall, that would be awesome.
>>>
>>> For the specific question, you basically have two options:
>>>
>>> (a) Propagate this state change all the way through to the client
>>> terminal emulator (which is what we do for mouse reporting), and continue
>>> to send bytes unchanged in the client-to-server direction.
>>>
>>> (b) Keep track of the state in the mosh-server only, and have the server
>>> modify incoming bytes from the client before applying them to the terminal.
>>> This is what we do for the "application mode" setting for the cursor keys.
>>> See src/terminal/terminaluserinput.cc .
>>>
>>> For this one, it seems like (b) might be sufficient... but really we
>>> should just fix bug #178 overall in some clean way if that's the root cause.
>>>
>>> -Keith
>>>
>>> On Sat, May 26, 2018 at 1:18 PM, Erik Hons  wrote:
>>>
>>>> I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
>>>> to send an alternate escape sequence for "C-Backspace" than the
&g

Re: [mosh-devel] How to support xterm modifier key setting (CSI > Ps; Ps m)

[Keith Winstein]

Hi Erik,

I'm a little confused why you want this in general, and it may relate to a
design weakness in Mosh, which is that it basically assumes that the client
terminal acts like an xterm. By default, an xterm sends Ctrl-H (0x08) when
the user types "Ctrl-Backspace" (and VTE seems to also follow this
convention). Mosh advertises to the remote host that it is an xterm (or
xterm-256color) and *basically* just sends bytes from the user's terminal
through to the host unchanged. For terminals that act a little differently
(e.g. rxvt), we have some long-lived bugs related to Mosh's failure to
translate from the terminal-generated escape codes to what the application
is (rightly) expecting from the advertised TERM type of
xterm/xterm-256color.

https://github.com/mobile-shell/mosh/issues/178

Maybe mintty and Ctrl-Backspace are in the same boat? If you want to help
us fix this bug overall, that would be awesome.

For the specific question, you basically have two options:

(a) Propagate this state change all the way through to the client terminal
emulator (which is what we do for mouse reporting), and continue to send
bytes unchanged in the client-to-server direction.

(b) Keep track of the state in the mosh-server only, and have the server
modify incoming bytes from the client before applying them to the terminal.
This is what we do for the "application mode" setting for the cursor keys.
See src/terminal/terminaluserinput.cc .

For this one, it seems like (b) might be sufficient... but really we should
just fix bug #178 overall in some clean way if that's the root cause.

-Keith

On Sat, May 26, 2018 at 1:18 PM, Erik Hons  wrote:

> I'm trying to make emacs work well inside mintty/mosh. I'd like mintty
> to send an alternate escape sequence for "C-Backspace" than the
> default (which is "C-_"). There is an xterm sequence for this --
> "\e[>4;1m" -- which sets the "modifyOtherKeys" resource. Emacs sends
> that sequence on startup. When using ssh for remoting, the sequence is
> passed to the client side, mintty sees it, and implements the desired
> behavior.
>
> The mosh terminal emulator appears to discard the sequence. There is
> no matching function in terminal/terminalfunctions.cc defined for it,
> so the dispatch process hits the "unknown function" condition in
> terminal/terminaldispatcher.cc@226 (Dispatcher::dispatch()).
>
> As an experiment, I've added a terminal function for "\e[>4;1m" and
> confirmed that it sees the sequence when emacs sends it. I'm stuck on
> what to do next.
>
> It looks like I need to add something to Terminal::DrawState, then in
> Display::new_frame() look for that member and call
> frame.append("\e[>4;1m"); That's how the "mouse_reporting_mode" and
> similar settings are handled.
>
> But this might bring up a bigger question: How should the mosh
> terminal emulator interact with the client side terminal emulator? I
> can add support for this specific sequence, but maybe something more
> general is warranted.
>
> Any advice?
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh CN domain and keyword

[Keith Winstein]

Hello,

Thank you for reaching out to us. Mosh is an open-source software project.
We have the domain name "mosh.org", and our website is hosted at
https://mosh.org. We have a pending trademark registration for "Mosh" in
the United States.

We were not aware of these proposed registrations for mosh.cn, mosh.com.cn,
mosh.net.cn, or mosh.org.cn.

We have no affiliation or connection with Kaikun Ltd.

Sincerely,
Keith Winstein
Mosh project

From: "Charles Liu" <
> servi...@chinaregistry-jb.org.cn>
> To: 
> Date: Sat, 21 Apr 2018 05:21:21 +0800
> Subject: mosh CN domain and keyword
> (It's very urgent, please transfer this email to your CEO. Thanks)
>
> We are the domain registration and solution center in China. On April 18,
> 2018, we received an application from Kaikun Ltd requested "mosh" as their
> internet keyword and China (CN) domain names (mosh.cn, mosh.com.cn,
> mosh.net.cn, mosh.org.cn). But after checking it, we find this name
> conflict with your company name or trademark. In order to deal with this
> matter better, it's necessary to send email to you and confirm whether your
> company have affiliation with this Chinese company or not?
>
> Best Regards,
> Charles Liu | Service & Operations Manager
> China Registry (Head Office) | 6012, Xingdi Building, No. 1698 Yishan
> Road, Shanghai 201103, China
> Tel: +86-02154290702 | Fax: +86-02154290703 | Mob: +86-13816428671
> Email: char...@chinaregistry.cn
> Web: www.chinaregistry.cn
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Secure agent forwarding with Mosh

[Keith Winstein]

On Thu, Nov 9, 2017 at 6:43 AM, Daniel Roethlisberger  wrote:

> Specifically, I am not interested in manually approving agent
> requests.  The ratio of hassle to mitigated risk is unreasonable
> in my opinion.  It addresses a narrow category of attacks while
> not helping against other attacks with similar prerequisites and
> risk (e.g. injecting commands into TTYs of SSH sessions from the
> compromised system, or replacing a legit auth challenge on the
> compromised server as it is being handed to the client machine's
> agent where it will be approved by the user).  So unless the
> confirmations can be easily removed by configuration or patching,
> I won't be overly excited about this.
>

Thanks for your feedback, Daniel. I think if you try it, you will be
pleasantly surprised.

On the issue of "manually approving agent requests" -- you don't have to.
The local agent gets to see and approve each request, but the user can
"allow forever" and doesn't need to approve each request manually.

Re: "additional network and firewall considerations," Guardian Agent just
runs over autossh. If you can SSH to the intermediary, you can run Guardian
Agent.

On the "other attacks with similar prerequisites" -- if I understand you,
Guardian Agent already prevents these attacks. The "legit auth challenge"
is bound to the triple of { intermediary machine, command, server }, so
it's not possible to "replace" a legit auth challenge and use the user's
credentials to execute a different command (or on a different server, or
from a different intermediary) than what was requested. (The way that
Guardian Agent works is that the local agent actually issues the command to
the remote server before handing over the session to the intermediary.) So
while a compromised intermediary machine can *ask* to execute an evil
command, the agent will know about it and it won't match some prior "allow"
rule in the local configuration.

(To be clear, this works best for commands like 'git fetch-pack' to a
particular repository or something like that, where the command is not
going to allow arbitrary follow-on commands to be executed. If the user
wants to execute a shell or some other interactive session, then yes, this
doesn't prevent a malicious intermediary from later inserting arbitrary
input into the session. Probably the best thing in that case, if you really
don't trust the intermediary, would be to just to use the intermediary to
ferry ciphertext bytes and not to let it see the plaintext at all. But even
in that case, at least Guardian Agent still lets you lock down which
intermediaries can connect to which remote servers.)

-Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] Secure agent forwarding with Mosh

[Keith Winstein]

Hi folks,

We developed a (prototype) tool that does secure agent forwarding and works
with Mosh. Would be grateful for testing and feedback:
https://github.com/StanfordSNR/guardian-agent

Compared with traditional ssh-agent forwarding, this tool provides
more-constrained agent forwarding that we think could safely be enabled on
any connection. It works alongside any version of Mosh or SSH. Users run
sga-guard (the agent) on their local machine, in a separate window
alongside the interactive session. sga-guard prompts the user to approve
forwarded ssh requests from the intermediary host, either with an X11 popup
or in that second terminal window. Unlike with ssh-agent forwarding, the
agent can enforce limits on which intermediary host can run which command
on which servers.

Based on feedback to this beta/prototype, maybe we can agree on a good way
to incorporate these techniques more deeply into Mosh. (Even if it's just a
mosh -A flag that sets this up automatically instead of needing a second
terminal window.)

There is a more detailed writeup in the README:
https://github.com/StanfordSNR/guardian-agent

We're grateful for feedback, whether about the usability of the tool, the
underlying mechanism, or the best way to make this smooth for Mosh users.

Thanks all,
the Guardian Agent developers (Dima Kogan, Henri Stern, David Mazieres,
Keith Winstein)
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] [mosh-users] How to properly kill old mosh-server connections

[Keith Winstein]

Hello Dan,

For idea #1, please check out the MOSH_SERVER_NETWORK_TMOUT
and MOSH_SERVER_SIGNAL_TMOUT environment variables. These are documented in
the mosh-server(1) man page. The feature was released in Mosh 1.2.6 (August
2016) so your mosh-server needs to be at least that new.

For idea #2, we could certainly try to be more sophisticated than the
current behavior, but I think many people deal with this by using mosh to
invoke a command like "screen -dr", which automatically cleans up any older
mosh session before starting the new one.

E.g.: mosh user@server -- screen -dr

Regards,
Keith

On Wed, Oct 18, 2017 at 10:09 PM, Dan Mahoney (Gushi) 
wrote:

> All,
>
> I'm aware that for every mosh connection (i.e. one each from my laptop,
> desktop, and other laptop), I'm going to have a mosh-server connection.
> These each have their own ssl key, and they pass a screen session around,
> by doing a screen -d -r on whatever system I sit down at.
>
> Recently, it seems like I had something like 20 mosh-server sessions
> running, which cropped up at various times as I did updates on my various
> systems, and then ssh'd back in.
>
> I'm aware that mosh cannot possibly know when a system has been rebooted,
> so can't know when to kill a server session.
>
> That said, one useful idea would be killing any session that hasn't been
> "used" in over some period of time (say, a week?).  This could be done by
> giving mosh-server some kind of idle timeout -- or by making this
> queryable somehow, so that a server-side crontab could clear these out.
>
> A second (more complicated) idea would be -- assume that I'll only ever
> connect once from a given machine -- and allow me to "kick" any other
> connections from my existing hostname.  Is this possible?  It would
> require mosh to know the hostname of the client machine and somehow be
> able to compare that on servers.  (Obviously this is less workable when
> your hostname is dynamic, assigned via your DHCP server or based on your
> RDNS).
>
> -Dan
>
> --
>
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144   AIM: LarpGM (Farewell, AIM!)
> Site:  http://www.gushi.org
> ---
>
> ___
> mosh-users mailing list
> mosh-us...@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-users
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] SSH agent forwarding

[Keith Winstein]

Hello Daniel,

The issue is basically the same since the original pull request in 2013 --
whatever change we make to the Mosh protocol to support ssh-agent
forwarding is one we have to live with forever, and the limitations of the
Mosh protocol make us not want to commit ourselves to these changes. Mosh
does not handle big Instructions well; our fragmentation system is very
simple, so adding reliable transport of not-exactly bounded OOB data in the
synchronized SSP object makes me nervous.

(We're also pretty paranoid about security, and this leads to maybe
excessive conservatism -- Mosh has never had a security hole, and we hope
to keep it that way. Making intensive protocol changes to add extra
features to the core protocol is also something I'm nervous about, and
nervous about supporting over time. If you look at where SSH and TLS's
security holes have come from, it's basically all from adding this kind of
complexity in a non-isolated way. Of course many entities do run Timo's
version; apparently Facebook uses it extensively.)

I think my preferred approach here is to release something that does
resilient ssh-agent forwarding "to the side" of the Mosh connection, over a
separate connection and with a separate package that users can run if they
choose. We have developed something internally (at Stanford) that you might
like that also does "secure" ssh-agent forwarding, by allowing the agent to
authenticate and limit (1) the host making the request, (2) the remote host
that host is trying to authenticate to, and (3) the command the host wants
to execute on the remote host. (With normal ssh-agent forwarding, the agent
can't learn any of these things and is basically signing a blank check.)
This works alongside SSH and Mosh. We hope to have a public beta soon and
will look forward to reports from anybody who wants to test it.

-Keith

On Thu, Sep 21, 2017 at 9:33 AM, Daniel Roethlisberger 
wrote:

> John, all,
>
> Mosh is still lacking SSH agent forwarding, preventing the use of
> mosh in many setups.  What is blocking the resolution of issue
> 120 and pull request 696?  The issue has been raised in 2012 and
> the pull req is sitting there since 2015:
>
> https://github.com/mobile-shell/mosh/issues/120
> https://github.com/mobile-shell/mosh/pull/696
>
> What would be needed to get SSH agent support into mosh, be it
> with Timo J. Rinne's implementation in the pull req or in a
> different way?
>
> -Daniel
>
> --
> Daniel Roethlisberger
> http://daniel.roe.ch/
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] WO0000010291764 || Regarding the ECCN for the product Mosh Version 1.3.2

[Keith Winstein]

Hello,

It is our understanding that we have complied with the requirements
(including notification) for Mosh to have an ECCN of 5D002.

Sincerely,
Keith Winstein

On Tue, Sep 12, 2017 at 3:25 PM, Kumar, Ashish /CS  wrote:

> Hi Keith,
>
>
>
>
>
> This is Ashish Kumar, a software analyst from centralized license
> management team ( also known as IT Asset Management ) of ExxonMobil
>
>
>
> This is to bring in your kind notice that we are interested in your
> product *Mosh version 1.3.2,* so we would request you to please assist us
> with some of our queries below :
>
>
>
> If you have already classified this software with *ECCN*, please confirm
> the applicable number.
>
>
>
> If you do not have your software classified with an ECCN, please kindly
> answer the following questions so that we may self-assess:
>
>
>
> 1, Does the Software perform any encryption or utilize any encryption
> processes?  Y/N
>
> 2. If the answer is YES to question 1, please indicate if the encryption
> is coded into the application or separately called (such as using SSL)
>
> 3. If the answer is YES to question 1, please indicate what function(s)
> the cryptography/encryption serves
>
>
>
> A, Copyright protection purposes (Includes using a license key/code)
>
> B, User authentication purposes
>
> C, A core part of the functionality such as to encrypt databases
>
> D, To encrypt communications between the software and a host system.
>
>
>
> *Background information:*
>
> *An Export Control Classification Number (ECCN) is a specific
> alpha-numeric code that identifies the level of export control for items
> e.g. software that are exported from member states of the Wassenaar
> Arrangement, including the United States. After obtaining the ECCN, the
> exporter must determine whether an export license is required to export
> items to certain countries.*
>
>
>
> Thanks in advance.
>
>
>
>
>
> Thanks and Regards,
>
> *Ashish Kumar*
>
> New Products Team
>
> EMIT Customer Infrastructure
>
>
>
> *HCL Technologies Private Limited*
>
> (CIN: *L74140DL1991PLC046369*)
>
> 10th Floor, ODC-IV, Software Tower 6, Sector 126
>
> Noida SEZ, Uttar Pradesh – 201301, India
>
> Phone +14088093746 <(408)%20809-3746>; Extn - 4144552
>
> IM me | E-mail me 
>
>
>
> for
>
>
>
> *ExxonMobil Global Services Company*
>
> 22777 Springwoods Village Parkway
>
> Spring, TX 77389
>
> United States of America
>
>
>
> This email and / or its attachments may contain information that is
> privileged, confidential, private, proprietary and exempt from disclosure
> under applicable law. If you are not the intended recipient, you are put on
> notice that any unauthorized use, disclosure, copying, distribution, or
> taking of any action in reliance on the contents of any of the materials
> herein is prohibited. If you have received this email in error, please
> inform the sender immediately and delete this email and its attachments.
>
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Termius + Mosh

[Keith Winstein]

Roman,

In early May, we had this exchange (also below in this thread). I wrote:

(3) We've had bad experiences in the past with people (especially iSSH on
> iOS) attempting to implement the Mosh protocol, but with imperfect results,
> and users blaming Mosh for the problems. As with these past cases, please
> don't refer to your implementation as "Mosh." Please refer to it as
> "Termius mosh-compatible mode," with your own name first and
> "mosh-compatible" instead of "Mosh".


You replied:

Sure, no problem. We will make sure that it’s mentioned as
> "mosh-compatible”.


We expect your company to honor this agreement -- do you plan to do so?

I'm happy to explain our position further, and maybe you can understand why
this is important to us. Mosh is a piece of software, like OpenSSH or
Chrome. The protocol is called SSP (State Synchronization Protocol). You
have told us that your program is not derived from Mosh, so we really don't
want your company to call it Mosh. It's nothing personal -- but users are
better served knowing the difference. We had a bad experience with somebody
writing what they thought was a compatible implementation, and users
getting confused and blaming us. So we don't want users to think they are
running Mosh when they are running somebody else's application.

We would be fine with you making statements like, "Termius is
mosh-compatible" or "Termius has a mosh-compatible client" or even "Termius
works with Mosh servers." They key thing here is that it's fine for Termius
to claim mosh-compatibility, or to work *with* Mosh servers. It shouldn't
claim to *be* or to include Mosh, because it doesn't.

Yes, the text "SSH, Telnet, and Mosh in your pocket" and "... with SSH,
Telnet, and Mosh." appears on your current website, https://termius.com.
You can visit it yourself to see.

-Keith

On Mon, Aug 7, 2017 at 5:20 PM, Roman Kudiyarov  wrote:

> Hi Keith,
>
> Could you please point me where “Mosh in your pocket” is. Honestly I can’t
> find it. Btw, we’ve recently updated both of our websites so you might
> refer to the old version.
>
> In terms of the naming, there are two entities called MOSH:
> 1. *Mosh protocol*. Termius is keen to participate in the discussion of
> the protocol development. We have some thoughts on improving UX, e.g live
> sessions for quick switch between devices.
> 2. *Server and client implementation* of the protocol which is available
> on GitHub.
>
> In general, I find mosh-compatible pretty long and a little bit confusing
> as it’s just a proprietary implementation of the mosh protocol, e.g. there
> are many implementation of the SSH protocol. In addition, we can’t fit in
> in Apple App Store description, e.g. Termius - SSH, Mosh-compatible and
> Telnet client.
>
> In terms of the support requests, we are subscribed to the mosh-devel
> channel and happy with answering questions related to our implementation.
> Btw, we have UserVoice integrated into our apps so we see most of the
> requests right there.
>
> On 7 August 2017 at 7:48:41 PM, Keith Winstein (kei...@cs.stanford.edu)
> wrote:
>
> Hello Roman,
>
> As we requested earlier (below in this thread), could you please refer to
> your software as "mosh-compatible" instead of calling it a mosh client (or
> "Mosh in your pocket" as is on your website now)?
>
> Thank you,
> Keith
>
> On Sun, Aug 6, 2017 at 10:56 PM, Roman Kudiyarov 
> wrote:
>
>> Hi there!
>>
>> I’m glad to announce that Termius is a free mosh client for iOS and
>> Android. At the moment we are working on a version for Mac, Windows and
>> Linux.
>>
>> I wonder if it is possible to put a link to termius website from mosh.org so
>> end users have more options to pick up from.
>>
>> On 4 May 2017 at 4:46:24 PM, Keith Winstein (kei...@cs.stanford.edu)
>> wrote:
>>
>> Hello Roman,
>>
>> Okay, but if we can't see your code, we don't have a good way to start to
>> know if your implementation is "fully compatible" with Mosh (it's not like
>> we have a compatibility test suite for new binary implementations). If you
>> didn't implement it with clean-room approach and were referencing the Mosh
>> code as you wrote your own implementation, we can't tell you if your
>> program is a derivative of Mosh or not. I do appreciate your kind words
>> about Mosh.
>>
>> Sincerely,
>> Keith
>>
>> On Wed, May 3, 2017 at 6:45 PM, Roman Kudiyarov 
>> wrote:
>>
>>> Hi Keith!
>>>
>>> On 2 May 2017 at 6:40:20 AM, Keith Winstein (kei...@cs.stanford.edu)
&g

Re: [mosh-devel] Termius + Mosh

[Keith Winstein]

Hello Roman,

As we requested earlier (below in this thread), could you please refer to
your software as "mosh-compatible" instead of calling it a mosh client (or
"Mosh in your pocket" as is on your website now)?

Thank you,
Keith

On Sun, Aug 6, 2017 at 10:56 PM, Roman Kudiyarov  wrote:

> Hi there!
>
> I’m glad to announce that Termius is a free mosh client for iOS and
> Android. At the moment we are working on a version for Mac, Windows and
> Linux.
>
> I wonder if it is possible to put a link to termius website from mosh.org so
> end users have more options to pick up from.
>
> On 4 May 2017 at 4:46:24 PM, Keith Winstein (kei...@cs.stanford.edu)
> wrote:
>
> Hello Roman,
>
> Okay, but if we can't see your code, we don't have a good way to start to
> know if your implementation is "fully compatible" with Mosh (it's not like
> we have a compatibility test suite for new binary implementations). If you
> didn't implement it with clean-room approach and were referencing the Mosh
> code as you wrote your own implementation, we can't tell you if your
> program is a derivative of Mosh or not. I do appreciate your kind words
> about Mosh.
>
> Sincerely,
> Keith
>
> On Wed, May 3, 2017 at 6:45 PM, Roman Kudiyarov  wrote:
>
>> Hi Keith!
>>
>> On 2 May 2017 at 6:40:20 AM, Keith Winstein (kei...@cs.stanford.edu)
>> wrote:
>>
>> Thanks for letting us know!
>>
>> (1) Could you please describe the process you used to develop a
>> clean-room implementation of the Mosh protocol? Did you write up a protocol
>> specification based on the Mosh source code, and then have somebody else
>> implement the spec? If so, would you be willing to share the protocol spec?
>>
>> Writing the spec would be ideal scenario but we just used the original
>> source code to learn the protocol and developed our own implementation from
>> scratch using different set of libraries and frameworks.
>>
>>
>>
>> (2) Is the source code of your implementation available?
>>
>> We are not sure about making it open-source as we are going to use as our
>> competitive advantage and we’ve invested quite a lot of time to get to this
>> point.
>>
>>
>>
>>
>> (3) We've had bad experiences in the past with people (especially iSSH on
>> iOS) attempting to implement the Mosh protocol, but with imperfect results,
>> and users blaming Mosh for the problems. As with these past cases, please
>> don't refer to your implementation as "Mosh." Please refer to it as
>> "Termius mosh-compatible mode," with your own name first and
>> "mosh-compatible" instead of "Mosh".
>>
>> Sure, no problem. We will make sure that it’s mentioned as
>> "mosh-compatible”.
>>
>>
>>
>>
>> Regards,
>> Keith
>>
>> On Sun, Apr 30, 2017 at 3:34 PM, Roman Kudiyarov 
>> wrote:
>>
>>> Hi all!
>>>
>>>
>>> I’m a co-founder of Crystalnix. We work on Termius, cross-platform SSH
>>> client (iOS, Android, Mac, Windows, Linux and Chrome). Now we have around
>>> 200K of monthly users! Our team aims to redesign command line UX from
>>> scratch. Your team has done an amazing job with the mosh protocol which was
>>> one of the most desired features that our users have been asking for.
>>>
>>> We had to develop our own mosh client(completely different code-base)
>>> due to the license restrictions. Anyway our code is fully compatible with
>>> the current version of the mosh server. Very shortly we are launching beta
>>> for Android and then will roll out to other platforms as well.
>>>
>>> That means that this amazing technology(mosh) will be available for huge
>>> user base for free!
>>>
>>> I just wanted to share those news and say thank you for the job you’ve
>>> done!
>>>
>>> Please let me know if you have any questions!
>>>
>>>
>>> Kind Regards,
>>> Roman Kudiyarov
>>> Termius Team
>>>
>>> ___
>>> mosh-devel mailing list
>>> mosh-devel@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>>
>>>
>>
>>
>>
>>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.3.2 released

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mosh users and developers,

mosh 1.3.2 has been released. This is primarily a maintenance
release. (We skipped version 1.3.1 because of a glitch in Debian
packaging. The previous release was mosh 1.3.0.)

The source code is at: https://mosh.org/mosh-1.3.2.tar.gz
(SHA-256: da600573dfa827d88ce114e0fed30210689381bbdcff543c931e4d6a2e851216)

John Hood was the primary developer and release coordinator and
deserves all our thanks.

Compatibility: mosh 1.3.2 is backwards-compatible with mosh-clients
back to 0.96 and mosh-servers back to 1.0.9.

macOS binary package: We are releasing a macOS binary package.

https://mosh.org/mosh-1.3.2.pkg is an x86_64 build for 10.10 and later.
(SHA-256: 7b00838e04e954e19d6bd5a63ff9729084bd55e21d894994916b73e996a9c42f)

However, we encourage macOS users to install via MacPorts or Homebrew,
instead of using the binary package, in order to receive automatic upgrades.

Bugs: Please let us know of any problems at the GitHub issue tracker,
at https://github.com/mobile-shell/mosh/issues. The developers can
also be found on IRC at .

The full change log for this release:

===

* Platform support:
* Explicitly enable binding to both IPv4 and IPv6 addresses.
  (Giel van Schijndel)
* Restore perl 5.8.8 support for RHEL5.  (Alexander Chernyakhovsky)
* Make tests detect UTF-8 locale with a helper executable.  (John Hood)
* Don't print /etc/motd on IllumOS.  (John Hood)
* Print {,/var}/run/motd.dynamic on Ubuntu.  (John Hood)
* Fix build on Haiku. (Adrien Destugues)
* Disable unicode-later-combining.test for tmux 2.4.
  This fixes build failures.  (John Hood)

  * Bug fixes:
* In tests, explicitly set 80x24 tmux window, for newer versions
  of tmux.  (John Hood)
* Work around JuiceSSH rendering bug.  (John Hood)
* Do not move cursor for SCROLL UP and SCROLL DOWN--
  fixes an issue with tmux 2.4.  (John Hood)

===

Best regards on behalf of the Mosh team,
Keith Winstein
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZc8lFAAoJECC3KDr+JUxpFJIQAIKI3CwPyIgd6BNyoYdqIz9v
AjapQEvYERErkjM0R8qNDGajJc5i1n6uHs/QJs+O0BflbTDchXueTG6cLodqhu7v
i+rMpoYXasuE3DirlvR5R10AHo5WOTv3hRI6xeZW5pi7FcHXfc8UcyVT7AeBcxrj
epk2F5AAYVnXt60XyakXDyq1SR6XprspX06VSOZeiqn13qIgnVVVA0SPsAHJ32fo
9Wm6vRJQAaUkdZ/8tIgXNp/NU/EPqSW0JMte3OvvA43CICTltfyAy/Btk4A8Ibbw
iJ6okgxHFA/+Hnr0Y+HmRlqIQgArlxSfg3fMA6VaqOb1H5H7x8Wno2rpV/OY4Rf2
86jw2TVVKxuWXvdzF1oXiTpLtbX985T/FWPZj+31jp438uiupMhrxDS7P1/El9ZF
v8x+/syFwo+Ht4UjZdynCtQgw5MM2aUIltJIUXmGP1N/QHYS94VSNMjj15WbeIGJ
OmhIahUtHyELNuWiTwV+I60pZdTGtilhVun6r6jxAwKufCnQ2sM6D+z1QJiO4qgZ
tCZUkE3CRmSIDQRXO0MKBiuk8qcfpJX0f+0P1LH7Qm5s1j/5Jn48Atd9UaozDVpK
+GO6AOySZ+2BNgSu3EC3hj6ezu7UnNqJ9/SUZ/1NsS+YT15YYWFexjggJ1t/0SlI
hZuMTcTCXD5n8jn++dYr
=fjFO
-END PGP SIGNATURE-
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] [mosh-users] Mosh 1.3.1 release candidate 2 available for testing

[Keith Winstein]

Thanks, Jeremie! Do these tests work with 1.3.0? (And if so, are you able
to bisect this for us?)

Cheers,
Keith

On Fri, May 26, 2017 at 4:55 PM, Jeremie Courreges-Anglas 
wrote:

>
> On OpenBSD-current (amd64), make check reports two failures.  Log files
> attached.
>
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>
> ___
> mosh-users mailing list
> mosh-us...@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-users
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Termius + Mosh

[Keith Winstein]

Hello Roman,

Okay, but if we can't see your code, we don't have a good way to start to
know if your implementation is "fully compatible" with Mosh (it's not like
we have a compatibility test suite for new binary implementations). If you
didn't implement it with clean-room approach and were referencing the Mosh
code as you wrote your own implementation, we can't tell you if your
program is a derivative of Mosh or not. I do appreciate your kind words
about Mosh.

Sincerely,
Keith

On Wed, May 3, 2017 at 6:45 PM, Roman Kudiyarov  wrote:

> Hi Keith!
>
> On 2 May 2017 at 6:40:20 AM, Keith Winstein (kei...@cs.stanford.edu)
> wrote:
>
> Thanks for letting us know!
>
> (1) Could you please describe the process you used to develop a clean-room
> implementation of the Mosh protocol? Did you write up a protocol
> specification based on the Mosh source code, and then have somebody else
> implement the spec? If so, would you be willing to share the protocol spec?
>
> Writing the spec would be ideal scenario but we just used the original
> source code to learn the protocol and developed our own implementation from
> scratch using different set of libraries and frameworks.
>
>
>
> (2) Is the source code of your implementation available?
>
> We are not sure about making it open-source as we are going to use as our
> competitive advantage and we’ve invested quite a lot of time to get to this
> point.
>
>
>
>
> (3) We've had bad experiences in the past with people (especially iSSH on
> iOS) attempting to implement the Mosh protocol, but with imperfect results,
> and users blaming Mosh for the problems. As with these past cases, please
> don't refer to your implementation as "Mosh." Please refer to it as
> "Termius mosh-compatible mode," with your own name first and
> "mosh-compatible" instead of "Mosh".
>
> Sure, no problem. We will make sure that it’s mentioned as
> "mosh-compatible”.
>
>
>
>
> Regards,
> Keith
>
> On Sun, Apr 30, 2017 at 3:34 PM, Roman Kudiyarov 
> wrote:
>
>> Hi all!
>>
>>
>> I’m a co-founder of Crystalnix. We work on Termius, cross-platform SSH
>> client (iOS, Android, Mac, Windows, Linux and Chrome). Now we have around
>> 200K of monthly users! Our team aims to redesign command line UX from
>> scratch. Your team has done an amazing job with the mosh protocol which was
>> one of the most desired features that our users have been asking for.
>>
>> We had to develop our own mosh client(completely different code-base) due
>> to the license restrictions. Anyway our code is fully compatible with the
>> current version of the mosh server. Very shortly we are launching beta for
>> Android and then will roll out to other platforms as well.
>>
>> That means that this amazing technology(mosh) will be available for huge
>> user base for free!
>>
>> I just wanted to share those news and say thank you for the job you’ve
>> done!
>>
>> Please let me know if you have any questions!
>>
>>
>> Kind Regards,
>> Roman Kudiyarov
>> Termius Team
>>
>> ___
>> mosh-devel mailing list
>> mosh-devel@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>
>>
>
>
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Termius + Mosh

[Keith Winstein]

Thanks for letting us know!

(1) Could you please describe the process you used to develop a clean-room
implementation of the Mosh protocol? Did you write up a protocol
specification based on the Mosh source code, and then have somebody else
implement the spec? If so, would you be willing to share the protocol spec?

(2) Is the source code of your implementation available?

(3) We've had bad experiences in the past with people (especially iSSH on
iOS) attempting to implement the Mosh protocol, but with imperfect results,
and users blaming Mosh for the problems. As with these past cases, please
don't refer to your implementation as "Mosh." Please refer to it as
"Termius mosh-compatible mode," with your own name first and
"mosh-compatible" instead of "Mosh".

Regards,
Keith

On Sun, Apr 30, 2017 at 3:34 PM, Roman Kudiyarov  wrote:

> Hi all!
>
>
> I’m a co-founder of Crystalnix. We work on Termius, cross-platform SSH
> client (iOS, Android, Mac, Windows, Linux and Chrome). Now we have around
> 200K of monthly users! Our team aims to redesign command line UX from
> scratch. Your team has done an amazing job with the mosh protocol which was
> one of the most desired features that our users have been asking for.
>
> We had to develop our own mosh client(completely different code-base) due
> to the license restrictions. Anyway our code is fully compatible with the
> current version of the mosh server. Very shortly we are launching beta for
> Android and then will roll out to other platforms as well.
>
> That means that this amazing technology(mosh) will be available for huge
> user base for free!
>
> I just wanted to share those news and say thank you for the job you’ve
> done!
>
> Please let me know if you have any questions!
>
>
> Kind Regards,
> Roman Kudiyarov
> Termius Team
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.3.0 released (corrected announcement)

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mosh users and developers,

mosh 1.3.0 has been released. (This is a corrected release announcement
that fixes a typo in the previous email.)

The source code is at: https://mosh.org/mosh-1.3.0.tar.gz
(SHA-256: 320e12f461e55d71566597976bd9440ba6c5265fa68fbf614c6f1c8401f93376)

John Hood was the primary developer and release coordinator and
deserves all our thanks.

Change in version numbering: We have switched our version numbering to
follow the semver.org recommendations. Mosh will increment the minor
version number any time we add new functionality. (In our previous
practice, this release would probably have been called "1.2.7".)

Compatibility: mosh 1.3.0 is backwards-compatible with mosh-clients
back to 0.96 and mosh-servers back to 1.0.9.

macOS binary package: We are releasing a macOS binary package.

https://mosh.org/mosh-1.3.0.pkg is an amd64 build for 10.10 and later.
(SHA-256: a423fcb5aab7079e20b03cfa5e8623bb89391087dd5492d68947c89a39eee80c)

However, we encourage macOS users to install via MacPorts or Homebrew,
instead of using the binary package, in order to receive automatic upgrades.

Bugs: Please let us know of any problems at the GitHub issue tracker,
at https://github.com/mobile-shell/mosh/issues. The developers can
also be found on IRC at .

The full change log for this release:

===

* New features:
  * Change website URLs from http://mosh.mit.edu to https://mosh.org.
    (Keith Winstein)
  * Add --no-ssh-pty option for Dropbear compatibility and other issues.
  * Switch to semantic versioning, making this version 1.3.0 instead
of 1.2.7.

* Platform support:
  * Added nonce-incrementing test.  (Keith Winstein)
  * Add build-source-package.sh for Debian.  (Keith Winstein)
  * Fix CPPFLAGS handling possibly causing curses detection failure.
(John Hood)
  * Add an Appveyor/Cygwin CI build.
  * Improve warning-flags detection for 'make distcheck'.  (John Hood)
  * Improve robustness of regression tests.  (John Hood)
  * Support OpenBSD pledge() sandboxing.  (John Hood)
  * Use backward-compatible name for AES in AppleCommonCrypto, fixing
builds with older OS X SDKs.  (John Hood)
  * Detect clock_gettime() and CLOCK_MONOTONIC carefully, fixing
OS X 10.12 + Xcode 7.3 builds.  (John Hood)
  * Support older versions of Perl, back to 5.10, fixing RHEL 5 builds.
(Anders Kaseorg)
  * Add a Travis OS X CI and release build.  (John Hood)
  * Add --help and --version, enabling Automake's 'std-options' checks.
(Anders Kaseorg)
  * Add a simple smoke test not requiring tmux, to help validate builds
on older platforms including RHEL 5. (Anders Kaseorg)
  * Check for presence of clock_gettime() for OS X, where the symbol
may not be resolved on older OS X versions.  (John Hood)
  * Fix a memory alignment issue in OCB with ARM/Neon. (Carlos Cabanero)
  * Mosh now runs correctly on Bash for Windows with Windows 10 Insider
builds 15002 and higher. (No change in Mosh)
  * Other minor platform compatibility fixes for Mosh sources and tests.
(John Hood)

* Bug fixes:
  * Work around a pty buffering issue causing failed connections on
FreeBSD 11, or with Dropbear.  (John Hood)
  * Restore '-p 0' option for OS-selected UDP port bindings.  (John Hood)
  * Shell hygiene fixes, including better quoting of pathnames.
(Anders Kaseorg)
  * Fix typos in project docs.  (Jakub Wilk)
  * Fix excess newlines on mosh client startup/shutdown.  (John Hood)
  * Exit gracefully, closing session, on pty write or ioctl failure.
(John Hood)
  * Fix two bugs that caused mosh-server to consume excessive CPU in
certain circumstances.  (John Hood)
  * Fix bug that caused text copied from mosh-client to paste as long
lines joined by spaces.  (John Hood)
  * Documentation improvements. (chenxiaoqino, Ashish Gupta)
  * Use getuid(), not geteuid(), for correct getpw* lookups.  (John Hood)

===

Best regards on behalf of the Mosh team,
Keith Winstein
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJY2BwOAAoJECC3KDr+JUxpsV8P/3Wd7fEzxNpxXJN7QaeFpGrS
70KtHzXuxXg50tn9E+UQVTkg4rXVh72q6vElsVWCmsWlpzquCDRCpEZeWySmQxjQ
MnN2tzrMYZBOEaPTV2xeLKPgRTLcDSMpw/bJEdyDs33LSpFk05fZIQHZOtL/0REq
NjHYuvzmcNGP7aydWmkQyu1Vtpjk4urORnwsYdQ5JLt21AcJsD+GpdjPdQfaEJIU
ZZ/haXZ9bvJBUzS2h0ZvJSpwHsZ1dIK4RZR5sSrtOmiIK7oEgK1KsidOriRyNEhX
ORhc+kQspuncDsGDNTUPtI8PrqvrnVNSq6nvi0I1JVGqfUbwxpK+2j7t8rDFkYx/
y9s9VkcE+cvm0JaJOhnVVZQn8BK5ztDsUVYkHrg48l3DmMQDaEujaNzASAx8aJRW
WRzUowM41R5GG1EQ1tXFLH2igI2VRF9uUyIAHwHInUMHbrQQC3I1SgKod9xwdOVv
HghszMDFlh8A9+80zzf46vYpMcGuqZWyv+AMAbYP0XF9cDFTZOeOP/t84CddRVda
A5jJl9gc57Z0hWdBOIDl02yMMCmn3hibDchz3jlJATTGMycIqRcIA3n/9HBtDoa0
4NOzbJvZxtQxHnulGX53hD9fnr3pvvYxX5POkVaFtKB3wJpUbScTAV8BjivM+EYV
yaQLE4qz9HGLDv9bU2FZ
=DJjX
-END PGP SIGNATURE-
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.3.0 released

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mosh users and developers,

mosh 1.3.0 has been released.

The source code is at: https://mosh.org/mosh-1.3.0.tar.gz
(SHA-256: 320e12f461e55d71566597976bd9440ba6c5265fa68fbf614c6f1c8401f93376)

John Hood was the primary developer and release coordinator and
deserves all our thanks.

Change in version numbering: We have switched our version numbering to
follow the semver.org recommendations. Mosh will increment the minor
version number any time we add new functionality. (In our previous
practice, this release would probably have been called "1.2.7".)

Compatibility: mosh 1.2.7 is backwards-compatible with mosh-clients
back to 0.96 and mosh-servers back to 1.0.9.

macOS binary package: We are releasing a macOS binary package.

https://mosh.org/mosh-1.3.0.pkg is an amd64 build for 10.10 and later.
(SHA-256: a423fcb5aab7079e20b03cfa5e8623bb89391087dd5492d68947c89a39eee80c)

However, we encourage macOS users to install via MacPorts or Homebrew,
instead of using the binary package, in order to receive automatic upgrades.

Bugs: Please let us know of any problems at the GitHub issue tracker,
at https://github.com/mobile-shell/mosh/issues. The developers can
also be found on IRC at .

The full change log for this release:

===

* New features:
  * Change website URLs from http://mosh.mit.edu to https://mosh.org.
    (Keith Winstein)
  * Add --no-ssh-pty option for Dropbear compatibility and other issues.
  * Switch to semantic versioning, making this version 1.3.0 instead
of 1.2.7.

* Platform support:
  * Added nonce-incrementing test.  (Keith Winstein)
  * Add build-source-package.sh for Debian.  (Keith Winstein)
  * Fix CPPFLAGS handling possibly causing curses detection failure.
(John Hood)
  * Add an Appveyor/Cygwin CI build.
  * Improve warning-flags detection for 'make distcheck'.  (John Hood)
  * Improve robustness of regression tests.  (John Hood)
  * Support OpenBSD pledge() sandboxing.  (John Hood)
  * Use backward-compatible name for AES in AppleCommonCrypto, fixing
builds with older OS X SDKs.  (John Hood)
  * Detect clock_gettime() and CLOCK_MONOTONIC carefully, fixing
OS X 10.12 + Xcode 7.3 builds.  (John Hood)
  * Support older versions of Perl, back to 5.10, fixing RHEL 5 builds.
(Anders Kaseorg)
  * Add a Travis OS X CI and release build.  (John Hood)
  * Add --help and --version, enabling Automake's 'std-options' checks.
(Anders Kaseorg)
  * Add a simple smoke test not requiring tmux, to help validate builds
on older platforms including RHEL 5. (Anders Kaseorg)
  * Check for presence of clock_gettime() for OS X, where the symbol
may not be resolved on older OS X versions.  (John Hood)
  * Fix a memory alignment issue in OCB with ARM/Neon. (Carlos Cabanero)
  * Mosh now runs correctly on Bash for Windows with Windows 10 Insider
builds 15002 and higher. (No change in Mosh)
  * Other minor platform compatibility fixes for Mosh sources and tests.
(John Hood)

* Bug fixes:
  * Work around a pty buffering issue causing failed connections on
FreeBSD 11, or with Dropbear.  (John Hood)
  * Restore '-p 0' option for OS-selected UDP port bindings.  (John Hood)
  * Shell hygiene fixes, including better quoting of pathnames.
(Anders Kaseorg)
  * Fix typos in project docs.  (Jakub Wilk)
  * Fix excess newlines on mosh client startup/shutdown.  (John Hood)
  * Exit gracefully, closing session, on pty write or ioctl failure.
(John Hood)
  * Fix two bugs that caused mosh-server to consume excessive CPU in
certain circumstances.  (John Hood)
  * Fix bug that caused text copied from mosh-client to paste as long
lines joined by spaces.  (John Hood)
  * Documentation improvements. (chenxiaoqino, Ashish Gupta)
  * Use getuid(), not geteuid(), for correct getpw* lookups.  (John Hood)

===

Best regards on behalf of the Mosh team,
Keith Winstein
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJY2BbpAAoJECC3KDr+JUxpr84P/jwB9rBN02fKTH6loSIHmncJ
UCQXElDDiIwSIMiQkAvQmhD7r+Rw7fuaILOp1qKBkCqH0g7HGwLOesnnvCPsYVR3
fm33+IPo7TAHZ10KuLGbb87gw8XZxelVfRu2B4ZCtu4baItWbTtzehCDF6+sTaFy
o4aDtf9QHIHq4lioHH22ShMmBvb8gLPJeKPtNk/1BMHhgVEICikaSTNdmskeCH+r
FqGeV4pa/sQMd1CBZTla3tXUsc0IR8aTyrRiaWSVcO6xKnThcoa3cj0Kch0aWFME
uXkv4/AKImqk3uzI97QkzVg9HPWdOl0CqaWpKmp7SzH8n+MYRXRc3N+sekmxRkm4
GsmijAi/AuOL3y1cpZs3SRqszg1Y8DApRrTEpjeTrzKfMYUfextMjBYPqI8Fitlu
8VncldsFqi5OLkiOFJj3E+zu1AbInYk1SG4O639wGTOEhITybt1glMt2m+MPlL+H
tVUhJPapg0KXTpw95SmWKhooo4/h9bS9YGqTyKV4FZQwWNv9LqXaszi/aVBIoNFg
R/ADhu8y7UsMdcOlKEHnDMKbAZDzCIH3wSl0sIU/tXsRckGUUNk06T5dV0kOyKPa
WdOVO8mqFo1358PIKIMZv7xzaJ+UcMW45FcsSk5T2giGwAtfroI56+3AEGx/5O6G
4woaPpzc7Uz7xUBJAhb9
=q7Jk
-END PGP SIGNATURE-
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh and utmp on athena.dialup.mit.edu

[Keith Winstein]

Hello Lizhou,

Sigh, these should probably not be the same sysname, but I guess that ship
has probably sailed. I reverted to a statically-linked binary, but still
compiled on Athena. utempter seems to be still working on athena.dialup.

-Keith

On Fri, Feb 24, 2017 at 2:23 PM, Lizhou Sha  wrote:

> Hi Keith,
>
> I'm observing a regression for my self-deployed Ubuntu 16.04 dialup
> with regards to libprotobuf linkage:
>
> $ mosh --ssh="ssh -K" --server="athrun mosh_project mosh-server"
> sha.mit.edu -- byobu a -d
> /afs/sipb.mit.edu/project/mosh/arch/amd64_deb60/bin/mosh-server.real:
> error while loading shared libraries: libprotobuf.so.8: cannot open
> shared object file: No such file or directory
> Connection to sha.mit.edu closed.
> /usr/bin/mosh: Did not find mosh server startup message.
>
> Best,
> Lizhou
>
> On Fri, Feb 24, 2017 at 4:39 PM, Keith Winstein 
> wrote:
> > Hello Jonathon,
> >
> > I deployed a new build of mosh-server for amd64 architectures (compiled
> on
> > test.dialup) in the mosh_project locker. It seems to be updating utmp
> now.
> > Please let me know if you see any trouble.
> >
> > -Keith
> >
> > On Fri, Feb 24, 2017 at 1:17 PM, Jonathon Weiss  wrote:
> >>
> >> Hi Keith,
> >>
> >> libutempter-dev is now installed on test.dialup.mit.edu.  It should hit
> >> the production dialups over the course of next week, but doing your
> >> build on test.dialup.mit.edu should be fine.  thanks for the help.
> >>
> >> Jonathon
> >>
> >>
> >>
> >> Keith Winstein  wrote:
> >>
> >> > Hello Jonathon,
> >> >
> >> > I investigated and it's probably my fault -- I'm compiling and
> >> > statically
> >> > linking on an Ubuntu system that expects it
> >> > in /usr/lib/x86_64-linux-gnu/utempter/utempter, and athena.dialup
> has it
> >> > in /usr/lib/utempter/utempter.
> >> >
> >> > Could you please install libutempter-dev on the dialups? Then I can
> >> > compile
> >> > on Athena, and my guess is it will start working again. (Or I can spin
> >> > up a
> >> > VM that more closely matches the dialups if necessary.)
> >> >
> >> > (Anton, this is a bit of a special case as I am the one who is
> building
> >> > and
> >> > installing Mosh at MIT -- we use this to test release candidates.)
> >> >
> >> > Regards,
> >> > Keith
> >> >
> >> > On Thu, Feb 23, 2017 at 2:50 PM, Jonathon Weiss 
> wrote:
> >> >
> >> > >
> >> > > Hello all,
> >> > >
> >> > > Following up on a zephyr conversation I had with Keith and others
> >> > > about a week ago, I was wondering why mosh logins don't appear in
> the
> >> > > output of "who" or "w" on the athena.dialup.mit.edu servers.  We
> got
> >> > > as far as confirming that utempter was setgid utmp:
> >> > >
> >> > > -rwxr-sr-x 1 root utmp 10104 Oct  5  2012 /usr/lib/utempter/utempter
> >> > >
> >> > > oh, these files also appear to me ot have reasonable permissions:
> >> > >
> >> > > -rw-rw-r-- 1 root utmp 190080 Feb 23 17:47 /var/run/utmp
> >> > >
> >> > > -rw-rw-r-- 1 root utmp 2704128 Feb 23 17:45 /var/log/wtmp
> >> > >
> >> > > -rw-rw 1 root utmp 992640 Feb 23 17:25 /var/log/btmp
> >> > >
> >> > > Anything you can suggest to check?  Anyhting I can do to help debug?
> >> > >
> >> > > Jonathon
> >> > >
> >> > > Jonathon Weiss 
> >> > > MIT/IS&T/Infrastructure Design & Engineering
> >> > > Cloud Platforms (Server Operations)
> >> > > ___
> >> > > mosh-devel mailing list
> >> > > mosh-devel@mit.edu
> >> > > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> >> > >
> >> >
> >> > 
> >> > Alternatives:
> >> >
> >> > 
> >>
> >
> >
> > ___
> > mosh-devel mailing list
> > mosh-devel@mit.edu
> > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> >
>
>
>
> --
> Lizhou Sha
> Massachusetts Institute of Technology
> Department of Physics
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh and utmp on athena.dialup.mit.edu

[Keith Winstein]

Hello Jonathon,

I deployed a new build of mosh-server for amd64 architectures (compiled on
test.dialup) in the mosh_project locker. It seems to be updating utmp now.
Please let me know if you see any trouble.

-Keith

On Fri, Feb 24, 2017 at 1:17 PM, Jonathon Weiss  wrote:

> Hi Keith,
>
> libutempter-dev is now installed on test.dialup.mit.edu.  It should hit
> the production dialups over the course of next week, but doing your
> build on test.dialup.mit.edu should be fine.  thanks for the help.
>
> Jonathon
>
>
>
> Keith Winstein  wrote:
>
> > Hello Jonathon,
> >
> > I investigated and it's probably my fault -- I'm compiling and statically
> > linking on an Ubuntu system that expects it
> > in /usr/lib/x86_64-linux-gnu/utempter/utempter, and athena.dialup has it
> > in /usr/lib/utempter/utempter.
> >
> > Could you please install libutempter-dev on the dialups? Then I can
> compile
> > on Athena, and my guess is it will start working again. (Or I can spin
> up a
> > VM that more closely matches the dialups if necessary.)
> >
> > (Anton, this is a bit of a special case as I am the one who is building
> and
> > installing Mosh at MIT -- we use this to test release candidates.)
> >
> > Regards,
> > Keith
> >
> > On Thu, Feb 23, 2017 at 2:50 PM, Jonathon Weiss  wrote:
> >
> > >
> > > Hello all,
> > >
> > > Following up on a zephyr conversation I had with Keith and others
> > > about a week ago, I was wondering why mosh logins don't appear in the
> > > output of "who" or "w" on the athena.dialup.mit.edu servers.  We got
> > > as far as confirming that utempter was setgid utmp:
> > >
> > > -rwxr-sr-x 1 root utmp 10104 Oct  5  2012 /usr/lib/utempter/utempter
> > >
> > > oh, these files also appear to me ot have reasonable permissions:
> > >
> > > -rw-rw-r-- 1 root utmp 190080 Feb 23 17:47 /var/run/utmp
> > >
> > > -rw-rw-r-- 1 root utmp 2704128 Feb 23 17:45 /var/log/wtmp
> > >
> > > -rw-rw 1 root utmp 992640 Feb 23 17:25 /var/log/btmp
> > >
> > > Anything you can suggest to check?  Anyhting I can do to help debug?
> > >
> > > Jonathon
> > >
> > > Jonathon Weiss 
> > > MIT/IS&T/Infrastructure Design & Engineering
> > > Cloud Platforms (Server Operations)
> > > ___
> > > mosh-devel mailing list
> > > mosh-devel@mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> > >
> >
> > 
> > Alternatives:
> >
> > 
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh and utmp on athena.dialup.mit.edu

[Keith Winstein]

Hello Jonathon,

I investigated and it's probably my fault -- I'm compiling and statically
linking on an Ubuntu system that expects it
in /usr/lib/x86_64-linux-gnu/utempter/utempter, and athena.dialup has it
in /usr/lib/utempter/utempter.

Could you please install libutempter-dev on the dialups? Then I can compile
on Athena, and my guess is it will start working again. (Or I can spin up a
VM that more closely matches the dialups if necessary.)

(Anton, this is a bit of a special case as I am the one who is building and
installing Mosh at MIT -- we use this to test release candidates.)

Regards,
Keith

On Thu, Feb 23, 2017 at 2:50 PM, Jonathon Weiss  wrote:

>
> Hello all,
>
> Following up on a zephyr conversation I had with Keith and others
> about a week ago, I was wondering why mosh logins don't appear in the
> output of "who" or "w" on the athena.dialup.mit.edu servers.  We got
> as far as confirming that utempter was setgid utmp:
>
> -rwxr-sr-x 1 root utmp 10104 Oct  5  2012 /usr/lib/utempter/utempter
>
> oh, these files also appear to me ot have reasonable permissions:
>
> -rw-rw-r-- 1 root utmp 190080 Feb 23 17:47 /var/run/utmp
>
> -rw-rw-r-- 1 root utmp 2704128 Feb 23 17:45 /var/log/wtmp
>
> -rw-rw 1 root utmp 992640 Feb 23 17:25 /var/log/btmp
>
> Anything you can suggest to check?  Anyhting I can do to help debug?
>
> Jonathon
>
> Jonathon Weiss 
> MIT/IS&T/Infrastructure Design & Engineering
> Cloud Platforms (Server Operations)
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] snap package for mosh

[Keith Winstein]

Thanks, Leo. Do you already have snaps for similar programs (e.g. screen,
tmux, ssh)? Mosh is probably going to have similar needs to those re: the
isolation or "plugs".

Generally we add new platforms/distros when somebody submits a PR or
volunteers to be a maintainer; my suggestion is for you to just submit a PR
with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate)
and we can all try it out.

Cheers,
Keith

On Fri, Jan 13, 2017 at 7:56 AM, Leo Arias  wrote:

> On Thu, Jan 12, 2017 at 11:59:53PM -0800, Keith Winstein wrote:
> > Right now we have a Debian package, which we maintain in our own source
> > tree, and which we upload to Debian every time there's a new release.
> That
> > flows into Ubuntu as part of the normal release schedule. For users who
> > want something more immediate, we also have the mosh-dev PPA that pulls
> > from our GitHub repository once a day and auto-builds the Ubuntu source
> and
> > binary packages, and then we have a "stable" mosh PPA as well, which only
> > gets updated on new releases.
>
> That is great because we would love to hear your impressions, taking into
> account your experience with debs and PPAs.
>
> In classic Ubuntu you have to follow our 2 years/6 months release cycle,
> or use
> a PPA. When you release a deb to an LTS, you will quickly get many users
> in an
> outdated version for many years, you need maintainers to review your
> package to
> make sure it's compatible with the archive, and you need to follow a
> heavy-weight format full of conventions and rules to make the archive
> consistent. debs are great for some projects and some users, and we are
> using
> them as a base for our new Ubuntu Core distro; but something like getting
> the
> mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.
>
> That's what we are trying to improve with this new dev experience. Snaps
> are
> mounted read-only directly from the uncompressed package and they bundle
> all
> their dependencies. So there is no conflict between snaps, nor with the
> base
> system, and then we can get out of your way, you don't need the distro as a
> middle man and you can just push to the store any version you want, any
> time
> you want.
>
> Snaps are also isolated to their sandbox for security reasons. But there's
> where things get interesting with mosh...
>
> > Is it possible to teach Launchpad to also auto-build a snap once a day
> (if
> > our Git repo has changed), alongside the PPA .debs? Can we script
> Travis-CI
> > to automatically build and push a snap each time it runs a successful CI
> > test on the master branch? Or how would you recommend we do this?
>
> Yes, we want the snapcraft.yaml metadata to be as simple as possible, and
> to
> use continuous deployment, so you will just have to spend a little time
> packaging one time, and then everything is automatic. You can take a look
> here:
> http://snapcraft.io/docs/build-snaps/ci-integration
>
> > Mosh is pretty simple so I doubt we're going to be pushing the boundaries
> > of the snap format -- it's basically two unprivileged binaries and some
> man
> > pages. And a bash-completion script that gets put
> > in /usr/share/bash-completion/completions/mosh. I guess that might be a
> > little more interesting, depending on whether snap can handle that.
>
> If I understand correctly, the mosh server is a terminal emulator. (I'm not
> sure about mosh internals, so I'm eager to understand more about that too
> :)
> By default, snaps can't do anything outside of their confinement, so things
> like calling binaries they don't provide or accessing devices will be
> blocked.
> And that's good enough for the vast majority of applications out there,
> they
> just declare a few "plugs", like listening to the network, and they can
> fully
> function. But now we are turning our eyes to also support developer tools,
> like
> emacs which needs to be able to read and write to /etc, or a shell like
> zsh, or
> mosh.
> They pose a bigger security risk than normal apps, but still we think it
> should
> be a direct agreement between the user and the developers distributing that
> package. So you would declare on your snap the kind of things that your
> application will do out of its confinement, and the user decides to grant
> that
> permission or not.
>
> > Happy to work with you on this if you think there is user demand for it.
>
> Well, I'm sure it will make it easier for you to do early testing of the
> new
> release, and once you are ready to release to the stable channel, many of
> your
> use

Re: [mosh-devel] snap package for mosh

[Keith Winstein]

Hello Leo,

Thanks for getting in touch, and thanks for your kind words about mosh!

Right now we have a Debian package, which we maintain in our own source
tree, and which we upload to Debian every time there's a new release. That
flows into Ubuntu as part of the normal release schedule. For users who
want something more immediate, we also have the mosh-dev PPA that pulls
from our GitHub repository once a day and auto-builds the Ubuntu source and
binary packages, and then we have a "stable" mosh PPA as well, which only
gets updated on new releases.

Is it possible to teach Launchpad to also auto-build a snap once a day (if
our Git repo has changed), alongside the PPA .debs? Can we script Travis-CI
to automatically build and push a snap each time it runs a successful CI
test on the master branch? Or how would you recommend we do this?

Mosh is pretty simple so I doubt we're going to be pushing the boundaries
of the snap format -- it's basically two unprivileged binaries and some man
pages. And a bash-completion script that gets put
in /usr/share/bash-completion/completions/mosh. I guess that might be a
little more interesting, depending on whether snap can handle that.

Happy to work with you on this if you think there is user demand for it.

Cheers,
Keith

On Thu, Jan 12, 2017 at 10:00 AM, Leo Arias  wrote:

> Hello!
>
> I’m Leo. I work as part of the engineering team around Ubuntu and
> Snapcraft [1].
>
> Last year I found about mosh, and it has been the most amazing experience.
> It
> solves most of the problems due to my unstable latin american internet
> connection; so first, let me say thank you very much!
>
> I was reading about your new candidate release, and I thought that this
> might be
> interesting for you. We’re working on snaps, a platform to enable
> developers to
> directly control delivery of software updates to their users, and make
> their
> software available in a secure way, with automatic updates in different
> channels.
>
> The channels are particularly relevant when trying to release new
> versions, and
> solve an old problem we had with Ubuntu. Instead of having a 6 month cycle
> for
> everybody, you can push different versions whenever you want. So you could
> push
> a new version to the edge channel every time something lands on your
> repository,
> to get extreme early feedback from your contributors. When you make a
> freeze to
> stabilize for the release, you can push that to the beta channel. And when
> you
> are ready to release but want to give it to a greater audience for the
> final
> checks, you can push to the candidate channel. When everybody is happy
> with the
> release, it can be pushed to the stable channel. Your users just decide the
> level of risk they want to take, and they will constantly receive updates
> when
> you push something new.
>
> I this sounds like a good fit for your project, I would love to work with
> you
> making the snap. I'm particularly interested in the feedback that you can
> give
> us about a few new features that might be useful for mosh.
>
> pura vida.
>
> [1] http://snapcraft.io/
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] Fwd: Gratitude

[Keith Winstein]

Some nice feedback!

-- Forwarded message --
From: Vitalii Tolstonogov 
Date: Sat, Nov 26, 2016 at 4:00 PM
Subject: Gratitude
To: kei...@cs.stanford.edu

I am Head of IT Bureau at National Nuclear Energy Generating Company
"Energoatom", which generates more than 50% of electricity in Ukraine and
operates 15 nuclear reactors.

Thank you for Mosh. It helps a lot every day.
Thanks to you and to all the developers of this wonderful tool.

--
best regards,
Vitalii V. Tolstonogov
IT Architect
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Persistent Connections

[Keith Winstein]

Hello Carlos,

Sounds cool! I think you will need to save every state newer than the
"throwaway number," because the other side is allowed to reference that
state (or any newer state that you have acked) in building a new diff.

My main fear with these saved states is that a user would somehow be able
to try "resuming" the same session twice, from the same save file. That
will result in the same sequence number being reused, which would be
cryptographically catastrophic. So any implementation that allows
"resuming" from a saved state must ensure that the saved state is destroyed
as part of the resumption.

-Keith

On Wed, Nov 9, 2016 at 3:14 PM, Carlos Cabanero 
wrote:

> I have started to work on “Persistent Connections” for Blink with great
> success! For background, these are the related GH issues (
> https://github.com/mobile-shell/mosh/issues/394) and (
> https://github.com/blinksh/blink/issues/59).
>
>
> I hacked together - as in I have hardcoded most of the stuff - a simple
> version that is able to save a session to disk and reconstruct it given the
> previous key. Turns out it was all a lot easier than I thought, without
> requiring hardcore object serialisation. States (timestamp, sequence nonce
> and content) can be dropped to disk as if they were going to be sent over
> the network, and reconstructing the states to the initial
> Terminal::Complete and Network::UserStream objects is straightforward with
> the diff functions.
>
>
> There is the question of how many states should be saved, from reading the
> code I guess the answer is all of them, from my test only the latest acked
> one was enough - but again, crappy test.
>
>
> Another obvious security concern as the states contain information from
> the terminal in a completely readable format. Could that be encrypted again
> with the key before saving? In the case of iOS I can save the secure key to
> the keychain. But I think that on top of that, saving the session with a
> Passphrase might be a good idea.
>
>
> I understand that this might only be useful in Blink, but any guidance
> would be appreciated. In the same manner, if you change your opinion, I'm
> more than happy to walk the extra mile and make it work for everyone.
>
>
> Thanks a lot!!
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh-devel anti-spam changes (moderating posts from non-members)

[Keith Winstein]

Hello Mosh developers,

Historically, mosh-devel has been our public contact address (and gets a
lot of spam), while mosh-users has been restricted to "members-only"
posting.

A lot of people want to be on mosh-devel but don't like spam, so I just
changed mosh-devel to "Hold" non-member posts for moderation. John Hood and
Andrew Chin will be the moderators.

I hope this solves the spam problem. As always, you can join the mosh-devel
list if you don't want to be moderated, or keep yourself just on mosh-users
if you don't want the burden of messages from the random public.

Cheers all,
Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Getting mosh page update

[Keith Winstein]

Thanks for this -- the website is maintained at
https://github.com/mobile-shell/moshweb . If you can submit a pull
request on GitHub that adds OpenIndiana, I expect we can take it. It
could go right next to OpenCSW.

Cheers,
Keith

On Tue, Aug 16, 2016 at 2:54 AM, Predrag Zečević - Unix Systems
Administrator  wrote:
> Hi all,
>
> hope this is proper address... Can you add to https://mosh.org/#getting
> page following info:
>
> ---8<---
> For OpenIndiana (hipster distribution) use command:
>
> $ pfexec pkg install -v mosh
> ---8<---
>
> Project home page: https://www.openindiana.org/
> Repository:
> https://pkg.openindiana.org/hipster/en/search.shtml?token=mosh&action=Search
>
> With best regards.
> Predrag Zečević
> --
> Predrag Zečević
> Technical Support Analyst
> 2e Systems GmbH
>
> Telephone: +49 6196 9505 815, Facsimile: +49 6196 9505 894
> Mobile:+49 174 3109 288, Skype: predrag.zecevic
> E-mail:predrag.zece...@2e-systems.com
>
> Headquarter:  2e Systems GmbH, Königsteiner Str. 87,
>65812 Bad Soden am Taunus, Germany
> Company registration: Amtsgericht Königstein (Germany), HRB 7303
> Managing director:Phil Douglas
>
> http://www.2e-systems.com/ - Making your business fly!
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel

___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] "debian-package" branch out of date?

[Keith Winstein]

Thanks for pointing this out, Axel. I just renamed this branch
"debian-1.2.5" to reflect its real purpose (updates to the Debian
1.2.5 package). The fix that was in the 1.2.5-2 package (for the glibc
2.22 crashing issue) is now upstream in 1.2.6.

Best regards,
Keith

On Fri, Aug 12, 2016 at 12:25 AM, Axel Beckert  wrote:
> Hi,
>
> I just wanted to file a pull request for what Keith fixed at the same
> time in
> https://github.com/mobile-shell/mosh/commit/ca2750dd036c133953839d59a30197983dee668a
>
> During that I noticed that the Debian packaging seems uptodate in the
> master branch, but outdated in the "debian-package" branch.
>
> Is the "debian-package" branch no more used? If so, maybe it should be 
> removed or
> renamed?
>
> Kind regards, Axel
> --
> /~\  Plain Text Ribbon Campaign   | Axel Beckert
> \ /  Say No to HTML in E-Mail and News| a...@deuxchevaux.org  
> (Mail)
>  X   See http://www.nonhtmlmail.org/campaign.html | a...@noone.org 
> (Mail+Jabber)
> / \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ 
> (Web)
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.2.6 released

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Mosh users and developers,

mosh 1.2.6 has been released.

The source code is at: https://mosh.org/mosh-1.2.6.tar.gz
(SHA-256: 7e82b7fbfcc698c70f5843bb960dadb8e7bd7ac1d4d2151c9d979372ea850e85)

John Hood was the release coordinator and deserves all of our thanks.
Major new features, all due to John, include:

- - huge performance improvements, especially on large terminals,
- - the ability to set a timeout to end dormant sessions automatically, and
- - support for crypto libraries other than OpenSSL (Nettle and
  Apple Common Crypto).

On the developer side, we now have an end-to-end test suite and
continuous-integration tests on every pull request. We also worked
around a bad interaction with glibc 2.22 that caused mosh-server to
crash on startup.

Compatibility: mosh 1.2.6 is backwards-compatible with mosh-clients
back to 0.96 and mosh-servers back to 1.0.9.

macOS binary package: We are releasing a macOS binary package.

https://mosh.org/mosh-1.2.6.pkg is an i386+amd64 build for 10.9 and later.
(SHA-256: 5eb7797b0c3a5423da1c62f80f8e6268acd55b1b10a850e58fd7bb8f6bdb520d)

However, we encourage macOS users to install via MacPorts or Homebrew,
instead of using the binary package, in order to receive automatic upgrades.

Bugs: Please let us know of any problems at the GitHub issue tracker,
at https://github.com/mobile-shell/mosh/issues. The developers can
also be found on IRC at .

Website moves: Please note that the Mosh repository has moved to
https://github.com/mobile-shell/mosh (from https://github.com/keithw/mosh).
The Mosh website has moved to https://mosh.org (from https://mosh.mit.edu).

The full change log for this release:

* New features:
* Add Travis CI builds for Linux and Mac.  (Anders
  Kaseorg, others)
* Add a --local option to run without ssh.  (John Hood)
* Mosh now returns exitstatus reflecting connection success.
  (John Hood)
* Add a end-to-end test suite and many tests.  (John Hood)
* Implement timeouts and signals to help address
  orphaned sessions.  (John Hood)
* Major rework of Mosh's display
  differencing/rendering code with much improved
  performance for slow machines.  (John Hood)
* Implement ANSI back/forward tab (CSI CBT, CSI CHT).
  (John Hood)
* Do not start user shell until network session starts.
  (John Hood)
* Add options for more flexible specification of IPv4/IPv6
  hostname resolution.  (John Hood)
* Improved bash completion.  (Steve Dignam, HIGUCHI Yuta)
* Add options for different methods of resolving the
  remote host address, allowing operation without
  SshProxyCommand.  (John Hood)

* Platform support:
* Add configurable support for Apple Common Crypto and
  Nettle, in place of OpenSSL.  Implement base64 locally.
  (John Hood)
* Workaround Cygwin select() bug.  (John Hood)
* Updates to Debian packaging.  (Anders Kaseorg, Keith
  Winstein)
* Workaround a glibc-2.22 issue causing segfaults on
  Debian Sid.  (John Hood with help from many others)
* Prefer c++ to g++, for systems like FreeBSD where
  g++ is not usable.  (John Hood)
* Fixes for Illumos Hipster 20151003.  (John Hood)
* Disable -Werror for protobuf code, to resolve a new
  gcc6 warning.  (John Hood)
* Link test for -fstack-protector-all on an embedded
  platform.  (Baruch Siach)
* Resolve issue with bswap64() on FreeBSD-CURRENT with
  libc++-3.8.0.  (John Hood)
* Fix issue with RECVTOS error message on client on FreeBSD.
  (John Hood)

* Bug fixes:
* Remove an assertion causing aborts on Unicode
  fallback found by fuzzing with afl.  (Keith
  Winstein)
* Fix a server hang with XON/XOFF on BSD systems.
  (John Hood)
* Fix a typeahead-prediction bug that caused display
  corruption on urxvt.  (John Hood)

Best regards on behalf of the Mosh team,
Keith Winstein
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXrXMJAAoJECC3KDr+JUxp0TsP/0xLkHq3s1CP9CG68ymA5eb2
zNVnXJTlfwamgRoz39NmOp+9Ixgw4w1zXCKkg1vE0LhoZGXEbMhqxN6YDV2HSlWV
y1mTneiSc7FK1t6w71NQNIAHhN+sCM0pdA+eCrCj098Lx9l8zQnRrBXPhYMxcNkT
gGlQXOBe0e3to9EXLRINdRLhnsshkTRmeCnCs7LaH5mFzrkLn47gHSegdrCMj0uu
NRuII0eMw4ldNgsxaLGUcZp/Pud5HOwqOV18mTCIGP2leMnlkW5l8ViY0G9xdCJ0
JK7w4H

Re: [mosh-devel] Mosh 1.2.5-2 silently dying on ubuntu 16.04

[Keith Winstein]

I can't seem to replicate this using a fresh Amazon EC2 instance with
Ubuntu 16.04 LTS -- it works for me. :-(

It does look a lot like https://github.com/mobile-shell/mosh/issues/727 aka
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929, which we believe
to be fixed in the 1.2.5-2 package.

If you run "mosh-server" at the command line, what is the version output?
It should look something like "mosh-server (mosh 1.2.5) [build mosh 1.2.5]".

Can we also see the output of "which mosh-server" and "ldd
/usr/bin/mosh-server"?

Thanks,
Keith

On Wed, Jul 27, 2016 at 1:19 AM, Patrik Hirvinen 
wrote:

> As requested on IRC, output of mosh-server new -v
>
> > patrik@hirvinen:~⟫ mosh-server new -v -i 37.252.125.72 -p 60001:61000
> > MOSH CONNECT 60001 J0DaNHE4DY7Icic2RA8tJg
> > mosh-server (mosh 1.2.5) [build mosh
> > 1.2.5] Copyright 2012 Keith
> > Winstein 
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>.
> > This is free software: you are free to change and redistribute
> > it.  There is NO WARRANTY, to the extent permitted by law.
> >
> > [mosh-server detached, pid = 20937]
> Paste breaks somehow, this is immediately afterwards
> > patrik@hirvinen:~⟫ pgrep mosh
> "1" below is pgrep's exit status
> > 1 patrik@hirvinen:~⟫
>
> For context, paste from IRC:
> > 10:56 < Hirvinen> Hi! Just wanted to pop in to tell that on my Ubuntu
> > 16.04
> >   VPS, the version in default repositories (1.2.5-2) doesn't work.
> > "nothing
> >   received on 60001". Running mosh-server manually also exits
> > immediately, notafter 60 seconds. I can use nc to communicate on
> > UDP 60001. For me, this was
> >   fixed by upgrading to Ubuntu PPA version
> > 1.2.5.95rc1+1152-0ppa~ubuntu16.04.1
> >   . I'm not using sslh. Is this a known issue?
> > 10:56 < Hirvinen> If not, may I help by providing additional information?
>
> --
> Patrik Hirvinen
> patrik.hirvi...@iki.fi
> +358-(0)40-7186320
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Blink and Mosh changes released

[Keith Winstein]

Hello Carlos,

If the whole thing is GPL, that's great news! Re: lawyers, we had a good
experience dealing with the Software Freedom Law Center (softwarefreedom.org);
Aaron Williamson is the attorney who helped us draft the iOS waiver in the
first place. I'm guessing they may be able to help you as well.

Best regards,
Keith

On Wed, Jun 15, 2016 at 3:00 PM, Carlos Cabanero 
wrote:

> Thanks for your prompt response Keith. Hope this serves to clarify any
> possible issues, and please let me know if there are any things I might
> have missed:
>
> a) Everything in Blink is Open Source already. There are no and will be no
> parts kept proprietary. And it uses the same license as Mosh (GPL v3 with
> OpenSSL exception). This is the only way that Mosh could be actually used
> on iOS without building a separate implementation. My vision is that people
> see Blink just like a very small distro with a few embedded tools to work,
> and they basically trust this distribution.
> a') Other pieces that integrate Blink are also important for the license
> part, to avoid incompatibilities. These include: Libssh2 (BSD), OpenSSL,
> Protobufs (BSD), linenoise (BSD), HTerm (BSD) and Mosh (GPL v3 with OpenSSL
> and iOS exception). Also, icons are released under the CC by SA 4.0 which
> is one way compatible with GPL. Fonts will be downloadable online but the
> packaged ones will be OFL SIL, again GPL compatible. I think it is all
> good, but I'm in process to corroborate all of this with Open Source
> lawyers. If someone knows someone who could help I would appreciate that
> too :)
>
> b) The "interface" we are exporting (if it can be called like that as it
> is only a bridge to keep the code separate) is only mosh_main, which can be
> found in our iOS branch, the new file called terminalbridge.cc. It
> instances an iOSClient object (copy of STMClient, removing stdin and stdout
> to work with our custom streams).
>
>> int mosh_main(FILE *f_in, FILE *f_out, struct winsize *window_size,
>>
>>   const char *ip, const char *port, const char *key, const
>>> char *predict_mode)
>>
>>
> c) No other libraries are implementing the same interface. This is just a
> bridge for mosh. The reason why the GPL still applies is because we have to
> compile it as a static library. In theory, it would be possible to do a
> dynamic library since iOS 8, but really, I feel comfortable (and even
> relieved) with doing Blink GPL too.
>
> d) The other side to implement this interface, or the caller of the
> bridge, is our MoshSession class. This is Blink's mosh-client per se. Our
> Session objects try to act like a "Process" within a Thread and have a
> TerminalStream (with a "stdin", "stdout", "stderr", "windowsize", etc...),
> and a main function. You can see that in the code for Blink in
> Sessions/Session.m and Sessions/MoshSession.m. And then MoshSession for
> example calls SSHSession, etc... So yes, I tried to replicate the basis of
> a pipes and process system so that connecting other tools would be easy too
> (and linenoise for example was).
>
> And I think this is it. If anyone please see any issues or has any more
> questions, please shoot!
>
> Best
>
> On Wed, Jun 15, 2016 at 3:29 PM, Keith Winstein  wrote:
>
>> Thanks, Carlos, it will be very interesting to read through the code. I'm
>> trying to make sure I understand the licensing implications of what you're
>> planning to release on the App Store. Could you please describe:
>>
>> (a) Which parts of the overall Blink application are you planning to
>> release as open-source software, under which licenses? Which parts do you
>> intend to keep proprietary?
>>
>> (b) What is the interface that "Mosh as a library" exports? Is there
>> documentation on this interface?
>>
>> (c) What other libraries implement the same interface?
>>
>> (d) What are the programs that implement the other side of this interface?
>>
>> Best regards,
>> Keith
>>
>> On Wed, Jun 15, 2016 at 8:47 AM, Carlos Cabanero <
>> carlosecaban...@gmail.com> wrote:
>>
>>> Hi everyone!
>>>
>>>
>>> We’ve finally released Blink v 0.714, and most important, the code for
>>> it (https://github.com/blinksh/blink) and our Mosh changes (
>>> https://github.com/blinksh/mosh), including build scripts too (
>>> https://github.com/blinksh/build-mosh)
>>>
>>>
>>> First of all, I did not merge with latest version, changes will be
>>> required to our implementation anyway, as these were just to make sure the
>&g

Re: [mosh-devel] Blink and Mosh changes released

[Keith Winstein]

Thanks, Carlos, it will be very interesting to read through the code. I'm
trying to make sure I understand the licensing implications of what you're
planning to release on the App Store. Could you please describe:

(a) Which parts of the overall Blink application are you planning to
release as open-source software, under which licenses? Which parts do you
intend to keep proprietary?

(b) What is the interface that "Mosh as a library" exports? Is there
documentation on this interface?

(c) What other libraries implement the same interface?

(d) What are the programs that implement the other side of this interface?

Best regards,
Keith

On Wed, Jun 15, 2016 at 8:47 AM, Carlos Cabanero 
wrote:

> Hi everyone!
>
>
> We’ve finally released Blink v 0.714, and most important, the code for it (
> https://github.com/blinksh/blink) and our Mosh changes (
> https://github.com/blinksh/mosh), including build scripts too (
> https://github.com/blinksh/build-mosh)
>
>
> First of all, I did not merge with latest version, changes will be
> required to our implementation anyway, as these were just to make sure the
> project would be doable, and didn’t want to cover everything in a pile of
> new commits. I’ll be focusing on fixing bugs and provide you with nicer
> pull requests to Mosh during the next days. These are basically in two
> areas, but nothing too big:
>
>
>
>- Mosh as a library, with iOSClient as a subclass of STMClient and
>makefiles with BUILD_IOS_CONTROLLER flag.
>- Mosh multithreaded.
>
>
> There is also a straightforward bug with the socket (commit 8b21ee1), that
> we triggered because iOS always closes sockets when going to the
> background. I will submit that one straight to GH as could help make Mosh
> more stable in this corner cases.
>
>
> To keep it clean, I will start the conversation on those in a separate
> thread, and just keep this one for any issues related to Blink-Mosh
> licensing, attributions, or compatibilities we might have.
>
>
> Thanks a lot!! :)
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.6 release candidate available for testing

[Keith Winstein]

Thanks all who have tested the mosh 1.2.6 release candidate so far.

We're still looking for a postive ACK that somebody has successfully tested
the release candidate on:

- Fedora
- OS X binary .pkg (
https://github.com/mobile-shell/mosh/releases/download/untagged-0d43a0f73825e9952677/mosh-1.2.5.95rc1.pkg
)
- OS X compiling from source

Thanks all,
Keith

On Sun, Jun 5, 2016 at 8:39 PM, Richard Woodbury  wrote:

> I have confirmed that the RC builds and runs OK in Mosh for Chrome.
>
> On Thu, Jun 2, 2016 at 11:47 PM Richard Woodbury 
> wrote:
>
>> Hi, Keith. I don't have predictable time right now, but as I can, I'll
>> look into this for Mosh for Chrome. I did manage to do a quick "smoke test"
>> build, but I'm getting a bunch of protobuf link errors. I'll need to do
>> more investigation, which may include bringing in a newer NaCl SDK so I can
>> also get newer libraries from naclports. Hopefully I'll find time in the
>> next day or two.
>>
>> I can add that it builds OK on the Raspberry Pi (ARM, Raspbian), and the
>> performance improvement makes a *huge* difference! mosh-server used to
>> take most of the CPU for busy output or large window size and was notably
>> sluggish, depending on local echo to be usable. Now the CPU usage is in the
>> noise, and it responds wonderfully.
>>
>>
>> On Mon, May 30, 2016 at 3:34 AM Keith Winstein  wrote:
>>
>>> Hi folks,
>>>
>>> Could you please send in some positive testing reports on the Mosh 1.2.6
>>> release candidate?
>>>
>>> It would be great to have an independent "looks good" from at least the
>>> following platforms before we cut the release:
>>>
>>> - Fedora
>>> - the OS X binary .pkg
>>> - OS X compiling from source
>>> - OpenBSD
>>> - FreeBSD
>>> - NetBSD
>>> - Chrome
>>>
>>> Thanks,
>>> Keith
>>>
>>> On Wed, May 25, 2016 at 8:56 PM, john hood  wrote:
>>>
>>>> Hi all,
>>>>
>>>> We're happy to announce the upcoming release of Mosh 1.2.6, and are
>>>> calling for testing on Mosh 1.2.5.95rc1.  The release has picked up
>>>> some minor new features in the year since the last release such as
>>>> better IPv6 support and tools to handle orphaned sessions.  However,
>>>> it's also seen significant improvements in performance, testing, and
>>>> portability.
>>>>
>>>> The Changelog for this release:
>>>>
>>>>   * New features:
>>>> * Add Travis CI builds for Linux and Mac.  (Anders Kaseorg, others)
>>>> * Add a --local option to run without ssh.  (John Hood)
>>>> * Mosh now returns exitstatus reflecting connection success.
>>>>   (John Hood)
>>>> * Add a end-to-end test suite and many tests.  (John Hood)
>>>> * Implement timeouts and signals to help address orphaned sessions.
>>>>   (John Hood)
>>>> * Major rework of Mosh's display differencing/rendering
>>>>   code with much improved performance for slow machines.  (John
>>>> Hood)
>>>> * Implement ANSI back/forward tab (CSI CBT, CSI CHT).
>>>>   (John Hood)
>>>> * Do not start user shell until network session starts.
>>>>   (John Hood)
>>>> * Add options for more flexible specification of IPv4/IPv6
>>>>   hostname resolution.  (John Hood)
>>>> * Improved bash completion.  (Steve Dignam, HIGUCHI Yuta)
>>>> * Add options for different methods of resolving the remote host
>>>>   address, allowing operation without SshProxyCommand.  (John Hood)
>>>>
>>>>   * Platform support:
>>>> * Add configurable support for Apple Common Crypto and
>>>>   Nettle, in place of OpenSSL.  Implement base64 locally.
>>>>   (John Hood)
>>>> * Workaround Cygwin select() bug.  (John Hood)
>>>> * Updates to Debian packaging.  (Anders Kaseorg, Keith Winstein)
>>>> * Workaround a glibc-2.22 issue causing segfaults on Debian Sid.
>>>>   (John Hood with help from many others)
>>>> * Prefer c++ to g++, for systems like FreeBSD where g++ is not
>>>> usable.
>>>>   (John Hood)
>>>> * Fixes for Illumos Hipster 20151003.  (John Hood)
>>>> * Disable -Werror for protobuf code, to resolve a new gcc6 warning.
>>>>   (John Hood)
>&

Re: [mosh-devel] (fwd) Fw: Re: Mosh 1.2.6 release candidate available for testing]

[Keith Winstein]

(adding mosh-devel list)

Thanks, Ryan. This may have come from 0eb61480 (
https://github.com/mobile-shell/mosh/commit/0eb61480), when we made it a
fatal error if pkg-config fails to find the desired library (when adding
support for Apple Common Crypto and Nettle alongside OpenSSL).

Perhaps we should just make it a warning...?

On Tue, May 31, 2016 at 1:02 PM, Ryan Steinmetz  wrote:

> Keith,
>
> FreeBSD ships with OpenSSL, however, (as mentioned) does not provide .pc
> files.  .pc files are only installed alongside the openssl/libressl
> ports.
>
> mosh's configure smarts should:
> - Look for the openssl libraries in a couple of default locations
>  (/usr/lib and /usr/local/lib).
> - Should provide a --with-openssl-libs and --with-openssl-includes
>  configure options.
>
> The existing configure script from mosh 1.2.5 finds the libraries fine.
>
>
> Let me know if you have any questions, thanks,
> -r
>
> - Forwarded message from Peter Jeremy  -
>
> Date: Wed, 1 Jun 2016 05:57:15 +1000
> From: Peter Jeremy 
> To: z...@freebsd.org
> Subject: Fw: Re: [mosh-devel] Mosh 1.2.6 release candidate available for
> testing]
> User-Agent: Mutt/1.6.1 (2016-04-27)
>
> Sorry, I should have copied you on the attached.
>
> --
> Peter Jeremy
>
> Date: Tue, 31 May 2016 20:45:02 +1000
> From: Peter Jeremy 
> To: Keith Winstein 
> Cc: Richard Woodbury 
> Subject: Re: [mosh-devel] Mosh 1.2.6 release candidate available for
> testing
> User-Agent: Mutt/1.6.1 (2016-04-27)
>
> Hi Keith,
>
> On 2016-May-30 00:33:27 -0700, Keith Winstein  wrote:
>
>> Could you please send in some positive testing reports on the Mosh 1.2.6
>> release candidate?
>>
>
> It won't configure with the base OpenSSL on FreeBSD 10.3 because FreeBSD
> doesn't include the pkg-config files;
>
> configure:8821: checking for CRYPTO
> configure:8828: $PKG_CONFIG --exists --print-errors "openssl"
> Package openssl was not found in the pkg-config search path.
> Perhaps you should add the directory containing `openssl.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'openssl', required by 'world', not found
>
> Possibly the port maintainer can work around that.
>
> If I install OpenSSL or LibreSSL from ports then mosh builds and works.
> I've tried 1.2.5.95rc1 as a server with both itself 1.2.4a as a client
> and don't see any obvious issues.
>
> Note that most of the self tests are skipped:
>
> make  check-TESTS
> PASS: ocb-aes
> PASS: encrypt-decrypt
> PASS: base64
> SKIP: e2e-success.test
> SKIP: e2e-failure.test
> SKIP: emulation-ascii-iso-8859.test
> SKIP: emulation-80th-column.test
> SKIP: emulation-attributes-vt100.test
> SKIP: emulation-attributes-16color.test
> SKIP: emulation-attributes-256color8.test
> SKIP: emulation-attributes-256color248.test
> SKIP: emulation-back-tab.test
> SKIP: emulation-cursor-motion.test
> SKIP: emulation-multiline-scroll.test
> SKIP: emulation-wrap-across-frames.test
> SKIP: prediction-unicode.test
> SKIP: pty-deadlock.test
> SKIP: server-network-timeout.test
> SKIP: server-signal-timeout.test
> SKIP: window-resize.test
> SKIP: unicode-combine-fallback-assert.test
> SKIP: unicode-later-combining.test
>
> --
> Peter Jeremy
>
>
>
>
>
>
> - End forwarded message -
>
> --
> Ryan Steinmetz
> PGP: 9079 51A3 34EF 0CD4 F228  EDC6 1EF8 BA6B D028 46D7
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.6 release candidate available for testing

[Keith Winstein]

(Excuse me, I meant FreeBSD.)
On May 31, 2016 11:26 AM, "Keith Winstein"  wrote:

> Thanks for the report! Is this a regression -- did 1.2.5 or 1.2.4 work
> out-of-the-box on OpenBSD?
>
> Thanks
> Keith
> On May 31, 2016 3:45 AM, "Peter Jeremy"  wrote:
>
>> Hi Keith,
>>
>> On 2016-May-30 00:33:27 -0700, Keith Winstein  wrote:
>> >Could you please send in some positive testing reports on the Mosh 1.2.6
>> >release candidate?
>>
>> It won't configure with the base OpenSSL on FreeBSD 10.3 because FreeBSD
>> doesn't include the pkg-config files;
>>
>> configure:8821: checking for CRYPTO
>> configure:8828: $PKG_CONFIG --exists --print-errors "openssl"
>> Package openssl was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `openssl.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'openssl', required by 'world', not found
>>
>> Possibly the port maintainer can work around that.
>>
>> If I install OpenSSL or LibreSSL from ports then mosh builds and works.
>> I've tried 1.2.5.95rc1 as a server with both itself 1.2.4a as a client
>> and don't see any obvious issues.
>>
>> Note that most of the self tests are skipped:
>>
>> make  check-TESTS
>> PASS: ocb-aes
>> PASS: encrypt-decrypt
>> PASS: base64
>> SKIP: e2e-success.test
>> SKIP: e2e-failure.test
>> SKIP: emulation-ascii-iso-8859.test
>> SKIP: emulation-80th-column.test
>> SKIP: emulation-attributes-vt100.test
>> SKIP: emulation-attributes-16color.test
>> SKIP: emulation-attributes-256color8.test
>> SKIP: emulation-attributes-256color248.test
>> SKIP: emulation-back-tab.test
>> SKIP: emulation-cursor-motion.test
>> SKIP: emulation-multiline-scroll.test
>> SKIP: emulation-wrap-across-frames.test
>> SKIP: prediction-unicode.test
>> SKIP: pty-deadlock.test
>> SKIP: server-network-timeout.test
>> SKIP: server-signal-timeout.test
>> SKIP: window-resize.test
>> SKIP: unicode-combine-fallback-assert.test
>> SKIP: unicode-later-combining.test
>>
>> --
>> Peter Jeremy
>>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.6 release candidate available for testing

[Keith Winstein]

Thanks for the report! Is this a regression -- did 1.2.5 or 1.2.4 work
out-of-the-box on OpenBSD?

Thanks
Keith
On May 31, 2016 3:45 AM, "Peter Jeremy"  wrote:

> Hi Keith,
>
> On 2016-May-30 00:33:27 -0700, Keith Winstein  wrote:
> >Could you please send in some positive testing reports on the Mosh 1.2.6
> >release candidate?
>
> It won't configure with the base OpenSSL on FreeBSD 10.3 because FreeBSD
> doesn't include the pkg-config files;
>
> configure:8821: checking for CRYPTO
> configure:8828: $PKG_CONFIG --exists --print-errors "openssl"
> Package openssl was not found in the pkg-config search path.
> Perhaps you should add the directory containing `openssl.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'openssl', required by 'world', not found
>
> Possibly the port maintainer can work around that.
>
> If I install OpenSSL or LibreSSL from ports then mosh builds and works.
> I've tried 1.2.5.95rc1 as a server with both itself 1.2.4a as a client
> and don't see any obvious issues.
>
> Note that most of the self tests are skipped:
>
> make  check-TESTS
> PASS: ocb-aes
> PASS: encrypt-decrypt
> PASS: base64
> SKIP: e2e-success.test
> SKIP: e2e-failure.test
> SKIP: emulation-ascii-iso-8859.test
> SKIP: emulation-80th-column.test
> SKIP: emulation-attributes-vt100.test
> SKIP: emulation-attributes-16color.test
> SKIP: emulation-attributes-256color8.test
> SKIP: emulation-attributes-256color248.test
> SKIP: emulation-back-tab.test
> SKIP: emulation-cursor-motion.test
> SKIP: emulation-multiline-scroll.test
> SKIP: emulation-wrap-across-frames.test
> SKIP: prediction-unicode.test
> SKIP: pty-deadlock.test
> SKIP: server-network-timeout.test
> SKIP: server-signal-timeout.test
> SKIP: window-resize.test
> SKIP: unicode-combine-fallback-assert.test
> SKIP: unicode-later-combining.test
>
> --
> Peter Jeremy
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.6 release candidate available for testing

[Keith Winstein]

Hi folks,

Could you please send in some positive testing reports on the Mosh 1.2.6
release candidate?

It would be great to have an independent "looks good" from at least the
following platforms before we cut the release:

- Fedora
- the OS X binary .pkg
- OS X compiling from source
- OpenBSD
- FreeBSD
- NetBSD
- Chrome

Thanks,
Keith

On Wed, May 25, 2016 at 8:56 PM, john hood  wrote:

> Hi all,
>
> We're happy to announce the upcoming release of Mosh 1.2.6, and are
> calling for testing on Mosh 1.2.5.95rc1.  The release has picked up
> some minor new features in the year since the last release such as
> better IPv6 support and tools to handle orphaned sessions.  However,
> it's also seen significant improvements in performance, testing, and
> portability.
>
> The Changelog for this release:
>
>   * New features:
> * Add Travis CI builds for Linux and Mac.  (Anders Kaseorg, others)
> * Add a --local option to run without ssh.  (John Hood)
> * Mosh now returns exitstatus reflecting connection success.
>   (John Hood)
> * Add a end-to-end test suite and many tests.  (John Hood)
> * Implement timeouts and signals to help address orphaned sessions.
>   (John Hood)
> * Major rework of Mosh's display differencing/rendering
>   code with much improved performance for slow machines.  (John Hood)
> * Implement ANSI back/forward tab (CSI CBT, CSI CHT).
>   (John Hood)
> * Do not start user shell until network session starts.
>   (John Hood)
> * Add options for more flexible specification of IPv4/IPv6
>   hostname resolution.  (John Hood)
> * Improved bash completion.  (Steve Dignam, HIGUCHI Yuta)
> * Add options for different methods of resolving the remote host
>   address, allowing operation without SshProxyCommand.  (John Hood)
>
>   * Platform support:
> * Add configurable support for Apple Common Crypto and
>   Nettle, in place of OpenSSL.  Implement base64 locally.
>   (John Hood)
> * Workaround Cygwin select() bug.  (John Hood)
> * Updates to Debian packaging.  (Anders Kaseorg, Keith Winstein)
> * Workaround a glibc-2.22 issue causing segfaults on Debian Sid.
>   (John Hood with help from many others)
> * Prefer c++ to g++, for systems like FreeBSD where g++ is not usable.
>   (John Hood)
> * Fixes for Illumos Hipster 20151003.  (John Hood)
> * Disable -Werror for protobuf code, to resolve a new gcc6 warning.
>   (John Hood)
> * Link test for -fstack-protector-all on an embedded platform.
>   (Baruch Siach)
> * Resolve issue with bswap64() on FreeBSD-CURRENT with libc++-3.8.0.
>   (John Hood)
> * Fix issue with RECVTOS error message on client on FreeBSD.
>   (John Hood)
>
>   * Bug fixes:
> * Remove an assertion causing aborts on Unicode fallback found by
>   fuzzing with afl.  (Keith Winstein)
> * Fix a server hang with XON/XOFF on BSD systems.  (John Hood)
> * Fix a typeahead-prediction bug that caused display corruption on
>   urxvt.  (John Hood)
>
> Source code is available as
> <
> https://github.com/mobile-shell/mosh/releases/download/untagged-0d43a0f73825e9952677/mosh-1.2.5.95rc1.tar.gz
> >.
>  The SHA256 sum for this file is
> a2697c41cfc8c92dc7a743dd101849a7a508c6986b24d6f44711d8533d18fcf5
>
> One standalone OS X package is available:
>
> *
> <
> https://github.com/mobile-shell/mosh/releases/download/untagged-0d43a0f73825e9952677/mosh-1.2.5.95rc1.pkg
> >
> is an i386/x86_64 build for OS X 10.9 and higher.  The SHA256 sum for
> this file is
> 48a56d83d0ef655d38e0ea596fd9cac98c0dc433cb5356205d26748350d47e6c
>
> (If you are using a package system such as MacPorts or Homebrew, I
> recommend using that, though.)
>
> As always, Ubuntu PPA builds of the latest source are available at
> ppa:keithw/mosh.
>
> Packagers, please note that Mosh has some minor dependency changes: Perl
> is now required to be >= 5.14, but IO::Socket modules are no longer
> required.  If anybody needs to package for older versions of Perl, talk
> to me and I'll probably bring something into the release.  Also, if
> anyone needs an OS X package for 10.8 or lower, please contact me.
>
> Your testing is very unlikely to prove Mosh to be free of bugs, but your
> testing will help us make 1.2.6 a better release.  Please report any
> issues you find on Github, and we can be found on IRC at
> .
>
> Looking ahead, we expect Mosh 1.3 to be a feature release, bringing
> significant new functionality.  SSH agent forwarding is high on the list.
>
> The Mosh team thanks you for your help.
>
>   --John Hood
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] SSP specification (or RFC)?

[Keith Winstein]

Hi Zach -- I think, frankly, a rigorous spec is unlikely to happen soon
unless somebody really wants it. Most of the demand we get has been for new
features (scrollback, SSH-agent forwarding, server-side roaming, better
handling of new Unicode characters), many of which will require protocol
mods anyway.

-Keith

On Mon, Jan 4, 2016 at 3:22 PM, Zach Walton  wrote:

> Thanks Keith. Any plans to codify SSP into an RFC? I ask because it makes
> the barrier for entry as a developer lower, and easier to sell SSP as a
> good technical decision to a business or development team.
>
> On Mon, Jan 4, 2016 at 3:12 PM, Keith Winstein 
> wrote:
>
>> Short answer is, yes, source code is basically the definitive reference
>> (and mosh-paper.pdf / mosh-paper-draft.pdf). The state-synchronized objects
>> that define the Mosh protocol are in
>> https://github.com/mobile-shell/mosh/tree/master/src/statesync
>>
>> Best regards,
>> Keith
>>
>> On Mon, Jan 4, 2016 at 2:08 PM, Zach Walton  wrote:
>>
>>> Hi,
>>>
>>> I've trolled through the mosh-devel archives and didn't see an answer to
>>> this; is there a specification or RFC for SSP, or is (
>>> https://mosh.mit.edu/mosh-paper-draft.pdf) the definitive source (along
>>> with the mosh source code)?
>>>
>>> Thanks!
>>>
>>> ___
>>> mosh-devel mailing list
>>> mosh-devel@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>>
>>>
>>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] SSP specification (or RFC)?

[Keith Winstein]

Short answer is, yes, source code is basically the definitive reference
(and mosh-paper.pdf / mosh-paper-draft.pdf). The state-synchronized objects
that define the Mosh protocol are in
https://github.com/mobile-shell/mosh/tree/master/src/statesync

Best regards,
Keith

On Mon, Jan 4, 2016 at 2:08 PM, Zach Walton  wrote:

> Hi,
>
> I've trolled through the mosh-devel archives and didn't see an answer to
> this; is there a specification or RFC for SSP, or is (
> https://mosh.mit.edu/mosh-paper-draft.pdf) the definitive source (along
> with the mosh source code)?
>
> Thanks!
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Regarding testing of mosh

[Keith Winstein]

Hello Dinesh,

The mosh paper used the term-save and term-replay utilities (
https://github.com/keithw/stm-data). These can record and replay the
timestamps of user keyboard input and an application response.

You might also enjoy reading some of the other student reproductions of the
mosh measurements:

2015:
https://reproducingnetworkresearch.wordpress.com/2015/05/31/cs244-15-mosh-reproducing-network-research-results/

2014:
https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs-244-14-mosh-an-interactive-remote-shell-for-mobile-clients/

2013:
https://reproducingnetworkresearch.wordpress.com/2013/03/13/cs244-2013-evaluation-of-mosh-mobile-shell-performance-results/

Best regards,
Keith

On Sat, Nov 21, 2015 at 11:47 AM, Daultani, Dinesh 
wrote:

> Hi Keith,
>
> I am currently working on my practical telecommunication course project
> that I have taken MoSh.
>
> And I am trying to test the Mosh results from Amazon AWS t2-micro instance 
> cloud
> to my virtual vmware ubuntu client.
>
> Can you please tell me how have you generated the *graph of response time
> Vs keystrokes.*
>
> I am new to SSH & Linux and trying to do research on the Mosh.
>
> It would be great help if you can guide me through the procedure for
> getting results in the form of *response time Vs keystrokes *graph.
>
> Please reply soon.
>
>
> Thanks and Regards,
>
> Dinesh Daultani
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] Fwd: Bug#803253: mosh: error: --compare-versions takes three arguments:

[Keith Winstein]

Do the Debian experts have any idea on this one? Maybe it is coming from
our use of rm_conffile in the maintainer script?

-Keith

-- Forwarded message --
From: Jakub Wilk 
Date: Wed, Oct 28, 2015 at 11:05 AM
Subject: Bug#803253: mosh: error: --compare-versions takes three arguments:
  
To: 803...@bugs.debian.org


* Keith Winstein , 2015-10-28, 08:50:

> Do you see this error message if you remove the mosh package (dpkg --purge
> mosh) and then re-install mosh only?
>

Yes, I do.

-- 
Jakub Wilk
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Nit-pick bug in mosh 1.2.5 man page

[Keith Winstein]

Thanks for the report. Point taken. We'll take a pull request!

Best,
Keith
On Sep 5, 2015 12:20 PM, "Andrew C Aitchison" 
wrote:

>
> Thanks for continuing work on mosh;
> I particularly appreciate the XTerm mouse mode.
>
> I can't see the point in making a release for this bug,
> and it may need changing again for the next release, but
> the man page is still dated "April 2013" even though
> it has been updated with mention of the --bind-server option.
>
> Thanks,
>
> Andrew C Aitchison
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh for PC to remote raspberry Pi

[Keith Winstein]

Hello Kris,

Could you point me to the instructions you're following?

The typical use of Mosh just involves typing "mosh " on the
client, or typing the name of server into the Mosh Chrome app. It doesn't
involve running anything on the server (other than installing mosh in the
first place).

For debugging purposes, it is possible to run the "mosh-server" and
"mosh-client" programs separately (as described on http://mosh.mit.edu),
but in normal use you would just run "mosh," or the Chrome app, on the
client, and it takes care of starting the server. (Just like with SSH, how
you might run "ssh server" on the client.)

If you do want to run mosh-server separately, the command is "mosh-server"
with a dash in the middle.

-Keith

On Thu, Sep 3, 2015 at 8:04 PM, Kris Mclean 
wrote:

> We normally SSH from a PC (using the Chrome browser SecureShell app) into
> a Rpi via wifi on a home network. Recently we got the Pi working on a 3G
> dongle & noticed that SSH to the Pi (now outside the home network) no
> longer worked.
>
> We installed mosh for chrome on the PC & mosh for Debian on the PI. The
> instructions said to run mosh server on the Pi to get a key, IP etc for the
> form the Chrome mosh wants filled in. But mosh server on the Pi responds
> with;
> /usr/bin/mosh: Could not resolve hostname server
> ssh_exchange_indentification: Connection closed by remote host
> /usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand
> disabled?)
>
> The Pi definitely has a connection;
>
> ppp0  Link encap:Point-to-Point Protocol
>  inet addr:10.178.192.20  P-t-P:10.64.64.64  Mask:255.255.255.255
>  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>  RX packets:574 errors:78 dropped:0 overruns:0 frame:0
>  TX packets:552 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:3
>  RX bytes:128723 (125.7 KiB)  TX bytes:277499 (270.9 KiB)
> and ping google.com works. So just wondering what we could try next?
> Rgds. Kris Mc(mcleanautomation.com.au)
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Broken link in mosh.mit.edu

[Keith Winstein]

Thanks for the report. Switched to locally-hosted version (which I was able
to retrieve using Lynx from the Gopher URL of Iain's blog, gopher://
sdf.org:70/0/users/irl/blog/2012-08-22-mosh-in-a-lift.md).

Best regards,
Keith

On Fri, Aug 14, 2015 at 6:34 AM, m...@francescoprovino.com <
m...@francescoprovino.com> wrote:

> Hello,
> I know it’s a little stupid thing, but the link in the main page at
> "Aug. 22, 2012: Mosh (and its tolerance for high packet loss) helps Iain
> Learmonth escape from an elevator."
> is broken, the only other reference I was able to find about this episode
> is https://www.mail-archive.com/mosh-users@mit.edu/msg00023.html that
> also contain a broken link.
> Thank you for your work on mosh!
>
> Best regards
> 
> Francesco Provino
> francescoprovino.com
> 
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Concerns about mosh's security at the Broad Institute

[Keith Winstein]

Hello Hayden,

The thread seems to have run its course -- do you have enough to proceed,
or how can we help you move forward?

Best regards,
Keith

On Fri, Aug 7, 2015 at 4:33 PM, Hayden Metsky  wrote:

> Hi,
>
> A friend (Simon Ye, CC'd) and I are PhD students at MIT who are
> currently working at the Broad Institute (a genomics center) using
> their computing infrastructure. The standard workflow is to use ssh to
> connect to a login server and then do work on that. This login server
> is accessible from anywhere (including outside the VPN) and password
> is the sole method of authentication.
>
> We would like the Broad Institute's IT staff to unblock UDP ports
> 6-61000 so that we can use mosh to connect to the login servers.
> (We've both used mosh elsewhere and loved it.) Unfortunately we've
> encountered resistance from the security team, who have cited a number
> of security concerns. We've responded to many of these concerns but
> have made little progress. Of course, the security team's view is
> going to be biased in a conservative direction.
>
> Since networking and computer security are well outside our area of
> expertise, we think it would be helpful to pass the concerns along to
> mosh's developers. We would love to hear your thoughts; obviously we
> would welcome rebuttals, but we would also be happy to hear if you
> think the concerns have validity.
>
> Below I am going to quote six concerns verbatim from a document
> written by the security team. Under some of these concerns I'll
> include a short note from myself giving our thoughts.
>
> * "Mosh requires opening UDP ports on the Broad perimeter. That makes
>   the Broad network available as a participant in a DDoS performed
>   against external entities, specifically ICMP PORT UNREACHABLE class of
>   attack ("Smack" is one productized version). Even unwitting
>   participation by the Broad in a DDoS could have materially damaging
>   effect upon the Broad as a whole and the outcome of such an event
>   would inevitably involve closing the ports anyway."
>- This is the team's primary concern. Our initial thought is that it
>  is difficult to imagine a single machine (server or router) having
>  a meaningful impact in a DDoS amplification, but perhaps this is
>  mistaken. Or maybe it is possible to use mosh with restrictions on
>  outgoing traffic that would avoid the Broad from participating in
>  this kind of attack? Even though this is not specific to mosh, we
>  would very much appreciate your thoughts.
>
> * "Mosh is based on the experimental MIT State Synchronization Protocol
>   (SSP). SSP is not know to any commercially available firewalls or
>   perimeter devices, so the use of mosh would not be manageable. Also
>   the first UDP mosh packet is from client to server. That underscores
>   the fact that there is no way for a firewall to have any control of
>   state."
>
> * "Both Google and Mozilla have rejected mosh."
>- I don't know about Mozilla, but my understanding is that this is
>  incorrect with regard to Google. Even if Google only allows mosh
>  access from within a VPN and we're asking the Broad to allow access
>  from outside (ssh is allowed from outside), it is difficult to see
>  how this is an argument against mosh.
>
> * "Mosh sends the session key as an environment variable. User-
>   controlled environment variables are an injection path - their use
>   for sensitive purposes opens security vulnerabilities."
>
> * "Mosh requires server-side modification to /etc/sshd_config to enable
>   'SendEnv LANG LC_*'; this is turned off by default to protect against
>   environment variable injection."
>- There's a lot that's misleading or incorrect about this. First, I
>  think they mean 'AcceptEnv' rather than 'SendEnv'. On many OS's,
>  it is my understanding that this is actually turned *on* by default.
>  When I run 'ssh broad locale', I receive back my laptop's locale
>  (even after changing it), indicating that the server is accepting
>  my LANG/LC_* env variables. So I suspect this is in fact turned on
>  (I cannot read the file). Regardless, we're able to install mosh
>  and use it internally among nodes, which we believe suggests that
>  no changes need to be made (besides unblocking ports).
>
> * "The mosh client can, at startup, invoke any program on the server.
>   The program does not have to be the mosh-server. So it is an
>   unrestricted and unmonitored remote execution environment like rsh."
>- We're a bit confused on this point. The same (we believe) is true
>  of ssh, and since mosh authenticates via ssh we don't quite see how
>  this might be held against mosh given that ssh is already used.
>
> Thank you all so much for looking at this!
>
> Best,
> Hayden
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.5 in jessie-backports?

[Keith Winstein]

FYI: Mosh 1.2.5 was just accepted into jessie-backports.

On Sun, Aug 9, 2015 at 11:15 AM, Keith Winstein  wrote:

> Hello Jonathan,
>
> I believe it's already been uploaded to the NEW queue for
> jessie-backports and will be there once it gets reviewed.
>
> Best regards,
> Keith
>
> On Sun, Aug 9, 2015 at 2:02 AM, Jonathan Lane  wrote:
> > Hello,
> >
> > I just read the Mosh 1.2.5 release notes and saw IPv6 support listed.
> This seems like a prime candidate for backporting to Jessie, especially
> with IPv6 deployment taking off at long last.  Is there anything we the
> users can do to help the process along?
> >
> > Thanks,
> >
> > Jon
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Concerns about mosh's security at the Broad Institute

[Keith Winstein]

On Sat, Aug 8, 2015 at 7:36 AM, C.v.St.  wrote:
> The more ports of a host are not firewalled, the more ports an attacker
> can use to send faked packets to, to provoke (e.g.) misdirected 'ICMP
> PORT UNREACHABLE' responses to a third party.  So opening more ports
> makes somebody unknown elsewhere more vulnerable and makes a 'local
> server' machine more suspect. So some people strictly minimize the
> number of visible ports to the outside to only a few well known ports.

I don't follow this argument about how "opening more ports makes
somebody unknown elsewhere more vulnerable" -- am I missing something
here?

>From some quick measurements, Linux throttles its ICMP port
unreachable messages on a total outgoing basis.

It doesn't matter how many ports you have open -- 1,000 incoming
datagrams to the same port will get the same number of IP port
unreachables as 1 incoming datagram directed to each of 1,000 ports.

It doesn't matter whether the IP datagrams are TCP or UDP. (ICMP port
unreachables are sent in reply to both.)

It doesn't even matter whether a socket is listening on that port or
not. If something is listening, Linux will respond with a TCP SYNACK
(if TCP) or a Mosh reply message (if Mosh and if the incoming datagram
passed the integrity check against the shared secret key). If nothing
is listening, Linux will respond with an ICMP port unreachable. A TCP
SYNACK can be larger than an ICMP port unreachable.

In all these cases, an incoming IP datagram earns a reply to the
apparent IP source address -- but there is no significant
amplification.

So I don't follow the concern here. If an institution is really
worried about ICMP, it should block ICMP. But in what respect is an
ICMP port unreachable reply, when directed to a third party, more
harmful than a TCP SYNACK or other reply? (Mosh in general fixes this
problem of third-party attacks by not responding to anything unless it
passes the integrity check.)

-Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.5 in jessie-backports?

[Keith Winstein]

Hello Jonathan,

I believe it's already been uploaded to the NEW queue for
jessie-backports and will be there once it gets reviewed.

Best regards,
Keith

On Sun, Aug 9, 2015 at 2:02 AM, Jonathan Lane  wrote:
> Hello,
>
> I just read the Mosh 1.2.5 release notes and saw IPv6 support listed.  This 
> seems like a prime candidate for backporting to Jessie, especially with IPv6 
> deployment taking off at long last.  Is there anything we the users can do to 
> help the process along?
>
> Thanks,
>
> Jon
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Concerns about mosh's security at the Broad Institute

[Keith Winstein]

Hello Hayden and Simon,

Happy to help if we can. There may be others on the list who are more
familiar with some of these kinds of concerns than me -- hope they
will weigh in. Why don't you let us bat around the response for a bit
before we commit to it. My instincts are that if you really want to
move the needle, perhaps we should get on a conference call and try to
hear them out and understand where they're coming from a bit better.
I'm happy to participate if it would be helpful.

Here would be my initial responses. Our basic perspective is that Mosh
has been out for three and a half years, has been very stable, and has
millions of users, including at major Silicon Valley companies like
Google, Facebook, and Apple. All told, the number of serious security
holes that have been reported in Mosh to date is: zero. This speaks
well of our conservative design and development process, and it
amounts to a better track record than OpenSSL, OpenSSH, or the
underlying SSH and TLS protocols. We have some FAQs on security at
https://mosh.mit.edu that you might find helpful.

On Fri, Aug 7, 2015 at 4:33 PM, Hayden Metsky  wrote:
> * "Mosh requires opening UDP ports on the Broad perimeter. That makes
>   the Broad network available as a participant in a DDoS performed
>   against external entities, specifically ICMP PORT UNREACHABLE class of
>   attack ("Smack" is one productized version). Even unwitting
>   participation by the Broad in a DDoS could have materially damaging
>   effect upon the Broad as a whole and the outcome of such an event
>   would inevitably involve closing the ports anyway."

Our initial response: We are not sure that we understand the proposed
risk and would need more details to produce a well-informed reply.
Mosh does not require ICMP; your institution can block ICMP and Mosh
will continue to function.

We did not find many references to "Smack." According to
http://www.isi.edu/~mirkovic/bench/attacks.html, Smack attempts to
crash endpoints by sending "random ICMP unreachable packets from
random IP's" in order to bring about "End-point networking crash."

This class of attack is not related to UDP specifically; hosts will
respond with an ICMP port-unreachable message whether the incoming IP
datagram is UDP or TCP. Closing UDP ports will not prevent this
attack. To the extent Broad is worried about phony ICMP unreachable
messages, it will need to mitigate this attack whether the institution
allows UDP or not (perhaps by blocking these ICMP messages, which will
not affect Mosh).

Other large research institutions, such as MIT and Stanford, do not
block UDP and have not suffered this outcome. Many institutions block
all incoming connections (TCP and UDP) by default, but allow them on
an opt-in basis to whitelisted hosts. Stanford does this, and we
understand MIT is moving in this direction -- something similar at
your institution might satisfy all sides.

Mosh does not require opening 1,000 UDP ports; if the institution is
more comfortable with fewer, it could open 10 or 100. The number of
ports is an upper limit on the number of concurrent mosh-servers on
any particular server machine. Mosh uses separate port numbers as a
security feature; different users are isolated from one another by the
kernel. There is no code in Mosh that runs as root or with elevated
privileges. This has allowed Mosh to avoid a class of
privilege-escalation or remote-root security vulnerabilities that have
afflicted various implementations of SSH and HTTPS servers.

> * "Mosh is based on the experimental MIT State Synchronization Protocol
>   (SSP).

Our initial response: SSP is not experimental. It has been widely used
for more than three years. There have been zero vulnerabilities
reported to date. Its security track record is, so far, better than
SSH and TLS.

>   SSP is not know to any commercially available firewalls or
>   perimeter devices, so the use of mosh would not be manageable.

Our initial response: This is becoming the best-practice in secure
protocols. Earlier protocols (like SSH and TLS) are built on top of
unencrypted TCP. More recent protocols (like Mosh's SSP and Google's
QUIC) use fully-encrypted payloads after the UDP header. With SSP and
QUIC, security is end-to-end and there are fewer opportunities for
modification by in-network middleboxes. This increases security and
defeats a class of vulnerabilities that have afflicted SSH and TLS.
Even today, these protocols are vulnerable to phony RST segments,
since they do not authenticate the TCP headers.

However, a Mosh session can always be uniquely tracked by the IP and
port of the server. There is no need to open up UDP to every server at
Broad; the institution could white-list a small set of opt-in servers.
(MIT and Stanford follow a similar approach.)

> Also the first UDP mosh packet is from client to server.

Our initial response: We do not understand the described concern and
may need more information to be able to give a well-informed reply.

[mosh-devel] Mosh repository URL moved (but existing links/clones will still work)

[Keith Winstein]

Hello Mosh users and developers,

On the heels of the successful 1.2.5 release, just an FYI that the
Mosh repo has moved to: https://github.com/mobile-shell/mosh

This has allowed us to turn on Travis CI for continuous
integration/testing (without giving Travis full access to my GitHub
account).

All existing links and local clones should continue to work fine and
will be transparently redirected, but please let me know if anybody
has trouble.

Cheers,
Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] mosh 1.2.5 released

[Keith Winstein]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mosh users and developers,

mosh 1.2.5 has been released.

The source code is at:

https://mosh.mit.edu/mosh-1.2.5.tar.gz

SHA-256: 1af809e5d747c333a852fbf7acdbf4d354dc4bbc2839e3afe5cf798190074be3

John Hood was the release coordinator for this release and deserves
all of our thanks! New features include mouse support, a reconfigurable
escape key, and basic support for IPv6. There has also been a focus on
making this a stable, reliable release as a base for future features.

The change log for this release:

* New features:
* Bind to a specific IP address with --bind-server. (Philipp
  Haselwarter)
* MOSH_ESCAPE_KEY configures escape character.  (Timo
  J. Rinne)
* Support non-roaming IPv6. (Anders Kaseorg)
* Implement XTerm mouse mode. (Barosl LEE, Andrew Chin,
  Louis Kruger)
* Report Git revision along with version if available.
  (John Hood)

* Platform support:
* Add pselect() emulation. (Jérémie Courrèges-Anglas)
* OpenBSD, OS X: Fix be64toh-related issues. (Jérémie
  Courrèges-Anglas)
* ARM Neon: fix gcc4.8 compiling problem(Pasi Sjöholm)
* NaCl: Conditionally rename main to mosh_main. (Richard
  Woodbury)
* FreeBSD: Token pasting, forkpty(), ARM fixes. (John Hood)
* AIX: Implement CTTY grabbing when TIOCSCTTY is missing
  (Anton Lundin)
* OS X: Broaden build support to cover OS X 10.5 through
  10.10. (John Hood)
* Debian: Improve bash-completion install and
  functionality. (Suggested by Gabriel Filion, John Hood)

* Bug fixes:
* Automake/autoconf workarounds.  (Anders Kaseorg)
* mosh-server: Allow startup without PTY.  (Keith Winstein)
* network.cc: Properly close old fd on Socket assignment
  operator. (Thanks to Igor Bukanov)
* mosh-server:  Allow startup with zero-window-size PTY.
  (Igor Bukanov)
* AddrInfo: Fix error message generation when node == NULL
  (Anders Kaseorg)
* Timestamp: Prevent integer overflow on Darwin PPC 32-bit
  (Anders Kaseorg)
* scripts/mosh: Fix hang when remote closes the connection
  (Anders Kaseorg)
* Fix issues with parsing of 256-color SGR sequences.
  (John Hood)
* Numerous code hygiene, Coverity, and Clang static analyzer
  fixes.  (Anders Kaseorg, Geoffrey Thomas, John Hood)

*Compatibility*: mosh 1.2.5 is backwards-compatible with mosh clients
back to 0.96 and mosh servers back to 1.0.9.

*OS X binary packages*: We are releasing two OS X binary packages:

https://mosh.mit.edu/mosh-1.2.5.pkg is an i386+amd64 build for OS X 10.9
SHA-256: 8a590ba81edd6f706f2d0afe1cb882bd8ff8860e395b7c6ac7285306f4f12209

https://mosh.mit.edu/mosh-1.2.5-leopard.pkg is an i386+ppc build for OS X 10.5
SHA-256: 5fd77ce1c2d4b24db79be8daff3140975e53f49c83b48ff57087483133a59155

However, when possible, we encourage OS X users to install via
MacPorts or Homebrew, instead of using the binary package, in order
to receive automatic upgrades.

*Packagers, please note* that Mosh has picked up some minor new
dependencies: for example, Debian/Ubuntu packaging now uses
bash-completion at build time, install requires a not-ancient dpkg
version, and IO::Socket::IP is recommended for IPv6 support.  All of
these dependencies are optional.

*Bugs*: Please let us know of any problems at the GitHub issue
tracker, at https://github.com/keithw/mosh/issues. The developers can
also be found on IRC at .

Best regards on behalf of the Mosh team,
Keith Winstein

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVsLluAAoJECC3KDr+JUxpFfkQAIzJEXg+KT5cJvTG6urxQOce
SXgDcK1K15uj8/eyYNa0VrXL7dBuWCHDpWsBpl8O8VVOdPuA4yTo7TKDk8IWi3Jh
QjBUfv6XQ4RY8yK3lf9bnZlTiBAnQxP/hpG+I+y4C37thvTc3PVgq3oLYW8/CwaN
x1DmSUvNipXAfhDk2CMn7DrxIRnVzt233Qhwyl+YlwUmxxLDDA+fG/Mp4J94aEt7
QWfwNii8zSwIMpZnzYD3nV2XkK1Dve1YNc7fD32URMpvlTboosQjQ7sLqbHVJQFS
53lePMU0UWfzGPsr28n4gQjH9/iac5Kyu6a2aQTAy9ErkQ1oQnwU9njtaTBdJRIJ
hGLNg9aTtZCejCNaaoiCc7iKT8XPWZfNLMgdsEQzvQ/bdstLc2TwFgZql+uJpJWw
B3lXU4LM1lUpO+0Qp1ixBq4XyAw6Wx9wGcF6oJtNAds0pnAqqq5ASFseN9/gY6Q2
r9BYWGHEOhrdCD6kQrsqT5tKCBLepUa0SlPTz2jsFNe7fwnLyc3pGIU02S+sf5Pf
XcjgrcNedKCQpuaSNCIq5bwfUpetX+Kb+HwuuPvRRBwRjXgjAIcUlcKD5Lz9ED0G
Eqybni+P2brdNGa2+ivTQITwgvY4vDRNZf+c5YLKA2KwOWKnoCo0Tnfv57mOSNqX
3RFXJyYBv9gKNfAxXYmg
=uzIB
-END PGP SIGNATURE-
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh 1.2.5 release candidate 2 available for testing

[Keith Winstein]

Thanks for the report!

I can chip in that the rc2 has built (and the tests passed) for every
Debian architecture (
https://buildd.debian.org/status/package.php?p=mosh&suite=sid).

And in the Ubuntu PPA (
https://launchpad.net/~keithw/+archive/ubuntu/mosh-dev).

Would love to hear a report from the various OS X architectures and
versions.

> PS: will we have to regen autoconf/make files for 1.2.5-release?

No, the 1.2.5 release tarball will be like previous releases -- a GNU-style
tarball with a prebuilt ./configure. (From "make distcheck") It won't
require autoconf. Thanks for noticing this.

-Keith

On Thu, Jul 2, 2015 at 8:43 PM, Jérémie Courrèges-Anglas 
wrote:

>
> FWIW, mosh-1.2.4.95rc2 builds and works fine on OpenBSD-current, amd64
> and sparc64 architectures.  This update[1] means that most tweaks and
> patches are now unneeded in the OpenBSD ports framework.
>
> There is one remaining patch, related to ARM assembly support.  Since
> gas on OpenBSD/arm has recently gained support for more opcodes, this
> patch[2] may now be unneeded.  No idea yet.
>
> Cheers,
>
> PS: will we have to regen autoconf/make files for 1.2.5-release?
>
> [1] http://marc.info/?l=openbsd-ports&m=143561579421068&w=2
> [2]
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/mosh/patches/patch-src_crypto_ocb_cc?rev=1.1&content-type=text/plain&only_with_tag=HEAD
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh in jessie-backports

[Keith Winstein]

Thanks, Romain. I think at this rate, let's just revisit this once 1.2.5 is
released, uploaded to the main archive, and hits testing.

Cheers,
Keith

On Sat, Jun 27, 2015 at 5:26 AM, Romain Francoise 
wrote:

> Hi Keith,
>
> On Fri, Jun 26, 2015 at 11:17:27PM -0400, Keith Winstein wrote:
> > I'm not sure if I have permissions to do that as a DM.
>
> Good question. I asked the backports people, and since you already have
> permission to upload to the main archive, all you need to do is to ask
> to be added to the backports ACL as per this section:
>
>  http://backports.debian.org/Contribute/#index2h3
>
> The first upload still needs to be signed by a Debian Developer, so I
> can sponsor that for you.
>
> That leaves the question of whether or not you have the time, need and
> inclination to maintain the backport, the procedures are a bit different
> than for the main archive. If you don't, I'm happy to maintain it.
>
> > We are about to have a 1.2.4.95rc2 and (hopefully soonafter) a 1.2.5, but
> > you are welcome to upload the 1.2.4.95rc1 backport now if you will follow
> > it up with 1.2.5 as soon as it is released.
>
> Ok, sure. Backports to stable follow the version in testing, so as soon
> as these versions migrate from unstable, the backport will need to be
> updated.
>
> Thanks,
> --
> Romain Francoise 
> http://people.debian.org/~rfrancoise/
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh in jessie-backports

[Keith Winstein]

Hello Romain,

I'm not sure if I have permissions to do that as a DM.

We are about to have a 1.2.4.95rc2 and (hopefully soonafter) a 1.2.5, but
you are welcome to upload the 1.2.4.95rc1 backport now if you will follow
it up with 1.2.5 as soon as it is released.

Best regards,
Keith

On Fri, Jun 26, 2015 at 4:57 PM, Romain Francoise 
wrote:

> Hi,
>
> Do you plan to upload a backport of mosh 1.2.4.95rc1-1 to
> jessie-backports? If not, do you mind if I do it myself?
>
> Thanks,
> --
> Romain Francoise 
> http://people.debian.org/~rfrancoise/
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] carpal tunnel, measuring latency, and how to disable prediction testing

[Keith Winstein]

Frederick:

Thanks for your kind words about Mosh. For instant predictions (that might
be wrong and get corrected by the server), please try the
--predict=experimental option to mosh.

You can measure the latency with our term-save tool:
https://github.com/keithw/stm-data/

Best regards,
Keith

On Wed, Jun 24, 2015 at 12:13 AM, Frederik Eaton  wrote:

> Dear Mosh Developers,
>
> Thank you for a great product. I have thought about the need for
> something like this for years, and was happy when I discovered 'mosh'
> (a bit late I know).
>
> Your mailing list is not indexed by Google, but I downloaded the
> archives and found there seems to be no mention of 'carpal tunnel
> syndrome' or 'tendonitis'. I wanted to say that the reason I think a
> product like mosh is so valuable, is that according to my own self
> observation, typing over high-latency connections causes tendonitis. I
> wonder that no one else has made this connection, perhaps it is my own
> imagination. (I guess the hypothetical mechanism would be that my
> brain sends a "work faster" signal whenever a nerve seems to be
> working slowly, according to the delayed visual feedback, causing some
> kind of damage to healthy nerves)
>
> In any case, whether for health or "minimum annoyance" reasons, I have
> an interest in eliminating latency as much as possible. I don't care
> if someone sees part of all of my password, or if control sequences
> briefly show up on my editor screen. What I want is for immediate
> visual confirmation when one of my fingers pressed a key. The man page
> says "The predictive model must prove itself anew on each row of the
> terminal and after each control character, so mosh avoids echoing
> passwords or non-echoing editor commands." Is there an easy way to
> turn this feature off in the source code? Is it a bad idea, for some
> reason I haven't anticipated?
>
> My other (related) question is how to measure the actual latency. I
> can imagine that someone may have patched xterm to log input and
> output characters with sufficiently fine-grained timestamps, so that
> the latency of ssh, mosh, screen, etc. could be calculated, as the
> user presses random keys. I saw a couple things on your github issue
> tracker which look like people are measuring these values. I'm curious
> how to measure them myself. My initial trial of mosh (on an Arch
> Linux, 800 MHz "Intel(R) Atom(TM) CPU N270" (32-bit)) seems to show a
> slightly higher latency than simply typing on a local editor, and I'm
> curious to know if this is real.
>
> Thank you again for your dedication and incredibly useful software
> contribution, and also for reading my questions.
>
> Please Cc on replies as I'm not subscribed. Thanks,
>
> Frederick Eaton
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[mosh-devel] Fwd: New Defects reported by Coverity Scan for keithw/mosh

[Keith Winstein]

FYI -- our Coverity scan report.

-- Forwarded message --
From: 
Date: Tue, Jun 9, 2015 at 7:20 AM
Subject: New Defects reported by Coverity Scan for keithw/mosh
To: kei...@mit.edu



Hi,

Please find the latest report on new defect(s) introduced to keithw/mosh
found with Coverity Scan.

6 new defect(s) introduced to keithw/mosh found with Coverity Scan.
2 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 6 of 6 defect(s)


** CID 111991:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/benchmark.cc: 65 in main()



*** CID 111991:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/benchmark.cc: 65 in main()
59 #include "fatal_assert.h"
60
61 const int ITERATIONS = 10;
62
63 using namespace Terminal;
64
>>> CID 111991:  Error handling issues  (UNCAUGHT_EXCEPT)
>>> In function "main(int, char **)" an exception of type
"std::runtime_error" is thrown and never caught.
65 int main( int argc, char **argv )
66 {
67   int fbmod = 0;
68   int width = 80, height = 24;
69   int iterations = ITERATIONS;
70   if (argc > 1) iterations = atoi(argv[1]);

** CID 111990:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/benchmark.cc: 65 in main()



*** CID 111990:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/benchmark.cc: 65 in main()
59 #include "fatal_assert.h"
60
61 const int ITERATIONS = 10;
62
63 using namespace Terminal;
64
>>> CID 111990:  Error handling issues  (UNCAUGHT_EXCEPT)
>>> In function "main(int, char **)" an exception of type
"std::invalid_argument" is thrown and never caught.
65 int main( int argc, char **argv )
66 {
67   int fbmod = 0;
68   int width = 80, height = 24;
69   int iterations = ITERATIONS;
70   if (argc > 1) iterations = atoi(argv[1]);

** CID 111989:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/termemu.cc: 75 in main()



*** CID 111989:  Error handling issues  (UNCAUGHT_EXCEPT)
/src/examples/termemu.cc: 75 in main()
69 #include "select.h"
70
71 const size_t buf_size = 16384;
72
73 static void emulate_terminal( int fd );
74
>>> CID 111989:  Error handling issues  (UNCAUGHT_EXCEPT)
>>> In function "main(int, char **)" an exception of type
"std::runtime_error" is thrown and never caught.
75 int main( int argc, char *argv[] )
76 {
77   int master;
78   struct termios saved_termios, raw_termios, child_termios;
79
80   set_native_locale();

** CID 111988:  Insecure data handling  (TAINTED_STRING)
/src/frontend/mosh-server.cc: 790 in chdir_homedir()()



*** CID 111988:  Insecure data handling  (TAINTED_STRING)
/src/frontend/mosh-server.cc: 790 in chdir_homedir()()
784   perror( "getpwuid" );
785   return; /* non-fatal */
786 }
787 home = pw->pw_dir;
788   }
789
>>> CID 111988:  Insecure data handling  (TAINTED_STRING)
>>> Passing tainted string "home" to "chdir", which cannot accept
tainted data.
790   if ( chdir( home ) < 0 ) {
791 perror( "chdir" );
792   }
793
794   if ( setenv( "PWD", home, 1 ) < 0 ) {
795 perror( "setenv" );

** CID 111987:(TAINTED_STRING)
/src/examples/termemu.cc: 138 in main()
/src/examples/termemu.cc: 138 in main()
/src/examples/termemu.cc: 138 in main()
/src/examples/termemu.cc: 138 in main()



*** CID 111987:(TAINTED_STRING)
/src/examples/termemu.cc: 138 in main()
132 my_argv[ 0 ] = strdup( pw->pw_shell );
133   }
134   assert( my_argv[ 0 ] );
135   my_argv[ 1 ] = NULL;
136   argv = my_argv;
137 }
>>> CID 111987:(TAINTED_STRING)
>>> Passing tainted string "*argv" to "execvp", which cannot accept
tainted data.
138 if ( execvp( argv[ 0 ], argv ) < 0 ) {
139   perror( "execve" );
140   exit( 1 );
141 }
142 exit( 0 );
143   } else {
/src/examples/termemu.cc: 138 in main()
132 my_argv[ 0 ] = strdup( pw->pw_shell );
133   }
134   assert( my_argv[ 0 ] );
135   my_argv[ 1 ] = NULL;
136   argv = my_argv;
137 }
>>> CID 111987:(TAINTED_STRING)
>>> Passing tainted string "argv[0]" to "execvp", which cannot accept
tainted data.
138 if ( execvp( argv[ 0 ], argv ) < 0 ) {
139   perror( "execve" );
140  

Re: [mosh-devel] mosh releases

[Keith Winstein]

On Wed, May 27, 2015 at 7:00 AM, John Hood  wrote:

>  (3) When the mosh-client prints a new character to the screen that it's
> never printed before, it then interrogates the terminal to get its current
> column to verify that the terminal emulator's idea of the width is the same
> as what's in the Terminal::Complete object. If yes, it marks it as a
> dependable character where the Terminal::Complete width matches the outer
> termemu's width. Otherwise, it marks it as a problematic character (so that
> it needs to absolutely position whatever comes next). Probably we can
> assume that all the characters in Unicode 3.0 without ambiguous widths are
> handled properly or something.
>
>  What do you think?
>
> I'm a little uncomfortable with querying the terminal on the fly for
> cursor position-- I don't 100% know why.  At least part of it is that there
> is a long-standing issue with terminal input combined with terminal
> reports:  if the user (in Emacs, say) types ESC, pauses (on the normal
> human scale for typing), mosh-client sends the Cursor Position Report
> sequence and the terminal blats out the response, and then the user types
> X...you have a problem.  Also, the client must wait for the response.  But
> how long should it wait?  1, 10, 1000 milliseconds?  You can't and don't
> know.  And what does it do if it never gets the response?
>

Ok, fair enough. Let's just kill step 3. The client does not try to audit
the character widths that the server is telling it. If there's a mismatch
between what the outer termemu thinks is the character width and what the
mosh-server thinks, it's the user's responsibility to update the
wcwidth.txt file on the server. (This would still be a lot better than the
status quo!)

I haven't seriously looked at the prediction code in a while (maybe ever).
> My naive question is, why does input prediction insert its predicted
> characters, instead of overstriking?  I'd think that overstriking and
> letting the server handle redisplaying inserted characters, even if it's
> laggy, is likely to be a better result in general.
>

Well, try it and see what you think. Most of the time I think I am editing
text in insert mode (and going back to fix typos and stuff), and it's nice
to have that handled locally. But I haven't done an A/B test probably since
early 2012.

-Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] does mosh have a version-specific dependency on Google Protobuf?

[Keith Winstein]

Good question!

We have a (small) crypto-focused test suite that gets run from "make check"
and as part of building the Debian/Ubuntu packages (and possibly
Fedora/EPEL?), but it doesn't test protocol interoperability among versions
of mosh that were compiled differently.

It would be great to do a rigorous test suite like this, but honestly I
think this is not where we're going to get in trouble (that Google will
introduce a breaking change into the protobuf wire format and we won't know
about it). I'm a lot more worried about screwing up the terminal emulation
(or the timeout semantics in SSP, which are a bit byzantine) than the
possibility that Google will screw us over on protobuf.

Our intention is that that any mosh-client since 0.96 (February 2012) and
any mosh-server since 1.0.9 (March 2012) can talk to each other and to the
most recent release and the Git tip.

On Thu, May 14, 2015 at 4:56 PM, James C. McPherson <
james.mcpher...@oracle.com> wrote:

>
> Hi Alex,
> thankyou for the quick and reassuring response.
>
> btw, is there a test suite to help confirm the hypothesis?
>
> James
>
> On 15/05/15 09:50 AM, Alex Chernyakhovsky wrote:
> > Hi James,
> >
> >  From my reading of
> > https://github.com/google/protobuf/blob/master/CHANGES.txt#L187, there
> > are no wire-level differences. As long as mosh builds, it should
> > stil=l be compatible across protobuf versions. I recently rebuilt
> > Fedora's mosh to work against libprotobuf.so.9, which IIRC is 2.6.1,
> > and I noticed no issues.
> >
> > The protobuf generated output source should be different, since protoc
> > got new features.
> >
> > Sincerely,
> > -Alex
> >
> >
> > On Thu, May 14, 2015 at 7:44 PM, James C. McPherson
> >  wrote:
> >> Hi mosh-devel,
> >> I've observed that Google Protobuf has made some incompatible
> >> changes between v2.5 and 2.6.1.
> >>
> >> When I built mosh for Solaris (internal testing / evaluation
> >> work), I used 2.5 and all seemed well. I built it again today
> >> using 2.6.1 - and again, all seems ok, but the protobuf generated
> >> output is different between the two versions.
> >>
> >> Does mosh have a dependency on a specific version of Google
> >> protobuf?
> >>
> >>
> >> thanks in advance,
> >> James C. McPherson
> >> --
> >> Oracle
> >> Systems / Solaris / Core
> >> https://www.jmcpdotcom.com/blog
> >> ___
> >> mosh-devel mailing list
> >> mosh-devel@mit.edu
> >> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
> --
> James C. McPherson
> --
> Oracle
> Systems / Solaris / Core
> https://www.jmcpdotcom.com/blog
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Lazy buffers?

[Keith Winstein]

Great!

If you wanted to try to add local prediction for up- and down-arrow,
https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc#L824-L836
would be the place to do it.

I don't think we have that high a probability of successfully predicting
these locally very often, though, but maybe in a lowbandwidth mosh it's
worth it just to move the cursor so the user can see that they've done
something?

On Mon, Apr 27, 2015 at 8:44 PM, Robert Redelmeier 
wrote:

>   Success!  (Thanks for the tip about debian/control).
>
> -b lowbandwith has the delays I suggested.  --predict=[DEFAULT]
> and sightly better --predict=experimental  give that neat underlining
> that disappears and fixes itself when wrong (like vim k for scroll up).
>
> Horizontal cursor <- and -> work fine, without delays (or at least
> working on the buffer).  But vertical scrolling has maddening delays
> and slow visual feedback.  Hard to correctly position cursor.
>
> -- Robert
>
>
> On 1657-0700 Tue 21 Apr, Keith Winstein wrote in part:
> > Can you give a try to the lowbandwidth branch with the
> > --predict=experimental command-line option? You might find that
> > to be more to your liking.
> >
> > We could flush out on certain characters -- that would be reasonable (but
> > not currently implemented).
> >
> > Cheers,
> > Keith
> >
> > On Tue, Apr 21, 2015 at 4:49 PM, Robert Redelmeier  >
> > wrote:
> >
> > > On 0022-0700 Tue 21 Apr, Keith Winstein wrote in part:
> > > > Hello Robert, Thanks for your email!
> > >
> > > And thank you in turn for your prompt and detailed reply.
> > >
> > > > We do this to a degree,
> > > > but with the goal of _reducing_ latency -- please see Figure
> > > > 3 of the Mosh paper ( https://mosh.mit.edu/mosh-paper.pdf).
> > >
> > > Fascinating!  This 8ms is far too fast for human input, could
> > > it be something like ACK & echo packet combining, or combining
> > > from terminal local [cut'n']paste?
> > >
> > > > With the constants tuned differently, we end up reducing the
> > > > packets sent as you suggest. This is in the "lowbandwidth"
> > > > branch in the Git repository.  > > Cheers, > Keith
> > >
> > > I had a peek, thanks, but could not see how this would work
> > > differently from termios.c_cc(VTIME)=5 beyond ^C handling.  I tried
> > > this dumb delay, and the added latency on top of a slow connection
> > > was very irksome.  But I found I could reduce the irritation greatly
> > > by forcing the buffer out early when a command char was received.
> > > Could the special handling for ^C be expanded to all ^char plus
> > > duplicated chars (many pgms use hjkl for cursor movement)?
> > >
> > > Latency during straight typing is far less annoying unless chars
> > > are lost.  Of course this system generates lots of false flushes.
> > > But who cares?  Even `bookkeepers` sent as 4 packets is much better
> > > than 11, especially considering the "ACK-echo-ACK" multiplication.
> > >
> > >
> > > > On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier <
> red...@sbcglobal.net
> > > >
> > > > wrote:
> > > >
> > > > >  First, thanks y'all for your work on mosh!
> > > > > Second, a suggestion for your consideration (_NOT_ a vile "feature
> > > > > request"):
> > > > >
> > > > > Have you considered allowing send buffers to fill a bit before
> > > > > sending?  Not sending ASAP, but often sending more than one char
> > > > > per packet?  Of course this increases latency, but reduces packet
> > > > > count _tremendously_ and data usage likewise since the payload is
> > > > > tiny compared to overhead (incl ACK)..
> > > > >
> > > > > Not sure how this would interact with SSP, but I hacked ssh to do
> > > > > this 10+ years ago.  To minimize the latency when it would most
> > > > > annoy, the buffer was released if a command was received or when
> > > > > typing stopped for 300-600ms.  Commands were considered to be any
> > > > > control-char or any duplicated char (likely to be cursor movement).
> > > > >
> > > > > Of course, latency is sometimes noticeable but that is the price
> > > > > of reduced transmission data.  Most of the time, I'm typing blind
> > > > > anyways -- I'm not going to focus on the screen unless needed.
> > > > > Sometimes the reductions were as large as 70%, more often 50%.
> > > > >
> > > > > -- Robert in Houston
> > > > >
> > > > >
> > > > > ___
> > > > > mosh-devel mailing list
> > > > > mosh-devel@mit.edu
> > > > > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> > > > >
> > >
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Lazy buffers?

[Keith Winstein]

Can you give a try to the lowbandwidth branch with the
--predict=experimental command-line option? You might find that to be more
to your liking.

We could flush out on certain characters -- that would be reasonable (but
not currently implemented).

Cheers,
Keith

On Tue, Apr 21, 2015 at 4:49 PM, Robert Redelmeier 
wrote:

> On 0022-0700 Tue 21 Apr, Keith Winstein wrote in part:
> > Hello Robert, Thanks for your email!
>
> And thank you in turn for your prompt and detailed reply.
>
> > We do this to a degree,
> > but with the goal of _reducing_ latency -- please see Figure
> > 3 of the Mosh paper ( https://mosh.mit.edu/mosh-paper.pdf).
>
> Fascinating!  This 8ms is far too fast for human input, could
> it be something like ACK & echo packet combining, or combining
> from terminal local [cut'n']paste?
>
> > With the constants tuned differently, we end up reducing the
> > packets sent as you suggest. This is in the "lowbandwidth"
> > branch in the Git repository.  > > Cheers, > Keith
>
> I had a peek, thanks, but could not see how this would work
> differently from termios.c_cc(VTIME)=5 beyond ^C handling.  I tried
> this dumb delay, and the added latency on top of a slow connection
> was very irksome.  But I found I could reduce the irritation greatly
> by forcing the buffer out early when a command char was received.
> Could the special handling for ^C be expanded to all ^char plus
> duplicated chars (many pgms use hjkl for cursor movement)?
>
> Latency during straight typing is far less annoying unless chars
> are lost.  Of course this system generates lots of false flushes.
> But who cares?  Even `bookkeepers` sent as 4 packets is much better
> than 11, especially considering the "ACK-echo-ACK" multiplication.
>
>
> > On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier  >
> > wrote:
> >
> > >  First, thanks y'all for your work on mosh!
> > > Second, a suggestion for your consideration (_NOT_ a vile "feature
> > > request"):
> > >
> > > Have you considered allowing send buffers to fill a bit before
> > > sending?  Not sending ASAP, but often sending more than one char
> > > per packet?  Of course this increases latency, but reduces packet
> > > count _tremendously_ and data usage likewise since the payload is
> > > tiny compared to overhead (incl ACK)..
> > >
> > > Not sure how this would interact with SSP, but I hacked ssh to do
> > > this 10+ years ago.  To minimize the latency when it would most
> > > annoy, the buffer was released if a command was received or when
> > > typing stopped for 300-600ms.  Commands were considered to be any
> > > control-char or any duplicated char (likely to be cursor movement).
> > >
> > > Of course, latency is sometimes noticeable but that is the price
> > > of reduced transmission data.  Most of the time, I'm typing blind
> > > anyways -- I'm not going to focus on the screen unless needed.
> > > Sometimes the reductions were as large as 70%, more often 50%.
> > >
> > > -- Robert in Houston
> > >
> > >
> > > ___
> > > mosh-devel mailing list
> > > mosh-devel@mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> > >
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Lazy buffers?

[Keith Winstein]

Hello Robert,

Thanks for your email! We do this to a degree, but with the goal of
_reducing_ latency -- please see Figure 3 of the Mosh paper (
https://mosh.mit.edu/mosh-paper.pdf).

With the constants tuned differently, we end up reducing the packets sent
as you suggest. This is in the "lowbandwidth" branch in the Git repository.

Cheers,
Keith

On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier 
wrote:

>  First, thanks y'all for your work on mosh!
> Second, a suggestion for your consideration (_NOT_ a vile "feature
> request"):
>
> Have you considered allowing send buffers to fill a bit before
> sending?  Not sending ASAP, but often sending more than one char
> per packet?  Of course this increases latency, but reduces packet
> count _tremendously_ and data usage likewise since the payload is
> tiny compared to overhead (incl ACK)..
>
> Not sure how this would interact with SSP, but I hacked ssh to do
> this 10+ years ago.  To minimize the latency when it would most
> annoy, the buffer was released if a command was received or when
> typing stopped for 300-600ms.  Commands were considered to be any
> control-char or any duplicated char (likely to be cursor movement).
>
> Of course, latency is sometimes noticeable but that is the price
> of reduced transmission data.  Most of the time, I'm typing blind
> anyways -- I'm not going to focus on the screen unless needed.
> Sometimes the reductions were as large as 70%, more often 50%.
>
> -- Robert in Houston
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] ssp, verse, and documentation

[Keith Winstein]

Hello Alex,

I think it's unlikely that the SSP implementation will be directly
helpful to another project, but it may be worth a look.

https://github.com/keithw/mosh/tree/master/src/network

https://mosh.mit.edu/mosh-paper-draft.pdf (has more information than
the published version)

http://nms.csail.mit.edu/papers/loginessay.pdf

Best regards,
Keith

On Wed, Feb 25, 2015 at 10:46 AM, Alex Davies  wrote:
> Hey, where would I look to find more information about the state
> synchronization protocol?
>
>
> Another project, verse tries to do the same sort of state synchronization,
> but less elegantly in some ways.
>
> It includes a tree like data structure. Equivelent to the DoM or a file
> system.
>
> Anyway, it looked like it could be interesting to see if there's anywhere
> SSP can do the heavy lifting in verse.
>
> --
> With dread but cautious optimism, Alex Davies.
> traverse...@gmail.com
> +1 902 580 1543
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] predictive local echo

[Keith Winstein]

It might be reasonable to special-case this panel separator and stop moving
the line of text over when you reach that special character...

I think we would probably take this patch if it's simple.

https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc
is where the prediction is implemented.

Best regards,
Keith

On Mon, Dec 29, 2014 at 11:30 AM, David Manouchehri <
da...@davidmanouchehri.com> wrote:

> Hi Keith,
>
> Do you have a suggestion on how to prevent the predictive local echo
> from moving any "|" panel separator? I'm going to try to fix it
> myself, but I was hoping you'd be able to point me in the right
> direction.
>
> Video:
> http://youtu.be/1kmtoy_MSnc
>
> Report:
> https://github.com/keithw/mosh/issues/574
>
> Thanks.
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] error on the page https://mosh.mit.edu/

[Keith Winstein]

Hello Max,

The "s" is there already -- perhaps it is just getting wrapped to the next
line based on your browser width?

Best regards,
Keith

On Tue, Nov 25, 2014 at 2:17 AM, Max.Goncharov  wrote:

> Hi
>
> during the install instructions for Ubuntu the “s” missing in
>
> sudo apt-get install python-software-propertie(s)
>
>
> should be
>
> sudo apt-get install python-software-properties
>
>
> --
> ICQ: 6507622
> AIM: gmaxatwork
> Skype: gmax_at_work
> WWW: http://gmax.at
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh package in Alpine Linux

[Keith Winstein]

Thanks, Francesco. Please submit a pull request to the moshweb repository (
https://github.com/keithw/moshweb) if you would like these instructions
added to the Web page.

Best regards,
Keith

On Wed, Oct 15, 2014 at 11:11 PM, Francesco Colista <
fcoli...@alpinelinux.org> wrote:

> Hello guys,
> this is just to inform you that a mosh package is available in the main
> repository of Alpine Linux distribution (www.alpinelinux.org).
>
> Id is possible to install with:
>
> apk add mosh
>
> Thanks for you attention.
>
> --
> :: Francesco Colista
> :: Alpine Linux Infrstraucture
> :: http://www.alpinelinux.org
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] mosh-server doesn't display (all of) the motd on Ubuntu Trusty machines

[Keith Winstein]

Thanks, Jonathon. mosh-server just copied what OpenSSH sshd does. Do you
know how OpenSSH knows it's supposed to print /run/motd.dynamic? (Does
Ubuntu patch it? Is there some other location to look at?) If so, maybe we
should take the same patch for the Ubuntu packages of mosh.

Cheers,
Keith

On Mon, Sep 15, 2014 at 4:27 PM, Jonathon Weiss  wrote:

>
> On Ubuntu (at least Trusty) machines the motd is split between
> /etc/motd and /run/motd.dynamic .  Note that Ubuntu Precise handles
> this differently and /etc/motd is a symlink to /var/run/motd .  So on
> Trusty machines where mosh-server prints /etc/motd, it misses all
> content in /run/motd.dynamic (on the athena dialups that is all motd
> content, as none of it is in /etc/motd .)  "man motd" on both Precise
> and Trusty contains some useful information.
>
> Jonathon
>
> Jonathon Weiss 
> MIT/IS&T/O&I  Server Operations
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] State Synchronization Protocol

[Keith Winstein]

Not really, no. You might find these helpful:

http://mosh.mit.edu/mosh-paper-draft.pdf (longer version)
http://mosh.mit.edu/mosh-paper.pdf

Best regards,
Keith

On Wed, Aug 6, 2014 at 10:40 AM, David Shur  wrote:
> Great - I will try that. Is the API documented somewhere?
>
> Thanks,
> David.
> -
>
> On 8/5/2014 6:24 PM, Keith Winstein wrote:
>>
>> Hello David,
>>
>> Yes, please see
>> https://github.com/keithw/mosh/tree/master/src/network, which builds
>> libmoshnetwork.a in the Mosh source tree.
>>
>> Best regards,
>> Keith
>>
>> On Tue, Aug 5, 2014 at 11:26 AM, David Shur  wrote:
>>>
>>> Hi,
>>>
>>> I am interested in using the State Synchronization Protocol
>>> independently of mosh (i.e., for another data sharing application that
>>> is not terminal oriented). Is there a library and/or API available for
>>> this purpose?
>>>
>>> Thanks,
>>> David.
>>>
>>> --
>>> David Shur, Ph. D
>>> Applied Communication Sciences
>>> 150 Mount Airy Road
>>> Basking Ridge, NJ 07920
>>> Phone: 1-908-748-2018 (off) 1-732-429-4429 (cell)
>>> e-mail: ds...@appcomsci.com
>>>
>>>
>>> ___
>>> mosh-devel mailing list
>>> mosh-devel@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
>
> --
> David Shur, Ph. D
> Applied Communication Sciences
> 150 Mount Airy Road
> Basking Ridge, NJ 07920
> Phone: 1-908-748-2018 (off) 1-732-429-4429 (cell)
> e-mail: ds...@appcomsci.com
>
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] State Synchronization Protocol

[Keith Winstein]

Hello David,

Yes, please see
https://github.com/keithw/mosh/tree/master/src/network, which builds
libmoshnetwork.a in the Mosh source tree.

Best regards,
Keith

On Tue, Aug 5, 2014 at 11:26 AM, David Shur  wrote:
> Hi,
>
> I am interested in using the State Synchronization Protocol
> independently of mosh (i.e., for another data sharing application that
> is not terminal oriented). Is there a library and/or API available for
> this purpose?
>
> Thanks,
> David.
>
> --
> David Shur, Ph. D
> Applied Communication Sciences
> 150 Mount Airy Road
> Basking Ridge, NJ 07920
> Phone: 1-908-748-2018 (off) 1-732-429-4429 (cell)
> e-mail: ds...@appcomsci.com
>
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] measuring disconnectivity

[Keith Winstein]

Short answer is "not right now." For the future, we have been thinking
about the best way to give Mosh an opt-in voluntary scheme to collect some
network info and contribute it anonymously for future research. Could be a
great way to monitor the health of the Internet and the frequency of actual
mobility.

But we need to figure out a way to do it that doesn't freak people out
(even if it's opt-in), and I don't really want to know who is talking to
whom.

For the present, you could probably come up with a patch for the
mosh-server that has it write out the time difference between the last-sent
state and the last acknowledged state to a file every time there's a new
state.

-Keith


On Mon, Jun 2, 2014 at 6:19 PM, Dave Taht  wrote:

> I usually have a mosh session nailed up going multiple hops through a
> wireless network that
> frequently goes down, so here I sit with a nice means of continually
> measuring, without
> ping, what's going on on my network.
>
> is there a way to pull out timestamped packet loss statistics from
> mosh and/mosh daemon?
>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Mosh.

[Keith Winstein]

Hello Jonathan,

Happy to hear Mosh is helpful! Re: an API, you might take a look at
how the mosh-client program is implemented
(https://github.com/keithw/mosh/blob/master/src/frontend/mosh-client.cc).
It instantiates an STMClient object, calls the init() method, and then
the main() method, which encapsulates the whole eventloop.

Not sure if this is quite what you're looking for, but maybe if you
tell us some more about your use case we might be able to be more
helpful. As you probably know, Mosh is really only useful for
conveying an interactive terminal over the network; it's not really
set up to be a general communications layer for arbitrary streams.

Best regards,
Keith

On Fri, May 2, 2014 at 6:54 PM, Jonathan Barronville
 wrote:
> Hi, Keith.
>
> My name is Jonathan Barronville. I'm a hacker here in Boston.
> I've been using Mosh for a while now and I really really enjoy it.
> Thanks so much for building it!
>
> Anyway, I'm working on a project for virtual machine management and I want
> to use Mosh for the communication layer, rather than simply using SSH. Now,
> I have a fairly good understanding of how Mosh works and have even glanced
> through some of the code, but I was somewhat disappointed to find that Mosh
> doesn't have some type of main high-level C (or even C++) API I could use.
> In other words, it would be great if I could just link to libmosh or
> something like that, include a header, and just call a couple high-level
> functions. Maybe I'm not looking in the right place ... how straightforward
> is this with Mosh? All I need is a main entry point (like a header) to use
> some high-level Mosh functions (something like `mosh_connect()` for
> example).
>
> Please let me know what you think or at least, if possible, give me a few
> pointers.
> Thanks!
> Have a good one!
>
> - Jonathan
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] donate?

[Keith Winstein]

Hi Jeffrey,

Thank you for your very kind email! We're grateful for your support
and it's great to hear that Mosh helped you out.

The easiest way may be to make a donation to the MIT Student
Information Processing Board, a student club that most of the Mosh
developers belonged to, by going to https://giving.mit.edu and making
a donation to their account "Student Information Processing Board Fund
(2721388)".

Please also feel free to make a donation to the Free Software
Foundation if you prefer that.

Either way, please let us know if you would like to be acknowledged in
the release notes for the next version of Mosh.

Thank you again!

Best regards,
Keith

On Wed, Apr 30, 2014 at 3:35 AM, Jeffrey Milloy
 wrote:
> Hello
>
> Can I donate to the Mosh project? If not, is there somewhere you would like
> a donation to go?
>
> It's made me very very happy this evening.
>
> Jeff
>
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Website error

[Keith Winstein]

Thanks for reporting this. Do you know what the correct Cygwin link should
be?

Thank you,
Keith


On Thu, Feb 27, 2014 at 11:57 AM, P. Blissenbach  wrote:

> Hi,
> I am new to this list, and only popping in to tell that the cygwin part on
> the website
> http://mosh.mit.edu/#getting
> has a broken link.
>
> greetings.
>
> Purodha
>
> --
> (this e-mail probably scanned by NSA and GCHQ and others)
> ___
> mosh-devel mailing list
> mosh-devel@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] [mosh-users] Logging from mosh-server

[Keith Winstein]

On Wed, Jan 1, 2014 at 11:06 PM, Jim Cheetham  wrote:
> Currently I'm on at 13:20 WST (Perth, Australia) on Thursday 9 Jan. I don't
> know your timezone, but that'll be between 9pm and midnight on *Wednesday*
> for the US
> (http://www.timeanddate.com/worldclock/fixedtime.html?msg=lca2014mosh&iso=20140109T13&p1=196).
> If you could start up a new IRC channel for this, I'll pop it up onscreen
> during the Q&A.

Ok, Jim, let's do it in #moshqa on irc.freenode.org. I'll be there.

If I understand your concern correctly, you are concerned that the
mosh-server will decode IP datagrams with any source address. By
contrast, SSH relies on TCP, which only looks at incoming IP datagrams
with a particular source address.

I think where we disagree is that we do not think TCP's filtering by
IP source address has a material effect on security. You
cannot trust that the IP source address is accurate. In general, one
should assume that a bad guy who exfiltrates the SSH session key OR
the Mosh session key can take control of the user's account on the
server. Both session keys (SSH and Mosh) hold the "keys to the
kingdom" in this respect. Of course if a site takes extra steps to make
the IP source address trustworthy (e.g. by requiring packets to come
from an authenticated VPN), both protocols benefit to some degree.

In general, compared with SSH, we think the security of a long-running
Mosh session is probably better because (a) Mosh's AEAD cryptography is
thought to be safer, (b) Mosh authenticates the framing of each
datagram, so is not vulnerable to fake RST and similar DOS attacks (c)
Mosh's design is simpler and more conservative (e.g., Mosh has no code
running as root), and (d) so far Mosh's emprical security track record is
better. Time will tell on all these things, and of course it's
appropriate that the security community take its time getting
comfortable with Mosh -- we welcome the scrutiny and are happy to
participate.

Looking forward to your presentation and answering questions if I can help.

Best regards,
Keith
___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] Announcment feed?

[Keith Winstein]

Hello David,

Please feel free to subscribe to the mosh-users or mosh-devel lists
(listed at http://mosh.mit.edu). Future Mosh releases will be
published in the same PPA (just as before) so you could also just add
it and wait for a release. There is also the ppa:keithw/mosh-dev PPA,
which receives more frequent updates.

Best regards,
Keith

On Thu, Jan 2, 2014 at 9:55 AM, d❤vid seaward  wrote:
> Hello Keith,
>
> I've just realised that since I use Ubuntu Saucy, I won't now if a new
> stable release appears on the mosh PPA. I couldn't find an Atom/RSS
> announcements feed to subscribe to. Is there one, and if not would you
> consider creating one?
>
> Many thanks.
>
> David
> --
> This message was sent from Launchpad by
> =?utf-8?b?ZOKdpHZpZCBzZWF3YXJk?= (https://launchpad.net/~kwill)
> using the "Contact this user" link on your profile page
> (https://launchpad.net/~keithw).
> For more information see
> https://help.launchpad.net/YourAccount/ContactingPeople

___
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

Re: [mosh-devel] [mosh-users] Logging from mosh-server

[Keith Winstein]

Hello Jim,

I'd be happy to participate on IRC if you think that would be helpful --
just let me know the date/time.

You're in good company in suggesting the idea of renegotiation and (broadly
speaking) more bells and whistles in the protocol. And we may do this kind
of thing in the future, especially as we want to support proxying of a Mosh
session through a bastion host (letting the proxy track the authentic
roaming client, without giving the proxy the plaintext) and things like
keeping a session open over reboot.

But here's why we have been cautious: if you look at *why* SSH v1 was
fatally broken, and why SSH v2 (CBC mode) was broken, and why SSL v1 and v2
and v3 and TLS v1 were broken, and the various bugs in SSH (the
implementation) over the years, many of those breaks are attributable to
exactly the kind of options and bells and whistles that Mosh has really
resisted implementing.

The Mosh protocol is simple on purpose and that simplicity is partly to
credit with our good record so far -- in the nearly two years since Mosh
1.0 was released, we have not had a security vulnerability yet. I say "so
far" because inevitably we will have one at some point, just like everybody
else. But to date, Mosh's security record looks considerably better than
the implementations of SSH, SSL, TLS, and DTLS -- to put it frankly, how
much do we really want to emulate those systems?

>From a cryptographic perspective, Mosh (with its pinned AEAD mode) is
probably better than SSH's encrypt-and-MAC and also better than TLS's
MAC-then-encrypt. From a DoS perspective, both SSH and TLS are vulnerable
to the simple attack where a bad guy (not even an eavesdropper) sends a TCP
RST segment to end the connection, because SSH and TLS use cleartext TCP
for the session. Mosh of course applies integrity checking to the whole
datagram and isn't fooled by fake resets.

You're right that a bad guy who steals the session key from a mobile device
can "roam" the session elsewhere. Compromise of the client is a difficult
attack to counteract. A bad guy who steals the session key would probably
be able to use a nearby sequence number -- either by stealing the sequence
number at the same time, or just reading a recent sequence number off the
wire. (Like SSH, TLS, and DTLS, Mosh sends the sequence number in the
clear.)

A bad guy who steals an SSH session key can't roam the session, but they
probably don't need to -- in most attack scenarios that would let a bad guy
grab the session key, the attacker can just send a series of keystrokes to
install their own public key as trusted or curl | sh an arbitrary shell
script. (Either by sending them from the SSH client itself, or by send TCP
segments encoding the keystrokes. The sender does not need to receive the
acknowledgments for SSH to receive and pass the keystrokes to the running
application.) Of course Mosh is the same in this respect -- it's hard to
defend against a client compromise.

I like your suggestion to log crypto exceptions to syslog for the benefit
of an IDS, and I don't think it would be too hard for us to do this.

We're grateful for your interest in Mosh and I look forward to hearing
about your presentation. Please let me know if you'd like me to participate
in the Q&A and I'm happy to do it.

Cheers,
Keith

On Mon, Dec 30, 2013 at 8:36 PM, Jim Cheetham 
 wrote:

> (sorry about the quoting, webmail isn't quite so flexible as my normal MTA)
>
> --
> *From:* winst...@gmail.com [winst...@gmail.com] on behalf of Keith
> Winstein [kei...@mit.edu]
> *Sent:* Friday, 27 December 2013 6:21 a.m.
>
> > If the badguy is running as the user, they could start up a fresh SSH or
> Mosh (or anything) connection and log in from anywhere -- no need to hijack
> an existing connection, although they could do that too.
>
> I was more concerned about a key being stolen from the mobile device, and
> exfiltrated to the bad guy elsewhere. Where TCP-based connections require
> an attacker to spoof the original source address as well as the session
> credentials, mosh has only the session credentials; you don't seem to have
> any protection against large jumps in the sequence number as an indication
> of attack for example, or invalid packets for a connection coming from
> different sources. Looking from outside the application, from an IDS
> perspective, will help for some of this but won't help to understand the
> contents of the packets.
>
> > A sequence number is a 63-bit unsigned integer. There's no wraparound. A
> legitimate SSP sender will simply end the connection after two petabytes of
> data have been sent to preserve the authenticity and privacy of the AES-OCB
> stream. There is no key renegotiation.
>
> 2PB is of course immense, but in the long term I think y