RUSTSEC-2026-0244 is assigned to two crates, so cargo-audit cannot load the database at all

[TAIPANBOX]

Since #3128 the advisory ID RUSTSEC-2026-0244 exists in two files:

crates/gettext-rs/RUSTSEC-2026-0244.md
crates/gettext-sys/RUSTSEC-2026-0244.md

That PR moved the advisory to gettext-sys but the copy under gettext-rs
was not removed, so both are present on main (currently 565436d8).

cargo-audit refuses to load the database when it sees a duplicate ID, which
means every cargo audit run fails, not only ones involving gettext:

    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
error: error loading advisory database: parse error: duplicate advisory ID: RUSTSEC-2026-0244

Reproducing

cargo audit

on any project. Or directly:

ls ~/.cargo/advisory-db/crates/gettext-{rs,sys}/RUSTSEC-2026-0244.md

Impact

This is a hard failure rather than a warning, so it blocks any CI step or
pre-push hook that runs cargo audit. We hit it on several repositories today;
in one of them the pre-push gate refuses the push entirely, with 22 of 23
checks passing and only the advisory step failing.

Fix

Delete crates/gettext-rs/RUSTSEC-2026-0244.md, keeping the gettext-sys one
that #3128 intended.

Happy to open that PR if it is useful.

[alex]

Hmmm, https://github.com/rustsec/advisory-db/tree/main/crates/gettext-sys doesn't seem to exist on main, so I'm a bit confused.

[AlastairHolmes]

The advisory is about gettext-rs, gettext-sys is the one to delete (it was a mistake in the advisories db, which is fixed now).

[alex]

Sure, but your post says that one also existed, which prevents the database from being loaded, and that's the thing I want to understand.

[AlastairHolmes]

If someone ran cargo-audit before the db was fixed, the tool will download the DB. Which is a set of folders, one for each crate that has one or more advisory. As this advisory was changed to a different crate. When cargo-audit downloads the updated DB, there will now be two folders one for the old wrong crate (gettext-sys) and the new correct crate (gettext-rs). After downloading the db, cargo-audit tries to load the db into memory, which is when it fails.

I'm not sure if cargo-audit should even be changed here. Just trying to help. This isnt my post.

[alex]

My apologies, didn't realize you weren't OP.

In any event: if the DB is busted and doesn't load, that's a high priority thing I want to fix ASAP. If the metadata is wrong on one advisory, we should fix that, but it's not urgent.

[djc]

Given that the PR the OP is pointing at did definitely contains a move rather than a copy, I guess the problem here is that the way cargo-audit updates the database can result in removed files being left around? Seems pretty strange but if someone has a chance to dig into that more, would be great.

In any case, it seems likely that only people who updated the database in the short window that the wrong advisory was there are affected, so hopefully that means most people won't run into this at all.