- Arch-general - lists.archlinux.org

Re: [arch-announce] The xz package has been backdoored
by Genes Lists 01 Apr '24

01 Apr '24

On Fri, 2024-03-29 at 18:55 +0000, Arch Linux: Recent news updates: David Runge wrote: > TL;DR: Upgrade your systems and container images **now**! > > Thanks for sharing. Truly an astounding revelation. This is a very, very sophisticated tool-chain attack along the lines of Ken Thompson's famous compiler trust example [1] Arch has been a strong advocate for reproducible builds [2] which can be part of a defense strategy [2]. I note that our xz package is marked as good in this regard [3]. I wonder what more we can reasonably do in the near term. Since git gives us decent tools to check what changed etc., I would imagine that can provide a stronger base on which to check things than working with tarballs or tarballs alone. This may have gone largely un-noticed for so long as people are probably more likely to check the source than the tarball itself. In this case, it seems, it was a primary developer doing the naughty - but they chose to leave the git repo alone and only infect the tarball. Question: -------- Would it make sense, therefore, to switch builds, where possible, away from tar files and instead pull directly from git source (signed tags where possible as usual etc)? Of course a git repo can also carry infections - perhaps taht's a little less likely. Or is this not worth the trouble? Gene [1] https://wiki.c2.com/?TheKenThompsonHack [2] https://reproducible-builds.org/ https://wiki.archlinux.org/title/DeveloperWiki:ReproducibleBuilds https://bootstrappable.org/ [3] https://reproducible.archlinux.org/ -- Gene

2 1

Which Emacs package?
by Abraham S.A.H. 31 Mar '24

31 Mar '24

Hey fellows; There are many Emacs packages available across Arch repositories and AUR. I list some of them here, in no specific order: From Extra repository: * emacs * emacs-wayland * emacs-nativecomp * emacs-nox From AUR and some third party repositories: * emacs-lucid-nativecomp * emacs-git * chaotic-aur/emacs-pgtk-native-comp-git I do not explain any of them for details. My audience is the one who already tried them, so can give me some advice. I already have tried all of them and also read archwiki's Emacs article. The Lucid one seems like the most stable with the least bugs, but with an archaic UI and without dnd support, but I do not use those scroll/menu/toolbars. Please, if you have any experience, share it with me. -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

5 6

man.archlinux.org/man/xzmore.1.uk is not in English
by u34＠net9.cf 30 Mar '24

30 Mar '24

https://man.archlinux.org/man/xzmore.1.uk manual page is not in English. Visually, I would say my local copy, man -l /usr/share/man/uk/man1/xzmore.1.gz , and xzmore.1.uk at man.archlinux.org have the same text. I also have many warnings, for a lot of packages, from pacman -Qkk. One of these warnings is about /usr/share/man/uk/man1/xzmore.1.gz. The warning is despite the fact the actaul data for /usr/share/man/uk/man1/xzmore.1.gz seems to agree with zgreping /var/lib/pacman/local/xz-5.6.1-2/mtree for that file. Local pacman version is 6.0.2-9. -- u34

3 4

Mensaje de ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ
by ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ 29 Mar '24

29 Mar '24

hello

1 0

Why after rebuild do I still get "warning: normalize: unknown key 'makepkgopt' in package description"?
by David C. Rankin 28 Mar '24

28 Mar '24

