ironcorelabs / ironnode Goto Github PK

When someone hits our rate limit within Cloudflare, we should respond with a specific error code telling the user that they're being rate limited. Then consumers of the SDK can decision of this. When we hit the CF ratelimit they'll return us an HTTP error code of 429 which we should use to decision off of.

Once IronCoreLabs/recrypt-node-binding#107 merges update this library to support node 18 and release.

Add code to support version 2 of our document header which embeds the document ID and internal segment ID to the front of the document. The implementation will be as follows:

Byte 1: Version number, set to 2.
Byte 2,3: Encoded number which represents the size of the following header bytes, N
Bytes 4-N+3: utf-8 encoded JSON header which contains document ID (_did_) and internal segment ID (_sid_). fields
Bytes N+4-End: Encrypted document which includes AES IV and encrypted data.

Since we need to know what the document ID is at the time we do the encryption, we can also no longer rely on ironcore-id to generate document IDs for us if the caller doesn't provide one. So in addition to this we'll also generate the random document IDs on the client before we pass them to the server.

When we get a document that is version 1, we'll continue to do what we do today and just pull off the first byte. No changes will be made to the SDK to remove the need for providing a document ID as part of the various operations.

Once the neon binding native module works for Windows, change the package.json file to add support for Windows. Then test on Windows to make sure it works as advertised.

• Expose a SDK.device.list() method
• Expose a SDK.device.delete() method

Known high severity security vulnerability detected in handlebars < 4.0.14 defined in yarn.lock.

yarn.lock update suggested: handlebars ~> 4.0.14.

Known high severity security vulnerability detected in js-yaml < 3.13.1 defined in yarn.lock.

yarn.lock update suggested: js-yaml ~> 3.13.1.

Should be implemented in the same form as IronWeb.

One nice features to add is the ability to lookup users public keys by ID. This allows users to lookup to see if another user has setup their IronCore keys yet or not. Likely expose this as a SDK.user.getPublicKey method or similar.

group.update(options)

Options will be an object where currently the only supported field is name: string | null.

group.delete(groupID)

Delete the provided group given it's ID.

This would provide a nice way to determine if another user in the system has created their keys yet or not. Likely exposed as SDK.user.getPublicKey or similar.

Looks like arm64 is not a supported platform, would it be possible to add support for Apple silicon?
The readme says to open an issue to potentially get support added.
Would this be possible?

Here's an image for context:

Please let me know if there's some more you need from me.
Thanks

SDK.user.changePasscode(oldPasscode, newPasscode)

Expose fields from API now that they are provided for all document and group operations.

Add a new boolean flag (default true) on document.create which controls whether the author of the document will have the document be encrypted to them. The document.create call must share with at least one user/group, so if this option is false, the grantList must have at least one entry.

Also need to consume changes to how the document list, document get response structures can change if the author is requesting a document that they cannot decrypt.

Now that the API takes a device name as part of the device add call, we should let callers of the SDK provide a name for their device which will be useful for the response of the device list API call.

generateDeviceKeys(jwt: string, password: string, {options: {deviceName: string}})

We are going to standardize the DeviceContext/DeviceKeys JSON format across all SDKs. The proposed format (in Typescript) is:

{
    deviceId: number;
    accountId: string;
    segmentId: number;
    devicePrivateKey: Base64String;
    // “expanded private key” (both pub/priv)
    signingPrivateKey: Base64String; 
}

see: IronCoreLabs/ironoxide#25

We currently use the Recrypt.deriveSymmetricKey within IronNode to get a private key from a plaintext. While this works, it makes the code look weird so instead we should use the new Recrypt.hash256 method which is more generic.

Consume https://github.com/IronCoreLabs/ironcore-id/pull/853. ironweb will have this functionality before anything else, see it to try to have a consistent API.