I've removed all hardcoded key hashes as they are not required and to avoid possible legal issues.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2552
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: Maufeat <sahyno1996@gmail.com>
Co-committed-by: Maufeat <sahyno1996@gmail.com>
update mbedtls functors to support mbedtls3 signatures
moved some vulkan stuff from externals to root, yuzu_use_cpm manages
them now
needs testing:
- all key/derivation related things
- nca verification
- game loading/updates/stuff
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/485
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
Previously the constructor for all of these would run at program
startup, consuming time before the application can enter main().
This is also particularly dangerous, given the logging system wouldn't
have been initialized properly yet, yet the program would use the logs
to signify an error.
To rectify this, we can replace the literals with constexpr functions
that perform the conversion at compile-time, completely eliminating the
runtime cost of initializing these arrays.
In a few places, the data to be set as the IV is already within an array.
We shouldn't require this data to be heap-allocated if it doesn't need
to be. This allows certain callers to reduce heap churn.
We can just reserve the memory then perform successive insertions
instead of needing to use memcpy. This also avoids the need to zero out
the output vector's memory before performing the insertions.
We can also std::move the output std::vector into the destination so
that we don't need to make a completely new copy of the vector, getting
rid of an unnecessary allocation.
Additionally, we can use iterators to determine the beginning and end
ranges of the std::vector instances that comprise the output vector, as
the end of one range just becomes the beginning for the next successive
range, and since std::vector's iterator constructor copies data within
the range [begin, end), this is more straightforward and gets rid of the
need to have an offset variable that keeps getting incremented to
determine where to do the next std::memcpy.
Given it's only used in one spot and has a fairly generic name, we can
just specify it directly in the function call. This also the benefit of
automatically moving it.
Instead, we can make it part of the type and make named variables for
them, so they only require one definition (and if they ever change for
whatever reason, they only need to be changed in one spot).
Given the VirtualFile instance isn't stored into the class as a data
member, or written to, this can just be turned into a const reference,
as the constructor doesn't need to make a copy of it.
crueter