A few days after release, I grabbed openKylin-Server-V3.0-2026.8.27-3-arm64.iso and spun it up in UTM on an M5 MacBook Air to see what’s actually in it. openKylin is a Chinese Linux distribution developed under the OpenAtom Foundation — it descends from the Kylin / NeoKylin lineage, which has roots in Chinese government and defense procurement, but openKylin itself is pitched as the free, open-source community branch, distinct from Kylinsoft’s commercial “Kylin Server” product. Version 3.0 shipped around August 27, 2026, so this is a days-old major release with essentially no public analysis in English yet.

I treated the VM as a research subject, not infrastructure: isolated network, throwaway credentials, read-only poking wherever possible, nothing from the guest executed on the host.

Getting it running

  • Host: macOS on Apple Silicon (M5 MacBook Air, 32GB)
  • Hypervisor: UTM, QEMU backend, aarch64 with hvf acceleration
  • The VM sits on an isolated UTM network, not my Tailscale tailnet, holding nothing of value

The installer itself is unremarkable in the way that matters — it’s a normal Debian/Ubuntu-style server installer, and it got a working aarch64 system up without drama. Package mirrors are hosted in China (archive.build.openkylin.top), so apt operations are noticeably slow from the US. That’s not a bug, just geography — give it long timeouts and let it work.

One thing worth calling out for anyone doing the same thing in UTM: my resolv.conf on the guest picked up DNS search domains from my Mac’s active Tailscale session (*.ts.net) purely via DHCP relay from the UTM host gateway. The VM itself never touched Tailscale — no binary, no service — but it’s a reminder that an “isolated” VM network can still leak host-side network metadata to an untrusted guest depending on your virtualization network mode. Worth checking if you care about that.

What openKylin actually claims for 3.0

Reading their release material, four things stood out as testable:

  1. First distribution to ship on Linux kernel 7.0
  2. A refactored, Rust-based system userland
  3. Post-quantum cryptography in the base system
  4. “Panshi,” a novel permission and reliability architecture (“Boulder”), opened up in 3.0

I went through each of these from inside the installed system, plus took a broader look at how openKylin actually relates to its upstream.

Kernel: confirmed

$ uname -a
Linux openkylin 7.0.0-2-generic #0ok7-KYLINOS SMP PREEMPT_DYNAMIC Wed Aug 26 16:23:24 UTC 2026 aarch64

Kernel 7.0.0 with a -KYLINOS build tag, built the day before the ISO’s release date. The “first on 7.0” claim checks out, at least as far as version number goes.

The bigger surprise: it’s Ubuntu, not Debian

openKylin is routinely described as Debian-derived. Looking at the actual package metadata, that’s not what’s installed. Of 552 packages on a fresh server install:

  • 354 packages — including bash, coreutils, and systemd — still carry an unmodified Maintainer: Ubuntu Developers <[email protected]> field
  • ~177 packages have been re-maintained under openKylin Developers <[email protected]>
  • /etc/os-release doesn’t even declare an ID_LIKE field, so it doesn’t claim lineage either way

Every package, regardless of maintainer, carries openKylin’s own -okN build suffix (bash 5.3-ok1, coreutils 9.4-ok4, systemd 259.5-ok1.5), so everything passes through their build pipeline — but the packaging metadata is unambiguous that the source is Ubuntu, not Debian.

There’s a real pattern in what they re-maintain versus what they just rebuild:

  • The 177 re-maintained packages skew toward base-system and security-relevant tooling — apparmor, cron, cryptsetup, git, fwupd, bind9, busybox, dash
  • Deeper libc-adjacent packages — bash, coreutils, systemd — are straight rebuilds under Ubuntu’s original attribution

Two changelog samples make the split concrete. git’s changelog.Debian.gz is the stock Ubuntu CVE-patch changelog, and its most recent entry still refers to nile — an older openKylin release codename — even though this system is huanghe. That’s a low-touch rebuild whose metadata didn’t get refreshed. By contrast, apparmor ships at 5.0.0~beta1-ok2 (notably ahead of upstream stable, which is around 4.x) with a real human commit:

apparmor (5.0.0~beta1-ok2) huanghe; urgency=medium

  *skip test.

 -- liubo01 <[email protected]>  Fri, 14 Aug 2026 11:21:44 +0800

kylinos.cn is Kylinsoft’s commercial domain. So despite the public narrative separating openKylin (community) from Kylinsoft (commercial), Kylinsoft engineers are directly committing to openKylin’s packaging — at least for apparmor. That’s a small, verifiable detail that complicates the clean community/commercial split usually described.

Rust userland: no evidence found

openKylin advertises a Rust-based refactor of system tools in 3.0. On this server image, I couldn’t find any trace of it:

  • ls, cat, cp, mv, grep, find, ps, top, df, du, mount are all standard GNU coreutils / procps / util-linux binaries — checked with file and by scanning for rustc/cargo build markers in the binaries themselves
  • GNU coreutils 9.4 and findutils 4.10 are installed and are what’s actually in /usr/bin
  • No uutils, eza/exa, bat, ripgrep, fd, or similar Rust reimplementations are installed anywhere
  • A broad scan of /usr/bin, /usr/sbin, /usr/libexec for Rust build markers turned up exactly two hits, both false positives — one was git’s binary matching an unrelated substring inside the config key core.trustctime

