- Arch-releng - lists.archlinux.org

[arch-releng] [archiso] [GIT] branch master updated (55cdc1e -> 05f1116)
by Gerardo Exequiel Pozzi 06 Apr '19

06 Apr '19

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch master in repository archiso. from 55cdc1e make sure the root filesystem is owned by root new fb2f34d Update packages.x86_64 new 05f1116 [configs/releng] Add iwd The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit 05f11168d2d34492cd3d7770338ff55e92f82f7d Author: Gerardo Exequiel Pozzi <vmlinuz386(a)gmail.com> Date: Sat Apr 6 00:29:57 2019 -0300 [configs/releng] Add iwd Requested at FS#62087 commit fb2f34d127989467c72744789ec514f05fe007d6 Author: martindamianfernandez <martin.damian.fernandez(a)gmail.com> Date: Fri Apr 5 18:01:34 2019 -0300 Update packages.x86_64 wpa_actiond 404 file no found Summary of changes: configs/releng/packages.x86_64 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] accessibility support in official arch iso.
by Alexandr Epaneshnikov 22 Mar '19

22 Mar '19

hello. i am a blind arch user. currently to independently install arch i am using the TalkingArch <https://talkingarch.info> it is simple respin of archiso with speakup and brltty packages included. it wood be nice if official arch live iso comes with accessability support. especialy then Debian, fedora and even gentoo provides such option and it doesn't required much maintenance when implemented. if someone from arch Community interested to implement with my guidance of course. a possible approach : 1 include alsa, brltty and espeakup packages. 2 create a special boot option to boot archiso live session with speech enabled. brltty can be enabled in standard session because it not interfere with workload for sited people. 3 make a11y documentation on arch wiki. if someone is interested. lets discuss. p.s. i hope that I chose the right list. Sincerely, Alexander

3 2

