From Markdown to remote code execution in Atom | Hacker News Reader

From Markdown to remote code execution in Atom

statuscode.ch

234 pointsxh3n1145 comments

As soon as I saw the title I suspected the exploit was probably markdown related, as I had fixed pretty much the exact same issues in VS Code. Two things to keep in mind when developing electron apps:

- The potential impact of an XSS or other security exploits is much higher. You can limit the impact of most of these with additional layers of security, such as running untrusted html in isolated environments with node integration disabled. However, also remember that...

- Many security features are opt-in. Content security policies (CSP) are a good example. Pages without a CPS default to allowing anything, which sort of makes sense in browser world for backwards compatibility, but is not a good idea for desktop apps.

> As soon as I saw the title I suspected the exploit was probably markdown related

The title literally says "from Markdown to remote code execution" what else were you expecting?!

The title was changed after the original post.

Yes, thank you. This was originally posted as: "An XSS in Atom Editor That Turned into RCE". XSS + Electron instantly made me think markdown

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser.

Not only will this be more secure, it'll also be 10s or 100s of times more performant.

I understand the sentiment and dislike laggy UIs, but browsers have been running millions of apps securely on billions of computers for ages. No browser exploit has led to worldwide data compromise. In fact, being able to run untrusted code at this scale represents the pinnacle of security engineering feats.

There have also been plenty of exploits in applications written entirely with native code.

Whilst there haven't been that many data breaches, I'd argue that's because the browser is operating at the edges of your architecture, not in the centre, where the data lies.

However, to say that browsers are secure is pure nonsense. Browsers get exploited all of the time, I'd argue that this is not as big of an issue as it could be because browser vendors respond to new vulnerabilities very quickly. WebGL, for instance, is still a massive mess in terms of security.

I guess you don’t remember internet explorer.

It seems to me that the one of the challenges in reaching that pinnacle was adequately quarantining browser-hosted code from local resources and capabilities. But frameworks like Electron are designed to expose the latter to the former, otherwise they’d just be WebKit in a window.

Browsers can barely open a simple web page without getting owned. They're probably the number one infection vector nowadays...

This has lead to some pretty bad hacks. I'm not sure what more you could want really, a vulnerability where people can be punched in the face over the internet?

> a vulnerability where people can be punched in the face over the internet?

That sounds like a mild form of swatting, which is already a thing.

Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.

Cross-platform GUI development in general is a dumb idea. The user chose a specific platform and expect applications to follow that platforms UX guidelines. Building a cross-platform app is basically saying you don't give a fuck about your customers. It's an insult to your users.

So you're saying software OEMs need to pick one of Windows or MacOS and not support any other platforms?

No, you create a proper abstraction layer that maps to native plaform elements.

For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on.

Yes, it takes some initial effort, but it only needs to be done once.

That's easy to say for a file picker on desktop OSs, but what happens when you need to layout a page on all 3 desktop plus Android and iOS?

Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc...

Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept of "files" like iOS or up to recently Android (at least in what is normally exposed to the user)

Roll in various versions of each OS and you are up to needing 10+ ways of doing most things. How are you supposed to create anything even remotely complicated?

I agree; if you build a system that completely covers specifying layouts for all widget needs and a DSL that handles wiring views into models, for all operating systems and device formfactors, you will have invented HTML, CSS, and JavaScript, with the DOM api and a browser as the default interface.

Not at all, because HTML, CSS and JavaScript are a poor man's UI with the lowest common denominator of OS features.

"lowest common denominator" is kind of a feature, when it comes to something used on a ton of different platforms. The rest can be built up out of those. I'm not saying that html et. al are amazing, just that I am doubtful something could be built that spans such a large vector space, so to speak, so expressively, without being subject to the same complaints.

> lowest common denominator of OS features

Not sure I agree here. There are a great many browser features (e.g. web speech api for recognition and tts, webrtc, etc) that are just not lowest common denominator. Even if we stick with UI only, features like cross platform vector graphics are not trivial. Of course some libs like qt abstract it, but you're back to your same complaint except it's qml, css, and js (or often times worse, c++ if using widgets)

How do you think we used to create portable software across 8 bit and 16 bit platforms?

Most of it actually written in Assembly.

Code is a different beast than UI.

Magnitudes easier to shim and support multiple architectures.

Still doable when user experience is more valuable then developer convinience.

It is all about design a good application architecture from the get go.