I’ll state this plainly rather than hedge it: on this specific server build, the Rust userland claim doesn’t hold up. It’s possible this applies to the desktop edition, or components not present on a minimal server install, or it’s roadmap language that got ahead of the release. But “claimed, not found” is the honest result here.

Post-quantum crypto: real, and on by default

This is the one claim that genuinely checks out.

openssl list against the default provider (OpenSSL 3.5.5) shows ML-KEM-512/768/1024, the hybrid KEMs X25519MLKEM768, X448MLKEM1024, SecP256r1MLKEM768, SecP384r1MLKEM1024, and ML-DSA-44/ 65/87 signatures. More interestingly, the effective SSH server config (sshd -T, root-checked) lists mlkem768x25519-sha256 as the first-preference key exchange algorithm, ahead of classical curve25519-sha256. That means a stock SSH connection to this box negotiates a post-quantum-hybrid key exchange by default, not just when explicitly requested.

SSH host key algorithms remain classical only — no ML-DSA host keys — which lines up with where upstream OpenSSH actually is; PQC host authentication isn’t standardized or shipped anywhere yet.

Worth being precise about attribution here: openssh-server 10.2p1 and openssl 3.5.5 are recent enough upstream releases that this PQC support and its default-on posture come from upstream OpenSSH/OpenSSL, not custom openKylin engineering. What openKylin gets credit for is shipping current-enough software, fast enough, to inherit it — which is a real and somewhat unusual achievement for release cadence, just not the novel cryptographic engineering the marketing implies.

One related, distinctive default worth a mention: the kernel has the sm4 module loaded, and OpenSSL’s default provider fully implements China’s national cryptography suite (SM2/SM3/SM4, correct OIDs under the 1.2.156.10197.* arc) as first-class, enabled algorithms. Not a security architecture, but a genuinely distinctive default most Western coverage of this release probably won’t mention.

Panshi / “Boulder” permission architecture: not found

This is the least documented piece of openKylin’s pitch — their own permission and reliability architecture, explicitly not SELinux and not AppArmor, that 3.0 supposedly “opens up.” I searched exhaustively:

find /etc /usr/lib /usr/share -iname '*panshi*' -o -iname '*kysec*'
systemctl list-units --all | grep -iE 'kysec|panshi|kylin'
man -k mac

All empty, aside from two unrelated hits (kylin-build, kylin-version — build metadata packages, nothing to do with permissions). The active LSM stack, read from /sys/kernel/security/lsm, is lockdown, capability, landlock, yama, apparmor, ima, evm — the standard modern Ubuntu-server stack, with AppArmor active. SELinux libraries are installed as a dependency of something else but SELinux itself is not in the active LSM list and has no policy tooling present.

Whatever Panshi is, it leaves zero trace anywhere on this server ISO — no config, no service, no binary, no documentation. This is worth stating as a clean negative result rather than something I “couldn’t find good documentation for.” It’s possible it’s desktop-only or not yet in the server track, but on this build, it does not exist.

Network behavior on a clean boot

A headless server should be quiet, and this one is. Root-level ss -tulpn shows exactly three things listening: SSH (22, v4 and v6), the systemd-resolved stub resolver (127.0.0.53/54 plus LLMNR on 5355), and chronyd’s local NTP client socket. Nothing else reaches out.

motd-news, Ubuntu’s dynamic-MOTD phone-home mechanism, is present but disabled by default (ENABLED=0), and its configured URL is repointed to https://motd.openkylin.top rather than Canonical’s servers, which is exactly what you’d expect from a proper rebrand. Running services and timers (apt-daily, fwupd-refresh, logrotate, fstrim, sysstat, dpkg-db-backup, etc.) are all standard Ubuntu-server boilerplate. NTP and DNS servers are pulled entirely from DHCP, no hardcoded openKylin endpoints. No telemetry, license check, or activation service anywhere.

The takeaways

  1. openKylin 3.0 Server is a rebuilt Ubuntu, not a Debian derivative, whatever the branding implies. 354 of 552 packages, including bash, coreutils, and systemd, still carry unmodified Ubuntu maintainer metadata, and os-release doesn’t declare lineage at all.
  2. Kylinsoft, the commercial vendor, is directly committing to openKylin’s community packaging — not merely sponsoring it — as shown by a @kylinos.cn-attributed commit inside the AppArmor package. That undercuts the usual clean separation drawn between the “free community project” and the “commercial product.”
  3. Panshi, their headline permission architecture, is completely absent from the server build — no files, no services, no LSM presence, nothing. A clean, verifiable negative result, not a documentation gap.
  4. Post-quantum crypto is real and on by default, but it’s an inherited property of shipping current upstream OpenSSH/OpenSSL rather than something openKylin engineered themselves.
  5. The claimed Rust userland refactor doesn’t show up anywhere on this image — GNU coreutils is still what’s actually running.

None of this is damning — most of it is just a distribution doing normal distribution things, with marketing running a little ahead of what’s actually shipped in this particular release track. But the Ubuntu-not-Debian lineage and the Kylinsoft packaging involvement are, as far as I can tell, not stated plainly anywhere else in English right now.