This is of general interest for anyone programming in Rust.
It highlights the extreme vulnerability of Rust’s dependence on crates.io as a single point of failure, and as a system easily susceptible to supply chain interference.
I’m posting here as a reply to the comments about packaging Rust dependencies in Debian, because the article explains how to use those packages to mitigate the risks of depending on crates.io alone.
I suggest that these measures, as well as others mentioned in the article would be wise to look into for Safe Network, because the failure of an outage of crates.io risks bringing development to a halt. Cc @chriso
@happybeing In preparation for the next testnet I thought I’d update my Pi. Even after running:-
rustup default stable
rustup update
I’m getting this:-
Compiling vdash v0.14.2
error[E0283]: type annotations needed
--> /home/safe/.cargo/registry/src/index.crates.io-6f17d22bba15001f/vdash-0.14.2/src/bin/../custom/ui_node.rs:426:4
|
426 | .constraints(constraints.as_ref())
| ^^^^^^^^^^^ ------ type must be known at this point
| |
| cannot infer type of the type parameter `C` declared on the method `constraints`
|
= note: multiple `impl`s satisfying `Vec<Constraint>: AsRef<_>` found in the `alloc` crate:
- impl<T, A> AsRef<Vec<T, A>> for Vec<T, A>
where A: Allocator;
- impl<T, A> AsRef<[T]> for Vec<T, A>
where A: Allocator;
help: consider specifying the generic argument
|
426 | .constraints::<&T>(constraints.as_ref())
| ++++++
For more information about this error, try `rustc --explain E0283`.
error: could not compile `vdash` (bin "vdash") due to previous error
error: failed to compile `vdash v0.14.2`, intermediate artifacts can be found at `/tmp/cargo-install36NhtM`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
NOTE: you may see error messages when vdash starts up but you can ignore them. I’ll clean that up later!
This update means you can stop vdash at any point and re-start it and it will both get started much quicker and more importantly, not lose any statistics due to logfile rotation. Providing you don’t wait too long to restart vdash that is. If a logfile is rotated after a checkpoint, you would lose any cumulative data (e.g. PUTS, GETS, ERRORS) and timeline data in slots that fall between the checkpoint and the end of the rotated logfile, so still not much.
Beware, I have not done much testing but am releasing in case those sneaks start a testnet while I’m travelling…
I had expected this feature to take me weeks to implement but it has taken only a few days due largely to the amazing Rust ecosystem. Even as a first time user of the serialisation library serde I have been able to save and load a complex set of structs and values, including hashmaps, vectors and many other types with minimal effort by using a few macros. Most of the work has been in application logic which was fairly straightforward, along with some refactoring to accommodate that.
This may be down to me starting these local nodes on my own LANnet with a script that includes a sleep 10 in the loop. I stopped and restarted vdash twice in the 30 x 10 secs it took for the script to complete.
vdash v0.15.3 fixes a few things including one serious bug in the new checkpoints feature which I’m afraid means you can’t reload older checkpoints with this new version.
So best only update for the next testnet or when starting all nodes from scratch.