• 4 Posts
  • 100 Comments
Joined 1 month ago
cake
Cake day: January 6th, 2026

help-circle








  • oversimplifying a bit:

    TLS (https) provides transport security that whatever is served by the mirror is really associated with the domain name for that mirror domain name. Each HTTPS response is signed live so the private key must be “hot” and loaded in memory on the mirror (or its reverse proxy).

    PGP signatures provides integrity and authentication that the package files themsvelves have been signed by the repo signing key. This signing can be done once per package and the private key can be offline.

    HTTPS is not a replacement for PGP sigs. They are for different things. HTTPS will provide a bit better privacy (and now that I think of it, theoretically some package manager could be vulnerable to downgrade mitm - substitute a package with a legit and signed but older vulnerable version - or other bugs).

    PGP on the other hand is such a mess that even some cryptographers don’t like it.

    I’ve seen plenty of critique on PGP for email encryption but that’s not relevant here.

    sq (sequoia) is great alternative implementation you can use instead of GnuPG.




  • Tricking users into using Snap without realizing it, making them unknowingly vulnerable to exploits like this, would be really really bad and unethical on Canonical’s part.

    That is not what is happening at all.

    Just so nobody is confused or gets afraid of their install: Getting the Firefox snap installed via Ubuntus apt package does not make users vulnerable to what is talked about here and is just as safe as the apt package version. For Firefox snaps might even be safer since you will probably get security patches earlier than with apt upgrades and get some sandboxing. In both cases you are pulling signed binaries from Canonical servers.

    The post is about third-party fake snaps. If you run a snap install command from a random web site or LLM wkthout checking it, or making a typo, then you are at risk. If Ubuntu didnt have snaps, this would be malicious flatpaks. If Ubuntu didnt have flatpaks, it would be malicious PPAs. And so on. Whatever hosted resource gets widely popular and allows users to blindly run and install software from third-parties will be abused for malware, phishing, typosquatting and so on. This is not the fault of the host. You can have access to all the apps out there you may ever want or you can safely install all your apps from one trusted source. But it’s an illusion that you can never have both.

    People have opinions about if snaps are a good idea or not and thats fine but there shouldnt be FUD. If you are using Canonicals official snaps and are happy with them you dont have to switch.






  • The concept is attractive.

    Since back before “atomic” and “immutable” were fashionable buzzwords, I’ve had a few Alpine installations running something like this. Their installer supports it. https://wiki.alpinelinux.org/wiki/Immutable_root_with_atomic_upgrades

    I guess I’m also not alone in having been running OpenWrt with atomic upgrades for many years.

    Since then been running a ublue fork (Aurora) for a while now. Forking it and running the builds on my own infra instead of relying on their GitHub works after hacking up the workflow files but it’s quite redudandant and inefficient with IMO one too many intermediate layers (kinoite -> akmods -> main -> aurora/silverblue/bazzite -> iso) downloading the same things multiple times repeatedly despite spending considerable overhead on caching. It’s clear that building outside of their GitHub org is not really actively supported.

    Also tried openSUSE microOS (Aeon) a year or two back for a while. I want to like it but find zypper and transactional-update pretty uncomfortable and TBH sometimes still confusing to work with. Installing it on encrypted RAID was daunting IIRC. Rough edges. Enough out-of-date docs on the official site to make Debian wiki look like ArchWiki in comparison.

    KDE Linux looks promising but it was still in a very early and undocumented stage last I looked. Great to see the progress.

    More recently been looking more at Arkane Linux and been using it for some months now. It’s an immutable with Arch base. Much easier to customize and maintain than the ublue options and a lot less time spent triggering and waiting for builds - while having less stuff pulled from third-party servers in the process and an easy way to fork packages by cloning and submoduling an AUR repo. Lot more straightforward to make work without relying on GitHub. If you’re looking at rolling your own builds and are comfortable with Arch, I highly recommend checking it out. My fav so far.

    https://arkanelinux.org/

    https://codeberg.org/arkanelinux/arkdep

    Given the self-contained nature of Debian - cloning the Debian sources is enough to do a complete offline build of everything - I think it’d be the most interesting base for a sustainable immutable distro unless you go to the opposite end with “distroless” (no comment). Looking forward to one.


  • kumi@feddit.onlinetoLinux@lemmy.mlDrag and Drop is an absolute mess
    link
    fedilink
    English
    arrow-up
    17
    ·
    edit-2
    20 days ago

    It’s not as black and white as they say. Flatpak is not a bad choice per se but not without tradeoffs and they can come with catches like this because of the security model. There is no one-size-fits-everyone here. If you want all your apps to have access to everything your user does and value convenience over the sandboxing, flatpaks might not be the best choice for your situation. Also like for any repo with external third-party uploads, quality varies a lot between apps and maintainers on flathub. Some are excellent and some are in a sorry state. Before installing from fllathub its a good idea to some basic due diligence on the package and maintainer before jumping in.

    I agree with the IanTwenty that the UX has room for improvement in making it more obvious what’s going on and making it easier to manage customizations and overrides. For the time being, getting comfortable with Flatseal and learning more about Flatpaks seems like the best way for a user to make it work for them if defaults don’t work out.

    Flatpak has tradeoffs and whatever is on flathub is not guaranteed to always be your best pick. That doesn’t make it Bad. Going as far as calling them harmful in general is hyperbole. It can still be a great option for many users.




  • Apart from what others said about power/throttling, I wonder if the filled up memory during the upgrade (or other memory-heavy use) pushes some central pages to swap and then they stay there after?

    After the upgrade and you have plenty of free memory again you can force back everything to RAM by temporarily disabling swap:

    swapoff $swapdev && swapon $swapdev  
    

    To list swap devices, just run swapon.

    Also switching to an X11 window manager can be quite a lot snappier than modern GNOME for older hardware. You could try Xfce, Cinnamon, MATE, or KDE with the X session.

    If it’s not throttling/thernals, I wouldn’t be surprised if those two together is what made things worse after migrating dist.

    If you’ve been swapping heavily over time you might also want to check disk health with smartctl and check that you don’t have related errors in dmesg.

    If you press tab in htop you can also see if there is high IO load going on.