Skip to content

automatic lockfile updating and LLM review #273

Open

Description

@apoelstra

I'd like to pilot a new lockfile process here. Using this repo since it's widely-used but development is pretty slow, so hopefully it won't be too disruptive to try new stuff. Here's my proposal:

  1. We add a Cargo-minimal.lock alongside Cargo-recent.lock which is checked to actually match the minimum dependencies. cargo-rbmt has some facility for checking this; we should take a look at what rust-bitcoin does.
  2. For Cargo-recent.lock, we add a cronjob that (attempts to) update every dependency to the latest version, whenever a new version comes out. The PR should query a LLM agent to review the diff, providing a summary of changes (highlighting anything that "seems important" but wasn't mentioned in the CHANGELOG), a security audit, and a summary of how this crate might be affected.

If this works, we can try doing it on other repos. We may need to do something clever to share reviews so we're not re-reviewing the same dep on every repo that needs it. (But OTOH, I would guess that the cost is only a dollar or two per update, on average, and maybe there's value in doing multiple passes.)

We've had several abortive attempts to use humans to review each dependency update. In practice there's just way too much to handle, so instead we put off updating the lockfile til we're forced to. And then we just do it without looking at the diffs.

cc @Arvolear @psgreco -- I would appreciate a concept ACK. I'd also like Blockstream to sponsor the LLM usage here.

Activity

  1. delta1 commented on May 18, 2026

    @delta1
    Member

    Concept ACK, seems like a perfect usecase for AI since the diffs are normally way too large for thorough human review

  2. psgreco commented on May 18, 2026

    @psgreco
    Contributor

    Concept ACK, absolutely. WRT the "clever" review, we could do a simple MD file on a reviewed-crates repo, with every crate version and the date of review for every model.

  3. apoelstra commented on May 18, 2026

    @apoelstra
    MemberAuthor

    That's a great idea @psgreco. We should push these to a private reviewed-crates repo, mirror them to a public one if there are no problems (if there are, we may need to contact upstream maintainers privately), and then our cronjobs can query the public one to decide whether an updated version is "available".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions