8 Commits

Author SHA1 Message Date
Andrew Kelley
6115cf2240 migrate from std.Target.current to @import("builtin").target
closes #9388
closes #9321
2021-10-04 23:48:55 -07:00
Andrew Kelley
d29871977f remove redundant license headers from zig standard library
We already have a LICENSE file that covers the Zig Standard Library. We
no longer need to remind everyone that the license is MIT in every single
file.

Previously this was introduced to clarify the situation for a fork of
Zig that made Zig's LICENSE file harder to find, and replaced it with
their own license that required annual payments to their company.
However that fork now appears to be dead. So there is no need to
reinforce the copyright notice in every single file.
2021-08-24 12:25:09 -07:00
Jacob G-W
641ecc260f std, src, doc, test: remove unused variables 2021-06-21 17:03:03 -07:00
Isaac Freund
5b850d5c92
Run zig fmt on src/ and lib/std/
This replaces callconv(.Inline) with the more idiomatic inline keyword.
2021-05-20 17:14:18 +02:00
Andrew Kelley
c60d8f017e std: remove redundant comptime keyword
@g-w1's fancy new compile error in action
2021-04-28 22:58:12 -07:00
Frank Denis
10f2d62789
std/crypto: use finer-grained error sets in function signatures (#8558)
std/crypto: use finer-grained error sets in function signatures

Returning the `crypto.Error` error set for all crypto operations
was very convenient to ensure that errors were used consistently,
and to avoid having multiple error names for the same thing.

The flipside is that callers were forced to always handle all
possible errors, even those that could never be returned by a
function.

This PR makes all functions return union sets of the actual errors
they can return.

The error sets themselves are all limited to a single error.

Larger sets are useful for platform-specific APIs, but we don't have
any of these in `std/crypto`, and I couldn't find any meaningful way
to build larger sets.
2021-04-20 19:57:27 +02:00
Frank Denis
b98d7747fa Use a unified error set for std/crypto/*
This ensures that errors are used consistently across all operations.
2021-03-14 20:51:31 +01:00
Frank Denis
a5a3ad4f95 std/crypto: add AES-OCB
OCB has been around for a long time.

It's simpler, faster and more secure than AES-GCM.

RFC 7253 was published in 2014. OCB also won the CAESAR competition
along with AEGIS.

It's been implemented in OpenSSL and other libraries for years.

So, why isn't everybody using it instead of GCM? And why don't we
have it in Zig already?

The sad reason for this was patents. GCM was invented only to work
around these patents, and for all this time, OCB was that nice
thing that everybody knew existed but that couldn't be freely used.

That just changed. The OCB patents are now abandoned, and OCB's
author just announced that OCB was officially public domain.
2021-02-28 20:40:49 -08:00