I'd love to be shown an example, because I honestly don't believe it is doable, let alone doable easier than just making several different applications.

Non UI code lives in a static/shared lib that gets called from UI code. The non-UI code shouldn’t be coupled to a UI at all, instead reporting progress/completion via callbacks or other notification mechanisms.

If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.

That's a valid architecture, but it's not a cross platform UI library that uses fully native looking UI on every platform which is what I'm skeptical of working.

I don't think that fully native-looking UI is a very important thing. Not all of the software has a fully native UI on my computer, and it doesn't matter at all.

I completely agree, but the conversation above was speaking to native UIs being a benefit, and there being alternatives that allow you to "write once run anywhere" with native UIs (which I disagree that this even exists in any usable form)

I'm late, but I think wxWidgets tried this. It was OK, I wrote some stuff with it, but mainly targeted Linux. There were definitely some differences in widgets between platforms, but it looked pretty good for not much effort.

Transmission comes to mind. It as a gtk, osx and Qt GUI

Desktop and laptop systems tend to be in portrait orientation; phones and tablets tend to be in portrait. So you already have to either make two layout styles or accept a mediocre general solution.

Cursors and styluses are accurate, but fingers are not. So, if you make buttons sized for fingers, they feel awkwardly large (takes large hand movements to change between UI components, and the spacing means more scrolling or pages of UI), but if you size them for cursors/styluses, they are frustratingly small targets for touchscreens.

You can probably assume that most devices in portrait orientation are that way so they can be held in one hand leaving the other free to work a touchscreen, so you only need to handle three of the four combinations for a comfortable user experience in those regards.

However, there's more to it than that. Desktop users often run apps windowed, while phones tend to omit that option entirely. Mac puts the menu bar at the screen edge regardless of the window size/position, but other desktop/laptop OSs usually put the menu bar within the window border. You can remove the menu bar entirely and draw a hamburger button into your UI, but desktop users have the expectation of a menu bar and the change in convention will make the app feel like an outsider.

A desktop/laptop user will never try a long press and don't have a menu button, both of which have been used to hide extra functionality on phones, but they often do have a keyboard, and there is a massive list of keyboard shortcuts that they will automatically use. Desktop UIs have a logical tab order and that selection can be moved with the arrow keys. Cut, copy, and paste function as expected. On windows, F2 almost always means "rename selected item", F1 for help, alt-enter to toggle full screen, and so on. What about the multitude of multi-finger phone/tablet gestures? You have two very different modes on input, and users' muscle memory expects your app to fully support whichever one they are using. As an anecdote, I tried writing something in an Electron app's text box, then went for ctrl-left to jump back a word, but instead it caused a page navigation and lost the entire message I was typing. That was a frustrating "this app is an outsider on desktop" experience to me.

Your decision is effectively mediocre everywhere or customized to fit the conventions for each platform.

I'm really going to have to ask for an example of this. Other than SWT I've not seen it done well.

Office, Photoshop.

Office isn't a good example: it used to be the case (may have changed) that WinWord and MacWord were entirely separate codebases.

https://books.google.co.uk/books?id=vPvhzDqZlaAC&pg=PA174&lp... (Spolsky)

Not anymore.

See the Office related talks at CppCon 2015 about how to write portable code using what Microsoft calls the hamburger model, as part of their migration to a common codebase.

Basic a shim layer for low level OS APIs, the middle layer with the majority of code and another shim layer for UI APIs.

Office is hardly the same on multiple platforms. There may be shared code, but from UI and function-based perspectives there are big differences.

Which is exactly my point, the application architecture has to be done in proper modular layers to separate UI specific code that makes use of the UI elements that provide a good UX, from the common code.

Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.

You misunderstand. Even forgetting the UI, the Office programs are different between platforms. One know this, because functionality differs between platforms.

Two very mature and high revenue products.

Sure, but once upon a time developed from scratch, always supported PC, Mac and some UNIX variations, and the Web wasn't even a thing.

Web browsers like the one used by Electron do this as well. The styles of buttons, inputs, etc. vary from platform to platform. They can be overridden, of course, but that’s true of any native GUI framework as well.

Yes, it takes some initial effort, but it only needs to be done once.

It needs to be redone for each platform every few years as apis and visual styles change. Cross platform libraries are notoriously hard and usually end up in the uncanny valley (qt, swing etc).

Platform vendors of course any devs to buy into just one platform, they want and need the lock-in. Using web UI is a way to sidestep that.

