Debian 13 status and how to upgrade from Debian 12 to 13 via extrepo?

Support
1

How is the development status for Debian 13? From what I see here, Debian 13 hasn’t been added into extrepo data yet. repos/debian/kicksecure.yaml · master · External repositories team / extrepo-data · GitLab

I enabled Kicksecure repo from extrepo. How do I upgrade everything from Debian 12 to 13 from the repo contained in extrepo?

2

Kicksecure 17 is based on Debian 12 (Bookworm) and is not compatible with Debian 13 (Trixie). Kicksecure 18 will be based on Debian 13.

Kicksecure 18 is still in (very active) development, it isn’t suitable for daily use or beta testing yet (though it may be pretty close to beta-testable). When it is available, you will be able to upgrade an existing Kicksecure 17 installation using a release-upgrade script, and ISOs and VM images will be available for clean installation. Until it is released however, do not attempt to upgrade your system to Debian 13, you will break your system.

1 Like
3

I didn’t install full Kicksecure because there are too many things that I don’t need, such as GUI and Tor.

I have only installed certain packages from Kicksecure.

I did apt install -y security-misc usability-misc tirdad* sandbox-app-launcher kicksecure-base-files dist-base-files apparmor-profiles-kicksecure apparmor-utils on a Debian 12 fresh installation.

4

It still is probably a good idea to wait for Kicksecure 18 to be released, since those package’s contents may change substantially and there may be upgrade issues with them if you try to upgrade now.

2 Likes
5

Now it is released but I can’t upgrade. Because I installed Kicksecure 17 on Debian 12. I can’t pass file checks with release-upgrade

6

Not to my awareness. There is no release announcement for Kicksecure 18 at News - Kicksecure Forums.

You aren’t using full Kicksecure, you’re using Kicksecure packages on top of Debian, so the release-upgrade script will almost certainly not work for you. It is designed to upgrade a full Kicksecure installation. Regardless though, you still should not be trying to upgrade yet. (We’re still finding and working out bugs; the Wayland and LXQt transition has taken quite a bit of development work to get right.)

1 Like
7

Oh I see. Thank you.

But I think move to Wayland is not a smart move. X has been used for a long time and it is more stable.

By the way, I don’t see any discussion in Kicksecure forum about move from X to Wayland?

8

X was a more stable platform, and for a limited set of applications it is is preferable to Wayland. The X.org server however has been abandoned upstream, and is for the most part deprecated and bitrotting (this is beginning to show with application support, toolkit support, and driver support, and will get worse over time most likely). Moving to Wayland is not simply a security enhancement move, it is vital for ongoing usability in the future.

It’s been in planning for a while, but the discussion was mostly on the Whonix forum. See:

9

There was a change submitted 3 days ago, it doesn’t seem like abandoned:

Many important applications doesn’t work on Wayland. Also, X is more stable and less bugs and will contain obvious fewer security flaws than Wayland. Switching to Wayland will reduce the security of Kicksecure.

10

The primary developer was Red Hat, which deprecated X.org in RHEL 9 and fully removed it from RHEL 10. The last changes were reverts to fix regressions, i.e. not code being fixed, but code being completely removed. That’s not the same as being truly maintained or developed. (It does seem like it’s seeing more changes than I believed it was receiving when I wrote that it was abandoned upstream, but I don’t really see how “this feature doesn’t work, no one wants to fix it, let’s throw it out” is really maintenance.) Additionally, the X.org repository Git history is not really a good way to measure the activity of the standalone X.org server, since the same repo also contains Xwayland, which is actively developed and maintained.

This is increasingly becoming less and less of a problem. For users who absolutely need X.org, it’s still in the Debian repos, you can install X.org and an appropriate window manager or similar to run software that requires X11.

This has not been my experience personally, see notes about bitrotting application, toolkit, and driver support above.

I don’t believe this is the case. Wayland doesn’t rely on simply being a better display server implementation for security, it does a number of things that fundamentally make it less of a security hazard than X11 even if the compositor or libraries it depends on contain security vulnerabilities. For instance:

  • X.org traditionally runs as root (and I believed ran as root even in Kicksecure 17), meaning a compromise of the display server is equivalent to a compromise of the entire system. Wayland runs in a logged-in unprivileged user account.
  • X.org exposes its IPC sockets in a world-writable location, increasing the risk that a malicious process running as a restricted user like man could compromise the server. Wayland saves its IPC sockets in /run/user/UID, which is only available to the logged-in user itself. Thus applications are authenticated to the server just by virtue of being able to connect to the socket, and unauthorized applications are unable to connect because of kernel-level filesystem restrictions.

These two advantages alone are huge because it means that almost any application that could connect to and compromise the Wayland server, most likely would gain no further access to the system by doing so (the only exception would be GUI applications with AppArmor sandboxes). An application might compromise the Wayland server to read the window contents of other applications or sniff keystrokes, but these are both things that X.org allows by design, so there’s no additional risk there. The display server goes from being a highly valuable exploit target to being relatively uninteresting. Even if labwc (our chosen Wayland compositor) or wlroots (the library it uses to implement a Wayland compositor) turns out to be riddled with security holes, it’s still better than a nearly bulletproof X11 would be (and X11 is not nearly bulletproof).

1 Like
11

I thought Kicksecure is based on Debian instead of RHEL? I also don’t trust this company at all. I think it just proves that we need to rely on Xorg and abandon Wayland.

but I don’t really see how “this feature doesn’t work, no one wants to fix it, let’s throw it out” is really maintenance.

Sometimes just remove codes is a good thing isn’t it? Keep it simple and stupid.

Wayland doesn’t rely on simply being a better display server implementation for security

Does that “implementation for security“ base on adding more security features? It will expand the code base and the more mechanism and codes you have the more possible there will be security issue.

The X server interacts with hardware. Something has to interact with hardware.

I highly recommend read this article:

12

Yes, but RHEL is/was the primary developers of X.org as I understand it.

That should be (and is, with both X.org and Wayland) the kernel.

I am familiar with the article.

1 Like
13

Great. So no feature will be added and only bug fixes, so everything will run stable. One more reason to use Xorg over Wayland. But I prefer we keep both in use.

I don’t trust them. Their ultimate goal is to control open source community.

By the way, you can run X server rootlessly.

So let’s keep Wayland and Xorg both in support.

14

Port to Wayland in version 18 is a done deal. Re-adding Xorg support would be a high effort and maintenance issue. Hence, not planned.

Related:
Wayland only or Noland

2 Likes