mimics the duplication of strings in `Builder` for `Pkg`. This
ensures the lifetime of the memory backing strings in a `Pkg`
struct and the `Pkg.dependencies` slice is not shorter than the
`Builder` that the data is associated with.
The new defaults that came in with
644400054c5769a397ded4f569e2ac0600d65305 are nice, however, it is still
possible that someone knows their inputs are always small and wants to
use the simpler implementations. We keep the default to make the choice
at runtime, but expose the linear functions in the public interface of
std.mem.
Also improved the doc comments.
- use `PascalCase` for all types. So, AES256GCM is now Aes256Gcm.
- consistently use `_length` instead of mixing `_size` and `_length` for the
constants we expose
- Use `minimum_key_length` when it represents an actual minimum length.
Otherwise, use `key_length`.
- Require output buffers (for ciphertexts, macs, hashes) to be of the right
size, not at least of that size in some functions, and the exact size elsewhere.
- Use a `_bits` suffix instead of `_length` when a size is represented as a
number of bits to avoid confusion.
- Functions returning a constant-sized slice are now defined as a slice instead
of a pointer + a runtime assertion. This is the case for most hash functions.
- Use `camelCase` for all functions instead of `snake_case`.
No functional changes, but these are breaking API changes.
* move the opaque section to after struct, enum, union, and add
hyperlinks
* improve the introduction of the zig build system. don't link to the
wiki.
* update to the latest zig init-exe example code
* rename headers to avoid redundant words such as "zig"
* simplify example code
Unlike glibc and musl, MinGW provides no libssp symbols leading to
countless compile errors if FORTIFY_SOURCE is defined.
Add a (incomplete) implementation of libssp written in Zig so that
linking succeeds.
Closes#6492
Pay close attention to the RHS type alignment when rendering an
assignment op as it may differ from the LHS pointer one.
This problem was noticed when debugging a CI failure in #6648: due to
sheer luck the misalignment caused a segfault on macos that was also
reproduced locally.
I tried to write a small test case but it turned out to be a daunting
task as I couldn't manage to trigger the problem consistently (and stop
the optimizer from simplifying everything). Patches welcome.
* remove GetModuleHandleA from kernel32.zig. use of A functions
considered harmful.
* make it a compile error to expose WinMain instead of wWinMain. same
thing.
* start code declares wWinMainCRTStartup instead of WinMainCRTStartup
when it has the choice.
`DefaultCsprng` is documented as a cryptographically secure RNG.
While `ISAAC` is a CSPRNG, the variant we have, `ISAAC64` is not.
A 64 bit seed is a bit small to satisfy that claim.
We also saw it being used with the current date as a seed, that
also defeats the point of a CSPRNG.
Set `DefaultCsprng` to `Gimli` instead of `ISAAC64`, rename
the parameter from `init_s` to `secret_seed` + add a comment to
clarify what kind of seed is expected here.
Instead of directly touching the internals of the Gimli implementation
(which can change/be architecture-specific), add an `init()` function
to the state.
Our Gimli-based CSPRNG was also not backtracking resistant. Gimli
is a permutation; it can be reverted. So, if the state was ever leaked,
future secrets, but also all the previously generated ones could be
recovered. Clear the rate after a squeeze in order to prevent this.
Finally, a dumb test was added just to exercise `DefaultCsprng` since
we don't use it anywhere.
