February 2021 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Dropping arptables/ebtables
by Sébastien Luttringer 13 Apr '21

13 Apr '21

Hello, I would like stop maintaining arptables and ebtables and drop them in [unsupported]. The future in the linux kernel is clearly nftables and keeping them in the repository present is of little interest these days. ebtables is still an hard dependency on others packages, but the iptables-nft package ship a remplacement based on nftables. I have not tested the compatibility, so if someone think it's not possible, please let me know. If you have spare time, I suggest you take a look at the nftable package and become a master in nft-fu. It is much more convenient and efficient than the iptables / ipset / ebtables / arptables solution. For the less enthusiastic about the command line, firewalld has an nftables backend. Regards, Sébastien "Seblu" Luttringer

2 2

[arch-dev-public] RFC: Using RFCs
by David Runge 02 Mar '21

02 Mar '21

Dear staff, I have begun work on a Request for Comment (RFC) process for Arch Linux and I am excited to now be able to open the first RFC... to introduce "Using RFCs" :) A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 Please visit the above link for discussion. Summary: A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment. Best, David P.S.: To all staff members, that do not have an SSO account yet, please get in touch with Sven-Hendrik Haase <svenstaro(a)archlinux.org> to be signed up and be able to participate in the discussion. -- https://sleepmap.de

5 10

[arch-dev-public] Mkinitcpio replacement with Dracut
by Giancarlo Razzolini 19 Feb '21

19 Feb '21

Hi All, Recently, Dave announced his intention to step down as mkinitcpio maintainer. I have been handling a few things on it, made some small changes to our mkinitcpio-busybox [0], closed a few old bugs, while also made sure some of the other bug reports are still valid. [1] I have been testing a few patches to mkinitcpio for a while to fix those bugs, but last week Dave and I had a discussion on IRC and we agreed that we could spend better time contributing somewhere else than keeping working with mkinitcpio. Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils [2] uses very old code. Even though ipconfig works, it has several drawbacks compared to using more modern tools. Not to mention that we have two use cases for mkinitcpio, which are base and systemd enabled initramfs. Even though we use by default our base enabled initramfs, we have to support systemd related issues and we have to keep developing our systemd hooks. I have been looking into dracut for some time now, I copied some stuff from them on a few of my own scripts and they also have an actual test suite, that we currently can't use on Arch, but I plan to change that. With this in mind, I have packaged dracut for Arch and put it on Extra [3]. I have been using a dracut initramfs for a while now to boot my encrypted partition. Surprisingly, I only had to create a small patch to one of the dm-crypt module scripts [4] In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will probably have to keep both packages on our repos for a long time, but once we are confident it's a good fit, we can replace mkinitcpio on our iso and base, so new installs get dracut by default. Please, drop in your comments as well. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… [1] https://bugs.archlinux.org/index.php?string=mkinitcpio&project=0 [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/ [3] https://www.archlinux.org/packages/extra/x86_64/dracut/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Cha…

4 7

[arch-dev-public] News draft: Moving to Zstandard images by default on mkinitcpio
by Giancarlo Razzolini 17 Feb '21

17 Feb '21

