Live data from Hacker News

Charm – Tools to make the command line glamorous

charm.sh

121–130 of 223 posts

Re: Charm – Tools to make the command line glamorous

#121
post #2

I love Charm; doing `ssh git.charm.sh` is a lot of fun and really sparks the imagination about SSH apps. They also have usable solutions for auth and storage, which like, if you're thinking of writing something like this are the first things you'd start reaching for. They also work hard to enable you to run all your own services, so you don't rely on the Charm cloud for everything. Definitely a good model for future…

Looks cool! Are there any security risks posed by ssh'ing into an unknown server?

By default, you are probably uniquely identifiable: the SSH client sends your public keys, and sites like GitHub and GitLab publish the public keys for each account too. Someone made a demonstration SSH server a few years back that would greet you by GitHub username based on this, but I can’t immediately find it.

If you don’t specify a username, your local account name will be used and thereby disclosed.

Much more seriously, if you have the ForwardAgent option enabled, the remote server can impersonate you, using your SSH agent to log into any remote server. Don’t enable ForwardAgent globally, despite its convenience, unless you have an agent that requires manual action for every action; and be exceedingly leery of using it even on trusted servers, lest the compromise of one machine allow the compromise of everything. Consider ProxyJump instead.

I think this is sufficient regardless of configuration (but don’t trust me to be correct, I haven’t verified the actual traffic or anything):

  ssh -a -o PubkeyAuthentication=no nobody@git.charm.sh
It’ll prompt you for a password, just press Enter, it’ll accept it.

Now of course using this will make you comparatively fingerprintable (though not identifiable) unless enough other people do it too. But then, they have your IP address, so—

If you want to skip the host key stuff, you can add `-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no`, though it’ll emit a warning about adding the host key to the known hosts file every time.

Re: Charm – Tools to make the command line glamorous

#122
post #99

Earlier quoted context omitted.

Maybe it's aimed at a younger demographic and not just all devs that use cli tools. The design doesn't appeal to me but the several animated examples and quick blurbs about functionality seemed to showcase what was on offer pretty well.

I'm young and had the same experience as GP - for me it's just too little said about too many different things, it's hard to tell what 'it' is (and I only realised on the second read through that that's partly because they are many things). Imagine if Amazon had a landing page with headings like 'eShopping', 'Internet', and 'Cashierless Shopping' to describe what the company did. (And worse, then obscured them behind…

> Imagine if Amazon had a landing page with headings like 'eShopping', 'Internet', and 'Cashierless Shopping' to describe what the company did. (And worse, then obscured them behind fun but not descriptive names.)

Well, they do have Route 53, EC2, Elastic something on AWS.

Re: Charm – Tools to make the command line glamorous

#123

Earlier quoted context omitted.

You potentially send all your key IDs (ie public keys) your agent has. there are command line options to force your ssh not to use your agent in which case, barred any bugs in the ssh client, it’s like browsing to a domain in your browser.

This is the first time I’ve heard someone say sharing public keys is a security risk. Can you explain the threat model here?

If you ever manage to leak a private key it’s easier to track it back to you. There was a recent paper showing the ability to tie rather a lot of keys to the associated developers.

Re: Charm – Tools to make the command line glamorous

#124
I have one major problem with a lot of the recent TUI stuff that’s been happening: it almost always assumes dark terminal, and uses techniques that work poorly or terribly on light terminals.

For example: bat’s default colour scheme uses white text for the contents of files except where syntax highlighting changes it. Not the default colour, but white. This makes it completely unusable for me without --theme=ansi (which can go in ~/.config/bat/config), because the text is literally invisible unless I highlight it. This is an idiotic or thoughtless default.

The fact of the matter is that you can’t reliably do anything even vaguely interesting in colours, because clients are too inconsistent. Do the bright codes higher contrast, or do they mean lighter? Different programs and different themes treat them different ways, and the effects matter greatly.

This particular app is mostly not too objectionable in my high-contrast light colour scheme, but there are a few places where it’s clearly not what was intended and doesn’t work as well, though still tolerable. Pane focus outline is a fair way off so that it’s much less obvious, and some of the colour choices grate. Markdown `code` highlighting, which is supposed to be salmon-coloured with a subtle lightening background, is way off and quite painful. Screenshot: https://temp.chrismorgan.info/2022-01-24-git.charm.sh-in-lig...>. It’s all particularly bad for me with a light terminal, but I imagine it’ll look at least mildly dodgy even on many dark colour schemes.

There are no satisfactory choices in designing TUIs with colour. You can: stick to 5–6 colours plus bold and have it work pretty well for everyone but miss out on some desirable possibilities; go up towards 16 and have it start to not work properly for more people (e.g. blue could be clearly visible, or nigh-invisible against black and just about painful to read); use 256 or 24-bit and design for a particular background and character of colour scheme, and feel badly out of place on other sorts of colour schemes and work really badly in other sorts of backgrounds, especially as you can’t predict whether a lighter colour means higher or lower contrast; or specify the background colour (only even vaguely reasonable for full-screen TUIs) and badly annoy a lot of people.

It’s unfortunately a dead end for design as it stands: ANSI colour codes are just very insufficient. Things could be improved if apps at least tried detecting the terminal’s default foreground and background colours (printf "\033]10;?\033\\" and "\033]11;?\033\\") and adjusted things if that works, but you’re still just fundamentally quite limited in what’s possible.

Re: Charm – Tools to make the command line glamorous

#125

Earlier quoted context omitted.

You potentially send all your key IDs (ie public keys) your agent has. there are command line options to force your ssh not to use your agent in which case, barred any bugs in the ssh client, it’s like browsing to a domain in your browser.

This is the first time I’ve heard someone say sharing public keys is a security risk. Can you explain the threat model here?

I think it’s more of a privacy leak. E.g., the service could potentially figure out who you are if your public keys are tied to some other service, like GitHub.

Re: Charm – Tools to make the command line glamorous

#126

I liked their contact email: vt100@charm... :)

