The release process should be as simple as possible but also not sacrifice security for convenience.
We should probably have a constraint that new releases that trigger auto-update require a 2nd reviewer to avoid accidentally released versions or attacks.

The packager in create-react-app-extensions can produce .asar and amd-zipped (https://github.com/cthackers/adm-zip) packages.

The shell should be able to handle both.

• Documentation
• Run GH pages locally
• Implement new header
• Implement dark theme
• Intro text
• New font
• Mobile friendly
• Ensure releases table is solid
• Remove release body text

related to #1

1. Only Load Secure Content: use https/wss instead of http/ws
2. Disable Node.js Integration for Remote Content
3. Enable Context Isolation for Remote Content
4. Handle Session Permission Requests From Remote Content
5. Do Not Disable WebSecurity
6. Define a Content Security Policy
7. Do Not Set allowRunningInsecureContent to true
8. Do Not Enable Experimental Features
9. Do Not Use enableBlinkFeatures
10. Do Not Use allowpopups
11. Verify WebView Options Before Creation
12. Disable or limit navigation
13. Disable or limit creation of new windows

see: https://electronjs.org/docs/tutorial/security

Especially make sure that:

• nodeIntegration is turned off for ALL renderers
• preload scripts are not leaking ANY NodeJs API: no window.process, window.require, window.fs, window.ipc
• IPC is restricted in the preload script: no wildcard IPC - everything is put behind facade object and "whitelisted"
• webview support is enabled through the webviewTag flag
• Electron logic is encapsulated in its own separate file outside of main

We want the CI to build a new release draft whenever a new Electron version is released to:
https://github.com/electron/electron/releases

After the build is tested and changed from draft to release this should also trigger the auto-updater so that installed version automatically update.

The app that is downloaded with the electron-app-updater can currently & intentionally execute code on the main thread.
Because this is a sec. issue if the downloaded app is unknown(not the case for mist) or npm modules in the app are potentially malicious(this is the case for every app) the main process should instead configure a renderer / browser window following https://electronjs.org/docs/tutorial/security and should not allow any other code to run on the privileged main process until we find a better solution

no description

• build Linux
• build Windows
• build Mac

This is a rewrite of the geth binary download, start, stop and configuration logic.

Related to

• https://github.com/ethereumjs/geth.js
• https://github.com/ethereum/ethereum-client-binaries
• https://github.com/ethereum/mist/blob/develop/modules/clientBinaryManager.js

Requirements analysis based on Mist issues:

• attach to an already running geth node: ethereum/mist#3859
  -> many users just chose this way because they cannot make fine-grained configurations about e.g. the datadir in the UI. If we allow a better config through Mist it will resolve many of the problems that happen because people try to bypass the default config.

• support user IPC configuration: ethereum/mist#3809

• let users explicitly choose their node from all available (local & remote) geth binaries: ethereum/mist#3855

• remove flag-pass-through: don't forward electron args to sub-processes unless really needed: ethereum/mist#4145, ethereum/mist#4076
  -> defer geth start so that this can be done through UI instead of CLI args

• provide useful debug info if geth binaries cannot be found or are otherwise 'unavailable': ethereum/mist#4157, ethereum/mist#3978

• provide info for a recommended geth version but don't block if it is not used: sanity check should be warning not error: ethereum/mist#4064

• provide better guidance on when to use/not to use http IPC but don't crash: ethereum/mist#3995

• detect datadir & binary path changes and issue warnings

• allow backup and migration of different --datadir locations:
  ethereum/mist#4161
  ethereum/mist#4164

Notes

We should try to minimize the dependency footprint here as everything runs on main/privileged: no unnecessary 3rd party modules.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

File: renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid configuration option: packageRules[0].enable``

We want the CI to build a new release draft whenever a new mist(-ui)-react version is released to:
https://github.com/ethereum/mist-ui-react/releases

After the build is tested and changed from draft to release this should NOT trigger electron-builder's auto-updater because electron-app-updater will take care of updating installed versions.

yarn.lock serves to determine the exact modules' versions at a certain commit time. We should implement a similar mechanism to handle the mist-ui, to make this use case possible:

git checkout v2.0.0
yarn release

git checkout v1.0.0
yarn release

ideally, each of those commands would download mist-ui packages specified in their HEAD and pack a reproducible release.

got it -rg

do you want to disallow downloading multiple different versions at once or just the same version? For the same version, it was a bug where I had to change returning on release.progress > 0 to >= 0 :) i'll have it in my next PR

https://www.electron.build/code-signing

• update app manager version
• test Grid on several OSes