36 ms·

As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms

As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred. The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares. Dave and toDesktop have build a product that serves many people really well, but I'd encourage everyone building desktop software (no matter how, with or without toDesktop!) to really understand everything involved in compiling, signing, and releasing your builds. In my projects, I often make an argument against too much abstraction and long dependency chain in those processes. If you're an Electron developer (like the apps mentioned), I recommend: * Build with Electron Forge, which is maintained by Electron and uses @electron/windows-sign and @electron/osx-sign directly. No magic. * For Windows signing, use Azure Trusted Signing, which signs just-in-time. That's relatively new and offers some additional recovery mechanisms in the worst case. * You probably want to rotate your certificates if you ever gave anyone else access. * Lastly, you should probably be the only one with the keys to your update server.

paradite 2y ago
Hi. I'm an electron app developer. I use electron builder paired with AWS S3 for auto update. I have always put Windows signing on hold due to the cost of commercial certificate. Is the Azure Trusted Signing significantly cheaper than obtaining a commercial certificate? Can I run it on my CI as part of my build pipeline?
- felixrieseberg 2y ago
  Azure Trusted Signing is one of the best things Microsoft has done for app developers last year, I'm really happy with it. It's $9.99/month and open both to companies and individuals who can verify their identity (it used to only be companies). You really just call signtool.exe with a custom dll. I wrote @electron/windows-sign specifically to cover it: https://github.com/electron/windows-sign https://github.com/electron/windows-sign Reference implementation: https://github.com/felixrieseberg/windows95/blob/master/forge.config.js#L26-L31 https://github.com/felixrieseberg/windows95/blob/master/forg...
  - itsFolf 2y ago
    The big limitation with Azure Trusted Signing is that your organization needs to be at least 3 years old. Seems to be a weird case where developers that could benefit from this solution are pushed towards doing something else, with no big reason to switch back later.
    - Deathmax 2y ago
      That limitation should go away when Trusted Signing graduates from preview to GA. The current limitation is because the CA rules say you must perform identity validation of the requester for orgs younger than 3 years old, which Microsoft isn't set up for yet.
    - gschier 2y ago
      This is not true. Or maybe it is but they missed me? I signed up with a brand new company without issue.
  - paradite 2y ago
    Hi. This is very helpful. Thanks for sharing!
gamedever 2y ago
And yet, tons of developers install github apps that ask for full permissions to control all repos and can therefore do to same things to every dev usings those services. github should be ashamed this possibility even exists and double ashamed that their permission system and UX is so poorly conceived that it leads apps to ask for all the permissions. IMO, github should spend significant effort so that the default is to present the user with a list of repos they want some github integration to have permissions for and then for each repo, the specific permissions needed. They should be designed that minimal permissions is encouraged. As it is, the path of least resistance for app devs is "give me root" and for users to say "ok, sure"
- madeofpalk 2y ago
  Why spend that effort when any code you run on your machine (such as dependency post-install scripts, or the dependencies themselves!) can just run `gh auth token` can grab a token for all the code you push up. By design, the gh cli wants write access to everything on github you can access.
- xmprt 2y ago
  I personally haven't worked with many of the github apps that you seem to refer to but the few that I've used are only limited to access the specific repositories that I give and within those repositories their access control is scoped as well. I figured this is all stuff that can be controlled on Github's side. Am I mistaken?
- charrondev 2y ago
  I will note that at least for our GitHub enterprise setup permissions are all granular, tokens are managed by the org and require an approval process. I’m not sure how much of this is “standard” for an org though.
- cdmyrm 2y ago
  Yeah, turns out "modern" software development has more holes than Swiss cheese. What else is new?
TZubiri 2y ago
Question. I've noticed a lot of websites import from other sites, instead of local. <script src="scriptscdn.com/libv1.3"> I almost never see a hash in there. Is this as dangerous as it looks, why don't people just use a hash?
- bastawhiz 2y ago
  1. Yes 2. Because that requires you to know how to find the hash and add it. Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.
  - valenterry 2y ago
    Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.
    - sirl1on 2y ago
      You can define a CSP header to only exec 3rd Party scripts with known hashes
      - valenterry 2y ago
        But that doesn't make it easy to integrate a new script from an author who doesn't provide the hash already.
        no_wizard 2y ago
        Vendor your dependencies. It’s better for you as a maintainer anyway, since caching only works[0] with first party domains with any reliability. And once you vendor your dependencies you can calculate the hash yourself [0]: there are caveats to this
