Current behaviour (RuDS): SHA-256 everywhere (crates/bds-core/src/util/checksum.rs, used by engine/post.rs publish + rebuild, engine/media.rs import + replace_media_file line ~376). On a bDS2-created DB: replace-file "identical content" no-op never triggers, checksum-based import duplicate/conflict classification mismatches, and rebuild writes checksums where bDS2 leaves nil.
Spec inconsistency to fix too:specs/media.allium rule ReplaceMediaFile says md5(...) but specs/schema.allium Post.checksum comment says "SHA-256 of content". Decide the canonical story per entity with the maintainer (likely: match bDS2 exactly for DB compat), then align code AND both spec files, and validate specs with the allium CLI.
Task: Implement the decided algorithms; audit all content_hash/file_hash call sites (post publish, post rebuild, media import/replace/rebuild, metadata_diff comparisons, wordpress_import classification, embedding content hashes are internal-only and may stay SHA-256). Add a compatibility test against a fixture checksum produced by bDS2.
Acceptance: Checksums written/compared match bDS2 for the same input bytes; specs consistent; cargo test --workspace green.
**Source:** Audit sections 1.5 and 4. Affects shared-database compatibility with bDS2-created projects.
**bDS2 behaviour:**
- Media: MD5, lower-hex — `../bDS2/lib/bds/media.ex:321` (`replace_media_file`), WXR import (`import_analysis.ex` md5). `import_media` stores a caller-supplied checksum.
- Posts: rebuild-from-files sets `checksum: nil` (`../bDS2/lib/bds/posts/rebuild_from_files.ex:162,226`).
**Current behaviour (RuDS):** SHA-256 everywhere (`crates/bds-core/src/util/checksum.rs`, used by engine/post.rs publish + rebuild, engine/media.rs import + `replace_media_file` line ~376). On a bDS2-created DB: replace-file "identical content" no-op never triggers, checksum-based import duplicate/conflict classification mismatches, and rebuild writes checksums where bDS2 leaves nil.
**Spec inconsistency to fix too:** `specs/media.allium` rule ReplaceMediaFile says `md5(...)` but `specs/schema.allium` Post.checksum comment says "SHA-256 of content". Decide the canonical story per entity with the maintainer (likely: match bDS2 exactly for DB compat), then align code AND both spec files, and validate specs with the `allium` CLI.
**Task:** Implement the decided algorithms; audit all `content_hash`/`file_hash` call sites (post publish, post rebuild, media import/replace/rebuild, metadata_diff comparisons, wordpress_import classification, embedding content hashes are internal-only and may stay SHA-256). Add a compatibility test against a fixture checksum produced by bDS2.
**Acceptance:** Checksums written/compared match bDS2 for the same input bytes; specs consistent; `cargo test --workspace` green.
hugo
added the bug label 2026-07-20 19:43:57 +00:00
Decision by maintainer: use the checksum as it is done by bDS2 and update the spec. bDS2 is the golden master and the checksum is not cryptographically significant, but only a change signal.
Decision by maintainer: use the checksum as it is done by bDS2 and update the spec. bDS2 is the golden master and the checksum is not cryptographically significant, but only a change signal.
Implemented in b3bf134. Media change signals now use bDS2-compatible lower-hex MD5 for WordPress analysis/import and replacement; ordinary media import preserves the bDS2 caller-supplied/null checksum semantics. Post and translation publishing preserve caller-supplied checksums, while filesystem rebuild/sync clears them. Generated-file and embedding hashes remain SHA-256. Updated the Allium schema/behavior specs and README, added the bDS2 fixture compatibility test plus import/replacement/publish/rebuild coverage, and removed one unused macOS dependency found by the dependency gate. Verified with allium check/analyse, cargo machete, cargo outdated, cargo build --workspace, and cargo test --workspace (all green; one intentional model-download test ignored).
Implemented in b3bf134. Media change signals now use bDS2-compatible lower-hex MD5 for WordPress analysis/import and replacement; ordinary media import preserves the bDS2 caller-supplied/null checksum semantics. Post and translation publishing preserve caller-supplied checksums, while filesystem rebuild/sync clears them. Generated-file and embedding hashes remain SHA-256. Updated the Allium schema/behavior specs and README, added the bDS2 fixture compatibility test plus import/replacement/publish/rebuild coverage, and removed one unused macOS dependency found by the dependency gate. Verified with allium check/analyse, cargo machete, cargo outdated, cargo build --workspace, and cargo test --workspace (all green; one intentional model-download test ignored).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Source: Audit sections 1.5 and 4. Affects shared-database compatibility with bDS2-created projects.
bDS2 behaviour:
../bDS2/lib/bds/media.ex:321(replace_media_file), WXR import (import_analysis.exmd5).import_mediastores a caller-supplied checksum.checksum: nil(../bDS2/lib/bds/posts/rebuild_from_files.ex:162,226).Current behaviour (RuDS): SHA-256 everywhere (
crates/bds-core/src/util/checksum.rs, used by engine/post.rs publish + rebuild, engine/media.rs import +replace_media_fileline ~376). On a bDS2-created DB: replace-file "identical content" no-op never triggers, checksum-based import duplicate/conflict classification mismatches, and rebuild writes checksums where bDS2 leaves nil.Spec inconsistency to fix too:
specs/media.alliumrule ReplaceMediaFile saysmd5(...)butspecs/schema.alliumPost.checksum comment says "SHA-256 of content". Decide the canonical story per entity with the maintainer (likely: match bDS2 exactly for DB compat), then align code AND both spec files, and validate specs with thealliumCLI.Task: Implement the decided algorithms; audit all
content_hash/file_hashcall sites (post publish, post rebuild, media import/replace/rebuild, metadata_diff comparisons, wordpress_import classification, embedding content hashes are internal-only and may stay SHA-256). Add a compatibility test against a fixture checksum produced by bDS2.Acceptance: Checksums written/compared match bDS2 for the same input bytes; specs consistent;
cargo test --workspacegreen.Decision by maintainer: use the checksum as it is done by bDS2 and update the spec. bDS2 is the golden master and the checksum is not cryptographically significant, but only a change signal.
Implemented in
b3bf134. Media change signals now use bDS2-compatible lower-hex MD5 for WordPress analysis/import and replacement; ordinary media import preserves the bDS2 caller-supplied/null checksum semantics. Post and translation publishing preserve caller-supplied checksums, while filesystem rebuild/sync clears them. Generated-file and embedding hashes remain SHA-256. Updated the Allium schema/behavior specs and README, added the bDS2 fixture compatibility test plus import/replacement/publish/rebuild coverage, and removed one unused macOS dependency found by the dependency gate. Verified with allium check/analyse, cargo machete, cargo outdated, cargo build --workspace, and cargo test --workspace (all green; one intentional model-download test ignored).