From Markdown to remote code execution in Atom

Post by z3t4 » Thu, Nov 23, 2017, 10:30 PM UTC

scrollaway wrote: post #19

zx2c4 wrote: post #10

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 be…

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 desk…

Post by xfer » Thu, Nov 23, 2017, 10:38 PM UTC

neoeldex wrote: post #38

ryanplant-au wrote: post #32

Earlier quoted context omitted.

> 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 mo…

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.

Post by baddox » Thu, Nov 23, 2017, 10:44 PM UTC

pjmlp wrote: post #36

pjc50 wrote: post #26

Earlier quoted context omitted.

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.

Post by ovis » Thu, Nov 23, 2017, 10:50 PM UTC

scoot wrote: post #96

mattbierner wrote: post #14

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…

> 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?!

Post by xfer » Thu, Nov 23, 2017, 10:59 PM UTC

codefined wrote: post #94

xfer wrote: post #90

Earlier quoted context omitted.

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...