No, I suggest they build an native app for each platform.

I'll venture a guess, most devs, most applications, do not exist to give their users delightfully crafted UI and UX with handmade animations.

Most applications are really crude in their design, and do not target large international hip demographics.

As a user of those apps, that’s a clear indication they are probably shit.

If you didn’t even take the effort to get your interface with your user (read: customer) right, how lazy did you get with the parts of the app I can’t see ?

> The user chose a specific platform and expect applications to follow that platforms UX guidelines.

1) Most users don't actually give a crap about "UX guidelines". I promise.

2) "UX guidelines" are, in my opinion, why our user interfaces continue to suck.

...or it's saying you have limited resources and want to maximize what you do with them.

The UI of your app is the one highly visible point where 99,999% of the interaction with your customers takes place. If you can't be bothered to have a good UI, how shit is the stuff I can't see as a user ?

A bad UI is a huge smell. In my experience there is a 1:1 relationship between the quality of the UI and the quality of the software as a whole.

Was it ever really hard to make cross postform applications that look identical on all platforms? If application looks identical on every platform is it really cross platform?

Why? Qt/swing/gtk apps tend to look like shit and are horrible to try and code

> Qt/swing/gtk apps tend to look like shit

You couldn't be further from the truth. Have you seen the Blizzard app (Qt) [0]? The JetBrains Toolbox app(Qt) [1]?

Also, here's a small app I wrote in kotlin and swing for my GF who wanted to download music from youtube without installing crapware downloaders [2]. You'll notice it has a custom window frame, support for drag and drop, and fully customized table and buttons. I spent about 5 hours styling the UI, and half a weekend writing the entire app.

Yes, I agree, dowloading music from youtube is immoral and illegal, but I'm showcasing the UI so please ignore the underlying purpose of the app.

[0] http://l3.yimg.com/ny/api/res/1.2/v.xvnI7eUsLskyHopY6Kkg--/Y...

[1] https://www.jetbrains.com/help/img/idea/2017.2/rm_py_toolbox...

[2] https://imgur.com/J29HJJk

The Jetbrains toolbox UI (and your downloader) do very little. Blizzard's app does a great deal more but is a terrible, sluggish, battery-hogging mess, which also includes web UI elements of some sort. Even Blizzard knows this which is why the app has a setting to hide its windows after launching a game. It doesn't feel like an example of a quality Qt app at all, if such a thing exists.

> The Jetbrains toolbox UI (and your downloader) do very little.

That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs.

Not to mention the irony of complaining about performance, when the promoted alternative is electron...

Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion. The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

> Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion

Well, it wasn't about being "better", it was about not looking like shit.

> The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

Well, Visual Studio Code used to drain battery life for blinking the cursor in the background. But again, it was never about performance. My original argument was that newer 'native' applications written using Qt or swing can look just as good as web based UIs

Your argument was that Qt and Swing apps looking like shit 'could not be further than the truth'. Your counter-examples are a pair of apps that do next to nothing and a really bad app.

My argument is that it takes a few hours to make a look and feel for swing that mimics the appearance of modern electron apps. Also that Qt has plenty of styling power. Blizzard's app is a "really bad app" just because you have a personal problem against it. It works pretty well on my PC (0.5% CPU and 130Mb ram) and I think it looks pretty nice.

Lots of people dislike the Blizzard app but if you like the Blizzard app or spent 5 hours beating a single Swing frame into looking like a web app with questionable typography, we probably have very different (subjective) notions of what a decent-looking app is.

What you did say is that Qt or Swing apps looking bad cannot be further from the truth. If that were the case, you should be able to rattle off dozens of beloved, beautiful, complex Qt or Swing apps. Most cross-platform UIs (including those based on Electron) look and behaves poopily. The few that don't are the result of exceptional effort and focus.

It looks like you're wasting your time arguing with a person who has not developed an appreciation for native, consistent, desktop applications.

Consistent? Where? Windows changes its style with each version. Macs may be more consistent, but they're the exception and I never owned a mac. Linux is a rainbow of diversity.

Unless someone puts in the extra effort to style the application, nothing will look consistent cross platform.

And if you want "native, consistent, desktop applications" (for the current platform), Qt has that out of the box and Swing had a native look and feel that looked pretty consistent on Windows 7 at least.

> questionable typography

To be fair, I did change it a bit later to use Open Sans .