All, In whatever changed a week or so ago, pacman gave "... unknown key 'makepkgopt' in package description" for a slew of old packages left on my system from a decade of use. I've since gone back and removed all the packages and rebuilt the ones I need, but I still get a handful of errors for the 'normalize' package I've just built. What am I doing wrong? On cleaning the cache I get: 20:11 valkyrie:~> pms -c Packages to keep: All locally installed packages Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description Database directory: /var/lib/pacman/ :: Do you want to remove unused repositories? [Y/n] removing unused sync repositories... The normalize package is the one I just built and updated from AUR, e.g 20:12 valkyrie:~> pmqi normalize Name : normalize Version : 0.7.7-7 Description : A tool for adjusting the volume of WAV files to a standard level Architecture : x86_64 URL : http://normalize.nongnu.org Licenses : GPL Groups : None Provides : None Depends On : audiofile libmad vorbis-tools lame flac mpg123 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 118.49 KiB Packager : Unknown Packager Build Date : Tue 19 Mar 2024 08:07:32 PM CDT Install Date : Tue 19 Mar 2024 08:08:26 PM CDT Install Reason : Explicitly installed Install Script : No Validated By : None The PKGBUILD is: 20:13 valkyrie:~> cat arch/pkg/bld/normalize/PKGBUILD # $Id: PKGBUILD 266875 2017-11-15 14:29:11Z foutrelis $ # Maintainer: Giovanni Scafora <giovanni(a)archlinux.org> # Contributor: Tom Newsom <Jeepster(a)gmx.co.uk> pkgname=normalize pkgver=0.7.7 pkgrel=7 pkgdesc="A tool for adjusting the volume of WAV files to a standard level" arch=('x86_64') url="http://normalize.nongnu.org" license=('GPL') depends=('audiofile' 'libmad' 'vorbis-tools' 'lame' 'flac' 'mpg123') makedepends=('pkg-config' 'intltool') source=("http://download.savannah.gnu.org/releases/${pkgname}/${pkgname}-${pkgver}.t…" 'normalize-0.7.7-audiofile-pkgconfig.patch' 'normalize-0.7.7-m4.patch') md5sums=('1749b16fc7a08aa5d0cf9f76eeaa8436' '77d565e29bef11837e80347adfd42b58' '0b4bca7bf183275b9f939576ebad4233') prepare() { cd "${srcdir}/${pkgname}-${pkgver}" patch -Np1 -i "${srcdir}/normalize-0.7.7-audiofile-pkgconfig.patch" patch -Np0 -i "${srcdir}/normalize-0.7.7-m4.patch" touch AUTHORS NEWS ChangeLog #libtoolize --force --copy #aclocal -I m4 autoreconf -vi #automake --add-missing } build() { cd "${srcdir}/${pkgname}-${pkgver}" ./configure --prefix=/usr \ --mandir=/usr/share/man \ --with-audiofile \ --with-mad make } package() { cd "${srcdir}/${pkgname}-${pkgver}" make DESTDIR="${pkgdir}" install } Nowhere can I figure out where there is a "key 'makepkgopt' in package description". The package description is pkgdesc="A tool for adjusting the volume of WAV files to a standard level" Where is the "... key 'makepkgopt' ..." coming from? -- David C. Rankin, J.D.,P.E.

2 2

Re: Proposal to increase the default vm.max_map_count value
by Rein Fernhout (Levitating) 25 Mar '24

25 Mar '24

