deps(deps): bump serde_json from 1.0.150 to 1.0.151 - #57
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
🔒 Security Validation ReportGenerated: Mon Jul 20 10:58:06 UTC 2026 📊 Summary
✅ Overall Security Status: PASSEDAll critical security validations passed successfully. 🔍 DetailsThis report covers:
📋 Next Steps✅ Security validation passed. Code is ready for deployment. ✅ Security validation passed! This code meets all security requirements. |
🔍 Pull Request SummaryGenerated: Mon Jul 20 11:01:19 UTC 2026 📋 Validation Results
✅ Overall Status: PASSED🔒 Security Checklist
📝 Review NotesPlease review the security implications of this change carefully. ✅ Automated validation passed! This PR is ready for review. |
Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.150 to 1.0.151. - [Release notes](https://github.com/serde-rs/json/releases) - [Commits](serde-rs/json@v1.0.150...v1.0.151) --- updated-dependencies: - dependency-name: serde_json dependency-version: 1.0.151 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
58146c5 to
c4db6b8
Compare
|
Superseded by #68, which carries the same serde_json 1.0.150 -> 1.0.151 lockfile bump regenerated on current main. For the record, the red Test Matrix here was never caused by this bump. It failed on a flaky wall-clock assertion in lib-q-k12/tests/constant_time.rs at merge-base 123fc27 - before |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
🔍 Pull Request SummaryGenerated: Tue Jul 28 21:58:57 UTC 2026 📋 Validation Results
❌ Overall Status: FAILED🔒 Security Checklist
📝 Review NotesPlease review the security implications of this change carefully. ❌ Automated validation failed! Please address the issues above before merging. |
🔒 Security Validation ReportGenerated: Tue Jul 28 22:02:08 UTC 2026 📊 Summary
❌ Overall Security Status: FAILEDCritical security validations failed. Please review the issues above. 🔍 DetailsThis report covers:
📋 Next Steps❌ Security issues detected. Please address before deployment. ❌ Security validation failed! Please address security issues before merging. |
…lengths (#69) `test_customization_constant_time` measured `""` (0 bytes), `"short"` (5), `"medium_length_customization"` (27) and `[0xAA; 100]`, then asserted all four timings sit within one 60% band. That asserts something false by construction. The customization string is absorbed into the sponge, so its LENGTH changes how much work Kt128 does -- 100 bytes costs strictly more than 0, and crossing a block boundary costs an extra permutation. The assertion only ever held because hashing the 1000-byte message dominated the difference: a test that passes only while the effect it measures is drowned out is not measuring anything. It is also aimed at the wrong property. A customization string is a domain separator -- public input, not key material -- so a length-dependent timing is not a side channel even in principle. The property actually worth asserting is that timing does not depend on the customization's CONTENT at a fixed length, which is what would matter if a customization ever carried secret material. All four inputs are now exactly 32 bytes and differ only in their bytes (all-zero, all-one, alternating, counter-derived), so the comparison is meaningful and the systematic length bias is gone. What this does NOT claim. It does not explain the observed CI failure on PR #57 (serde_json 1.0.150 -> 1.0.151), and it should not be sold as the fix for it. That run failed on 2026-07-20 at merge-base 123fc27, which predates `min_time` (introduced 2026-07-25 in a515797) -- so it was still single-sample wall clock, and the reported outlier was customization 0, the EMPTY string, i.e. the cheapest input timing slowest. That is noise, not length bias. Re-running #57 against current `main`, which now has the repeated-measurement minimum, is what addresses that failure; this commit removes an unsound assertion and restores the margin the length spread was eating, which makes future noise-induced failures less likely rather than impossible. The 60% band is deliberately NOT tightened. All four inputs now do identical work, so the band only absorbs runner noise; narrowing it would trade the bug just fixed for a fresh source of intermittent failures. This remains a coarse wall-clock smoke test, and the doc comment now says so: real leakage assessment belongs to `lib-q-sca-test` and the dedicated "Constant-Time Verification" job, and a pass here is not evidence of constant-timeness. Verified: 5/5 consecutive runs green, `cargo fmt -p lib-q-k12 -- --check` clean, `cargo clippy -p lib-q-k12 --all-targets --all-features -- -D warnings` clean.
…#68) Supersedes dependabot PRs #58 and #57, which were both Cargo.lock-only but had gone stale: five other dependency bumps landed on `main` first, so their locks no longer applied and GitHub reported #58 CONFLICTING. Regenerating both on current `main` with `cargo update --precise` is equivalent to what those PRs did and avoids waiting on a dependabot rebase cycle. serde pulls its workspace-internal companions with it (serde_core, serde_derive 1.0.228 -> 1.0.229); that is the normal coupled set, not extra scope. Lockfile-only: no Cargo.toml, no source, no API change. Note for the record: #57 previously showed a red Test Matrix, and it was NOT caused by this bump. It failed on a flaky wall-clock assertion in lib-q-k12/tests/constant_time.rs at merge-base 123fc27, before `min_time` (repeated-measurement minimum) existed on main.
1 participant
Bumps serde_json from 1.0.150 to 1.0.151.
Release notes
Sourced from serde_json's releases.
Commits
de85007Release 1.0.1513b2b3c5Merge pull request #1331 from WonderLawrence/rawvalue-from-string-unchecked0406d96Debug-assert well-formedness and no-whitespace in from_string_uncheckedcf16f75Add RawValue::from_string_unchecked827a315Update actions/upload-artifact@v6 -> v7cea36a5Update actions/checkout@v6 -> v7