Convert the existing Immutable data structure to Published Immutable data.

Note:

• The data type must move into the new data types crate
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API

• Convert the existing mutable data structure into unpublished sequenced mutable data.
• Implement validation of GET requests. Only owners and those in the permissions field with READ access should be able to fetch the data from the network.

Note:

• The data type must move into the new data types crate
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API

crate has been renamed to cipher

This crate has been renamed from stream-cipher to cipher.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/cipher>

See advisory page for additional details.

• Implement an AOdataInfo handle which would act as a structure used by SCL to map to AppendOnly Data in the data-types crate(once it goes live)
• This should facilitate is_sequenced and is_published flags to differentiate between the various AppendOnly Data types

Note:

• Common methods for all four types of the AppendOnly Data can be implemented here
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API

crate has been renamed to block-cipher

This crate has been renamed from block-cipher-trait to block-cipher.

The new repository location is at:

<https://github.com/RustCrypto/traits/tree/master/block-cipher>

See advisory page for additional details.

Change existing structures that use Mutable Data (Account, Access Container etc.) to use an appropriate data type.

This will most likely be Unpublished Sequenced MD - up for discussion.

Note:

• The data type must move into the new data types crate
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API

directories is unmaintained, use directoriess-next instead

The directories crate is not maintained any more;
use directories-next instead.

See advisory page for additional details.

• Include structure for this data type.
• GET requests for this data type should be validated. Only owners / clients with read access in the permissions list should be able to fetch the data.
• The data field is a BTreemap<Vec<u8>, Vec<u8>> - there is no version for a value mapped to a key. This validation is not required.
• However, when changes are made to the mutable data shell, version validation must be done

Questions:

• How will concurrent requests be handled without PARSEC?
  Even though this is done only for mock currently. What if 2 apps (locally) send mutation requests for the same key? I believe FIFO is implied. Asking for clarity.

Note:

• The data type must move into the new data types crate
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API

• Add structure for Unpublished Immutable data
• Implement name function that derives data address using the hash of the data and the owner.
• GET requests must be signed. Only the owner should be able to fetch the data from the network.

Questions:

• Will this require changes/additions in self_encryption?

Note:

• The data type must move into the new data types crate
• All RPCs are between clients and vaults
• Routing will include only a send(src, dest, payload) API
• Ownership of the data is non-transferrable

failure is officially deprecated/unmaintained

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

• anyhow
• eyre
• fehler
• snafu
• thiserror

See advisory page for additional details.

directories is unmaintained, use directoriess-next instead

The directories crate is not maintained any more;
use directories-next instead.

See advisory page for additional details.

Insufficient size checks in outgoing buffer in ws allows remote attacker to run the process out of memory

Affected versions of this crate did not properly check and cap the growth of the outgoing buffer.

This allows a remote attacker to take down the process by growing the buffer of their (single) connection until the process runs out of memory it can allocate and is killed.

The flaw was corrected in the parity-ws fork (>0.10.0) by disconnecting a client when the buffer runs full.

See advisory page for additional details.

term is looking for a new maintainer

The author of the term crate does not have time to maintain it and is looking
for a new maintainer.

Some maintained alternatives you can potentially switch to instead, depending
on your needs:

• crossterm
• termcolor
• yansi

See advisory page for additional details.

spin is no longer actively maintained

The author of the spin crate does not have time or interest to maintain it.

Consider lock_api (a subproject of
parking_lot) as an alternative which also supports no_std environments.

See advisory page for additional details.

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.