It also completely misses what I was saying. I was referring to making the status of forks visible directly in the generated debtree dependency diagram.

... but the debtree doesn't directly highlight that xserver-xorg-core is itself forked - would be nice if there was some way to have an indication of that.

(I'm sure it's not recommended practice, but...)

emanym@euterpe:~$ for i in `apt-cache search xserver- | sed -e 's/ .*//'`; do apt-cache show $i | grep Filename ; done

...
Filename: pool/DEBIAN/main/x/xserver-xorg-video-qxl/xserver-xspice_0.1.5+git20200331-3_amd64.deb
Filename: pool/DEVUAN/main/l/lightdm/lightdm_1.26.0-8+devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xorg-server-source_21.1.7-3+deb12u2devuan1_all.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-common_21.1.7-3+deb12u2devuan1_all.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xephyr_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xephyr-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-core_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-core-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-dev_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-legacy_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-legacy-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb

Searching for xorg in the Devuan repos only returns xorg-server - which is the source package for "xserver-xorg-core", aka "Xorg X server - core server".

That's different to the "X.Org X Window System" from the "xorg" package I was referring to, but it is a dependency of it.

Searching the debtree of xorg for "devuan" highlights that xserver-common is also a fork, (unsurprising since it comes from the same xorg-server source package), but the debtree doesn't directly highlight that xserver-xorg-core is itself forked - would be nice if there was some way to have an indication of that.

It also seems the issue in your linked thread has yet to be resolved - based on the versions listed at //pkginfo.devuan.org/xserver-xorg-core and //tracker.debian.org/pkg/xorg-server, there should be a 2:21.1.7-3+deb12u4devuan1 in daedalus-proposed-updates and a 2:21.1.7-3+deb12u5devuan1 in daedalus-security channel.

Xorg does not depend on systemd. The promptness of its security updates is due to the Debian X Strike Force, and the Debian Security Team.

None of these packages depend on systemd, none of these packages are forked by Devuan, security for them is not handled by the Devuan team.

That is not completely true. The package xserver-xorg-core does not come directly from Debian; it is a Devuan package. Is this true for any other Xorg-related packages? I don't know because I haven't had time to check.

By the way, someone pointed out this fact out a little over a month ago on this forum.

Addendum:
But when I do an update, it doesn't come from a Debian server. It comes from deb.devuan.org. Do the updates from Devuan come to this repository without delay? That's what makes me happy, everything happens very quickly. How should I imagine that?

Firefox does not depend on systemd. The promptness of its security updates is due to Debian maintainer Mike Hommey, the Debian Mozilla Team, and the Debian Security Team.

Chromium does not depend on systemd. The promptness of its security updates is due to Debian maintainers Andres Salomon, Timothy Pearson, the Debian Chromium Team, and the Debian Security Team.

Xorg does not depend on systemd. The promptness of its security updates is due to the Debian X Strike Force, and the Debian Security Team.

None of these packages depend on systemd, none of these packages are forked by Devuan, security for them is not handled by the Devuan team.

This is not a slight on those who maintain Devuan but an attempt to communicate that Devuan is Debian (with systemd removed).

The Devuan Team do important work to maintain init freedom - and absolutely deserve credit for that - but they have nothing to do with how your web browser, mail client, or display server works.

Sure ...
Why not.
Seems to be doing fine. -> see steve_v's excellent explanation above
But ...
What about the security holes you have made reference to?
Please, humour me.

Neither am I, like you, just a user with just a few years' experience with MS and Linux under my belt.
ie: not a coder/programmer/maintainer. Can hardly manage to $ ./configure | $ make | # make install once in a blue moon.

Well, you should know by now that to get to more and more common all you need are enough posts constantly beating that same drum over and over again till it ends up becoming common enough.

Along the same lines and only to illustrate my point:   <- no intention of starting a discussion
In the US, the view that Wayland Donald Trump is more secure the best president they ever had is becoming more and more common.

I see.
Lacking that important piece of IT review, it would then seem that ... the view that Wayland is more secure ... does not have much to stand on.
Yes?

Given the bloat and its provenance, I (very) seriously doubt it.
Of course, YMMV.

Like I said, I am (like you) just a user so I cannot/would not do that.
ie: I lack the needed know-how / training.

What I can tell you is that I have continuously used X11 for a great many years through (in hindsight) far too many distributions and have had no issues with respect to security or anything a well written xorg.conf could not (99% of the time) fix.

As far as I am concerned, the burden of proof is on Wayland and not on X11.
ie: Wayland has to prove to be both better and more secure than X11.

Not the other way around.

Thank you for your input.

Best,

A.

On the other hand, there was yet another set of xorg security updates that we don’t get because it's forked.

For security related questions, just check this

https://security-tracker.debian.org/tra … ckage/xorg

if a window is hijacked, X11 also leaks the data from the other windows to the attacker.

That's not a bug, it's a design decision.
X was not developed for personal computers, it's fundamentally a graphical mainframe technology. In that scenario the trust model is inverted WRT a PC - i.e. the network is secure, applications are served from the mainframe and implicitly trusted, the terminal running the xserver is not.

X is as secure as it has ever been and (at least for now) it's still getting patches for any newly discovered issues, but the core design concepts don't transfer particularly well to the age of software-as-an-enemy... Then again, as long as you don't run untrusted applications that might want to screenscrape or keylog you, you're fine.