file_store: `Store::load` never terminates when a changeset entry decodes to zero bytes
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 84/100
Rechercherichtung
Beginne in crates/file_store/src/entry_iter.rs, insbesondere bei EntryIter::next und seiner Deserialisierungsschleife. Füge crates/file_store/tests/test_zero_width.rs hinzu oder verwende diese Datei und führe anschließend cargo test -p bdk_file_store --test test_zero_width aus. Als erledigt gilt die Aufgabe, wenn Store::load für einen Zero-Width-Changeset, auf den ein nachfolgendes Byte folgt, beendet wird und entweder den Changeset oder einen Fehler zurückgibt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Describe the bug
EntryIter::next (crates/file_store/src/entry_iter.rs) treats every successful deserialize_from as progress but never checks that the read advanced the file offset. For a changeset type whose bincode encoding is zero bytes (e.g. (), which implements Merge in bdk_core), any trailing byte after the magic bytes makes Store::dump decode the same position over and over, so Store::load never returns.
This affects loading a corrupted or hand-edited store file. #2258 appears to address this by framing each entry with a length prefix.
This issue was found by AI.
To Reproduce
Add crates/file_store/tests/test_zero_width.rs and run cargo test -p bdk_file_store --test test_zero_width:
use bdk_file_store::Store;
use std::time::Duration;
const MAGIC: &[u8] = b"bdk_test_magic";
#[test]
fn load_terminates_on_zero_width_changeset() {
let dir = tempfile::tempdir().unwrap();
let path = dir.path().join("db");
let mut bytes = MAGIC.to_vec();
bytes.push(0xff); // any trailing byte
std::fs::write(&path, &bytes).unwrap();
let (tx, rx) = std::sync::mpsc::channel();
std::thread::spawn(move || {
let result = Store::<()>::load(MAGIC, &path);
let _ = tx.send(result.is_ok());
});
// `()` decodes as zero bytes, so the file offset never advances and `load` never reaches EOF.
assert!(
rx.recv_timeout(Duration::from_secs(5)).is_ok(),
"load did not terminate"
);
}
Current output:
thread 'load_terminates_on_zero_width_changeset' panicked at crates/file_store/tests/test_zero_width.rs:20:5:
load did not terminate
Expected behavior
Loading a store file should always terminate, returning either the aggregated changeset or an error.
- Vorherrschende Sprache
- Rust
- Sterne
- 1.1k
- Forks
- 491
- Ø Merge
- 1 T. 5 Std.
- Gemergte PRs (30 T.)
- 1
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus bitcoindevkit/bdk
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
bitcoindevkit/bdk#2309 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
bitcoindevkit/bdk#2308 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
bitcoindevkit/bdk#2294 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
bitcoindevkit/bdk#2293 ·
-
documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
bitcoindevkit/bdk#2287 ·
Alle Issues in bitcoindevkit/bdk
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
gitbutlerapp/gitbutler#15998 · 1 Kommentar ·
-
bug triage:deciding
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
open-telemetry/otel-arrow#4132 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100