General Questions #23

boredsquirrel commented 2024年10月18日 10:54:20 +02:00

Hey, I looked over the project, and installed HeliumOS-canary on a Chromebook already!

But I have a couple of general questions and ideas.

Matrix Room

I was not able to join, might be because of my server.

Matrix sucks for reuseable discussions. I would suggest asking the Alma guys if you can have a tag or category there? Or just use the Community category and add "HeliumOS:" to the title?

Matrix is kinda better than Discord but still not search engine indexed etc. Having public informations on the go, without needing to write docs, is really nice. I like Discourse and am a pretty active member of the Fedora Instance.

Release Notes

In the release notes you said, that you would switch to github and ghcr.io.

I found an empty account but nothing else, is that yours?

I would personally be in favor of codeberg + quay.io simply for software freedom. Github is owned by Microsoft, already has a dystopian dominance over the FOSS ecosystem, and is fully proprietary.

Instead, a donation page, for the quay costs and codeberg donations, sounds like a good idea. I would be the first donator!

Package Changes

You said Chromium would be replaced with GNOME-Web. When and where?

I rebased to the canary branch, and there was no such change.

Please clear this up, am I using some outdated image?

Package Philosophy

I dont know anything about Almas bootc images yet. Are they only for a full GNOME desktop?

The current HeliumOS is full of GNOME RPM packages.

This means it provides kind of a traditional Alma experience, but also with the downsides.

uBlue and Fedora Atomic Desktops in contrast go fully Flatpak and instead add yafti to install flatpaks at first startup (yafti can also run whatever commands).

I wonder: what is your philosophy here? Using uBlues default yafti presets, one could have a very stable system with up-to-date flatpaks, there are presets for GNOME and KDE apps, and you can add whatever you like.

Both have pros and cons, like less stable apps or (especially rare on GNOME and KDE Apps) breakages through the sandbox.

Auto-Updates

For a good UX, both bootc and flatpak updates should be automated, have a look at my currently broken try to implement them.

These updates should not need any user interaction, as users simply dont click those buttons.

They need to be opt-out with elevated privileges at most, and run without requiring a password.

I suggest adding a page to the GTK Image app, and can try to help here. When using yafti, some could be done there too.

This may be an upstream issue, I will open a separate issue on this.

Image Signing

Are the images signed with cosign? This would be very important for secure updates, especially in enterprise environments.

Secureboot

I read there are plans for secureboot support. I think limiting it to self-signed keys is reasonable for now, or does microsoft secureboot work on Alma?

Hey, I looked over the project, and installed HeliumOS-canary on a Chromebook already! But I have a couple of general questions and ideas. ## Matrix Room I was not able to join, might be because of my server. Matrix sucks for reuseable discussions. I would suggest asking the Alma guys if you can have a tag or category there? Or just use the Community category and add "HeliumOS:" to the title? Matrix is kinda better than Discord but still not search engine indexed etc. Having public informations on the go, without needing to write docs, is really nice. I like Discourse and am a pretty active member of the Fedora Instance. ## Release Notes In the release notes you said, that you would switch to github and ghcr.io. I found an empty account but nothing else, is that yours? I would personally be in favor of codeberg + quay.io simply for software freedom. Github is owned by Microsoft, already has a dystopian dominance over the FOSS ecosystem, and is fully proprietary. Instead, a donation page, for the quay costs and codeberg donations, sounds like a good idea. I would be the first donator! ### Package Changes You said Chromium would be replaced with GNOME-Web. When and where? I rebased to the canary branch, and there was no such change. Please clear this up, am I using some outdated image? ## Package Philosophy I dont know anything about Almas bootc images yet. Are they only for a full GNOME desktop? The current HeliumOS is full of GNOME RPM packages. This means it provides kind of a traditional Alma experience, but also with the downsides. uBlue and Fedora Atomic Desktops in contrast go fully Flatpak and instead add [yafti](github.com/ublue-os/yafti) to install flatpaks at first startup (yafti can also run whatever commands). I wonder: what is your philosophy here? Using uBlues default yafti presets, one could have a very stable system with up-to-date flatpaks, there are presets for GNOME and KDE apps, and you can add whatever you like. Both have pros and cons, like less stable apps or (especially rare on GNOME and KDE Apps) breakages through the sandbox. ## Auto-Updates For a good UX, both bootc and flatpak updates should be automated, [have a look at my currently broken try to implement them](https://discussion.fedoraproject.org/t/fixing-rpm-ostree-automatic-updates/109151). These updates should not need any user interaction, as users simply dont click those buttons. They need to be opt-out with elevated privileges at most, and run without requiring a password. I suggest adding a page to the GTK Image app, and can try to help here. When using yafti, some could be done there too. This may be an upstream issue, I will open a separate issue on this. ## Image Signing Are the images signed with cosign? This would be very important for secure updates, especially in enterprise environments. ## Secureboot I read there are plans for secureboot support. I think limiting it to self-signed keys is reasonable for now, or does microsoft secureboot work on Alma?

