If OpenSSL were a GUI (2022) | Hacker News Reader

If OpenSSL were a GUI (2022)

smallstep.com

190 pointstambourine_man62 comments

Actually, the example has way better discoverability than most CLI software, especially if every option had tooltips illustrating what it's for in more detail.

For an actually good example of adjacent software, have a look at Keystore Explorer: https://keystore-explorer.org/

I do manage my own CA for some development servers with it, way less of a headache than trying to remember a bunch of arbitrary commands (though obviously not well suited for any sort of automation, which I don't need in that specific use case).

For an example of a pleasant CLI with some good discoverability, I've always liked Docker's approach, where the commands are organized in a tree and entering a command without any arguments will print its usage in a useful format: https://docs.docker.com/reference/cli/docker/

  $>docker
  
  Usage:  docker [OPTIONS] COMMAND
  
  A self-sufficient runtime for containers
  
  Common Commands:
    run         Create and run a new container from an image
    exec        Execute a command in a running container
    ps          List containers
    build       Build an image from a Dockerfile
    pull        Download an image from a registry
    push        Upload an image to a registry
    images      List images
    login       Log in to a registry
    logout      Log out from a registry
    search      Search Docker Hub for images
    version     Show the Docker version information
    info        Display system-wide information
  
  ...

My favorite part is the punchline:

“This is incomplete. It covers about 80% of one corner of OpenSSL's functionality. The certificate policy options have a lot more knobs that I didn't include.”

This may be a nice example of the benefits and drawbacks of GUI vs CLI software.

Sure OpenSSL has myriad inscrutable options, but the majority of these probably aren't going to be used by 90% of people. Yet including them in a CLI gives less clutter/overhead versus what they would in a GUI. They can just stay out of the way for the people who need them.

I guess the same could be said of an "Advanced Features" second page of a GUI though.

I host a usable web app for this idea, including a full CLI via WebAssembly to illustrate the trade-offs

https://openssl.tplant.com.au/

The OpenSSL command line is more or less a test driver / reference for the library. It's a little weird to criticize its UX. Also: it's pretty easy to make something look bananas if you surface every obscure option in its main screen!

I don't think it's a critique of the library; calling the x509 specification complex enough to be magic seems accurate.

Honestly I love the UI presented: concise, shows all the options, a fantastic summary of the CLI without having to scroll a massive man page or website.

I'd love this for all the super complex CLI tools I need to use, as a visual cheatsheet on where to search in the man page.

I wrote a personal tool to do this automatically by parsing '--help' after I couldn't remember the tar options for the millionth time. Turns out the programs that have complicated, undiscoverable interfaces also tend to omit useful options from automatically discoverable documentation, so it wasn't especially reliable.

Reminds me of a similar wish for argv introspection I had at some point (e.g. https://github.com/ImageMagick/ImageMagick/issues/7688) that went nowhere. I hardcoded curl this way.

A long time ago, Apple actually did more or less this for the coreutils in A/UX, which was their own UNIX for the 68k Macintoshes.

This page has a screenshot of the GUI provided for ls: http://toastytech.com/guis/aux3.html

What an incredible website

I’ve always found it a shame that the UNIX philosophy seemed to stop at system/command line tools and no one ever took the further step to apply it to user interfaces.

UIs generated in systematic, composable ways emerging naturally from all the plumbing (pipes, option flags, etc) we already have in place.

Every few years I get the urge to dive into smalltalk/squeak/cuis/<insert smalltalk variant here> and while it suffers from being pretty heavily stuck in an era and a small community it always feels like a window into what could have been if operating systems in general and unix in particular didn’t stop at CLIs with a window manager tacked on top. In fact having recently revisited some old classic Mac things, it’s sort of interesting to note how despite how nice it is that osx has Unix underneath and windows has the WSL it also means we’re converging on a design with a lot of old baggage.

There was a time when I'd have agreed with you. But over time I've come to honestly disagree, perhaps unsurprisingly, since I detest the typical command line experience too.

Just like when books are adapted into movies, the good adaptations are the ones that are better than the sum of their parts (aren't a direct adaptation). Blind, generic composability is in direct contradiction with this. One could argue that it's the scale that determines whether a better integrated or a consistent but generic solution is better, but in this case I think the article very explicitly demonstrates that the latter approach is what loses out.

I have a very strong and persistent disdain towards the many shell incantations I had to come up with, have to keep around as notes, and have to have AI generated. Having to navigate the maze the article calls a GUI would result in much the same.

I feel like I'm taking crazy pills seeing people in this thread regarding this visual any good, especially given how even the article author clearly disagrees, hence "why" the article was created in the first place.

https://github.com/chriskiehl/Gooey

I'd love this for all the cli tools. Instead we'll get more boot managers and desktop managers.

Consider helping make such a thing!

> The OpenSSL command line is more or less a test driver / reference for the library

hmmm, not sure about that. Its the main (only?) interface if an individual wants to mess with certificates or generate them. It is often reported ACME/LE took off because it is easier to configure an ACME client than the annual wrestling with openssl. But if openssl had been easy for common user tasks maybe LE would have taken longer to be adopted.

ffmpeg also has a notoriously difficult CLI interface. Today you can just ask a LLM to generate you a command, the consequences are low if it gets it slightly wrong. The consequences of getting openssl wrong could not be obvious immediately and result in a lot of debugging down the line.

LE took off because everyone was charging ridiculous amounts for certificates and few people needed the verification that comes with that. ISRG created ACME for LE.

One of my personal frustrations with SSL as implemented in most systems is the conflation between encrypted communication and verified communication. SSH sort of got this right with ToFU as a default behavior but I think a lot of the resistance and difficulty in adopting SSL for encrypted intranet communication comes from the need to do the CA and cert signing song and dance. If you could turn on encryption without needing to do ID validation by default it would make things easier for people

I know that encrypted communication without knowing that your talking to the right person is somewhat useless, but it works for SSH most of the time, there’s no reason it couldn’t work well for https and encrypted db connections etc.

I recommend https://cryptography.io/en/latest/ as a way to use openssl library instead of the command line.

That actually looks very useful. Thanks.

I think you are right. On the other hand it’s the fact that a lot of tutorials / getting started guides etc include some ssl invocations to execute a specific command for key/cert creation. And a user wishing to adjust and maybe understand things gets thrown at a man page that is so overloaded. Similar to git. But git’s cli at least has a clear setup with optional vs mandatory values. I always disliked commandline interfaces with mandatory option fields.

Where do I find the UI for it then?

I don't know why, but three systems make me google the correct command line options every time I need to use them:

1. OpenSSL

2. Systemd

3. PGP

I have no idea why, but their command line interface is just somehow confusing.

I would argue that core systemd CLI interface is fairly compact and memorizeable (systemctl start-stop-restart, simple journalctl invocations). Some obscure directives still result in a trip to manpages though.

Openssl, PGP and (mentioned in the thread) ffmpeg are often run on one-off basis with changing inputs and outputs and thus almost always require searching the Internet for the correct flags.

so they're like prepared SQL statements in a sense?

IMHO bringing SQL in is a bit of a stretch; I believe prepared statements are generally strict about their n-arity. Key systemctl commands accept lists of units as subjects of the command.

If we were using the SQL analogy, I'd say stored procs were closer.

Systemd is a weird one, because I do feel like the user experience is fairly well managed, things makes sense when I read them and use them, yet next week, completely gone.

As someone else pointed out, perhaps it's not entirely fair to critic the OpenSSL commandline tool too much, it is in some sense a catch-all reference implementation. On the other hand, Curl have a million options as well, but seems really well put together. Maybe because you only really need a small subset of Curl most of the time, but the same is true for OpenSSL.

I realized why. Systemd splits journalctl and systemctl into two utilities. With journalctl having impenetrable command line options that put `tar` to shame.

If systemctl had something like `systemctl logs -f service`, it would have been much more welcome. Also something like `systemctl start --logs --follow service` would be great.

I'm going to file a ticket for them.

Huh. That's exactly my experience.

I suspect that its a combination of three things: first, they are not frequently used, second, their CLI is very complex, third, their design violates normal CLI conventions in weird ways.

I don't have the same problem with things like docker or git, which are arguably more complex.

Pro (Newbie) tip: use a GUI for git (like lazygit or VS Code Source Control). Git is one of the few complicated CLI tools that actually works well as a GUI, so take full advantage of it.

Very interesting! I was on another thread where the user stated that they preferred the git CLI to using a git GUI, because the GUI imposed another layer of conceptual complexity on top of an already complex tool.

May I ask what git GUI you use? lazygit?

I used IntelliJ and emacs' magit. I don't know what "extra layer of conceptual complexity" they're talking about, it's very straightfoward to me (admitedly, I knew the CLI well enough before I started using GUIs so maybe I had already internalized whatever concepts they're think about).

I use navi cheatsheets for that. You can store commands with descriptions and easily execute them. This is where I put all the "will need only once a year" commands.

What I do google is ffmpeg, but not before every online editor/converter on the internet completely betrays my expectations and makes me reconsider my life choices.

[0] https://github.com/denisidoro/navi

And FFmpeg. :)

4. Git

Git has entered the chat

If OpenSSL were a GUI - https://news.ycombinator.com/item?id=31697636 - June 2022 (234 comments)

At every enterprise job I have been in, there was always a quagmire around renewing or exchanging certificates.

The corresponding tasks always required disproportionately many high-level meetings and discussions for their actual simplicity.

I always attributed this directly to the complexity of the OpenSSL command and the fact that these tasks include hard deadlines because of certificate runtime.

The complex discussions which ultimately result in some simple commands mirror the OpenSSL CLI: you have to understand and articulate precisely what you need.

That being said I wonder some of the options (like "this file is a CER", PEM vs DER private key, etc.) couldn't be replaced by auto detection.

I'm looking forward to "If Python Were a GUI."

Well... https://docs.python.org/3/library/idle.html

Also, Jupyter(Lab,Notebook,QtConsole,etc), Marimo, Spyder, and a bunch of other good GUI-like options. :)

Is this fair though? Most common tasks have tutorials all over the net, so creating a GUI should consider these use cases instead of piling every option on the main UI. Many of these things are also just options that are right for one system and the user will use always the same parameters, therefore you should be able to hide this in the settings instead of showing everything at the same time all the time.

X.509 certificates are not simple, the majority of the complexity being in the extensions, and OpenSSL's x509 command can be used for many different purposes. I am reminded of an old saying in the GUI vs CLI war: "what you see is all you get", and in this case, you get a lot.

It's not really hypothetical, putty settings dialog has similar complexity, but is implemented as a settings tree and designed to fit ergonomically on 640*480 screen.

Tangentially related, if you generate certificates infrequently enough that you always have to look up openssl command line options check out https://github.com/chris2511/xca/.

It's basically keepass but for certs instead of passwords.

I host a usable web app like this, including a complete CLI via WebAssembly. it's surprisingly useful for teaching, kind of like CyberChef

https://openssl.tplant.com.au/

Something about the cookie banner on this site hijacks my history so I can't go backwards.

I sort of don’t hate this! Push these around a bit and that looks pretty usable to me.

I've found this tool handy for faster-than-man explanations of various CLI invocations:

https://explainshell.com/

Sadly, it hasn't been updated in years.

Is there a command line to UI converter? That feeds off CLI autocomplete? Would be awesome for discovery.

the only thing this proves is that you can make any tool’s UX look terrible by putting all settings as one big blob.

One big blob? There are over 40 tabs.

now we need similar GUI, just for ffmpeg

It exists, and that’s called a video editor.

Handbrake(.fr)

thank you

(2022)

... But I doubt OpenSSL has changed enough to make this out-of-date.

Now let's do ls

"GUI make simple things easy, and difficult things impossible"

Sooner or later everyone must go CLI =3

Yeah it is kind of silly to believe check boxes, radio buttons and drop downs somehow make things easier. They don't especially when the options are anyway complex, mutual incompatible or even dangerous if clicked random! I can't fly the Boeing 747 with digital controls anymore than I could a WW2 era hydraulic one.

Added later: I should have said 787 - the 747 is almost WW2 era itself!

These were the only commands I ever needed and I found them pretty straight forward. With LLMs today at your hand, command line is the king, ux was yesterday.

Check expiration of web address manually:

    openssl s_client \
        -servername service.local.mytld.com \
        -connect service.local.mytld.com:443 | openssl x509 -noout -dates

Check SSL cert:

    openssl s_client \
        -showcerts -connect service.local.mytld.com:443 </dev/null

Check local SSL cert from disk:

    openssl x509 -noout -text -in wildcard.local.mytld.com.fullchain

Reply on news.ycombinator.com