If OpenSSL were a GUI
smallstep.com
smallstep.com
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.
Before acme, someone had to create a CSR manually, often using OpenSSL.
Also, should therw be a separate tool to debug and inspect ssl certs and connection? How many individual tools should there be?
Also using Kleopatra for GPG keys.
I have bad news for you: LetsEncrypt and ACME are almost 10 years old. Like the rest of us, you're getting old.
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.
Arguably, OpenSSL is a collection of lots of individual tools. Each of the tabs in the "GUI" is an individual command with its own man-page, etc.
Each command still brings a lot of of options and therefore complexity with it, but that's because the domain is complex.
Certbot has been around for 7 years at this point, and is the same age as VS code. Frankly at this stage there's very little excise to not use it.
Actually, to understand how certs, TLS and the web PKI system works in detail, I do want exactly that.
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.
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
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.
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?
E.g. something like "check the OCSP for this certificate". This should be a simple command.
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.
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.
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.
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.
That nobody uses outside of games.
And Fusion 360 basically had to write their own entire GUI engine to do all the stuff they wanted.
Infuriatingly, Fusion 360 doesn't provide a Linux version which should be stupidly easy to do since they wrote their own GUI.
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.
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.
[1]: https://books.google.com/books?id=7wEAAAAAMBAJ&pg=PT89&lpg=P...
[2]: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86...
[3]: https://youtu.be/cVusw4JNK0s (1999)
[4]: https://youtu.be/323fmUgwMyI (2022)
[5]: https://damassets.autodesk.net/content/dam/autodesk/www/auto...
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).
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.
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?
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.
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 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.
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'.
OpenSSL can have this kind of UI. Its just a matter of understanding user requirements.
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.
However, it's good that it's there, so you can add it if the lower layers aren't providing.
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.
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.
"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.
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.
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.
[1]: https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encry...
[2]: https://www.nytimes.com/2013/09/06/us/nsa-foils-much-interne...
[3]: https://finance.yahoo.com/news/juniper-breach-mystery-starts...
That is too much complexity for a single security-critical program.
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.
You mean like this? https://iangetz.com/projects/ffmpeg-builder/
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.
https://gist.github.com/tayvano/6e2d456a9897f55025e25035478a...
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:
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 think they call that VLC
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.
No comment on Firefox.
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.
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.
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.
(examples are here: "http://bitsavers.org/pdf/apple/mac/a_ux/aux_2.0/030-0759-A_A...", "chmod" page 89, "grep" page 152, "ls" page 157, "wc" page 164, ...)
Then give it a pat from me and my 650.
I haven't tried it yet, IIUC it can generate GUIs for some Python CLI tools
Quick and dirty GUIs
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>.
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.
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.
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.)
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).
With the CLI at least you can cut and paste the options from somewhere else.
Set-and-forget still requires you to know what to set.
Some common functionality in tab ABC, and then opt-in for Headache Mode if necessary.
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 :(.
Thank you for your time!
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?
I think that good UIs increase discoverability, add guardrails, and make operations easier for people with different levels of familiarity.
Neither the linked GUI nor the OpenSSL command line tool make the grade imo.
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.
In theory it could be such a demonstration, but openssl's command line interface is... pretty bad, too.
I can’t wait until they release it (oh wait, they did, decades ago; now we just have — whatever — the Mac is now).
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.
[1]: https://news.ycombinator.com/item?id=30797575
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.
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.
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.
One that runs it, not so much.
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.
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.
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.
But that doesn't mean the kitchen sink one is useless.
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.
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.
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
Interested in feedback.
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.
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.
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.
Within a few secs i had somewhat not bad awarness of how big this thing can be
I would want to see more
If x were a gui
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.
I can't remember that I managed to do it properly, but as I asked on IRC, I was warned that there was a lot of probability of doing it wrong.
I guess I will keep trusting 7zip (who had a crypto flaw at some point).
https://www.nngroup.com/articles/progressive-disclosure/
> 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.
Like others mentioned FFMPEG is even complex :-)
It would perhaps take a cli program as its input, and outputs a gui version of the input program?
I know this is a bad idea!
But still, the gui in the article looks kinda cool.
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.
wait maybe there is one?
edit: no there isn't
Highlight tabs that had values set.
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.
For an example of a good GUI in this space, see KeyStore Explorer: https://keystore-explorer.org/
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)
nmap -sS -sU -T4 -A -v some_ip_address
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
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.
They expose a C API as a Bash API. There is just no reason not to use the higher level one.
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.
You should determine first what options are independent of other options, and which options aren't.
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.