There is now a solid Go implementation of `wormhole` (it's my daily wormhole driver). It works on Windows. It just needs a UI.
Since PGP has almost no serious real-world adoption (search your feelings; you know it to be true), it's wide open for replacement. People should use `wormhole` for file transfer in preference to `age`-encrypted files, if the only reason they're encrypting is to get the file safely across the wires.
Totally agree there, but I'll remain skeptical until I actually see that adoption start to happen. Certainly it's not going to until there's a nice GUI. (It's kind of sad, actually. Wormhole has such a nice TUI that would be utterly trivial to wrap in a simple QT interface or something.)
Right? RIGHT? I keep saying: everyone I've ever taught `wormhole` to does the same thing I did when 'lvh showed it to me: immediately and gleefully wormholing everything. It's such a great tool; the good people of the world deserve it.
It kills me that so many UI-type people build new encrypted email systems and nobody works on putting solid UI on cool-kid crypto like `wormhole`. It's such a high-impact project and it's missing exactly the skillset these people are strongest with. I mean that sincerely: as I think is obvious to everyone, crypto people can't do UI to save their lives.
Do programs exist that generate the most basic portable GUI (in Qt for example) from command line application?
Basically what you need is list of parameters, their types, allowed ranges, preferred way to modify and input parameter values (file selection, input box, slider, ...). Then button to run the program.
It’s based on wxWidgets so I assume it’s supported (at least roughly) wherever wxWidgets is supported. However, I’ve only used it to package a few small utilities for friends, and neither myself nor any of them run Linux Desktop, so I can’t be sure.
Since PGP has almost no serious real-world adoption (search your feelings; you know it to be true)
Checks...it's not true. Maybe the original email use case never caught on, but that's not the only one. For example, PGP is a standard way to transfer Visa, MasterCard, or Diner's Club credit card transaction files. We have thousands if not tens of thousands of entities transferring PGP encrypted files every day, and we get new requests for PGP enablement on a regular basis. This is a deeply embedded business process (even embedded in many corporate financial systems like Oracle Financials), and it's not going away any time soon.
Not only should PGP go away for that use case, but it easily could; very few people would need to be convinced to upgrade it to a better format. What's held that back from happening is nobody agreeing on what that better format is; it's the same reason we're only now getting WireGuard after almost 2 decades of IPSEC VPNs.
Not only should PGP go away for that use case, but it easily could
Says someone who has never had to do it.
very few people would need to be convinced to upgrade it to a better format
Only the tens of thousands of current users who I personally have who would see no reason to change something that currently works and is secure. I have, in fact, suggested a number of better solutions over the years.
Hell...it took us 10 years to convince all the third parties that plain FTP was probably a bad idea. And there's still a tiny handful of very, very large companies that still say 'meh' and force us to keep an FTP server around.
Must be nice to not have to deal with real customers.
Is there someone you know with a similar name to mine that you think you're talking to? The kinds of issues you're talking about are my actual full-time job.
Oh, my...don't you know who I am?. Classy. I guess my aversion to being Internet Famous makes me easy to condescend to.
My "actual full-time job" is building and operating security teams for Fortune 1000 sized companies, not startups. These kinds of issues are also what I do every day. I just do it with far more customers, internal stake holders, budget, technical debt, politics, employees, governance, geography, etc., etc. And I actually do those hard things; I don't just say "you should do this...it should be easy".
Consider that just maybe your perspective doesn't represent the totality of the security landscape. Things that are easy when you're consulting to the latest Foo of Bar startup or whatever is spooling out cat videos this week are very, very hard when you're dealing with entrenched, interconnected business processes processing billions of dollars of other peoples money. Just a thought.
I assume the go wormhole implementation you are talking about is https://github.com/psanford/wormhole-william . I've been working on building a mobile interface for it. After that I may look at doing a Windows UI.
The security doesn't, but availability might: the relay is very easy to DoS (not even DDoS!). This is the one thing that I think Thomas has jumped the gun on with his recommendation: the current protocol and infrastructure won't survive a DoS attack, which is tragically likely if magic-wormhole's popularity increases. Brian Warner is aware of this and has written about it.
I noticed the same issue as Joey Hess, except a couple of years later; then when I was giving a magic-wormhole demo, some of the audience members accidentally broke some of my live transfers in various ways.
(Otherwise, I feel just as gleeful as Thomas does. It's an awesome tool and fun to use!)
That's missing the point. $2 of RAM in exchange for security is a good deal. Go ahead and use the command line version yourself, but if you're not going to contribute to a native GUI version then don't be a party pooper about Electron.
Electron's only a problem when there's lock-in of some kind.
I think that people who say this think "yeah, running one Electron app is no problem". The problem comes when everything is Electron and now, like the ocean, you have no memory.
The newest baseline Dell XPS 13 (not even Inspiron) comes with 4 GB of memory by default. The very idea of an extra 8 GB is hilarious because manufacturers haven't kept up with the times (my laptop purchased 9 years ago had 8 GB), and by extension the median consumer's laptop hasn't either. Nobody has an "extra" 8 GB outside of people with the money to just unthinkingly buy the top of the line model or developers who know what they're doing.
We're talking about buying extra memory, not defaults. And while an XPS 13 is trying to be a macbook, on an XPS 15 you just pop open the back cover and shove more memory into it.
Never mind 16GB. There are quite a few 8GB or even 4GB laptops (4GB ones are usually >= 4yr old, but it's not uncommon to keep crappy laptops for that long outside the tech-savvy circle) among my friends and family.
I'm just replying directly to the "I would have bought less" comment, which implies having control over your memory amount. It's not hundreds of dollars when that happens. You can get all sizes of laptop memory for under $4 a gigabyte. And if you've maxed out at 16GB, you're not really at a spot where .3GB is a big burden.
> An electron app will hurt adoption, give the project a bad name and reduce the likelihood of a proper UI to never materialize. Please don't.
As opposed to having nobody use it in the first place.
> 2. How does using electron apps make me more secure than using native apps?
The electron app exists. The native app does not.
You think that ranting against electron is somehow making a native app appear, but the reality is that there are way more js/electron devs than there are qt/gtk/wpf devs, and the choice in most cases is either an electron app or no app.
> 1. I don’t know what RAM you’re buying, but mine costs way more than that. It’s especially bad if you’re using AMD.
DDR4 at 3200MHz, plenty to make Ryzen happy, is available at $4 per GB on Amazon. That gets you half a gig for $2. But that's not even our max budget. If we use oefrha's estimate of 300MB of RAM eaten by Electron, then we have a budget of $6.80 per GB. That gets you very nice RAM.
Those issues are only relevant to applications that display arbitrary HTML and already have XSS issues. Avoiding XSS is doable; with most web frameworks you're protected from XSS by default and have to specifically turn off the safeties to get XSS.
Since PGP has almost no serious real-world adoption (search your feelings; you know it to be true), it's wide open for replacement. People should use `wormhole` for file transfer in preference to `age`-encrypted files, if the only reason they're encrypting is to get the file safely across the wires.