Hi Guys, So, mkinitcpio-30 (on [testing]), uses zstd by default for initramfs images, since all our kernels now support it. I plan to move mkinitcpio in the next 24-48 hours but, since I anticipate some people holding back 5.4 kernels, I want to send the following news announcement (here [0] is the md I'm using, so feel free to help there): ---- All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing]. If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf COMPRESSION to use one of the compressors supported, like gzip, otherwise you *will not* be able to boot images generated by mkinitcpio. Regards, Giancarlo Razzolini [0] https://md.archlinux.org/zh8Ac75qQPSieS8ftGBkIg

3 4

[arch-dev-public] hardlink in util-linux
by Christian Hesse 17 Feb '21

17 Feb '21

Hello everybody, upstream util-linux replaced the current implementation of hardlink (which we do not ship) with Debian's [0]. For util-linux 2.37 I plan to package the hardlink executable and set provides, conflicts and replaces on hardlink package. Any objections? [0] https://github.com/karelzak/util-linux/commit/2180ecc81b5f7635adbe541201064… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

3 2

[arch-dev-public] New archweb release
by Jelle van der Waa 14 Feb '21

14 Feb '21

Hi All, A new archweb release has been deployed on archlinux.org which features a new user facing change in the todolist functionality. When creating a todolist it's now possible to specify the "kind" of todolist either a "rebuild" or "task". A "rebuild" should be used for rebuilds as usual, a task for for basically everything which isn't a rebuild and usually doesn't go through [staging] etc. for example [1]. In the future archweb will be able to show the move commands for when a rebuild todolist is complete and there is work being done on detecting overlapping rebuilds. Another minor change which is not visible yet, is the importing of the rebuilderd build_id so in the future the non reproducible dashboard will have links to diffoscope/build log output. [1] https://archlinux.org/todo/remove-svn-propset/ Greetings, Jelle van der Waa

2 1

[arch-dev-public] strip command of binutils 2.36 changes ownership in fakeroot 1.25.3
by Levente Polyak 10 Feb '21

10 Feb '21

Hi all, We were recently made aware by a bug report [1] that when the strip executable from binutils 2.36-3 in [core] is run within a fakeroot, it does not keep the correct file ownership during stripping, but indiscriminately assigns ownership to root:root instead. This causes issues with executables that make use of setuid, setgid or capabilities and should be owned by a user other than root. The incorrect ownership in combination with these attributes could lead to a potential local privilege escalation. The issue is caused by the fact that binutils 2.36-3 is compiled using glibc 2.33, thus using a new syscall that fakeroot does not intercept correctly [2]. Following the bug report, pacman was patched [3] to correctly handle file ownership during stripping itself, instead of relying on binutils to restore the correct ownership. Additionally, all packages built with binutils 2.36 were scanned for usage of setuid, setgid or capabilities (either during packaging or using an install script). A small number of packages was found, but these turned out to be false positives or operated on files that are already supposed to be owned by root anyway. We conclude that users were not exposed to any vulnerable packages affected by this issue [4]. Note that the fix to pacman only covers the stripping process run automatically by pacman. If strip is run inside a PKGBUILD, either manually or as part of a build system like qmake [5], file ownership will still be set to root:root. Please double-check all your packages to see whether they execute strip on files that should not be owned by root. Since it is unclear when fakeroot will be updated to work with glibc 2.33, permissions will have to be fixed manually after running strip by an appropriate chown call in this case. Note however that generally strip should not be run inside a PKGBUILD at all as it breaks creating debug packages, and should be disabled if run by default by the build system. [1] https://bugs.archlinux.org/task/69584 [2] https://sourceware.org/pipermail/binutils/2021-February/115252.html [3] https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9… [4] https://md.archlinux.org/TAiOYgKzQl-1cJxDaQlB_g [5] https://github.com/archlinux/svntogit-packages/commit/138105f29cb29d7b7ebdf… Greetings, Arch Linux Security Team

1 0

[arch-dev-public] Celebrating the 1000th Arch Linux Security Advisory
by Levente Polyak 08 Feb '21

08 Feb '21

It has been a long ride since our first Arch Linux Security Advisory released in September 2014 [0], but we are proudly announcing our 1000th published advisory [1]. In early days, the user RbN started some efforts [2] to track issues in the ArchWiki. The journey of our team began with a call for help by our long-time developer Allan McRae [3], which -- as a joint effort of Remi Gacogne (rgacogne) and Levente Polyak (anthraxx) [4] -- lead to the founding of the structured effort known today as the Arch Linux Security Team. Without doubt the work and analysis is challenging and the overall workload massive. During our ongoing journey we have grown quite a lot and are happy to welcome Christian Rebischke (shibumi), Jelle van der Waa (jelle), Santiago Torres (sangy), Morten Linderud (Foxboron), Andrea Denisse Gómez (denisse) and Jonas Witschel (diabonas) to our team. Together we are able to offer a strong and successful security team that is continuously expanding and re-evaluating capacities to cover a broader area of our distro. In December 2016 during the annual Chaos Communication Congress, we released our central security tracker [5] to streamline our vulnerability tracking and mitigation workflow. The tracker replaces the ArchWiki page which was used previously for this purpose. For further details on our adventure, we would like to invite you to watch the Arch Conf 2020 talk "Rolling your own security team for fun and no profit at all" [6]. Because a healthy team is not just about technology, but also about the people behind it, we have met in a Jitsi video conference to celebrate this awesome achievement and to chink glasses :-) Sincerely, Your Security Team [0] https://lists.archlinux.org/pipermail/arch-security/2014-September/000097.h… [1] https://lists.archlinux.org/pipermail/arch-security/2021-January/001719.html [2] https://lists.archlinux.org/pipermail/arch-security/2014-March/000012.html [3] https://lists.archlinux.org/pipermail/arch-dev-public/2014-March/025952.html [4] https://lists.archlinux.org/pipermail/arch-security/2014-September/000098.h… [5] https://security.archlinux.org [6] https://media.ccc.de/v/arch-conf-online-2020-6394-rolling-your-own-security…

1 0

[arch-dev-public] Arch Linux in GSOC 2021
by Konstantin Gizdov 01 Feb '21

01 Feb '21

Hi all! Last year Arch Linux applied to be a mentoring organisation in the Google Summer of Code program. There were quite a few cool projects and lots of keen people. Unfortunately, we were not selected. However, I was hoping people are excited about trying again this year as well. I have already been contacted by a couple of people who saw the GSOC page on the Dev Wiki and are showing quite some interest. I presume, if we advertise we will get a lot of interested people. GSOC application period starts on January 29, 2021 for mentoring organisations and closes on February 19, 2021. We should make sure we satisfy the requirements [1]: 1. Mentor organisations must run an active open source or free software project. 2. Have produced and released software under an OSI approved license [2]. 3. Must not be based in a country currently embargoed by the United States. I think we do fall into those categories and I would suggest this year we start preparing a bit earlier to improve our chances. Let's try and coordinate an effort. Maybe start with the people keen on mentoring and collation of prospective project ideas. [1] - https://summerofcode.withgoogle.com/get-started/ [2] - https://opensource.org/licenses -- Regards, Konstantin

3 3

[arch-dev-public] News draft: Chromium losing Sync support in early March
by Evangelos Foutras 01 Feb '21

01 Feb '21

I would like to post this in ~48 hours from now. Review and corrections are welcome. :) ---- Google has [announced](https://blog.chromium.org/2021/01/limiting-private-api-availabil… that they are going to block everything but Chrome from accessing Google features (like Chrome sync) starting on March 15. This decision by Google is going to affect Arch's `chromium` package a bit earlier, on March 2, when Chromium 89 gets released. We know for sure that **data syncing** will stop working (passwords, bookmarks, etc.). Other features such as **geolocation** or **enhanced spell check** might continue to function for a bit longer. Extensions integrating with **Google Drive** are likely to be affected as well. After this change is implemented, we will be able to better evaluate the usefulness of Chromium builds with reduced functionality. It is not yet clear if Chromium will continue to be a viable browser for us to package, but we are trying to minimize the disruption to users. Other distros such as openSUSE and Fedora have already removed the soon-to-be-limited API keys from their Chromium 88 packages. Fedora's [advisory](https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5) provides a great deal of perspective on this and I also found this Hackaday [post](https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux… to be quite informative.

1 0