CI: Add cargo-audit workflow

[tnull]

Run security audits against all three checked-in lock files using the official rustsec/audit-check action. Triggers on push, PRs, and daily via cron to catch newly published advisories.

Co-Authored-By: HAL 9000

[tnull]

Also bumped some dependencies, rest should be done in #556 or #536.

[luisschwab]

ACK 2e56f00

[luisschwab]

cc @satsfy

[satsfy]

Why is Cargo.lock part of the matrix?

[tcharding]

against all three checked-in lock files

Yeah there should only be two. Did I commit one in electrsd accidentally or something?

[tnull]

Ah, right, dropped it.

[tnull]

Actually, it might make sense to add a step to generate a clean-slate Cargo.lock for this and then have the audit job check it? Otherwise we could theoretically miss advisories that don't pertain to the specific versions checked-in via Cargo-{minimal, recent}.lock, but would still be present if users would just cargo build regularly?

[tnull]

Now added a generate-lockfile step in 52e3dad, so we don't just check our checked-in versions over and over again.

[tcharding]

As it stands no-one is ever going to look at the auction run (well I definitely won't remember to do it). Can we have the action raise an issue if there are warnings? Or is that going to be too noisy? I don't have a lot of experience with cargo audit. (We do this already in rust-bitcoin for mutation testing when zombies survive.)

[luisschwab]

The GitHub bot will usually open an issue when there is a new RUSTSEC (see bitcoindevkit/bdk#2178).

[tcharding]

Does that bot hit projects to use cargo audit?

[luisschwab]

Actually, I think we need to use the actions-rust-lang/audit action for it to open issues. On my personal repos I only use the bare cargo audit and it does not open any issues there.

This is bdk's audit job:

name: Audit

on:
  push:
    paths:
      # Run if workflow changes
      - '.github/workflows/audit.yml'
      # Run on changed dependencies
      - '**/Cargo.toml'
      - '**/Cargo.lock'
      # Run if the configuration file changes
      - '**/audit.toml'
  # Rerun periodically to pick up new advisories
  schedule:
    - cron: '0 0 * * *' # Nightly
  # Run manually
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - uses: actions/checkout@v6
        with:
          persist-credentials: false
      - uses: actions-rust-lang/audit@v1
        name: Audit Rust Dependencies

I could be talking out of my ass, I'm not certain about this.

[tcharding]

Sounds legit :)

[tnull]

As it stands no-one is ever going to look at the auction run (well I definitely won't remember to do it). Can we have the action raise an issue if there are warnings? Or is that going to be too noisy? I don't have a lot of experience with cargo audit. (We do this already in rust-bitcoin for mutation testing when zombies survive.)

This will already do this, hence the issues: write permissions. See for example LDK Node where we use it (https://github.com/lightningdevkit/ldk-node/blob/main/.github/workflows/audit.yml), example issue: lightningdevkit/ldk-node#836.

Actually, I think we need to use the actions-rust-lang/audit action for it to open issues. On my personal repos I only use the bare cargo audit and it does not open any issues there.

No, audit-check is definitely sufficient, but it will only open issues via the cron-scheduled jobs:

"The action does not raise issues when it is not triggered from a "cron" scheduled workflow." (see https://github.com/rustsec/audit-check#granular-permissions)

If we want to validate that it works as expected, we could split out the fixes / bump commits to a second PR and first ensure the job opens an issue for the advisories found. Should we do that?

[luisschwab]

@tcharding can you re-trigger the failing job?

[luisschwab]

ACK 52e3dad

[jamillambert]

ACK 52e3dad