Skip to content

Latest commit

 

History

History
144 lines (90 loc) · 11.4 KB

CHANGELOG.md

File metadata and controls

144 lines (90 loc) · 11.4 KB
Raw

IronWeb SDK Changelog

The IronWeb SDK NPM releases follow standard Semantic Versioning style versions. The versions of the SDK are in the form major.minor.patch.

Note: The patch versions of the IronWeb SDK will not be sequential and might jump by multiple numbers between sequential releases.

v4.2.5

  • add support for browsers with privacy settings that require use of the Storage Access API

v4.2.1

  • added deleteDeviceByPublicSigningKey to the SDK. This allows someone with access to a JWT for a user to delete a device for that user without initializing the SDK (and creating a new browser device).

v4.1.1

  • added listDevices() to the User SDK. This lists all devices for the currently logged in user.
  • added deleteDevice(deviceId?: number) to the User SDK. This deletes a user's device by ID, and if passed no ID deletes the current device and clears its keys from browser storage.
  • deprecated deauthorizeDevice() in favor of deleteDevice().
  • added deleteDeviceByPublicSigningKey(publicSigningKey: Base64String) to the User SDK. This deletes a user's device by its public signing key.

v4.0.19

  • deprecated encryptToStore, decryptFromStore, and updateEncryptedDataInStore methods
  • updated all dependencies

v4.0.15

  • Support for MS Edge Legacy (version <= 44) has been removed. All currently supported versions of MS Edge should work.

  • Fixed a bug where local state in browser wouldn't be updated after a changePasscode call.

v3.5.3

Public key caching for groups and users. There are no API impacting changes in this release. Internal calls to list groups or users will now go through a public key cache, reducing the number of roundtrips to IronCore services.

v3.4.1

Encrypted search index feature. Adds methods to create a blind encrypted search index that allows for searching over encrypted data.

  • New namespace, IronWeb.search, that adds methods to create and initialize a blind search index and then methods for tokenizing data and search queries.
    • A new blind search index can be created via the IronWeb.search.createBlindSearchIndex(groupId: string): BlindIndex to create a new search index that is accessible by everyone in the provided group.
    • Initialize an existing search index via IronWeb.search.initializeBlindSearchIndex(index: BlindIndex): InitializedSearchIndex which takes the result of the createBlindSearchIndex call and returns an InitializedSearchIndex which contains methods for tokenizing data
    • The tokenizeData method on InitializedSearchIndex creates an index for the provided plaintext data. The resulting Uint32Array is the index of all the trigrams in the provided plaintext.
    • The tokenizeQuery method on InitializedSearchIndex tokenizes the provided search query into trigrams and returns a Uint32Array which can be compared against the result of tokenizeData to find matches.
  • Removed need for peerDependency of es6-promise as Promise polyfill is no longer needed for modern browsers.

v3.3.3

Group Key Rotation feature. Groups can now be created with a needsRotation flag. This flag denotes that the group should have its private key rotated when the owner of the group "takes control" of the group. The main use case for this is a workflow that requires the group to be generated prior to the group owner logging in for the first time. In this situation, the group's cryptographic keys can be generated by a third party, like a server process, and then the group owner can take control of their group by rotating the group's private key at a later point.

  • Group create options object now supports a handful of new fields
    • needsRotation: boolean If true denotes that upon creation of the group it should be flagged as needing its private key rotated.
    • memberList: Array<string> A list of user IDs to add as members of this group at creation time.
    • adminList: Array<string> A list of user IDs to add as admins of this group at creation time.
    • ownerUserId: string By default the user who creates a group becomes the groups initial admin and thereby owner. When providing this option the owner of the group can be specified as another user. This can be helpful when a group is created by a third party, like a server process, but that third party shouldn't be an admin nor member of the group. This feature is usually used in conjunction with the group private key rotation feature.
  • Add a new method on the group namespace for rotating a group's private key, as described above. The sdk.group.rotatePrivateKey(groupId: string) can be used to perform this task. Note that this operation can take a while to complete if the group being rotated has a large number of administrators. This method can only be called by administrators of the group.
  • Getting a group via sdk.group.get(groupId) will now return whether the group is flagged for rotation. This field will only be returned for administrators of the group.
  • The response from calling sdk.initialize() now includes a groupsNeedingRotation which is an array of groups that the current user is an administrator of that are flagged as needing rotation.
  • The response from sdk.createNewDeviceKeys() now includes the ID of the device created, its optional name, and the time it was created.

v3.2.1

User Key Rotation feature. Users can now be created with a needsRotation flag. This flag can be used to mark that the private key for this user should be rotated when the user "takes control" of their keys. The main use case for this is a workflow that requires the users to be generated prior to them logging in for the first time. In this situation, a user's cryptographic identity can be generated by a third party, like a server process, and then the user can take control of their keys by subsequently rotating the private key after their first login. A users key can be rotated using the sdk.user.rotateMasterKey(password) method.

  • Added an optional options object to the createNewUser method. Currently takes a single optional needsRotation key which will mark the user as needing rotation upon creation.
  • Return structure after calling sdk.initialize() now includes a needsRotation boolean that denotes if the currently authenticated user has been flagged as needing rotation. If a user is marked as needing rotation, it should occur immediately after the initialize() Promise has resolved.
  • Added a new method to the User namespace, sdk.user.rotationMasterKey(password). Requires the users password to unlock their current master private key. Calls to rotate the users key can be done at any time, regardless of whether the users record is curretly flagged for rotation.

SDK

v3.0.7

Other Changes

  • Fix bug where the FrameUtils.documentToByteParts would error if the document had a byteOffset which was non-zero.

v3.0.6

Other Changes

  • Fix bug where the DocumentSDK.getDocumentIdFromBytes would error if the documentData had a byteOffset which was non-zero.

v3.0.5

Breaking Changes

  • Removed support for browsers which don't support WebAssembly. This primarily means that support for IE has been removed. Performance in IE was always bad enough that it made the library nearly unusable. In addition, because of support for WebCrypto within IE it was less secure than other browsers.

Other Changes

  • Added a top level createNewUser method which can be called prior to SDK initialization. This method takes a callback to a valid JWT and the users escrow password as arguments. This method will create a new identity for the user ID specified in the JWT but it will not generate a new device key for that user.

  • Added a top level createNewDeviceKeys method which can be called prior to SDK initialization. This method takes a callback to a valid JWT and the users existing escrow password as arguments. This method will genreate a new set of device keys (encryption and signing) for the user ID specified in the JWT. The full key set will be returned once the Promise this method returns resolves.

  • Added a new document namespace sdk.document.advanced which allows encrypting/decrypting documents while also returning the encrypted document encryption keys (EDEK) instead of having them stored within the IronCore service. Currently only supports a method for decrypting unmanaged documents.

v2.0.1

Breaking Changes

  • Moved all DocumentSDK operations to deal with Uint8Array, we no longer assume base 64 strings.
    • Document.encrypt always returns data as Uint8Array.
    • Document.decrypt always accepts data as Uint8Array.
    • Document.getDocumentIDFromBytes expects data as Uint8Array.
    • Use IronWeb.codec utility functions for easy interop with base64 and utf8 strings.

v1.2.9

  • Fixed exported TypeScript types.
  • Upgraded version of RecryptJS (only used for non WebAssembly browsers) to consume Schnorr signing fixes.

v1.2.7

  • WebAssembly! The IronWeb SDK will use the Recrypt WASM module to greatly improve performance of most cryptographic operations. The WebAssembly module will automatically be used if the browser supports it (currently MSEdge, Chrome, Safari, and Firefox). No changes are required to consume this change. All these performance benefits are automatically applied in this new version.

v1.1.4

  • Added created and updated timestamps to all document and group methods which return details about the document/group. These timestamps are strings formatted in RFC3339 format which can be passed directly into the Date constructor (e.g. new Date(document.created)).

v1.1.2

  • Upgraded version of internal RecryptJS dependency.

v1.1.1

  • Added new IronWeb.group.update() method to update a group. Currently only supports updating the name to a new value or clearing the name.
  • Added new IronWeb.group.delete() method to delete a group. Group deletes are permanent and will cause all documents that are only encrypted to the group to no longer be decryptable. Use caution when calling this method.
  • Added restrictions for user, group, and document IDs. If any method is called with an ID that doesn't confirm to the ID requirements, that method will throw. IDs are now restricted to the following characters:
    • Any number (0-9)
    • Any uppercase or lowercase letter from a-z
    • The following special characters _.$#|@/:;=+'-
    • Be at most 100 characters long

v1.0.12

  • Updated version byte on the front of all encrypted documents to version two. Encrypted documents now contain the ID of the document embedded as a header of the document.
  • Added a new document method IronWeb.document.getDocumentIDFromBytes() which takes an encrypted document and attempts to parse the header to retrieve the document ID. If the document was an older, version 1 document, null will be returned.

v1.0.11

  • Added version byte to the front of all encrypted documents. This byte will represent an all-encompassing flag to denote the details about how documents are symmetrically encrypted. This will allow for backward compatible future modification if changes are made to how documents are symmetrically encrypted.
  • Updated all dependencies to the latest version

v1.0.5

Initial release