imbev commented 2024年10月18日 17:58:28 +02:00

It's exciting to see new HeliumOS installations!

Matrix Room

I agree with your concerns. Matrix is useful for ephemeral conversation, but not for information that might be referenced later.

Relying on AlmaLinux, Fedora, or another organization with a distinctive Linux brand for discussion is something that I would prefer to avoid.

The issue tracker on Codeberg is currently meeting this need, although not ideal. To self-host Discourse or use the hosted option is preferable, however that is an expense. Reddit is a free option, however that has some privacy and proprietary concerns.

Release Notes

My GitHub account: https://github.com/imbev

That's not quite accurate. Development and collaboration is held on Codeberg, with Quay.io as the container registry. GitHub holds mirrors of some HeliumOS repositories and GitHub Actions is used to build and push the bootc images.

To move to a more open platform, perhaps self-hosted is preferable. Unfortunately, Quay.io's CI is heavily lacking. If you know of another CI provider that is more open while also retaining basic features, please let me know.

A donation page is possible, I could setup donation options with Liberapay and Crypto :)

Package Changes

Chromium was replaced by GNOME Web for a few weeks. After examination, I decided to revert the change because of the 600mb difference in storage space.

If you have Chromium installed, you are uptodate.

Package Philosophy

AlmaLinux provides very minimal images suitable for servers. Most GNOME packages on HeliumOS are from the AlmaLinux or EPEL repositories.

I wasn't aware of yafti until now, but that is exactly what HeliumOS needs.

There are a few dimensions with regard to apps on HeliumOS:

• Manually installed vs Preinstalled
• Removable vs Mandatory
• RPM vs Flatpak

The goal for HeliumOS is to have a reliable base system that's sufficient for all users (and not excessive), while relying on Flatpak and Distrobox/Podman/Docker for the user's applications and development environment.

RPMs are currently used for stability and lower storage use, while Flatpaks are used for compatible, yet updated software. With the use of Yafti, HeliumOS could suggest browser, media, office, and other Flatpak software. That would overcome the image size issue with some preinstalled software. Even so, a backup web browser is something that I think HeliumOS should always provide.

Auto-Updates

I agree with everything here.

Image Signing

No, the images are not signed with cosign. This is an area that we can improve in the future, however care will be needed to not restrict the user from changing their base image.

Secureboot

Indeed, secureboot support is important. We regenerate the initramfs, so Microsoft's keys won't work with HeliumOS. Providing a simple and easy way for users to enroll a HeliumOS key would be ideal until HeliumOS is permitted to sign images compatible with Microsoft's keys.

Much of this is a matter of time and effort, so progress will be made in these areas over the next few months.

