manjaro-arm-tools issueshttps://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues2021-05-20T09:39:41Zhttps://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/35Add support for nemo mobile2021-05-20T09:39:41ZJozef MlichAdd support for nemo mobileIt would be nice if you can merge following commit into manjaro-arm-tools:
https://github.com/nemomobile-ux/manjaro-arm-tools/commit/a369c3426ad509028c81c3326714bc653d4493f9It would be nice if you can merge following commit into manjaro-arm-tools:
https://github.com/nemomobile-ux/manjaro-arm-tools/commit/a369c3426ad509028c81c3326714bc653d4493f9https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/34buildarmimg: allow setting custom repo using URL2023-10-01T08:45:41ZJozef Mlichbuildarmimg: allow setting custom repo using URLI want to use repository defined by custom URL in my scenario. I believe this could be useful also for other people. See attached patch.I want to use repository defined by custom URL in my scenario. I believe this could be useful also for other people. See attached patch.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/33Vulnerability: Images are built with a pre-initialised (and thus common) pacm...2021-06-14T09:40:54ZAshley Newsonashleynewson@smartsim.org.ukVulnerability: Images are built with a pre-initialised (and thus common) pacman keyring and signing keyI'm unsure if this is the appropriate place for security bug reports. I could not find any official direction for submitting security-related bugs.
## Impact
Installations of the pre-built ARM images can be tricked into installing mali...I'm unsure if this is the appropriate place for security bug reports. I could not find any official direction for submitting security-related bugs.
## Impact
Installations of the pre-built ARM images can be tricked into installing maliciously signed packages by a network attacker, leading to code execution as root.
[CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) (8.0 High)
## Details
Having recently started experimenting with a couple of Manjaro ARM images for the Pinephone, I noticed that the images which are distributed (e.g. on GitHub) all contain a pre-initialised pacman keyring - i.e., the `/etc/pacman.d/gnupg` directory.
This is problematic because everyone who installs one of these pre-built images will inherit the same local signing key (both private and public components). This is dangerous because the local signing key can be used to sign packages for installation - even those obtained from supposedly official mirrors.
I was able to confirm that a man-in-the-middle attacker (or a rogue mirror) can use this common signing key to serve modified databases and packages which would then pass pacman's signature checks and would thus be installed without any objection. As such, malware could be installed to a user's phone (or other ARM-based device) by a man-in-the-middle attacker.
(Note that technically, databases aren't signed, but packages must be signed by a trusted key. The database typically contains package signatures, and so it must be modified by an attacker also.)
## Exploitability
- Use of plaintext HTTP mirrors (i.e. not HTTPS) are still common place and enabled by default, allowing database and package downloads to be subverted by a network adjacent attacker.
- It's my understanding that Manjaro can be configured to download updates automatically. (I'm not sure if it will install them automatically, but poisoning the database/package cache may be 50% of the way there.)
- Though I've only tested Phosh and Plasma-mobile images for the Pinephone, I believe the root cause to be with the common build process (i.e. manjaro-arm-tools). Therefore, many more images than I've tested are potentially affected.
## Suggested Remediation
- Assuming the keyring is needed during the build process, `/etc/pacman.d/gnupg` should be purged afterwards before the image is finalised.
- Defer initialisation of the final pacman keyring (`pacman-key --init`) until the first proper boot. (Similar to how SSH server keys are currently handled.)
- Rebuild any affected images without a pre-initialised keyring as soon as possible.
As far as I know, pacman won't automatically initialise a keyring, so this may require the use of a first-time setup script. First-time setup scripts are already used for some images (such as those for the Pinephone).
I note that GitHub has a download counter for many of the images with compromised keys. A significant number of users are thus evidently using insecure keyrings already. Can this be addressed retroactively somehow?
## References
Example images with pre-initialised keyrings:
- https://github.com/manjaro-pinephone/phosh/releases/tag/beta8
- https://github.com/manjaro-pinephone/plasma-mobile/releases/tag/202105060255https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/31Outdated qemu-aarch64-static binary2020-11-06T16:22:34ZDownloading69Outdated qemu-aarch64-static binarySeems the binary is outdated. (QEMU 5+ is already released)
`
[user@box ~]$ /usr/bin/qemu-aarch64-static --version
qemu-aarch64 version 3.1.0 (Debian 1:3.1+dfsg-7)
`
Ignore if there is a valid reason for this, just noticed it while pla...Seems the binary is outdated. (QEMU 5+ is already released)
`
[user@box ~]$ /usr/bin/qemu-aarch64-static --version
qemu-aarch64 version 3.1.0 (Debian 1:3.1+dfsg-7)
`
Ignore if there is a valid reason for this, just noticed it while playing around ;) !https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/30[buildarmimg] pkglist generation uses the databases from host instead of rootfs2020-08-14T11:04:10ZGhost User[buildarmimg] pkglist generation uses the databases from host instead of rootfsIt seems the pkglist generation that's run at the end, tries to use the same database names as the host, resulting in "database multilib does not exist" messages. The same will show for every database which does not exist in the rootfs, ...It seems the pkglist generation that's run at the end, tries to use the same database names as the host, resulting in "database multilib does not exist" messages. The same will show for every database which does not exist in the rootfs, so basically any database that's not `core`, `extra` and `community`.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/29[buildarmpkg] Newly built packages always gets installed into the rootfs2020-08-12T19:58:04ZGhost User[buildarmpkg] Newly built packages always gets installed into the rootfsEver since the addition of the "install pkg into rootfs" function, the `buildarmpkg` script always installs it. Even when the -n flag is not given.
This should obviously not happen.Ever since the addition of the "install pkg into rootfs" function, the `buildarmpkg` script always installs it. Even when the -n flag is not given.
This should obviously not happen.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/28[buildarmpkg] we should install packages after building into chroot2020-08-02T01:00:10ZPhilip Müller[buildarmpkg] we should install packages after building into chrootEspecially for batch building we might need a feature to install the package after building it. This can be done by using the following cmd line: `$NSPAWN $BUILDDIR/$ARCH/ --chdir=/build/ makepkg -Asci --noconfirm`
... Question is: do w...Especially for batch building we might need a feature to install the package after building it. This can be done by using the following cmd line: `$NSPAWN $BUILDDIR/$ARCH/ --chdir=/build/ makepkg -Asci --noconfirm`
... Question is: do we want to install it by default or add another switch to **buildarmpkg**?https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/27Prune and unmount pkg-cache seems to be broken2020-08-02T01:05:13ZPhilip MüllerPrune and unmount pkg-cache seems to be brokenWhen you do a batch compile like **kde-git** packages, it seems that `pkg-cache` don't get unmounted properly:
```
==> Cleaning up...
-> Prune and unmount pkg-cache...
Failed to resolve path /var/lib/manjaro-arm-tools/img/rootfs_aarch...When you do a batch compile like **kde-git** packages, it seems that `pkg-cache` don't get unmounted properly:
```
==> Cleaning up...
-> Prune and unmount pkg-cache...
Failed to resolve path /var/lib/manjaro-arm-tools/img/rootfs_aarch64: No such file or directory
umount: /var/lib/manjaro-arm-tools/img/rootfs_aarch64/var/cache/pacman/pkg: no mount point specified.
```
This results in following situations:
```
/dev/sda7 on /run/media/phil/home type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
/dev/sdb2 on /var/lib/manjaro-arm-tools/pkg/aarch64/var/cache/pacman/pkg type ext4 (rw,noatime)
/dev/sdb2 on /var/cache/manjaro-arm-tools/pkg/pkg-cache type ext4 (rw,noatime)
```https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/25[buildarmimg] file not found: `fsck.xfs'2020-06-08T07:11:12Zmritd[buildarmimg] file not found: `fsck.xfs'I get an error when I compile the img for Raspberry Pi 4:
```
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi4.preset: 'default'
-> -k 4.19.122-1-MANJARO-ARM -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Startin...I get an error when I compile the img for Raspberry Pi 4:
```
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi4.preset: 'default'
-> -k 4.19.122-1-MANJARO-ARM -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 4.19.122-1-MANJARO-ARM
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> ERROR: file not found: `fsck.xfs'
==> WARNING: No fsck helpers found. fsck will not be run on boot.
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly
```
I am new to manjaro, and it seems to be a problem with linux-rpi4 after querying the information; can anyone help me?https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/24automate creation of signature, checksums and torrent files2020-03-14T07:31:25ZBernhard Landauerautomate creation of signature, checksums and torrent filessimilar to the same features of **deployiso** for mainline ISOs this will be needed also in **manjaro-arm-tools**.similar to the same features of **deployiso** for mainline ISOs this will be needed also in **manjaro-arm-tools**.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/23[buildarmimg] overwrite existing image files2020-03-15T11:45:08ZBernhard Landauer[buildarmimg] overwrite existing image filesCurrently when you rebuild an image and you don't remove the old file, buildarmimg will run the whole process and in the end simply not create the new image file due to existing file.
Existing files of the same name as the currently crea...Currently when you rebuild an image and you don't remove the old file, buildarmimg will run the whole process and in the end simply not create the new image file due to existing file.
Existing files of the same name as the currently created should be removed / overwritten with the new one.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/22sign_pkg() broken2020-02-06T13:40:58ZBernhard Landauersign_pkg() broken```
$ deployarmpkg -p manjaro-arm-i3-settings -r community -a aarch64 -k oberon@manjaro.org
-> Signing [manjaro-arm-i3-settings] with GPG key belonging to oberon@manjaro.org...
gpg: manjaro-arm-i3-settings: read error: Is a directory
``````
$ deployarmpkg -p manjaro-arm-i3-settings -r community -a aarch64 -k oberon@manjaro.org
-> Signing [manjaro-arm-i3-settings] with GPG key belonging to oberon@manjaro.org...
gpg: manjaro-arm-i3-settings: read error: Is a directory
```https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/21Flag to pause until keypress just before the image compression phase?2020-02-04T07:26:10ZMilkiiFlag to pause until keypress just before the image compression phase?So as to give an for configuration files and similar to be edited.So as to give an for configuration files and similar to be edited.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/20archlinux-keyring missing in latest function.sh2019-10-07T07:22:22Zfkardamearchlinux-keyring missing in latest function.shI tried cubocore edition and few package failed with pgp signature invalid.
I added
`$NSPAWN $ROOTFS_IMG/rootfs_$ARCH pacman -S archlinux-keyring --noconfirm 1> /dev/null 2>&1`
and it installed fine.I tried cubocore edition and few package failed with pgp signature invalid.
I added
`$NSPAWN $ROOTFS_IMG/rootfs_$ARCH pacman -S archlinux-keyring --noconfirm 1> /dev/null 2>&1`
and it installed fine.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/19[buildarmpkg] should use host's arm pkg-cache2019-06-14T18:44:10ZGhost User[buildarmpkg] should use host's arm pkg-cache`buildarmpkg` should use the host systems `/var/cache/manjaro-arm-tools/pkg/pkg-cache` folder for it's package cache, instead of redownloading everything for each rebuild.
Could possible be done with a symlink in the function between pk...`buildarmpkg` should use the host systems `/var/cache/manjaro-arm-tools/pkg/pkg-cache` folder for it's package cache, instead of redownloading everything for each rebuild.
Could possible be done with a symlink in the function between pkg-cache and the rootfs cache.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/18Task list!2021-05-27T10:48:47ZGhost UserTask list!* [x] Pinebook: LCD display on Mainline kernel
* [x] Pinebook: Audio on Mainline kernel
* [x] Odroid N2: Add Mainline support (probably with 5.3)
* [x] RockPro64: Fix 5 minute boot time on kernel 5.2
* [x] RockPi4: Add support for t...* [x] Pinebook: LCD display on Mainline kernel
* [x] Pinebook: Audio on Mainline kernel
* [x] Odroid N2: Add Mainline support (probably with 5.3)
* [x] RockPro64: Fix 5 minute boot time on kernel 5.2
* [x] RockPi4: Add support for this device in tools
* [x] Pinebook: eMMC image installer script ( https://gitlab.manjaro.org/manjaro-arm/packages/community/manjaro-arm-emmc-flasher )
* [x] Odroid C2: Add Audio support on Mainline kernel
* [x] Rock64: Add audio support on Mainline kernel
* [x] Sopine: Add Audio support on Mainline kernel
* [x] Pinebook Pro: Add device support to tools
* [x] Pinebook Pro: Build uboot and package it for use
* [x] Package Plasma Mobile
* [x] Pinebooks: LXQT Brightness applet. ( Sort of fixed itself with lxqt updates )
* [x] Raspberry Pi 4: Add support for this in tools
* [x] Khadas Vim3: Add working support in tools
* [x] Khadas Vim3: Build uboot and kernel and package them for use
* [x] Khadas Vim 1/2: Maybe add support for these devices ( they seem to have mainline support )https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/17same uboot for rock64 and rockpro64?2019-03-22T07:40:15Zchlorophyll-zzsame uboot for rock64 and rockpro64?from
https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-installer/blob/master/manjaro-arm-installer
```shell
elif [[ "$DEVICE" = "rock64" ]] || [[ "$DEVICE" = "rockpro64" ]]; then
```
it seems the rock64 gets the rk339...from
https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-installer/blob/master/manjaro-arm-installer
```shell
elif [[ "$DEVICE" = "rock64" ]] || [[ "$DEVICE" = "rockpro64" ]]; then
```
it seems the rock64 gets the rk339x bootloader. The Rock64 needs the Rk3328 Uboot.
My Device, which boots every rock64 image (armbian-rock64, ayufan-lxde-rock64, does not boot with this Image: Manjaro-arm-19.02-rock64-minimal.
It has the wrong u-boot.img or idbloader.img in /boot/ for Rk3328.
Please confirm. TYhttps://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/16Make compressing the image optional2019-02-18T07:52:20ZPhilip MüllerMake compressing the image optionalWhen we do development for new images on the #pinebook we might not need the compressing step at the end for the image. Currently I'm canceling that always. If we had a switch, we could pass it not to compress.When we do development for new images on the #pinebook we might not need the compressing step at the end for the image. Currently I'm canceling that always. If we had a switch, we could pass it not to compress.https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/15services listed in i3 profile not enabled2019-02-17T16:36:16ZBernhard Landauerservices listed in i3 profile not enabledworking on the i3 profile, I noticed that none of the services listed in the service file are enabled.
At first glance in functions.sh I can only see some services explicitly listed.
How is this supposed to work? What am I missing?working on the i3 profile, I noticed that none of the services listed in the service file are enabled.
At first glance in functions.sh I can only see some services explicitly listed.
How is this supposed to work? What am I missing?https://gitlab.manjaro.org/manjaro-arm/applications/manjaro-arm-tools/-/issues/13[buildarmimg] /var/lib/manjaro-arm-tools/tmp/user: No such file or directory2019-01-20T11:24:27ZPhilip Müller[buildarmimg] /var/lib/manjaro-arm-tools/tmp/user: No such file or directoryDuring creating the current kde image for the Pinebook with **manjaro-arm-tools v2.4.1** I got the following error: `/var/lib/manjaro-arm-tools/tmp/user: No such file or directory`
```
-> Enabling services...
-> Applying overlay for...During creating the current kde image for the Pinebook with **manjaro-arm-tools v2.4.1** I got the following error: `/var/lib/manjaro-arm-tools/tmp/user: No such file or directory`
```
-> Enabling services...
-> Applying overlay for kde edition...
-> Setting up users...
-> Enabling user services...
cat: /var/lib/manjaro-arm-tools/tmp/user: No such file or directory
-> Setting up system settings...
-> Doing device specific setups for pinebook...
cat: /var/lib/manjaro-arm-tools/tmp/user: No such file or directory
-> Cleaning rootfs for unwanted files...
```