Everything there is worded so that sysadmins and devops kind of persons will love it. All the product names are cute and innocuous. This is a huge red flag and the entire operation is highly suspicious.

What do you suspect they are doing?

Re: Charm – Tools to make the command line glamorous

#127
post #70

Earlier quoted context omitted.

I really liked their web design.

Could you say a bit more about your demographic and what you like about it? It's definitely not for me, and I'm entirely ok with that. But I'm really curious about who it works for.

I never really liked the flat design, weird colors and shapes design trends from two years ago. So I'm happy to see subtle animations and gradients again.

Re: Charm – Tools to make the command line glamorous

#128

# Arch Linux (btw) yay -S glow Heh, nice take on the whole "I use Arch btw" meme. This is really cool.

What I don't understand is with the recent adaptation of GPU-accelerated terminals, why not create something that actually renders Markdown like you'd expect in the browser, but in the terminal? It would have to be significantly faster than the bloat of a typical browser, but just with limited features... like no JS engine.

What about 'glow' and 'glamour' components of the charm project? What is their difference from what you propose?

Aside: I use glow to display help for special keybindings mode on sway.

Re: Charm – Tools to make the command line glamorous

#129
post #44

Gross candy-store like website. I can not believe that the start page is nearly 14 MB big. And I still don't understand what they sell.

Yeah, there's some discrepancy that doesn't make much sense to me. It's more like terminal is a fashion to those people, rather than a practical choice. The fact that their SSH website is painful to use across the pacific ocean proves the point. TUI is not the answer for sure.

Re: Charm – Tools to make the command line glamorous

#130

I have one major problem with a lot of the recent TUI stuff that’s been happening: it almost always assumes dark terminal, and uses techniques that work poorly or terribly on light terminals. For example: bat’s default colour scheme uses white text for the contents of files except where syntax highlighting changes it. Not the default colour, but white . This makes it completely unusable for me without --theme=ansi (w…

lipgloss, the ANSI color library from Charm, has support for specifying different colors for light and dark terminals.

https://github.com/charmbracelet/lipgloss#adaptive-colors

Post reply on HN