Binary cache upload optimization

[roberth]

Is your feature request related to a problem? Please describe.

Binary cache uploads can take longer than necessary.

Describe the solution you'd like

I'd like to avoid compressing the NAR before determining that it's already available in the cache.
This can be done by naming the NAR file after the uncompressed hash.
It has further benefits for the uploading implementation, which is that when the ValidPathInfo is already known (currently always the case), we can compress and upload simultaneously rather than sequentially, saving time even in the case where we do actually need to compress and upload.

Describe alternatives you've considered

Do we have a good reason to name the NAR file after its compressed hash? All I can think of is that it simplifies a possible integrity check, but that check can still be done by reading the narinfo files. In fact you probably want to read those anyway so you can garbage collect any incomplete uploads that didn't make it to the narinfo upload step.

Additional context

• Somewhat off-topic comment for Get rid of Hash::dummy from BinaryCacheStore #3935 discussing how it relates to a possible Store interface refactoring

[zimbatm]

Assuming a compromised cache, uncompressing before verification also has the potential of including zip-bomb equivalents that explode disk usage. I just wanted to reply to the challenge and don't think that it's a significant-enough threat to prevent this change :D

[roberth]

@zimbatm that's an interesting thought though!

Assuming a compromised cache

Normally I'd say you have bigger problems in that case, but perhaps it's useful to have an untrusted cache for content-addressable stuff like sources. So that would be a cache where you don't configure a public key and rely on CA hashes for verification.

But even then, before unpacking we will have queried the narinfo, telling us the size, that we can then use to abort decompression if necessary. Or of course even earlier if we decide that the recorded size is too big in the first place.

Currently Nix doesn't seem to have any protection against large NARs, so it's kind of an orthogonal issue.

[Ericson2314]

Hehe I hadn't heard about zip bombs, how fun! I think the risk is less for us because we are compressing whole archives rather than individual files? When we decompress, we can just bail out if it exceeds the nar size also specified in the narinfo file.

[zimbatm]

Oops, I didn't mean to start a thread, please ignore my comment :D

I think that this issue is a good idea.

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I closed this issue due to inactivity. → More info

[roberth]

Perhaps of interest to @zhaofengli, author of attic.