The future is now

Someone took Packman over, so it's actually staying.

As far as I know, the alternatives are using the VLC repo instead of Packman, or use the Flatpak version of the media applications.

Makes sense but Packman’s for proprietary media codecs and stuff right? What’s the alternative? I want those codecs. Is there a way of getting it to never try to overtake what’s available on the official repos?

A new team has agreed to take over Packman. It's not dead yet.

I'm guessing this might be a conflict with packman repos. Maybe look into removing packman as a repository, if you have it enabled? I'm pretty sure I read packman might be shutting down anyway.

Where to file expired key against a package? Its not quite a bug, but an admin issue.

Some immutable distros like talos linux, have an extremely stripped down installation of linux with just what ia needed to run kubernetes.

However most immutable distros have something akin to the standard base of a normal linux distro.

And even then, the Linux kernel, is now one of the biggest attack surfaces, infintely more of a threat than having a package on the host. Most packages on the host, since they aren't setuid, can't really do anything malicious.

Flatpak sandboxing is interesting but not as strong as I would like, and not unique to immutable distros. In additiom to that, flatpak and docker have very little supply chain security compared to the traditional distro model of packaging, so the result is that we are trading this invincible supply chain (Debian/RedHat enterprise linux (but NOT fedora or bazzite or other less stable distros/Ubuntu were not affected by xz utils backdoor) for weak sandboxing, which is not something I'm very happy about.

Security makes a lot of trade offs between other elements of security, and features and peformance.

I can't get into a discussion about something I know too little about it. But, it has a reduced attack surface. Do you agree on that?

os wise. software is in a different partition.

Not generally a fan of the opensuse products myself, but i do highly recommend trying immutable systems! Such a breeze to deal with. Been running Bazzite on main desktop pc for years now. Now looking into uCore for my servers too. Universal Blue doing excellent work for this community 💙

No, the root system being read only is not a security benefit. Attackers (with root or a root exploit) can remount as read only, or remove the immutable bits on files.

In addition to that, thinks like /var usually contain persistent state which can be written to, even on an immutable system

Now, an attackers changes to the root filesystem would probably be overwritten on the next image upgrade. Although better is impermeance, where the root filesystem is generated from config files on boot (NixOS can do this). That is better because now the system is wiped every boot, however it runs into some of the same issues: an attacker with root can modify the update mechanism, or the persistent config files.

While I would say that an immutable system offers practical security benefits, in that most existing Linux malware probably is designed for an orthodox system, it doesn't offer theoretical security benefits. It's just security by obscurity that will probably wane if/when immutable distros get more popular.

Yes, or you just let it do automatically and don't even know that it updated in the background.

Thank you! Does that mean you have to reboot every time you update something?

@illusionistReminds me of the old joke about Windows. "A new mouse position has been detected, please reboot your computer for this changes to take effect.."@slazer2au

Only the running system is read only, not everything. You simply boot into a new version when updating. If the new image fails, it boots into the old snapshot (i haven't seen this in practice on opensuse aeon because it did not yet break)

Followup question, how do system files get patched if its mounted as RO?

Bingo.

I'd say use cases are home users sure but it would be even more appreciated in schools and offices. In those scenarios you're more likely to worry about security concerns than an end user accidentally borking something and having to revert.

The root filesystem is mounted as read-only. Attackers can't write to or modify it.

As someone that is not really interested in immutable distros, what is the use case here when btrfs covers the quick and easy rollback part already?

Thanks to Packman, many of us have been able to use openSUSE as the operating system on our PCs. I don’t currently use the Packman repository because, with the openSUSE openh264 repository, all the multimedia files I use work fine. Thank you for the great work you’ve done, particularly for enabling so many of us to use openSUSE; ever since we tried this magnificent distribution, we’ve stuck with the ‘chameleon’ of Linux.

Oh no.

I know it's very much a 'self serving' situation as a user of Opensuse Tumbleweed, but this is nice.

I would start by grepping /var/log/zypper.log for aborted or posttrans, seeing where the previous installation failed to run the post transaction hook. Then check the timestamp and see if it makes more sense what happened.

I don't use opensuse, or zypper, (arch btw) so I'm sorry I can't give more detailed help.

The good news is I've seen multiple broken Ubuntu/Debian/etc systems from aborted upgrades too. So I don't think your situation is unique to your distro. It's more about learning what you system is actually doing when you update and how catch when something has gone wrong.

OK, that's interesting :) I'm learning something new. What would I be looking for in the Zypper history log? Any keywords you'd look for?