The password format is introduced for the password hash generated by crypt(),
so that the user can import the password hash from /etc/shadow. The packager,
especially those who packages 3rd party drivers, can utilize this feature to
import a 3rd party certificate without interfering the package installation.
This commit implements the sha256-based crypt() hash function.
Conflicts:
Makefile
MokManager.c
The password format is introduced for the password hash generated by crypt(),
so that the user can import the password hash from /etc/shadow. The packager,
especially those who packages 3rd party drivers, can utilize this feature to
import a 3rd party certificate without interfering the package installation.
This commit implements the sha256-based crypt() hash function.
Conflicts:
Makefile
MokManager.c
Without this patch, on some machines we never see MokManager's UI. This
protocol has never (I think?) been officially published, and yet I still
have new hardware that needs it.
If you're looking for a reference, look at:
EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl/ConsoleControl.c
in the edk2 tree from Tiano.
Signed-off-by: Peter Jones <pjones@redhat.com>
Without this patch, on some machines we never see MokManager's UI. This
protocol has never (I think?) been officially published, and yet I still
have new hardware that needs it.
If you're looking for a reference, look at:
EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl/ConsoleControl.c
in the edk2 tree from Tiano.
Signed-off-by: Peter Jones <pjones@redhat.com>
The maximum length of a string representation of an ipv6 address is 39
characters (8 groups of 4 hex chars, with 7 colons in between). So don't
allocate more room than this - and more importantly, don't blindly accept
strings from the server that are longer than our buffer...
The maximum length of a string representation of an ipv6 address is 39
characters (8 groups of 4 hex chars, with 7 colons in between). So don't
allocate more room than this - and more importantly, don't blindly accept
strings from the server that are longer than our buffer...
A wrong pointer was being passed to EFI_PXE_BASE_CODE_TFTP_READ_FILE,
preventing us from getting the file size back from the tftp call, ensuring
that we don't have enough information to properly secureboot-validate the
retrieved image.
A wrong pointer was being passed to EFI_PXE_BASE_CODE_TFTP_READ_FILE,
preventing us from getting the file size back from the tftp call, ensuring
that we don't have enough information to properly secureboot-validate the
retrieved image.
Right now the CA is checking if shim builds expose a particular version
of the shim protocol. To do this, they're looking for SHIM_LOCK_GUID's
value in the resulting binary.
Currently, with SHIM_LOCK_GUID as a macro that gets assigned to local
variables, that means they have to compensate for mov instructions mixed
in with the actual value. This is completely absurd, so promote it to a
first-class object with a symbol to make it both easy to find and
continuous.
Signed-off-by: Peter Jones <pjones@redhat.com>
Right now the CA is checking if shim builds expose a particular version
of the shim protocol. To do this, they're looking for SHIM_LOCK_GUID's
value in the resulting binary.
Currently, with SHIM_LOCK_GUID as a macro that gets assigned to local
variables, that means they have to compensate for mov instructions mixed
in with the actual value. This is completely absurd, so promote it to a
first-class object with a symbol to make it both easy to find and
continuous.
Signed-off-by: Peter Jones <pjones@redhat.com>
