Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552023-12-26T11:59:52ZParabola Issue Tracker
Redmine Packages - Bug #3561 (info needed): wp-cli not built from source (but source code is provided)https://labs.parabola.nu/issues/35612023-12-26T11:59:52ZGNUtooGNUtoo@cyberdimension.org
<p>The pkp-cli recipe consists in the following:</p>
<pre>
build() {
cd "$_archive"
composer install --no-interaction --prefer-dist --no-scripts
php -dphar.readonly=0 utils/make-phar.php wp-cli.phar
}
</pre>
<p>After installing php-cli I can get the source code in this way:</p>
<pre>
# cd $(mktemp -d)
# phar extract -f /usr/bin/wp
# find > wp-cli-files.txt
</pre>
<p>wp-cli-files.txt is attached</p>
<p>I've looked at a random file (usr/bin/wp/vendor/wp-cli/wp-config-transformer/src/WPConfigTransformer.php) and the source code is perfectly readable so it does not look transformed in any way.</p>
<p>It is possible to build wp-cli from source, and there is a tutorial for that here: <a class="external" href="https://make.wordpress.org/cli/handbook/contributions/pull-requests/#setting-up">https://make.wordpress.org/cli/handbook/contributions/pull-requests/#setting-up</a></p>
<p>Do we need to remove wp-cli because it's not built from source or is the fact that it provide source code sufficient?</p> Packages - Bug #3212 (unconfirmed): valgrind broken on armv7hhttps://labs.parabola.nu/issues/32122022-04-01T22:09:07ZGNUtooGNUtoo@cyberdimension.org
<p>on armv7h, valgrind is broken:<br /><pre>
$ make check
cc main.c -o main
valgrind --leak-check=full ./main
==10136== Memcheck, a memory error detector
==10136== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10136== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==10136== Command: ./main
==10136==
==10136== Invalid write of size 4
==10136== at 0x401B100: _dl_start (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7b54 is on thread 1's stack
==10136== 120 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401236C: _dl_setup_hash (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7b68 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4019548: _dl_sysdep_start (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7aec is on thread 1's stack
==10136== 104 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4015858: __GI___tunables_init (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7a8c is on thread 1's stack
==10136== 96 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4012544: _dl_sort_maps_init (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7afc is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401FC24: sbrk (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7af0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401BBF0: dl_main (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78dc is on thread 1's stack
==10136== 528 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400C488: _dl_new_object (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78ac is on thread 1's stack
==10136== 48 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400BF50: __minimal_calloc (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78b0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400BDF4: __minimal_malloc (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78ac is on thread 1's stack
==10136== 24 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400C3B8: _dl_add_to_namespace_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78e0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4019CCC: _dl_discover_osversion (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f76ec is on thread 1's stack
==10136== 496 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400716C: _dl_init_paths (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78bc is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x40181F8: _dl_important_hwcaps (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7844 is on thread 1's stack
==10136== 112 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018CAC: _dl_hwcaps_split_masked (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7858 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018BA0: _dl_hwcaps_split (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7840 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018140: copy_hwcaps (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f780c is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401B074: audit_list_add_dynamic_tag (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78f0 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x40164D4: _dl_audit_activity_map (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78b0 is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401BACC: handle_preload_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f68dc is not stack'd, malloc'd or (recently) free'd
==10136==
==10136==
==10136== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==10136== Access not within mapped region at address 0xBD9F68DC
==10136== at 0x401BACC: handle_preload_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== If you believe this happened as a result of a stack
==10136== overflow in your program's main thread (unlikely but
==10136== possible), you can try to increase the size of the
==10136== main thread stack using the --main-stacksize= flag.
==10136== The main thread stack size used in this run was 8388608.
==10136==
==10136== HEAP SUMMARY:
==10136== in use at exit: 0 bytes in 0 blocks
==10136== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==10136==
==10136== All heap blocks were freed -- no leaks are possible
==10136==
==10136== For lists of detected and suppressed errors, rerun with: -s
==10136== ERROR SUMMARY: 33 errors from 20 contexts (suppressed: 0 from 0)
make: *** [Makefile:4: check] Segmentation fault (core dumped)
</pre></p>
<p>Here's my valgrind version on armv7h:<br /><pre>
$ pacman -sS valgrind
extra/valgrind 3.18.1-3 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>On i686 I have instead:<br /><pre>
$ make check
cc main.c -o main
valgrind --leak-check=full ./main
==29363== Memcheck, a memory error detector
==29363== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29363== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==29363== Command: ./main
==29363==
Hello world
==29363==
==29363== HEAP SUMMARY:
==29363== in use at exit: 0 bytes in 0 blocks
==29363== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==29363==
==29363== All heap blocks were freed -- no leaks are possible
==29363==
==29363== For lists of detected and suppressed errors, rerun with: -s
==29363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
</pre></p>
<p>With the following valgrind version:<br /><pre>
$ pacman -sS valgrind
extra/valgrind 3.18.1-4.0 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>And on x86_64:<br /><pre>
# make check
cc main.c -o main
valgrind --leak-check=full ./main
==724655== Memcheck, a memory error detector
==724655== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==724655== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==724655== Command: ./main
==724655==
Hello world
==724655==
==724655== HEAP SUMMARY:
==724655== in use at exit: 0 bytes in 0 blocks
==724655== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==724655==
==724655== All heap blocks were freed -- no leaks are possible
==724655==
==724655== For lists of detected and suppressed errors, rerun with: -s
==724655== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
</pre></p>
<p>With the following valgrind version:<br /><pre>
# pacman -sS valgrind
extra/valgrind 3.18.1-4 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>I've attached the files used by they are a simple hello world and a Makefile that runs valgrind --leak-check=full ./main</p> Packages - Bug #3209 (confirmed): wget on armv7h fails to verify certificateshttps://labs.parabola.nu/issues/32092022-03-30T13:01:59ZGNUtooGNUtoo@cyberdimension.org
<p>On armv7h wget fails to verify the certificates:<br /><pre>
$ wget https://parabola.nu
--2022-03-30 14:56:30-- https://parabola.nu/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving parabola.nu (parabola.nu)... 93.95.226.249, 2001:470:1f09:96::2
Connecting to parabola.nu (parabola.nu)|93.95.226.249|:443... connected.
The certificate has not yet been activated
$ echo $?
5
</pre></p>
<p>But curl works fine:<br /><pre>
$ curl https://parabola.nu
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>
</pre></p>
<p>And wget also works fine on x86_64</p>
<p>Bill Auger was also able to reproduce the bug.</p> Packages - Bug #3130 (not-a-bug): Upload PKGBUILDs and patches as part of the source release of p...https://labs.parabola.nu/issues/31302021-11-21T02:50:59ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
It's far too easy to not keep the abslibre git repository in sync with the packages. For instance:
<ul>
<li>A developer can push to abslibre and forget to build the package, or that developer might want to build the package later on for various reasons. In addition we have several architectures, so the package in abslibre might not match the one currently available for a given architecture. I personally often push before having built the package and often forget to build it for ARM too, especially if my ARM builder is offline, and I often forget about it if the build takes too long.</li>
<li>A developer can also push the package and forget to push the corresponding git commits to abslibre. That probably happens when developers upload the package first to make sure that the git source and package are kept in sync, but forget to push the related git commits.</li>
</ul>
<p>In either cases users and other developers can be situations where they can't get the corresponding PKGBUILD source code.</p>
<p>As humans are error prone, and that all Parabola developers are volunteers, I think it would be an interesting feature to add as it could help us cope with situations where the people that can fix is not available or that the information is lost (for instance if a modified PKGBUILD was used to build the package due to a human error).</p>
<p>It could also make sure that developers that are already overworked are not blamed for mistakes that are way to easy to do, and make it clear that instead the process of package submission is too much error prone and should be fixed here.</p>
<p>Ideally it would also be a good idea to upstream that feature in Arch Linux as it would be maintained for us.</p>
<p>Denis.</p> libretools - Bug #2936 (fixed): librestage not working with pacman-mirrorlisthttps://labs.parabola.nu/issues/29362020-11-23T00:34:38ZGNUtooGNUtoo@cyberdimension.org
<p>I have the following error:<br /><pre>
$ ls
mirrorlist-20201122.txt pacman-mirrorlist-20201122-1.parabola2-x86_64-package.log
pacman-mirrorlist-20201122-1.parabola2-any.pkg.tar.xz pacman-mirrorlist-20201122-1.parabola2-x86_64-prepare.log
pacman-mirrorlist-20201122-1.parabola2-any.src.tar.gz PKGBUILD
$ librestage
==> ERROR: Nothing was staged
</pre></p>
<p>How is it possible to librestage pacman-mirrorlist?</p>
<p>Denis.</p> Packages - Bug #2805 (unconfirmed): Verify if the u-boot documentation is FSDG complianthttps://labs.parabola.nu/issues/28052020-06-14T18:54:57ZGNUtooGNUtoo@cyberdimension.orglibretools - Bug #2648 (info needed): libremakepkg failing on i686 with Operation not permitted o...https://labs.parabola.nu/issues/26482020-03-03T15:41:24ZGNUtooGNUtoo@cyberdimension.orglibretools - Bug #2103 (not-a-bug): [linux-libre] cannot build due to missing gpg keyhttps://labs.parabola.nu/issues/21032018-11-28T14:41:37ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>I was trying to improve the linux-libre PKGBUILD by trying to fix the bug <a class="issue tracker-1 status-5 priority-3 priority-default closed" title="Bug: [linux-libre] cannot build due to missing gpg key (not-a-bug)" href="https://labs.parabola.nu/issues/2103">#2103</a>, however I cannot build it:<br /><pre>
$ sudo libremakepkg -n parabola-armv7h
[...]
| ==> Verifying source file signatures with gpg...
| linux-libre-4.19-gnu.tar.xz ... FAILED (unknown public key BCB7CF877E7D47A7)
| patch-4.19-gnu-4.19.2-gnu.xz ... FAILED (unknown public key BCB7CF877E7D47A7)
| logo_linux_clut224.ppm ... FAILED (unknown public key 227CA7C556B2BA78)
| logo_linux_mono.pbm ... FAILED (unknown public key 227CA7C556B2BA78)
| logo_linux_vga16.ppm ... FAILED (unknown public key 227CA7C556B2BA78)
| rcn-libre-4.19.2-armv7-x5.patch ... FAILED (unknown public key 227CA7C556B2BA78)
| ==> ERROR: One or more PGP signatures could not be verified!
| ==> ERROR: Could not download sources.
</pre></p> Documentation - Bug #1867 (open): Warn users about arbitrary execution of code with full disk enc...https://labs.parabola.nu/issues/18672018-07-03T00:43:36ZGNUtooGNUtoo@cyberdimension.org
<p>Users using full disk encryption without /boot in clear typically expects that it's harder to gain arbitrary execution of code inside the distribution that resides in it.</p>
An attacker would then need to temper with the non-encrypted code that runs before or during the opening of the encrypted partition. For instance:
<ul>
<li>If the user uses GRUB_ENABLE_CRYPTODISK=y the attacker would need to temper with the tiny GRUB code that is embedded on the internal disk.</li>
</ul>
However there are some cases where the attacker might need to reflash the boot software (BIOS, UEFI, etc):
<ul>
<li>If the user uses an external USB key to boot and the internal computer storage is fully encrypted</li>
<li>If users are using Libreboot or Coreboot with GRUB to open the encrypted partition with the internal storage fully encrypted<br />This can be mitigated by adding seals on the laptop screws (such as with nail polish or glue with glider)</li>
</ul>
<p>An other way for an attacker would be to try to temper with the storage device content and/or firmware: Authenticated encryption is pretty new in cryptsetup, and the commonly used encryption algorithms are not authenticated. So there may be ways to gain arbitrary execution of code either by injecting content by manipulating encryption parameters or by trying to implement some way to recover the key by using an oracle (as fsck may correct the corrupted data) but it's probably far from trivial to attempt any of that.</p>
<p>However there is an easier way with Parabola: if the attacker can guess the root= kernel parameter for instance root=/dev/laptop-rootfs, the attacker could stick an SD card with the same vg and lv.</p>
I can reproduce it with:
<ul>
<li>A thinkpad under Coreboot that has an SD card slot</li>
<li>The same VG/LV than the rootfs on a SD card</li>
<li>The encryption key being inside the initramfs</li>
</ul>
<p>I'll try to gather more information on the conditions necessary to trigger that problem (I had the issue several weeks ago).</p>
<p>This probably affects Libreboot too as there is documentation about such setup there too.</p> Packages - Bug #1655 (fixed): Update virt-manager on i686 (cannot install due to dependency issue) https://labs.parabola.nu/issues/16552018-03-08T00:28:51ZGNUtooGNUtoo@cyberdimension.org
<p>Virt-install seem to have been updated in the repositories but not virt-manager:<br /><pre>
# uname -m
i686
# pacman -sS virt-manager
community/virt-manager 1.4.3-2
Desktop user interface for managing virtual machines
# pacman -S virt-manager
resolving dependencies...
warning: cannot resolve "virt-install=1.4.3", a dependency of "virt-manager"
:: The following package cannot be upgraded due to unresolvable dependencies:
virt-manager
# pacman -sS virt-install
libre/virt-install 1.5.0-1.parabola1 [installed]
Console user interface for managing virtual machines, without non-FSDG compliant distros and operating
systems support
</pre></p> Packages - Bug #1267 (fixed): wrong dependencies for pcr/mat: mutagen is not optionalhttps://labs.parabola.nu/issues/12672017-03-28T23:01:16ZGNUtooGNUtoo@cyberdimension.org
<p>Here's how it ends up without mutagen:<br /><pre>
$ mat-gui
Traceback (most recent call last):
File "/usr/bin/mat-gui", line 18, in <module>
from libmat import mat
File "/usr/lib/python2.7/site-packages/libmat/mat.py", line 22, in <module>
import strippers # this is loaded here because we need LOGGING_LEVEL
File "/usr/lib/python2.7/site-packages/libmat/strippers.py", line 5, in <module>
import mutagenstripper
File "/usr/lib/python2.7/site-packages/libmat/mutagenstripper.py", line 6, in <module>
from mutagen.flac import FLAC
ImportError: No module named mutagen.flac
$ mat
Traceback (most recent call last):
File "/usr/bin/mat", line 10, in <module>
from libmat import mat
File "/usr/lib/python2.7/site-packages/libmat/mat.py", line 22, in <module>
import strippers # this is loaded here because we need LOGGING_LEVEL
File "/usr/lib/python2.7/site-packages/libmat/strippers.py", line 5, in <module>
import mutagenstripper
File "/usr/lib/python2.7/site-packages/libmat/mutagenstripper.py", line 6, in <module>
from mutagen.flac import FLAC
ImportError: No module named mutagen.flac
</pre></p>
<p>After installing mutagen it launches:<br /><pre>
# pacman -S mutagen
[...]
$ mat
ERROR:root:Unable to find exiftool: no images support
usage: mat [-h] [-a] [-b] [-L] [-c] [-d] [-l] [-v] [files [files ...]]
$ mat-gui # no crash
</pre></p>
<p>Mutagen is an optional dependency, but given that it crashes without it, it should probably be a required dependency instead:<br /><pre>
$ pacman -Q -i mat
[...]
Optional Deps : perl-image-exiftool: extended image support, [installed]
mutagen: extended audio format support [installed]
</pre></p> Packages - Bug #1266 (fixed): [weboob] [pcr] Update to 1.2https://labs.parabola.nu/issues/12662017-03-27T17:52:36ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>In AUR the version is at 1.2-2, we are still at 1.0-1<br /><a class="external" href="https://aur.archlinux.org/packages/weboob/">https://aur.archlinux.org/packages/weboob/</a></p>
<p>Denis.</p> Documentation - Bug #872 (fixed): Duplicated standalone installation instructions need to be mergedhttps://labs.parabola.nu/issues/8722015-11-22T18:06:11ZGNUtooGNUtoo@cyberdimension.org
<p>Move <a class="external" href="https://wiki.parabola.nu/User:Isacdaavid/Sandbox">https://wiki.parabola.nu/User:Isacdaavid/Sandbox</a> the the main namespace, like <a class="external" href="https://wiki.parabola.nu/Parabola_ARM_installation">https://wiki.parabola.nu/Parabola_ARM_installation</a></p> Packages - Bug #713 (fixed): x86, x86_64: libre/handbrake-svn, libre/handbrake-cli-svn: still lin...https://labs.parabola.nu/issues/7132015-05-06T21:55:40ZGNUtooGNUtoo@cyberdimension.org
<p>They have to be recompiled:</p>
<p>% ghb<br />ghb: error while loading shared libraries: libx264.so.142: cannot open shared object file: No such file or directory</p>
<p>% HandBrakeCLI <br />HandBrakeCLI: error while loading shared libraries: libx264.so.142: cannot open shared object file: No such file or directory</p>
<p>Denis.</p> Packages - Bug #275 (not-a-bug): vlc+totem (/usr/lib/libdvdnav.so.4) segfault while opening a dvd.https://labs.parabola.nu/issues/2752012-12-12T13:03:04ZGNUtooGNUtoo@cyberdimension.org
<p>gdb on totem gives that as the last functions in the stack:<br />#0 0xac3206ec in dvdnav_describe_title_chapters () from /usr/lib/libdvdnav.so.4<br /><a class="issue tracker-1 status-2 priority-5 priority-high3 closed" title="Bug: [bugs/labs] Migrate bug tracker (fixed)" href="https://labs.parabola.nu/issues/1">#1</a> 0xac35e156 in ?? () from /usr/lib/gstreamer-1.0/libgstresindvd.so</p>
<p>I've libdvdread, libdvdnav and libdvdcss...</p>
<p>Denis</p>