Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
UEFI Revocation List being distributed by Debian
91 views
Skip to first unread message
Mario.Li...@dell.com
May 6, 2020, 11:10:02 PM5/6/20
to
Hello,
Recently there has been a discussion within upstream fwupd to start including the UEFI dbx revocation list directly with the fwupd package. During the code review for this as part of reviewing the terms included with it there are concerns if this would fit within the DFSG. Would it be possible to request a review of these terms to determine if this is appropriate to distribute in Debian?
https://uefi.org/revocationlistfile
Furthermore, if it is not acceptable to distribute this raw data in Debian, one of the options being considered is to programmatically re-generate a list of invalid hashes but without the signatures in the original file. Would that be acceptable to distribute in Debian instead?
Thanks,
Paul Wise
May 6, 2020, 11:50:02 PM5/6/20
to
On Thu, May 7, 2020 at 3:06 AM Mario Limonciello wrote:
> https://uefi.org/revocationlistfile
For the benefit of the mailing list archive, here is a copy of that
page in plain text form:
UEFI Revocation List File
ACCESS TO THE UEFI REVOCATION LIST FILE
This file is used to update the Secure Boot Forbidden Signature
Database, dbx. It contains the raw bytes passed in *Data to
SetVariable()... an EFI_VARIABLE_AUTHENTICATION_2 concatenated with
the new variable value. Example usage: SetVariable( "dbx",
EFI_IMAGE_SECURITY_DATABASE_GUID, NV+BS+RT+AT+AppendWrite,
dbxUpdateDotBin_sizeInBytes, *dbxUpdateDotBin_bytes). dbxupdate.bin
already contains a Microsoft KEK signature (encoded as specified by
the UEFI spec).
UEFI Revocation List File - available for download here (last updated
on August 8, 2016).
http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
UEFI Download Page Terms of Use for Microsoft Corporation's UEFI
Revocation List file ("UEFI Revocation List")
By downloading the UEFI Revocation List file ("UEFI Revocation List")
from this website (www.uefi.org), you agree to the following terms.
If you do not accept them, do not download or use the UEFI Revocation
List.
These terms do not provide you with any legal rights to any
intellectual property in any Microsoft product.
You may copy and use the UEFI Revocation List for your internal,
reference purposes and to design, develop, and test your software,
firmware or hardware, as applicable; and you may distribute the UEFI
Revocation List to end users solely as part of the distribution of an
operating system software product, or as part of the distribution of
updates to an operating system product; and you may distribute the
UEFI Revocation List to end users or through your distribution
channels solely as embodied in a firmware product or hardware product
that embodies nontrivial additional functionality. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
If you are engaged in the business of developing and commercializing
hardware products that include the UEFI standard, you may copy and use
the UEFI Revocation List for your internal, reference purposes and to
design, develop, and test your software; and you may distribute the
UEFI Revocation List end users solely as part of the distribution of
an operation system software product, or as part of the distribution
of updates to an operation system software product. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
The UEFI Revocation List is provided “as-is.” The information
contained in the UEFI Revocation List may change without notice.
Microsoft does not represent that the UEFI Revocation List is error
free and you bear the entire risk of using it. NEITHER MICROSOFT NOR
UEFI MAKES ANY WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE
UEFI REVOCATION LIST, AND MICROSOFT AND UEFI EACH EXPRESSLY DISCLAIMS
ALL OTHER EXPRESS, IMPLIED, OR STATUTORY WARRANTIES. THIS INCLUDES
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
MICROSOFT OR UEFI BE LIABLE FOR ANY SPECIAL, INDIRECT OR SONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER ARISING OUT OF OR IN CONNECTION WITH
THE USE OR DISTRIBUTION OF THE UEFI REVOCATION LIST, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION.
YOU AGREE TO RELEASE MICROSOFT (INCLUDING ITS AFFLIATES, CONTRACTORS,
AGENTS, EMPLOYEES, LICENSEES AND ASSIGNEES) AND UEFI (INCLUDING ITS
AFFILIATES, CONTRACTORS, AGENTS, EMPLOYEES, LICENSEES AND SUCCESSORS)
FROM ANY AND ALL CLAIMS OR LIABILITY ARISING OUT OF YOUR USE OR
DISTRIBUTION OF THE UEFI REVOCATION LIST AND ANY RELATED INFORMATION.
--
bye,
pabs
https://wiki.debian.org/PaulWise
> https://uefi.org/revocationlistfile
For the benefit of the mailing list archive, here is a copy of that
page in plain text form:
UEFI Revocation List File
ACCESS TO THE UEFI REVOCATION LIST FILE
This file is used to update the Secure Boot Forbidden Signature
Database, dbx. It contains the raw bytes passed in *Data to
SetVariable()... an EFI_VARIABLE_AUTHENTICATION_2 concatenated with
the new variable value. Example usage: SetVariable( "dbx",
EFI_IMAGE_SECURITY_DATABASE_GUID, NV+BS+RT+AT+AppendWrite,
dbxUpdateDotBin_sizeInBytes, *dbxUpdateDotBin_bytes). dbxupdate.bin
already contains a Microsoft KEK signature (encoded as specified by
the UEFI spec).
UEFI Revocation List File - available for download here (last updated
on August 8, 2016).
http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
UEFI Download Page Terms of Use for Microsoft Corporation's UEFI
Revocation List file ("UEFI Revocation List")
By downloading the UEFI Revocation List file ("UEFI Revocation List")
from this website (www.uefi.org), you agree to the following terms.
If you do not accept them, do not download or use the UEFI Revocation
List.
These terms do not provide you with any legal rights to any
intellectual property in any Microsoft product.
You may copy and use the UEFI Revocation List for your internal,
reference purposes and to design, develop, and test your software,
firmware or hardware, as applicable; and you may distribute the UEFI
Revocation List to end users solely as part of the distribution of an
operating system software product, or as part of the distribution of
updates to an operating system product; and you may distribute the
UEFI Revocation List to end users or through your distribution
channels solely as embodied in a firmware product or hardware product
that embodies nontrivial additional functionality. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
If you are engaged in the business of developing and commercializing
hardware products that include the UEFI standard, you may copy and use
the UEFI Revocation List for your internal, reference purposes and to
design, develop, and test your software; and you may distribute the
UEFI Revocation List end users solely as part of the distribution of
an operation system software product, or as part of the distribution
of updates to an operation system software product. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
The UEFI Revocation List is provided “as-is.” The information
contained in the UEFI Revocation List may change without notice.
Microsoft does not represent that the UEFI Revocation List is error
free and you bear the entire risk of using it. NEITHER MICROSOFT NOR
UEFI MAKES ANY WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE
UEFI REVOCATION LIST, AND MICROSOFT AND UEFI EACH EXPRESSLY DISCLAIMS
ALL OTHER EXPRESS, IMPLIED, OR STATUTORY WARRANTIES. THIS INCLUDES
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
MICROSOFT OR UEFI BE LIABLE FOR ANY SPECIAL, INDIRECT OR SONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER ARISING OUT OF OR IN CONNECTION WITH
THE USE OR DISTRIBUTION OF THE UEFI REVOCATION LIST, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION.
YOU AGREE TO RELEASE MICROSOFT (INCLUDING ITS AFFLIATES, CONTRACTORS,
AGENTS, EMPLOYEES, LICENSEES AND ASSIGNEES) AND UEFI (INCLUDING ITS
AFFILIATES, CONTRACTORS, AGENTS, EMPLOYEES, LICENSEES AND SUCCESSORS)
FROM ANY AND ALL CLAIMS OR LIABILITY ARISING OUT OF YOUR USE OR
DISTRIBUTION OF THE UEFI REVOCATION LIST AND ANY RELATED INFORMATION.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Paul Wise
May 7, 2020, 12:00:03 AM5/7/20
to
On Thu, May 7, 2020 at 3:06 AM Mario Limonciello wrote:
> there are concerns if this would fit within the DFSG
>
> https://uefi.org/revocationlistfile
>
Since it does not include modification permission and several
restrictions on redistribution, this license is unlikely to meet the
DFSG requirements. I suggest contacting the UEFI folks to ask why
these restrictions are needed at all. A regular BSD/MIT license should
be enough to meet their purposes. OTOH, I'm not sure if the data meets
the requirements for copyrightability, in which case the license would
not need to be complied with at all.
https://www.debian.org/social_contract#guidelines
https://en.wikipedia.org/wiki/Threshold_of_originality
> Recently there has been a discussion within upstream fwupd to start including the UEFI dbx revocation list directly with the fwupd package.
source code of fwupd, I think this should be separate to fwupd in the
same way that tzdata is separate to glibc and DNSSEC root keys are
separate to DNS servers and the web PKI CAs should be separate to web
browsers. I suggest that fwupd download it directly from the UEFI
website and update the copy within the boot firmware that way.
> Furthermore, if it is not acceptable to distribute this raw data in Debian, one of the options being considered is to programmatically re-generate a list of invalid hashes but without the signatures in the original file. Would that be acceptable to distribute in Debian instead?
since it would be derived from the original files?
Florian Weimer
May 7, 2020, 1:30:02 AM5/7/20
to
* Paul Wise:
> This sort of data is liable to be out of date if included in the
> source code of fwupd, I think this should be separate to fwupd in the
> same way that tzdata is separate to glibc and DNSSEC root keys are
> separate to DNS servers and the web PKI CAs should be separate to web
> browsers. I suggest that fwupd download it directly from the UEFI
> website and update the copy within the boot firmware that way.
It also has to be optional and disabled by default because a future
dbx update may be specifically designed to stop Debian systems from
booting. No Debian user will want to install such an update.
> This sort of data is liable to be out of date if included in the
> source code of fwupd, I think this should be separate to fwupd in the
> same way that tzdata is separate to glibc and DNSSEC root keys are
> separate to DNS servers and the web PKI CAs should be separate to web
> browsers. I suggest that fwupd download it directly from the UEFI
> website and update the copy within the boot firmware that way.
dbx update may be specifically designed to stop Debian systems from
booting. No Debian user will want to install such an update.
Paul Wise
May 7, 2020, 1:50:02 AM5/7/20
to
On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
> It also has to be optional and disabled by default because a future
> dbx update may be specifically designed to stop Debian systems from
> booting. No Debian user will want to install such an update.
Isn't the point of these updates to fix security issues, not to block
> It also has to be optional and disabled by default because a future
> dbx update may be specifically designed to stop Debian systems from
> booting. No Debian user will want to install such an update.
systems from booting? Presumably fwupd can be made to not install dbx
updates that would block use of the shim binary currently in use.
Mario.Li...@dell.com
May 7, 2020, 2:00:02 AM5/7/20
to
Paul,
Appreciate your response.
* Paul Wise:
> This sort of data is liable to be out of date if included in the
> source code of fwupd, I think this should be separate to fwupd in the
> same way that tzdata is separate to glibc and DNSSEC root keys are
> separate to DNS servers and the web PKI CAs should be separate to web
> browsers. I suggest that fwupd download it directly from the UEFI
> website and update the copy within the boot firmware that way.
It also has to be optional and disabled by default because a future
dbx update may be specifically designed to stop Debian systems from
booting. No Debian user will want to install such an update.
I should clarify the intent of this database was to measure the OEM's commitment to security. It was not for fwupd to distribute updated dbx database.
The only time dbx is modified is when known vulnerabilities are disclosed in a signed bootloader.
That type of action to update dbx should be specifically paired with an updated bootloader. Debian currently does not support this as I can tell.
Florian Weimer
May 7, 2020, 2:50:02 AM5/7/20
to
* Paul Wise:
> On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
>
>> It also has to be optional and disabled by default because a future
>> dbx update may be specifically designed to stop Debian systems from
>> booting. No Debian user will want to install such an update.
>
> Isn't the point of these updates to fix security issues, not to block
> systems from booting?
If Debian signatures are revoked, then the intent is to stop Debian
from booting, for everyone. The main reason for doing this will
likely be to protect users from harm that did not intent to run Debian
at all, but there is no way to tell those users from everyone else.
According to the signing policy, Debian signatures can be revoked if a
vulnerable Debian kernel is used to kexec other operating systems in
the wild, bypassing their security protections:
| b. Developers might assume that secure boot security requirements
| have been satisfied when their initial boot is complete. However,
| if a secure boot system permits launch of another operating system
| instance after execution of unauthenticated code, the security
| guarantee of secure boot is compromised. If this vulnerability is
| exploited, the submission might be revoked.
<https://techcommunity.microsoft.com/t5/windows-hardware-certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>
I assume “exploited” here means “actual malware abuses signed code”,
not harmless demonstration code.
In order reduce this risk, Debian would have to blacklist earlier
kernels along with kernel updates that fix root-to-ring-0
vulnerabilities (likewise for GRUB and shim). The signing policy
actually requires this today. Quoting the same source:
| b. Submitter must design and implement a strong revocation
| mechanism for everything the shim loads, directly and subsequently.
I do not know *any* Linux distribution that does this. Most system
administrators would really dislike it if they could only boot one
kernel version and have no way to downgrade if there is a kernel
regression.
(We should probably move this discussion to debian-project.)
> On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
>
>> It also has to be optional and disabled by default because a future
>> dbx update may be specifically designed to stop Debian systems from
>> booting. No Debian user will want to install such an update.
>
> Isn't the point of these updates to fix security issues, not to block
> systems from booting?
from booting, for everyone. The main reason for doing this will
likely be to protect users from harm that did not intent to run Debian
at all, but there is no way to tell those users from everyone else.
According to the signing policy, Debian signatures can be revoked if a
vulnerable Debian kernel is used to kexec other operating systems in
the wild, bypassing their security protections:
| b. Developers might assume that secure boot security requirements
| have been satisfied when their initial boot is complete. However,
| if a secure boot system permits launch of another operating system
| instance after execution of unauthenticated code, the security
| guarantee of secure boot is compromised. If this vulnerability is
| exploited, the submission might be revoked.
<https://techcommunity.microsoft.com/t5/windows-hardware-certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>
I assume “exploited” here means “actual malware abuses signed code”,
not harmless demonstration code.
In order reduce this risk, Debian would have to blacklist earlier
kernels along with kernel updates that fix root-to-ring-0
vulnerabilities (likewise for GRUB and shim). The signing policy
actually requires this today. Quoting the same source:
| b. Submitter must design and implement a strong revocation
| mechanism for everything the shim loads, directly and subsequently.
I do not know *any* Linux distribution that does this. Most system
administrators would really dislike it if they could only boot one
kernel version and have no way to downgrade if there is a kernel
regression.
(We should probably move this discussion to debian-project.)
Mario.Li...@dell.com
May 7, 2020, 4:20:03 PM5/7/20
to
To the original conversation that started this, upstream fwupd decided
not to ship the updated database due to this discussion. The feature
that will use it will display an error message telling a user where
to fetch it from and manually install on their system instead to use the
feature.
> -----Original Message-----
> From: Florian Weimer <f...@deneb.enyo.de>
> Sent: Thursday, May 7, 2020 1:43 AM
> To: Paul Wise
> Cc: Limonciello, Mario; debian-legal
> Subject: Re: UEFI Revocation List being distributed by Debian
>
>
> [EXTERNAL EMAIL]
hashes.
Due to the nature of
1) Being able to interchangeably use bootloaders and kernels from another
Linux based distribution
and
2) Debian closely following upstream both for kernel and bootloader
It's very unlikely that hashes would be revoked solely for Debian and
not every other Linux distribution that has a signed bootloader at the
same time in the event of a bootloader vulnerability of sufficient magnitude.
Furthermore I think your strong wording is an incorrect assumption
on the intent of revocation of hashes. The database is to ensure that
there are no known security vulnerabilities in any pieces that hurt the
ecosystem. Even without secure boot in the picture a security vulnerability
being found in the bootloader would likely warrant distributing an updated
bootloader image online updates and re-spinning installation media. This just
mandates it to use your computer with secure boot enabled in BIOS setup.
I don't feel this is unique to Debian in any way. The part that is missing
from Debian today is a method to distribute this updated database at the same
time as an updated bootloader.
> According to the signing policy, Debian signatures can be revoked if a
> vulnerable Debian kernel is used to kexec other operating systems in
> the wild, bypassing their security protections:
>
> | b. Developers might assume that secure boot security requirements
> | have been satisfied when their initial boot is complete. However,
> | if a secure boot system permits launch of another operating system
> | instance after execution of unauthenticated code, the security
> | guarantee of secure boot is compromised. If this vulnerability is
> | exploited, the submission might be revoked.
>
> <https://techcommunity.microsoft.com/t5/windows-hardware-
> certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>
>
> I assume “exploited” here means “actual malware abuses signed code”,
> not harmless demonstration code.
Harmless demonstration code is just malware building blocks.
>
> In order reduce this risk, Debian would have to blacklist earlier
> kernels along with kernel updates that fix root-to-ring-0
> vulnerabilities (likewise for GRUB and shim). The signing policy
> actually requires this today. Quoting the same source:
>
> | b. Submitter must design and implement a strong revocation
> | mechanism for everything the shim loads, directly and subsequently.
>
> I do not know *any* Linux distribution that does this. Most system
> administrators would really dislike it if they could only boot one
> kernel version and have no way to downgrade if there is a kernel
> regression.
>
> (We should probably move this discussion to debian-project.)
It's also possible to publish a MokListX database update for this same
purpose.
not to ship the updated database due to this discussion. The feature
that will use it will display an error message telling a user where
to fetch it from and manually install on their system instead to use the
feature.
> -----Original Message-----
> From: Florian Weimer <f...@deneb.enyo.de>
> Sent: Thursday, May 7, 2020 1:43 AM
> To: Paul Wise
> Cc: Limonciello, Mario; debian-legal
> Subject: Re: UEFI Revocation List being distributed by Debian
>
>
> [EXTERNAL EMAIL]
>
> * Paul Wise:
>
> > On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
> >
> >> It also has to be optional and disabled by default because a future
> >> dbx update may be specifically designed to stop Debian systems from
> >> booting. No Debian user will want to install such an update.
> >
> > Isn't the point of these updates to fix security issues, not to block
> > systems from booting?
>
> If Debian signatures are revoked, then the intent is to stop Debian
> from booting, for everyone. The main reason for doing this will
> likely be to protect users from harm that did not intent to run Debian
> at all, but there is no way to tell those users from everyone else.
>
Just to correct; it's not signatures that would be revoked but rather
> * Paul Wise:
>
> > On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
> >
> >> It also has to be optional and disabled by default because a future
> >> dbx update may be specifically designed to stop Debian systems from
> >> booting. No Debian user will want to install such an update.
> >
> > Isn't the point of these updates to fix security issues, not to block
> > systems from booting?
>
> If Debian signatures are revoked, then the intent is to stop Debian
> from booting, for everyone. The main reason for doing this will
> likely be to protect users from harm that did not intent to run Debian
> at all, but there is no way to tell those users from everyone else.
>
hashes.
Due to the nature of
1) Being able to interchangeably use bootloaders and kernels from another
Linux based distribution
and
2) Debian closely following upstream both for kernel and bootloader
It's very unlikely that hashes would be revoked solely for Debian and
not every other Linux distribution that has a signed bootloader at the
same time in the event of a bootloader vulnerability of sufficient magnitude.
Furthermore I think your strong wording is an incorrect assumption
on the intent of revocation of hashes. The database is to ensure that
there are no known security vulnerabilities in any pieces that hurt the
ecosystem. Even without secure boot in the picture a security vulnerability
being found in the bootloader would likely warrant distributing an updated
bootloader image online updates and re-spinning installation media. This just
mandates it to use your computer with secure boot enabled in BIOS setup.
I don't feel this is unique to Debian in any way. The part that is missing
from Debian today is a method to distribute this updated database at the same
time as an updated bootloader.
> According to the signing policy, Debian signatures can be revoked if a
> vulnerable Debian kernel is used to kexec other operating systems in
> the wild, bypassing their security protections:
>
> | b. Developers might assume that secure boot security requirements
> | have been satisfied when their initial boot is complete. However,
> | if a secure boot system permits launch of another operating system
> | instance after execution of unauthenticated code, the security
> | guarantee of secure boot is compromised. If this vulnerability is
> | exploited, the submission might be revoked.
>
> <https://techcommunity.microsoft.com/t5/windows-hardware-
> certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>
>
> I assume “exploited” here means “actual malware abuses signed code”,
> not harmless demonstration code.
>
> In order reduce this risk, Debian would have to blacklist earlier
> kernels along with kernel updates that fix root-to-ring-0
> vulnerabilities (likewise for GRUB and shim). The signing policy
> actually requires this today. Quoting the same source:
>
> | b. Submitter must design and implement a strong revocation
> | mechanism for everything the shim loads, directly and subsequently.
>
> I do not know *any* Linux distribution that does this. Most system
> administrators would really dislike it if they could only boot one
> kernel version and have no way to downgrade if there is a kernel
> regression.
>
> (We should probably move this discussion to debian-project.)
purpose.
Steve Langasek
May 8, 2020, 4:50:03 PM5/8/20
to
Hi Mario,
First, the license is not an end-user license and if someone chooses to
agree to the license as part of downloading, this appears to only be binding
on the downloader; it is not a license that must be included in the
redistribution to users (as debian/copyright).
Second, the following URL is accessible without affirmatively agreeing to
the license.
http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
Third, the contents of this file are a non-copyrightable list of statements
of mathematical facts. Distribution of this file is not subject to
copyright law.
I don't think there is any issue with Debian distributing this file.
FWIW Ubuntu already distributes this file in the secureboot-db package. I
do not think that Ubuntu would want to enable updates of the revocation list
via the fwupd package since revocations could in principle impact the
bootability of the system (if the dbx update included a hash of Ubuntu's
shim, or Ubuntu's signing key). dbx updates should be carefully managed in
conjunction with updates to the bootloader itself, which the tighter
coupling of a directly-managed native package gives us. I think similar
reasoning would apply for Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slan...@ubuntu.com vor...@debian.org
agree to the license as part of downloading, this appears to only be binding
on the downloader; it is not a license that must be included in the
redistribution to users (as debian/copyright).
Second, the following URL is accessible without affirmatively agreeing to
the license.
http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
Third, the contents of this file are a non-copyrightable list of statements
of mathematical facts. Distribution of this file is not subject to
copyright law.
I don't think there is any issue with Debian distributing this file.
FWIW Ubuntu already distributes this file in the secureboot-db package. I
do not think that Ubuntu would want to enable updates of the revocation list
via the fwupd package since revocations could in principle impact the
bootability of the system (if the dbx update included a hash of Ubuntu's
shim, or Ubuntu's signing key). dbx updates should be carefully managed in
conjunction with updates to the bootloader itself, which the tighter
coupling of a directly-managed native package gives us. I think similar
reasoning would apply for Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Mario.Li...@dell.com
May 8, 2020, 5:00:03 PM5/8/20
to
> -----Original Message-----
> From: Steve Langasek <vor...@debian.org>
> Sent: Friday, May 8, 2020 3:35 PM
> To: Limonciello, Mario
> Cc: debian...@lists.debian.org
> Subject: Re: UEFI Revocation List being distributed by Debian
>
most sense to create a new package for this. I don't feel it should be distributed
as part of fwupd, just like Ubuntu distributes it as part of secureboot-db.
>
> FWIW Ubuntu already distributes this file in the secureboot-db package. I
> do not think that Ubuntu would want to enable updates of the revocation list
> via the fwupd package since revocations could in principle impact the
> bootability of the system (if the dbx update included a hash of Ubuntu's
> shim, or Ubuntu's signing key). dbx updates should be carefully managed in
> conjunction with updates to the bootloader itself, which the tighter
> coupling of a directly-managed native package gives us. I think similar
> reasoning would apply for Debian.
There is no intent for fwupd enabling the updated of the revocation list.
The intent was to compare whether the firmware already contains everything
in the latest revocation list to notify the user if items are missing as part
of an upcoming security measurement feature.
I completely agree the revocation list needs to be rolled out in tandem with
updated bootloaders should the need arise.
0 new messages