It's exciting to see new HeliumOS installations! > Matrix Room I agree with your concerns. Matrix is useful for ephemeral conversation, but not for information that might be referenced later. Relying on AlmaLinux, Fedora, or another organization with a distinctive Linux brand for discussion is something that I would prefer to avoid. The issue tracker on Codeberg is currently meeting this need, although not ideal. To self-host Discourse or use the hosted option is preferable, however that is an expense. Reddit is a free option, however that has some privacy and proprietary concerns. > Release Notes My GitHub account: https://github.com/imbev That's not quite accurate. Development and collaboration is held on Codeberg, with Quay.io as the container registry. GitHub holds mirrors of some HeliumOS repositories and GitHub Actions is used to build and push the bootc images. To move to a more open platform, perhaps self-hosted is preferable. Unfortunately, Quay.io's CI is heavily lacking. If you know of another CI provider that is more open while also retaining basic features, please let me know. A donation page is possible, I could setup donation options with Liberapay and Crypto :) > Package Changes Chromium was replaced by GNOME Web for a few weeks. After examination, I decided to revert the change because of the 600mb difference in storage space. If you have Chromium installed, you are uptodate. > Package Philosophy AlmaLinux provides very minimal images suitable for servers. Most GNOME packages on HeliumOS are from the AlmaLinux or EPEL repositories. I wasn't aware of yafti until now, but that is exactly what HeliumOS needs. There are a few dimensions with regard to apps on HeliumOS: - Manually installed vs Preinstalled - Removable vs Mandatory - RPM vs Flatpak The goal for HeliumOS is to have a reliable base system that's sufficient for all users (and not excessive), while relying on Flatpak and Distrobox/Podman/Docker for the user's applications and development environment. RPMs are currently used for stability and lower storage use, while Flatpaks are used for compatible, yet updated software. With the use of Yafti, HeliumOS could suggest browser, media, office, and other Flatpak software. That would overcome the image size issue with some preinstalled software. Even so, a backup web browser is something that I think HeliumOS should always provide. > Auto-Updates I agree with everything here. > Image Signing No, the images are not signed with cosign. This is an area that we can improve in the future, however care will be needed to not restrict the user from changing their base image. > Secureboot Indeed, secureboot support is important. We regenerate the initramfs, so Microsoft's keys won't work with HeliumOS. Providing a simple and easy way for users to enroll a HeliumOS key would be ideal until HeliumOS is permitted to sign images compatible with Microsoft's keys. Much of this is a matter of time and effort, so progress will be made in these areas over the next few months.

boredsquirrel commented 2024年10月19日 00:43:49 +02:00

Matrix

A lemmy community could be an idea then!

Jerboa is one of many nice clients. Lemmy has pretty little features regarding community maintenance, but basics like admin rights, flagging, blocking etc.

Using some good server, registering there and creating a community there, anyone from any community can join, moderators need to be on the same.

Code forge

ah I understand! So Codeberg is only for being open. The issue will then be that all trust lies in Github CI, when signing images those need to be in Github as well.

Apps

yes that sounds totally reasonable.

Here is a list of recommended Flatpak apps I maintain. It it pretty messy, I lost a few hours of work when Firefox crashed...

Using only GNOME apps from Flathub would keep the storage size lower. I use a mix, main issue is that all KDE apps are completely unusable on GNOME as the theme is broken. Fedora discuss topic on that.

I will open a separate issue on the flatpak repo situation.

Firefox can be installed as the tarball, as the flatpak seccomp filter prevents it from creating user namespaces (like bubblewrap and podman normally use), instead it simply uses none and just nested seccomp filters. Using the tarball means fastest updates, but the app lies in some random directory that is writable by any process (otherwise the integrated updater wouldnt work, I suppose). Fedora Firefox also adds more flags, like working with hardend_malloc (I requested that a while back).

Image signing

as they are already built in Github CI, maybe look at how uBlue does it? They use cosign for their images. Are the Alma images even signed? The Fedora images for example, that uBlue takes as source, are not, so this is kinda security theatre. Still, more signing the better.

Users will always be able to sign their images themselves and to rebase to unsigned images, at least this works in rpm-ostree, dont know about bootc.

Secureboot

I found 2 guides for almalinux, but they kinda manually resigned kernel and modules with mokutil, or did some even more crazy stuff.

It seems that

1. a key needs to be generated, openssh seems to work here
2. the files need to be signed, this may be needed to do in CI, then build the image
3. the pubkey may be needed to be added to a firmware partition, probably by the user

this sounds like a good idea for yafti, and ujust. ujust is a customized command runner that is very useful for doing all sorts of things.

