Build tooling to review Cargo.lock bumps #20

Open
opened 2024-01-18 21:59:55 +00:00 by ryan · 2 comments
Owner

Given two version of Cargo.lock (base commit, head commit), find out which new versions of packages are added, and run the following steps:

  • Download a tarball of the old version
  • Verify tarball using Lockfile
  • Initialize Git repository, make a commit, based on the existing tarball
  • Download a tarball of the new version
  • Verify tarball using Lockfile
  • Replace working directory with contents of tarball
  • Add all files to Git staging area
  • Run git difftool HEAD
Given two version of Cargo.lock (base commit, head commit), find out which new versions of packages are added, and run the following steps: * Download a tarball of the old version * Verify tarball using Lockfile * Initialize Git repository, make a commit, based on the existing tarball * Download a tarball of the new version * Verify tarball using Lockfile * Replace working directory with contents of tarball * Add all files to Git staging area * Run `git difftool HEAD`
Author
Owner

Can use cargo fetch. Implemented via make review.

Can use `cargo fetch`. Implemented via `make review`.
ryan closed this issue 2024-01-19 00:16:26 +00:00
Author
Owner

Reopening because I'm not happy with this. I want a tool that can be used to audit things before or while cargo update is being run, something that allows more interactivity. The ideal workflow would be:

  1. The total list of potential upgrades is acquired
  2. For each potential upgrade, determine:
    • The impact of the upgrade
    • The amount of dependencies added/forked
  3. If the dependency is approved, run a system similar to make review for each crate to be affected by this change.

make review can still be used by anyone who wishes to review all previously upgraded crates at once, but tooling must exist to streamline the process of choosing what upgrades to include.

Reopening because I'm not happy with this. I want a tool that can be used to audit things before or while `cargo update` is being run, something that allows more interactivity. The ideal workflow would be: 1. The total list of potential upgrades is acquired 2. For each potential upgrade, determine: * The impact of the upgrade * The amount of dependencies added/forked 3. If the dependency is approved, run a system similar to `make review` for each crate to be affected by this change. `make review` can still be used by anyone who wishes to review all previously upgraded crates at once, but tooling must exist to streamline the process of choosing what upgrades to include.
ryan reopened this issue 2024-01-26 08:41:07 +00:00
lrvick added this to the Custody Framework project 2024-11-25 10:21:10 +00:00
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/keyfork#20
No description provided.