[arch-releng] Secure Boot support (FS#53864)
by Jonas Witschel 23 Jan '19

23 Jan '19

Hi all, following up on FS#53864, I tried to summarise possible ways to implement Secure Boot in Arch Linux. I apologise in advance for the very long email... I structured the text into two possible approaches (technically three, but the first one is not very feasible) and would love to hear your opinion on them. If there is an interest in implementing Secure Boot, I am happy to help out wherever I can. You will see however that most required changes are more on the "administrative" side rather than the "coding" side, e.g. officially adopting packages from the AUR, creating certificates, submitting binaries to Microsoft for review, ... I have successfully tested the approach "Using a signed shimx64.efi built by a third party" on different machines, with Secure Boot enabled and disabled. Current situation ----------------- On UEFI systems, Archiso uses PreLoader.efi from efitools [1] to chainload the systemd-boot boot loader. As the efitools EFI binaries used in Arch Linux are built from source and not signed by Microsoft, this procedure fails when Secure Boot is enabled because the unsigned PreLoader.efi cannot be executed. (This makes the preloader a bit useless, see FS#59487: systemd-boot could be directly installed as bootx64.efi instead, as the only purpose of the preloader is to make Secure Boot possible.) Previously, Archiso used an old version of efitools signed by Microsoft, which is provided by Linux kernel maintainer James Bottomley [2]: it was formerly packaged as "prebootloader", but this package has been removed in favour of efitools [3]. Possible solutions ------------------ Using a signed PreLoader.efi built by Arch Linux ------------------------------------------------ It is possible to build UEFI binaries yourself and get them signed by Microsoft by submitting them to [4], see [5] for the requirements that need to be fulfilled. However, judging by [4], it seems that Microsoft focuses on the "shim" boot loader instead of efitools, therefore I don't know how likely it is for such a request to succeed. I therefore concentrated on switching from efitools to shim in the next two sections. Using a signed shimx64.efi built by a third party ------------------------------------------------- The efforts regarding Secure Boot on Linux now seem to concentrate around the shim boot loader [6], available in the AUR as shim-efi. It is developed by Red Hat and works as a drop-in replacement for efitools: the only difference are some name changes, i.e. "PreLoader.efi" is called "shimx64.efi", "HashTool.efi" is "mmx64.efi", and the second-stage boot loader needs to be called "grubx64.efi" instead of "loader.efi" (even if it is not GRUB, but systemd-boot in case of Archiso). This would allow to use Secure Boot by the following process, which is also documented in the corresponding section of the Wiki [7]: 1. Boot the Arch Linux ISO with Secure Boot enabled. 2. The signed shimx64.efi tries to load grubx64.efi, which is the systemd-boot boot loader. As systemd-boot is unsigned, this will fail, so shimx64.efi launches mmx64.efi instead. mmx64.efi gives you the opportunity to enroll the hashes of the boot loader (grubx64.efi) and kernel (vmlinuz.efi). This saves their hashes in the EFI variable "MokList", which allows them to be executed with Secure Boot enabled. 3. After a restart, shimx64.efi is now able to execute the thus approved boot loader and kernel without further user action. 4. When the boot loader or kernel are updated, the user needs to enroll the new binaries using the same process as in 2. There are two possibilities to obtain a pre-built signed shimx64.efi: there is a "generic" version built by former Red Hat employee Matthew Garrett [8], but it is very old and might not be suitable any more. As an alternative, we can use any newer Microsoft-signed shim built by a distribution like Fedora [9], which is what the AUR package shim-signed does. Advantages of this approach: + Most distributions supporting Secure Boot seem to use shim, so this might be more well-tried than the efitools approach. + It should be easy to verify the authenticity of the prebuilt binaries because the review process for shims signed by Microsoft is public [10] and includes information about the build configuration. Detaching the signature from the binary [11] makes it possible to verify that the unsigned binary is reproducible from source. Disadvantages: - We don't have control over the build of the unsigned binary and depend on another distribution for updates. - Other distributions include their own signing key in the shim binary. This allows them to sign their boot loader and kernel themselves, avoiding the need to enroll the hashes every time (see the next section). We cannot make use of this key ourselves, so we have a shim that includes a superfluous (but harmless) additional public key. Using a signed shimx64.efi built by Arch Linux ---------------------------------------------- It is possible to build shim yourself and get it signed by Microsoft. To do this, you need to submit it to Microsoft [4] and open an issue in [10] providing all the necessary information. If the request is approved, you receive back the signed files you can then distribute. The easiest approach is to only get shimx64.efi signed and let users enrol the hashes of the boot loader and kernel manually [7]. However, with our own shim, we can do much better: it is possible to embed the public key of a certificate into the shim binary [12]. This certificate can be used to sign the boot loader and kernel so that Secure Boot works completely automated out of the box, without having to enrol hashes. This process is documented in the Wiki as well [13] (except that you don't have to enroll "MOK.cer" manually, since it is already embedded in the shim binary). This approach would not only be beneficial to Archiso, it can also be used on installed systems for Secure Boot to work out of the box! To follow this approach, the following things need to be done: 1. Create a certificate conforming to the policy [5]. 2. Build shim [6], embedding the public part of the certificate generated in 1. [12] 3. Submit the binary "shimx64.efi" to Microsoft [4] and the shim-review repository [10]. 4. Once the signed binary is returned, verify that it matches the submitted build [11] and distribute it as a package. 5. In Archiso, replace "PreLoader.efi" and "HashTool.efi" by "shimx64.efi" and "mmx64.efi", rename "loader.efi" to "grubx64.efi". 6. (Optional) Sign the kernel "vmlinuz-linux" and all relevant boot loaders (systemd-boot, GRUB, REFInd) with sbsign from the sbsigntools package using the key generated in 1. This needs to be incorporated into the PKGBUILD of the respective packages. Advantages: + Full control over the distributed binaries. + Transparent for users, no manual enrollment is necessary. + Works for installed systems as well as Archiso. Disadvantages: - This is much more elaborate than using a pre-built signed binary, as we need to go through the shim review process ourselves. - Signing the kernel and boot loaders requires access to the private key of the certificate. Depending on how the certificate is stored, this might pose logistic problems for developers/TUs wanting to update one of the affected packages. Note however that this part is completely optional, users will still be able to enrol unsigned binaries using a hash [7]. Therefore this will also still allow users running a custom kernel or boot loader to use Secure Boot. Suggested action ---------------- If shipping binaries built by a third party is acceptable in this context, I would start with the approach described in "Using a signed shimx64.efi built by a third party". This requires the least effort to get Secure Boot working (just adopt shim-signed as an official package and follow "Using a signed shimx64.efi built by Arch Linux", step 4.), but will still require manual enrolment of the boot loader and kernel hashes by the user. If you want full control over the distributed binaries, I suggest the approach described in "Using a signed shimx64.efi built by Arch Linux", possibly in the following stages: 1. Adopt the AUR package shim-efi as an official package in order to build shim from source. 2. Move Archiso from efitools to shim as described in "Using a signed shimx64.efi built by Arch Linux", step 4. 3. Wait a couple of months to gain experience with the new preloader. 4. If all goes well, submit shim for signing as described in "Using a signed shimx64.efi built by Arch Linux", step 3. 5. Distribute the signed shim as a package and use it in Archiso. 6. When this is up and running, gauge interest for signing the boot loader and kernel with the key embedded in shim to remove the need to manually enrol the hashes on every boot loader/kernel update. If there is an interest in pursuing any of these approaches, I am happy to submit the necessary (but fairly trivial) patch to move Archiso from efitools to shim or to assist in the process of submitting the shim binary for review as far as I can. Unfortunately, the main workload will still rest on a developer/TU. If there are any questions, don't hesitate to ask! I have successfully tested the approach described in "Using a signed shimx64.efi built by a third party" on multiple machines with Secure Boot enabled and disabled and I am happy to share the necessary steps to locally build an Arch Linux ISO which works with Secure Boot enabled. Cheers, Jonas [1] https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git [2] https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-rele… [3] https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/prebootl… [4] https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/lsa-and… [5] https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/… [6] https://github.com/rhboot/shim [7] https://wiki.archlinux.org/index.php/Secure_Boot#shim_with_hash [8] https://mjg59.dreamwidth.org/20303.html [9] https://apps.fedoraproject.org/packages/shim/ [10] https://github.com/rhboot/shim-review [11] https://wiki.debian.org/SecureBoot#line-160 [12] https://github.com/rhboot/shim/blob/b3e4d1f7555aabbf5d54de5ea7cd7e839e7bd83… [13] https://wiki.archlinux.org/index.php/Secure_Boot#shim_with_key

1 1

[arch-releng] [archiso] [GIT] branch testing updated (d320406 -> 55cdc1e)
by Gerardo Exequiel Pozzi 09 Jan '19

09 Jan '19

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch testing in repository archiso. from d320406 prepare release new 55cdc1e make sure the root filesystem is owned by root The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit 55cdc1e9bc2b2d56509c3d238f3f19e9822fd976 Author: Christian Hesse <mail(a)eworm.de> Date: Tue Jan 8 12:05:54 2019 +0100 make sure the root filesystem is owned by root Signed-off-by: Christian Hesse <mail(a)eworm.de> Summary of changes: archiso/mkarchiso | 1 + 1 file changed, 1 insertion(+) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] [archiso] [GIT] branch master updated (d320406 -> 55cdc1e)
by Gerardo Exequiel Pozzi 09 Jan '19

