| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
Makefile
|
|
Conflicts:
Makefile
|
|
|
|
|
|
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
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
|
|
The dir filter appends L'/' to the directory entries without
allocating a new buffer, and this could crash the whole program.
|
|
The dir filter appends L'/' to the directory entries without
allocating a new buffer, and this could crash the whole program.
|
|
This is the first stage of porting the MokManager UI to the UI code used
by the Linux Foundation UEFI loader.
|
|
This is the first stage of porting the MokManager UI to the UI code used
by the Linux Foundation UEFI loader.
|
|
This is the first stage of porting the MokManager UI to the UI code used
by the Linux Foundation UEFI loader.
Conflicts:
MokManager.c
|
|
This is the first stage of porting the MokManager UI to the UI code used
by the Linux Foundation UEFI loader.
Conflicts:
MokManager.c
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Conflicts:
MokManager.c
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Conflicts:
MokManager.c
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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>
|
|
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...
|
|
|
|
|
|
|
|
|
|
We don't need to add one because our end pointer is already off the end of
the string we want to copy.
|
|
We don't need to add one because our end pointer is already off the end of
the string we want to copy.
|
|
Fix various errors in the tftp string handling, to ensure we always have
properly nul-terminated strings.
|
|
Fix various errors in the tftp string handling, to ensure we always have
properly nul-terminated strings.
|
|
|
|
|
|
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.
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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>
|
|
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>
|
|
|
|
the netboot code.
|
|
errors in filenames passed to tftp.
|
