Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552023-04-22T17:10:16ZParabola Issue Tracker
Redmine Packages - Freedom Issue #3471 (unconfirmed): [netctl] unclear licensehttps://labs.parabola.nu/issues/34712023-04-22T17:10:16ZGNUtooGNUtoo@cyberdimension.org
The netctl source code seems to be available here: <a class="external" href="https://gitlab.archlinux.org/archlinux/netctl">https://gitlab.archlinux.org/archlinux/netctl</a> and after downloading it, the only hints for a license are:
<ul>
<li>that there is a COPYING file</li>
<li>that for some reasons <a class="external" href="https://gitlab.archlinux.org/archlinux/netctl">https://gitlab.archlinux.org/archlinux/netctl</a> has a GNU GPLv3 button that then brings to a page that has this text: "This project is licensed under the GNU General Public License v3.0 only. Learn more". But this is done automatically by gitlab.</li>
</ul>
<p>So we probably need upstream to clarify the license of that software by sending a patch to do that (for instance by telling that this program and all that is in this git repository is released under the GPLv3 or later in the README as per what's explained both in the GPLv3 text (how to apply [...] and in the documentation that explains how to apply the GPL ( <a class="external" href="https://www.gnu.org/licenses/gpl-howto.html#why-license-notices">https://www.gnu.org/licenses/gpl-howto.html#why-license-notices</a> ).</p>
<p>Once done we can also update the FSD entry about netctl as well: <a class="external" href="https://directory.fsf.org/wiki/Netctl">https://directory.fsf.org/wiki/Netctl</a></p> Packages - Freedom Issue #3412 (unconfirmed): Evaluate the libreoffice extensions repositoryhttps://labs.parabola.nu/issues/34122022-12-27T23:55:36ZGNUtooGNUtoo@cyberdimension.orgPackages - Bug #3269 (unconfirmed): [telegram-desktop] possible DRM, security, privacy, and anony...https://labs.parabola.nu/issues/32692022-05-05T14:25:13ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Someone described on the gnu-linux-libre mailing list a Telegram anti-feature that looks like DRM to me<sup><a href="#fn1">1</a></sup>: that anti-feature "forbids the user to copy/paste or forward text (and also forbids saving images or other media included in the messages) from certain groups where the admin has enabled the restriction".</p>
<p id="fn1" class="footnote"><sup>1</sup> <a class="external" href="https://lists.nongnu.org/archive/html/gnu-linux-libre/2022-05/msg00002.html">https://lists.nongnu.org/archive/html/gnu-linux-libre/2022-05/msg00002.html</a></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 #3211 (unconfirmed): gdb broken on armv7h when linking to opensslhttps://labs.parabola.nu/issues/32112022-04-01T22:00:26ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>If I link a hello world to libcrypto, I can't debug it anymore on armv7h:<br /><pre>
$ make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "armv7l-unknown-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /home/replicant/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0xb6dec408 in ?? () from /usr/lib/libcrypto.so.1.1
(gdb) A debugging session is active.
Inferior 1 [process 9953] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
</pre></p>
<p>Here libcrypto comes from OpenSSL:</p>
<pre>
$ pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1
</pre>
<p>I've tried recompiling gdb and openssl and it didn't change<br />anything (it still crashed).</p>
<p>I've restored Parabola's gdb and openssl (by reinstalling them) <br />before doing the test I pasted above.</p>
<p>On i686 however it works fine:<br /><pre>
make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /tmp/tmp.OiT2tDGGNe/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Hello world
[Inferior 1 (process 28480) exited normally]
</pre></p>
<p>And here's OpenSSL version:<br /><pre>
$ pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1.0
</pre></p>
<p>And on x86_64 I've also no issues:<br /><pre>
# make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /root/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Hello world
[Inferior 1 (process 724520) exited normally]
</pre></p>
<p>And the OpenSSL version is the same than on armv7h:<br /><pre>
# pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1
</pre></p>
<p>I've attached the files used during the test, though it's just<br />a hello world and it just runs it through gdb so there is nothing fancy.</p> Packages - Bug #3193 (unconfirmed): /etc/pacman.d/gnupg/gpg.conf is not updatedhttps://labs.parabola.nu/issues/31932022-02-22T16:26:32ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Many Parabola systems (including winston) have an old <code>/etc/pacman.d/gnupg/gpg.conf</code> with the following content:<br /><pre>
no-greeting
no-permission-warning
lock-never
keyserver-options timeout=10
keyserver pool.sks-keyservers.net
</pre></p>
<p>Instead it should have that:<br /><pre>
no-greeting
no-permission-warning
lock-never
keyserver-options timeout=10
keyserver-options import-clean
keyserver-options no-self-sigs-only
</pre></p>
<p>Somehow <code>gpg.conf</code> should be updated.</p>
<p>I've no idea if it's a bug in Parabola or Arch Linux though.</p> Packages - Bug #2805 (unconfirmed): Verify if the u-boot documentation is FSDG complianthttps://labs.parabola.nu/issues/28052020-06-14T18:54:57ZGNUtooGNUtoo@cyberdimension.orgPackages - Bug #1762 (open): [openvpn-update-resolv-conf-git] and/or [openvpn-update-systemd-reso...https://labs.parabola.nu/issues/17622018-04-25T12:47:32ZGNUtooGNUtoo@cyberdimension.org
<p>OpenVPN isn't capable of handling DNS server push information in GNU/Linux without the help of external scripts like<br /><pre>
/etc/openvpn/update-resolv-conf
</pre></p>
<p>Trisquel and <a href="https://packages.debian.org/stretch/amd64/openvpn/filelist" class="external">other debian based distribution ship this file in the openvpn package</a> :</p>
<p>However arch and Parabola don't have such file in the OpenVPN package.</p>
However there is a PKGBUILDS for this file available here:
<ul>
<li><a class="external" href="https://aur.archlinux.org/packages/openvpn-update-resolv-conf-git/">https://aur.archlinux.org/packages/openvpn-update-resolv-conf-git/</a><br />and a pkgbuild for an alternative script using systemd here:</li>
<li><a class="external" href="https://aur.archlinux.org/packages/openvpn-update-systemd-resolved/">https://aur.archlinux.org/packages/openvpn-update-systemd-resolved/</a></li>
</ul> Ports - Packaging Request #1296 (open): [pcr] Compile pcr/multipath-tools for arm (it's available...https://labs.parabola.nu/issues/12962017-04-28T16:27:43ZGNUtooGNUtoo@cyberdimension.orgPorts - Porting #1252 (open): abs not working (+GPL issue?)https://labs.parabola.nu/issues/12522017-03-22T09:57:11ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>With the default config, I can't get the sources:</p>
<pre>
# uname -m
armv7l
# abs
==> ERROR: No mirrors found in mirrorlist file /etc/pacman.d/mirrorlist
</pre>
<p>In the default config /etc/pacman.d/mirrorlist is the same than on x86, I don't know if that information is relevant or not.</p>
<p>Denis.</p> Ports - Bug #1039 (open): ARM: architecture not autodetected properlyhttps://labs.parabola.nu/issues/10392016-06-21T19:30:18ZGNUtooGNUtoo@cyberdimension.org
<p>On my GTA04 which runs Parabola I have:<br /><pre>
# uname -m
armv7l
</pre></p>
<p>This seem to be picked by pacman, and I'm required to force the architectuer to armv7h in /etc/pacman.conf like that:<br /><pre>
Architecture = armv7h
</pre></p> Ports - Packaging Request #1038 (open): jitsi is available on x86 but not on arm.https://labs.parabola.nu/issues/10382016-06-21T19:28:58ZGNUtooGNUtoo@cyberdimension.org
<p>On i686:<br /><pre>
# pacman -sS jitsi
pcr/jitsi 2.8.5426-1 [installed]
#
</pre></p>
<p>On ARM (with PCR enabled) it's not available:<br /><pre>
# pacman -sS jitsi
#
</pre></p> Ports - Bug #1037 (open): Have a way to calibrate resistive touchscreens.https://labs.parabola.nu/issues/10372016-06-21T19:23:38ZGNUtooGNUtoo@cyberdimension.org
<p>Many ARM mobile devices made for GNU/Linux have resistive touchscreen.<br />This is more precise, but requires calibration.<br />Some GUI exist for that such as xinput-calibrator, which work with evdev.</p>
<p>Alternatively there is also tslib, but xf86-input-tslib isn't in officially maintained by Xorg. This is problematic because there is no guarantee that at a given time, xf86-input-tslib still matches the current Xorg API.</p>
<p>We also have the option of calibrating manually with xinput, but that is really tedious and not user friendly. Though it sometimes gives better results.</p>
<p>We could also somehow have a package that ships calibration data, but that might be complicated to integrate seamlessly, especially if users are supposed to mess around with the system. It also cannot support every device that ever existed.</p>
<p>Denis.</p> Packages - Bug #933 (open): Outdated mirrors security issue.https://labs.parabola.nu/issues/9332016-02-14T18:49:31ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
We had this mirror in /etc/pacman.d/mirrorlist as the first(default) mirror:<br /><pre>http://parabolagnulinux.mirrors.linux.ro/$repo/os/$arch</pre><br />The issue is that it stopped being up to date.<br />/etc/pacman.d/mirrorlist comes from libre/pacman-mirrorlist.<br />Here we assume that the user kept the default configuration.<br />When that mirror stopped being up to date, pacman still used it to check for updates, and will still do for as long as that mirror is still online.<br />It only uses that mirror since it's available online and it's the first/default one.<br />Computers still using that mirror do not have an up to date system.<br />They will continue to do so, until the user finds the lack of update suspicous enough to bother checking what happened, unless we:
<ul>
<li>Warn the users.</li>
<li>Fix Parabola to prevent such issue from happening again.</li>
</ul>
<p>Here the mirror is not necessarily malicious. It could just have had an issue and stop syncing.<br />Parabola should be resilient to that, either automatically, or with the help of people like its developers or community.</p>
We should prevent systems from not learning about new updates:
<ul>
<li>First by addressing that concern assuming that the mirrors are not malicious, that also assume possible MITM.</li>
<li>Then by addressing the malicious mirrors concerns.</li>
</ul>
<p>As parabola infrastructure was down when I found that issue, I sent a mail to the [DEV] mailing list, but the mail delivery was delayed due to the infrastructure being down.<br />Its subject is "[Dev] Mirrors vulnerability issue, Many outdated installs in the wild"</p> Servers - Bug #913 (open): [labs] Enable account-less bugreportshttps://labs.parabola.nu/issues/9132016-01-09T00:13:32ZGNUtooGNUtoo@cyberdimension.org
<p>I'm not sure if it's desirable.<br />I've also no idea on how that can be implemented in a way that would prevent spam.<br />The user on IRC just wanted not to have to handle yet one more account and was looking for a way to bugreport without creating an account for each project that user wants to bugreport to.</p>
<p>Denis.</p>