verification is sort of pointless, because:
The Cargo.toml file is parsed and reformatted by the packaging tool to normalize its contents.
Thus, the Cargo.toml file of the downloaded version never matches the Cargo.toml file that's actually used.
Unfortunately, there doesn't seem to be an easy way to check the equivalence of two Cargo.toml files,
except for recursively and deeply parsing through and comparing all the possibile keys and values of
the abstract key/value tree. This is a much bigger project than I'm prepared to figure out today.
As a hack, we compare to the Cargo.toml.orig file. Which is...kind of OK, but really, this opens us
up to attacks where someone just has to replace a version on a package or even just swap out an
entire package for a malicious one by just using package name re-assignment which is a thing that
the format supports. In other words, all this checking is kind of pointless because it's super-easy
to swap out key crates for whole other crates and have it go undetected.
- default SVD file is specified now as a constant at the top of xtask
- SVD files are now tracked to commit refs in the betrused-soc tree
this is so that we don't have to guess which crate rev corresponds
to which SVD rev -- we specify it explicitly with a feature flag.
Now that we have full JSON parsing inside xtask, actually parse the
assets API endpoint to determine the correct URL.
Signed-off-by: Sean Cross <sean@xobs.io>
Still not there....to get it reporting in a user-visible fashion
I'm realizing I'm going to have to build a dedicated facility in
Xous to track this because otherwise I have to trigger the
automatic rebuild of a "heavy" program that would naturally
encapsulate such information.
Maybe for now, though, at least over the serial port I can
get a somewhat relevant string???
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
these are secondary attack surfaces -- code that isn't directly
in the kernel, but involved in the manipulation, handling, grooming
and preparation of source and binary files
This makes `locales` its own package. As a result, the system will not
rebuild the locales unless necessary.
Additionally, the `generate-locales` command has been updated to simply
force a rebuild of this file in order to keep the previous behavior.
Signed-off-by: Sean Cross <sean@xobs.io>
