[HN Gopher] If OpenSSL were a GUI
___________________________________________________________________
If OpenSSL were a GUI
Author : soheilpro
Score : 414 points
Date : 2022-06-10 18:21 UTC (4 hours ago)
(HTM) web link (smallstep.com)
(TXT) w3m dump (smallstep.com)
| jandrusk wrote:
| 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.
| layer8 wrote:
| 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.
| [deleted]
| agumonkey wrote:
| you re giving me a second wave of ideas regarding UX
| behnamoh wrote:
| 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.)
| ocdtrekkie wrote:
| 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.
| dmart wrote:
| 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).
| jstimpfle wrote:
| This isn't even a GUI. It's only an image.
| imwillofficial wrote:
| It's a joke
| jstimpfle wrote:
| You missed my point.
| jstimpfle wrote:
| Whoever downvoted me, let me expand: Since this is not a
| GUI, but only an image, maybe a GUI is not necessary?
| tuckerpo wrote:
| Yeah, I'd prefer a GUI in this instance over going back and
| forth to the man page and trying to remember all of the
| options and all of their formats.
| bombcar wrote:
| 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.
| solar-ice wrote:
| 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.
| 0daystock wrote:
| Google Cloud does this also - shows the equivalent gcloud
| command line to execute APIs available through the UI
| console.
| imwillofficial wrote:
| This is awesome
| fenesiistvan wrote:
| I dont't konwn, if you realized that this user interface is
| just one of the many tabs
| Asooka wrote:
| The best design for me would be a CLI with a GUI on top and a
| "show command" button for when I find the right options to
| use.
| BeFlatXIII wrote:
| 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.
| toastedwedge wrote:
| 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.
| xoa wrote:
| 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 :(.
| amelius wrote:
| We need a CLI equivalent for the web, and for mobile.
| commandlinefan wrote:
| > demonstrates were CLI excels and where GUI's fall short
|
| In theory it could be such a demonstration, but openssl's
| command line interface is... pretty bad, too.
| murermader wrote:
| 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?
| codedokode wrote:
| 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.
| peddling-brink wrote:
| When your GUI is a man page with checkboxes, it's easy to say
| that it falls short.
|
| 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.
| jchw wrote:
| 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.
| wruza wrote:
| 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`.
| linsomniac wrote:
| 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...
|
| Interested in feedback.
|
| https://github.com/linsomniac/rgca
| jchw wrote:
| I would _love_ to see the equivalent "If libsodium were a GUI."
| marcosdumay wrote:
| 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.
| jchw wrote:
| 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.
| marcosdumay wrote:
| You should pick a library with reduced scope. And not feel
| any bad about it.
|
| But that doesn't mean the kitchen sink one is useless.
| jchw wrote:
| Yeah, I think we're in agreement.
| matthewaveryusa wrote:
| This is where the builder pattern works really well. rclone is a
| good example of a cli that uses a builder for config, and
| turbotax for guis.
| chaps wrote:
| 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.
| em-bee wrote:
| 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.
| riazrizvi wrote:
| 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.
| kringo wrote:
| A great way to visualize the complexity of OpenSSL
|
| Like others mentioned FFMPEG is even complex :-)
| colordrops wrote:
| 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"
| ape4 wrote:
| As we know too many options / complexity is bad for reliable
| cryptography. Perhaps some options could be removed or
| depreciated.
| notriddle wrote:
| I remember when I wrote a pretty harsh rant about a wget GUI [1].
| This thing is much, much better.
|
| [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.
|
| [2]: https://www.nngroup.com/articles/tabs-used-right/
| phil294 wrote:
| 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.
|
| [1] http://www.martin-achern.de/wgetgui
| mseepgood wrote:
| Why would it be implemented for Mac OS 9?
| jandrese wrote:
| Because it would have been implemented in 1999 and then left to
| rot for decades, just like the CLI interface.
| sph wrote:
| It would probably be some old Tcl/Tk GUI module written in
| 1999 that a single madman has maintained until today.
| greyhair wrote:
| 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.
| tenebrisalietum wrote:
| This is what you get when you have something that's entirely in
| the application layer when part of it should be in lower
| layers. Cf. HTTP3/QUIC
|
| However, it's good that it's there, so you can add it if the
| lower layers aren't providing.
| kortex wrote:
| 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.
| dekhn wrote:
| 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.
| dataflow wrote:
| > 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.
| dekhn wrote:
| 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?
| bsder wrote:
| What you probably like most are the "Radial Menus". Which are a
| damn good GUI paradigm.
|
| 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_.
| Ruq wrote:
| Krita makes use of radial menus as an option.
| dekhn wrote:
| IIRC Fusion 360 has radial menus (https://help.autodesk.com/v
| iew/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.
| meue wrote:
| 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.
|
| [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/ww
| w/auto...
| [deleted]
| AdamH12113 wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| ikiris wrote:
| > imagine the same gui for ffmpeg...
|
| I think they call that VLC
| jyrkesh wrote:
| > ffmpeg
|
| 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.
| fugalfervor wrote:
| I have seen many tutorials using CloudFlare's `cfssl` as an
| alternative.
| ajsnigrutin wrote:
| That is just a small subset of ffmpeg commands, here's the
| full list:
|
| https://gist.github.com/tayvano/6e2d456a9897f55025e25035478
| a...
|
| 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:
|
| https://hohnstaedt.de/xca/
| AdamH12113 wrote:
| 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.
|
| No comment on Firefox.
| Beltalowda wrote:
| > 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.
| AdamH12113 wrote:
| 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...
| qwertox wrote:
| I was hoping that it was interactive, showing all tabs and all
| options. But I like what I'm seeing there.
| [deleted]
| tptacek wrote:
| 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.
| tambourine_man wrote:
| Checkboxes are not 100% platinum accurate, but great job all in
| all.
| throw7 wrote:
| Do ImageMagick! ;)
| em-bee wrote:
| imagemagick has a GUI: display
| MontyCarloHall wrote:
| 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.
| throwaway892238 wrote:
| 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.
| commandlinefan wrote:
| I was really hoping those tabs would be clickable...
| tigroferoce wrote:
| 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.
| fizzbuzz-rs wrote:
| Practically all GUI software would look too complicated if you
| have to put everything on one screen. Compare tar and your
| favorite archive tool GUI.
| corrral wrote:
| 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".
| msla wrote:
| The UX design concept for that is probably "progressive
| disclosure":
|
| 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.
| mirekrusin wrote:
| 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.
| ngetchell wrote:
| PowerShell has a Show-Command cmdlet that dynamically generates
| a GUI based on the cmdlet parameters.
|
| Quick and dirty GUIs
|
| https://ngetchell.com/poor-mans-gui/
| aozgaa wrote:
| Amazing! Does anyone know of a comparable toolkit for quick
| UI's (gui or tui) in the linux/bash ecosystem?
| usrn wrote:
| 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.
| behnamoh wrote:
| I think it also helps that PowerShell treats everything
| as objects and can pass them in pipes.
| wheybags wrote:
| There's zenity, but I think it's not as featureful (I may
| be wrong there)
| znpy wrote:
| Uhm... would that work using powershell in gnu/linux?
| debugnik wrote:
| 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.
| idle_zealot wrote:
| > 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.
| behnamoh wrote:
| Sometimes it is tho. Imagine if pilots had to use something
| akin to CLI instead of numerous buttons, handles, clutches,
| etc.
| sprash wrote:
| This is exactly what was done on A/UX (an obscure Apple Unix
| before NEXT). When you open CLI applications in Finder a GUI
| like this appears.
|
| (examples are here: "http://bitsavers.org/pdf/apple/mac/a_ux/au
| x_2.0/030-0759-A_A...", "chmod" page 89, "grep" page 152, "ls"
| page 157, "wc" page 164, ...)
| im_down_w_otp wrote:
| 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.
| gattilorenz wrote:
| Bring it to its senses by asking on how many non-Quadra
| Macs A/UX works. Hell, it did not even run on _all_
| Quadras...
|
| Then give it a pat from me and my 650.
| balaji1 wrote:
| Posted on HN: https://github.com/chriskiehl/Gooey
|
| I haven't tried it yet, IIUC it can generate GUIs for some
| Python CLI tools
| jayd16 wrote:
| 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.
| puzzlingcaptcha wrote:
| 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.
|
| https://github.com/chriskiehl/Gooey
| jvolkman wrote:
| 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.
| jonathaneunice wrote:
| 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.
| dpcx wrote:
| I really wish AWS had the ability to generate this for any
| piece of my infrastructure. Either the `aws` command _or_ the
| relevant CFN script.
| phtrivier wrote:
| Is there a reasonable subset of openssl / TLS / whatever that
| covers the use case people should really start with in 2022 ? Can
| it get a branding ?
| gspr wrote:
| I believe things look a lot better if you stick to TLS 1.3
| only, and drop support for almost all formats for certificates.
| krallja wrote:
| I think that's the intention of LibreSSL.
| amelius wrote:
| A badly designed GUI.
|
| You should determine first what options are independent of other
| options, and which options aren't.
| ykl wrote:
| I think that's the whole joke; OpenSSL's various options are so
| extensive and so Byzantine that this is what you end up with.
| codedokode wrote:
| 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.
| mmalone wrote:
| It's a critique of OpenSSL, which also makes no attempt to
| think of user experience.
| kebman wrote:
| 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!)
| gsich wrote:
| This looks actually good.
| qwertox wrote:
| 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.
| tptacek wrote:
| WireGuard is much, much better than OpenVPN, and almost nobody
| should still be deploying OpenVPN, but this is about OpenSSL,
| not OpenVPN.
| gpm wrote:
| This reminds me of this project which automatically converts rust
| programs using the most popular (in rust) arg parsing library to
| gui's
|
| https://github.com/MichalGniadek/klask
| Iv wrote:
| Wow, such a good and useful idea!
| akpa1 wrote:
| This also exists for Python! It's called Gooey, and mimics the
| argparse standard library module.
|
| https://github.com/chriskiehl/Gooey
| axilmar wrote:
| This is not about GUIs, it's about OpenSSL. I.e. how complex it
| is.
| RcouF1uZ4gsC wrote:
| As an aside, does anyone else miss the tabbed interfaces of the
| late 1990's?
| layer8 wrote:
| 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.
| em-bee wrote:
| with so many tabs, i'd put them in a column down the left
| side
| werdnapk wrote:
| Needs a "wizard" interface. :)
| em-bee wrote:
| try this one:
|
| https://www.reddit.com/r/photoshopbattles/comments/9w663a/ps...
| equivocates wrote:
| Let me introduce you to a little app called FFMPEG
| digitallyfree wrote:
| 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.
| formerly_proven wrote:
| 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.
| marcosdumay wrote:
| They are designed to expose the API, not as an example.
|
| They expose a C API as a Bash API. There is just no reason
| not to use the higher level one.
| wahern wrote:
| 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.
| billyhoffman wrote:
| 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
| em-bee wrote:
| and there are dozens of GUIs for it.
| usrn wrote:
| And most look pretty much like that.
| apocalyptic0n3 wrote:
| 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
| throwaway0x7E6 wrote:
| I unironically love this
| bbkane wrote:
| Is it bad that I actually want this?
| layer8 wrote:
| 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.
| raisedbyninjas wrote:
| 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?
| marcosdumay wrote:
| I want a version of this that spills the command at the end.
|
| One that runs it, not so much.
| banana_giraffe wrote:
| 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.
| charonn0 wrote:
| I would use this if it existed.
| tptacek wrote:
| 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.
| xwdv wrote:
| Need certificate policy options.
|
| Highlight tabs that had values set.
| johnklos wrote:
| 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.
| fein wrote:
| 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".
___________________________________________________________________
(page generated 2022-06-10 23:00 UTC)