09 Jan '19

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch master in repository archiso. from d320406 prepare release new 55cdc1e make sure the root filesystem is owned by root The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit 55cdc1e9bc2b2d56509c3d238f3f19e9822fd976 Author: Christian Hesse <mail(a)eworm.de> Date: Tue Jan 8 12:05:54 2019 +0100 make sure the root filesystem is owned by root Signed-off-by: Christian Hesse <mail(a)eworm.de> Summary of changes: archiso/mkarchiso | 1 + 1 file changed, 1 insertion(+) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] [PATCH 1/1] make sure the root filesystem is owned by root
by Christian Hesse 08 Jan '19

08 Jan '19

From: Christian Hesse <mail(a)eworm.de> Signed-off-by: Christian Hesse <mail(a)eworm.de> --- archiso/mkarchiso | 1 + 1 file changed, 1 insertion(+) diff --git a/archiso/mkarchiso b/archiso/mkarchiso index 4d4db50..72a6e32 100755 --- a/archiso/mkarchiso +++ b/archiso/mkarchiso @@ -217,6 +217,7 @@ _mkairootfs_img () { _mount_airootfs _msg_info "Copying '${work_dir}/airootfs/' to '${work_dir}/mnt/airootfs/'..." cp -aT "${work_dir}/airootfs/" "${work_dir}/mnt/airootfs/" + chown root:root "${work_dir}/mnt/airootfs/" _msg_info "Done!" _umount_airootfs mkdir -p "${work_dir}/iso/${install_dir}/${arch}"

1 0

[arch-releng] [archiso] [GIT] annotated tag v40 created (now f0441a1)
by Gerardo Exequiel Pozzi 24 Dec '18

24 Dec '18

This is an automated email from the git hooks/post-receive script. djgera pushed a change to annotated tag v40 in repository archiso. at f0441a1 (tag) tagging d320406c9319654c7e0c78ebf2045d662871e430 (commit) replaces v39 by Gerardo Exequiel Pozzi on Mon Dec 24 00:30:20 2018 -0300 - Log ----------------------------------------------------------------- tagging -----BEGIN PGP SIGNATURE----- iQFJBAABCAAzFiEEDzNNhpiIFXj2XSrlXtUUpFvVyTgFAlwgUs0VHHZtbGludXoz ODZAZ21haWwuY29tAAoJEF7VFKRb1ck4M1QIAL8Q0yPFd7ThEXdJGsutTRu8x+xZ GReY3RsxTZmh0q8R40WcAa80PEI7eWc5a40KTRCtehLf5NzbYjwBGewLJCqpUued T04beG216wdOoijsCHUQgW1lwcG7Uwj96RG9118M/8UKl2i/RiUWrb9otpf7Sk4y BPG8mcl+WtlJmo+6WDNyBrLgMxlVcXVgOkrZxdGOdrEej5FiDqiEj5Ugvn8JY47J x+zRFmKtDrxX1mkMIJpBoaj7taaVNNbk1tErF/o4vrO6RFvWGO1KrBzfxMIcSmGH sloF6xix5uYehnkh5OSFdybNoT6I3DoBbKgwTM2OANbc6g3HeXC73C8f27c= =3lZA -----END PGP SIGNATURE----- Christian Hesse (1): update download url for Shell_Full.efi Gerardo Exequiel Pozzi (1): prepare release ----------------------------------------------------------------------- No new revisions were added by this update. -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] [archiso] [GIT] branch testing updated (e23dbb4 -> d320406)
by Gerardo Exequiel Pozzi 24 Dec '18

