Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

Post reply on HN
Print view View original

111–120 of 152 posts

Re: From Markdown to remote code execution in Atom

#111

Post by josephg »

Tehnix wrote: post #77
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…

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

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.

Re: From Markdown to remote code execution in Atom

#112

Post by blub »

Tehnix wrote: post #77
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…

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

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?

Re: From Markdown to remote code execution in Atom

#113

Post by hoodoof »

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.

Re: From Markdown to remote code execution in Atom

#114

Post by syrrim »

eptcyka wrote: post #7

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?

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.

Re: From Markdown to remote code execution in Atom

#115

Post by zghst »

hoodoof wrote: post #113

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

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

Re: From Markdown to remote code execution in Atom

#116

Post by zghst »

Rapzid wrote: post #83
DandyDev wrote: post #40

Earlier quoted context omitted.

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

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

f# is the future

Re: From Markdown to remote code execution in Atom

#117

Post by zghst »

rootlocus wrote: post #70
tcd wrote: post #42

Earlier quoted context omitted.

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!

Re: From Markdown to remote code execution in Atom

#118

Post by JoshMnem »

Klathmon wrote: post #78
mattgreenrocks wrote: post #72

Earlier quoted context omitted.

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.

Re: From Markdown to remote code execution in Atom

#119

Post by Klathmon »

JoshMnem wrote: post #118
Klathmon wrote: post #78

Earlier quoted context omitted.

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)

Re: From Markdown to remote code execution in Atom

#120

Post by sfifs »

cabalamat wrote: post #8

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.

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!
Post reply on HN