guardian-agent VS widecharwidth

https://github.com/StanfordSNR/guardian-agent

The problem basically is the current agent forwarding protocol doesn't have a way to reliably identify the source and remote host that can't be spoofed. guardian-agent tries to do that using some extra software, this linked SSH proposal is to add that to SSH but it will require software upgrades even to the sshd of the intermediate and remote hosts - it's not ideal that it can't just work out of the box - but I welcome this we just need to get it done now for later.

I frequently finding myself thinking about adding useful things to software I want to use now and go well it will be years before its on every host I use and can be used reliably. I have had this thought on and off for more than a decade. Ship some new stuff, it'l be great later :D

ObPlug for Guardian Agent, which is basically "safe" ssh-agent forwarding (and works with Mosh and SSH): https://github.com/StanfordSNR/guardian-agent

The basic story is that ssh-agent really just exposes a primitive of "please sign this challenge," which is useful locally, but the protocol wasn't designed to be forwarded. If requests are coming from a semi-trusted intermediary host, the protocol doesn't tell the agent (a) what remote server is being authenticated to [i.e., who generated the challenge?], or (b) what command is going to be executed. It doesn't even really know (c) what (semi-trusted) host has forwarded the challenge?

Guardian Agent is a sort of hack that allows the agent to know (a), (b), and (c) before deciding whether to grant or deny the request, and you can set up policies like, "I'd like to allow `jump host x` to use to run "git pull" when talking to `git server y`, but that's it." The basic ssh-agent protocol just doesn't have enough info to be able to do something like that.

there is a fork with port forwarding support https://github.com/rinne/mosh and a PR with a long discussion https://github.com/mobile-shell/mosh/pull/696 on why it's not merged

you can compile them yourself or if you want to skip the step I recently set up GitHub actions to compile linux binaries of this [1][2], tested by a sample of 1 so no guarantees it works, was planning on doing a tap PR/tap of it at some point

also the official developers have been involved a project to solve this while improving the whole-agent approval things also https://github.com/StanfordSNR/guardian-agent , but I couldn't get it to work which is why I tried the fork and got that working

[1] https://github.com/gnyman/mosh/actions/runs/1068715036

‘mosh’ is amazing for this, although I had to stop using it years ago because it didn’t support key forwarding. Apparently, there’s now a solution for that: https://github.com/StanfordSNR/guardian-agent

>For example, iTerm2 considers the "rosette" emoji to have width 1

The reason for this is quite possibly that Unicode 9 changed the width for some codepoints (mostly emoji) from 1 to 2, and iTerm until very recently (don't know if it's released yet) defaulted to the Unicode 8 widths, with an opt-in escape sequence to change to Unicode 9.

>This approach comes from the wcwidth utility, and the comment at the top of the C source file provides further insight into the difficulties faced here.

That's link goes to Markus Kuhn's implementation from 2007. It supports Unicode 5, and is by now woefully out of date. You don't want to use it anymore.

Most terminals have their own definition, and the annoying part is that the client application and the terminal need to have theirs in sync or they get weird glitches when moving the cursor.

Shameless plug: Fish's solution is widecharwidth[0], which is a python script that parses the Unicode data files and generates a wcwidth for C++, Javascript and Rust. It's still a wcwidth, meaning that it has issues with joining code points, but it's at least a start. It's up-to-date with Unicode 14 and, unless they change the data format (again) should be easy to update to future Unicode releases.

It's public domain and used by at least fish and WezTerm.

[0]: https://github.com/ridiculousfish/widecharwidth

With fish we've made the experience that relying on libc isn't good enough.

Specifically in the case of connecting to a server that typically has an old libc with old unicode information, from a desktop that has a much newer system, or in case of ambiguous characters, where libc will just give you one width that might not match what the terminal actually renders (and they frequently have configuration options to change it!).

So we've made something we call widecharwidth (https://github.com/ridiculousfish/widecharwidth), which is a python script that parses the unicode datafiles (UnicodeData.txt, emoji-data.txt and friends) and generates a header you can #include.

And someone's opened a PR to mosh to integrate it: https://github.com/mobile-shell/mosh/pull/1143