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> Upstreaming Patches - Upstreaming #2809 (open): Upstream pcr/searx changeshttps://labs.parabola.nu/issues/28092020-06-15T13:49:01ZGNUtooGNUtoo@cyberdimension.orgUpstreaming Patches - Upstreaming #2807 (open): Upstream prboom-plus --disable-cpu-opthttps://labs.parabola.nu/issues/28072020-06-14T19:42:37ZGNUtooGNUtoo@cyberdimension.orgPackages - Bug #2805 (unconfirmed): Verify if the u-boot documentation is FSDG complianthttps://labs.parabola.nu/issues/28052020-06-14T18:54:57ZGNUtooGNUtoo@cyberdimension.orgUpstreaming Patches - Upstreaming #2799 (open): Upstream 0002-fix-Atmel-maXTouch-touchscreen-supp...https://labs.parabola.nu/issues/27992020-06-12T21:01:22ZGNUtooGNUtoo@cyberdimension.orgDocumentation - 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 #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> Packages - Freedom Issue #1130 (fixed): [virt-install] non-fsdg compliant distros and OS with lib...https://labs.parabola.nu/issues/11302016-10-28T01:08:36ZGNUtooGNUtoo@cyberdimension.org
<p>Hi, on my parabola server I installed libvirt, qemu-headless and qemu-headless-arch-extra.<br />I connected to it trough my parabola laptop,with virt-manager.</p>
<p>After connecting to the server, I clicked on "create a new virtual machine" <br />I then selected local install media (ISO image or cdrom)</p>
<p>When messing with OS type and version, many non-FSDG compliant GNU/Linux distributions(like Ubuntu 16.04) and operating system (Microsoft Windows 10) are shown.</p>
<p>Denis.</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 - Packaging Request #711 (fixed): xf86-video-qxlhttps://labs.parabola.nu/issues/7112015-05-03T16:13:51ZGNUtooGNUtoo@cyberdimension.org
<p>This will make parabola graphics way faster in a vm:<br /> <a class="external" href="https://aur.archlinux.org/packages/xf86-video-qxl/">https://aur.archlinux.org/packages/xf86-video-qxl/</a></p>
<p>Trisquel already has xf86-video-qxl.</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>