101008 2y ago
Question that I hope you can help me. I'm working on a Electron app that works offline. I am plan to sell it cheap, like $5 one payment. It won't have licenses or anything, so if somebody wants to distribute it outside my website they will be able to do it. If I just want to point to a exe file link in S3 without auto updates, should just compile and upload be enough?
RadiozRadioz 2y ago
How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. Touching files on a user's system should be treated as a rare special occurrence. If a server is involved with the app, build a stable interface and think long and hard about every change. Meticulously version and maintain everything. If a server is involved, it is completely unacceptable for a server-side change to break an existing user's local application unless it is impossible to avoid - it should be seen as an absolute last resort with an apology to affected customers (agree with OP on this one). It is your duty to make sure _all_ of your users are able to continue using the same software they installed in exactly the same way for the reasonable lifetime of their contract, the package, or underlying system (and that lifetime is measured in years/decades, with the goal of forever where possible. Not months). You can, if you must, include an update notification, but this absolutely cannot disrupt the user's experience; no popups, do not require action, include an "ignore forever" button. If you have a good product with genuinely good feature improvements, users will voluntarily upgrade to a new package. If they don't, that is why you have a sales team. Additionally, more broadly, it is not your app's job to handle updates. That is the job of your operating system and its package manager. But I understand that Windows is behind in this regard, so it is acceptable to compromise there. We go a step further at my company. Any customer is able to request any previous version of their package at any time, and we provide them an Internet download page or overnight ship them a CD free of charge (and now USB too).
- Hackbraten 2y ago
  > Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.
  - cdmyrm 2y ago
    You're allowed to have a support matrix. You can refuse to support versions that are too old, but you can also just... let people keep using programs on their own computers.
filleokus 2y ago
> For Windows signing, use Azure Trusted Signing I recently checked it out as an alternative to renewing our signing cert, but it doesn't support issuing EV certs. I've understood it as having an EV code signing cert on Windows is required for drivers, but somehow also gives you better SmartScreen reputation making it useful even for user space apps in enterprisey settings? Not sure if this is FUD spread by the EV CA's or not though?
- linwangg 2y ago
  [flagged]
- gschier 2y ago
  Im not sure if they're technically considered EV but mine is linked to my corporation and I get no virus warnings at all during install.
- Moni_Mac 2y ago
  [dead]
jbverschoor 2y ago
You know, there's this nice little thing called AppStore on the mac, and it can auto update
- woadwarrior01 2y ago
  All apps on the Mac AppStore have to be sandboxed, which is great for the end-user, but a pain in the neck for the run of the mill electron app dev.
deleted 2y ago
[deleted]
rustcleaner 2y ago
This one is right. Have a shoe-box key, a key which is copied 2*N (redundancy) times and N copies are stored in 2 shoe-boxes. It can be on tape, or optical, or silicon, or paper. This key always stays offline. This is your rootiest of root keys in your products, and almost nothing is signed by it. The next key down which the shoe-box key signs (ideally, the only thing) is for all intents and purposes your acting "root certificate authority" key running hot in whatever highly secure signing enclave you design for any other ordinary root CA setup. Then continue from there. Your hot and running root CA could get totally pwned, and as long as you had come to Jesus with your shoe-box key and religiously never ever interacted with it or put it online in any way, you can sign a new acting root CA key with it and sign a revocation for the old one. Then put the shoe-box away.
- account42 2y ago
  Signing a revocation doesn't magically inform all affected devices. In practice this is equivalent to pushing an update that replaces the root key.
- oncallthrow 2y ago
  > It can be on tape, or optical, or silicon, or paper. You can pick up a hardware security module for a few thousand bucks. No excuse not to.
  - xandrius 2y ago
    I see a good excuse right there: the few thousand bucks. I'd rather one the most reliable and cheap hardware security model we know of: paper. Print a bunch of QR/datamatrix codes with your key. Keep one in a fireproof safe in your house, and another one elsewhere. Total cost: ~$0.1 (+ the multipurpose safe, if needed)
    - HeatrayEnjoyer 2y ago
      Printers often have hard drives with cached pages
mckravchyk 2y ago
> No magic. There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)
hinkley 2y ago
Code signing is a really excellent place to look at ponying up the money for one of those hardware security modules that triggers sticker shock. The ones on their own PCI card with potted chips and optional Byzantine Generals access cards and consultants wearing ties. It’s cheaper than blowing six months of developer time trying to fake it (remember it will always take you twice as long as you think it will) I built one code signing system after being the “rubber duck” for a gentleman who built another, and both used HSM cards and not cheap ones. Not those shitty little USB ones. One protected cellphones, the other protected commercial aviation.

paradite 2y ago

Hi. I'm an electron app developer. I use electron builder paired with AWS S3 for auto update. I have always put Windows signing on hold due to the cost of commercial certificate. Is the Azure Trusted Signing significantly cheaper than obtaining a commercial certificate? Can I run it on my CI as part of my build pipeline?

felixrieseberg 2y ago
Azure Trusted Signing is one of the best things Microsoft has done for app developers last year, I'm really happy with it. It's $9.99/month and open both to companies and individuals who can verify their identity (it used to only be companies). You really just call signtool.exe with a custom dll. I wrote @electron/windows-sign specifically to cover it: https://github.com/electron/windows-sign https://github.com/electron/windows-sign Reference implementation: https://github.com/felixrieseberg/windows95/blob/master/forge.config.js#L26-L31 https://github.com/felixrieseberg/windows95/blob/master/forg...
- itsFolf 2y ago
  The big limitation with Azure Trusted Signing is that your organization needs to be at least 3 years old. Seems to be a weird case where developers that could benefit from this solution are pushed towards doing something else, with no big reason to switch back later.
  - Deathmax 2y ago
    That limitation should go away when Trusted Signing graduates from preview to GA. The current limitation is because the CA rules say you must perform identity validation of the requester for orgs younger than 3 years old, which Microsoft isn't set up for yet.
  - gschier 2y ago
    This is not true. Or maybe it is but they missed me? I signed up with a brand new company without issue.
- paradite 2y ago
  Hi. This is very helpful. Thanks for sharing!

gamedever 2y ago

And yet, tons of developers install github apps that ask for full permissions to control all repos and can therefore do to same things to every dev usings those services. github should be ashamed this possibility even exists and double ashamed that their permission system and UX is so poorly conceived that it leads apps to ask for all the permissions. IMO, github should spend significant effort so that the default is to present the user with a list of repos they want some github integration to have permissions for and then for each repo, the specific permissions needed. They should be designed that minimal permissions is encouraged. As it is, the path of least resistance for app devs is "give me root" and for users to say "ok, sure"

madeofpalk 2y ago
Why spend that effort when any code you run on your machine (such as dependency post-install scripts, or the dependencies themselves!) can just run `gh auth token` can grab a token for all the code you push up. By design, the gh cli wants write access to everything on github you can access.
xmprt 2y ago
I personally haven't worked with many of the github apps that you seem to refer to but the few that I've used are only limited to access the specific repositories that I give and within those repositories their access control is scoped as well. I figured this is all stuff that can be controlled on Github's side. Am I mistaken?
charrondev 2y ago
I will note that at least for our GitHub enterprise setup permissions are all granular, tokens are managed by the org and require an approval process. I’m not sure how much of this is “standard” for an org though.
cdmyrm 2y ago
Yeah, turns out "modern" software development has more holes than Swiss cheese. What else is new?

TZubiri 2y ago

Question. I've noticed a lot of websites import from other sites, instead of local. <script src="scriptscdn.com/libv1.3"> I almost never see a hash in there. Is this as dangerous as it looks, why don't people just use a hash?

bastawhiz 2y ago
1. Yes 2. Because that requires you to know how to find the hash and add it. Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.
- valenterry 2y ago
  Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.
  - sirl1on 2y ago
    You can define a CSP header to only exec 3rd Party scripts with known hashes
    - valenterry 2y ago
      But that doesn't make it easy to integrate a new script from an author who doesn't provide the hash already.
      - no_wizard 2y ago
        Vendor your dependencies. It’s better for you as a maintainer anyway, since caching only works[0] with first party domains with any reliability. And once you vendor your dependencies you can calculate the hash yourself [0]: there are caveats to this

101008 2y ago

Question that I hope you can help me. I'm working on a Electron app that works offline. I am plan to sell it cheap, like $5 one payment. It won't have licenses or anything, so if somebody wants to distribute it outside my website they will be able to do it. If I just want to point to a exe file link in S3 without auto updates, should just compile and upload be enough?

