Rather than the very C-like API we currently have, accepting a void* and
a length, let's take a Bytes object instead. In almost all existing
cases, the compiler figures out the length.
This will verify that the signature of the ephemeral key used in the
DHE and ECDHE key exchanges is actually generated by the server.
This verification is done using the first certificate provided by the
server, however the validity of this certificate is not checked here.
Instead this code expects the validity to be checked earlier by
`TLSv12::handle_certificate`.
This add an implementation for the EMSA-PKCS1-V1_5-ENCODE function from
RFC8017 section 9.2. The verification of this encoding is implemented by
simply encoding the message to be verified, and then comparing the two
encoded string.
The digest info for the different hash function is from RFC8017 section
9.2 notes 1. These byte sequences are actually ASN.1 encoded data,
however these are always constant for a specific hash function and can
be treated as opaque byte sequences.
Same as Vector, ByteBuffer now also signals allocation failure by
returning an ENOMEM Error instead of a bool, allowing us to use the
TRY() and MUST() patterns.
Problem:
- Static variables take memory and can be subject to less optimization
(https://serenityos.godbolt.org/z/7EYebr1aa)
- This static variable is only used in 1 place.
Solution:
- Move the variable into the function and make it non-static.
Problem:
- Clang ToT reports an error because `digest_size` cannot be evaluated
at compile-time.
Solution:
- Change from using the member function to the `static` shadow of the
NTTP.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This flag warns on classes which have `virtual` functions but do not
have a `virtual` destructor.
This patch adds both the flag and missing destructors. The access level
of the destructors was determined by a two rules of thumb:
1. A destructor should have a similar or lower access level to that of a
constructor.
2. Having a `private` destructor implicitly deletes the default
constructor, which is probably undesirable for "interface" types
(classes with only virtual functions and no data).
In short, most of the added destructors are `protected`, unless the
compiler complained about access.
This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
