| Age | Commit message (Collapse) | Author |
|---|
|
Changes since 1.8.2:
- Add `Hash::as_slice`.
- Update to the 2024 Edition and bump the MSRV to 1.85.
- Fix a set of Miri failures in the intrinsics implementations. We were
computing (though not dereferencing) an out-of-bounds pointer using
`add` rather than `wrapping_add`. I'm not aware of any observable
consequences of this bug. See https://github.com/BLAKE3-team/BLAKE3/pull/507.
- CPU feature detection on x86/x86-64 no longer requires the `std` Cargo
feature in the `blake3` crate.
- Build fixes in the C implementation for macOS and Cygwin, and various
improvements to the CMake build.
|
|
While we're taking this MSRV bump, we can also update
`constant_time_eq`, which uses the 2024 edition in its most recent
versions.
|
|
|
|
Upstream `crypto-common` now does the pin itself:
https://github.com/RustCrypto/traits/issues/2036#issuecomment-3522196740
|
|
This is a temporary hack to fix warnings in CI. Upstream tracking issue:
https://github.com/RustCrypto/traits/issues/2036
|
|
Previously "std" enabled runtime CPU feature detection on x86, but as of
https://github.com/BLAKE3-team/BLAKE3/pull/469 that's always on.
|
|
|
|
Changes since 1.8.1:
- Fixes to the CMake build, particularly around the new TBB feature.
|
|
|
|
Changes since 1.8.0:
- [CMake] Fix transitive dependencies for TBB when libblake3 is built
with BLAKE3_USE_TBB=1 (#460 and #461).
|
|
Changes since 1.7.0:
- The Rust crate now provides the `blake3::hazmat` module, which
replaces the undocumented and now deprecated `blake3::guts` module.
This is intended for advanced use cases like Bao and Iroh, which need
to manipulate chunk and subtree "chaining values" directly. See the
module docs for more: https://docs.rs/blake3/1.8.0/blake3/hazmat
|
|
Changes since 1.6.1:
- The C implementation has gained multithreading support, based on
Intel's oneTBB library. This works similarly to the Rayon-based
multithreading used in the Rust implementation. See c/README.md for
details. Contributed by @silvanshade (#445).
- The Rust implementation has gained a WASM SIMD backend, gated by the
`wasm32_simd` Cargo feature. Under Wasmtime on my laptop, this is a 6x
performance improvement for large inputs. This backend is currently
Rust-only. Contributed by @monoid (#341).
- Fixed cross-compilation builds targeting Windows with cargo-xwin.
Contributed by @Sporif and @toothbrush7777777 (#230).
- Added `b3sum --tag`, which changes the output format. This is for
compatibility with GNU checksum tools (which use the same flag) and
BSD checksum tools (which use the output format this flag turns on).
Contributed by @leahneukirchen (#453) and @dbohdan (#430).
|
|
|
|
|
|
This code is based on rust_sse2.rs of the same distribution, and is
subject to further improvements. Some comments are left intact even if
their applicability is questioned.
SIMD implementation is gated by `wasm32-simd` feature, portable version
is used otherwise.
Performance measurements with a primitive benchmark with ~16Kb of data:
| M1 native | 11,610 ns |
| M1 WASM SIMD | 13,355 ns |
| M1 WASM | 22,037 ns |
| x64 native | 6,713 ns |
| x64 WASM SIMD | 11,985 ns |
| x64 WASM | 25,978 ns |
wasmtime v12.0.1 was used on both platforms.
Closes #187.
|
|
Changes since 1.6.0:
- Remove `mmap` from the default features list. It was added
accidentally in v1.6.0, last week. This is technically a
backwards-incompatible change, but I would rather not tag v2.0.0 for a
build-time bugfix with a simple workaround.
|
|
I committed this change accidentally in
a12fa7b8a4131d77c35eda5c680b9307a0fc28d3. Thanks to @ArmoredPony for
catching this in https://github.com/BLAKE3-team/BLAKE3/issues/452.
|
|
Changes since 1.5.5:
- Add Hash::from_slice. (#448)
- Fix a build error on Windows 7 targets. (#447)
|
|
|
|
|
|
Changes since 1.5.4:
- `b3sum --check` now supports checkfiles with Windows-style newlines.
`b3sum` still emits Unix-style newlines, even on Windows, but
sometimes text editors or version control tools will swap them.
- The "digest" feature (deleted in v1.5.2) has been added back to the
`blake3` crate. This is for backwards compatibility only, and it's
insta-deprecated. All callers should prefer the "traits-preview"
feature.
|
|
|
|
|
|
Changes since 1.5.3:
- Initial implementation of SIMD acceleration for the XOF (i.e.
blake3::Hasher::finalize_xof). This brings long output performance
into line with long input performance. Currently AVX-512-only and
Unix-only.
- Add build support for "gnullvm" targets (Clang on Windows).
- The "zeroize" feature no longer depends on proc-macros and syn.
|
|
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/416.
|
|
Removes dependence on proc-macros when enabling the zeroize feature.
|
|
Changes since 1.5.2:
- Revert the serialization change. It was intended to be backwards
compatible, but that didn't hold for non-self-describing serialization
formats like bincode. See #414.
|
|
This mostly reverts commits 8416b1658c2690dc6351bdc7e0975b0d5f1a5282 and
dd0afd640ad97b5ebcf887107162009a23ffdca0.
Changing the serialization of Hash can only be backwards-compatible in
self-describing formats like CBOR. In non-self-describing formats like
bincode, the deserializer has to know in advance which serialization
format was used.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/414.
Reopens https://github.com/BLAKE3-team/BLAKE3/issues/412.
|
|
Changes since 1.5.1:
- `build.rs` sets `cc::Build::emit_rerun_if_env_changed(false)` to
prevent some unnecessary rebuilds, particularly when the `PATH`
changes on Windows. See #324.
- Serializing a `Hash` produces a bytestring instead of an array in
formats that support bytestrings (like CBOR). Deserialization is
backwards-compatible with the array format.
- Cleanup and edge case fixes in the C and CMake builds.
|
|
Closes #412.
|
|
|
|
|
|
|
|
Changes since 1.5.0:
- The Rust crate is now compatible with Miri.
- ~1% performance improvement on Arm NEON contributed by @divinity76 (#384).
- Various fixes and improvements in the CMake build.
- The MSRV of b3sum is now 1.74.1. (The MSRV of the library crate is
unchanged, 1.66.1.)
|
|
|
|
Changes since 1.4.1:
- The Rust crate's Hasher type has gained new helper methods for common
forms of IO: update_reader, update_mmap, and update_mmap_rayon. The
latter matches the default behavior of b3sum. The mmap methods are
gated by the new "mmap" Cargo feature.
- Most of the Rust crate's public types now implement the Zeroize trait.
This is gated by the new "zeroize" Cargo feature.
- The Rust crate's Hash types now implements the serde Serialize and
Deserialize traits. This is gated by the new "serde" Cargo feature.
- The C library now uses atomics to cache detected CPU features under
most compilers other than MSVC. Previously this was a non-atomic
write, which was probably "benign" but made TSan unhappy.
- NEON support is now disabled by default on big-endian AArch64.
Previously this was a build error if the caller didn't explicitly
disable it.
|
|
|
|
Added a new cargo feature `serde` that when enabled will derive
`serde::Serialize` and `serde::Deserialize` for the `blake3::Hash`
struct.
|
|
New methods:
- update_reader
- update_mmap
- update_mmap_rayon
These are more discoverable, more convenient, and safer.
There are two problems I want to avoid by taking a `Path` instead of a
`File`. First, exposing `Mmap` objects to the caller is fundamentally
unsafe, and making `maybe_mmap_file` private avoids that issue. Second,
taking a `File` raises questions about whether memory mapped reads
should behave like regular file reads. (Should they respect the current
seek position? Should they update the seek position?) Taking a `Path`
from the caller and opening the `File` internally avoids these
questions.
|
|
|
|
As part of this change, I don't think we need the `zeroize_crate`
workaround anymore if we use the relateively new `dep:` syntax in
Cargo.toml.
|
|
|
|
|
|
|
|
Changes since 1.4.0:
- Improved performance in the ARM NEON implementation for both C and
Rust callers. This affects AArch64 targets by default and ARMv7
targets that explicitly enable (and support) NEON. The size of the
improvement depends on the microarchitecture, but I've benchmarked
~1.3x on a Cortex-A53 and ~1.2x on an Apple M1. Contributed by
@sdlyyxy in #319.
- The MSRV is now 1.66.1 for both the `blake3` crate and `b3sum`.
|
|
This bumps the MSRV of both `blake3` and `b3sum` to 1.66.1.
|
|
Changes since 1.3.3:
- The C implementation provides a `CMakeLists.txt` for callers who build
with CMake. The CMake build is not yet stable, and callers should
expect breaking changes in patch version updates. The "by hand" build
will always continue to be supported and documented.
- `b3sum` supports the `--seek` flag, to set the starting position in
the output stream.
- `b3sum --check` prints a summary of errors to stderr.
- `Hash::as_bytes` is const.
- `Hash` supports `from_bytes`, which is const.
|
|
The MSRV is already 1.60, so this doesn't affect much. The only impact
to other code is that we no longer need to explicitly import TryInto.
|
|
Changes since 1.3.2:
- Fix incorrect output from AVX-512 intrinsics under GCC 5.4 and 6.1 in
debug mode. This bug was found in unit tests and probably doesn't
affect the public API in practice. See
https://github.com/BLAKE3-team/BLAKE3/issues/271.
|
|
Changes since 1.3.1:
- Dependency updates only. This includes updating Clap to v4, which
changes the format of the `b3sum --help` output. The new MSRV is
1.59.0 for `blake3` and 1.60.0 for `b3sum`. Note that this project
doesn't have any particular MSRV policy, and we don't consider MSRV
bumps to be breaking changes.
|