RadiozRadioz 2y ago

How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. Touching files on a user's system should be treated as a rare special occurrence. If a server is involved with the app, build a stable interface and think long and hard about every change. Meticulously version and maintain everything. If a server is involved, it is completely unacceptable for a server-side change to break an existing user's local application unless it is impossible to avoid - it should be seen as an absolute last resort with an apology to affected customers (agree with OP on this one). It is your duty to make sure _all_ of your users are able to continue using the same software they installed in exactly the same way for the reasonable lifetime of their contract, the package, or underlying system (and that lifetime is measured in years/decades, with the goal of forever where possible. Not months). You can, if you must, include an update notification, but this absolutely cannot disrupt the user's experience; no popups, do not require action, include an "ignore forever" button. If you have a good product with genuinely good feature improvements, users will voluntarily upgrade to a new package. If they don't, that is why you have a sales team. Additionally, more broadly, it is not your app's job to handle updates. That is the job of your operating system and its package manager. But I understand that Windows is behind in this regard, so it is acceptable to compromise there. We go a step further at my company. Any customer is able to request any previous version of their package at any time, and we provide them an Internet download page or overnight ship them a CD free of charge (and now USB too).

Hackbraten 2y ago
> Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.
- cdmyrm 2y ago
  You're allowed to have a support matrix. You can refuse to support versions that are too old, but you can also just... let people keep using programs on their own computers.

filleokus 2y ago

> For Windows signing, use Azure Trusted Signing I recently checked it out as an alternative to renewing our signing cert, but it doesn't support issuing EV certs. I've understood it as having an EV code signing cert on Windows is required for drivers, but somehow also gives you better SmartScreen reputation making it useful even for user space apps in enterprisey settings? Not sure if this is FUD spread by the EV CA's or not though?

linwangg 2y ago
[flagged]
gschier 2y ago
Im not sure if they're technically considered EV but mine is linked to my corporation and I get no virus warnings at all during install.
Moni_Mac 2y ago
[dead]

jbverschoor 2y ago

You know, there's this nice little thing called AppStore on the mac, and it can auto update

woadwarrior01 2y ago
All apps on the Mac AppStore have to be sandboxed, which is great for the end-user, but a pain in the neck for the run of the mill electron app dev.

deleted 2y ago

[deleted]

rustcleaner 2y ago

This one is right. Have a shoe-box key, a key which is copied 2*N (redundancy) times and N copies are stored in 2 shoe-boxes. It can be on tape, or optical, or silicon, or paper. This key always stays offline. This is your rootiest of root keys in your products, and almost nothing is signed by it. The next key down which the shoe-box key signs (ideally, the only thing) is for all intents and purposes your acting "root certificate authority" key running hot in whatever highly secure signing enclave you design for any other ordinary root CA setup. Then continue from there. Your hot and running root CA could get totally pwned, and as long as you had come to Jesus with your shoe-box key and religiously never ever interacted with it or put it online in any way, you can sign a new acting root CA key with it and sign a revocation for the old one. Then put the shoe-box away.

account42 2y ago
Signing a revocation doesn't magically inform all affected devices. In practice this is equivalent to pushing an update that replaces the root key.
oncallthrow 2y ago
> It can be on tape, or optical, or silicon, or paper. You can pick up a hardware security module for a few thousand bucks. No excuse not to.
- xandrius 2y ago
  I see a good excuse right there: the few thousand bucks. I'd rather one the most reliable and cheap hardware security model we know of: paper. Print a bunch of QR/datamatrix codes with your key. Keep one in a fireproof safe in your house, and another one elsewhere. Total cost: ~$0.1 (+ the multipurpose safe, if needed)
  - HeatrayEnjoyer 2y ago
    Printers often have hard drives with cached pages

mckravchyk 2y ago

> No magic. There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)

hinkley 2y ago

Code signing is a really excellent place to look at ponying up the money for one of those hardware security modules that triggers sticker shock. The ones on their own PCI card with potted chips and optional Byzantine Generals access cards and consultants wearing ties. It’s cheaper than blowing six months of developer time trying to fake it (remember it will always take you twice as long as you think it will) I built one code signing system after being the “rubber duck” for a gentleman who built another, and both used HSM cards and not cheap ones. Not those shitty little USB ones. One protected cellphones, the other protected commercial aviation.