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

[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

[arch-dev-public] Decommissioning dragon and upgrading to new box
by Sven-Hendrik Haase 30 Jan '21

30 Jan '21

Hey everyone, A new sponsorship term for dragon (our build server for those who weirdly enough don't know) was coming up and as the box was getting pretty slow for 2021 I felt perhaps we should also try for an upgrade. Anyway so Hetzner kindly agreed to give us a sponsorship deal for a bigger box which is roughly twice as fast as dragon. It'll be called "mir" and will be made available in the next few days. dragon is scheduled to be decommissioned on the 19th of January. Since nobody is supposed to be storing any data on dragon, we won't be performing a home directory transfer. Still, if there's any data you care about on dragon, please back it up until the 19th. Have fun with the new box! Cheers, Sven

1 2

[arch-dev-public] Chromium losing Sync support on March 15
by Evangelos Foutras 28 Jan '21

28 Jan '21

It looks like Sync will only work with official Chrome starting two months from now. [1] It is understandable to some extend, perhaps to guard against malicious applications using unofficial (non-Chrome) API keys and tricking users to log into their account. This argument doesn't hold much ground in the context of trusted builds like our chromium package, but I doubt Google would bother to work with us (i.e.: each individual Linux distro) on this to find a workable solution going forward. This is intended as a heads-up; I am not sure what we're going to do yet. [1] https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

16 33

[arch-dev-public] build.archlinux.org now available
by Sven-Hendrik Haase 26 Jan '21

26 Jan '21

Hello all, A new bigger and badder build box is now available to all packagers at build.archlinux.org. home dirs (but not .cache) have been transferred to the new box from dragon and all users should have access. The new box, as previously mentioned, is roughly twice as fast as dragon and has enough memory and storage to handle some load. dragon is scheduled to be decommissioned on the 31st of January so you still have some time to check whether everything was properly transferred. Have fun! Sven

3 3

Re: [arch-dev-public] News draft: PHP 8.0 is available
by Pierre Schmitz 26 Jan '21

26 Jan '21

Thanks for the ihint. I'll use "suffix" instead. (I did a brief research about the difference between postfix and suffix; I can't say I fully understand it :-)) 'll also add a note about the modules that are available for php7 as well as users might need to manually install them. I'll probably post this tomorrow or the day after. Greetings, Pierre On Mon, Jan 25, 2021 at 8:19 PM Chester Wisniewski <chetw(a)zuzax.com> wrote: > > I would recommend changing "postfix" to suffix. Postfix is a package, suffix works better in English. > > Chester > > -----Original Message----- > From: Pierre Schmitz via arch-dev-public <arch-dev-public(a)lists.archlinux.org> > Reply-To: Public mailing list for Arch Linux development <arch-dev-public(a)lists.archlinux.org> > To: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> > Cc: Pierre Schmitz <pierre(a)archlinux.de> > Subject: [arch-dev-public] News draft: PHP 8.0 is available > Date: Mon, 25 Jan 2021 19:04:51 +0100 > > Hi all, > > I'd like to move the PHP 8 rebuild to [extra] soon. Here is a little > news draft to mainly inform users about the new php7 package for > legacy software: > > --- > The php package has been updated to version 8.0(1). Please refer to > the upstream migration guide(2). As some applications are not > compatible with PHP 8 yet we provide a php7 package which can be > installed alongside version 8. Packages that depend on PHP reflect > this update and will require php7 if needed. You might need to update > your configuration accordingly. PHP 7 binaries and configuration have > the "7" postfix: > * /usr/bin/php -> /usr/bin/php7 > * /etc/php -> /etc/php7 > * /usr/bin/php-fpm -> /usr/bin/php-fpm7 > * /usr/lib/systemd/system/php-fpm.service -> > /usr/lib/systemd/system/php-fpm7.service > * /run/php-fpm -> /run/php-fpm7 > Note that support for php7 will be limited and likely be dropped in > about a year(3) depending on how soon the majority of applications > will be compatible with version 8. > --- > 1) https://www.php.net/releases/8.0/en.php > 2) https://www.php.net/manual/en/migration80.php > 3) https://www.php.net/supported-versions.php > > Let me know if I should add or change anything. > > Greetings, > > Pierre >

1 0