I haven't been working on this project much lately, so it's possible there are things I have overlooked, but from my notes these appear to be the outstanding items:

• Auto upgrade for the OSX version. This code is mostly written but the flow needs to be tested with the real certificate. 2-4 hours.
• Font awesome doesn't render on Tails. I have no idea what this is about. 5 minutes - 4 hours.
• Re-name everything, and change the text to whatever vocabulary we land. Blocked by actually choosing a name/vocabulary. 1 hour.
• Complete documentation, convert to read the docs format. Blocked by getting some help from Trevor to solidify the documentation. 4 hours.
• Implement whatever UI changes are necessary to match the features Fred is adding. 8 hours? Hard to estimate.

Not too bad, but definitely some potential stumbling blocks in there.

It works fine on 6.9.1 but fails on 7.2.0.

When installing the deb package, a few apt dependencies must be satsified, otherwise the dpkg -i command will fail. These seem to be:

• libappindicator1
• libdbusmenu-glib4
• libdbusmenu-gtk4
• libindicator7

Tested under Debian Stretch. Should also test on Ubuntu Xenial and document any differences.

Output of make build

The current default behavior is similar to a password field in a web browser: instead of displaying the actual characters entered in the textarea, the equivalent number of black dots are shown instead. This behavior can be toggled by checking the "Reveal?" checkbox above and to the right of the textarea.

I find myself nearly always toggling the textarea to reveal the text, and find it annoying that I almost always have to check the "Reveal?" checkbox first. I think we should change this to display the typed text by default, and provide an option to "Hide?" it.

The benefit of obscuring the text is to mitigate some (but not all) shoulder-surfing attacks. Potential adversaries include another person in the room with the user while they are splitting a secret, video cameras that might record their screen (accidentally or intentionally), etc.

Note that obscuring the text on the screen is a strong mitigation against shoulder-surfing attacks, but not a complete one: for example, it's possible that a camera could film the user's keyboard and infer the secret by watching their keystrokes.

My arguments for changing the default include:

• When splitting the secret, making sure you've entered the correct secret is probably more important than mitigating shoulder-surfing attacks.
• In our best practices documentation, we discuss the sensitivity of both the splitting and recovering ceremonies. I think adding a note about mitigating shoulder-surfing attacks to the documentation would be more effective than defaulting to hiding the text, especially since in most cases the user can be expected to at least quickly reveal the secret to make sure it was entered correctly before proceeding with the ceremony.

In order to get a handle on the build process, with the intent of fully automating it, I'd like to have a build VM. That'll provide solid encapsulation of the dependencies, and save me from having to install nodejs in my host OS environment.

Ideally I'd like to be able to clone the git repo, run a command or two, and sip coffee while the packages build in a clean environment.

Despite new asset changes in #17, the built application still uses the default app icon for Electron:

Output of npm run dist on Mac includes:

⚠️ Application icon is not set, default Electron icon will be used

Notably that message does not display when building under Linux (including changes proposed in #22), but I also don't see a custom icon under Linux:

So looks like we have some pathing issues to sort out. Will hit the docs.

Bug

Description

Sunder uses electron 1.7.2 which has a CVE associated with it. While it appears Sunder does not use app.setAsDefaultProtocolClient and this vulnerability should not be exploitable, GitHub's Dependency Graph informs us that the current version is vulnerable.

More info here: https://electronjs.org/blog/protocol-handler-fix

Expected Behavior

Electron package version should not have a CVE associated to it.

Actual Behavior

Electron package version has a CVE associated to it.

Comments

The current main window is 1024x768px, which has a good height but is awkwardly too wide IMHO. I prefer something in the range of 600-660px.

The only potential issue here is what to do with the dev tools pane. When they are toggled on they default to displaying in a vertical pane within the main window, and if the window is very narrow everything will be too cramped to be usable. Note that this only affects developers, but it would be good for this to have an ergonomic default behavior as well. Two possible options:

1. Resize the window when the devtools are toggled on
2. Open the devtools in a separate window by default.

Also note that each individual developer can change the default location of the dev tools (click the three dots menu in the top right corner and change the Dock side ), and this change persists across restarts.

Getting an error on the TASK [sunder-build : Compile CSS and JS application code. task. Full gist of error output: https://gist.github.com/conorsch/fc36971557b21820af3b0f36693953e5

May be related to #10, but also maybe not. The line Cannot find module '../dist' is fairly explicit, but I defer to @GabeIsman on the proper solution.

Just had a heck of a time resolving conflicts between #15, #16, and #17. See #24 for a full report. The problems introduced in there were surely my fault, as I fumbled with sorting out the dependency changes in the closely related feature branches.

Let's add testing to the repo so that at the very least we can confirm tests are passing. That's not the same as a full npm test e2e build on Mac, but even that may be achievable in CI, since CircleCI supports Mac builds.

Feature Request

Description

We should improve the existing documentation (currently just a couple of .md files in docs/) so it is convenient for end users to read and navigate the documentation.

One possible suggestion: SecureDrop's had really good results from writing/building documentation with ReStructuredText/Sphinx and hosting them on https://readthedocs.org/.

Bug

Description

When a FileOrTextInput is rendered, a warning is displayed in the DevTools console:

Warning: Unknown props `initialValue`, `autofill`, `onUpdate`, `valid`, `invalid`, `dirty`, `pristine`, `error`, `active`, `touched`, `visited`, `autofilled` on <textarea> tag. Remove these props from the element. For details, see https://fb.me/react-unknown-prop
    in textarea (created by FileOrTextInput)
    in div (created by FileOrTextInput)
    in div (created by FileOrTextInput)
    in FileOrTextInput (created by Split)
    in div (created by Panel)
    in div (created by Panel)
    in Panel (created by Split)
    in div (created by Split)
    in Split (created by ReduxForm(Split))
    in ReduxForm(Split) (created by Connect(ReduxForm(Split)))
    in Connect(ReduxForm(Split)) (created by ReduxFormConnector(Split))
    in ReduxFormConnector(Split) (created by ConnectedForm)
    in ConnectedForm (created by SplitScreen)
    in div (created by Layout)
    in div (created by Layout)
    in Layout (created by SplitScreen)
    in SplitScreen (created by Connect(SplitScreen))
    in Connect(SplitScreen) (created by RouterContext)
    in div (created by App)
    in App (created by RouterContext)
    in RouterContext (created by Router)
    in Router
    in Provider

Steps to Reproduce

1. npm run dev
2. Click Sunder It
3. Observe warning logged in DevTools console.

Expected Behavior

A warning should not be logged when rendering a FileOrTextInput.

Comments

The warning message suggests visiting https://fb.me/react-unknown-prop for more info.

We need a few basic brand assets. At bare minimum: an app icon. Possibly also a logo. This doesn't have to be fancy at all, we could easily use what amounts to a placeholder logo, but we do need something beyond the default electron icon.

The postinstall task has a deprecation warning about using an old API of electron-rebuild. Not to mention it's not super clear to me that the current setup is even the right approach. Would a simple npm rebuild be more effective than electron-rebuild?

Feature Request

Description

Was initially confused as to whether tested versions of Node.js listed actually referred to NPM since some NPM versions looked similar. Tested Node and NPM versions should be listed, separately.

We can't load a secret from a file in the "Recover a Secret" flow.

Motivation: I want a small but non-trivial bug to work on so I can gain some experience with React and the secretshare codebase. Discussed this with @GabeIsman and agreed this was a desired feature that also fits the criteria of a good first bug. He was thinking of refactoring this into a unified "share input" component capable of handling either text input or file input. Since doing that refactor together sounds like a useful educational experience, I am going to start by doing this my (very likely to be naive and unsophisticated) way, and we can revisit refactoring after that.

Feature Request

Description

Document the use case of border crossings (e.g., share "shard" with remote party, then recover after safely crossing).

The Veracrypt integration in b1f92aa uses child_process.exec and string interpolation with user-provided input to build the command string. This is vulnerable to a shell injection attack.

Best practice is to use a list to provide arguments with execFile or spawn. For more info, see this blog post.

Bug

Description

Before @FredericJacobs implemented post-quantum signatures, each secret share was approximately the same size as the secret, and it was reasonable to assume that there might be cases where people would input secret shares manually, by typing them on a keyboard. Now that we are using post-quantum signatures, the minimum size of a secret share is ~130KB. I don't think we should expect that users will want to enter such large shares manually.

Steps to Reproduce

1. Open Sunder. Split a secret into shards and save a quorum of shards. The choice of secret and parameters are irrelevant to reproducing this issue.
2. From the home view, click Recover It to start the recovery flow.
3. Change the default method of secret share entry from From File to As text.
4. Open one of your secret shards from Step 1 in a text editor, and copy it to the clipboard.
5. Return to where you were in Sunder.
6. Paste the secret shard into the textarea in the Recover Secret view.

Expected Behavior

An error should not be encountered, since this is a perfectly reasonable course of action for the user to take.

Actual Behavior

A warning is displayed:

This is too large to display (don't worry, we can still use it).

This is holdover from before we integrated the post quantum signatures, when it was possible for a secret share to be just a handful of bytes. It misleadingly implies that it it is possible for the share to be small enough to display, but since we've implemented the post-quantum signature scheme that is impossible—even a 1-byte secret results in shares that are each 130KB in size, which is over the maximum display size.

Comments

This is a little tricky since I think we're going to have to get creative with the UI/UX.

I would argue that it doesn't make sense for this input to be a textarea, since the smallest possible share is so large that I don't think we should realistically expect users to type them in. On the other hand, it would be nice if we still supported pasting shares from the clipboard in the recovery flow.

Here's one proposal: replace the As text input option in the recovery flow with a From clipboard option. This would be a new React component with a Paste from Clipboard button. We should also ensure the default {Cmd,Ctrl}-V keyboard shortcut works in a convenient manner, and pastes the share from the clipboard.

Feature Request

Description

If you are in the "Distribute Secret Shards" view, there is no "Back" button that allows you to return to the previous "Create Secret Shards" view. There is a back button, but it says "Home" and takes you back to the start page.

I anticipate users splitting a secret, only to realize they want to modify the secret or the sharing parameters slightly. It would be nice if the user could go back to the previous "Create Secret Shards" view, make a minor modification to the parameters they already set, and then re-create secret shards with the updated parameters.

Of course, there is a serious UX concern, with implications for availability, here: users must not mix shards from two different sets of shards. Without providing some kind of clear messaging to the user, I'm afraid it would be easy for them to unintentionally or accidentally distribute shards from two or more sets, and then be unable to recover their secret at a later date.

User stories

• To do

Bug

Note: I've updated this to reflect the actual issue I discovered, not my bumbling initial mistaken issue.

Description

They fail on master with:

 1) main window should click view secret button:
     unknown error: Element <div class="btn btn-default  " id="view-secret-button">...</div> is not clickable at point (351, 496). Other element would receive the click: <div class="btn-icon-container">...</div>

Steps to Reproduce

npm run test-e2e, although this bug seems quite fragile in that it might be dependent on current system load (how fast chromium calculates layouts) or the size of your monitor, I'm not sure. Also it won't come up if you don't have Veracrypt installed.

Expected Behavior

Tests should pass.

Actual Behavior

They do not.

Now that we are using the post-quantum signature scheme, each share is very large even if the original secret is small. The view share text box is small (and lacks a scrollbar), so it feels kind of confusing because the secret will always be larger than the window, but that is not immediately evident, and it is also not immediately evident that you can scroll the window (although you can) because there is no scrollbar.

Potential resolutions:

• Make the view share window larger and add a visible scrollbar
• Get rid of the "View" option entirely. It's hard for me to imagine ever really using it in practice - I would almost always use the "Copy" or "Save" buttons instead.

I didn't know about this project, but it looks really good. https://github.com/electron/spectron. It's much cleaner than the current setup for a couple of reasons:

1. It would allow us to run integration tests directly on the built binaries.
2. It would allow us to access real electron APIs from the tests, so we can stop mocking electron.remote and get more test coverage around the OS interactions.
3. It would solve the integration test issue in #34, by allowing us to directly access electron.clipboard.read from the test.

Bug

Description

On macOS 10.13.3, npm run dist hangs on the "Building DMG" step.

Steps to Reproduce

On macOS 10.13.3:

1. npm install
2. npm run dist

Expected Behavior

npm run dist should complete in a reasonable amount of time and output a functional .dmg, or we should disable building DMG if the .zip format is suitable for distribution.

Comments

Possibly related to the relatively old version of electron-builder we are using (17.10.0 vs. 19.56.0).

Please use the appropriate part of the template: "Bug" or "Feature Request"

Bug

Description

A short summary of the issue.

Steps to Reproduce

OS: macOS High Sierra
Node version: v8.9.4
NPM version: v5.6.0

Update local repo with the latest from the master branch. Ran npm install.

Expected Behavior

Build runs successfully.

Actual Behavior

Build fails and debug log shows the following issue involving a JSON parsing error:

0 info it worked if it ends with ok
1 verbose cli [ '/Users/huertanix/.nvm/versions/node/v8.9.4/bin/node',
1 verbose cli   '/Users/huertanix/.nvm/versions/node/v8.9.4/bin/npm',
1 verbose cli   'install' ]
2 info using [email protected]
3 info using [email protected]
4 verbose npm-session be5730aade9d19ab
5 silly install runPreinstallTopLevelLifecycles
6 silly preinstall [email protected]
7 info lifecycle [email protected]~preinstall: [email protected]
8 silly install loadCurrentTree
9 silly install readLocalPackageData
10 silly install loadIdealTree
11 silly install cloneCurrentTreeToIdealTree
12 silly install loadShrinkwrap
13 silly saveTree [email protected]
14 verbose stack SyntaxError: Unexpected token < in JSON at position 387
14 verbose stack     at JSON.parse (<anonymous>)
14 verbose stack     at module.exports (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/lib/utils/parse-json.js:3:15)
14 verbose stack     at BB.join (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/lib/install/read-shrinkwrap.js:31:20)
14 verbose stack     at tryCatcher (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
14 verbose stack     at Holder$3._callFunction (eval at generateHolderClass (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/join.js:92:16), <anonymous>:14:44)
14 verbose stack     at Holder$3.checkFulfillment (eval at generateHolderClass (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/join.js:92:16), <anonymous>:29:30)
14 verbose stack     at Promise.eval (eval at thenCallback (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/join.js:14:16), <anonymous>:6:20)
14 verbose stack     at Promise._settlePromise (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:566:21)
14 verbose stack     at Promise._settlePromise0 (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
14 verbose stack     at Promise._settlePromises (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
14 verbose stack     at Promise._fulfill (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18)
14 verbose stack     at Promise._settlePromise (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:582:21)
14 verbose stack     at Promise._settlePromise0 (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
14 verbose stack     at Promise._settlePromises (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
14 verbose stack     at Promise._fulfill (/Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18)
14 verbose stack     at /Users/huertanix/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/bluebird/js/release/nodeback.js:42:21
15 verbose cwd /Users/huertanix/Source/sunder
16 verbose Darwin 17.4.0
17 verbose argv "/Users/huertanix/.nvm/versions/node/v8.9.4/bin/node" "/Users/huertanix/.nvm/versions/node/v8.9.4/bin/npm" "install"
18 verbose node v8.9.4
19 verbose npm  v5.6.0
20 error Unexpected token < in JSON at position 387
21 verbose exit [ 1, true ]

Feature Request

Description

While React should automatically escape any potential injection, electron does not offer a way to eliminate network connectivity. Using a restrictive content security policy would provide defense-in-depth and further reduce the risk of XSS within the app.

User Stories

As a developer, I want to ensure that JavaScript code is executed only from local sources.

Feature Request

Description

The Debian packages are currently built via Ansible, requiring Vagrant VMs. A full build takes ~10m, which isn't terrible, but repeated builds aren't much faster.

User Stories

As a developer, I don't want to install a bunch of clunky tooling to get started a new project like Sunder. If I can run containers, most everything else in the build environment should be automatic.

As a maintainer, I want to make sure we're testing both the build logic and the developer environment. By using containers for building, we can run the same logic in CI and prevent version mismatches, thereby distributing a more reliable build env.

Bug

Description

The FileOrTextInput triggers a warning in the developer console when it is rendered:

Warning: Unknown props `initialValue`, `autofill`, `onUpdate`, `valid`, `invalid`, `dirty`, `pristine`, `error`, `active`, `touched`, `visited`, `autofilled` on <textarea> tag. Remove these props from the element. For details, see https://fb.me/react-unknown-prop
    in textarea (created by FileOrTextInput)
    in div (created by FileOrTextInput)
    in div (created by FileOrTextInput)
    in FileOrTextInput (created by Split)
    in div (created by Panel)
    in div (created by Panel)
    in Panel (created by Split)
    in div (created by Split)
    in Split (created by ReduxForm(Split))
    in ReduxForm(Split) (created by Connect(ReduxForm(Split)))
    in Connect(ReduxForm(Split)) (created by ReduxFormConnector(Split))
    in ReduxFormConnector(Split) (created by ConnectedForm)
    in ConnectedForm (created by SplitScreen)
    in div (created by Layout)
    in div (created by Layout)
    in Layout (created by SplitScreen)
    in SplitScreen (created by Connect(SplitScreen))
    in Connect(SplitScreen) (created by RouterContext)
    in div (created by App)
    in App (created by RouterContext)
    in RouterContext (created by Router)
    in Router
    in Provider

Steps to Reproduce

1. npm run dev
2. On the start screen, click Sunder It.
3. When the next page is rendered, the warning is logged to the developer console.

Expected Behavior

No mysterious warning!

Comments

The warning helpfully includes a link to some documentation about this specific warning. Unfortunately, I do not understand React well enough to grok the linked docs.

Feature Request

Description

We need a proper LICENSE file for the project.

At the moment, the recovery UI uses a lightning bolt icon for individual shares/shards:

We asked our designer to come up with some ideas for a better share/shard icon, and they provided the following designs:

When we last discussed this as a group, we agreed that 3 was the winner. I also think 1 would be a good choice. We should choose one and integrate it into the recovery UI.

The interface icons for common actions such as Save and Copy do not render on Debian Stretch. Example:

On Mac those icons render just fine. Tried installing the deb package on Tails, to make sure the problem wasn't with my workstation (which is running Debian Stretch), but the install failed. See gist here: https://gist.github.com/conorsch/1499ec7eb575258ebcadda1595ed4f78

Looks like we'll need a lot more Linux testing now that we've switched the build logic to electron-builder. Happy to handle that, but waiting for resolution of #16 and #17 first.

Please use the appropriate part of the template: "Bug" or "Feature Request"

Feature Request

Description

Update user_manual.md with screenshots from the latest build of Sunder.

Feature Request

Description

Document the use case of recovering a shared SD signing key for the air-gapped SD release ceremony.

The documentation should be revised to achieve the following goals:

1. Clearly, but succinctly, describe Sunder's underlying cryptography and technology. Link to external resources where appropriate.
2. Clearly describe how to obtain a copy of Sunder to try out. For the initial release, we can provide a .dmg and a .deb on the GitHub release page.
3. Write succinct walkthrough guides for splitting and recovering secrets with Sunder, with screenshots.
4. Pick one example use case" and document it carefully. We've agreed #50 is the best choice, as it is the OG use case and highlights the Veracrypt integration.

Bug

Description

The command make build failed with the following error, this is Debian9 with libvirt backend.

Steps to Reproduce

$ make build
make ansible
make[1]: Entering directory '/home/kdas/code/sunder'
ansible-galaxy install -r ansible/requirements.yml -p ansible/roles
- downloading role 'nodejs', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-nodejs/archive/4.1.2.tar.gz
- extracting geerlingguy.nodejs to /home/kdas/code/sunder/ansible/roles/geerlingguy.nodejs
- geerlingguy.nodejs (4.1.2) was installed successfully
make[1]: Leaving directory '/home/kdas/code/sunder'
vagrant up --provision
Bringing machine 'sunder' up with 'libvirt' provider...
==> sunder: Box 'ubuntu/trusty64' could not be found. Attempting to find and install...
    sunder: Box Provider: libvirt
    sunder: Box Version: >= 0
==> sunder: Loading metadata for box 'ubuntu/trusty64'
    sunder: URL: https://atlas.hashicorp.com/ubuntu/trusty64
The box you're attempting to add doesn't support the provider
you requested. Please find an alternate box or use an alternate
provider. Double-check your requested provider to verify you didn't
simply misspell it.

If you're adding a box from HashiCorp's Atlas, make sure the box is
released.

Name: ubuntu/trusty64
Address: https://atlas.hashicorp.com/ubuntu/trusty64
Requested provider: [:libvirt]
Makefile:15: recipe for target 'build' failed
make: *** [build] Error 1

Expected Behavior

It should build the development environment properly.

We will have to update the documentation with proper steps.

We've taken some time to write explanatory docs, but haven't shared them around for review yet. Let's get some docs into this repo. We can use Markdown files, or RTD, depending on what we want the ultimate docs site for Sunder to be (e.g. github.com/freedomofpress/sunder, freedom.press/tools/sunder, etc.).

Let's start by commiting the existing docs we've written into this repo as Markdown and go from there.

Feature Request

Description

Document the use case of storing "shards" offline for safe archival.

• npm run test output
• npm-debug.log

I'm running the latest LTS release of Node.js:

sunder ~> node --version
v6.11.0
sunder ~> npm --version
3.10.10

This is a feature that @FredericJacobs has already added to rusty-secrets but isn't yet supported in the app. Shouldn't be too difficult, but I also don't think it should block launch.

Bug

Description

When Sunder is run in development mode, a warning is logged to the DevTools shortly after startup:

A Parser-blocking, cross site (i.e. different eTLD+1) script, http://localhost:3000/dist/bundle.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.

Steps to Reproduce

1. npm run dev
2. The DevTools window opens automatically in development mode.
3. Observe warning message in the DevTools Console.

Expected Behavior

A warning should not be shown consistently after startup.

Comments

This is a minor issue, since the network request is not actually blocked, and the application subsequently works as expected. It is only an issue for developers, who might find it confusing or noisy.

Bug

Description

Documentation sates that node v4.1 and v5.7 are tested for use with sunder. However, underlying dependency electron-rebuild (v.1.5.7) requires node>=6 (see https://github.com/electron/electron-rebuild/blob/v1.5.7/package.json#L28)

Steps to Reproduce

npm install on master branch with node 4.x or 5.x and observe the following error:

/Users/m/src/sunder/node_modules/electron-rebuild/lib/src/rebuild.js:73
                depKeys.push(...Object.keys(rootPackageJson.dependencies || {}));
                             ^^^

SyntaxError: Unexpected token ...
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/m/src/sunder/node_modules/electron-rebuild/lib/src/main.js:3:19)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)

Expected Behavior

Application should install

Actual Behavior

An error occurs (see above)

It occurred to me to that we will need a landing page for this project. I'm imagining something really simple: one paragraph explanation, links to download, contribute, and read the docs. This involves a couple of steps:

• Decide on name/branding (blocking, everyone). (FPF+invitee shareable link: https://docs.google.com/a/freedom.press/document/d/16NE0FgT4LpwJo78lXPdVwnf8ZSouq-a2AfErgNFHQVU/edit?usp=sharing)
• Build out a simple static page, lifting some general styles from the app itself (@GabeIsman).
• Copy for the page, probably distilled from the docs (@justintroutman ? @trevortimm ?) (FPF+invitee shareable link: https://docs.google.com/a/freedom.press/document/d/10wB1b0kIpfI9eoFZyG9T6fi-cdB0uSBUlgWkucmLvhk/edit?usp=sharing

Regression as of merging #16. Debian packages built since that merge only show a blank screen on launch:

Whereas on the commit prior to that merge, e76d232, the package runs just peachy:

(Note the assets are old because the updated assets hadn't been merged yet.)

Rather at a loss to begin debugging this—will hit the Electron docs and see if I can bump verbosity to try to get more useful information about the failure.

Steps to Reproduce

1. Start Sunder
2. Click "Sunder It"
3. Fill in a secret and some share options
4. Click "Create Secret Shares"
5. In the list of secret shares, click the Copy button

Expected behavior

The share is copied to the clipboard and can be pasted in another application.

Observed behavior

The secret share is not copied to the clipboard.

Comments

This feature may also be broken on Linux; I haven't tested it there.

Feature Request

Description

Document the use case of documentarians wanting to protect unused footage (e.g., sharing "shard" with lawyer).

Bug

Description

During npm install, the following warning is logged:

npm WARN deprecated [email protected]: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

During both the sunder and recover UI flows, there is a progress indicator animation displayed between triggering either a sunder or recover action and displaying the resulting output. Currently, a large Sunder shield icon is overlaid on the input form and the inner keyhole rotates.

It is important to note that this animation is not, strictly speaking, necessary. In most cases the cryptographic operations complete so quickly that displaying a progress animation is unnecessary. The concept for adding the animation here was developed during the UI/UX design phase, since our initial user testing showed that some people were confused by how quickly the cryptographic operations completed, and adding a progress indicator helped them understand what was going on between entering input and receiving output.

I see a couple of possible approaches here:

1. If the cryptographic operations are found to be reasonably fast, we might consider removing the animation and reworking the UI on the output views so it is clear that the requested action is complete and the output is available.
2. If we still want to use a progress indicator animation, we might consider implementing one of the more elegant animations prototyped by our designers:
   Sunder Animations.zip.

Bug

Description

Whenever Sunder opens a file picker, it defaults to opening in the same directory as the Sunder code. A more common UX convention is for file pickers to remember the last location where they performed an operation (e.g. opened or saved a file), and default to that last location when they are opened again. This creates a helpful and convenient UX for common tasks in Sunder (such as saving a bunch of shares in the same, or neighboring, locations).

Steps to Reproduce

I have only observed this on macOS and have not tested this on Linux. I am not sure if Linux would have the same or different default behavior.

1. Open Sunder
2. Split a secret into shards (value of secret and parameters are irrelevant)
3. On the Distribute Secret Shards page, click the Save button next to a shard.
4. Notice that the default location (the Where: field on macOS) to save the shard is the Sunder code directory.
5. Change Where: to another location, e.g. Desktop.
6. Save the shard.
7. Click the Save button next to a different shard.

Expected Behavior

The file picker's location defaults to the last location where it performed an action, e.g. Desktop, since you saved the first shard there.

Actual Behavior

The file picker's location defaults to the Sunder code directory again.

Comments

This is a fairly subtle UX bug, but I think fixing it would make a big difference, particularly if the user is saving a lot of shards; therefore, I'm prioritizing this for 1.0.

Feature Request

Description

When the user is interacting with the "Create Secret Shards" view, input validation is being performed constantly and validation errors are shown as soon as the user enters an invalid parameter. This feels unfriendly to me, especially when it happens before all of the parameters have been entered (voice in my head says: "hold on, I'm not done yet!").

For example:

1. Open Sunder.
2. From the starting view, click Sunder It.
3. In the Enter your Secret area, click once in the textarea to focus it.
4. You change your mind: you want to load the secret from a file instead. In the Enter your Secret area, click the dropdown to change As text to From file.
5. A Secret is required input validation error message is immediately shown.

I propose we either:

• Defer the initial validation check until the user clicks Create Secret Shares for the first time, then start doing the continuous input validation.
• Only perform a validation check when the user clicks Create Secret Shares.