terreii / hoodie-plugin-store-crypto Goto Github PK

Add a .travis.yml file for running tests on Travis-CI.

Is your feature request related to a problem? Please describe.
In the future (#50) there will be more documents under hoodiePluginCryptoStore/. This could reduce the noise.

Describe the solution you'd like
Filter out all changes to hoodiePluginCryptoStore/-documents in the event-emitter.

Describe alternatives you've considered
Let the user handle the filtering.

Additional context
The user can, if they like to, listen to changes to those documents, if they subscribe to events with hoodie-store-client (or pouchdb directly).

Is your feature request related to a problem? Please describe.
The README.md has a lot of good stuff, but it's so long I can't get a grip on it all.

Describe the solution you'd like
Maybe not all of it needs to be in one file?

Describe alternatives you've considered
Maybe add a clickable table of contents near the top, so it can be found on first scroll.
Another option could be to extract and move some really long sections to the end of the README, and finish off the readme with a link back to the table of contents.

Additional context
Goal should be to capture visitor's attention and quickly show what this plugin does, and make sure the visitor wants to come back again.

Is your feature request related to a problem? Please describe.
The tests can become unclear/spaghetti-code.

Describe the solution you'd like
Now that node v6 is end-of-life, all maintained node versions support async functions!
If node v6 support is dropped from this package, than all tests can be refactored using async functions!

Describe alternatives you've considered
Continue using normal functions and Promises.

Additional context
This feature request should change:

• Drop node v6 support
  • remove it in .travis.yml.
  • modify engines in package.json to require node v8 or higher.
  • Add v12.
• rewrite tests to use async functions (+ arrow-functions)

This can be done in one or more pull requests.

Save the salt of the main password.

One possible location would be _design/cryptoStore/salt.

Is your feature request related to a problem? Please describe.
pouchdb-hoodie-api has a similar API to hoodie-client-store, but it can't be used!

Describe the solution you'd like
Test and find out what doesn't work and fix it.

Describe alternatives you've considered
Don't support pouchdb-hoodie-api.

Additional context
Fetching the newest versions of the salt-doc doesn't work.

After updating from Webpack 4 to 5.1.3. the following behavior occurs.

While building Webpack warns about the changed behavior about browser-polyfill.
The hoodie-plugin-store-crypto is affected by the “stream-browserify” polyfill and shows the following warning:

ERROR in ./node_modules/cipher-base/index.js 2:16-43
Module not found: Error: Can't resolve 'stream' in '...\node_modules\cipher-base'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
        - add a fallback 'resolve.fallback: { "stream": require.resolve("stream-browserify") }'
        - install 'stream-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
        resolve.fallback: { "stream": false }
 @ ./node_modules/browserify-aes/decrypter.js 5:16-38
 @ ./node_modules/browserify-aes/browser.js 2:16-38
 @ ./node_modules/hoodie-plugin-store-crypto/lib/helpers/encrypt-core.js 5:10-35
 @ ./node_modules/hoodie-plugin-store-crypto/lib/utils/create-password-check.js 7:14-48
 @ ./node_modules/hoodie-plugin-store-crypto/lib/helpers/change-password-and-update-docs.js 4:26-67
 @ ./node_modules/hoodie-plugin-store-crypto/lib/change-password.js 7:34-86
 @ ./node_modules/hoodie-plugin-store-crypto/lib/bind-functions.js 59:25-58
 @ ./node_modules/hoodie-plugin-store-crypto/index.js 5:20-51
 @...

So like the warning say I install stream-browserify (3.0.0) manually and add the fallback in the webpack file.

 module.exports = {
    ...
    resolve: {  
        ...
        fallback: {
            'stream': require.resolve('stream-browserify')
        }      
      
    },

Result: the webpack warning is gone but when I load my app the browser (chrome) shows the following error:
"default-encoding.js:3 Uncaught ReferenceError: process is not defined"

So I install process (0.11.10) manually and add it to the plugin section in the webpack file:

   new webpack.ProvidePlugin({
            process: 'process/browser',
        }),

After this the Browser brings the follwoing error when creating a new store.. (when loading an exisitng it fails alos but only shows an authentication error)
"ReferenceError: Buffer is not defined"

So I install buffer (5.6.0) and add it also to the plugin section in the webpack file:

 new webpack.ProvidePlugin({
            process: 'process/browser',
            Buffer: ['buffer', 'Buffer'],
        }),

For now it seems to work, but I'm not sure if my doing is correct or has any side effects.
Maybe all this missing dependencies, polyfill and config should be add to the hoodie-plugin-store-crypto directly?

Is your feature request related to a problem? Please describe.
When updating to v2 of this plugin and a service worker is used, there is a time where not every instance is updated.

Describe the solution you'd like
Release a v1 update that can also use hoodiePluginCryptoStore/salt as a salt object.

Describe alternatives you've considered
Let the plugin user read hoodiePluginCryptoStore/salt and pass it to setPassword(password, salt).

Additional context
This is related to #46.

Describe the solution you'd like
Add methods that let the user (here of the package) encrypt any JSON-Object they like and not have to store it.

Describe alternatives you've considered
The user add their own encryption.

Additional context
This could use the active key (and with withPassword any other) to encrypt an object.

hoodie.cryptoStore.encrypt({ value: 'something' }) // something like it
  .then(encrypted => {
    // use it
  })

There is still the question: where we get the aad (last argument on nativeCrypto.encrypt)

Split up the cryptoStore.setPassword() method into a firstSetup() and a unlock() methods.

• firstSetup should create a salt document and fail if one already exists.
• unlock should not create a salt doc. But if none exists, sync if online, and fail if still none exists.

Describe the bug
The tests that check the hoodie.updated property fail at random.

To Reproduce
Steps to reproduce the behavior:

1. Push a change to Github.
2. Wait for the test.

Expected behavior
Tests should only fail if there is an error.

Desktop (please complete the following information):

• OS: linux
• Browser -
• Version -

Hi @Terreii
in your new provided types declaration file #115, typescript (4.1.3) complaints about the following line:

When I change it to
declare const CryptoStoreConstructor: CryptoStoreConstructor;
it works.

System Info:
Webpack 5
Typescript 4.1.3

Describe the solution you'd like
Add an example app that uses most features.

Additional context
This example app should be easy to use and well documented.
It could be located in ./example.

Is your feature request related to a problem? Please describe.
If the user looses their password, there is no way to reset the crypto-password. So the user also looses all encrypted data!

Describe the solution you'd like

• Generate a reset-key on every password change.
• Save a document with the crypto-key encrypted with the reset-key.

Describe alternatives you've considered
-- none --

Additional context
This would be good to implement after #50, but could also be implemented earlier.

Explain and report in the readme about the crypto process.

This should include:

• which algorithm is used
• how the key is generated
• what is used as the inputs for the encryption of the documents
• how are the documents encrypted
• how to reimplement the encryption and decryption
• what will stay unencrypted (_id, _rev, _deleted and hoodie)

Hello
Has this package any other „build tools dependencies" and is it compatible with node v10.15.3?
On installation I get the following message:

node-gyp rebuild
gyp ERR! configure error
gyp ERR! stack Error: Can't find Python executable "C:... .windows-build-tools\python27\python.exe", you can set the PYTHON env variable.

(Got some similar messages when installing pouchdb and some people suggest to use an older node version. See also https://stackoverflow.com/questions/45473045/angular-pouchdb-error-cant-find-python-executable-python-you-can-set-the-py)

Thanks

Is your feature request related to a problem? Please describe.
On installation the native-crypto dependency raw-ecdsa fails to compile (it is a C++ node extension). While the failure doesn't matter (it is not used), it can tip off new users!

Describe the solution you'd like
Directly use browserify-aes and crypto.subtle.

Describe alternatives you've considered
Continue to use native-crypto, but add an info for that warning.

Additional context
How to use browserify-aes and crypto.subtle can be found in native-crypto `s encrypt and decrypt implementation.

Is your feature request related to a problem? Please describe.
If the plugin isn't unlocked, and the user tries to read or write a doc, the native.crypto error will be thrown.

Describe the solution you'd like
Check at the beginning of every method, if the crypto-key is set. Throw if it isn't.

Describe alternatives you've considered
Document the native.crypto error.

Additional context
It should be a pouchdb-error. Fail early.

Document the API of this plugin.

APIs

• cryptoStore (the main export)
• setPassword
• add
• find
• findAll
• findOrAdd
• update
• updateOrAdd
• updateAll
• remove
• removeAll
• withIdPrefix
• setPassword
• withPassword
• on
• off
• one

Is your feature request related to a problem? Please describe.
_design/ docs are special documents. Through them a CouchDB & PouchDB user can create their own indexes, validate updates, add filters and more. Those special functionality are stored under predefined special fields (views, and more) in a design doc. They must not be encrypted!

Currently if a _design/ doc is written using one this plugins methods, then the full design doc is encrypted by default. Making it useless.

Describe the solution you'd like
Don't encrypt those special design doc fields.

Describe alternatives you've considered
The user could also use cy_ignore and __cy_ignore for every design doc.

Additional context
It would be help full if there is a warning (console.warn) every time a design doc is updated/written to using this plugins methods.

📝 Where to make the change
In lib/encrypt.js add the special design doc fields to the docIgnore array. But only if it is a design doc.

Is your feature request related to a problem? Please describe.
Whenever the crypto-password is changed, all encrypted documents are re-encrypted!

Describe the solution you'd like
Generate a internal password on every password change (and the setup). And use this internal password to encrypt documents. The new internal password and all old ones can be stored in documents that are then encrypted in the users crypto-password.

Describe alternatives you've considered
The current implementation works fine but takes up much space on the server and over the network.

Additional context
The biggest problem lies in syncing. In the old implementation, the user could be asked for the old password and the old salt could be gathered from the salt-doc history.
Also any internal password would have to have an id (UUID from hoodie on add?). And every document that is encrypted with this password would also store that id.

Describe the bug
If an object/doc is added/updated/removed, then the original object is modified! Its _id, _rev, _deleted and hoodie object are removed!

To Reproduce
Steps to reproduce the behavior:

1. create an Object in a variable with an _id
2. save the object
3. inspect (console.log, ...) the original object
4. The original object now doesn't have an _id

Expected behavior
The original object should be unmodified

Screenshots

Desktop (please complete the following information):

• OS: Mac
• Browser firefox, chrome
• Version 61, 68

**Additional contex
In lib/encrypt.js the properties are deleted on the original file. It is better to move everything to new objects!

Document how to start and setup this plugin.

• after sign up
• unlock / after sign in
• how to change the password

Add and activate semantic-release.

Is your feature request related to a problem? Please describe.
The user can't specify keys that shouldn't be encrypted, but saved in the document.

Describe the solution you'd like
Add a special _unencrypted key, that contains an array of key-strings. Every key in it will be ignored. But the _unencrypted array will not be saved.

Describe alternatives you've considered

• Add a unencrypted array that will be saved along but behaves the same.
• The user could use #51 to encrypt data and save them in an object along the other keys.

Is your feature request related to a problem? Please describe.
At the time of writing, there is no method of storing an encrypted attachment to a document.

Describe the solution you'd like
Add a methods to add, read, update and remove attachments.

Describe alternatives you've considered
In combination with #51 users could encrypt an Buffer/Blob and save them using PouchDB exposed through hoodie.store.db.

Additional context
This would require the creation of new APIs. They should follow Hoodies dreamcode philosophy.

Refactor the store functions.

• Move common functions into a utils directory.
• Use more hoodiehq/hoodie-store-client functions.

Is your feature request related to a problem? Please describe.
Because every doc is encrypted and sometimes decrypted before updating it, it could be read or also updated without the change!

Describe the solution you'd like
Create a lock for doc-ids.

Describe alternatives you've considered
I have no idea.

Describe the bug
In CouchDB _design-docs have special roles. In version 1 they have been wrongly used! Signs v2 they are no longer written to, but still checked! This can cause bugs!

Expected behavior
Don't use _design* at all!

Ways to fix this bug
Remove checking, reading and deleting of _design/cryptoStore/salt in setup.js and unlock.js.

Describe the solution you'd like
Expose the lib/utils/is-encrypted-object.js function on the root API instance.

Additional context
The user (of the package) should be able the check if a document or JSON-Object is encrypted.

hoodie.cryptoStore.isEncrypted(obj) // -> Boolean (true if it is encrypted)

Describe the bug
After resign in all bulk doc methods (findAll(), updateAll() and removeAll()) throw an error, that the database is destroyed.

To Reproduce
Steps to reproduce the behavior:

1. Run hoodie and open http://localhost:8080/
2. Sign in
3. Sign out
4. Sign in again
5. tip in the browser console hoodie.cryptoStore.findAll().then(console.log, console.error)
6. See error

Expected behavior
findAll(), updateAll() and removeAll() should work after sign in.

Screenshots

Desktop (please complete the following information):

• OS: Mac
• Browser: Firefox
• Version: 63

Is your feature request related to a problem? Please describe.
When a user signs out, the key doesn't change!

Describe the solution you'd like
Add a function to lock the cryptoStore! This could also happen automatically on an sign out event from hoodie-account (or an hook.after).

Describe alternatives you've considered
This is a forgotten requirement!

Is your feature request related to a problem? Please describe.
When a user imports this plugin, they have to use the full hoodie-client or mock it using a temporary object.

import PouchDB from 'pouchdb'
import Store from '@hoodie/store-client'
import createCryptoStore from 'hoodie-plugin-store-crypto'

const store = new Store('name', {
  PouchDB,
  remote: 'remote'
})
const obj = {
  store: store
}
createCryptoStore(obj)
const cryptoStore = obj.cryptoStore
// now it can be used

Describe the solution you'd like
Change the default export so that it returns the cryptoStore, while hoodie/client.js doesn't.

Describe alternatives you've considered
Document the example.

Additional context
There also should be tests that check if multiple instances of the cryptoStore can exist at the same time.
This would also be a breaking change!

Is your feature request related to a problem? Please describe.
There is currently no check if the entered Password is correct! Only after the first encrypted doc is read it can be found out!

Describe the solution you'd like
Save a encrypted String in the salt-doc, that will be decrypted on unlock. If this fails, than the password is wrong. Maybe even a random generated string would do.

Describe alternatives you've considered
I didn't come up with one.

Additional context
This is probably best to implement after #26 is fixed.

Add a cryptoStore.changePassword(oldPassword, newPassword) method.

This should:

• Save the salt
• Update every encrypted object