Can an asar archives be signed by a license key and/or success with Enclose.js?


#1

So I can’t seem to find a way to prevent someone from accessing source code for a published application?

There is both the propietary client, and as well a handfull of proprietary node modules for common client libraries and isomorphic libraries and model schemas, etc.

It seems like the best strategy for this would be to provide a feature for .asar format archives to be only openable/executable with a license key that they are packaged with - but then someone with a license key could still access the code?

Or is there no way around this issue?

I love open source, and feel like Electron is an incredible way to distribute open source applications, but our market is incredibly competitive and most everything is proprietary, so even our customers would expect this!

Thoughts?

Update:

Found this discussion: https://groups.google.com/forum/#!topic/nodejs/mPIcq5mHihM

Any thoughts on using http://enclosejs.com/ with electron.js?


Closed source app
#2

Minifying the code makes it more obscure, as a side effect, but I agree it may not be the best solution.


#3

Lol, of course Enclose.js is only available for non-commercial use, too. But it could be an option.

I’ve been able to access the source code for several non-open source electron.js apps by unpacking the asar file, however non-linux distributions that use signing seem somewhat less accessible.

I also just realized that without an authorized account, the app is veritably useless, so a license key is probably not necessary (Doh!)


#4

Enclose looks like it slows the application down a lot, which makes a lot of sense. It looks like Slack is packaged as a binary, but is that just how codesign + asar works? Haven’t achieved a darwin build yet, as I only have a linux machine.

I think I’ll just argue that minification and platform signing is good enough, and that no matter what we do, private actors will be able to reverse engineer the code if they want, and that our most valuable assets should live on the server anyways! Many enterprise webapps have only a minified frontend, so in theory our application is as vulnerable as any of these.


#5

I can see how other folks might find a license key signing w/ asar to be very handy, even if it doesn’t apply to my app. So here are some other thoughts about that:

  1. This would require on-the-fly packaging, which could be achieved with what? Appveyor and/or CircleCI?
  2. This would also require changes to the actual atom/asar project, I’d assume - what would that require? Would it require a fork, because obviously atom is open source focused and the developers might see this additional feature to be beyond their scope? Or could this be used for something similarl md5 verification which would still be useful for ensuring the security of open source projects?
  3. Also, setting up an account/license key management server seems like a mindf*** but I see that there are some npm packages for generating the appropriate keys and such.

#6

Oops I’m bad at using Discourse.

As you can see in my continued monolouge below, there is a good argument that minification is good enough because it’s what everyone else uses anyways, and besides, the real goods with our application live in the server sde.


#7

If you can afford the risk of users prettifying your minified code, then you might just go as far as saying: “look, this service can only be used with a regular license and the official client” and pack the app normally.


#8

Right. Licensing information is key. And, from experience, prettyifying minified code is still pretty ugly - function/class names and such are all obfusicated for performance reasons, and there are no comments, for example (at least I think thats what ugllify does). It will still run, but it could take time to know what is happening, especially if you have highly modularized code :smile:

And without having access to the source for the backend services, the client is pretty useless besides some having the source to cool frontend modules and components (trying to be humble here, haha). Again, you could name thousands of of web apps that rely on this very strategy. Also, the asar-ification and codesiging adds some additional layers of obscurity from prying eyes.

We don’t need to distribute to linux for this app, and my grestest success with accessing source from electron projects (that I shouldnt be able to access) are where apps are distributed as basic executables that use asar (I won’t mention which apps, for their sake) where the app.asar can just be decompressed into the actual source. The .app pacakges don’t seem to be as accessible.


#9

This is a very similar discussion to this previous one:

Except where that one talked about only preventing modifications to the source code, this is taking it a step further and attempting to prevent people from even viewing the code. But I believe my answer then still applies:

Let’s say you encrypt your code. (Digital signing doesn’t prevent people from reading the code, it verifies that the code hasn’t changed since it left your hands.) They can’t run it like that, so they have to have a key to decrypt it. If the key is shipped with the archive, then they could decrypt it themselves. If they have to get the key from a server every time, they could spoof your applicaton asking the server for the key, then they have the key and could decrypt it themselves. Or they could watch the network and read the key as it is coming back from the server or as the key is being read into memory.

No matter what you do, a persistent enough attacker is going to be able to get at whatever secrets you have in the code you let them have on their machine.


#10

Thanks for the clarification, this is very helpful! Definately realizing this is the case across the board. Sorry for wasting people’s time when I just needed to do my research.


#11

no apologies, I found your thread informative @acao


#12

In fact, i modified ASAR to add my own encryption. But it asks to modify Electron too to decrypt it to read the file.