mirror of
https://git.proxmox.com/git/efi-boot-shim
synced 2025-06-13 15:22:00 +00:00
1d39ada8cb
OpenSSL changes quite a bit of the key validation, and most of the keys I can find in the wild aren't marked as trusted by the new checker. Intel noticed this too: https://github.com/vathpela/edk2/commit/f536d7c3ed but instead of fixing the compatibility error, they switched their test data to match the bug. So that's pretty broken. For now, I'm reverting OpenSSL 1.1.0e, because we need those certs in the wild to work. This reverts commit513cbe2aea. This reverts commite9cc33d6f2. This reverts commit80d49f758e. This reverts commit9bc647e2b2. This reverts commitae75df6232. This reverts commite883479f35. This reverts commit97469449fd. This reverts commite39692647f. This reverts commit0f3dfc01e2. This reverts commit4da6ac8195. This reverts commitd064bd7eef. This reverts commit9bc86cfd6f. This reverts commitab9a05a10f. Signed-off-by: Peter Jones <pjones@redhat.com>
98 lines
3.8 KiB
C
98 lines
3.8 KiB
C
#ifndef HEADER_OPENSSLV_H
|
|
# define HEADER_OPENSSLV_H
|
|
|
|
#ifdef __cplusplus
|
|
extern "C" {
|
|
#endif
|
|
|
|
/*-
|
|
* Numeric release version identifier:
|
|
* MNNFFPPS: major minor fix patch status
|
|
* The status nibble has one of the values 0 for development, 1 to e for betas
|
|
* 1 to 14, and f for release. The patch level is exactly that.
|
|
* For example:
|
|
* 0.9.3-dev 0x00903000
|
|
* 0.9.3-beta1 0x00903001
|
|
* 0.9.3-beta2-dev 0x00903002
|
|
* 0.9.3-beta2 0x00903002 (same as ...beta2-dev)
|
|
* 0.9.3 0x0090300f
|
|
* 0.9.3a 0x0090301f
|
|
* 0.9.4 0x0090400f
|
|
* 1.2.3z 0x102031af
|
|
*
|
|
* For continuity reasons (because 0.9.5 is already out, and is coded
|
|
* 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
|
|
* part is slightly different, by setting the highest bit. This means
|
|
* that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start
|
|
* with 0x0090600S...
|
|
*
|
|
* (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
|
|
* (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
|
|
* major minor fix final patch/beta)
|
|
*/
|
|
# define OPENSSL_VERSION_NUMBER 0x100020bfL
|
|
# ifdef OPENSSL_FIPS
|
|
# define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2k-fips 26 Jan 2017"
|
|
# else
|
|
# define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2k 26 Jan 2017"
|
|
# endif
|
|
# define OPENSSL_VERSION_PTEXT " part of " OPENSSL_VERSION_TEXT
|
|
|
|
/*-
|
|
* The macros below are to be used for shared library (.so, .dll, ...)
|
|
* versioning. That kind of versioning works a bit differently between
|
|
* operating systems. The most usual scheme is to set a major and a minor
|
|
* number, and have the runtime loader check that the major number is equal
|
|
* to what it was at application link time, while the minor number has to
|
|
* be greater or equal to what it was at application link time. With this
|
|
* scheme, the version number is usually part of the file name, like this:
|
|
*
|
|
* libcrypto.so.0.9
|
|
*
|
|
* Some unixen also make a softlink with the major verson number only:
|
|
*
|
|
* libcrypto.so.0
|
|
*
|
|
* On Tru64 and IRIX 6.x it works a little bit differently. There, the
|
|
* shared library version is stored in the file, and is actually a series
|
|
* of versions, separated by colons. The rightmost version present in the
|
|
* library when linking an application is stored in the application to be
|
|
* matched at run time. When the application is run, a check is done to
|
|
* see if the library version stored in the application matches any of the
|
|
* versions in the version string of the library itself.
|
|
* This version string can be constructed in any way, depending on what
|
|
* kind of matching is desired. However, to implement the same scheme as
|
|
* the one used in the other unixen, all compatible versions, from lowest
|
|
* to highest, should be part of the string. Consecutive builds would
|
|
* give the following versions strings:
|
|
*
|
|
* 3.0
|
|
* 3.0:3.1
|
|
* 3.0:3.1:3.2
|
|
* 4.0
|
|
* 4.0:4.1
|
|
*
|
|
* Notice how version 4 is completely incompatible with version, and
|
|
* therefore give the breach you can see.
|
|
*
|
|
* There may be other schemes as well that I haven't yet discovered.
|
|
*
|
|
* So, here's the way it works here: first of all, the library version
|
|
* number doesn't need at all to match the overall OpenSSL version.
|
|
* However, it's nice and more understandable if it actually does.
|
|
* The current library version is stored in the macro SHLIB_VERSION_NUMBER,
|
|
* which is just a piece of text in the format "M.m.e" (Major, minor, edit).
|
|
* For the sake of Tru64, IRIX, and any other OS that behaves in similar ways,
|
|
* we need to keep a history of version numbers, which is done in the
|
|
* macro SHLIB_VERSION_HISTORY. The numbers are separated by colons and
|
|
* should only keep the versions that are binary compatible with the current.
|
|
*/
|
|
# define SHLIB_VERSION_HISTORY ""
|
|
# define SHLIB_VERSION_NUMBER "1.0.0"
|
|
|
|
|
|
#ifdef __cplusplus
|
|
}
|
|
#endif
|
|
#endif /* HEADER_OPENSSLV_H */
|