This is funny, but the OpenSSL CLI is in large part just a series of utility/driver/diagnostic programs for library functionality that isn't expected to be used on a standalone basis. It's the industry standard for generating certificates, but that's because the industry doesn't understand certificates; most people should be using nothing but certbot and mkcert.
What bugs me a little is the idea that you might want a well-designed version of what the OpenSSL CLI offers. Bad idea! You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.
Perhaps it's worth mentioning XCA [1] at this point. It's a GUI based on openssl that provides an intuitive UI for managing keys, certs (root CA, intermediate CA, server and client) and CSR. It existed before acme and mkcert. What I liked in XCA was that it made it easy to review all parameters related to the operations it managed.
Maybe there should be, but for many things that openssl can do (for example, testing and debugging a TLS connection, examining the contents of a certificate, creating a CSR to send to a non-ACME CA, converting between different formats of certificates, etc.) I'm not aware of good single-purpose tools.
I use certbot to maintain valid certificates for my website, but there are more use cases for certificates than just https binding--and not all of them lend themselves to LetsEncrypt provisioning. The openssl CLI is definitely not simple, but in my experience it has often been the best available tool for various use cases.
To use day by day? No way. It's like running your car with a cross-section cut out. Fun to look at! Might work! Might break when you stick your finger in a moving part.
But these are expert level tools. The "running your car" equivalent for TLS is making sure the little padlock is closed in your browser.
A car mechanic has a ton of shit in his shop from hydraulic plattforms to torque wrenches and electronic diagnostic equipment, but you only need to put gas in and go to the shop when a warning light comes on
> You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.
I want both. Different higher-level crypto tools have different limitations, whereas OpenSSL can do absolutely anything I could ever want. When I'm trying to get BouncyCastle, PyCrypto and whatever library that random IoT device that I need to reverse engineer uses to play nicely together, I need a tool that can work with all of them. There are so many weird extensions and optional parts of the standards that I need to configure just right and no high-level tools expose all of them.
Sometimes you just need to generate a key or check a cert and for that, high-level tools are far better. But sometimes you need to do something in just the right way because of reasons outside of your control and in that case, you need to have every single one of those options and switches at your disposal.
> most people should be using nothing but certbot and mkcert
Most people likely don't know (and don't have to) about any of those, possibly most tech workers could indeed get away with just those two (though openssl has useful functionality other than key/certificate generation, but I guess one can avoid using that too), yet even mildly advanced usage would require more advanced tools. Actually certbot is primarily an ACME client, so not easily interchangeable with/comparable to openssl, while mkcert only covers one very specific use case: probably common in that middle group, but I don't quite see why it needs a separate program: a basic shell script (or an alias) would achieve that.
> You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.
Well, it offers that thin layer rather well! Seriously though, there's likely some middle ground between mkcert's lack of options and openssl's functionality covering a lot of other bits in addition to X.509 certificates. Though then again, you can consider `openssl x509` as basically a separate program, with its own man page and options -- and then it focuses on one thing, providing a rather complete functionality.
Middle ground certainly exists and has done for decades already. MacOS X has shipped with a very capable PKI GUI for a long time. It's obscure and not well known, but:
1. Start the Keychain App and you can manage your certs and keys.
2. Click the app menu, Certificate Assistant and then one of the options there to open wizards for various PKI related tasks.
The certificate assistant is quite amazing. It can do an enormous amount of stuff, including things like actually running a whole CA for you complete with creating root certs, intermediate certs, gathering CSRs, converting them into issued certs, evaluating cert validity, rendering cert contents and so on.
People don't know about it because only developers interact with certs really, and documentation likes to have copy/pasteable commands that work on Linux as well as OS X.
> What bugs me a little is the idea that you might want a well-designed version of what the OpenSSL CLI offers. Bad idea! You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.
To exaggerate a bit: should you always want a tool that's one button that's all some other dude's opinions? Isn't there a place for a tool like "well-designed version of what the OpenSSL CLI," but as something that would be less frequently used?
I think the point is that there should be multiple tools, each with its own UX that's specifically tailored towards one particular scenario that OpenSSL covers, and with customizable options that are relevant to that scenario.
There are lots of systems that don't support ACME. Enterprise firewalls for example are just starting to support it. Lots of embedded devices still do not support it. Older enterprise servers have either very poor or not compatible enough to make it work reliably.
GUI's can be counter productive for theses kind of tool. There are some contexts like "SSL" were the user needs to understand the underlaying concepts a UI cannot teach in itself
I believe they do. Configuration files usually have comments, GUIs typically lack that or documentation. If they do not, you have to look it up somewhere. GUIs could have documentation, but it is very rare I would say. It is something similar with the CLI flags as well. That is just my opinion. Maybe I am the only one who reads manual pages that explain what a CLI flag is supposed to do, or for example what key X means in a configuration file.
I have been taught more by those two, than by GUI. The only thing I could imagine that may teach me through GUI is Smalltalk, but that is very limited. On top of that, GUIs might be less common for whatever reasons as well in the UNIX world.
Configuration files occasionally have comments. CLIs sometimes have man pages. GUIs sometimes have tooltips and often have additional help documentation. I'd say that's pretty much a wash. But GUIs can also much more easily convey complex relations between options, such as some option only taking effect when another two each have a specific value, or even simpler things there being a specific set of permitted values for an option. Sure, you can document the cli but that information is probably going to be inherently presented as part of the GUI.
Truly great GUI design is very challenging. I've used very few applications which I think have a truly great UI that beats the CLI in terms of the efficiency of presenting options in orthogonal and conditional ways (orthogonal: two features which don't interact at all can usually be programmed independently and appear in distinct locations, while conditional: options that are only valid if another option is set to a specific value).
The best UI I've worked with so far is Fusion 360. Like most 3d modelling tools it has a fairly steep learning curve, but it does a fantastic job of making your life easier. It has a bunch of UI dialogs for parameter setting (some of which are better than others) that do a good job with both orthogonality and conditionality. I really wanted to like blender but just about everything in it feels rotated 90 degrees to how I'd do it.
> I've used very few applications which I think have a truly great UI that beats the CLI in terms of the efficiency of presenting options in orthogonal and conditional ways
I can think of so many off the top of my head: Word, Excel, PowerPoint, Chrome/Firefox, Acrobat, Audacity...
And this is before you get into stuff dealing with pictures, like Photoshop or literally almost every modern game.
You can do most of these on the command line (see ffmpeg, imagemagick, etc.) but I'm pretty sure > 99.99% of people do not prefer a CLI version of such applications over the GUI forms.
IMHO the power of CLI apps isn't in their orthogonality or presentation, but ease of automation and composability, and the ability to cram a ton of features into a single interface without really caring about how easy it is to use for 99% of people.
Rather than listing several specific applications, what i'd do is generalize:
Word processors: are a real improvement over using ed at the CLI, or really any scripting tool, to process large amounts of human-readable text. Although in many cases, simple markup on simple text in a simple text file can be excellent.
Spreadsheets: for all that people complain about spreadsheets, they do a few things fairly well (cellular data model, dependency-graph-driven computations)
PowerPoint: I should have mentioned that "sheets/slides/presentation" apps are one of the best examples of this; features like "Align vertically" are a great example of where UIs make certain operations very intuitive and easy
Browser: I dunno, I prefer e-links :)
Music editing: Actually, the whole world of track-based video and music editing. This is a such a huge improvement over any other system (musicians and video professionals may disagree), specifically the ability to quickly view, cut and paste, and combine multiple parts of longer videos. A lot of this depends on a concept that only really became feasible once disk storage really became huge: https://en.wikipedia.org/wiki/Non-linear_editing
Composability and orthogonality go hand in hand- much of my argument rests on the idea that composing orthogonal features is trivial for UIs, whereas composing interacting features leads to combinatorial complexity and can really only be expressed in code (and possible visual programming- being used more and more commonly to give artists GUI control over complex code-like operations).
The automation is the last interesting bit- will visual programming ever become ubiquitious, so that most people doing automation don't actually drop down to some CLI/text interface/programming language?
Nobody will argue about the advantages of a WYSIWG text editor, file manager or spreadsheet over their CLI counterparts.
The problem is that for any of these kinds of applications it is possible to do either a great GUI, which enables maximum user productivity, or a bad GUI, which slows down the user.
Sadly, if I try to remember the best user interfaces for such programs, the award still goes to some ancient MS-DOS programs that I had been using 30 years ago, i.e. the Brief editor for programmers, the Xtree Gold file manager and the Lotus 1-2-3 spreadsheet.
Those programs did not have real GUIs, because they had to use the text user interface of MS-DOS, but they already had the most important features of any GUI, e.g. tiled windows, pop-up windows, menus, histories for any kind of user input, many kinds of visual selection, scripting, keyboard macros, and so on.
After you learned the keyboard shortcuts for menu commands and maybe you also developed your own custom keyboard macros, it was possible to perform any task on those ancient programs much faster than on any modern equivalent.
I am not sure which is the reason, but maybe those old programs were more efficient because the mouse was optional. You could use a mouse if you had one, but the programs were perfectly usable without a mouse.
I assume that because of that, the developers paid a lot of attention of how to ensure that every task could be done by pressing a minimum of keys.
Even if most modern GUIs are supposed to also support a keyboard-only use, in practice I always discover that some operations are either impossible or extremely awkward when not using the mouse. (when using just the keyboard, a graphic selection cannot be expected to work as well as with a mouse, but any kind of text selection should be as fast or faster)
A point-and-click user interface is supposed to be better for a casual user, who cannot be familiar with the complex keyboard-shortcut sequences that might be needed for performing a task at maximum speed. This was certainly true for almost all GUIs in the first one or two decades of their use, but many modern GUIs have a lot of very well hidden and hard to discover options, so being a GUI becomes no improvement over a CLI where you need to read the man page.
In conclusion, there is no doubt that GUIs should be better for many tasks, but in practice one encounters too many bad GUIs, for which it may be simpler to use ancient CLI alternatives.
> Nobody will argue about the advantages of a WYSIWG text editor, file manager or spreadsheet over their CLI counterparts.
I think you've never met a LaTeX fan.
Regarding spreadsheets and file managers: for simple tasks I agree they can be better than the command line. But for even a moderately complex spreadsheet I usually prefer a python script, and I've seen office workers spend literal hours doing something that could take me under a minute using the command line.
I wonder what versions of those GUI applications that you like have you used.
I was very content with the GUI of Word, Excel or PowerPoint of 20 years ago.
On the other hand I despise the recent GUI of MS Office, where many options are not grouped in a way that I would consider rational and it is frequently very difficult to discover where some options are hidden.
The same with Internet browsers. I was very content with the GUI of Netscape Navigator, then Mozilla.
Firefox was worse than Mozilla since the beginning and it became worse and worse, with various options becoming more and more hidden or disappearing completely. Opera had retained for a longer time than other browsers a traditional, more customizable GUI, but then it has also succumbed to the modern fashion of dumbing down the GUIs.
When the tabbed windows were introduced in the Internet browsers, that was a great improvement. However, with this exception, in my opinion the browser GUIs have become worse, not better, than the old GUIs, because I have lost control over many features that I could configure in the past, while other surviving options have become increasingly difficult to discover.
So if we refer to their current versions, most of your examples are for me exactly the examples of the worst modern GUIs.
So you are saying that MS Office products have 'truly great UI design'? You must be using a different version than me. The web-based version is full of bugs and the traditional desktop version is neither a good choice for well trained nor for complete newbies. Instead it is some kind of weird compromised.
To give an example of not so great design: One thing that bothers me every day is the dialog that comes up when you want to 'save as' a file. There are about 3 different versions you can go through, depending on, if you want to use Sharepoint/Teams, OneDrive or you local machine to save the file. They all have different capabilities (e.g. some allow creating new folders), appearances and some are only usable if you want to use a recently used location.
Granted MS Office certainly has not the worst UI design, but in my opinion, those applications are pretty far away from 'truly great UI design'.
Automation and composability are an important part of a UI. CLI tools also generally beat GUIs in speed. A hypothetical text2pdf runs almost instantly. Doing the same thing with Word can take 5 minutes.
Have the same feel when two months ago i switched from 10 years vim usage to intellij for code. The UI is so well designed, the "everyday's coder problem is so well understood in the UI layer its just a pleasure to work with this tool. The UI just reflect that. Everything is just so well organised. As a web UI developper, and despite material/responsive requirements i refer often to IntelliJ's GUI. Its just so well designed.
OpenSSL can have this kind of UI. Its just a matter of understanding user requirements.
IIRC Fusion 360 has radial menus (https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-6514...), and I think it was a major part of Maya or another one of the older modellers. I was never a huge fan and the mouse model still trips me up (imho, mouse-button-1 drags should rotate, and shift/alt mouse-button-1 pan and zoom, respectively).
Also, everything in Fusion 360 could be done in Qt5 without a lot of work, it's just that getting all the hints and the second level details (like maintaing the selection when you switch tools) is a real bear.
I work in industrial design and the use of Alias for surface modeling is quite prevalent (and has been for decades). It used to be called PowerAnimator, and marking menus were first added somewhere around the release of v6 (1995). Alias/Wavefront actually incorporated this functionality into their first release of Maya several years later, trying to innovate on the feature further with the use of hotbox menus [1][2].
Since Alias corp. was later acquired by Autodesk in the early 2000's, you can imagine Fusion 360 as being the symbolical evolution of it. Especially considering the current Alias UI has not changed much since 1999! [3][4]
If interested more on this topic, fun HCI bath-time reading: Gord Kurtenbach's 1993 dissertation on The Design and Evaluation of Marking Menus [5]. Not surprisingly, from Alias/Wavefront he went on to head Autodesk Research for most of the 2000's.
Cool, thanks- I had forgotten about Alias before Maya. I was introduced to radial when Maya came out (somebody demo'd in, I was interested by couldn't afford it).
I think of Fusion 360 as being more descended from Inventor (which defined a lot of my early expectations for 3d modelling). I'm only a hobbyist and I used Fusion 360 with large (mesh) surfaces (it got significantly better at meshes recently) and it definitely got clunky, although the performance is fine when working with parameteric brep objects.
I've been using Autodesk products (starting with 2D AutoCAD on a 286 running DOS) for quite a while (35 years).
Radial menus have the same problem(admittedly to a lesser degree) as icon fields(for example, a phone home screen, or most file explorers), they fail to be well sorted and as such are harder then they need to be to find things. A linear list with a search option, or better yet a table where you can sort by several attributes is a better option.
That isn't a praise of GUIs, it is a damnation of OpenSSL
The exact opposite of *NIX philosophy. Don't do just one thing well, be Swiss Army knife, the largest one you have ever seen, with a lot of the blades poking part way out, so you may lacerate yourself at any moment.
I heard rumors on HN that security agencies had a hand in making the protocols overly complex, hoping that would cause bugs in implementations they could exploit.
Security agencies have spent hundreds of millions of dollars per year in its efforts to undermine internet encryption standards and implementations. One well-known case is Dual_EC_DRBG, in which the NSA backdoored a NIST encryption standard and bribed companies to implement it in widely used products.
All of this is well documented by numerous major news outlets, especially since 2013. I wonder if people screaming "conspiracies!" are doing so in good faith.
Dual_EC_DRBG was a little different. It introduced an asymmetric key that only the NSA had the private key for. So only the NSA was able to exploit it. If they were to make stuff complex generically with the hope of it being buggy, it would lead to bugs that other intelligence agencies could exploit.
Do they really care though? NSA's previous handling of zero days [1] suggest that they care more about advancing their offensive capabilities even if it means putting critical public infrastructure at risk.
"Heard a rumor" was there to provide an estimate of how (un)reliable the information was. My hope was someone would be able to confirm it, and it was not my intent to pass it off as confirmed fact. Regardless, as the sibling poster noted, they have already been caught weakening standards.
No conspiracy needed, they deliberately sabotaged certain standards to make them weak/easy to break, until it was caught by the security community and they were rightly rebuked for it. Like DES
This may sound plausible at first, but if you've watched these kinds of things for a while there's an entirely plausible other explanation. Everyone wants to have their little special case feature in, and nobody says "No!". Very few people actively try to avoid complexity and favor simplicity in standardization processes, even fewer did up until a few years ago.
"Avoiding complexity is good for security" is the thing that everyone will claim to agree if you say it, but hardly anyone follows in practice.
Sprinkle in some security by obscurity; “If we just use our own variant of the algorithm , the hackers can not use common exploits!!”
Scare of liability is another plausible reason. Nobody wants to be famous for picking the wrong default algorithm that exposed the whole internet. Easier to blame each individual user for choosing the wrong exponent or number of padding-bits.
I wish we had a layer 6-ish security protocol that "just worked" the way HTTP just works. Something analogous to an ssh tunnel, where once you establish the correct keys (via a single, simple operation), clients and servers can just talk with no extra application-level configuration.
Currently if I want to use HTTP2/3, I have to fuss with openssl, self-signed certs (which never seems to work reliably for me), messing with /etc/hosts... it's always just painful for me for some reason.
When using kubernetes you have Service Mesh. Not the most easy.
Outside of that there is like you say SSH tunnel or other forms of VPN. Except those are usually more global and expect all players inside the network to be dmz.
I think people are wildly missing the point here. This GUI mock-up is not about improving usability, it's a comment on the hideous complexity of OpenSSL. The visible tab's options represent, in the words of the author, "80% of one corner of OpenSSL’s functionality". There are 45 tabs shown. On my monitor, this one tab is over two pages long. If the other tabs average out to a similar length, there would be around 100 pages of options available.
That is too much complexity for a single security-critical program.
OpenSSL is a "swiss army knife" for all things security... making a bad (mock) gui makes it look a lot more terrible than it really is. Imagine the same gui for bash settings, ffmpeg or even just a browser (just look at the size of about:config!)
Most people do just one of a few operations, where they copy-paste the commands found online, as they do with windows registry, firefox about:config or ffmpeg, so it's no different than that.
I'm a CLI guy, but `openssl` is insanely complex and I think it would benefit the ecosystem immensely if someone built a wrapper CLI that made it easier to complete the small handful of popular use cases that 90% of us have to go to Google to remember.
If you make a GUI out of this, it will be a pain in the ass... and ugly!
Luckily, there are many ffmpeg frontends, that select just a tiny subset of commands that are most often needed (like yours and many others), and the same things exist for openssl, eg:
>if you make a GUI out of this, it will be a pain in the ass
I guarantee you, 10000%, that it will still be more usable than CLI is without having to google everything. FFMPEG is so complex that doing anything with it feels like talking in some ancient archaic code known only to the video tech wizards, and a GUI would absolutely make that better.
I don't think a Swiss army knife approach is a good idea for security software to begin with. It's a good way to generate cruft and lock yourself into questionable design decisions due to Hyrum's Law. It's not great for auditability, either.
FFmpeg is a practically an entire non-linear video editor in a CLI tool. That is indeed a lot of complexity, but the stakes are low -- if you screw up an FFmpeg command, you've lost some encoding time, not your entire password database. (I get the impression a lot of FFmpeg's functionality wouldn't serialize well, either, but I'm far from an expert on that.)
Nobody on Earth ever has or ever will like the Windows registry.
The entire point is that libavcodec exposes a different interface. You wouldn't build a GUI for ffmpeg, you'd build one for libavcodec unless your actual goal is generating ffmpeg commands.
> That is too much complexity for a single security-critical program.
Looking at this x509 page, a lot of these options kind of seem like "required complexity" to me. There's a few things that aren't really needed (like the string conversion stuff) and a few things that could be condensed in one option (the "Print [..]" options can be one "print [list-of-fields]"), but those are relatively minor things.
The thing is, SSL/TLS is kinda complicated, but that's not really OpenSSL's fault.
Sure, I'm willing to accept that the X.509 is inherently complicated and there's not much OpenSSL could do to simplify it. But that seems like a good reason not to add support for 44 other major operations to the software...
If you want a tool that "just generates certificates" then it's easy, but if you want an advanced management tool that can do all sorts of things then you will end up with something complex because TLS is complex with a lot of different parts.
And yeah, the openssl tool could be designed a lot better, but much of this is a matter of UX and managing complexity, not so much reducing it.
Also fun thing is that openssl doesn't even properly handle all of the cases and complexities of x509. Like subject altnames and what can be included in there by certain specifications and standards.
It is. You're not meant to be using it directly. Some of what's in OpenSSL is just glorified test drivers. OpenSSL is complicated in large part because it is the de facto reference implementation for a lot of cryptography.
Jesus, I just realized how amazingly clean and dense UIs really can be.
Radios, checkboxes, sliders, complexity hiding tabs, help on hover (not shown), error messages on invalid inputs, making invalid inputs not representable in general etc.
Imagine every cli tool having this kind of mock ui as playground that spits out cmd line command with args - as help tool/whatever as alternative to medium sized book text help.
Apple's A/UX had "commando" - but I think these were manually-defined instead of dynamically generated (whereas PowerShell cmds all export their own parameter definitions so PowerShell can dynamically generate UIs): http://toastytech.com/guis/aux3.html
I'd imagine power shell has some way to pull the available parameters out of cmdlets (they probably all inherit from some cmdlet class or something.) On bash you have to get this from somewhere else.
Maybe it's because I've discovered it recently enough and I'm quite amazed at the possibilities, but I really think this is a great project for (using) Nix (even NixOS itself in desktop mode).
Here's my rough intuition.
1. Nix brings immutable packages (static, read-only), versioned as you wish to target various dependencies. (the `/nix` folder)
2. This means the goal is to create once and for all a GUI for each command, a static view.
3. Meanwhile, the Nix ecosystem is heavily curated yet quite expansive (some 60k+ pkgs IIRC), and a decentralized part is evolving towards an AUR-like mindset (the NUR, Nix User Repository). These are the people you want to polish a good-enough-but-not-perfect GUI automation tool. Remember, it's a one-off, since each version is static, forever in Nix (thus presumably shared by all users).
4. An intuitively natural design to me seems to split the auto-GUI tool process in 3 steps:
- Parse and encode some `man` or `--help` output (probably needs a well-defined sub-spec to make perfect parsing predictable by devs targeting Nix). Generate some .gui_spec file.
- Read a .gui_conf file that overrides defaults (empty = defaults). This is where maintainers, designers and curators can rectify the auto-gui tool once and for all on a need-to basis. End-users may override this vendor-provided config in their home environment (notably to auto-apply DE theming parameters, etc).
- Generate final GUI executable for target env (should work in X/Wayland but also as a barebones terminal app with optional mouse support).
Basically, heavy lifting is done upstream by following a standardized auto-GUI specification (some DSL to call it bluntly, that happens to look like `man` + descriptors), and there is one layer of "good steward" curation before the recipe gets properly rendered by end-users' DE (+ optional local customization).
The point is to add as little extra work as possible every step of the way (if possible, none) by leveraging existing structures (man, nix, term/X/DE conventions, …) to apply "great defaults" automagically enough.
I'm pretty sure this is the next-level tldr and a killer feature at the tip of a shortcut for <insert cool shell>.
If I'm not mistaken, that's basically how shell completions work in Nix. At least for fish. Package derivations can include completion scripts at a special location. Users can override the provided completions either in their shell init file or using an overlay over the package. And in lieu of a manually written completion, at least fish can parse man pages and turn that into completions.
Docs say it's Windows only, sadly. Shouldn't be too hard to implement the same on another toolkit, although maybe upstream isn't interested in maintaining it.
There is a neat python library called Gooey which wraps command line arguments in wxWidgets with just a function decorator. Sadly the development seems to have stopped.
Only somewhat relevant, but Google Cloud does this in their console at least for some products. E.g., go through the UI Kubernetes cluster flow, but instead of clicking the create button at the end, you can click a button to get the equivalent `gcloud` command line. Also works for VMs, VPCs, and others I'm sure.
First saw this type of "use the nicer UI, get the command line equivalent" in 1989. IBM's homegrown version of Unix, AIX, had a system management tool, SMIT, that majored on this "emit the CLI equivalent" feature.
Its not really feasible outside of a mockup without much more work. Non-obviously, I assume this is a hand tuned layout for a fixed width window. Certainly elements are placed in arbitrary spots for aesthetic effect. The layout would look much worse if you changed the text by changing languages or if you tried to resize the window. Its a great mockup but realworld UI is very hard.
> Imagine every cli tool having this kind of mock ui as playground that spits out cmd line command with args
Interesting, my thought looking at this is “this is why complex tools work better in a CLI”. Discoverability is a nice ideal, but usage of this program clearly requires a manual due to inherent complexity. Showing all possible options in a window really isn’t helpful at all.
> Showing all possible options in a window really isn’t helpful at all.
Well, then you shouldn't.
Almost anything that's mature, evolved and complex can be represented like a nightmare with a bad UI. ffmpeg is the usual extreme example of a bonkers out-of-control parody of itself, yet there are useable UI's that wrap the most essential functionality of ffmpeg by taking some very popular use-cases and making them straightforward. Same thing with git.
I think something similar could be done with OpenSSL. Does everyone who works with OpenSSL really keep all that stuff (like in the OP's article) in their head? Maybe some, but the vast majority of folks will just follow a pattern of usage that someone else "pioneered". No one has time for that kind of incidental complexity, not in a CLI, not in a GUI.
The Quadra 610 I have running A/UX 3.0 is presently taking umbrage with your calling it obscure, and I don't have the heart to tell it that you're right.
And what you can't communicate with a picture is that the UI should also tell you what options can be taken given the value of the other options (like depending on what kind of certificate you loaded, etc). That's the big think UI are so powerful when managing a machine, they show you the state of the system and tell you what options are available from there.
This also demonstrates were CLI excels and where GUI's fall short. With the GUI your just stuck digging for the correct option and tab. With the CLI you can create aliases or shell scripts to make wrappers for complex CLI options. Not to mention building custom openssl.cnf configs.
Funny, when I looked at this my first impression was how much nicer the (hypothetical) GUI looked to use, with all of the functionality easily discoverable without digging through man pages and rewriting your intentions in terms of obscure flags.
To clarify, I'm not saying the GUI is actually better. But I wish we could bring some of those conveniences to the command line experience (way better autocomplete and command discovery).
Another second order factor is that precisely because the GUI just puts it all out there visually, it creates encouragement to start imagining what can be eliminated/automated, or at least shoved behind "advanced options (rarely needed)". What can be sane modern defaults vs reinventing the wheel each time. There are a ton of options in OpenSSL almost nobody should ever use in 2022 including some genuine footguns. Without discipline, CLIs are easy to just keep adding to, and scripting may well encourage that in the typical nature of creating a dependent ecosystem that discourages breakage. Not that there can't be really bad ginormous GUIs too but minimalism has a bit more human psychology behind it there.
Of course, for precisely that reason there are lots and lots of examples (particularly under "modern" "clean/flat" design tastes) that go to the opposite extreme and remove too much, get too information light and hide or eliminate stuff that's genuinely very important. But in the specific context of security software at least the current best practices thinking is that the fewer knobs and dials the better. A huge amount is purely legacy from when there were many more tradeoffs to be made in available compute power/memory vs security, but that fell away long ago in settings that would make use of complex CAs anyway vs something simpler. Not that simple CLI/text configs can't be easy too, look at WireGuard.
This topic strikes a little close to home right now too since I just went through an incredibly frustrating period of trying to put together some internal CAs with modern best practices (like name constraints) and it was quite the maze to get through. And having done it (or at least Good Enough) it definitely didn't need to be that hard. Ah well. Although then again, my experience also highlights to the perils of GUIs at the same time: I would have just used something like the built-in web gui CA generator on OPNsense, except it's so simple it lacks name constraints. Which then led me back into the red in tooth and claw world of openssl and ca config files. So there's the binary of both, an over simplistic GUI and an over complex CLI. Perhaps there are better tools bridging that gap but my searching failed :(.
It really comes down to "is this a one-time task you're trying to figure out" or do you want the options set once and never touch it again in a script.
With the CLI at least you can cut and paste the options from somewhere else.
Microsoft solved this for a lot of their server stuff by having a "show me the powershell command" at the end of most wizards. If you want to write a script, going through this process is usually a good idea.
"Cut and paste the options from somewhere" is a questionable practice even when it's not part of a security-critical workflow. And yet I'd venture to say that most people who use OpenSSL do so with commands copy-pasted verbatim from the internet, specifically because of its obtuse complexity.
Set-and-forget still requires you to know what to set.
I've got a visual memory. I'm going to remember some obscure sub-menu on a forgotten screen far better than a command I learn and expect to use exactly once when I inevitably need to find it a second time.
At first glance, it would be better with more separation of sections rather than cramming it all on one page. After a while it does become unruly, but it could be improved over time and after test case reports.
Some common functionality in tab ABC, and then opt-in for Headache Mode if necessary.
That makes me think... was your comment really necessary? Maybe it was my intention to let the reader draw their own conclusions. Maybe the expansion wasn't really necessary. I surely wouldn't have added another comment if there weren't the unnecessary downvotes.
The interpretation here is implying that this GUI exists to demonstrate good GUI design. It instead exists to demonstrate what it would look like if you directly mapped the APIs of OpenSSL into a GUI 1:1. This is not the ideal way to do that, of course, but I would argue that with really good APIs, if you did do something like that, it would wind up being quite passable.
How openssl is today is probably not so bad for what it is, though. The GUI design here might be doing it a disservice by intentionally not having as much hierarchy. But this is actually a really bad argument for why CLIs are better. That’d be like arguing that closets are better for organization than shelves because when you haphazardly throw everything from your shelves into your closet, your room looks cleaner when the closet door is shut.
This does not demonstrate that at all. This just demonstrates how bad a UI can be, if no thought goes into it at all.
Not everything has to be visible all the time, settings can be grouped, and the user can be guided through the settings piece-by-piece, instead of just putting every option next to each other.
This does not have a GUI because making a good GUI is alot of work + the target demographic are more technical people that are able to use the CLI, so why put in all the effort?
Many of the settings are unnecessary, for example, input file format switch: I would prefer a computer to figure out this for me. And there is no need for all those "display X" switches because you can display everything at once.
CLI is useful for something you know and want to automatically reproduce. But it sucks if the thing you want to do is one-shot or too rare. You read the docs, few tutorials, type the command, aaaand the task is done, the knowledge is gone. I’d just sit there with a black screen if every time I wanted to change a wallpaper I’d have to type out something like `sudo desktopctl -X --ignore-duplicates -f aspect -c 180 ~/path/to/image.jpeg`.
An actual GUI for openssl tasks could be hugely more user-friendly than the one depicted here. If anything, it demonstrates that a GUI interface could be superior (for non-scripting use, obviously), because the depicted version is meant to illustrate the CLI experience.
Maybe that's also why visual programming never took off. There's just a sense of "power and control" that comes with raw text that's unmatched in GUI apps.
I agree with your point about CLI. At the same time, I wish we had more GUI *inside* CLI. For example, an interactive and pretty MAN page that's not just text, but has clear borders, boxes, buttons (with keyboard shortcuts), and uses different colors for different sections (e.g., command description, arguments, examples, etc.)
I think there's a strong case for a lot of systems having both a GUI and a CLI, because there are purposes each excel at, and a user may want to be able to switch between them depending what they are doing.
The Jony Ive quote "When something exceeds your ability to understand how it works, it sort of becomes magical” sounds like a restatement of Arthur C Clarke's famous quote: “Any sufficiently advanced technology is indistinguishable from magic”
Brings back memories; the Apple Platinum look appeared around the time when 90% of the UI was black-and-white or at least boring so it really seemed to instantly transform the Mac into a professional-looking tool.
I can’t wait until they release it (oh wait, they did, decades ago; now we just have — whatever — the Mac is now).
Honestly: this is what I dislike about OpenSSL. There are so many different knobs you can turn that I'm not sure how to use it securely, or whether specific options increase or decrease security. Its documentation seems to assume a lot of background knowledge about cryptography and the technologies involved, making it particularly tricky to get things right or figure out how to perform even simple workflows safely.
Side note: the cookies preference pop-up on that site is absolutely evil. Anyone who actually chooses something like that is an asshole.
It's funny that someone who writes an article about how crazy of a GUI OpenSSL would have to have would also have a form that someone needs to fill out to opt-out of bullshit tracking. It's almost as if... Never mind. This Carl Tashian person is just shitty.
The controls in that pop up are definitely worse than the ones in the OpenSSL GUI mockup. The boolean switches suffer from the same problem of many light switches: which is the on position and which is the off one? The radio buttons in the mock up are impossible to mistake. Accept ( ) Do not accept (*) would do.
Was this recently disabled? I'm on mobile right now (android) and tried reloading in desktop mode, but to no avail.
I never saw this prompt.
The way you describe it almost seems like a joke, as in "If GDPR were a GUI".
There's a "chat" floating icon in the lower right corner on the desktop web page, and along with that there's a floating checkmark above that. If you click on the checkmark, you can see the "This site uses cookies", "Continue to site", "Policies | Preferences", "Do not sell my personal information" window.
What this tells me is that a tool that follows the "huge swiss army knife" style instead of "do just one thing and do it well", ought to have an extra option that provides Profiles for the most common use cases. Otherwise for most non-expert people (but who end up needing to use the tool anyways for whatever reason), who I'd wager is the majority of users, the tool is close to useless due to the sheer amount of knobs. Just provide some profiles, for the love of $DEITY!
Just for fun, here's a list of things IMHO this one does right, and the wget one does wrong:
* They actually have an option for specifying where the output data goes, and it's right at the top.
* "Open..." buttons. OpenSSL doesn't ask you to type local filesystem paths directly into the thing.
* There don't seem to be any sentinel values in here. Every optional config option has a checkbox or radio button to turn it on, instead of some magic like setting it to -1.
* The spacing is a lot better. I don't see any places where the connection between checkboxes and their text entry fields is ambiguous, if you're willing to assume left-to-right, top-to-bottom associativity.
And here's a few things it still does wrong:
* Text boxes that won't get used should be grayed out.
* The text output and display options make no sense at this stage. Instead, allow the user to configure what they see after running. Output everything, and use various kinds of disclosure widgets to to filter the output.
* Multiple rows of tabs are bad [2]. These should be separate apps, like how LibreOffice Writer and Impress use the same backend but have separate start menu entries.
That wget GUI you are referring to and dragging through the dirt is a GPL Perl script from a lone programmer done in 2007 who did it out of personal motivation [1]. He provides his personal email address and asks for feedback through it. Have you contacted him?
It's fine to shit on proprietary garbage by huge companies which are involving UX experts into their development process such as Reddit or Facebook UI, but what you're doing is not cool.
I think notriddle’s comment is fine. They didn’t criticize the designer of the UI, just the UI itself. Their detailed UI critique helps other people reading the comments improve their UI design skills by prompting them to think how to avoid such criticisms.
That's a funny spoof for a GUI. I don't know what design language was used here, but it's pretty outdated by now.
Windows (for domain admins) has similar tools to OpenSSL. How do you use that, you may ask? Simple: wizards. There's a wizard to create a CA. There's a wizard to create a CSR. There's a wizard to sign said CSR. There are probably wizards to set up custom wizards.
When you turn OpenSSL into a step-by-step process (with the subcommand chosen by the button that spawns the wizard, as well as a separate wizard for the "mini CA") it becomes quite manageable. Just stuff each part into a separate page and filter out any options that might be irrelevant based on earlier choices.
You'd end up with a seven to eight step wizard for most operations and I doubt you'd be as confused. OpenSSL is forty tools in one executable.
Yes, except that the reordering behavior of multi-row tab controls always confuses me, and that there should be a way to “break out” individual tabs to see them side-by-side, maybe similar to an MDI interface.
A team I worked on years ago had a build system with an insane number of options. Someone made a GUI that looked vaguely like this OpenSSL GUI does, only it didn't have a "Build" button, but a textbox that showed you the command line options you had picked (I think it could automatically save to a script as well).
It was such a useful tool. I've endeavored to recreate that a few times in other teams when I encounter a tool with a --help that's more than a page long. Really helps new people figure things out.
I was just wondering if this existed yesterday. LetsEncrypt is out there for real certs. I need a site cert for local development. Why can't I type my hostname and mash one button?
No, I had the same thought. Moreover, a GUI/TUI would actually allow implementing some further usability improvements. And there could be a “save as script” option.
A large part of what makes libsodium simple is that it does very little.
Some of doing little is great. It does not let you erratically mess with your encryption options, it does not let you apply a bad algorithm, and it does not let you use one algorithm for a task it's badly suited for (well, up to a point).
But some of it is just things the library doesn't do. You can't run a PKI with it, you can't deal with industry-standard file types, and your options for interoperability are just none.
It's really good to make those nice focused libraries that people can actually use. But that doesn't remove the need for kitchen-sink packages that will solve every problem under the Sun.
This is true, but a majority of projects are using this kitchen sink library, poorly, for roughly the same 0.2% of it. Not good.
Thankfully, the situation has improved; at least some old stuff has been moved off into a module in 3.x, and a lot of cruft has been cleaned up. But still, it’s hard to not want to pick a library with reduced scope, if you at all can.
I have worked with smallstep and I can't say anything but amazing things. It's a top quality project with clear doc and great UX. I really wish we had many more projects like this. Kudos guys, kudos.
Does this exist? Because I want it. The only thing it needs is a couple extra buttons at the top like "Modern TLS Certificate" and it selects the right options, but then I can tweak it from there.
This better explains how ruthlessly focused UI design needs to be. User Interface design needs to know the person on the other side, what their motives are and what makes them feel like they have superpowers. OpenSSL is a system. A GUI needs to bridge the gap between the system and the user, and it can’t be done in one implementation, because the types of user is super diverse. Makes the whole act of UI design increasingly challenging and fun all at the same time
OpenSSL is an expert tool. And one that should probably be three or more specialized tools instead. Then three+ expert UIs built on them.
Any simpler UIs should probably just consume a stable API of those more specialized tools/libraries. This is kind of happening with the various forks and alternative tooling taking over. But not soon even IMO. Anyway, a girl can dream.
Beautiful and educational. It’s a design activity very similar to building a good cheat sheet or study guide.
From an evolutionary standpoint our intelligence is heavily oriented toward navigation of complex terrain, to locate food sources and avoid danger. So translating this API into a structured layout makes it more suited to our natural learning faculties.
I have been playing around with trying to simplify the CLI-based self-signed CA use case, which started as a Memorial Day Weekend toy project. I have something working for the "new cert" case which replaces the old shell script that manages openssl.cnf files that no longer met our current use case (largely because it didn't support SANs).
My experiment is basically: A config file, which can be overridden by the environment or CLI options, for the common certificate generation arguments. So the simple use case is:
rgca cert new --san users.example.com www.example.com
It can also run pre and post scripts to, say update your serial/index in git, and deploy keys to the server, say you are rekeying every 30 days...
I've finally found some time to play with WireGuard and have been doing so for nearly a month now for about 5 hours a week. Many things were really easy and clear, in contrast to OpenVPN, though it lacks some hooks I'd like to have. For example something like OpenVPN's `client-connect` and `client-disconnect` script triggers. Also it looks like one can't reduce the handshake interval. And the issue with DynDNS where it doesn't reconnect to a new IP if it changes (though there are acceptable workarounds for this).
I'm currently looking at how I can replace my site-to-site OpenVPN setup with it, where the issue is that I don't have physical access to the remote site, so the slightest mistake can end up being a real problem.
With rare exception, good GUIs are good because they intelligently restrict the options available to the user. The default values for 99% of OpenSSL options work for 99% of use cases. A good GUI designer would identify the 1% of options that frequently require nondefault values and expose only those to the user. A great GUI designer would identify more obscure options that might need manual specification depending on how other basic options are set and show those on an as-needed basis.
If the above do not apply, then a GUI is probably not the right interface for your tool, as this facetious mess of a GUI hilariously illustrates.
Heh, I once did the opposite and turned an infrastructure's asset management GUI/API into a CLI tool. It had a backend API which presented some decent typing and its nested structure, so it wasn't beyond impossible, just had to be massaged into a doctopt string.
It was, uh... It had a lot of options. It was immediately obvious that it was beyond useless because any use of the tool started with a search in the documentation, just as I would if I was just calling the API. No time saved and had an excessively small niche.
this highlights the difference: on a commandline it is syntactically easy to add lots of options, whereas the GUI has limits, but the GUI is easier to discover. for the commandline you need to read documentation.
As someone who doesn't use OpenSSL often enough to remember all the options, this actually looks very useful to have (with the exception of the help and list options).
That said, the pixelated tabs and controls combined with an antialiased font look really weird. I suppose it could be called the "fake retro" aesthetic.
This but instead as a "WTF are you trying to do?" wizard that left out options that are very obsolete or entirely a bad idea, would actually be cool. Start with the goal rather than the "how".
> Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.
"Encrypt File" would be a big button on the first screen, which would lead to the most common secure ways to encrypt a file that version of the software knows about, with less-common but still secure methods gated behind an "Advanced" button, and known-insecure methods gated behind a "Danger" button after that, which shows them on a screen which explains that they're known to be insecure and are not recommended for use.
It's well-known that people, in general, refuse to read what's on their screens, so the warnings won't do a single bit of good if someone has the patience to click through all the way to the insecure algorithms. Since most people don't have that kind of patience, it evens out in the end.
That is awesome. I'm glad I don't have to use it as a GUI and that I can have all those options nicely tucked away until I need to look something up that I haven't memorized from frequent usage yet.
All criticism of OpenSSL aside, I would like to see other tools represented in a similar fashion. If nothing else it is more intuitive for me to look at this and understand what is possible than a man page.
To give that idea serious credence would mean being able to parse the inputs and outputs, and make the togglable settings on each.
When it's a simple number, that's not hard. When it's a file, it's a lot harder, since there's a lot of non-file files (fifo's, directories, symlinks, hard symlinks, network locations, mountpoints, etc). And don't forget that you can pipe stuff in anything that looks like a file.
It sounds simple, but for things like ffmpeg or openssl, the possibilities are just stupid complex.
I love how simple this is for newcomers. With this tool we can finally get folks managing their own privacy and stop asking poor developers to implement “same defaults”
Everyone discussing the GUI, and none of them the tons of options that goes into PEM and DER files. For some obscure reason I decided that I needed to go into the hex coding of those, but eventually I just scrapped it and said "F IT! I'm just going to make my own bcos who needs compatibility or compliance anyway!1" (And don't get me started on ASN.1!)
I... kind of like it? Not the fact that using such a GUI would be almost impossible, like the humorous example of an "engineer oriented UI" in the Silicon Valley series https://www.reddit.com/r/SiliconValleyHBO/comments/4nvvnl/pi... which might be confusing for most people.
But rather the fact that all of the complexity the software has is laid bare, so that nobody could mistakenly assume that it's just a small utility that does just one thing. But rather, that it's a system with a large surface area and plenty of things that it attempts to do. Somehow the example also has better discoverability of what's available to use, than reading manpages or help documentation ever would. So I guess, why not? Hide 80% of the GUI under context sensitive menus and options and you'll actually have something usable.
Somehow, if you look at the screenshots, it actually feels more discoverable for the average user than using a CLI tool might be: https://keystore-explorer.org/screenshots.html (especially if you talk about the Java CLI tools in the space)
The problems with GUIs are largely the fact that they don't really map nicely to CLI commands and usually cannot be automated themselves - the ideal software would have a GUI that's optionally available, but would offer you the underlying CLI commands when you're about to do something (implying that the UI would be separate from the logic, being optional). The best example that I can think of this is Zenmap, a GUI for nmap: https://nmap.org/zenmap/
So in the GUI you might pick:
Target: some_ip_address
Profile: Intense scan plus UDP (dropdown)
And get the following output:
nmap -sS -sU -T4 -A -v some_ip_address
Whether you execute the command through the UI or add it to some script, that's up to you.
Some other software that comes to mind:
- Kdenlive: shows you what the encoder command for rendering videos will be
- SourceTree (or other Git GUIs): shows you what commands you're attempting to execute
- MySQL Workbench/pgAdmin: shows you what SQL will be executed
I think that's the perfect approach to having your cake and eating it too.
Both ffmpeg(1) and openssl(1) share that they're meant, or used to be meant, as examples/demos of the underlying APIs. No one was actually supposed to run an actual CA with openssl(1), for example. Both also share that some things are vastly easier using the API than bending over backwards thrice at full moon using the CLI, but because using the API has more friction to it, people generally stick to the CLI (almost) no matter how hard that'll make things.
Oh, and just like you have to know a ton about how media containers, streams and codecs actually work to use the ffmpeg API, you likewise need to be a crypto expert to use the OpenSSL API. Almost the same is true for their CLIs as well, though.
I'm less familiar with ffmpeg, but the openssl(1) command wasn't originally designed to expose the API. It was intended to provide very rudimentary examples for using the API, and perhaps operated as a useful development tool for contributors, but that's it. There were plenty of APIs it never exposed, and plenty API changes it was never updated to accommodate. And IIRC there were some breakages along the way.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
The same is true of ffmepg. The api documentation even links to the source of the bins so you can read the example code. To pick on ffplay, I think it most clearly illustrates this - with the bare minimum rendering context to get video on the screen but clean code continously updated to reflect the api's best practices, and an invaluable resource when I was writing an embedded player for a game.
True, but you use the wrong FFMpeg codec, or transcode an audio track instead of copying it to the output, no one is left dangerously insecure. You just have a bloated MKV :-D
There are plenty of ffmpeg interfaces, though. The most prominent is Handbrake. Of course, I don't think any of them try to expose every single option. The goal for them is almost always to create an interface that works for the 99% and let the 1% deal with the CLI
An FFMPEG GUI in the style of this OpenSSL one would be great if you are familar with the options but don't use the tool enough to remember the exact commands. It'll also let me explore interesting parameters that I can look up in the manual later to see if they apply to my application. Maybe the GUI could even have buttons that will open the manual page to that specific option. With the CLI I'll likely only grab the specific options I need from the manual and not explore as much.
This is just an example of poor GUI design. The author didn't make any attempt to think of user experience and just mechanically converted OpenSSL CLI options into widgets. This is not how one does GUI design [1].
For example, let's take "Input format" switch. Our computers can do billions of calculations per second, cannot they determine file format automatically? And show a warning if the format doesn't match file extension?
Or let's look at checkboxes, determining which information should be displayed: "print serial number" and so on. Cannot a program just display all important information at once without toggling any checkboxes?
Of course, CLI interface is good for using in scripts. But not every CLI program matches that purpose: utilities intended for use in scripts should output data in machine-friendly format like CSV or JSON or TOML or even specially invented CLIML, but not in plain text. Otherwise scripts will break every time they stumble upon a filename with spaces. Sadly, despite decades of evolution, many CLI programs are not machine-friendly yet.
I use openssl maybe once a month or once a year and I cannot remember a single option. I would rather prefer to type "crypttool /some/file.pem" than spend time finding out which options I need to specify.
And obviously if I had to manage a company-wide PKI with its own CA I would definitely prefer a well designed GUI tool.
[1] Please note that I am not a designer. I just learn things by observing other people's work.
What bugs me a little is the idea that you might want a well-designed version of what the OpenSSL CLI offers. Bad idea! You want tools designed to do one thing well, not one tool that offers a thin layer of getopt() over a low-level cryptography API.