### Matrix A lemmy community could be an idea then! Jerboa is one of many nice clients. Lemmy has pretty little features regarding community maintenance, but basics like admin rights, flagging, blocking etc. Using some good server, registering there and creating a community there, anyone from any community can join, moderators need to be on the same. ### Code forge ah I understand! So Codeberg is only for being open. The issue will then be that all trust lies in Github CI, when signing images those need to be in Github as well. ### Apps yes that sounds totally reasonable. [Here is a list of recommended Flatpak apps I maintain](https://github.com/boredsquirrel/recommended-flatpak-apps). It it pretty messy, I lost a few hours of work when Firefox crashed... Using only GNOME apps from Flathub would keep the storage size lower. I use a mix, main issue is that all KDE apps are completely unusable on GNOME as the theme is broken. [Fedora discuss topic on that](https://discussion.fedoraproject.org/t/correct-way-to-theme-kde-apps-on-gnome/133996). I will open a separate issue on the flatpak repo situation. Firefox can be installed as the tarball, as the flatpak seccomp filter prevents it from creating user namespaces (like bubblewrap and podman normally use), instead it simply uses none and just nested seccomp filters. Using the tarball means fastest updates, but the app lies in some random directory that is writable by any process (otherwise the integrated updater wouldnt work, I suppose). Fedora Firefox also adds more flags, like working with hardend_malloc (I requested that a while back). ### Image signing as they are already built in Github CI, maybe look at how uBlue does it? They use cosign for their images. Are the Alma images even signed? The Fedora images for example, that uBlue takes as source, are not, so this is kinda security theatre. Still, more signing the better. Users will always be able to sign their images themselves and to rebase to unsigned images, at least this works in rpm-ostree, dont know about bootc. ### Secureboot I found 2 guides for almalinux, but they kinda manually resigned kernel and modules with mokutil, or did some even more crazy stuff. It seems that 1. a key needs to be generated, openssh seems to work here 2. the files need to be signed, this may be needed to do in CI, then build the image 3. the pubkey may be needed to be added to a firmware partition, probably by the user this sounds like a good idea for yafti, and [ujust](github.com/ublue-os/ujust). ujust is a customized command runner that is very useful for doing all sorts of things.

imbev commented 2024年10月19日 19:14:11 +02:00

A lemmy community could be an idea then!

I acknowledge that a Lemmy community has some value, but I don't think they outweigh the costs yet.

Creating a new codeberg repository specifically for feature requests would fulfill the same use case.

So Codeberg is only for being open. The issue will then be that all trust lies in Github CI, when signing images those need to be in Github as well.

Indeed. Considering that Microsoft owns the root secureboot keys, this is acceptable.

Apps

Looks good, we can continue this in the other issue.

Firefox can be installed as the tarball

I would like to avoid a mandatory Firefox installation. To the best of my knowledge, Chromium and Firefox Flatpaks are reasonably secure, though not optimal.

If we are to include a mandatory browser, it should be something treated as a "backup browser" such as chromium, gnome web, Falkon, etc. This also resolves the system codec issue.

Image signing

IIRC, they use cosign for image signing. We'll need to do more research into the best way of signing through CI. My initial takeaway is that we can store a private key as a GitHub Actions secret and do the secureboot signing as another task in the pipeline.

The upstream AlmaLinux images are not signed: https://github.com/AlmaLinux/bootc-images/tree/main/.github

> A lemmy community could be an idea then! I acknowledge that a Lemmy community has some value, but I don't think they outweigh the costs yet. Creating a new codeberg repository specifically for feature requests would fulfill the same use case. > So Codeberg is only for being open. The issue will then be that all trust lies in Github CI, when signing images those need to be in Github as well. Indeed. Considering that Microsoft owns the root secureboot keys, this is acceptable. > Apps Looks good, we can continue this in the other issue. > Firefox can be installed as the tarball I would like to avoid a mandatory Firefox installation. To the best of my knowledge, Chromium and Firefox Flatpaks are reasonably secure, though not optimal. If we are to include a mandatory browser, it should be something treated as a "backup browser" such as chromium, gnome web, Falkon, etc. This also resolves the system codec issue. > Image signing IIRC, they use cosign for image signing. We'll need to do more research into the best way of signing through CI. My initial takeaway is that we can store a private key as a GitHub Actions secret and do the secureboot signing as another task in the pipeline. The upstream AlmaLinux images are not signed: https://github.com/AlmaLinux/bootc-images/tree/main/.github

imbev commented 2024年12月27日 21:31:09 +01:00

Angelfish is now the system-managed browser

Angelfish is now the system-managed browser

imbev commented 2025年01月24日 23:59:58 +01:00

This issue has been split into #47, #48

This issue has been split into https://codeberg.org/HeliumOS/bootc/issues/47, https://codeberg.org/HeliumOS/bootc/issues/48