> Yes, I agree, dowloading music from youtube is immoral and illegal, ...

It is neither! Enjoy your music :)

Time to pick up some UI/UX skills.

Would something along the lines of "React QT" be possible? React Native for desktop!

> I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser.

Great idea! Now show me an application that can be extended in the same way Atom can, that didn't have 30-40 development behind it...

30-40 whats? Years? Developer-years?

30-40 years of development. I was alluding to VIM or emacs, and even they still suck immensely on the GUI front. The emacs TUI and GUI is embarrassing for something that had access to async features for so long, and VIM frontends are only progressing in the immense speed their are because of Neovim and the clean separation they made of the logic and the UI.

Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!

If you consider web to be "high quality UI paradigm", then you might be seriously interested in learning other UI tools. You know like literary any other UI library on Earth where vertical centering of one element in another is just a basic functionality not a task that requires a hack.

You need some Flex in your life: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Or use one of the systems that is already well-established. Here's just a few.

WxWidgets [0], bindings in: Python, Perl, Ruby, Lua, C++, C#, and others.

Qt [1], bindings in: JS, Python, C++, and others. Also has QML to make things easier.

Tk [2], bindings in just about everything. Included in most Python distributions.

Kivy [3], Python only.

Java/FX [4] Java and other JVM languages.

If your main problem is the duplication effort between the web and an application: Qt is the simple path. Qt includes WebKit. Everything Electron can do, Qt can do, but faster and smaller.

[0] http://wxwidgets.org/

[1] https://www.qt.io/

[2] https://www.tcl.tk/

[3] https://kivy.org/#home

[4] https://docs.oracle.com/javafx/2/overview/jfxpub-overview.ht...

I wish there was a dead-simple, you-cannot-get-it-wrong, step-by-step, nothing-left-out, no-knowledge-assumed, all-in-one-document, not-spread-out-over-various-pages, tutorial/checklist on how to ensure your Electron app is as secure as possible.

It shits me that it is a research task with all the attendant uncertainty about whether or not I did in fact make it secure.

I do appreciate that security is complex and even such a document would not guarantee security, or that you had not somehow created your own security hole, but I just want to do the very best possible effort at security and currently that is too hard with Electron.

UPDATE: this post has led me to attempt to redesign my application to not use Electron. I just can't afford some misconfiguration or coding error leading to user machines being cracked.

Security is never easy. It is always a battle. Maybe AI is the answer

AI is decidedly not the answer. Formal verification is the answer, and tooling around it.

My impression is that making everything formally verified is a lot of work and it would be very hard to make formally verified code as easy to write as non-verified code.

The central dilemma is that there are myriad ways to do it wrong for every one way to do it correctly.

Electron makes things worse: it is not secure. Electron has many security vulnerabilities. The latest version is still based on old Chromium (58 & 59) so it inherits many of the security vulnerabilities published in Chromium 60, 61 and 62

See here for the security issues published in Chrome stable releases in those versions:

https://chromereleases.googleblog.com/2017/07/stable-channel... https://chromereleases.googleblog.com/2017/09/stable-channel... https://chromereleases.googleblog.com/2017/10/stable-channel...

As long as you don't load untrusted code or content... I guess many of the issues are moot if untrusted code can't get access to javascript and is only exposed to HTML parser (DOMParser).

The way I'm using electron for my pet projects is only passing untrusted HTML to DOMParser and then sanitizing with strict whitelist of attributes/html elements. Only then will any HTML code get interpreted by the browser engine.

Feels somewhat safe, but I haven't read the bug list. :)

Image format decoding and HTTP/TLS/request processing layer bugs may be other source of issues in any case. But hopefully that runs in some restricted environment.

"As long as you don't load untrusted code or content..."

Because end users are soooo good at that?

They're referring to the application developer.

If the developer uses Electron only to open the application's own html files and doesn't render user-provided HTML anywhere, then there won't be any XSS vulnerabilities.

Whilst it's very hard to write a secure C application because writing C is hard, it seems it's very hard to write a secure application in javascript because javascript is too easy. Maybe we should stop blaming language complexity and start blaming the complexity (or lack thereof) of the designs that fail us?

Neither of those is about "hard" versus "easy". C pre-dates a modern understanding of security boundaries and tries a little bit too hard to be "close to the machine" (so long as the machine looks a lot like a PDP-11). Javascript-the-language is not the problem, but having the whole browser infrastructure present in order to render a document is the problem here in Electron.

The challenge in language design is to erect the right number of boundaries and barriers, in the right places. Too many, and you get people complaining that they can't write Rust because of the borrow checker. Too few, and you get people vaporising multi-million-dollar Etherum contracts by mistake.

I don't think you understand. I am not blaming languages, or indeed making a statement about how hard or simple they are to use. I'm just trying to point out that application design is hard - and in fact I do consider the fact that a text editor has pulled in the whole browser infrastructure to render a document a design error.

> having the whole browser infrastructure present in order to render a document

This is disingenuous; the whole browser infrastructure is present to run an application. This shouldn't be surprising because that is exactly what a browser is: an application execution environment.

C isn't hard. C is easy, in fact. This is the main impetus behind its popularity: people liked it, in part because it was easy. Security is hard in c, in part because c tries to make things easy for the developer at the detriment if security. Javascript is in the exact same posistion. Why is javascript popular? Because its easy. Why is javascript easy? Because none of its features are focused on security.

C is not easy, it looks easy, that is the trap or a plain siren song.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

https://blog.regehr.org/archives/1393

This is why I don't run any Electron apps on my computers at all, ever.

That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron.

I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's been around for ages and continually sees updates. Usually people who see the Qt light are pretty satisfied. It can also be used from a wide variety of languages, in case you're not into writing C++.

I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers who otherwise wouldn't have had any clue how to make desktop/native applications. However, do I really want to be running unsandboxed xss==>rce code written by clueless devs? No, no I do not. So, in the end, refusing to run Electron apps turns out to be a somewhat reasonable security posture.

welcome to the history loop!

it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs.

I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries.

then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images!

good luck with that

As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.

The solution, is to bump the version in the dockerfile, rebuild, and deploy.

This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.

Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.

Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.

when it works for containers, it would have worked just the same for shared lib, but with one less step.

containers: update the lib, rebuild.

sane software: update the lib.

now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.

container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.

sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.

Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.

I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good

with shared libraries containers are an option just fine

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.

> it is a very known fact for all unix grey beards ...

It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.

Go packaging philosophy goes against that. but go is also released in a good enough state and things are being done right on the fly.

> a very known fact for all unix grey beards

The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.

It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code...

Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.

And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).

The same Rob Pike also stated that UNIX is past its due date.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream.

There really is no competition and any claim to the contrary would need to offer more than a cross platform desktop app.

It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.

Sure, you can hate a programming language. It changes absolutely nothing, except your potential revenue streams.

It's like saying "I loathe Linux!!" and knowing nothing about it; sure, but in this industry, you're going to have a tough time :)

To be fair, JavaScript hardly deserves being compared to Linux. People don't loathe JavaScript for no reason. The language itself is pretty rough around the edges.

Not just the edges!

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?

Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

"It is all a matter of actually knowing how to write proper JavaScript, or just using TypeScript to compile code that looks like JavaScript."

> It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

