vendorCargoRegistries: avoid escaping shell args

[llakala]

Motivation

Using the evaluation profiler showed me that this was a surprisingly hot call. I believe all of these uses are unnecessary.

The result of vendorCrate p should just be a store path, and the result of escapeShellArg name is known info, since there's only one name (crates.io). escapeShellArg "${p.name}-${p.version}" could technically be an issue, so if it's preferred, I can drop this one - but it would require a horrible name and version to trigger.

Checklist

• added tests to verify new behavior
• added an example template or updated an existing one
• updated docs/API.md (or general documentation) with changes
• updated CHANGELOG.md

[ipetkov]

1. vendorCrate p should be a store path yes, but can store paths contain spaces? If not the /nix/store/<hash>-<name> path, what about subdirectories? Technically the caller can override the download derivation with whatever they want. Maybe its their own fault if they do a shell injection, but escaping here is a foolproof way of dealing with quoting
2. I'd strongly prefer we keep escaping ${p.name}-${p.version}. There's probably a number of different ways to set them to something potentially evil

[llakala]

1. How about we just always quote? ln -s '${vendorCrate }'. Depends on whether subdirectories can contain '.
2. I can live with that. Although it would need single quotes for escapeShellArg to do anything, which your example doesn't use.

[ipetkov]

If overrideVendorCargoPackage returns a quoted path quoting it again might end up "undoing" the quotes

[ipetkov]

The original motivation for escaping name here was to avoid potential quoting issues, though its probably the wrong tool for the job anyway. I suppose these are directly controlled by the caller (via whatever registries they have configured directly in the craneLib instantiation) so I'm okay with relaxing this