serai/deny.toml

99 lines
2.4 KiB
TOML
Raw Normal View History

[advisories]
db-path = "~/.cargo/advisory-db"
db-urls = ["https://github.com/rustsec/advisory-db"]
vulnerability = "deny"
yanked = "deny"
notice = "warn"
unmaintained = "warn"
ignore = [
"RUSTSEC-2020-0071", # https://github.com/chronotope/chrono/issues/602
2023-01-13 22:44:20 +00:00
"RUSTSEC-2021-0139", # https://github.com/serai-dex/serai/228
"RUSTSEC-2022-0061", # https://github.com/serai-dex/serai/227
]
[licenses]
unlicensed = "deny"
allow = [
# Effective public domain
"CC0-1.0",
"Unlicense",
# Attribution required
"MIT",
2023-04-09 06:34:31 +00:00
"MITNFA",
"BSD-2-Clause",
"BSD-3-Clause",
"ISC",
"Unicode-DFS-2016",
"OpenSSL",
# Non-invasive copyleft
"MPL-2.0",
"Apache-2.0",
"Apache-2.0 WITH LLVM-exception",
"GPL-3.0 WITH Classpath-exception-2.0",
]
copyleft = "deny"
allow-osi-fsf-free = "neither"
default = "deny"
exceptions = [
{ allow = ["AGPL-3.0"], name = "serai-env" },
{ allow = ["AGPL-3.0"], name = "ethereum-serai" },
{ allow = ["AGPL-3.0"], name = "serai-message-queue" },
{ allow = ["AGPL-3.0"], name = "serai-processor-messages" },
{ allow = ["AGPL-3.0"], name = "serai-processor" },
{ allow = ["AGPL-3.0"], name = "tributary-chain" },
{ allow = ["AGPL-3.0"], name = "serai-coordinator" },
2023-04-11 13:21:35 +00:00
{ allow = ["AGPL-3.0"], name = "serai-tokens-pallet" },
Tokens pallet (#243) * Use Monero-compatible additional TX keys This still sends a fingerprinting flare up if you send to a subaddress which needs to be fixed. Despite that, Monero no should no longer fail to scan TXs from monero-serai regarding additional keys. Previously it failed becuase we supplied one key as THE key, and n-1 as additional. Monero expects n for additional. This does correctly select when to use THE key versus when to use the additional key when sending. That removes the ability for recipients to fingerprint monero-serai by receiving to a standard address yet needing to use an additional key. * Add tokens_primitives Moves OutInstruction from in-instructions. Turns Destination into OutInstruction. * Correct in-instructions DispatchClass * Add initial tokens pallet * Don't allow pallet addresses to equal identity * Add support for InInstruction::transfer Requires a cargo update due to modifications made to serai-dex/substrate. Successfully mints a token to a SeraiAddress. * Bind InInstructions to an amount * Add a call filter to the runtime Prevents worrying about calls to the assets pallet/generally tightens things up. * Restore Destination It was meged into OutInstruction, yet it didn't make sense for OutInstruction to contain a SeraiAddress. Also deletes the excessively dated Scenarios doc. * Split PublicKey/SeraiAddress Lets us define a custom Display/ToString for SeraiAddress. Also resolves an oddity where PublicKey would be encoded as String, not [u8; 32]. * Test burning tokens/retrieving OutInstructions Modularizes processor_coinUpdates into a shared testing utility. * Misc lint * Don't use PolkadotExtrinsicParams
2023-01-28 06:47:13 +00:00
{ allow = ["AGPL-3.0"], name = "serai-in-instructions-pallet" },
Initial In Instructions pallet and Serai client lib (#233) * Initial work on an In Inherents pallet * Add an event for when a batch is executed * Add a dummy provider for InInstructions * Add in-instructions to the node * Add the Serai runtime API to the processor * Move processor tests around * Build a subxt Client around Serai * Successfully get Batch events from Serai Renamed processor/substrate to processor/serai. * Much more robust InInstruction pallet * Implement the workaround from https://github.com/paritytech/subxt/issues/602 * Initial prototype of processor generated InInstructions * Correct PendingCoins data flow for InInstructions * Minor lint to in-instructions * Remove the global Serai connection for a partial re-impl * Correct ID handling of the processor test * Workaround the delay in the subscription * Make an unwrap an if let Some, remove old comments * Lint the processor toml * Rebase and update * Move substrate/in-instructions to substrate/in-instructions/pallet * Start an in-instructions primitives lib * Properly update processor to subxt 0.24 Also corrects failures from the rebase. * in-instructions cargo update * Implement IsFatalError * is_inherent -> true * Rename in-instructions crates and misc cleanup * Update documentation * cargo update * Misc update fixes * Replace height with block_number * Update processor src to latest subxt * Correct pipeline for InInstructions testing * Remove runtime::AccountId for serai_primitives::NativeAddress * Rewrite the in-instructions pallet Complete with respect to the currently written docs. Drops the custom serializer for just using SCALE. Makes slight tweaks as relevant. * Move instructions' InherentDataProvider to a client crate * Correct doc gen * Add serde to in-instructions-primitives * Add in-instructions-primitives to pallet * Heights -> BlockNumbers * Get batch pub test loop working * Update in instructions pallet terminology Removes the ambiguous Coin for Update. Removes pending/artificial latency for furture client work. Also moves to using serai_primitives::Coin. * Add a BlockNumber primitive * Belated cargo fmt * Further document why DifferentBatch isn't fatal * Correct processor sleeps * Remove metadata at compile time, add test framework for Serai nodes * Remove manual RPC client * Simplify update test * Improve re-exporting behavior of serai-runtime It now re-exports all pallets underneath it. * Add a function to get storage values to the Serai RPC * Update substrate/ to latest substrate * Create a dedicated crate for the Serai RPC * Remove unused dependencies in substrate/ * Remove unused dependencies in coins/ Out of scope for this branch, just minor and path of least resistance. * Use substrate/serai/client for the Serai RPC lib It's a bit out of place, since these client folders are intended for the node to access pallets and so on. This is for end-users to access Serai as a whole. In that sense, it made more sense as a top level folder, yet that also felt out of place. * Move InInstructions test to serai-client for now * Final cleanup * Update deny.toml * Cargo.lock update from merging develop * Update nightly Attempt to work around the current CI failure, which is a Rust ICE. We previously didn't upgrade due to clippy 10134, yet that's been reverted. * clippy * clippy * fmt * NativeAddress -> SeraiAddress * Sec fix on non-provided updates and doc fixes * Add Serai as a Coin Necessary in order to swap to Serai. * Add a BlockHash type, used for batch IDs * Remove origin from InInstruction Makes InInstructionTarget. Adds RefundableInInstruction with origin. * Document storage items in in-instructions * Rename serai/client/tests/serai.rs to updates.rs It only tested publishing updates and their successful acceptance.
2023-01-20 16:00:18 +00:00
{ allow = ["AGPL-3.0"], name = "serai-validator-sets-pallet" },
{ allow = ["AGPL-3.0"], name = "serai-runtime" },
{ allow = ["AGPL-3.0"], name = "serai-node" },
Initial In Instructions pallet and Serai client lib (#233) * Initial work on an In Inherents pallet * Add an event for when a batch is executed * Add a dummy provider for InInstructions * Add in-instructions to the node * Add the Serai runtime API to the processor * Move processor tests around * Build a subxt Client around Serai * Successfully get Batch events from Serai Renamed processor/substrate to processor/serai. * Much more robust InInstruction pallet * Implement the workaround from https://github.com/paritytech/subxt/issues/602 * Initial prototype of processor generated InInstructions * Correct PendingCoins data flow for InInstructions * Minor lint to in-instructions * Remove the global Serai connection for a partial re-impl * Correct ID handling of the processor test * Workaround the delay in the subscription * Make an unwrap an if let Some, remove old comments * Lint the processor toml * Rebase and update * Move substrate/in-instructions to substrate/in-instructions/pallet * Start an in-instructions primitives lib * Properly update processor to subxt 0.24 Also corrects failures from the rebase. * in-instructions cargo update * Implement IsFatalError * is_inherent -> true * Rename in-instructions crates and misc cleanup * Update documentation * cargo update * Misc update fixes * Replace height with block_number * Update processor src to latest subxt * Correct pipeline for InInstructions testing * Remove runtime::AccountId for serai_primitives::NativeAddress * Rewrite the in-instructions pallet Complete with respect to the currently written docs. Drops the custom serializer for just using SCALE. Makes slight tweaks as relevant. * Move instructions' InherentDataProvider to a client crate * Correct doc gen * Add serde to in-instructions-primitives * Add in-instructions-primitives to pallet * Heights -> BlockNumbers * Get batch pub test loop working * Update in instructions pallet terminology Removes the ambiguous Coin for Update. Removes pending/artificial latency for furture client work. Also moves to using serai_primitives::Coin. * Add a BlockNumber primitive * Belated cargo fmt * Further document why DifferentBatch isn't fatal * Correct processor sleeps * Remove metadata at compile time, add test framework for Serai nodes * Remove manual RPC client * Simplify update test * Improve re-exporting behavior of serai-runtime It now re-exports all pallets underneath it. * Add a function to get storage values to the Serai RPC * Update substrate/ to latest substrate * Create a dedicated crate for the Serai RPC * Remove unused dependencies in substrate/ * Remove unused dependencies in coins/ Out of scope for this branch, just minor and path of least resistance. * Use substrate/serai/client for the Serai RPC lib It's a bit out of place, since these client folders are intended for the node to access pallets and so on. This is for end-users to access Serai as a whole. In that sense, it made more sense as a top level folder, yet that also felt out of place. * Move InInstructions test to serai-client for now * Final cleanup * Update deny.toml * Cargo.lock update from merging develop * Update nightly Attempt to work around the current CI failure, which is a Rust ICE. We previously didn't upgrade due to clippy 10134, yet that's been reverted. * clippy * clippy * fmt * NativeAddress -> SeraiAddress * Sec fix on non-provided updates and doc fixes * Add Serai as a Coin Necessary in order to swap to Serai. * Add a BlockHash type, used for batch IDs * Remove origin from InInstruction Makes InInstructionTarget. Adds RefundableInInstruction with origin. * Document storage items in in-instructions * Rename serai/client/tests/serai.rs to updates.rs It only tested publishing updates and their successful acceptance.
2023-01-20 16:00:18 +00:00
{ allow = ["AGPL-3.0"], name = "serai-client" },
2023-07-20 23:34:10 +00:00
{ allow = ["AGPL-3.0"], name = "serai-docker-tests" },
2023-07-20 23:34:10 +00:00
{ allow = ["AGPL-3.0"], name = "serai-message-queue-tests" },
{ allow = ["AGPL-3.0"], name = "serai-processor-tests" },
2023-08-01 23:00:48 +00:00
{ allow = ["AGPL-3.0"], name = "serai-coordinator-tests" },
{ allow = ["AGPL-3.0"], name = "serai-reproducible-runtime-tests" },
]
[[licenses.clarify]]
name = "ring"
version = "*"
expression = "MIT AND ISC AND OpenSSL"
license-files = [
{ path = "LICENSE", hash = 0xbd0eed23 }
]
[bans]
multiple-versions = "warn"
wildcards = "warn"
highlight = "all"
cargo update 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
2023-08-19 05:14:01 +00:00
deny = [ { name = "serde_derive", version = ">=1.0.172" } ]
[sources]
unknown-registry = "deny"
unknown-git = "deny"
allow-registry = ["https://github.com/rust-lang/crates.io-index"]
allow-git = [
2023-08-20 04:14:38 +00:00
"https://github.com/serai-dex/schnorrkel",
2023-04-09 06:34:31 +00:00
"https://github.com/serai-dex/substrate-bip39",
"https://github.com/serai-dex/substrate",
"https://github.com/monero-rs/base58-monero",
]