You might wanna read that back to yourself. Now replace it with any language you hate, and then tell me how that statement makes any form of argument at all (it doesn't...).

I not a fan of javascript either, although I write js almost evey day and use Atom mainly because I could not find a better open source desktop editor that looks and works like Sublime Text. If anyone cares to write one in C++, D, Rust or Go, I'll happily use it.

There are many viable compile-to-js languages out there to pick from:

* clojurescript

* f# via fable

* c# via different means(even an MSIL compiler)

* Golang

* etc

I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bit of extra work that's probably small beans compared to the work required to get all of what parent described with completely separate languages and platforms.

Adding Reason(which is Ocaml with bucklescript backend) and Purescript to the list.

Adding this[0] list of languages that compile to JavaScript to the list. There seem so many that no matter your taste in syntactical sugar there should be something for you.

[0] https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Would like to clarify that it's not about "syntactical sugar" more like different semantics and/or safety(they treat js as machine code), hardly anyone would claim they are using these languages because of js syntax.

f# is the future

As clearly evidenced by how hard MS has been working to bring C# up to par these last few years :)

Naturally there are limits to how well you can retrofit something into a language compared to having that feature there from the start...

Electron is not really fast, nor does it generate great GUIs. It's much younger than Qt, only four years old. It's not frequently updated, it uses an insecure version of the Chromium browser. So... not all positives can be applied.

In fact none can be applied except ease of use and it's about the same, until the app grows and one realizes that the typical JS architecture is as easy to structure as a pile of mush.

Electron supporters are really taking the piss in this thread. Slapping together a bunch of statements which can be easily disproved doesn't qualify as an argument.

I absolutely disagree with all of your statements and think they are equally unjustified.

You have your unshakable opinions and I’ll leave you alone with them.

Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes.

But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS.

I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen.

I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment.

There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app?

You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core.

Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.

The thing is, with the desktop Web in the end what we get is ChromeOS, a browser window manager that makes the actual kernel completely irrelevant.

The adoration of Electron apps among Linux users will be the final nail on the year of desktop Linux.

> “really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies”

did you mean /s/start/stop/ above?

Uh, yeah. People have definitely started.

"Web on desktop" Reminds me of Win98 and how Microsoft tried to push that back then. It's just a bad security model. Technologies were different, but the security implications that lead to exploits stayed the same.

theres very litle reason today to make an electron app instead of a web app. especially if its just a client.

> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers

Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible".

Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.

I'm really surprised we haven't seen the functional style of elm, react and friends backported into modern gui frameworks. A react-like framework for native apps written entirely in swift would be killer - swift is a much better language than JS, and the resulting apps would be much smaller and snappier than what we get with electron or react native.

C#/F# would be a great candidate for this kind of thing too.

Qt QML is JS with a declarative UI language and C++ when you need it.

On the other hand you have JS with a document markup language combined with style sheets.

And the first one is embarassing you say. And declaring UIs in HTML and CSS is easier than in QML.

Why do you even post this. I mean... it's trivial to disprove it. Do you subscribe to the idea that if one makes enough noise their arguments will win out?

>the ease of CSS/HTML

Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.

On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.

> Bringing web security issues to desktop apps

Wonderful :)

Why does anyone think that blacklisting things they know about makes html more secure?

I guess whitelisting only the things they are absolutely sure are harmless is way more work.

Even whitelisting is dangerous for web/html. Given any tag, there's probably a large number of things you can do with them that boggles the mind as in "whoa I didn't know you could do that..." including things that are not in the w3c specs but are coded into the interpreters.

Basically the experience of a web developer every day, no matter how experienced you are.

I you whitelist tags and then whitelist attributes and then whitelist attribute values and for attributes that have values with its own structure, like style whitelist allowed things in that structure, you should be fine.

But it's hard to restrain yourself from doing: allow any (possibly except some) at any stage of whitelisting.

Even to a point of not allowing string of any characters as attribute value.

How about “not using a bazooka to kill a mosquito”? There's no reason why a text editor needs a frigging browser engine as a core component.

Apparently there's a reason because VS Code (and Atom) is way more useful than any other editor built over last few decades.

And yet somehow neither of them can compare to text-mode editors built more than 30 years ago.

I like to use both, depending on what I'm working on. If I'm writing code then a vim / tmux combo can be great but if you're editing markdown or an html / css website having the live preview and same developer tools as the browser is really nice.

Unsure how to quantify this kind of hyperbole. Compared to SublimeText 2 which is outdated at this point, VS Code and Atom are only getting back to the standard of fast code editors from the last few years ...

If you go back a few decades, you're competing against vi/vim and emacs, and there's no way you can say VS Code (and atom) can go against the "usefulness" or even productivity of either of those editors and their development environments.

Is there a good reason to allow unsafe eval in the Content Security Policy?

Not really, except when you are first adding a CSP to an older site that relies on eval (probably in a some crazy old jquery library). The name 'unsafe-eval' and the fact that 'unsafe-eval' has to be explicitly enabled are strong hints that you should move off of it as soon as possible

This is horrifying. And they only applied a bandage as a fix.

Unrelated: the article kept sending blurry low-res images and downloading the full version as I scrolled past them. I found this very annoying since I have a poor internet connection and had to wait for each image to load. I’d much rather prefer a slightly longer initial page load than waiting for each image.

The author suggests a malicious attacker might typosquat common packages and embed the exploit in a readme.

But if the user is already downloading your package, why bother with an exploit? You’ve got all the permissions allocated to packages (which I imagine are most permissions). You can just execute the malicious code directly from the package.

Edit: nvm

from the article:

> So a malicious attacker would just have to register a bunch of malicious packages for every letter or offer a few packages with similar names to existing ones. As soon as someone clicked on the name to see the full entry (not installing it!), the malicious code would already be executed.

My bad, missed that part. Yikes.

Reply on news.ycombinator.com