As of LLVM 22, most backends can (finally) handle legalization of these types as
necessary, so we don't need to do it ourselves anymore.
closes https://github.com/ziglang/zig/issues/23674
UTCTime years in the range 50-99 must map to 1950-1999, but the
parser unconditionally added 2000, producing dates 100 years in the
future.
This caused verify() to accept certificates whose validity actually
expired decades ago.
Change that to match what OpenSSL, BoringSSL, etc. do
AsconXof128 and AsconCxof128 were applying the padding in update()
calls. That was totally fine for one-shot hashing, but not for
streaming (multiple update() calls before finalization).
After decryption, TLS 1.3 plaintext is trimmed of zero padding, then
the last byte is read as the content type.
But when the plaintext was entirely zero padding, we got a
"thread panic: integer overflow at msg.len - 1" error. That could be
triggered by any server to crash the client.
If we have just created cache_dir_path, then there's no `tmp` dir
there, and
cache_dir.createFile(io, "tmp/libfuzzer.log", .{ .truncate = false })
fails.
Tested via
$ zig version
0.16.0
$ zig build --zig-lib-dir ~/p/zig/lib/ --fuzz
`setFileOwner` declared `SetOwnerError!void` but its vtable method
returns the wider `SetFileOwnerError!void` (adds `NameTooLong` and
`BadPathName`), so any call through the wrapper fails to compile.
`setTimestampsNow` dispatched to `io.vtable.fileSetTimestamps` with
`(Dir, []const u8, Dir.SetTimestampsOptions)`, but that vtable entry
takes `(File, File.SetTimestampsOptions)`. The intended target is
`dirSetTimestamps`, whose signature matches the call site.
The previous approach had a few downsides:
1. You couldn't set the alignment of the internal buffer. Many callers in
the standard library trying to use this for a small vec style
optimization worked around this by setting the alignment for
the struct itself, this ends up very verbose and also assumes a
specific layout for the struct which isn't guaranteed.
2. It was generic over the size of the buffer. This type is used a lot in
std with various sizes.
3. It has an awkward API where you had to call get which mutated the type
unlike all other allocators, and then had a runtime check to make sure
you didn't get this wrong.
The new approach resolves all of these issues by just taking the buf as
an argument.
This is particularly amenable to smallvec style optimizations: you can
just declare the buf as an array of the item you want to allocate to get
the exact minimum size.
Jacob Young