Seeing as other distributions have already adopted this change and gaming is a popular usecase for ArchLinux I do think this is a good thing to have. The default value will only be more of a bottleneck in the future. There's a balance in sticking to defaults. It'd be a shame if users need to alter multiple kernel parameters just to play modern games or run other applications with a high memory footprint. As I understand it there's no real downside to increasing this. Could someone with more knowledge of the kernel shed some light on any possible adverse effects that might come from increasing the default? I am also curious how the upstream discussed will go but I do not expect them to change it. Cheers, Levitating On 2024-03-25 09:10, Robin Candau wrote: > Hi everyone, > > I'm writing this mail as proposal to increase the default > `vm.max_map_count` [1] value in Arch Linux. > > The default `vm.max_map_count` 65530 value is making some Windows games > crash (or even prevent them to start at all) while being played through > Wine or Steam Play (Proton). > Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts > Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to > Valve for these games on that matter). > > In that regard, SteamOS is shipping an increased `vm.max_map_count` > default value to address the above issue and numerous distributions > have since then decided to implement that change on their side as well, > such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5]. > > While I'm aware that Arch is a user centric/DIY distro and everyone can > set their own `vm.max_map_count` value fairly easily, shipping an > increased value on our side would be a beneficial change to make in my > opinion as it would result in a smoother gaming experience out of the > box for our users without representing any downside/side effect (as far > as I'm aware). > > In terms of implementation, the change basically consists of shipping > the following sysctl file: > > ``` > # Increase the number of virtual memory areas that one process may > request > vm.max_map_count=1048576 > ``` > > For reference, Fedora added it to their systemd package [6], while > Ubuntu handled it at the procps level [7]. > I personally don't have a strong opinion on the implementation > way/place. > > To sum up, I think this would be a reasonable and positive change to > make to our distro. > I'd be happy to read your thoughts (or eventual objection)! 😊 > > [1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count > [2] > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 > [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount > [4] https://github.com/NixOS/nixpkgs/pull/238459 > [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 > [6] > https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf > [7] > https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4…

3 2

Do we need to fix dbus-broker-launch journal warnings -- or just ignore?
by David C. Rankin 25 Mar '24

25 Mar '24

Are we supposed to do anything to fix these dbus-broker-launch journal warnings? Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Tumbler.Thumbnailer1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Thumbnailer1'. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Noticed file-system modification, trigger reload. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Thunar.FileManager1.service' is not named after the D-Bus name 'org.freedesktop.FileManager1'. Mar 24 02:15:31 valkyrie dbus-broker-launch[1130]: Service file '/usr/share/dbus-1/services/org.xfce.Tumbler.Cache1.service' is not named after the D-Bus name 'org.freedesktop.thumbnails.Cache1'. I don't have XFCE installed, but do have thunar installed stand-alone for fluxbox. -- David C. Rankin, J.D.,P.E.

3 6

Where to find old png2ico PKGBUILD it was dropped to AUR?
by David C. Rankin 24 Mar '24

24 Mar '24

All, Cleaning up old packages, I still need the png2ico utility. It is no longer in AUR replaced by elphicon which uses that abomination electron. I need to know if the old PKGbUILD for Arch png2ico still exists in some historical form somewhere. It would save writing another. What say the historians, does such a thing exist? -- David C. Rankin, J.D.,P.E.

5 6

CLI access to dropbox
by Jeanette C. 22 Mar '24

22 Mar '24

Hey hey, I need CLI access to my dropboox account. I'm still running dropbox-cli, which is marked as out-of-date and I couldn't update to the latest version. Using trizen, I get this error message: [...] -> Found dropboxd-fallback.patch ==> Validating source files with sha256sums... dropbox-cli-2023.09.06.py ... FAILED dropboxd-fallback.patch ... Passed ==> ERROR: One or more files did not pass the validity check! :: Unable to build dropbox-cli - makepkg exited with code: 1 There is dbxcli a commandline interface written in Go, which also fails to build with this: no required module provides package github.com/dropbox/dbxcli: go.mod file not found in current directory or any parent directory; see 'go help modules' ==> ERROR: A failure occurred in build(). Aborting... :: Unable to build dbxcli - makepkg exited with code: 4 Has any one else perhaps encountered these errors and found a fix or can suggest another commandline app that will give easy access to an existing dropbox account. Best wishes and thanks, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c But tell me what happens when it stops? <3 (Britney Spears)

4 4

Re: Revising Go packaging guidelines (2024)
by Daniel Martí 19 Mar '24

19 Mar '24

Hello, I'm a long time user and only an occasional contributor, but I do have experience on the Go side, so perhaps my input is helpful. I keep forgetting that I can't reply to arch-dev-public, so I'm replying to the poster and arch-general. Overall I agree with simplifying and modernizing the Go guidelines. Practically every Go project uses modules now, not using Go's own linker will come as a surprise to most Arch users, and I've always found all those env vars and flags on top of "go build" to be a surprising setup. Your suggestion of just three flags in GOFLAGS seems far better. That said, I think your suggestion to just use "go build" everywhere is unfortunately not realistic, at least not yet given my experience out in the wild. That's because runtime/debug.ReadBuildInfo isn't actually quite enough. It does embed a module semver version when building via GOPROXY, e.g. "go install cuelang.org/go/cmd/cue@latest", and it also embeds VCS information when doing a local build inside a git clone, e.g. "git checkout master && go install ./cmd/cue". Crucially, however, in the latter case the main module lacks a module semver version, and the stamped VCS information is just a commit hash and a timestamp, without any notion about what the current or last semver tag was. This is a known limitation, and tracked at https://github.com/golang/go/issues/50603. Until this is fixed, some projects still support the ldflags hack, or hard-code a version string to manually change at every release, or simply live with "devel" or "commit X" versions when built locally. Upstream accepted the proposal, but it may be another couple of years before it's shipped and widespread enough that the ldflags hack is gone for good. I also see that you suggest adding -buildvcs=false to GOFLAGS; I'm not sure if that is the right choice or not for Arch, but consider the limitation of the BuildInfo version string I explain above. In the Go programs that I write, I make the "version" command or flag show the VCS information, precisely because otherwise there's no way to tell what the real version might actually be: > $ git rev-parse HEAD # in https://github.com/cue-lang/cue > b648cf45d5adc6592633206cc126670906881729 > $ git describe --tags # note how I'm a few commits after the > v0.9.0-0.dev tag > v0.9.0-0.dev-4-gb648cf45$ go install ./cmd/cue > $ cue version # the version at the top is a hard-coded string named > "fallbackVersion" > cue version v0.9.0-0.dev > > go version devel go1.23-0a6f05e30f 2024-03-17 15:57:54 +0000 > -buildmode exe > -compiler gc > DefaultGODEBUG > asynctimerchan=1,httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1,winreadlinkvolume=0,winsymlink=0 > CGO_ENABLED 1 > GOARCH amd64 > GOOS linux > GOAMD64 v3 > vcs git > vcs.revision b648cf45d5adc6592633206cc126670906881729 > vcs.time 2024-03-18T07:55:11Z > vcs.modified false TL;DR: sounds good to me, just don't assume that every project can simply "go build" now, and consider not disabling -buildvcs, at least for the time being. Cheers. On 18/03/2024 23.17, kpcyrd wrote: > hello, > > the Arch Linux Go packaging guidelines[0] currently suggest this for > building software written in Go: > > > export CGO_CPPFLAGS="${CPPFLAGS}" > > export CGO_CFLAGS="${CFLAGS}" > > export CGO_CXXFLAGS="${CXXFLAGS}" > > export CGO_LDFLAGS="${LDFLAGS}" > > export GOFLAGS="-buildmode=pie -trimpath -ldflags=-linkmode=external > -mod=readonly -modcacherw" > > > > # or alternatively you can define some of these flags from the CLI > options > > go build \ > > -trimpath \ > > -buildmode=pie \ > > -mod=readonly \ > > -modcacherw \ > > -ldflags "-linkmode external -extldflags \"${LDFLAGS}\"" \ > > . > > [0]: https://wiki.archlinux.org/title/Go_package_guidelines > > There's also section "2.2.2 Supporting debug packages" which > contradicts the previous section. > > ## Suggestion > > I'd like to propose changing this to something like: > > > prepare() { > > cd ${pkgname}-${pkgver} > > go mod download > > } > > > > build() { > > cd ${pkgname}-${pkgver} > > go build . > > } > > > > package() { > > cd ${pkgname}-${pkgver} > > install -Dm0755 -t "${pkgdir}/usr/bin/" "${pkgname}" > > } > > Plus any extra flags (for example for debug packages to work, if any > are needed at all - there's a note about this towards the end of this > essay). Instead of suggesting two (three) different approaches, the > packaging guidelines should endorse argv over environment variables > (how to set them with environment variables can still be documented in > a later section of the guideline). The reason I'm suggesting this: > > ## Passing flags over argv > > Setting these options through environment variables is for cases when > `go` isn't executed directly by our PKGBUILD, but instead by some > indirection like a Makefile. Makefiles are more popular in Go projects > than they are in e.g. Rust projects, but presumably because for many > years (10+) there was no analogous to `env!("CARGO_PKG_VERSION")` to > embed a version string into the binary for --version output. > > Since almost exactly two years ago, in Go 1.18 released March 2022, > there's now `runtime/debug.ReadBuildInfo` which gives you a reference > to an embedded struct that contains a version string[1]. > > [1]: https://pkg.go.dev/runtime/debug#ReadBuildInfo > > Hopefully more Go projects are going to favor this in the future over > custom build scripts and passing `-X main.Version=...` with output > from `git describe --tags`. If this catches on, people might think of > `go build` more like they currently think of `cargo build` and I think > the Go package guideline should encourage this. > > Not just for Go but for software in general, using `git describe` > should be considered an anti-pattern. In the way the Arch Linux build > system currently works, only the checked out files are authenticated > and pinned by sha256sums= and friends, but `git describe` explicitly > works on unauthenticated git objects in `.git/`. I've published a > writeup on how to take advantage of this on the reproducible builds > list in September 2023[2]. > > [2]: > https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/0… > > ## Using the Go native Linker > > Binaries built by the Go compiler have been reproducible for a long > time, however Go binaries built by Arch Linux usually aren't. This has > led to some confusion, with bug reports to upstreams of Go software > because it wasn't obvious that the package not being reproducible in > this case isn't a problem in upstream's source code, but the way Arch > Linux compiles it. > > Arch Linux generally prefers binaries with hardening flags enabled[3] > and therefore explicitly opts into a non-default linker (Cgo), but it > seems to be the unpopular choice. Cgo seems to have less support than > normal Go on Linux (evidently, since Cgo has been known to have > reproducible build issues for years now). Other Linux distributions > seem to stick to normal Go too, Nix has Cgo off by default[4] and > searching through nixpkgs for "buildGoModule" yields about 2k results, > searching for "CGO_ENABLED" has 105 results, with more than half being > "CGO_ENABLED=0" though. Alpine Linux only sets GOFLAGS globally[5] > (which Arch Linux currently doesn't), searching for `rg -l --multiline > '\tgo.*build'` in aports matches 356 files, `rg -l CGO_ENABLED=0` > matches 23 files and `rg -l CGO_ENABLED=1` matches 18 files. > > [3]: https://github.com/jvoisin/compiler-flags-distro > [4]: > https://github.com/NixOS/nixpkgs/blob/b081342f1c16e4cbe4f40f139bbdda1475ea3… > [5]: https://git.alpinelinux.org/abuild/tree/default.conf?h=3.12.0#n5 > > The global GOFLAGS as specified in Alpine Linux are: > > > export GOFLAGS="-buildmode=pie -modcacherw -trimpath -buildvcs=false" > > Which we could consider setting globally too, like we do with RUSTFLAGS. > > Figuring out what Debian does was somewhat challenging, their > integration with the go build system is called dh-golang[6], they seem > to set CGO_ENABLED=1 only when cross-compiling, with go >= 1.13 > (released 2019) they seem to build with `go install -trimpath ...` and > no further GOFLAGS environment variable. > > [6]: > https://salsa.debian.org/go-team/packages/dh-golang/-/blob/debian/sid/lib/D… > > I understand the concern of Go possibly being more prone to ROP-style > exploits when 1) built with the native linker and 2) used with e.g. a > vulnerable version of libgit2, however, as of 2024, there have been > barely any memory-corruption based exploits for Go software. > > ## Motivation > > - Most of our Go software is currently not reproducible due to Cgo, > including core/libcap, which is the last unreproducible package in > docker.io/library/archlinux > - The barrier for packaging Go in Arch Linux is currently somewhat > high (compared to e.g. packaging Rust), the guideline requires too > much interpretation and could be improved > - Quirks that are only needed for old Go projects (like 2.1.1) should > be listed towards the end instead of being the first code block in the > guideline > > --- > > cheers, > kpcyrd

1 0