1. Forum
  2. Usenet
  3. LINUX.DEBIAN.LEGAL

  • UEFI Revocation List being distributed by Debian

    From Mario.Limonciello@dell.com@21:1/5 to All on Thu May 7 05:10:01 2020
    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,

    <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
    <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style><!--
    /* Font Definitions */
    @font-face
    {font-family:"Cambria Math";
    panose-1:2 4 5 3 5 4 6 3 2 4;}
    @font-face
    {font-family:Calibri;
    panose-1:2 15 5 2 2 2 4 3 2 4;}
    /* Style Definitions */
    p.MsoNormal, li.MsoNormal, div.MsoNormal
    {margin:0in;
    margin-bottom:.0001pt;
    font-size:11.0pt;
    font-family:"Calibri",sans-serif;}
    a:link, span.MsoHyperlink
    {mso-style-priority:99;
    color:#0563C1;
    text-decoration:underline;}
    a:visited, span.MsoHyperlinkFollowed
    {mso-style-priority:99;
    color:#954F72;
    text-decoration:underline;}
    span.EmailStyle17
    {mso-style-type:personal-compose;
    font-family:"Calibri",sans-serif;
    color:windowtext;}
    .MsoChpDefault
    {mso-style-type:export-only;
    font-family:"Calibri",sans-serif;}
    @page WordSection1
    {size:8.5in 11.0in;
    margin:1.0in 1.0in 1.0in 1.0in;}
    div.WordSection1
    {page:WordSection1;}
    </style><!--[if gte mso 9]><xml>
    <o:shapedefaults v:ext="edit" spidmax="1026" />
    </xml><![endif]--><!--[if gte mso 9]><xml>
    <o:shapelayout v:ext="edit">
    <o:idmap v:ext="edit" data="1" />
    </o:shapelayout></xml><![endif]-->
    </head>
    <body lang="EN-US" link="#0563C1" vlink="#954F72">
    <div class="WordSection1">
    <p class="MsoNormal">Hello,<o:p></o:p></p>
    <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class="MsoNormal">Recently there has been a discussion within upstream fwupd to start including the UEFI dbx revocation list directly with the fwupd package.&nbsp; 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.&nbsp; Would it be possible to request a review of these terms to determine if this is appropriate to distribute in Debian?<o:p></o:p></p>
    <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class="MsoNormal"><a href="https://uefi.org/revocationlistfile">https://uefi.org/revocationlistfile</a><o:p></o:p></p>
    <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class="MsoNormal">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.&nbsp; Would
    that be
    acceptable to distribute in Debian instead?<o:p></o:p></p>
    <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class="MsoNormal">Thanks,<o:p></o:p></p>
    </div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Thu May 7 05:50:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Thu May 7 06:00:02 2020
    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.

    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.

    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?

    I don't think that is meaningfully different to the original files,
    since it would be derived from the original files?

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Florian Weimer on Thu May 7 07:50:01 2020
    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? Presumably fwupd can be made to not install dbx
    updates that would block use of the shim binary currently in use.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl6zoMwACgkQMRa6Xp/6 aaMk2xAAkoN+sFS+lDj73YBVWfH6NZOsIm9K6f9Y5cbg5PqEDCIzwiinyj+FwFxR RtQP5+qOr9wKQHpOQgHOWo3xKrwrN9IbZgsQypPxref9TWepH73EwZrfHChF0zTX jg0x7i/wDQAgtC2JgqN7SnORd4o4+bcs/RWXQtCgtYDXIdy3aguubPdx5+U3DrRi jM72jTylg5C78CpJYsVflsbJwJNtCZZ4DKNtP8APo171JdsZ62uR+BMhBmXtb484 OL4A+FIDv6+1UwONGnmypeUnv5Fd0s9UZBN0NR7nn3F3qZj/HWD/cU9KX1K1eBPI qlT7bugtpUn+gLhINJOhhooT8P/t81dKNbg8ePRWViCQkY3d2DveB6i8D37b7bQS zLm5JRwgb0lAhVmmqccYjQZCaKsKuRwx2M0dT0PQoaNzm879ZQFqf1X7NBj58wm0 myTGazQQWvEQhUR9k+oLkbUPh2nEaEcueSJfaqqF8cB2kDhVX2p2MUOG4wqzI7Ox SXRMBHXFqGzvREC5Xg8SQ23QpBsLqw2119VRJJE3PO9UK6ZTozhRiBz2VxJPU4Cj rbNQbEaqKWPoPY6vOAyi6x0BmCSfnw0ATo5Hf5figaKAnpftyLUQbSPBvcrZlhly AJc4I+dMlUpFRWQ4Ekdcajc0+rkGIpA9tZwcBlhXt/bVeoaAUvM=
    =q14L
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Thu May 7 07:30:01 2020
    * 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mario.Limonciello@dell.com@21:1/5 to All on Thu May 7 08:00:01 2020
    UGF1bCwNCg0KQXBwcmVjaWF0ZSB5b3VyIHJlc3BvbnNlLg0KDQpPbiBNYXkgNywgMjAyMCAwMDoy NiwgRmxvcmlhbiBXZWltZXIgPGZ3QGRlbmViLmVueW8uZGU+IHdyb3RlOg0KDQpbRVhURVJOQUwg RU1BSUxdDQoNCiogUGF1bCBXaXNlOg0KDQo+IFRoaXMgc29ydCBvZiBkYXRhIGlzIGxpYWJsZSB0 byBiZSBvdXQgb2YgZGF0ZSBpZiBpbmNsdWRlZCBpbiB0aGUNCj4gc291cmNlIGNvZGUgb2YgZnd1 cGQsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgc2VwYXJhdGUgdG8gZnd1cGQgaW4gdGhlDQo+IHNh bWUgd2F5IHRoYXQgdHpkYXRhIGlzIHNlcGFyYXRlIHRvIGdsaWJjIGFuZCBETlNTRUMgcm9vdCBr ZXlzIGFyZQ0KPiBzZXBhcmF0ZSB0byBETlMgc2VydmVycyBhbmQgdGhlIHdlYiBQS0kgQ0FzIHNo b3VsZCBiZSBzZXBhcmF0ZSB0byB3ZWINCj4gYnJvd3NlcnMuIEkgc3VnZ2VzdCB0aGF0IGZ3dXBk IGRvd25sb2FkIGl0IGRpcmVjdGx5IGZyb20gdGhlIFVFRkkNCj4gd2Vic2l0ZSBhbmQgdXBkYXRl IHRoZSBjb3B5IHdpdGhpbiB0aGUgYm9vdCBmaXJtd2FyZSB0aGF0IHdheS4NCg0KSXQgYWxzbyBo YXMgdG8gYmUgb3B0aW9uYWwgYW5kIGRpc2FibGVkIGJ5IGRlZmF1bHQgYmVjYXVzZSBhIGZ1dHVy ZQ0KZGJ4IHVwZGF0ZSBtYXkgYmUgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIHN0b3AgRGViaWFu IHN5c3RlbXMgZnJvbQ0KYm9vdGluZy4gIE5vIERlYmlhbiB1c2VyIHdpbGwgd2FudCB0byBpbnN0 YWxsIHN1Y2ggYW4gdXBkYXRlLg0KDQpJIHNob3VsZCBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhp cyBkYXRhYmFzZSB3YXMgdG8gbWVhc3VyZSB0aGUgT0VNJ3MgY29tbWl0bWVudCB0byBzZWN1cml0 eS4gSXQgd2FzIG5vdCBmb3IgZnd1cGQgdG8gZGlzdHJpYnV0ZSB1cGRhdGVkIGRieCBkYXRhYmFz ZS4NCg0KVGhlIG9ubHkgdGltZSBkYnggaXMgbW9kaWZpZWQgaXMgd2hlbiBrbm93biB2dWxuZXJh YmlsaXRpZXMgYXJlIGRpc2Nsb3NlZCBpbiBhIHNpZ25lZCBib290bG9hZGVyLg0KDQpUaGF0IHR5 cGUgb2YgYWN0aW9uIHRvIHVwZGF0ZSBkYnggc2hvdWxkIGJlIHNwZWNpZmljYWxseSBwYWlyZWQg d2l0aCBhbiB1cGRhdGVkIGJvb3Rsb2FkZXIuIERlYmlhbiBjdXJyZW50bHkgZG9lcyBub3Qgc3Vw cG9ydCB0aGlzIGFzIEkgY2FuIHRlbGwuDQoNCg==

    PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj5QYXVsLDwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRp diBkaXI9ImF1dG8iPkFwcHJlY2lhdGUgeW91ciByZXNwb25zZS4mbmJzcDs8YnI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSIgZGlyPSJhdXRvIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gTWF5IDcsIDIwMjAgMDA6MjYsIEZsb3JpYW4gV2VpbWVyICZsdDtmd0BkZW5lYi5lbnlv LmRlJmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9 InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTBwdCI+DQo8ZGl2Pjxicj4NCltFWFRFUk5BTCBFTUFJTF0gPGJyPg0KPGJyPg0K KiBQYXVsIFdpc2U6PGJyPg0KPGJyPg0KJmd0OyBUaGlzIHNvcnQgb2YgZGF0YSBpcyBsaWFibGUg dG8gYmUgb3V0IG9mIGRhdGUgaWYgaW5jbHVkZWQgaW4gdGhlPGJyPg0KJmd0OyBzb3VyY2UgY29k ZSBvZiBmd3VwZCwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBzZXBhcmF0ZSB0byBmd3VwZCBpbiB0 aGU8YnI+DQomZ3Q7IHNhbWUgd2F5IHRoYXQgdHpkYXRhIGlzIHNlcGFyYXRlIHRvIGdsaWJjIGFu ZCBETlNTRUMgcm9vdCBrZXlzIGFyZTxicj4NCiZndDsgc2VwYXJhdGUgdG8gRE5TIHNlcnZlcnMg YW5kIHRoZSB3ZWIgUEtJIENBcyBzaG91bGQgYmUgc2VwYXJhdGUgdG8gd2ViPGJyPg0KJmd0OyBi cm93c2Vycy4gSSBzdWdnZXN0IHRoYXQgZnd1cGQgZG93bmxvYWQgaXQgZGlyZWN0bHkgZnJvbSB0 aGUgVUVGSTxicj4NCiZndDsgd2Vic2l0ZSBhbmQgdXBkYXRlIHRoZSBjb3B5IHdpdGhpbiB0aGUg Ym9vdCBmaXJtd2FyZSB0aGF0IHdheS48YnI+DQo8YnI+DQpJdCBhbHNvIGhhcyB0byBiZSBvcHRp b25hbCBhbmQgZGlzYWJsZWQgYnkgZGVmYXVsdCBiZWNhdXNlIGEgZnV0dXJlPGJyPg0KZGJ4IHVw ZGF0ZSBtYXkgYmUgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIHN0b3AgRGViaWFuIHN5c3RlbXMg ZnJvbTxicj4NCmJvb3RpbmcuJm5ic3A7IE5vIERlYmlhbiB1c2VyIHdpbGwgd2FudCB0byBpbnN0 YWxsIHN1Y2ggYW4gdXBkYXRlLjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+ DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5JIHNob3VsZCBjbGFyaWZ5IHRoZSBpbnRlbnQgb2Yg dGhpcyBkYXRhYmFzZSB3YXMgdG8gbWVhc3VyZSB0aGUgT0VNJ3MgY29tbWl0bWVudCB0byBzZWN1 cml0eS4gSXQgd2FzIG5vdCBmb3IgZnd1cGQgdG8gZGlzdHJpYnV0ZSB1cGRhdGVkIGRieCBkYXRh YmFzZS48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRv Ij5UaGUgb25seSB0aW1lIGRieCBpcyBtb2RpZmllZCBpcyB3aGVuIGtub3duIHZ1bG5lcmFiaWxp dGllcyBhcmUgZGlzY2xvc2VkIGluIGEgc2lnbmVkIGJvb3Rsb2FkZXIuPC9kaXY+DQo8ZGl2IGRp cj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+VGhhdCB0eXBlIG9mIGFjdGlv biB0byB1cGRhdGUgZGJ4IHNob3VsZCBiZSBzcGVjaWZpY2FsbHkgcGFpcmVkIHdpdGggYW4gdXBk YXRlZCBib290bG9hZGVyLiBEZWJpYW4gY3VycmVudGx5IGRvZXMgbm90IHN1cHBvcnQgdGhpcyBh cyBJIGNhbiB0ZWxsLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTBwdCI+DQo8ZGl2PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Thu May 7 08:50:01 2020
    * 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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mario.Limonciello@dell.com@21:1/5 to All on Thu May 7 22:20:02 2020
    VG8gdGhlIG9yaWdpbmFsIGNvbnZlcnNhdGlvbiB0aGF0IHN0YXJ0ZWQgdGhpcywgdXBzdHJlYW0g Znd1cGQgZGVjaWRlZA0Kbm90IHRvIHNoaXAgdGhlIHVwZGF0ZWQgZGF0YWJhc2UgZHVlIHRvIHRo aXMgZGlzY3Vzc2lvbi4gIFRoZSBmZWF0dXJlDQp0aGF0IHdpbGwgdXNlIGl0IHdpbGwgZGlzcGxh eSBhbiBlcnJvciBtZXNzYWdlIHRlbGxpbmcgYSB1c2VyIHdoZXJlDQp0byBmZXRjaCBpdCBmcm9t IGFuZCBtYW51YWxseSBpbnN0YWxsIG9uIHRoZWlyIHN5c3RlbSBpbnN0ZWFkIHRvIHVzZSB0aGUN CmZlYXR1cmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmxvcmlh biBXZWltZXIgPGZ3QGRlbmViLmVueW8uZGU+DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgNywgMjAy MCAxOjQzIEFNDQo+IFRvOiBQYXVsIFdpc2UNCj4gQ2M6IExpbW9uY2llbGxvLCBNYXJpbzsgZGVi aWFuLWxlZ2FsDQo+IFN1YmplY3Q6IFJlOiBVRUZJIFJldm9jYXRpb24gTGlzdCBiZWluZyBkaXN0 cmlidXRlZCBieSBEZWJpYW4NCj4gDQo+IA0KPiBbRVhURVJOQUwgRU1BSUxdDQo+IA0KPiAqIFBh dWwgV2lzZToNCj4gDQo+ID4gT24gVGh1LCAyMDIwLTA1LTA3IGF0IDA3OjI2ICswMjAwLCBGbG9y aWFuIFdlaW1lciB3cm90ZToNCj4gPg0KPiA+PiBJdCBhbHNvIGhhcyB0byBiZSBvcHRpb25hbCBh bmQgZGlzYWJsZWQgYnkgZGVmYXVsdCBiZWNhdXNlIGEgZnV0dXJlDQo+ID4+IGRieCB1cGRhdGUg bWF5IGJlIHNwZWNpZmljYWxseSBkZXNpZ25lZCB0byBzdG9wIERlYmlhbiBzeXN0ZW1zIGZyb20N Cj4gPj4gYm9vdGluZy4gIE5vIERlYmlhbiB1c2VyIHdpbGwgd2FudCB0byBpbnN0YWxsIHN1Y2gg YW4gdXBkYXRlLg0KPiA+DQo+ID4gSXNuJ3QgdGhlIHBvaW50IG9mIHRoZXNlIHVwZGF0ZXMgdG8g Zml4IHNlY3VyaXR5IGlzc3Vlcywgbm90IHRvIGJsb2NrDQo+ID4gc3lzdGVtcyBmcm9tIGJvb3Rp bmc/DQo+IA0KPiBJZiBEZWJpYW4gc2lnbmF0dXJlcyBhcmUgcmV2b2tlZCwgdGhlbiB0aGUgaW50 ZW50IGlzIHRvIHN0b3AgRGViaWFuDQo+IGZyb20gYm9vdGluZywgZm9yIGV2ZXJ5b25lLiAgVGhl IG1haW4gcmVhc29uIGZvciBkb2luZyB0aGlzIHdpbGwNCj4gbGlrZWx5IGJlIHRvIHByb3RlY3Qg dXNlcnMgZnJvbSBoYXJtIHRoYXQgZGlkIG5vdCBpbnRlbnQgdG8gcnVuIERlYmlhbg0KPiBhdCBh bGwsIGJ1dCB0aGVyZSBpcyBubyB3YXkgdG8gdGVsbCB0aG9zZSB1c2VycyBmcm9tIGV2ZXJ5b25l IGVsc2UuDQo+IA0KDQpKdXN0IHRvIGNvcnJlY3Q7IGl0J3Mgbm90IHNpZ25hdHVyZXMgdGhhdCB3 b3VsZCBiZSByZXZva2VkIGJ1dCByYXRoZXINCmhhc2hlcy4NCg0KRHVlIHRvIHRoZSBuYXR1cmUg b2YNCjEpIEJlaW5nIGFibGUgdG8gaW50ZXJjaGFuZ2VhYmx5IHVzZSBib290bG9hZGVycyBhbmQg a2VybmVscyBmcm9tIGFub3RoZXINCkxpbnV4IGJhc2VkIGRpc3RyaWJ1dGlvbg0KYW5kDQoyKSBE ZWJpYW4gY2xvc2VseSBmb2xsb3dpbmcgdXBzdHJlYW0gYm90aCBmb3Iga2VybmVsIGFuZCBib290 bG9hZGVyDQoNCkl0J3MgdmVyeSB1bmxpa2VseSB0aGF0IGhhc2hlcyB3b3VsZCBiZSByZXZva2Vk IHNvbGVseSBmb3IgRGViaWFuIGFuZA0Kbm90IGV2ZXJ5IG90aGVyIExpbnV4IGRpc3RyaWJ1dGlv biB0aGF0IGhhcyBhIHNpZ25lZCBib290bG9hZGVyIGF0IHRoZQ0Kc2FtZSB0aW1lIGluIHRoZSBl dmVudCBvZiBhIGJvb3Rsb2FkZXIgdnVsbmVyYWJpbGl0eSBvZiBzdWZmaWNpZW50IG1hZ25pdHVk ZS4NCg0KRnVydGhlcm1vcmUgSSB0aGluayB5b3VyIHN0cm9uZyB3b3JkaW5nIGlzIGFuIGluY29y cmVjdCBhc3N1bXB0aW9uDQpvbiB0aGUgaW50ZW50IG9mIHJldm9jYXRpb24gb2YgaGFzaGVzLiAg VGhlIGRhdGFiYXNlIGlzIHRvIGVuc3VyZSB0aGF0DQp0aGVyZSBhcmUgbm8ga25vd24gc2VjdXJp dHkgdnVsbmVyYWJpbGl0aWVzIGluIGFueSBwaWVjZXMgdGhhdCBodXJ0IHRoZQ0KZWNvc3lzdGVt LiAgRXZlbiB3aXRob3V0IHNlY3VyZSBib290IGluIHRoZSBwaWN0dXJlIGEgc2VjdXJpdHkgdnVs bmVyYWJpbGl0eQ0KYmVpbmcgZm91bmQgaW4gdGhlIGJvb3Rsb2FkZXIgd291bGQgbGlrZWx5IHdh cnJhbnQgZGlzdHJpYnV0aW5nIGFuIHVwZGF0ZWQNCmJvb3Rsb2FkZXIgaW1hZ2Ugb25saW5lIHVw ZGF0ZXMgYW5kIHJlLXNwaW5uaW5nIGluc3RhbGxhdGlvbiBtZWRpYS4gIFRoaXMganVzdA0KbWFu ZGF0ZXMgaXQgdG8gdXNlIHlvdXIgY29tcHV0ZXIgd2l0aCBzZWN1cmUgYm9vdCBlbmFibGVkIGlu IEJJT1Mgc2V0dXAuDQoNCkkgZG9uJ3QgZmVlbCB0aGlzIGlzIHVuaXF1ZSB0byBEZWJpYW4gaW4g YW55IHdheS4gIFRoZSBwYXJ0IHRoYXQgaXMgbWlzc2luZw0KZnJvbSBEZWJpYW4gdG9kYXkgaXMg YSBtZXRob2QgdG8gZGlzdHJpYnV0ZSB0aGlzIHVwZGF0ZWQgZGF0YWJhc2UgYXQgdGhlIHNhbWUN CnRpbWUgYXMgYW4gdXBkYXRlZCBib290bG9hZGVyLg0KDQo+IEFjY29yZGluZyB0byB0aGUgc2ln bmluZyBwb2xpY3ksIERlYmlhbiBzaWduYXR1cmVzIGNhbiBiZSByZXZva2VkIGlmIGENCj4gdnVs bmVyYWJsZSBEZWJpYW4ga2VybmVsIGlzIHVzZWQgdG8ga2V4ZWMgb3RoZXIgb3BlcmF0aW5nIHN5 c3RlbXMgaW4NCj4gdGhlIHdpbGQsIGJ5cGFzc2luZyB0aGVpciBzZWN1cml0eSBwcm90ZWN0aW9u czoNCj4gDQo+IHwgYi4gRGV2ZWxvcGVycyBtaWdodCBhc3N1bWUgdGhhdCBzZWN1cmUgYm9vdCBz ZWN1cml0eSByZXF1aXJlbWVudHMNCj4gfCBoYXZlIGJlZW4gc2F0aXNmaWVkIHdoZW4gdGhlaXIg aW5pdGlhbCBib290IGlzIGNvbXBsZXRlLiBIb3dldmVyLA0KPiB8IGlmIGEgc2VjdXJlIGJvb3Qg c3lzdGVtIHBlcm1pdHMgbGF1bmNoIG9mIGFub3RoZXIgb3BlcmF0aW5nIHN5c3RlbQ0KPiB8IGlu c3RhbmNlIGFmdGVyIGV4ZWN1dGlvbiBvZiB1bmF1dGhlbnRpY2F0ZWQgY29kZSwgdGhlIHNlY3Vy aXR5DQo+IHwgZ3VhcmFudGVlIG9mIHNlY3VyZSBib290IGlzIGNvbXByb21pc2VkLiBJZiB0aGlz IHZ1bG5lcmFiaWxpdHkgaXMNCj4gfCBleHBsb2l0ZWQsIHRoZSBzdWJtaXNzaW9uIG1pZ2h0IGJl IHJldm9rZWQuDQo+IA0KPiA8aHR0cHM6Ly90ZWNoY29tbXVuaXR5Lm1pY3Jvc29mdC5jb20vdDUv d2luZG93cy1oYXJkd2FyZS0NCj4gY2VydGlmaWNhdGlvbi9taWNyb3NvZnQtdWVmaS1jYS1zaWdu aW5nLXBvbGljeS11cGRhdGVzL2JhLXAvMzY0ODI4Pg0KPiANCj4gSSBhc3N1bWUg4oCcZXhwbG9p dGVk4oCdIGhlcmUgbWVhbnMg4oCcYWN0dWFsIG1hbHdhcmUgYWJ1c2VzIHNpZ25lZCBjb2Rl4oCd LA0KPiBub3QgaGFybWxlc3MgZGVtb25zdHJhdGlvbiBjb2RlLg0KDQpIYXJtbGVzcyBkZW1vbnN0 cmF0aW9uIGNvZGUgaXMganVzdCBtYWx3YXJlIGJ1aWxkaW5nIGJsb2Nrcy4NCg0KPiANCj4gSW4g b3JkZXIgcmVkdWNlIHRoaXMgcmlzaywgRGViaWFuIHdvdWxkIGhhdmUgdG8gYmxhY2tsaXN0IGVh cmxpZXINCj4ga2VybmVscyBhbG9uZyB3aXRoIGtlcm5lbCB1cGRhdGVzIHRoYXQgZml4IHJvb3Qt dG8tcmluZy0wDQo+IHZ1bG5lcmFiaWxpdGllcyAobGlrZXdpc2UgZm9yIEdSVUIgYW5kIHNoaW0p LiAgVGhlIHNpZ25pbmcgcG9saWN5DQo+IGFjdHVhbGx5IHJlcXVpcmVzIHRoaXMgdG9kYXkuICBR dW90aW5nIHRoZSBzYW1lIHNvdXJjZToNCj4gDQo+IHwgYi4gU3VibWl0dGVyIG11c3QgZGVzaWdu IGFuZCBpbXBsZW1lbnQgYSBzdHJvbmcgcmV2b2NhdGlvbg0KPiB8IG1lY2hhbmlzbSBmb3IgZXZl cnl0aGluZyB0aGUgc2hpbSBsb2FkcywgZGlyZWN0bHkgYW5kIHN1YnNlcXVlbnRseS4NCj4gDQo+ IEkgZG8gbm90IGtub3cgKmFueSogTGludXggZGlzdHJpYnV0aW9uIHRoYXQgZG9lcyB0aGlzLiAg TW9zdCBzeXN0ZW0NCj4gYWRtaW5pc3RyYXRvcnMgd291bGQgcmVhbGx5IGRpc2xpa2UgaXQgaWYg dGhleSBjb3VsZCBvbmx5IGJvb3Qgb25lDQo+IGtlcm5lbCB2ZXJzaW9uIGFuZCBoYXZlIG5vIHdh eSB0byBkb3duZ3JhZGUgaWYgdGhlcmUgaXMgYSBrZXJuZWwNCj4gcmVncmVzc2lvbi4NCj4gDQo+ IChXZSBzaG91bGQgcHJvYmFibHkgbW92ZSB0aGlzIGRpc2N1c3Npb24gdG8gZGViaWFuLXByb2pl Y3QuKQ0KDQpJdCdzIGFsc28gcG9zc2libGUgdG8gcHVibGlzaCBhIE1va0xpc3RYIGRhdGFiYXNl IHVwZGF0ZSBmb3IgdGhpcyBzYW1lDQpwdXJwb3NlLg0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mario.Limonciello@dell.com@21:1/5 to All on Fri May 8 23:00:02 2020
    -----Original Message-----
    From: Steve Langasek <vorlon@debian.org>
    Sent: Friday, May 8, 2020 3:35 PM
    To: Limonciello, Mario
    Cc: debian-legal@lists.debian.org
    Subject: Re: UEFI Revocation List being distributed by Debian

    Hi Mario,

    On Thu, May 07, 2020 at 02:25:41AM +0000, Mario.Limonciello@dell.com wrote:
    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?

    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.

    If this similar sentiment is agreed upon others in this list I think it makes 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.


    You might have missed the previous intent discussed earlier in the thread. 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to Mario.Limonciello@dell.com on Fri May 8 22:50:02 2020
    Hi Mario,

    On Thu, May 07, 2020 at 02:25:41AM +0000, Mario.Limonciello@dell.com wrote:
    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?

    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/ slangasek@ubuntu.com vorlon@debian.org

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAl61woAACgkQVo0w8yGy Ez0JjhAAjdyc5oQdFkMD3k18tYne/Rk616Y0BouvH+JUz+8XsXtSfBabJINpO/5P 8rthFqc46dmfx9ZuhkhjYNXWavfDl8jUzkA6xkBKNJzTRbgPsrfaWf7K0o13+9CY p3Lqf3Hv7GXbL3bImIyFW5nJHLaagGj9Its6p+wFwhCrP+Qsp9mOAJL1PsJCIGKJ CEVQLzG1lwI4MOPwa7C+axtjm8hwJ1rfaJBpQ6YU0IPNNiCRnb8s65pD701y/NQV 36uR6oXhJgA/RGLHMVONuemXOG0pdtHRuSatz0lTpN4zllVx+G6V6zyrMTf3Yt5v 9tUQHplfrTrSYOkDW3DOVP0pP/nIehEl1gj4noQ96cl/toTWjauE9lyGhNyuC03h MEKq3ECj84jFYcka1OkXLAzHJvi6ZQOwsDF2eQpsPZNp+12aZfJ8p4Y2LHyItzBl ItKiu/fm+ygia54iW9Ih+IP7Dj75uVaVoAI7kb085EZlhTZHgjTaSBh0Bjvc6zjZ Xx3JoQtn6yXyizIOJ6pTQEcOa6SAMp1im2VFPPpj79zRVKLmj6iKKCRZlVaoyEw9 wpZHV/X0ruarpVpZuD13