Skip to content

zallet migration passes allow_warnings as strict mode in first zcashd dump parser stage #444

@Zk-nd3r

Description

@Zk-nd3r

Summary

zallet documents the default --allow-warnings=false behavior for zcashd wallet migration as strict, but the first zcashd dump parser stage appears to pass that flag into a parameter with the opposite meaning.

In zallet/src/commands/migrate_zcashd_wallet.rs, the migration currently calls:

ZcashdDump::from_bdb_dump(&db_dump, self.allow_warnings)

The callee in zcash/zewif-zcashd is:

pub fn from_bdb_dump(berkeley_dump: &BDBDump, strict: bool) -> Result<Self>

and it skips unparsable database keys when strict == false.

That means the default allow_warnings=false is interpreted by this first parser stage as strict=false / non-strict. The later ZcashdParser::parse_dump(&zcashd_dump, !self.allow_warnings) call is strict by default, but it only sees records that survived the earlier stage.

Expected behavior

With default flags, malformed or unparsable zcashd dump keys should fail the migration rather than being skipped.

Actual behavior

The first parser stage can skip unparsable database keys under default flags because allow_warnings=false is passed directly as strict=false.

Suggested fix

Pass the inverted flag into from_bdb_dump:

ZcashdDump::from_bdb_dump(&db_dump, !self.allow_warnings)

It may also be worth aligning the naming across the call boundary, so both sides use either allow_warnings semantics or strict semantics consistently.

Suggested regression test

Add a migration fixture with one unparsable/corrupt BDB key and run the migration with default flags. The test should assert that migration fails rather than silently skipping that key.

References

  • zallet/src/commands/migrate_zcashd_wallet.rs: ZcashdDump::from_bdb_dump(&db_dump, self.allow_warnings)
  • zcash/zewif-zcashd/src/zcashd_dump.rs: from_bdb_dump(..., strict: bool) skips unparsable keys only when !strict

This is intended as a public migration-correctness bug report, not a security advisory.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions