This release is motivated by a fix for a potential security
vulnerability. 421a21abd8 fixes a bug
introduced in a1c4c4efb5. A truncated
pointer register led to a segfault on x86-64 under Clang 7 and 8.
Clang 9 happens to be unaffected, but the behavior is undefined in
general. See also:
https://github.com/BLAKE3-team/BLAKE3/issues/60#issuecomment-585838317
The C implementation of BLAKE3 hasn't been formally packaged anywhere,
and most callers vendor code from master. This release tag is intended
to make the fix above more visible, to encourage callers to update their
vendored copies. We will continue to publish tags like this whenever
bugs in the C implementation are fixed, or if there are any incompatible
API changes.
Note that the issue above does not impact callers of the Rust `blake3`
crate. The affected file, `blake3_dispatch.c`, is not compiled by that
crate in any configuration. It does impact callers of the internal
`blake3_c_rust_bindings` crate, but that crate is not published on
crates.io and not intended for production use.
This gives the assembly files the same prefix as the intrinsics files which
simplifies building when the build system should pick between the assembly and
the intrinsics files.
Changes since 0.1.5:
- The `c_avx512` feature has been replaced by the `c` feature. In
addition to providing AVX-512 support, `c` also provides optimized
assembly implementations. These assembly implementations perform
better, perform more consistently across compilers, and compile more
quickly. As before, `c` is off by default, but the `b3sum` binary
crate activates it by default.
- The `rayon` feature no longer affects the entire API. Instead, it
provides the `join::RayonJoin` type for use with
`Hasher::update_with_join`, so that the caller can control when
multi-threading happens. Standalone API functions like `hash` are
always single-threaded now.
We use a counter value that's very close to wrapping the lower word,
when we're testing the hash_many chunks case. It turns out that this is
a useful thing to do with parents too, even though parents 1) are
teeechnically supposed to always use a counter of 0, and 2) aren't going
to increment the counter at all. We caught a bug in the assembly
implementations this way (where we accidentally did increment the
counter, but only the higher word), because the equivalent test in
rust_c_bindings uses this eccentric parents counter value.
Changes since 0.1.4:
- Remove all AVX-512 code from builds with the default feature set. This
works around https://github.com/rust-lang/rust/issues/68905 and fixes
the nightly build as long as the "c_avx512" feature is not activated.
This release is a backport of a single commit, e43a7d6. The master
branch contains backwards-incompatible changes (fc219f4), and the next
release of master will be version 0.2.0.
Note that the `b3sum` crate activates the "c_avx512" feature by default,
and it will continue to fail to build on nightly until the upstream bug
is fixed.
https://github.com/rust-lang/rust/issues/68905 is currently causing
nightly builds to fail, unless `--no-default-features` is used. This
change means that the default build will succeed, and the failure will
only happen when the "c_avx512" is enabled. The `b3sum` crate will still
fail to build on nightly, because it enables that feature, but most
callers should start succeeding on nightly.
https://github.com/rust-lang/rust/issues/68905 is currently causing
nightly builds to fail, unless `--no-default-features` is used. This
change means that the default build will succeed, and the failure will
only happen when the "c_avx512" is enabled. The `b3sum` crate will still
fail to build on nightly, because it enables that feature, but most
callers should start succeeding on nightly.
This is a new interface that allows the caller to provide a
multi-threading implementation. It's defined in terms of a new `Join`
trait, for which we provide two implementations, `SerialJoin` and
`RayonJoin`. This lets the caller control when multi-threading is used,
rather than the previous all-or-nothing design of the "rayon" feature.
Although existing callers should keep working, this is a compatibility
break, because callers who were relying on automatic multi-threading
before will now be single-threaded. Thus the next release of this crate
will need to be version 0.2.
See https://github.com/BLAKE3-team/BLAKE3/issues/25 and
https://github.com/BLAKE3-team/BLAKE3/issues/54.
Changes since 0.1.3:
- Hasher supports the reset() method.
- Hasher implements several traits from the `digest` and `crypto_mac`
crates.
- Bug fixes in the C implementation for MSVC and for 32-bit x86.
[main.c] removed including of unistd.h from c/main.c file.
[blake3_avx2.c|blake3_avx512.c|blake3_sse41.c] resolved compile error:
'C4146' - applying of unary minus operator to the unsigned value.
Currently this requires setting the BLAKE3_USE_NEON preprocessor flag.
In the future we may enable this automatically on AArch32/64 or include
some kind of dynamic feature detection. (Though ARM makes this harder
than x86.)
As part of this, get rid of the IS_ARM flag. It wasn't being set
properly when I tried it on a Raspberry Pi.
Closes #30.
Jack O'Connor
Samuel Neves
Erik Johansson
Cesar Eduardo Barros
TheVice