db0ceddf6b
The previous fetching logic had some pitfalls regarding its logic: * Fetched 'rad' references could end up not being verifiable and leaving the storage in a corrupt state * Forced pushes would be prohibited, since they would be rejected by the client side due to the refspecs being used. The new approach is to stage a fetch in 2 steps. The first step is to fetch the relevant `rad/id` and `rad/sigrefs` for verification. For all remotes that are verified, fetch all references listed in their respective `rad/sigrefs`, using the `+` marker in the refspec, allowing to update for any force pushes -- note that this becomes a safe operation since the `sigrefs` are signed by the remote that created them. To prevent unverifiable 'rad' references from polluting storage, all fetch negotiations are done in a staging repository set up in a temporary directory. All successful fetches are then transferred, using the 'file://' protocol, from the temporary directory into the radicle storage. Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| Dockerfile | ||