Bug#1072233: mosh: use wtmpdb to write wtmp entries

2024-05-30 Thread 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
>

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

2022-02-17 Thread Keith Winstein 
forwarded 1005718 https://github.com/mobile-shell/mosh/issues/1174
thankyou


On Sun, Feb 13, 2022 at 1:03 PM Sebastian Andrzej Siewior
 wrote:
>
> Source: mosh
> Version: 1.3.2-2.1
> Severity: important
> Tags: bookworm sid
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: ftbfs-3.0
>
> Your package is failing to build using OpenSSL 3.0 with the
> following error:
>
> | c++ -DHAVE_CONFIG_H -I. -I../..  -I./../util  -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -pedantic -Wno-long-long -Weffc++ 
> -Wmissing-declarations -fno-strict-overflow -D_FORTIFY_SOURCE=2 
> -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fPIE 
> -fno-default-inline -pipe -g -O2 -ffile-prefix-map=/<>=. 
> -Wformat -Werror=format-security -c -o ocb.o ocb.cc
> | ocb.cc: In function ‘void AES_ecb_encrypt_blks(block*, unsigned int, 
> AES_KEY*)’:
> | ocb.cc:360:80: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   360 |   AES_encrypt((unsigned char *)(blks+nblks), (unsigned char 
> *)(blks+nblks), key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘void AES_ecb_decrypt_blks(block*, unsigned int, 
> AES_KEY*)’:
> | ocb.cc:367:80: error: ‘void AES_decrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   367 |   AES_decrypt((unsigned char *)(blks+nblks), (unsigned char 
> *)(blks+nblks), key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:60:6: note: declared here
> |60 | void AES_decrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘int ae_init(ae_ctx*, const void*, int, int, int)’:
> | ocb.cc:804:75: error: ‘int AES_set_encrypt_key(const unsigned char*, int, 
> AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   804 | AES_set_encrypt_key((unsigned char *)key, key_len*8, 
> >encrypt_key);
> |   | 
>   ^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:51:5: note: declared here
> |51 | int AES_set_encrypt_key(const unsigned char *userKey, const int 
> bits,
> |   | ^~~
> | ocb.cc:808:82: error: ‘int AES_set_decrypt_key(const unsigned char*, int, 
> AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   808 | AES_set_decrypt_key((unsigned char *)key, (int)(key_len*8), 
> >decrypt_key);
> |   | 
>  ^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:54:5: note: declared here
> |54 | int AES_set_decrypt_key(const unsigned char *userKey, const int 
> bits,
> |   | ^~~
> | ocb.cc:817:76: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   817 | (unsigned char *)>Lstar, 
> >encrypt_key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘block gen_offset_from_nonce(ae_ctx*, const void*)’:
> | ocb.cc:854:72: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |   854 |   AES_encrypt(tmp.u8, (unsigned char *)>KtopStr, 
> >encrypt_key);
> |   | 
>^
> | In file included from ocb.cc:354:
> | /usr/include/openssl/aes.h:57:6: note: declared here
> |57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
> |   |  ^~~
> | ocb.cc: In function ‘int ae_decrypt(ae_ctx*, const void*, const void*, 
> int, const void*, int, void*, const void*, int)’:
> | ocb.cc:1338:68: error: ‘void AES_encrypt(const unsigned char*, unsigned 
> char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0 
> [-Werror=deprecated-declarations]
> |  1338 | AES_encrypt((unsigned char *), tmp.u8, 
> >encrypt_key);
> |   |^
> | In file included from ocb.cc:354:
> |

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

2020-12-18 Thread Keith Winstein 
Hi, sorry, I should have clarified that I am also the upstream maintainer,
and I keep the "debian" directory in the same source repository as
everything else. That's what I meant about submitting a pull request on
GitHub. It would still be a modification to debian/rules.

The backstory here is that because those mahimahi programs (mm-link,
mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root,
we are paranoid about using PATH at runtime. So we try to resolve these
absolute pathnames at build-time. If Debian wants to hardcode the
locations, fine with me.

I am curious -- why is it important that builds be identical between
usrmerge systems and non-usrmerge systems? It's not like we try to have
builds be identical between systems with different versions of the
compiler, etc. Still, though, if this is the notion of reproducibility that
Debian wants its packages to have, I'm happy to comply and have no quibbles
with your patch.

Cheers,
Keith



On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> On 2020-12-18, Keith Winstein wrote:
> > Thank you for tracking this down! Happy to take the patch -- would you
> mind
> > filing this as an upstream pull request at
> > https://github.com/ravinet/mahimahi ? That way we will have this in one
> > place when we next have cycles to upload a new mahimahi package.
>
> I'm not sure an "upstream" patch would make sense in this specific case;
> in Debian, the most compatible path should be in /bin and /sbin, but
> this would not necessarily be the case with all distros, and relying on
> the path detection might actually be appropriate in some cases.
>
> So the patch I submitted only modifies debian/rules, not any of the
> upstream code.
>
>
> An upstream fix *might* be to not embed the full paths at all, and rely
> a working system PATH, though there may be cases where this does not
> work... but I am not familiar enough with mahimahi to know if that would
> be workable. The upstream code that triggers this is the use of
> AC_PATH_PROG in configure.ac.
>
> For what it's worth, it also embeds the path to other binaries through
> AC_PATH_PROG, but many of those don't change on a Debian usrmerge
> system.
>
>
> Happy to dialog a little further to sort this out, and thanks for the
> quick response!
>
>
> live well,
>   vagrant
>

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

2020-12-18 Thread Keith Winstein 
Thank you for tracking this down! Happy to take the patch -- would you mind
filing this as an upstream pull request at
https://github.com/ravinet/mahimahi ? That way we will have this in one
place when we next have cycles to upload a new mahimahi package.

Sincerely,
Keith

On Fri, Dec 18, 2020 at 12:45 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> Source: mahimahi
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: usrmerge
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The paths to "iptables" and "ip" may vary when built on a usrmerge and
> non-usrmerge system, and get embedded in /usr/bin/mm-link and possibly
> other binaries:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/mahimahi.html
>
> It's a little hard to notice, but I caught these differences in mm-link:
>
>   /sbin/ipH
>   vs.
>   /usr/sbiH
>
>
> The attached patch fixes this by passing IPTABLES and IP to configure in
> debian/rules. With this patch applied, it should build reproducibly in
> our test infrastructure.
>
>
> Thanks for maintaining mahimahi!
>
>
> live well,
>   vagrant
>

Bug#920698: mosh-server not found

2019-01-28 Thread Keith Winstein 
Hello -- unfortunately mosh-server does need to be installed on the server
(it is sort of like ssh in this respect). You can either install it from a
package (which probably requires root -- you would need to ask the
sysadmin), or you can compile it from source, install it in your own home
directory, and give the location when starting mosh (e.g. "mosh
--server=/home/kaction/bin/mosh-server"). There are some instructions at
https://mosh.org you may find helpful.

Best regards,
Keith

On Mon, Jan 28, 2019 at 4:39 AM Dmitry Bogatov  wrote:

>
> Package: mosh
> Version: 1.3.2-2.1+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> maybe I am doing it wrong, but I fail to make mosh do anything. Any
> attempt to connect host results in:
>
> $ mosh kact...@people.debian.org
> bash: mosh-server: Komando ne trovita
> Connection to people.debian.org closed.
> /usr/bin/mosh: Did not find mosh server startup message. (Have you
> installed mosh on
> your server?)
>
> Isn't it the idea, that mosh-server gets installed automatically?
> Obliviously, I do not have permission to do `apt-get install mosh' on
> remote host.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500,
> 'testing'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages mosh depends on:
> ii  dpkg1.19.2
> ii  libc6   2.28-5
> ii  libgcc1 1:8.2.0-14
> ii  libprotobuf17   3.6.1.3-1
> ii  libssl1.1   1.1.1a-1
> ii  libstdc++6  8.2.0-14
> ii  libtinfo6   6.1+20181013-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.9p1-5
> ii  zlib1g  1:1.2.11.dfsg-1
>
> Versions of packages mosh recommends:
> pn  libio-socket-ip-perl  
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#899300: mosh: apt-get install error in jessie-backports

2018-05-22 Thread Keith Winstein 
Thank you for the bug report. I believe this is a duplicate of bug 803253,
which was fixed in mosh 1.2.5-1.1.

2018-05-22 1:08 GMT-07:00 ikar.us :

> Package: mosh
> Version: 1.2.5-1~bpo8+1
> Severity: important
>
>
> root@:~# apt-get -t jessie-backports install mosh
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
> Statusinformationen werden eingelesen Fertig
> Die folgenden Pakete wurden automatisch installiert und werden nicht mehr
> benötigt:
>   libevent-2.0-5 libnfsidmap2 libtirpc1 php5-sqlite
> Verwenden Sie »apt-get autoremove«, um sie zu entfernen.
> Die folgenden zusätzlichen Pakete werden installiert:
>   libprotobuf9 libutempter0
> Die folgenden NEUEN Pakete werden installiert:
>   libprotobuf9 libutempter0 mosh
> 0 aktualisiert, 3 neu installiert, 0 zu entfernen und 44 nicht
> aktualisiert.
> Es müssen 580 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 2.287 kB Plattenplatz zusätzlich benutzt.
> Möchten Sie fortfahren? [J/n] J
> Holen: 1 http://ftp.de.debian.org/debian/ jessie/main libprotobuf9 amd64
> 2.6.1-1 [361 kB]
> Holen: 2 http://ftp.de.debian.org/debian/ jessie/main libutempter0 amd64
> 1.1.5-4 [8.020 B]
> Holen: 3 http://ftp.de.debian.org/debian/ jessie-backports/main mosh
> amd64 1.2.5-1~bpo8+1 [211 kB]
> Es wurden 580 kB in 0 s geholt (2.867 kB/s).
> Vormals nicht ausgewähltes Paket libprotobuf9:amd64 wird gewählt.
> (Lese Datenbank ... 37354 Dateien und Verzeichnisse sind derzeit
> installiert.)
> Vorbereitung zum Entpacken von .../libprotobuf9_2.6.1-1_amd64.deb ...
> Entpacken von libprotobuf9:amd64 (2.6.1-1) ...
> Vormals nicht ausgewähltes Paket libutempter0 wird gewählt.
> Vorbereitung zum Entpacken von .../libutempter0_1.1.5-4_amd64.deb ...
> Entpacken von libutempter0 (1.1.5-4) ...
> Vormals nicht ausgewähltes Paket mosh wird gewählt.
> Vorbereitung zum Entpacken von .../mosh_1.2.5-1~bpo8+1_amd64.deb ...
> dpkg: Fehler: --compare-versions akzeptiert drei Argumente: 
>  
>
> Nutzen Sie dpkg --help für Hilfe zur Installation und Deinst. von Paketen
> [*];
> Benutzen Sie »apt« oder »aptitude« für benutzerfreundliches
> Paketmanagement;
> Nutzen Sie dpkg -Dhelp für eine Liste von Debug-Flags von dpkg;
> Nutzen Sie dpkg --force-help für eine Liste von Optionen zum Erzwingen;
> Nutzen Sie dpkg-deb --help für Hilfe zum Manipulieren von *.deb-Dateien;
>
> Optionen mit [*] geben viel aus - schicken Sie es durch »less« oder »more«!
> Entpacken von mosh (1.2.5-1~bpo8+1) ...
> Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
> libprotobuf9:amd64 (2.6.1-1) wird eingerichtet ...
> libutempter0 (1.1.5-4) wird eingerichtet ...
> Creating utempter group...
> mosh (1.2.5-1~bpo8+1) wird eingerichtet ...
> Trigger für libc-bin (2.19-18+deb8u10) werden verarbeitet ...
> root@:~#
>
>
>
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.17.27
> ii  libc6   2.19-18+deb8u10
> ii  libgcc1 1:4.9.2-10+deb8u1
> ii  libprotobuf92.6.1-1
> ii  libssl1.0.0 1.0.1t-1+deb8u8
> ii  libstdc++6  4.9.2-10+deb8u1
> ii  libtinfo5   5.9+20140913-1+deb8u2
> ii  libutempter01.1.5-4
> ii  openssh-client  1:6.7p1-5+deb8u4
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> Versions of packages mosh recommends:
> ii  libio-socket-ip-perl  0.32-1
> ii  perl-base [libio-socket-ip-perl]  5.20.2-3+deb8u10
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#870202: mosh-server failing to start with a missing symbol

2017-07-30 Thread Keith Winstein 
Thank you for this report. Is it possible you have a different version of
libprotobuf in your LD_LIBRARY_PATH, or a different version of mosh-server
in your PATH?

(Do you have anything related to libprotobuf in /usr/local ?)

On Sun, Jul 30, 2017 at 2:40 PM, Ivan Vucica  wrote:

> Package: mosh
> Version: 1.2.6-1+b2
> Severity: important
>
> Dear Maintainer,
>
> Yesterday I updated almost all of my system to stretch / stable.
> (Stragglers
> include things like php which might break some of my projects.)
>
> Today I am no longer able to connect to my server with mosh. Running
> mosh-server manually results in:
>
>   mosh-server: symbol lookup error: mosh-server: undefined symbol: _
> ZNK6google8protobuf11MessageLite25InitializationErrorStringB5cxx11Ev
>
> Perhaps there is some incompatibility with libprotobuf?
>
> Could we please patch stretch / stable?
>
> -- System Information:
> Debian Release: 9.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_US:en
> (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.24
> ii  libc6   2.24-11+deb9u1
> ii  libgcc1 1:6.3.0-18
> ii  libprotobuf10   3.0.0-9
> ii  libssl1.1   1.1.0f-3
> ii  libstdc++6  6.3.0-18
> ii  libtinfo5   6.0+20161126-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.4p1-10+deb9u1
> ii  zlib1g  1:1.2.8.dfsg-5
>
> Versions of packages mosh recommends:
> ii  perl-base [libio-socket-ip-perl]  5.24.1-3+deb9u1
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#854873: mosh FTBFS: FAIL local.test

2017-03-03 Thread Keith Winstein 
This is caused by #817236. We are working on a workaround.

On Sat, Feb 11, 2017 at 4:05 AM, Adrian Bunk  wrote:

> Source: mosh
> Version: 1.3.0~rc2-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=mosh
>
> ...
> FAIL: local
> ===
>
> ../../scripts/mosh: Did not find mosh server startup message. (Have you
> installed mosh on your server?)
> FAIL local.test (exit status: 10)
> ...
> 
> 
> Testsuite summary for mosh 1.3.0-rc2
> 
> 
> # TOTAL: 28
> # PASS:  4
> # SKIP:  23
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> 
> See src/tests/test-suite.log
> Please report to mosh-de...@mit.edu
> 
> 
> Makefile:853: recipe for target 'test-suite.log' failed
> make[6]: *** [test-suite.log] Error 1
>

Bug#844514: mosh: major issues with queued control sequences

2016-11-16 Thread Keith Winstein 
Hello Dominik,

Mosh, OpenSSH, and TELNET all just literally convey these characters from
the client to the pty. None of these programs try to interpret sequences
like "Ctrl-A n" or "ESC #". (To double-check, I have just tested ESC #
using "mosh localhost" and I could not see any difference in the behavior
with or without Mosh.)

I am not sure if you have identified a problem with screen and the timing
of its input, but I do not think this report describes a Mosh bug.

If you disagree, please consider opening a bug report with replication
instructions at the upstream GitHub: https://github.com/mobile-shell/mosh

Thank you,
Keith

On Wed, Nov 16, 2016 at 4:24 AM, Dominik George  wrote:

> Package: mosh
> Version: 1.2.6-1+b1
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I have trouble using mosh together with screen and even a normal shell
> because mosh does not handle control sequences correctly.
>
> Two example:
>
>   Ctrl-A n  for switching to the next screen inside GNU screen works
>   under normal circumstances, but when the connection gets bad and
>   mosh starts queueing and predicting things, once the connection comes
>   back, ^An is written to the shell verbatim, making the behaviour
>   wrong and non-deterministic and even leading to data corruption
>   if unnoticed.
>
>   Escape sequences, like  Esc #  for terminating the current shell
>   input line and prefixing it with a #, do not work at all.
>
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.10
> ii  libc6   2.24-5
> ii  libgcc1 1:6.2.0-10
> ii  libprotobuf10   3.0.0-7
> ii  libssl1.0.2 1.0.2j-1
> ii  libstdc++6  6.2.0-10
> ii  libtinfo5   6.0+20160917-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.3p1-2
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> Versions of packages mosh recommends:
> ii  libio-socket-ip-perl  0.37-1
> ii  perl-base [libio-socket-ip-perl]  5.24.1~rc3-3
>
> mosh suggests no packages.
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQJhBAEBCABLBQJYLFAAMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
> cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
> MOMP/i/hkXApBtJh6XQIPpgn+OCmQJ+0XU+KaAQs2/DHWZ3Hq8ECkL7wF8ZXB9RS
> gtMyDcLvCo7WTp6FWdAosZ3ScITn/gq99r+u74wKUdowPbVwykvnJDZZVDmE1JS6
> 3+EJujCBUMI6A8SldgtfDal9KCbVK+rOYayAf//lIoAkP32kT+Xy6vhCTuCRFcUB
> zHXGuYG0g0JeEjS8o01vsyDc9mrWamKId7gaHme3wNXWuUTILaxVC93O5XauBtYW
> VNjq9wNof/fR9lHAcTR1bSV2X+7mRUyRtmrznZ/H/ikw/0j/+V68HiYT0JE9hS1O
> bEo3nFlkOKAOk/zcMoYMdzM8pzQOXGQ72SymaEwb7H6R2R2rHHPTjhQtuByagHq8
> yvY58sQnmAhQ+UUK8d8JYJdBFxwVt6uVxrv6iYLhSM41tNsMzcQRUZcu9XfvDPaL
> XK6A2d/gdMRROYDExJQ0wontaaRqnPGPYbg/YLd/NrGuJsz5Ot3l2XqIFJF3tY8w
> ksac7cKThYS0SjdsJhtC/I657t2Acz8HNeSInJXX3s3seVuS3rqhLI0rfuJYeC8a
> jFTXfST0PQCAeXz41enan8DuewVlm+HFYfRd4+7L+fEJgLzTfUhZ0wI6Ua5KOToU
> Q6H9Hyo1mknfcvGTDghNfWNrOVr+uecLr/mRvrxGNnhSq4Jg
> =Av/J
> -END PGP SIGNATURE-
>

Bug#843523: mosh: screen corruption with long lines

2016-11-08 Thread Keith Winstein 
On Tue, Nov 8, 2016 at 1:53 AM, Philipp Marek 
wrote:

> > 3) Can you please send all *three* logs from "script"? We need
> simultaneous
> > captures of the output (1) entering tmux, (2) leaving tmux and entering
> > mosh, and then (3) leaving mosh.
> All three things are included in the previous file.
>
> > So three invocations of script, each
> > producing one logfile.
> Sorry, I don't understand. I need to call "script" before running tmux; how
> would I get the output of _leaving_ tmux alone? The "outer" script will
> still be running?
>

We need you to run three separate invocations of "script", each one writing
to a different logfile.

The first invocation will be before you even run mosh. Run something like
"script mosh_output" on your local machine.

Then, *inside the resulting shell*, run "mosh server".

Then, *inside that remote shell*, run "script tmux_output_and_mosh_input".

Then, *inside the resulting shell*, run tmux.

Then, *inside that*, run "script tmux_input".

Then, *inside the resulting shell*, do whatever you can do to demonstrate
the problem.

Then exit all the shells cleanly.

The result will be two logfiles on the remote machine ("tmux_input" and
"tmux_output_and_mosh_input") and one logfile on the local machine
("mosh_output").

We'll need to examine all three logfiles to figure out where the problem is
happening.

Thanks,
Keith

Bug#843523: mosh: screen corruption with long lines

2016-11-08 Thread Keith Winstein 
Thanks Philipp!

1) Can you fill me in -- what version of Mosh is running on the server in
your setup?

2) There are packages for pre-1.2.6 versions of Mosh in wheezy, jessie, and
jessie-backports (please see https://packages.debian.
org/search?keywords=mosh). You could also build from source (it would need
to be on both the client and server though to be sure).
https://mosh.org/mosh-1.2.5.tar.gz

3) Can you please send all *three* logs from "script"? We need simultaneous
captures of the output (1) entering tmux, (2) leaving tmux and entering
mosh, and then (3) leaving mosh. So three invocations of script, each
producing one logfile. (Use the command-line argument to give the logfile
name.) Also can you please tell me your terminal size so I can properly
replay the captures?

Thanks much,
Keith

On Tue, Nov 8, 2016 at 1:06 AM, Philipp Marek 
wrote:

> Hi Keith,
>
> > What version of Mosh is running on the server?
> > What architecture is the server (is it also a Debian amd64 machine)?
> Debian amd64, yes.
>
> > Could you please also test running Mosh 1.2.5 on the client *and* server,
> > and seeing if you can replicate the bug? That will help us determine if
> > this is a regression.
> Do you know when such a package was available in Debian, so that I can find
> it in the archives?
>
>
> > Depending on the results, the next request will be for you to use
> "script"
> > to capture the output (1) entering tmux, (2) leaving tmux and entering
> > mosh, and then (3) leaving mosh.
> Here you are.
>
>
> > Thanks very much for finding this,
> Hah! You're welcome, but I'd be happier if I didn't ;)
>
>
>

Bug#843523: mosh: screen corruption with long lines

2016-11-07 Thread Keith Winstein 
Thank you for this report.

What version of Mosh is running on the server?

What architecture is the server (is it also a Debian amd64 machine)?

Could you please also test running Mosh 1.2.5 on the client *and* server,
and seeing if you can replicate the bug? That will help us determine if
this is a regression.

Depending on the results, the next request will be for you to use "script"
to capture the output (1) entering tmux, (2) leaving tmux and entering
mosh, and then (3) leaving mosh.

Thanks very much for finding this,
Keith

On Mon, Nov 7, 2016 at 4:04 AM, Ph. Marek  wrote:

> Package: mosh
> Version: 1.2.6-1+b1
> Severity: normal
>
> Some interaction of tmux and mosh to access a remote machine makes long
> lines being displayed badly.
>
> For example, scrolling "less /var/log/kern.log" line by line
> should be uninterrupted long lines.
>
> It should be
>
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |5: +3.07 V (min = +1.95 V, max = +1.15 V) [ALARM] |
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |7: +3.33 V (min = +3.68 V, max = +2.24 V) [ALARM] |
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |8: +3.30 V (min = +1.39 V, max = +2.43 V) [ALARM] |
>
> and copy/paste of tha
>
> But when scrolling individual lines forward the output looks like
>
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |5: +3.07 V (min = +1.95 V, max = +1.15 V) [ALARM] |
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |: |
>   |7: +3.33 V (min = +3.68 V, max = +2.24 V) [ALARM] |
>   |Nov  7 08:10:50 much sensord: Sensor alarm: Chip w83627hf-isa-0290: in|
>   |: |
>   |8: +3.30 V (min = +1.39 V, max = +2.43 V) [ALARM] |
>
> To clarify: these combinations work normally:
>
>   xterm   > mosh > less
>   xterm   > mosh > screen > less
>   konsole > mosh > screen > less
>   konsole > ssh  > screen > less
>   konsole > tmux > ssh> less
>   konsole > tmux > ssh> screen > less
>
> I get the corruption with
>
>   konsole > tmux > mosh > less
>   xterm   > tmux > mosh > less
>   konsole > tmux > mosh > screen > less
>   konsole > tmux > mosh > screen > cat
>   konsole > tmux > mosh > screen > other terminal output
>
>
> When having a "screen" behind "mosh", the results are even more bizarry.
> When switching to an (empty, clean) screen window when such a screen
> corruption is visible, the freshly displayed screen is garbled, too:
>
>   |  b   t  i  '//www.rsyslog.com/e/2359 ]   |
>   |r2   -0290: i |
>   |   +3 0 .  =  R   |
>   |  0h  i  w83627hf-isa-0290: i |
>   |  |
>   |  +   |
>
> I guess that mosh tries to optimize for bandwidth by only pushing "changed"
> characters, but as the display is out of sync, it doesn't match up again.
>
> mosh tries to optimize for bandwidth by only pushing "changed" characters,
> but as the display is out of sync, it doesn't match up again.
>
> mosh tries to optimize for bandwidth by only pushing "changed" characters,
> but as the display is out of sync, it doesn't match up again.
>
> tmux and the mosh-clients have TERM=screen-256color; "tput cols" shows the
> same value outside tmux, inside tmux but before mosh, and behind mosh.
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.10
> ii  libc6   2.24-5
> ii  libgcc1 1:6.2.0-10
> ii  libprotobuf10   3.0.0-7
> ii  libssl1.0.2 1.0.2j-1
> ii  libstdc++6  6.2.0-10
> ii  libtinfo5   6.0+20160917-1
> ii  libutempter01.1.6-3
> ii  openssh-client  1:7.3p1-1
> ii  zlib1g  1:1.2.8.dfsg-2+b3
>
> Versions of packages mosh recommends:
> ii  libio-socket-ip-perl  0.38-1
> ii  perl-base [libio-socket-ip-perl]  5.24.1~rc3-3
>
> mosh suggests no packages.
>
> -- no debconf information
>

Bug#803253: mosh: diff for NMU version 1.2.5-1.1

2016-01-31 Thread Keith Winstein 
Thank you. I'm not sure what the etiquette is here -- I am fine with this
proposed change (we have taken the patch upstream but have not released a
new version of Mosh or an updated package yet). I'm happy to let your NMU
go through as-is, but if you would like me to do a 1.2.5-2 upload that
cherry-picks this patch, also fine.

-Keith

On Sun, Jan 31, 2016 at 7:43 AM, Laurent Bigonville 
wrote:

> Control: tags 803253 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for mosh (versioned as 1.2.5-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> diff -Nru mosh-1.2.5/debian/changelog mosh-1.2.5/debian/changelog
> --- mosh-1.2.5/debian/changelog 2015-07-23 08:45:07.0 +0200
> +++ mosh-1.2.5/debian/changelog 2016-01-31 16:19:12.0 +0100
> @@ -1,3 +1,11 @@
> +mosh (1.2.5-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * debian/mosh.maintscript: Fix /etc/bash_completion.d/mosh removal,
> thanks
> +to for the patch Jakub Wilk  (Closes: #803253)
> +
> + -- Laurent Bigonville   Sun, 31 Jan 2016 16:19:09
> +0100
> +
>  mosh (1.2.5-1) unstable; urgency=low
>
>* Version 1.2.5 released.
> diff -Nru mosh-1.2.5/debian/mosh.maintscript
> mosh-1.2.5/debian/mosh.maintscript
> --- mosh-1.2.5/debian/mosh.maintscript  2015-07-23 08:45:07.0 +0200
> +++ mosh-1.2.5/debian/mosh.maintscript  2016-01-31 16:14:18.0 +0100
> @@ -1 +1 @@
> -rm_conffile /etc/bash_completion.d/mosh 1.2.5~ -- "$@"
> +rm_conffile /etc/bash_completion.d/mosh 1.2.5~
>

Bug#803253: mosh: error: --compare-versions takes three arguments:

2015-10-28 Thread Keith Winstein 
My suspicion is that this error is coming from some package that mosh
depends on, instead of from mosh itself. Mosh doesn't try to run dpkg
itself.

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

On Wed, Oct 28, 2015 at 5:30 AM, Jakub Wilk  wrote:

> Package: mosh
> Version: 1.2.5-1+b1
>
> I get this when I install mosh:
>
> Preparing to unpack .../mosh_1.2.5-1+b1_i386.deb ...
> dpkg: error: --compare-versions takes three arguments: 
>  
>
> Type dpkg --help for help about installing and deinstalling packages [*];
> Use 'apt' or 'aptitude' for user-friendly package management;
> Type dpkg -Dhelp for a list of dpkg debug flag values;
> Type dpkg --force-help for a list of forcing options;
> Type dpkg-deb --help for help about manipulating *.deb files;
>
> Options marked [*] produce a lot of output - pipe it through 'less' or
> 'more' !
> Unpacking mosh (1.2.5-1+b1) ...
>
>
> -- System Information:
> Debian Release: stretch/sid
>  APT prefers unstable
>  APT policy: (990, 'unstable'), (500, 'experimental')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages mosh depends on:
> ii  dpkg1.18.3
> ii  libc6   2.19-22
> ii  libgcc1 1:5.2.1-22
> ii  libprotobuf9v5  2.6.1-1.3
> ii  libssl1.0.0 1.0.2d-1
> ii  libstdc++6  5.2.1-22
> ii  libtinfo5   6.0+20151024-1
> ii  libutempter01.1.6-1
> ii  openssh-client  1:6.9p1-2
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> Versions of packages mosh recommends:
> ii  perl-base [libio-socket-ip-perl]  5.20.2-6
>
> --
> Jakub Wilk
>

Bug#803253: mosh: error: --compare-versions takes three arguments:

2015-10-28 Thread Keith Winstein 
Thanks -- can you confirm that this fixes the problem for you? If so I'm
happy to apply it.

On Wed, Oct 28, 2015 at 2:47 PM, Jakub Wilk  wrote:

> Control: tags -1 + patch
>
> --
> Jakub Wilk
>

Bug#793158: mosh: Please provide a backport for jessie

2015-07-23 Thread Keith Winstein 
I have just packaged and uploaded the upstream 1.2.5 release.

Please feel free to upload this package to backports once it reaches testing.

Best regards,
Keith

On Tue, Jul 21, 2015 at 1:17 PM, Miguel Landaeta nomad...@debian.org wrote:
 Package: mosh
 Version: 1.2.4a-1+b2
 Severity: wishlist

 Now 1.2.4.95rc2-1 finally reached testing with long awaited features
 I think a backport for jessie is needed.

 Please provide one or just let me know if you don't have time or
 interest. I can take care of that backport.

 Thanks.


 -- System Information:
 Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: amd64 (x86_64)

 Kernel: Linux 4.0.0-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
 to en_US.UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages mosh depends on:
 ii  libc6   2.19-18
 ii  libgcc1 1:4.9.2-10
 ii  libprotobuf92.6.1-1
 ii  libssl1.0.0 1.0.1k-3+deb8u1
 ii  libstdc++6  4.9.2-10
 ii  libtinfo5   5.9+20140913-1+b1
 ii  libutempter01.1.5-4
 ii  openssh-client  1:6.7p1-5
 ii  zlib1g  1:1.2.8.dfsg-2+b1

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information

 --
 Miguel Landaeta, nomadium at debian.org
 secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
 Faith means not wanting to know what is true. -- Nietzsche


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686956: incompatible with sslh

2013-04-30 Thread Keith Winstein 
This is fixed in git (adding a new mosh option, --bind-server=ANY) and
will be in the next release.

On Fri, Sep 7, 2012 at 12:12 PM, chrysn chr...@fsfe.org wrote:
 Package: mosh, sslh
 Severity: minor

 mosh can't be used on hosts that hide their ssh services behind sslh.

 when connecting to such a host, mosh displays

 mosh: Nothing received from server on UDP port 60001.

 then:

 mosh: Nothing received from server on UDP port 60001. (... s without
 contact)

 the problem seems to be caused by the way the ssh connection is
 established in sslh: sslh forwards the connection by creating another
 tcp stream from itself to the ssh server, causing SSH_CONNECTION have
 127.0.0.1 in both source and destination ip fields -- and mosh, when
 started with -s, binds to the address it finds in SSH_CONNECTION.

 the mosh server seems to get started with -s automatically (even though
 the client seems to just call mosh-server, it shows up in the process
 list as `mosh-server new -s ...`).


 several solutions seem feasible, in increasing order of my preference:

 * provide a way for the client to specify he doesn't want to use the
   `-s` option server-side (fix on mosh side)
 * have a server-side configuration option to turn off the `-s` flag for
   the host (better, as it has to be done only once per host) (fix on
   mosh side)
 * provide a way to find out the real address (fix on ssh side)


 as a workaround, i have provided a way around sslh for clients to
 connect directly, but that's not usually what an sslh user wants to do.

 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.4-trunk-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6   2.13-35
 ii  libgcc1 1:4.7.1-7
 ii  libio-pty-perl  1:1.08-1+b2
 ii  libprotobuf72.4.1-3
 ii  libstdc++6  4.7.1-7
 ii  libtinfo5   5.9-10
 ii  libutempter01.1.5-4
 ii  openssh-client  1:6.0p1-3
 ii  zlib1g  1:1.2.7.dfsg-13

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#693519: mosh: Broken watchfile

2012-11-29 Thread Keith Winstein 
Thank you for catching this. We applied the patch and pushed to
Github. It will be in the next release.

On Sat, Nov 17, 2012 at 8:29 AM, Jonathan McCrohan jmccro...@gmail.com wrote:
 Package: mosh
 Severity: normal
 Tags: patch

 Hi,

 Github have changed their website which breaks debian/watch. I have
 attached a patch which fixes this issue.

 Jon

 -- System Information:
 Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (650, 'testing'), (600, 'unstable'), (450, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678020: mosh: 1.2 seems a lot less reliable than 1.1

2012-10-23 Thread Keith Winstein 
Package: mosh
Version: 1.2.3-1

Closing, as we believe performance over this kind of network has been
improved in 1.2.3 and have not heard back from filer. Please reopen if
this is not your experience.

On Fri, Oct 5, 2012 at 9:11 PM, Keith Winstein kei...@mit.edu wrote:
 Hello,

 Could you please try the 1.2.2.95rc1-1 package, recently uploaded to
 unstable, and see if you still have trouble? The source package should build
 fine on stable as well.

 We can't think of something that could have gotten worse between 1.1 and
 1.2, but 1.2.3 (and its release candidate) have some new techniques to try
 to punch through challenging client-side NATs.

 Best regards, and thank you for this report,
 Keith

 On Mon, Jun 18, 2012 at 1:09 PM, Jon Dowland j...@debian.org wrote:

 Package: mosh
 Version: 1.2-1~bpo60+1
 Severity: normal

 Hi,

 I'm using mosh as reported above on the server and 1.2.1-1 on the client
 end.

 Since the upgrade from 1.1 at both ends, I've found mosh a lot less
 reliable.

 It can typically establish a connection but then loses contact with the
 server
 after ~30 seconds or so and never regains it.

 My normal environment for using it is a 3G connection on a train.  I found
 1.1
 fairly good in that environment and bad with 1.2. I also tried it this
 weekend
 on some mainline trains (travelled ~350 miles each way) and my experience
 was
 the same.


 -- System Information:
 Debian Release: 6.0.5
   APT prefers stable
   APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates')
 Architecture: i386 (i686)

 Kernel: Linux 3.0.18-linode43 (SMP w/4 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6 2.11.3-3   Embedded GNU C Library:
 Shared lib
 ii  libgcc1   1:4.4.5-8  GCC support library
 ii  libio-pty-perl1:1.08-1   Perl module for pseudo tty IO
 ii  libncurses5   5.7+20100313-5 shared libraries for terminal
 hand
 ii  libprotobuf6  2.3.0-4protocol buffers C++ library
 ii  libstdc++64.4.5-8The GNU Standard C++ Library
 v3
 ii  libutempter0  1.1.5-3A privileged helper for
 utmp/wtmp
 ii  openssh-client1:5.5p1-6+squeeze2 secure shell (SSH) client,
 for sec
 ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691293: unblock: mosh/1.2.3-1

2012-10-23 Thread Keith Winstein 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

We respectfully request that you unblock mosh 1.2.3-1 and include it
in the wheezy release. A debdiff from mosh 1.2.2-1 is available at
http://mosh.mit.edu/mosh_1.2.2-1_to_mosh-1.2.3-1.debdiff.txt .

mosh 1.2.3 is an upstream microrelease that fixes several issues we
learned about during the first six months of widespread use. It is
well-tested and has passed the regressions tests.

Most prominently, mosh now links against OpenSSL and uses OpenSSL's
implementation of AES. Previously, Mosh 1.2.2 shipped its own AES
reference implementation for licensing reasons. The reference
implementation has been criticized for possible timing leakage, and it
is preferable to avoid shipping a duplicate cipher implementation.

Mosh 1.2.3 also includes several robustness fixes, including increased
resilience when transiting problematic NATs and VPNs and compatibility
with the KDE konsole and dual-stack IPv4/v6 sshds.

More security and robustness improvements are listed in the changelog.

I regret the lateness of this upstream release in the wheezy freeze
cycle. But given the expected lifetime of wheezy as a stable release,
upstream would much rather be supporting 1.2.3 instead of 1.2.2 for
the long term. We appreciate your consideration of our request.

unblock mosh/1.2.3-1


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678020: mosh: 1.2 seems a lot less reliable than 1.1

2012-10-05 Thread Keith Winstein 
Hello,

Could you please try the 1.2.2.95rc1-1 package, recently uploaded to
unstable, and see if you still have trouble? The source package should
build fine on stable as well.

We can't think of something that could have gotten worse between 1.1 and
1.2, but 1.2.3 (and its release candidate) have some new techniques to try
to punch through challenging client-side NATs.

Best regards, and thank you for this report,
Keith

On Mon, Jun 18, 2012 at 1:09 PM, Jon Dowland j...@debian.org wrote:

 Package: mosh
 Version: 1.2-1~bpo60+1
 Severity: normal

 Hi,

 I'm using mosh as reported above on the server and 1.2.1-1 on the client
 end.

 Since the upgrade from 1.1 at both ends, I've found mosh a lot less
 reliable.

 It can typically establish a connection but then loses contact with the
 server
 after ~30 seconds or so and never regains it.

 My normal environment for using it is a 3G connection on a train.  I found
 1.1
 fairly good in that environment and bad with 1.2. I also tried it this
 weekend
 on some mainline trains (travelled ~350 miles each way) and my experience
 was
 the same.


 -- System Information:
 Debian Release: 6.0.5
   APT prefers stable
   APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates')
 Architecture: i386 (i686)

 Kernel: Linux 3.0.18-linode43 (SMP w/4 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6 2.11.3-3   Embedded GNU C Library:
 Shared lib
 ii  libgcc1   1:4.4.5-8  GCC support library
 ii  libio-pty-perl1:1.08-1   Perl module for pseudo tty IO
 ii  libncurses5   5.7+20100313-5 shared libraries for terminal
 hand
 ii  libprotobuf6  2.3.0-4protocol buffers C++ library
 ii  libstdc++64.4.5-8The GNU Standard C++ Library
 v3
 ii  libutempter0  1.1.5-3A privileged helper for
 utmp/wtmp
 ii  openssh-client1:5.5p1-6+squeeze2 secure shell (SSH) client,
 for sec
 ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information

Bug#676132: debian-maintainers: Please add Keith Winstein as a Debian Maintainer

2012-06-04 Thread Keith Winstein 

Package: debian-maintainers

Dear Maintainer,

Please add Keith Winstein kei...@mit.edu to the Debian Maintainers
keyring. I attached the jetring changeset.

Thanks very much,
KeithComment: Add Keith Winstein kei...@mit.edu as a Debian Maintainer
Date: Mon, 04 Jun 2012 19:06:47 -0400
Action: import
Recommended-By: 
  Christine Spang christ...@spang.cc
Agreement: 
  http://lists.debian.org/debian-newmaint/2012/05/msg00050.html
Advocates: 
  http://lists.debian.org/debian-newmaint/2012/05/msg00051.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  mQINBE8uz+YBEADRlVWHFoznSp/ooMt8gHd5YTkyhaPQWBmpZG6ERJttgLjAvMdQ
  a4fUU994dNfu0ATcamedRcMtKcCCVM6DLMMZ3IVxaYx4J658BgTG/+mbVr9RBQQC
  qs89cQCGbjpEFvJHcgsiK6WMqYVUqo9Jqc9DXVea8iTjcAUvkm68ad2pnF/Y5EEK
  wFwZzn7Kyd0Khbhe6fBpIqyeoqbm/ir1zRwbQZKIG8jLkDGxP0ySpXxUqOTpWall
  d1q1uK7aOJgL63YFEu+5UNCSV5OeZl+Womrk/z3CpvergPgtwwxE8ZQNyN534wUH
  gPKRJQLKFB58DNwYrMFvmvUKOruPu5s7xP0Boin8dVEg+D+U0CzRSHp57Qt+6Sm9
  Y9jGrdrAmneDaF8nihesVCP3etmHdE1qpYkA5NXJ+y8Wf25gqR0Q+mDnq6B9N7UI
  GBBOcl0rYFXH+G4NvxnNeBc7r1xwbfGJYKzWmBWfpo48m8VyzJCYOH0g1bRFN2u6
  SOIgbcmdg4QGUhnttCRYla/XaEvAP9p9EY+KAbBcbmLBYMzWZ/pZoJCnqMCuqboY
  de4fAsrajav1V9SLUSxUsVAn0yB5CyTh3eyijEHqUK7p/f2OptfNl54ufMN7tyM1
  fAiCgL7K/bnuSCQjCxl8/PNF5nGFaoKF7ciq7qqWzQJyGef0ORK+8aDpfwARAQAB
  tB9LZWl0aCBXaW5zdGVpbiA8a2VpdGh3QG1pdC5lZHU+iQI9BBMBAgAnAhsDBQkF
  o5qAAh4BAheABQJPxhGOBQsJCAcDBRUKCQgLBRYCAwEAAAoJECC3KDr+JUxpI2QP
  /A+GCtT3+bxGBSWsfBd2iVqb4L+QGVpS0JCFYGCgAvkq8Au6M+IvVRRWLggHDgpU
  QDtmMA2RzFHcLedbbR04c9ULt0RIbztC1+7d8ZBd2RMehlLR0GSPjtSGzSJsc2I6
  DRC6Ge4R5Icc7orKOdPXaRCoUNCZyaAB/fZEkV6nsHC5Bd4zLbsoNy+DcXeOWQKS
  59ZzBZK1ztiYq0jhdQt6kpRu8CoZatC0EWkOoOi5jF0Z7X0YiaafV/Gj6+x9Fx8y
  HC95kioeuWu1SDVjKxkQk5KOPbPyDbcMJT8jmPxPiwea6w2aCLu55M2526ib3Wd7
  o/3OgCuOQ79U8nRTKx0//21l9ut/HCuMRRHdxtUhhoP7GDDFtkmpI0TjJtWeq68L
  vGwzhUJf/c27ufLZIZ5pUwSQgfDuHPgMQtyY4fXY2OW7veizQVEHMvcFV6BqxqnV
  9T7nkkbOdE4+NQgSmetOUG4fJiHnEyUOtsf4nEVouMs8nRU73ZfnYx/chw0LtZSZ
  uDstKbqKU9/KW8wEB34O4tNQKcLvAMxuLkBKbUho6znbt9N+aAp1ojKrbYlfFgo0
  Hiwgf2Huv1VOuW1bi5nfLZ8kBWg21AdN7/qE2rjTB6wK5/MvdKVtwRZlj9M3cnR2
  1GFZ1Vhs+hnLZZrHZBKs0rMIMZX+M6Wt47bee3IOfFqPiEYEExEIAAYFAk/Fh+8A
  CgkQscqS6KfYa5XHnwCeLD7NaxX+93QeX3P46HxunPJGSbUAoI7NUW6MMrtADNvJ
  HNWu1HTD4f/kiQIcBBABCAAGBQJPxOyDAAoJEGSVn+mDjfGcUfUP/jkBEVYvCkqR
  AOr60RQfZQ6GB8pEIRlRxlrre+vk5WZZJVeX/qavfSdyEppk8Z6dryHgxnBvxy4O
  FZBD0JVBoORS62pSZER2P06Ox/uZWNIs4cQ9Uq7w0hhTxYmXjnMA5vmPjMAlgs7F
  6FXFPn7Ye/IrldgnAA2I5ZkQ7mDEOlfcv9ohk0utHmBizNj1HuIzcfMQ+v80siMo
  1o6wc/BT/6CMlPnxS/ePzJlN9eOZp/+43+ePyf5aMzbkC5zk9eF5upke/e9Foi3V
  sNR3u4VjP95dFLlJ3sgLTZzAiogNaB74yXOPjmeO+ejN+8LJKAxhjmvzXzFXrlcG
  glZg8AuSLTytd0HDKGfoOYdhsmYib+YYBjMfr222G/oLg5Zr/578roC3CPyGrVVT
  kyuLvE3d1MW5n5f7GVX+NbZVdt6Od3RW+T5OnKzB+x4lzqDnfk3SYuMXBZdrEwUf
  S8grPcnnVqcFH2NnvC1fF38y1SmimAq7O5luom9U04HoGu3RMwUiKCH6QyCMop8h
  MIwghWOpEETFJEFq1H0v0y8Vx3tPJ2Y6aS84hcy+CT7SgN6incTlHNI8ZjYAR5/J
  Z7BnkaGG0TwCEf/hjptPFt22CyZ6GaY2c7wd8+Z6001AU4YudP6elQR+qkKbrT+t
  qtmVgmEnFD1LiUPDM/STvADgdujTTc1XiQIcBBMBCAAGBQJPxYmRAAoJEOY3FvTg
  aZSeWfoQANq83eIiy9Qk853TLbgKFzTN2lhytDhg4OKS8Qels3TTAoTrjvbGonVa
  ZbmafpVLNAEGHoWQJ1y3IOB5cikwqjWxr7HP4gY1Yt+h4sW9rqhP0Azk/l/Rq9H0
  GqcluEpgGJnSGeNQv7MSp8DdoskC4QGBkoQr4g1al/bLzWMaB8IbFX0ScMjcP6Fv
  2+v2/o/Z0fSW91o6EWXHlcrxpVbpXzUsxv5hIKUjEekBL5nt6SVspYDjMR9v3tvw
  Gq5ukGNEEGfDzMD4nCpwrODAkasM/F0k+6JotkR6grRib+XFj/z6DYiegGHbArAK
  U/w/Cv7eARDXtpDowbWvhVDFqvwz2D+XrbJmJ4KXByaN6QUDcvlJJpSIOjsiMNzL
  k7rmuZOZG+Ap+cW6Nz4T6VHBk4FMNHu3H6HO7uegvE6LMtsiUiPTF8NgVoQ9m+VL
  px/mcVpAmntpDqcb5eVR8L+o+lzy0d33D5Ye6vIyW06WQbhbb7HXjNXzmBHYVZDp
  MEM0MJEeiprU+P5QeP3NLonMIN+5npglopHXheF+elXkvliDBLJN3T9p2R3aJapN
  kqE16tSmDUanqIq6/SmEtlk2pPTNa2O5XsXKe9uGZuJ9L9pVnRWGl//AeCMd8tq9
  27HQC4f1oTOeRUly07wGvtx3PLsoc0vYYe7lgSJEk4F/3hdHLk04uQINBE8uz+YB
  EACuXXgaYGjt2p29kSX0HmzqcdIobK6W1PNNomXCaIDn92LJGCt+zsyK9G0ZBktp
  A35atn1/VLBQFzrbPwM3GoUBndjkXqGCBsXLbO4Xa66SXFLrJNXDwor6kJMfl5Z/
  is80srlN7tFt5FFPDqLJeS9e+BW/vOWH7gjetxjDcsc9BUY4kj9YvmMte7NOxKPh
  cO+lCdxfH4AVxfcsOmGCBOKRvJ8yp99yKov4X25Eda63rvuLWkW78VUiYXnGrw34
  4MNB8QehYXU2Rlr2DRqTSbrA/Jd/g2YJdE18RCTII9MnnkyT3nO5H16x5CxMmYq8
  /EyBGZedPaXj+7Fd66YIxAJe8uCZilqNSHi5x08aRt+DCnyP2j7qtcvTREr0doOo
  U40Nj7jDZaOj/8EqnKMQ9C1rgRLYOqWgScvM7XOaR+0pHlstfOxEwMqWQlmUwsgg
  mWTWn6hnyf9ssVDYzZDIkNJ0dhEdnMNAYzl5PTPetKNhXb2hYU/3ap4zbdyUpKeF
  YcSDnjH78Ax8TaEurgxN+wzi2DHSQMTTSDHT1j3v3/UyNIZQM8Juafivj+WQyMGN
  gRT+abi/x2Focx1D/NtyfN3g11suobZLgbJeYZfdfwO7214jDiSqrFDUsPzQ/o4v
  7pHF55ZXIEnbrWygZJOjzTp3HXtMzAulnjbbsY14jiImgwARAQABiQIlBBgBAgAP
  BQJPLs/mAhsMBQkFo5qAAAoJECC3KDr+JUxpF7QP/2EvDHd/JDdaMCqcOjn64g0e
  XtIMvQQc/EGjF1s2ag5uiCYWkiyfOfFfw4Le/zB0emQPXyjBjb0tZuOaXIsK1HGQ
  7N6Obyc+1PdtCAKg2L9mD+YKCLtWg+TqdAuidYyDnYxHz8A0kP0LEvPbEhWxiPzf
  5FRD/IMPBmefJQvURgP0W1DDPG+ID9Sd1I7QaAOue/GSCB2jKdQ2FBRkSFxHA8X3
  i7lmZX5WQotje9/Q0EeWUSkSDkPRUXrPgRcXyNO6FvUOO5d4vgrgjKYwPhYpHzjK
  9SXPWX7duHkwQJeN5LKpeFw3XhgrLX3QuVWecLJTQPmStfrHO20j+AGPo1vzB05k
  zjNL+c8+Ddnmdzu6669shBM4s2exp+0L3YCfB

Bug#674127: mosh: Add UFW integration file

2012-05-24 Thread Keith Winstein 
Thanks for this.

This has been added to the version in Git and the 1.2.1 release candidate
if you would like to test it.

(https://github.com/downloads/keithw/mosh/mosh-1.2.0.97.tar.gz)

We are planning to release 1.2.1 imminently so please let me know if this
does not meet your needs asap.

Best regards,
Keith

On Wed, May 23, 2012 at 4:49 AM, Fumihito YOSHIDA h...@kugutsu.org wrote:

 Package: mosh
 Version: 1.2-1
 Severity: wishlist
 Tags: patch

 Dear Maintainer,

 Please add UFW(Uncomplicated Firewall) integration file from
 LP: 985981 (1.2-1ubuntu1) [1].

 [1] https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/985981

Bug#673871: malicious escape sequences can cause denial of service for mosh-server

2012-05-21 Thread Keith Winstein 
Thanks, Timo, and thanks for submitting the original bug as well.

This bug allows applications and unscreened terminal input (run or
catted by the user) to DOS the mosh-server (also run by the user).
It also allowed the mosh-server process (invoked by the user but
resident on a remote host and not trusted by the client) to DOS the
mosh-client (run by the user).

Based on the severity, I don't think it warrants a backported patch or
emergency release.

We do intend to do a 1.2.1 release in the coming weeks that will roll
up the bugfixes we have done in the wake of 1.2, including this one.

Thanks again,
Keith

On Mon, May 21, 2012 at 3:43 PM, Timo Juhani Lindfors
timo.lindf...@iki.fi wrote:
 Package: mosh
 Version: 1.2-1
 Severity: important
 Tags: security

 I submitted details upstream at

 https://github.com/keithw/mosh/issues/271

 but here's also a copy:


 The commands

 echo -en \e[2147483647L
 echo -en \e[2147483647M
 echo -en \e[2147483647@
 echo -en \e[2147483647P

 all cause mosh-server to enter very long for-loops in terminalfunctions.cc.

 Upstream has released a fix, please consider including it in the debian
 package.

 Security team, this also affects gnome-terminal and probably all other
 terminal emulators that use libvte. Its upstream is also working a fix
 but they made their bug report restricted for now:
 https://bugzilla.gnome.org/show_bug.cgi?id=676090

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32-5-amd64 (SMP w/6 CPU cores)
 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages mosh depends on:
 ii  libc6           2.13-32
 ii  libgcc1         1:4.7.0-8
 ii  libio-pty-perl  1:1.08-1+b2
 ii  libprotobuf7    2.4.1-1
 ii  libstdc++6      4.7.0-8
 ii  libtinfo5       5.9-7
 ii  libutempter0    1.1.5-4
 ii  openssh-client  1:5.9p1-5
 ii  zlib1g          1:1.2.7.dfsg-1

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670078: mosh: UTF-8 error misleading

2012-04-26 Thread Keith Winstein 
Package: mosh
Version: 1.2-1

Thanks for this report. We made this much smoother in version 1.2
(just released), both in avoiding the error and in giving a clear
diagnostic when it can't be avoided.

In previous versions, you do need to have SSH set up to pass the
locale-related environment variables over the connection. This is the
default on new Debian installations (I think since lenny) but may not
be there if you have upgraded. More information is here:
https://github.com/keithw/mosh/issues/98

Thanks for filing this,
Keith

On Sun, Apr 22, 2012 at 2:24 PM, Colin Turner c...@piglets.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Package: mosh
 Version: 1.1.3-1
 Severity: minor

 Dear Maintainer,

 I first installed mosh on Debian client and server and on trying to
 connect got a fatal error that a UTF-8 locale was required; but the
 client only had a utf8 locale (see below) and the server supported
 that locale among others.

 In the end I was able on the server to set the default locale to the
 utf8 rather than what it was set to, which appeared to be none.

 I guess I'm surprised that you need to not only have the locale on the
 server but have it set as default?

 Many thanks for packaging this program.

 Regards,

 CT.

 - -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
 (1, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6           2.13-27
 ii  libgcc1         1:4.7.0-1
 ii  libio-pty-perl  1:1.08-1+b2
 ii  libncurses5     5.9-4
 ii  libprotobuf7    2.4.1-1
 ii  libstdc++6      4.7.0-1
 ii  libtinfo5       5.9-4
 ii  libutempter0    1.1.5-4
 ii  openssh-client  1:5.9p1-5
 ii  zlib1g          1:1.2.6.dfsg-2

 mosh recommends no packages.

 mosh suggests no packages.

 - -- no debconf information
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQIcBAEBCAAGBQJPlEzMAAoJEJhSfHbQK6t7f+EP/27TmxFkznDRJLXfPwtmR90r
 bFM67cUYUBnBrNXLY3KDKqfz3OXs8VjImkWwjBgw4/90nw/lIXkpwoySEd6Ucj/g
 EkEMskXMHS7X7LL2IbJ7lD47pIb3nxAWnEatk6DYKyP7jWXN58kzFQbheVm8FviC
 59SP3ftURwoA9CqiyP23jpyd6EfpgjfcRPvd4HCQhuHCVGzmphUo+m/stOKPKvEC
 TK3KQRhheHKGz08OUMNu/TDsnyRQCJVLYfbTerzvf78GMGjTFntDGQDSwS4R4qey
 di0Nm0dfXrSKk0qMWAh5PWhsilFSXgjdLUuSLPVVfrQjpxF1c5d0urshyEC9TCqJ
 lgSgQqKELvLLSy8V0/7KfwQYxJNfvtP20XcUI8I6EqJb+rOtRasuKdUMU67/WuEd
 wwjSUxf5ukTosil/bQcK9U86bEsJDQdV8n/DVv/RNYKz3siq0sYZeuyFggdmRLp7
 b254pTl0E9n4GJlYgECbAEqm0EU90gcu789+1QjBijUI7yqIOdlBUEC/r9D8SYep
 WkZmpGGsDpiMZPSCpaGv//9EtOT3ZB1JPP2cn626jeiemGTbw/HpaOevCr7rwYt+
 mYSn7VbCAmVcICPBUFZ2+JyyxxGp7v8DljIzFZQ8v96n4FkFBNROuCeSzsQy2ngD
 MJVgUmdKtsftRlxjhAgp
 =3chs
 -END PGP SIGNATURE-





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670079: mosh: Mosh problems with firewall (xxx s without contact

2012-04-26 Thread Keith Winstein 
Hello,

Thanks for the report. Mosh does need to have working UDP passing in
both directions. In the documentation (http://mosh.mit.edu), we
recommend just opening UDP ports 6-61000, but you can open a
smaller range if you like (e.g. 6-60010) or just open a single
port and request it with the -p option.

Unfortunately, at least with the current design, we can't rely on your
proposed strategy of having the server initiate the connection,
because this won't work after the client has roamed to a new IP
address. (How will the firewall know to allow UDP packets from the new
client IP?)

Best regards,
Keith

On Sun, Apr 22, 2012 at 2:22 PM, Colin Turner c...@piglets.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Package: mosh
 Version: 1.1.3-1
 Severity: normal

 Dear Maintainer,

 Thanks very much for packaging this very interesting application, I
 could really do with it.

 I found some problems getting it to connect to my main server, which
 evaporated when I disabled the firewall. My firewall essentially
 disables most access and then opens it for specific ports. But it
 includes this section.

 === Start Clip ===

 # Anything on the external interface which is related to, or otherwise
 to do

 # with an existing connection is allowed. Also allow new outbound
 connections.

 iptables -A OUTPUT  -o $DMZ_INTERFACE -m state --state
 NEW,ESTABLISHED,RELATED -j ACCEPT
 iptables -A INPUT   -i $DMZ_INTERFACE -m state --state
 ESTABLISHED,RELATED -j ACCEPT
 #iptables -A FORWARD -i $DMZ_INTERFACE -o $LAN_INTERFACE -m state
 - --state ESTABLISHED,RELATED -j ACCEPT

 === End Clip ===

 which I would have expected would have allowed mosh through.

 Indeed, I switched off the firewall, initiated a mosh connection and
 brought the firewall back up. That connection is still live as I type,
 and working; but another mosh session I just tried failed. This
 suggests to me that the bypass may be partially working after the
 initial connect.

 Perhaps mosh starts the connection on SSH, and then relies on the
 client to contact the server process - if the server process initiated
 this first it would solve this problem without having to open hundreds
 of UDP ports on the firewall.

 Kind regards,

 CT.

 - -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
 (1, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6           2.13-27
 ii  libgcc1         1:4.7.0-1
 ii  libio-pty-perl  1:1.08-1+b2
 ii  libncurses5     5.9-4
 ii  libprotobuf7    2.4.1-1
 ii  libstdc++6      4.7.0-1
 ii  libtinfo5       5.9-4
 ii  libutempter0    1.1.5-4
 ii  openssh-client  1:5.9p1-5
 ii  zlib1g          1:1.2.6.dfsg-2

 mosh recommends no packages.

 mosh suggests no packages.

 - -- no debconf information
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQIcBAEBCAAGBQJPlEyDAAoJEJhSfHbQK6t7RsUP/ia7NGsJ+8sUWPsAPZf/fQo8
 A98sAyWV2D8Fb6hM+9aYDHTfRck00CW5f5KzEyE7w8dVLCzQk2dtp5p/knyiWW69
 FWjZ90FcodYxUAwYHLyxm23RpjJNLAuj10pcLlkivb5T4+azrHQsubZs5VwuJEPW
 I2Kor59n8ozbKvaExhwDWFsT5srxN76n2xhHKx65C2H50D1DV3L4ryR26rWbjWhC
 nm6LG0BdEaihU8f1rNBzOFme0whKJQaFy1KtUVKR6C8iNWaAIXfQNj7HvgxKDDLi
 IvRrTfJ3gN20GpZX+a+v6+JdLEBDJ0SbCQSKgoOmf3xAlgB7LWyedecLdn2OHIKM
 LfhgAJz8xw204juwIJoUIvgqwtTMzzFfL5mjWl4/1DxGGrpTi3mwSds/6jPiIE4x
 AKkeHC/0Y6bLF+Z7267bHcspCGV05RUbfeeF/aC1P+PA6kazFIYbgO8HqS7XGPSK
 fP62hh2BRfY1PYyjvbmpiPZ3gCgv3rVWByNfBxby0QnO0DLFKNDehzrfr2ICLOnE
 ckU1a6WjZbxJ2dpR2eJevb2M9KOmzUQFiFVY60UW05QJG2SjTTa7YB/up0pCqbsz
 qj5D7hPhEjEAuvHxndC0dgxB4g1IDziQubEKCiYTUN9VVcmsyA79lHjrJWHlBgrL
 6J/A5XegzEp3+Eax1mQk
 =SrX3
 -END PGP SIGNATURE-





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665757: FTBFS on kfreebsd (IUTF8 termio is not POSIX) patch attached

2012-03-31 Thread Keith Winstein 
Further testing indicates that FreeBSD just doesn't have working UTF-8
character-erase (yet); the kernel does leave garbage in the input
buffer when it tries to erase a multibyte character in canonical mode.

We decided to just add an autoconf test for IUTF8, triggering a patch
along the lines submitted here. mosh-server also prints a warning on
startup in that case.

This has been pushed to master at http://github.com/keithw/mosh and I
would be grateful if you could let me know if it works for you.

This will be in the next version of the Debian package (1.1.3-1).

Best regards, and thank you,
Keith



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665760: mosh fails with IPv6 hosts

2012-03-26 Thread Keith Winstein 

Hello,

Thanks for filing -- you are correct. The mosh protocol is IPv4 only for 
now. We have some people working on an IPv6 port and I plan to commit 
these changes as soon as I can verify that IPv4-to-IPv6-to-IPv4 roaming is 
correctly implemented and that mosh behaves sensibly in common 
configurations.


We are tracking this issue at https://github.com/keithw/mosh/issues/81

Best regards,
Keith

On Sun, 25 Mar 2012, Christoph Egger wrote:


Package: mosh
Version: 1.1-1
Severity: normal
Tags: ipv6

Hi!

 Seems mosh can't deal with IPv6 (only) hosts.

Regards

   Christoph

christoph@hepworth ~
20:00 0 % mosh myron.siccegge.de
/usr/bin/mosh: Could not resolve hostname myron.siccegge.de
ssh_exchange_identification: Connection closed by remote host
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

christoph@hepworth ~
20:00 5 % host myron.siccegge.de
myron.siccegge.de has IPv6 address 2001:a60:f01c:0:70:1:6:f00


christoph@myron ~
20:02 0 % host myron.siccegge.de
myron.siccegge.de has IPv6 address 2001:a60:f01c:0:70:1:6:f00


-- System Information:
Debian Release: wheezy/sid
 APT prefers testing
 APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mosh depends on:
ii  libc6   2.13-27
ii  libgcc1 1:4.6.3-1
ii  libio-pty-perl  1:1.08-1+b2
ii  libncurses5 5.9-4
ii  libprotobuf72.4.1-1
ii  libstdc++6  4.6.3-1
ii  libtinfo5   5.9-4
ii  libutempter01.1.5-4
ii  openssh-client  1:5.9p1-3
ii  zlib1g  1:1.2.6.dfsg-2

mosh recommends no packages.

mosh suggests no packages.

-- no debconf information







--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665757: FTBFS on kfreebsd (IUTF8 termio is not POSIX) patch attached

2012-03-26 Thread Keith Winstein 

Hello,

Thanks for filing this. I can't take this patch as written, but I am very 
interested in getting mosh working on FreeBSD.


(1) We need and use IUTF8 on Mac OS X (XNU), so #ifdef __linux__ is not 
quite the right test.


(2) On platforms without IUTF8, we still need _some_ solution to the 
deletion of multibyte characters problem.


If you can tell me what mechanism FreeBSD uses to avoid this problem so 
that backspace works correctly in non-canonical mode with non-US-ASCII 
characters, I'm happy to make mosh enable it.


Here's how to demonstrate the problem:

(1) Open a UTF-8 terminal emulator.

(2) Run cat  /tmp/test.txt

(3) Type (or paste): The problem’s not obvious., including the curly 
Unicode apostrophe (U+2019) after problem. Do not type a carriage return 
at the end of the line.


(4) Hit the backspace key 15 times to back up to The problem.

(5) Type  is not obvious. and hit carriage return and then ^D.

(5a) You should see The problem is not obvious. on the screen.

(6) Run cat /tmp/test.txt

(7) With IUTF8, the apostrophe will have been correctly deleted, and you 
should see The problem is not obvious. (just as you saw when typing it)


(8) Without IUTF8, the kernel will not have correctly deleted the 
(three-byte) apostrophe, and you should see The problem? is not 
obvious. (with the Unicode replacement character in place of ?)


(8a) If you run od -c /tmp/test.txt, you'll see it has garbage after the 
word problem.


===

On the other hand, if FreeBSD really just has this bug and there is no way 
to fix it yet, I guess we can disable the use of IUTF8 on FreeBSD if 
that's what it takes to get mosh running... :-/ Perhaps the right approach 
is an autoconf test to see whether the platform has IUTF8.


Best regards, and thanks for using/testing mosh,
Keith

On Sun, 25 Mar 2012, Christoph Egger wrote:


Package: mosh
Version: 1.1-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

the IUTF8 termio constant isn't POSIX and isn't used on freebsd. We
still have UTF-8 enabled terminals though. Find below a patch I used
to make it buildwork on Debian GNU/kFreeBSD

Regards

   Christoph

-- System Information:
Debian Release: wheezy/sid
 APT prefers unstable
 APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mosh depends on:
ii  libc0.1 2.13-27
ii  libgcc1 1:4.7.0-1
ii  libio-pty-perl  1:1.08-1+b2
ii  libncurses5 5.9-4
ii  libprotobuf72.4.1-1
ii  libstdc++6  4.7.0-1
ii  libtinfo5   5.9-4
ii  libutempter01.1.5-4
ii  openssh-client  1:5.9p1-4
ii  zlib1g  1:1.2.6.dfsg-2

mosh recommends no packages.

mosh suggests no packages.

-- no debconf information

Bug#663291: please split package into server and client packages

2012-03-11 Thread Keith Winstein 
Thanks for this. My thinking has been that the client and server
really just sit there, linked with the same libraries, and it would be
silly to split them into two separate packages. (It is true that the
client pulls in openssh-client, but that also just sits there and is
relatively small.)

But I am new here and if the weight of Debian opinion is otherwise, I
do not feel that strongly about it.

On Sat, Mar 10, 2012 at 2:42 AM, martin f krafft madd...@debian.org wrote:
 Package: mosh
 Version: 0.96a-2
 Severity: wishlist

 Subject says it all. I do not need/want the client on all hosts that
 I want to become mosh-servers.

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-1-amd64 (SMP w/8 CPU cores)
 Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages mosh depends on:
 ii  libc6           2.13-27
 ii  libgcc1         1:4.6.3-1
 ii  libio-pty-perl  1:1.08-1+b2
 ii  libprotobuf7    2.4.1-1
 ii  libstdc++6      4.6.3-1
 ii  libutempter0    1.1.5-4
 ii  openssh-client  1:5.9p1-3
 ii  zlib1g          1:1.2.6.dfsg-2

 mosh recommends no packages.

 mosh suggests no packages.

 -- no debconf information


 --
  .''`.   martin f. krafft madduck@d.o      Related projects:
 : :'  :  proud Debian developer               http://debiansystem.info
 `. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#662939: mosh: Should probably depend on openssh-client | openssh-server instead of just openssh-client

2012-03-11 Thread Keith Winstein 
tag wontfix
thanks

Please feel free to reopen if necessary.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org