pub fn trusted(url: &str, into: &Path) -> Result<Fetched, CliError>Expand description
Get the file at url to into with nothing to hold it against but the connection it came over.
This exists for exactly two files and they are the two documents at the top of
spec/cross-compile/13-distribution.md section 13.4’s chain. Microsoft’s channel manifest is the
root of that chain, so there is nothing above it that could name its hash, and Microsoft’s
installer manifest has a hash published for it in the channel that does not match the file served
at the URL the channel names in the same breath, which was measured rather than assumed and is
written down in that section. Every file named by the installer manifest goes through fetch
above with the hash the manifest gives for it, and those hashes are exact.
So the trust a hash would have carried is carried by the downloader’s connection to a Microsoft
host instead, which is a weaker claim than the one fetch makes and is why this is a second
function with its own name rather than a None somebody could pass to the first one by accident.
A file already at into is downloaded over rather than trusted, because with no hash there is no
way to ask whether the one sitting there is the file. Nothing is written under into until the
download finished, the same as above.
§Errors
The same three as fetch minus the hash: no downloader, a downloader that ran and failed, or
a filesystem that refused.