ssbc/chloride

chloride's Issues

Replace sodium-prebuilt with sodium-native

When I wanted to install scuttlebot, there was numerous problems to install sodium-prebuilt package on Darwin without automake and libtool.
Recommended solution from @mafintosh mafintosh/node-sodium-prebuilt#10 (comment) is to replace package for sodium-native

Thoughts?

chloride launches electron every time it's required

chloride launches electron if electron is installed globally.
(The module name of electron-prebuilt is renamed to electron. https://github.com/electron-userland/electron-prebuilt#installation )

npm i -g electron

This is because isElectron() requires electron to detect it.

function isElectron () {
  try {
    require('electron')
    return true
  } catch (_) { return false }
}

https://github.com/dominictarr/chloride/blob/ca6978b4a0eaa07e490f0df0993e22dd4391fed8/index.js#L7

A possible solution is to see process.versions.electron etc. instead.
https://github.com/cheton/is-electron/blob/master/index.js

node v12 support

Would love to see support for node v12.

Right now if I try to npm install, the libsodium compilation fails.

mind pushing code for 2.2.7 to github?

Thanks!

Dropping TweetNaCl

Issues like #3 make me wonder whether this module would be better as a wrapper around sodium-chloride and sodium-universal, dropping support for TweetNaCl entirely. Trying to bridge two disparate APIs into a consistent interface is hard work, and unless we feel very strongly about TweetNaCl vs Sodium-JavaScript I think this might be the right move.

Is Electron workaround still necessary?

There's an Electron workaround in index.js that was added in July 2016, which was before Electron 1.3 was released (Chrome 52, Node 6). Four years later Electron is on version 10.11, and I've tested all the way back to Electron 7 and I can't find the problem. Does anyone have more context on what platform the problem was happening on? The only context I have is 50dbe3b, but that doesn't tell us much.

If the underlying problem is gone, I'd love to remove the workaround, but I thought I should make an issue before making a PR.

wasm variant is being irregularly picked

In my app I'm using chloride and wish to use the web assembly variant (from sodium-browserify). One of the first things my backend code does is set the env var CHLORIDE_JS, and in runtime I verified with a console.log that this line is running:

https://github.com/dominictarr/chloride/blob/7593ece159a2d9952156d26e25c4eca4a77cffc0/index.js#L4

In other words ./browser.js is certainly being imported, which imports sodium-browserify.

However, later on the app, the sodium-browserify-tweetnacl functions are being called constantly (many times after startup), but we expect sodium-browserify to catch on instead. The log below was printed during runtime, showing that tweetnacl functions are being called constantly.

crypto_scalarmult (sodium-browserify-tweetnacl/index.js)
     at Object.exports.multibox_open_key (private-box/index.js)
     at Object.exports.unboxKey (ssb-keys/index.js)
     at Object.key (ssb-db/minimal.js)
     at unbox (ssb-db/minimal.js)
     at EventEmitter.db.unbox (ssb-db/minimal.js)
     at Array.unboxerMap (ssb-db/minimal.js)
     at chainMaps (ssb-db/minimal.js)
     at mapper inside get (flumedb/index.js)
     at get (flumelog-offset/inject.js)

I took a look at the implementation of sodium-browserify, and added console.logs here and there. The interesting thing is that the mutation to apply webassembly happens much before (4 seconds) the tweetnacl uses of crypto_scalarmult, see these timestamps:

21:51:02.804: mutating crypto_sign_verify_detached to use webassembly
21:51:02.804: mutating crypto_sign_detached to use webassembly
21:51:02.805: mutating crypto_sign to use webassembly
21:51:02.805: mutating crypto_sign_open to use webassembly
21:51:02.805: mutating crypto_sign_ed25519_pk_to_curve25519 to use webassembly
21:51:02.805: mutating crypto_sign_ed25519_sk_to_curve25519 to use webassembly
21:51:02.805: mutating crypto_scalarmult to use webassembly
21:51:02.805: mutating crypto_secretbox_easy to use webassembly
21:51:02.805: mutating crypto_secretbox_open_easy to use webassembly
21:51:02.805: mutating crypto_box_easy to use webassembly
21:51:02.805: mutating crypto_box_open_easy to use webassembly
21:51:02.805: mutating crypto_auth to use webassembly
21:51:02.805: mutating crypto_hash to use webassembly
21:51:06.746: low order
21:51:06.746: low order
21:51:06.746: low order
21:51:06.746: low order
21:51:06.746: low order
              (this repeats forever)

So my best guess so far is that the mutation of the exports is not propagating correctly, maybe because some consumer library is extracting functions from chloride (like var scalarmult = chloride.crypto_scalarmult) instead of using chloride methods directly (like chloride.crypto_scalarmult(sk,pk)).

Converting ed25519 does not throw in browser

Consider the following snippet:

var sodium = require('chloride')

// crypto_sign_SEEDBYTES is missing too

var seed = Buffer.alloc(sodium.crypto_sign_SEEDBYTES || 32).fill('bug')

var keypair = sodium.crypto_sign_seed_keypair(seed)

var box_pk = sodium.crypto_sign_ed25519_pk_to_curve25519(keypair.secretKey)

console.log(box_pk)

In node the above throws an error due to the input being too long (here the secretKey is mistakenly used) but in the browser it happily continues. I'm not sure where to report this? Should I ensure the input myself instead?

cannot support platform=android and arch=arm64

when run on platform=android and arch=arm64, occur following error, cloud support android platform?

< error loading sodium bindings: No native build was found for platform=android arch=arm64 runtime=node abi=83 uv=1 armv=8 libc=glibc node=14.15.0 webpack=true

What is the relationship of this project to paixaop/node-sodium?

Why is this other URL listed in package.json?

  "repository": {
    "type": "git",
    "url": "https://github.com/paixaop/node-sodium"
  },

Tests not currently passing

Was trying to hunt down an issue and found that chloride's tests are not currently passing in the main branch.

doesn't work in browser

moving ssbc/ssb-keys#57 to here

What doesn't work is node-gyp-build.

That is the error

ERROR in ./node_modules/node-gyp-build/index.js
Module not found: Error: Can't resolve 'fs' in '/projects/insta/instagram/node_modules/node-gyp-build'

As i investigated that angular doesn't support fs anymore, I wondered any way around?

/cc @helxsz