96583da3b9
Achieves three notable updates. 1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity. 2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of libp2p-identity). 3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to 1.0.171. The last one is the most important. The former two are niceties. serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a complete compromise of supply chain security. This is done in order to reduce compile times, yet also for the maintainer of serde (dtolnay) to leverage serde's position as the 8th most downloaded crate to attempt to force changes to the Rust build pipeline. While dtolnay's contributions to Rust are respectable, being behind syn, quote, and proc-macro2 (the top three crates by downloads), along with thiserror, anyhow, async-trait, and more (I believe also being part of the Rust project), they have unfortunately decided to refuse to listen to the community on this issue (or even engage with counter-commentary). Given their political agenda they seem to try to be accomplishing with force, I'd go as far as to call their actions terroristic (as they're using the threat of the binary blob as justification for cargo to ship 'proper' support for binary blobs). This is arguably representative of dtolnay's past work on watt. watt was a wasm interpreter to execute a pre-compiled proc macro. This would save the compile time of proc macros, yet sandbox it so a full binary did not have to be run. Unfortunately, watt (while decreasing compile times) fails to be a valid solution to supply chain security (without massive ecosystem changes). It never implemented reproducible builds for its wasm blobs, and a malicious wasm blob could still fundamentally compromise a project. The only solution for an end user to achieve a secure pipeline would be to locally build the project, verifying the blob aligns, yet doing so would negate all advantages of the blob. dtolnay also seems to be giving up their role as a FOSS maintainer given that serde no longer works in several environments. While FOSS maintainers are not required to never implement breaking changes, the version number is still 1.0. While FOSS maintainers are not required to follow semver, releasing a very notable breaking change *without a new version number* in an ecosystem which *does follow semver*, then refusing to acknowledge bugs as bugs with their work does meet my personal definition of "not actively maintaining their existing work". Maintenance would be to fix bugs, not introduce and ignore. For now, serde > 1.0.171 has been banned. In the future, we may host a fork without the blobs (yet with the patches). It may be necessary to ban all of dtolnay's maintained crates, if they continue to force their agenda as such, yet I hope this may be resolved within the next week or so. Sources: https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion This includes several reports of various workflows being broken. https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944 dtolnay commenting that security should be resolved via Rust toolchain edits, not via their own work being secure. This is why I say they're trying to leverage serde in a political game. https://github.com/serde-rs/serde/issues/2526 - Usage via git broken dtolnay explicitly asks the submitting user if they'd be willing to advocate for changes to Rust rather than actually fix the issue they created. This is further political arm wrestling. https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob https://github.com/dtolnay/watt - dtolnay's prior work on precompilation |
||
|---|---|---|
| .github | ||
| audits/Cypher Stack crypto March 2023 | ||
| coins | ||
| common | ||
| coordinator | ||
| crypto | ||
| docs | ||
| message-queue | ||
| orchestration | ||
| processor | ||
| substrate | ||
| tests | ||
| .gitattributes | ||
| .gitignore | ||
| .rustfmt.toml | ||
| AGPL-3.0 | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| LICENSE | ||
| README.md | ||
Serai
Serai is a new DEX, built from the ground up, initially planning on listing Bitcoin, Ethereum, DAI, and Monero, offering a liquidity-pool-based trading experience. Funds are stored in an economically secured threshold-multisig wallet.
Layout
-
audits: Audits for various parts of Serai. -
docs: Documentation on the Serai protocol. -
common: Crates containing utilities common to a variety of areas under Serai, none neatly fitting under another category. -
crypto: A series of composable cryptographic libraries built around theff/groupAPIs, achieving a variety of tasks. These range from generic infrastructure, to our IETF-compliant FROST implementation, to a DLEq proof as needed for Bitcoin-Monero atomic swaps. -
coins: Various coin libraries intended for usage in Serai yet also by the wider community. This means they will always support the functionality Serai needs, yet won't disadvantage other use cases when possible. -
message-queue: An ordered message server so services can talk to each other, even when the other is offline. -
processor: A generic chain processor to process data for Serai and process events from Serai, executing transactions as expected and needed. -
coordinator: A service to manage processors and communicate over a P2P network with other validators. -
substrate: Substrate crates used to instantiate the Serai network. -
orchestration: Dockerfiles and scripts to deploy a Serai node/test environment. -
tests: Tests for various crates. Generally,crate/src/testsis used, orcrate/tests, yet any tests requiring crates' binaries are placed here.
Security
Serai hosts a bug bounty program via Immunefi. For in-scope critical vulnerabilities, we will reward whitehats with up to $30,000.
Anything not in-scope should still be submitted through Immunefi, with rewards issued at the discretion of the Immunefi program managers.