24 Dec '18

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch testing in repository archiso. from e23dbb4 [configs/releng] Update amd-ucode license path add c060639 update download url for Shell_Full.efi new d320406 prepare release The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit d320406c9319654c7e0c78ebf2045d662871e430 Author: Gerardo Exequiel Pozzi <vmlinuz386(a)gmail.com> Date: Mon Dec 24 00:30:05 2018 -0300 prepare release Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386(a)gmail.com> Summary of changes: Makefile | 2 +- configs/releng/build.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] [archiso] [GIT] branch master updated (c060639 -> d320406)
by Gerardo Exequiel Pozzi 24 Dec '18

24 Dec '18

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch master in repository archiso. from c060639 update download url for Shell_Full.efi new d320406 prepare release The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit d320406c9319654c7e0c78ebf2045d662871e430 Author: Gerardo Exequiel Pozzi <vmlinuz386(a)gmail.com> Date: Mon Dec 24 00:30:05 2018 -0300 prepare release Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386(a)gmail.com> Summary of changes: Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[arch-releng] [archiso] [GIT] branch master updated (e23dbb4 -> c060639)
by Gerardo Exequiel Pozzi 13 Dec '18

13 Dec '18

This is an automated email from the git hooks/post-receive script. djgera pushed a change to branch master in repository archiso. from e23dbb4 [configs/releng] Update amd-ucode license path new c060639 update download url for Shell_Full.efi The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Detailed log of new commits: commit c060639baeece0b20950367699b458c4e077a7e6 Author: Christian Hesse <mail(a)eworm.de> Date: Wed Dec 12 14:25:06 2018 +0100 update download url for Shell_Full.efi https://bugzilla.tianocore.org/show_bug.cgi?id=1108 Signed-off-by: Christian Hesse <mail(a)eworm.de> Summary of changes: configs/releng/build.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0