FAQ

Can I bundle the Widevine CDM to avoid downloading it on first start?

Show

While technically possible there are legal issues with providing the Widevine CDM with the application bundle, like Chrome does. We have been explicitly warned not to do this by the Widevine Team since it would open us up to potential litigation, specifically over decoder licensing (since there are decoders included in the CDM). As long as the CDM is dynamically installed by download from Google servers it is covered by the license Google has for the CDM.

How do I verify the VMP status of my build?

Show

You can use the castlabs Widevine VMP Lab to verify the VMP status of your ECS build. Open the VMP Lab in your ECS application, leave the backend set to UAT, and click Load Content. The VMP status will appear in the log output once the license response is received. See the VMP wiki page for details.

How can I VMP-sign my application during development?

Show

To VMP-sign your application during development you can use EVS to sign the distribution installed by npm in node_modules/electron/dist:

% python -m castlabs_evs.vmp sign-pkg node_modules/electron/dist
Signing: node_modules/electron/dist/electron.exe
 - Verifying existing VMP signature
 - Signature invalid: Certificate is valid for development only
 - Requesting VMP signature

Alternatively, if you have a VMP certificate of your own, you can use the vmp-resign.py script to do the same. In both cases you would need to do this each time you reinstall or update the distribution.

How can I use electron-builder with ECS?

Show

To be able to use electron-builder with ECS you have two options with different pros and cons. Option one is to use the electronDist configuration in your package.json to point to an already downloaded distribution, such as the one installed in node_modules by npm:

"build": {
  "electronDist": "node_modules/electron/dist"
}

Using this option lets electron-builder skip the download step but, as a consequence, only works on the platform that matches your installed distribution. The second option is to use the electronDownload/mirror configuration instead:

"build": {
  "electronDownload": {
    "mirror": "https://github.com/castlabs/electron-releases/releases/download/v"
  }
}

This allows electron-builder to automatically select and download the package for the requested platform, which makes it possible to build a package regardless of your native platform.

What kind of notarization is necessary on macOS Catalina (10.15) and later?

Show

With the stricter notarization requirements for macOS Catalina, 10.15, and later, you need to disable library validation in order for Electron to be able to load the Widevine CDM. You can do this by adding the following entitlement:

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

Can ECS be packaged for the Windows Store?

Show

This is not recommended because of inherent conflicts between the sanboxing done by the Desktop Bridge and Chromium itself, which causes issues with the Widevine CDM. The only reliable workaround is to disable the Chromium sandbox entirely, by passing the --no-sandbox command-line option to ECS, but this comes with serious security implications and is thus not something we can generally recommend.

Can ECS be packaged as a Universal binary on macOS?

Show

Yes, this is possible. However, when @electron/universal is used under the hood it requires an extra step (see ticket #105 for original investigation into this).

The reason for the extra step is that the pre-generated development VMP signature that is part of ECS releases can't be automatically merged by @electron/universal - leading to an error. To fix this, e.g. when using electron-builder to generate a macOS package, you can add something along the lines of the snippet below in the afterPack hook to remove the conflicting file prior to the merge. A new signature file will be generated when the merged universal package is then VMP signed using EVS (our VMP signing service), just make sure that the newly generated signature is not also removed by your hook implementation.

const fs = require('fs')

exports.default = async function(context) {
  fs.unlinkSync(context.appOutDir + '/My.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/Electron Framework.sig')
}

For other packagers using a corresponding hook should allow achieving the same result, the key being that the file is removed prior to the packager reaching the universal binary merging step (and that a new VMP signature is generated after the merge).

Can I use @electron/fuses with the free version of ECS and EVS?

Show

There is partial support for using fuses with ECS. Starting with version 35.0.0 a static set of fuses (in addition to the build-time default fuse wire) is supported by the VMP signing service. This effectively means that you can VMP-sign builds using this pre-defined set of fuses:

// Example @electron/fuses configuration
{
  version: FuseVersion.V1,
  [FuseV1Options.RunAsNode]: false,
  [FuseV1Options.EnableCookieEncryption]: true,
  [FuseV1Options.EnableNodeOptionsEnvironmentVariable]: false,
  [FuseV1Options.EnableNodeCliInspectArguments]: false,
  [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true,
  [FuseV1Options.OnlyLoadAppFromAsar]: true,
  [FuseV1Options.LoadBrowserProcessSpecificV8Snapshot]: false,
  [FuseV1Options.GrantFileProtocolExtraPrivileges]: true,
}

Versions prior to 35 does not support this, and can't successfully be VMP-signed with any change of the fuse wire. Going through a 3PL certification and building your own fork would make using any fuses possible, for any release, but comes associated with additional contractual concerns and costs.

Additional details and context can be found in the discussion of Electron Fuses in the related ticket: #152