Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552024-03-21T14:59:45ZParabola Issue Tracker
Redmine Packages - Freedom Issue #3609 (open): List of core freedom issues affecting work in Parabola.https://labs.parabola.nu/issues/36092024-03-21T14:59:45ZGNUtooGNUtoo@cyberdimension.org
<p>This bug is meant to track freedom issues affecting core components in Parabola.</p>
<p>For instance Pacman is a core component in Parabola since almost anything else depend on it.</p>
<p>Libretools is also required for working on Parabola as well as package definitions.</p>
<p>While there are often freedom issues found in regular packages (for instance a game being nonfree) the impact of these is more limited because it only affect a subset of users and doesn't affect packages required to contribute to Parabola (which are needed to fix these issues in the first place). Some packages (like u-boot for instance) can be critical to some users or use cases but don't affect all the users and contributors to Parabola.</p> 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 - Freedom Issue #3390 (open): geotag not built from sourcehttps://labs.parabola.nu/issues/33902022-12-13T16:25:03ZGNUtooGNUtoo@cyberdimension.org
<p>reference: <a class="external" href="https://github.com/archlinux/svntogit-community/blob/packages/geotag/trunk/PKGBUILD">https://github.com/archlinux/svntogit-community/blob/packages/geotag/trunk/PKGBUILD</a></p> Packages - 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.orglibretools - Housekeeping #2102 (open): librechroot should use the winston mirror exclusivelyhttps://labs.parabola.nu/issues/21022018-11-28T14:38:13ZGNUtooGNUtoo@cyberdimension.org
<pre>
$ sudo librechroot -n parabola-i686 update
[...] # went fine
$ sudo librechroot -n parabola-i686 enter
# pacman -Sy
:: Synchronizing package databases...
repo is up to date
libre is up to date
core is up to date
extra is up to date
community is up to date
pcr is up to date
# pacman -S git
resolving dependencies...
looking for conflicting packages...
Packages (4) perl-error-0.17027-1.0 perl-mailtools-2.20-2.1 perl-timedate-2.30-5.1 git-2.19.1-1.1
Total Download Size: 5.29 MiB
Total Installed Size: 39.93 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
error: failed retrieving file 'perl-error-0.17027-1.0-any.pkg.tar.xz' from redirector.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed retrieving file 'perl-timedate-2.30-5.1-any.pkg.tar.xz' from redirector.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed retrieving file 'perl-mailtools-2.20-2.1-any.pkg.tar.xz' from redirector.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed retrieving file 'git-2.19.1-1.1-i686.pkg.tar.xz' from redirector.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
[root@parabola /]# pacman -S perl-error
resolving dependencies...
looking for conflicting packages...
Packages (1) perl-error-0.17027-1.0
Total Download Size: 0.02 MiB
Total Installed Size: 0.10 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
error: failed retrieving file 'perl-error-0.17027-1.0-any.pkg.tar.xz' from redirector.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
</pre> 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> Installation Media - Feature Request #1780 (open): [armv7] do not set user/root password in futur...https://labs.parabola.nu/issues/17802018-05-02T11:11:24ZGNUtooGNUtoo@cyberdimension.org
<p>The <a class="external" href="https://repomirror.parabola.nu/iso/arm/LATEST/ParabolaARM-armv7-LATEST.tar.gz:"lastest">https://repomirror.parabola.nu/iso/arm/LATEST/ParabolaARM-armv7-LATEST.tar.gz:"lastest</a>" (at the time of writing) tarball release has a password set.</p>
<p>After booting the user can't log in.</p>
<p>Having no passwords in the next tarball release (and optionally adding the password to the <a class="external" href="https://wiki.parabola.nu/ARM_Installation_Guide#Change_or_set_the_root_password:"ARM">https://wiki.parabola.nu/ARM_Installation_Guide#Change_or_set_the_root_password:"ARM</a> installation guide" for this release would fix it.</p> Packages - Bug #1779 (open): [armv7] compile [qemu-user-static-binfmt]https://labs.parabola.nu/issues/17792018-05-01T15:31:32ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Having qemu-user-static-binfmt would be nice to have on ARM, as it could enable users to transparently run x86 code.</p>
<p>On Parabola x86, it works fine to run arm code (with it you can transparently arch-chroot inside a Parabola ARM installation for instance)</p>
<p>Denis.</p> Packages - 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> 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>