Provide a way of detecting system library leakage#5259
Conversation
Break's wicketd's dependency on libnvme
Break's wicketd's dependency on libnvme
| let entry = entry.context("dirent")?; | ||
| if !entry.file_type()?.is_dir() { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
I think we should be building all of the binaries here -- cargo build --bins should do it. You can use the JSON metadata with --message-format json-render-diagnostics, then iterate over the built binaries to check for them.
I realize it's a significant chunk of work, but it is hopefully not a massive amount, and will make this check much more resilient.
There was a problem hiding this comment.
Oh, and I forgot to mention that cargo_metadata, which xtask already pulls in, has support for this: https://docs.rs/cargo_metadata/0.18.1/cargo_metadata/enum.Message.html#method.parse_stream
| } | ||
|
|
||
| fn cmd_verify_library() -> Result<()> { | ||
| let metadata = load_workspace()?; |
There was a problem hiding this comment.
Probably should have a check here to error out if this is run on a non-illumos platform. (I'd recommend a stub impl that just prints out an error like "error: this command is only supported on illumos")
sunshowers
left a comment
There was a problem hiding this comment.
putting it back in your queue!
sunshowers
left a comment
There was a problem hiding this comment.
Looks fantastic, thanks! Just a few minor comments.
| @@ -0,0 +1,144 @@ | |||
| use anyhow::{bail, Context, Result}; | |||
There was a problem hiding this comment.
MPL files require a license header up top -- could you add one here?
| fn verify_executable( | ||
| config: &XtaskConfig, | ||
| path: &Utf8Path, | ||
| errors: &mut HashMap<String, Vec<LibraryError>>, |
There was a problem hiding this comment.
Should be some kind of ordered map -- either a BTreeMap or an IndexMap (probably a BTreeMap)
| config_path.push(".cargo/xtask.toml"); | ||
| let config = read_xtask_toml(&config_path)?; | ||
|
|
||
| let mut command = Command::new("cargo") |
There was a problem hiding this comment.
This should use $CARGO if available (which it will be almost all of the time, since cargo is invoked via the rustup wrapper)
There was a problem hiding this comment.
I left it as an error if the env::var("CARGO") fails, but happy to fall back on just "cargo" if you like that better.
There was a problem hiding this comment.
Should definitely fall back to cargo, yeah. This pattern is pretty standard, and is expressed in bash as e.g. ${CARGO:-cargo}.
| let mut msg = String::new(); | ||
| use std::fmt::Write; | ||
| errors.iter().for_each(|(binary, errors)| { | ||
| write!(msg, "{binary}\n").unwrap(); |
There was a problem hiding this comment.
writeln!
Also you can use https://crates.io/crates/swrite to avoid the unwrap.
| # If we are running on illumos we want to verify that we are not requiring | ||
| # system libraries outside of specific binaries. If we encounter this situation | ||
| # we bail. | ||
| # NB: `cargo xtask verify-libraries` runs `cargo build --bins` to ensure it can |
There was a problem hiding this comment.
Doesn't look like it runs cargo build --bins? Just cargo build.
After #5158 was integrated @Rain noticed that attempting to run a build of
omdbin the switch zone suddenly stopped working and filed oxidecomputer/helios-omicron-brand#15. @jgallagher ended up fixing this by splitting out the sled-hardware types into their own crate in #5245.We decided it would be good if we added some sort of CI check to omicron to catch these library leakages earlier. This PR introduces that check and adds it to the helios build and test buildomat job. I have also added some notes to the readme for others that may end up adding a new library dependency.
Locally I modified the allow list so that it would produce errors, those errors end up looking like: