Release LordOS 0.8.5-beta · lordbasex/LordOS

Added

A curated catalog of AI apps in the LordOS repository. apt/catalog.json lists nine apps with their package, summary (en/es/pt), licence, vendor, architectures (amd64 and arm64) and a pinned source; apt/keys/ holds the vendors' APT keys, apt/recipes/ LordOS's build recipes and apt/build.sh checks and fetches them (apt/README.md, docs/UPDATES.md "Mirrored apps (catalog)"). Claude Code, Claude Desktop, Visual Studio Code and Cursor come straight from their vendors' signed APT repositories ("direct"): apt/build.sh check verifies the pinned key fingerprint, the signed InRelease, the index hash and the package for each architecture. The other five are verified on the maintainer's machine and published in pool/catalog/ by tools/release/apt-repo.sh build … --catalog: goose 1.56.0 and opencode 1.19.4 (the vendor's .deb, pinned SHA-256), and three packages LordOS builds in debian:trixie containers with no network — llama.cpp 0.7.0, the local model runner (-hf downloads GGUF models from Hugging Face over HTTPS; every CPU variant built and the best one picked at run time, plus the Vulkan backend, loaded only when a Vulkan device exists), whisper.cpp 1.9.5 (CPU) and codex-cli 0.164.0 (OpenAI's static binary, its sigstore signature checked with cosign). Vendor packages are never modified; what their maintainer scripts do when the Store installs them (VS Code, Claude Desktop and Cursor add their own APT source) is documented.
Store → Artificial Intelligence. The catalog as a page of the Store: each app with its kind, vendor and licence, dimmed on an architecture it doesn't support. An app from its vendor's repository first says whose repository it adds and its key fingerprint, then adds it (pkg-source-add, the key checked against the catalog's fingerprint) and fetches the lists; removing the app removes that repository unless another installed catalog app uses it. An app LordOS builds that the lists don't have yet offers to fetch them again instead of "package not found". Cursor's package always writes its own source (cursor.sources, Signed-By: /usr/share/keyrings/anysphere.gpg), and a second entry for the same repository with another Signed-By stops apt reading any source, so its catalog entry names those files and LordOS writes the same ones (the key dearmored). Tested on the VMware machine: llama.cpp installed from the Store (14 MB), llama-server -hf ggml-org/Qwen3-0.6B-GGUF:Q8_0 downloaded the model on first run and answered over its HTTP API on the CPU (about 33 tokens/s, no Vulkan device); on VM 116, Cursor's and VS Code's sources added, Cursor installed (its own script rewrote the same file), apt update and the Store's own update both clean, then removed.
The Store's new look. A sidebar in three groups (Store: Discover, For this computer, Installed, Updates; Categories: Artificial Intelligence and Debian's ten categories, each with its count; LordOS apps), the page's title, a back button and the search in a toolbar, and apps as cards in a grid that fills the window: icon, name, category, two lines of summary, the download size and a Get, Open or View button. Discover opens with a featured banner, then the AI shelf and a shelf per category with "See all"; an app's page has a larger icon and a row of facts (version, size, category, distribution). The hardware suggestions moved to their own page, For this computer, which keeps the badge for new ones.
A featured banner LordOS can change without a release. Discover's banner comes from apt/featured/featured.json and apt/featured/banner.png in the repository: apt-repo.sh checks them (a schema 1 JSON object of at most 64 KB, a PNG of at most 2 MB) and publishes them signed with the indexes (main/featured/), and the package engine takes them only from a source whose signed Release says Origin: LordOS, checks their hashes, parses the JSON and the PNG signature, and keeps them in /var/lib/lordos/pkg/ (lord.pkg.featured(), read-only). The picture fills the banner under a shade; while it isn't there yet the Store draws a skeleton of the banner (it pulses, unless Reduce motion is on), and a system whose repository has no banner shows a catalog app instead. Tested on VM 116 against lordos.org/apt-staging: the banner, its skeleton without the image, For this computer, the categories and the cards.
Store → Commercial. Free-of-charge apps whose source code isn't public, from their makers' signed APT repositories with the key LordOS pins: Google Chrome (amd64 and arm64), Edge and Spotify (amd64). The page says before anything is installed that LordOS can't review or fix what they do, and points to For this computer for graphics drivers. Their packages write their own APT source: for Chrome and Edge the catalog names those files (google-chrome.sources, microsoft-edge.sources and their keyrings) so the package's write changes nothing, and for Spotify, which adds spotify.list unless that file exists, a new catalog field optout makes pkg-source-add create it empty (only when missing; pkg-source-remove deletes it only while it is still empty). Tested on the VMware machine with the admin action and LordOS's package engine: the three sources added, the three apps installed (Chrome 156.0.8078.47, Edge 156.0.4314.50, Spotify 1.2.95), apt update with no error or warning and the engine's update clean afterwards, and Chrome's window opening in the session. Spotify's package also copies its key into /etc/apt/trusted.gpg.d/, trusted by apt for any source without Signed-By (Debian's own sources have one). Steam needs i386 multiarch, which LordOS's package engine doesn't do yet (roadmap).
Root over SSH, as an advanced option. Settings → Sharing → Advanced lets an administrator allow root to log in over SSH with a public key only, or with a key or a password, for tests and administration: the keys are pasted or imported from a .pub file and listed with their fingerprints, root's password can be set, every change asks for your password again, and a warning stays visible while it is on. Off by default, and off again with one click.
The Store downloads over HTTPS. LordOS's package engine now speaks HTTPS as well as HTTP: a small sandboxed helper (lord-tls) checks the server's certificate and name and encrypts the download, so repositories that only accept HTTPS work, and what you install is private on the network. Every package is still checked against its signed index, as before; a secure download is never redirected to plain HTTP.
A guide to building an appearance. docs/THEMES-GUIDE.md explains, for a React developer new to LordOS, what a theme is, its parts (theme.json, tokens, the shell, window frames, menus, layers), right-to-left, light and dark, several displays and the performance rules, how to build and test one, and a checklist; examples/theme-minimal/ is a small working theme to start from. It also says plainly what is missing: a theme LordOS didn't sign doesn't load on a release build yet (no theme package format or user trust decision exists).
Settings → Displays: numbers, Identify and snapping. With more than one display each one has a number (the main display is 1); clicking a display in the arrangement, or Identify, shows its number big on that monitor for a moment, so you know which screen is which. Dragging a display snaps it edge to edge and aligns it with the others (side by side, stacked or offset), and a drop never leaves two displays overlapping or apart. The server keeps a position that fits exactly, and a chain of three displays is no longer pulled back onto the main one on every change.
A fuller Window menu, in both themes. Minimize, Zoom, Fill, Center; Move & Resize with the left, right, top and bottom halves, the quarters and thirds, arrangements of two windows (left and right, right and left, top and bottom, bottom and top) or four (quarters) with the windows behind it, and Return to Previous Size; Move to for every other display (a snapped window keeps its zone, the rest keep their place relative to the screen); Bring All to Front; and the open windows, the one in front checked.
Dock: Open at Login and Assign To. A Dock item's Options menu can open the app when you sign in (started the same way as a Dock click) and, with more than one display, assign it to a display: its new windows open there (kept by the display's name across boots).
One place to choose the desktop style. Settings → Appearance → Desktop style now lists every installed theme, and the separate Themes page is gone (an old link to it opens Appearance).
The app menu and Force Quit (Lord Flow). Clicking the app's name in the menu bar opens its menu: About (its icon, name, own version and where it comes from), Settings… (the app's own, ❖,), Hide , Hide Others, Show All and Quit (❖Q). The crown menu adds the Store, with how many updates are waiting, Recent Items, and Force Quit…, which lists the open apps and ends the chosen one without asking it: a Linux or isolated app's own process only (lord.wayland.kill, the same user's client, never X11, which is asked to close), a built-in app without its close guard. In Lord Classic, About is in each window's Help menu.
The themes are called Lord Flow and Lord Classic. The menu bar and Dock theme (formerly Lord Default) is now Lord Flow, and the taskbar and start menu theme (formerly Classic) is Lord Classic, in every language. Only the names changed: your choice is kept.
Menus inside the window in Lord Classic. Lord Classic has no menu bar on top, so an app with menus of its own (Files, Text Editor, Notes, Terminal, PDF Viewer, Photos, Screenshots, Mail, Passwords) shows them in a strip under its title bar (File, Edit, View, Go…, then Window and Help), as desktop apps do with a taskbar; apps without menus of their own get no strip.
Every native app has its own version. Each app's manifest now carries a version (all start at 0.8.5), the build refuses an app without a valid one, and Store → Installed shows it next to the app ("LordOS app · 0.8.5"), so the apps can later be versioned and released apart from LordOS.
Boot time, on the screen and on record. The boot splash shows the time since it started, in seconds and milliseconds, in the bottom right corner. About LordOS → Startup time shows how long this boot took from the kernel's start to the login screen (or, with automatic login, the desktop). Every boot is logged with the LordOS version and build (journalctl -b -u lordos | grep "first frame") and kept in /var/lib/lordos/boot-times.jsonl (the last 200 boots), so boots and versions can be compared; docs/RESULTS.md explains how to check and compare them.
lordos-fetch. Type it in a terminal to see the LordOS crown beside a summary of your computer: system, kernel, CPU, GPU, display, memory, disk, packages and how apps are isolated. lordos-fetch --share leaves out your user and computer names, for a screenshot you'll post.
System Information (About LordOS → System Report…): every piece of hardware this computer has and what LordOS makes of it. The graphics card is shown layer by layer (driver, display output, render node, GPU context, composition, direct scanout) with the exact reason when the screen is composed on the CPU, and a Compatibility panel says what works, what works with limits and what wasn't checked. Its Report tab shows the exact text of a report (Markdown or JSON) before you copy it or save it to Documents; nothing is sent anywhere. Its Checks tab checks LordOS's claims on this computer (display server without root, Landlock, the per-app firewall, verified code, the remote desktop closed when off, app scopes owned by the system) and says whether each was only found configured or actually tried. Run tests starts a test app that tries, inside the same sandbox as any isolated app, what it must not be able to do (your files, sockets, ptrace, leaving its scope, exec), plus the decoders' sandbox and the requests the system must refuse.
Linux video players can keep the screen on (idle-inhibit), and an app that copies now sees its own copy in the clipboard as the Wayland protocol says.
Test Bench (lordos-testbench): a test pattern window that checks the display server from the outside: frame timing and when frames really reach the screen, every key of the keyboard, the mouse and wheel, and the Wayland protocols the system offers. G draws a 3D scene and says whether a real graphics card or the processor renders it; V plays generated video at 24, 30 or 60 frames a second; L locks the pointer; its last report appears in System Information → Checks. Its frame times give the average, the 99th percentile and the frames that missed the display's refresh budget. Keys LordOS keeps for itself (Print Screen, the media keys, ❖ on its own) are outlined in purple.
Versioned results. tools/results/collect.sh writes the evidence for one machine into results/<version>/<machine>/: the hardware report, the Test Bench's report, whole-system memory with PSS per process, and the boot time, with the conditions and the exact commands (docs/RESULTS.md). Releases attach them to the GitHub release.
Monitor → Network shows ping (ICMP), raw IP and packet sockets (the last two can see or forge traffic: the row says so, with the protocol or ethertype and the interface), under the app that opened them, and the remote desktop's own UDP ports under Remote Desktop instead of an unknown "?".
lordos-sysreport report prints the hardware of this computer and what the system made of it, as Markdown or --json, with no serial numbers, addresses or names: the base of System Information.
Files: This Computer and every disk. The sidebar now has This Computer, to browse the whole system read-only as your user (the system's own permissions decide; the kernel's /proc, /sys, /dev and /run stay out), and every disk with a file system: one that isn't mounted shows dimmed and a click mounts and opens it (an internal disk asks for an administrator, as in Disks); a removable one can be ejected from its ⏏. Folders you can't write show no actions that would change them.
Monitor → Network, second generation. The app list is now a tree: each app opens into the sites and addresses it talks to, and each address into its ports, with what was sent and received everywhere, a small live meter and an allow/block switch on every destination. One pop-up button holds the whole view (group by app, domain, address, port or country; incoming or outgoing; TCP or UDP; allowed, denied or with rules; sort by name, most or least traffic, most recent or most connections), remembered for each user. The search turns app:, domain:, ip:, port:, proto: and country: into chips you can combine, and the history zoom (1 h to 30 d) now also shows each app's traffic for that window.
LordOS's own parts have their own rows and rules. Mail and the calendar sync, the Store and updates, printers and scanners, the Terminal (with the names of the programs you run in it) and the blocklist updates each run in a process of their own, so you can see and block each one separately, and the kernel enforces it. Blocking the Store asks first, because security updates stop. Name resolution, time synchronization, the network service and your VPN tunnels are shown too, and are never blocked.
Blocklists. Settings → Privacy → Blocklists offers public lists of advertising, tracker, malware and attacking sites, each with its source and licence; turn one on and LordOS downloads it over HTTPS once a day, in a sandboxed downloader, and blocks those destinations for every app. You can add your own list by its https address. A rule you write for a site always wins over a list: switch a blocked site on in the Monitor and it stays allowed.
Deny silently. A new firewall mode: only what a rule allows can connect, and everything else is denied and recorded (this computer's own services keep working). In Settings → Privacy and in the new menu bar item.
Network activity in the menu bar (optional, off by default): upload and download rates in the menu bar, and a panel with the last five minutes, the apps moving data now, what was recently denied, the firewall mode, the blocklists and a link to the Monitor.

Fixed

A session started at boot could live without its keyring service and its notifications. With automatic login, lord-sessiond started the session as soon as /run/user/<uid> existed, a few milliseconds before the user's service manager opened the session bus, so lord-vault (the Secret Service) and the notification server for Linux apps never got on the bus. Apps then got nothing, or, when an app had pulled in gnome-keyring, that one by D-Bus activation, with its own "Choose password for new keyring" window. lord-sessiond now starts user@<uid> and waits for the bus socket (up to 5 s) before starting the session. And when an app pulls in gnome-keyring, a drop-in shipped by the lordos package (gnome-keyring-daemon.service.d/lordos.conf) keeps only its PKCS#11 component, so LordOS's own keyring keeps the Secret Service. Tested on the VMware machine: after a reboot with automatic login, org.freedesktop.secrets and org.freedesktop.Notifications belong to the LordOS session, and Chrome asks through LordOS's own keyring prompt.
The Store ignored a repository written as Architectures: amd64,arm64. apt accepts commas there (Cursor's package writes it that way); LordOS's package engine split only on spaces, so it dropped that source and never saw the app's updates. Both are accepted now.
Locking the screen and switching user are faster. Handing the screen to the sign-in screen waited for every input device to close, and the last close of a USB mouse stops its transfers: about 0.7 s for VMware's virtual USB mouse, so a lock took 0.6 to 1.1 s there. Access is still cut at once (EVIOCREVOKE); the close now happens on a short-lived thread. Measured on a VMware Fusion VM: 903 ms → 141 ms from the lock to the sign-in screen. A slow hand-off is logged with the time of each step.
A dragged window's corners on the GPU path. While a window is dragged it is painted from a cached layer, and on the GPU path every fully transparent pixel of that layer was taken for the hole of a Linux app's window, including the pixels outside its rounded corners. Now only pixels inside an app surface can be holes. (Black corners while dragging were also seen in remote-desktop frames; that path is still being looked at.)
Dock → Options → Assign To with two monitors of the same model. The assignment was kept by the display's name, which two identical monitors share: both showed as checked and new windows went to the first. It is now kept by the connector (HDMI-A-1, DP-2…); an assignment saved by name still works while that name belongs to one display. Verified on VM 118 with two displays of the same name: Notes assigned to the second display opens there after being moved to the first and quit.
The sign-in and lock screen with several displays. It was laid out over the whole desktop, so the clock, the user and the password field were cut at the seam between two displays; they now go on the main display (the wallpaper still covers every display) and follow a display plugged in or out while it shows. Verified on VM 118 with two displays.
Monitor → Network: the map always shows the traffic. The arc to a country with no traffic at that moment was drawn almost transparent, so a selected app's destinations looked unconnected; arcs now stay plainly visible. Any traffic moves dots along the arcs (orange out, green in), not only above 256 B/s, so a slow app (a ping, a chat) shows its direction too. And the map follows the search and the filters like the list does: all apps, the selected app, or only the connections the filters leave. Short connections (a page, a download) used to close before their own rate was read, which left the arcs still while the app moved megabytes: the app's own rate is now spread over its destinations.
Monitor → Network: one color per app on the map. Each app's arcs have their own color, shown as a dot before the app in the list, and apps that reach the same country get separate arcs, so Chromium, the Terminal and the Store can be told apart; the moving dots stay orange (out) and green (in).
Monitor → Network: ping counts under the Terminal. Ping and raw sockets carry no cgroup of their own, so ping run in the Terminal showed as a separate, empty app; such sockets now take their process's cgroup and appear under the app that ran them.
Monitor → Network: a click on the empty space under the list clears the selection.
Two failed theme switches in a row could leave the session without a theme. After a theme was refused, the server still took it as the current one, so a second refused switch fell back to it. Now the last theme that loaded stays the fallback.
Apps whose launcher file has a space in its name didn't appear in Apps. A package may name its .desktop file freely (the LordOS Imager's is LordOS Imager.desktop), but the launcher skipped any name with a space or another unusual character. Such a name now gets an id with those characters turned into -, and the app is listed and launched from its real file. Also, an app installed in the same second the list was last read now shows up (the folders' times are compared in nanoseconds).
A see-through line around the Terminal. The Terminal's window has a transparent background, so its 1-pixel border and the line under its title bar let what was behind the window show through (a colored line when it was over another window). Both are now drawn opaque for transparent apps, in Lord Flow and Lord Classic.
The login screen no longer stays running behind your session. It was a whole display server kept in memory after sign-in (about 53 MB of its own, 78 MB counting shared pages, measured in a VMware VM). It now closes 10 seconds after a session takes the screen and starts again in a few milliseconds when you lock, switch user or log out; the whole system went from 603 to 548 MB in use. When you lock, the screen goes dark first and only then is the login screen started, so the unlocked desktop is never left visible meanwhile. Also fixed: asking for the login screen twice on a lock (the monitor handed over a second time), and its mode coming out empty when a request was retried.
On virtual cards that don't wait for the screen's refresh, the desktop drew hundreds of frames a second. The VMware graphics driver (vmwgfx) completes each page flip at once, so the compositor and every app followed it at 500–580 frames a second on a 60 Hz display, using CPU for frames nobody sees. LordOS now notices flips that complete within an eighth of a refresh, again and again, and paces frames to the display's refresh on a fixed grid (59.8 frames a second at 60 Hz measured, p99 18.4 ms); real graphics cards are unaffected. The same grid also paces sessions without a monitor, so waiting in whole milliseconds no longer turns 60 frames a second into 57.
The package now depends on libwayland-egl1 when the Test Bench is built with its 3D view, so lordos-testbench starts on a system that didn't have it.
Remote desktop video came in blocks for the first minutes, and had no sound. The browser's bandwidth estimate was a fixed ceiling, so a new connection stayed near 3 Mbit/s for about three minutes; it now reaches the top in about 10 s on a local network and still slows down on congestion. Software H.264 keeps its deblocking filter. Drawing without a GPU (a remote-only session, a virtual machine) is faster with the same pixels: the backdrop blur 2.5×, rounded rectangles 2×, and canvas.c builds at -O3. The video now follows the browser screen's refresh rate (60, 120, 144 Hz…) instead of a fixed 30: a video window under blurred windows went from 18 to 35 frames a second on a virtual machine without a GPU. Heavy frames paint on several threads (up to 8, only while needed): a 1080p session went from 45 to 55–58 frames a second.
The keyring box couldn't be answered when several apps asked at once: every new request wiped the field and Cancel brought it back for the next one. One answer now goes to all of them, and a key listener that fails no longer keeps the key from the others. The page starts muted, as browsers require, and its sound button hides in the top bar: the first click or key in the session now turns the sound on.
Files → This computer shows /proc, /sys, /dev and /run with a lock and says why it doesn't open them, instead of "outside your home folder".
Restart… and Shut Down… in a session seen only through the remote desktop showed the countdown and then did nothing: only the session on the monitor can ask for them. They are now offered only there.
The Store now follows apt's priorities (/etc/apt/preferences.d), choosing the same versions as apt. On the Raspberry Pi image, "Update all" could take Raspberry Pi's builds of Chromium, BlueZ and other Debian packages instead of Debian's; it no longer does, and Raspberry Pi's kernel packages stay blocked as the image intends.
LordOS Imager offered 0.8.3 as the newest Raspberry Pi image. It only accepted release tags with three numbers, so it skipped 0.8.4.1; point releases (v0.8.4.1-beta) are now listed and downloaded, in LordOS and in the desktop app, and the desktop app's update check reads them too.
A monitor plugged in after boot now shows the login screen. The login screen never listened for the kernel's display events, so a board booted without HDMI (a Raspberry Pi 5) stayed without video until it was restarted. It now follows them like a session does, without the system bus.
The Store's package engine could not download packages with a + in their name (kms++-utils, libkms++0) from lordos.org: the CDN reads a bare + as a space and answered 404. It now sends %2B, as apt does, so Settings → Board firmware can install the bootloader tools from the LordOS repository alone.

Known issues and limitations

Remote desktop: black corners on a window being dragged. While a window is dragged, the frames the remote desktop sends can show its rounded corners black; the monitor itself shows them right (checked on VM 116 against the display output). Being looked at.
llama.cpp on a GPU is not tested on real hardware yet. Its Vulkan backend is meant for AMD (Mesa RADV), NVIDIA (the NVIDIA driver or NVK) and Intel GPUs and falls back to the CPU without one; only the CPU path and the backend loading (software Vulkan) were checked.
Legacy BIOS: a black rectangle between the boot menu and the splash. The menu itself shows normally; when its 5 s run out (or Enter is pressed), GRUB loads the kernel and the initrd (about 100 MB) from the disc and shows its terminal area, painted black, inside the theme's background until the kernel starts: a few seconds on BIOS, which reads the disc slowly, and barely visible on UEFI. Seen on QEMU with SeaBIOS; 0.8.4's ISO does the same. Small test images with the same GRUB, theme and grub.cfg but no 900 MB system image show the menu and no rectangle; a background image set in each entry and a hidden countdown widget in the theme did not change it.
Searching "displays" in the search panel opens the Help article on touchpads and touch screens before Settings → Displays.
Settings → Displays: in the arrangement, the name of a small display is cut without an ellipsis.

Upgrading

From 0.8.4.1 or 0.8.4 (and 0.8.3 to 0.8.1): Store → Updates shows "LordOS 0.8.5 is available" with these notes; Update installs it and a restart finishes it. sudo apt update && sudo apt upgrade does the same. No migration runs (ls /var/lib/lordos/migrations is unchanged from 0.8.4); your settings are kept. Tested before the release with the same package built as 0.8.5~rc2: a VMware machine on 0.8.4.1 and a Raspberry Pi 5 on 0.8.4, both with apt, then a restart.
The Store's new Artificial Intelligence and Commercial pages add a maker's repository only when you install one of its apps, and remove it when you remove the app.

Downloads

File	What it is
`lordos-live-0.8.5-amd64.iso`	Live and installable image for 64-bit PCs (UEFI and BIOS). Write it to a USB stick as is; Secure Boot off.
`lordos-0.8.5-rpi5-arm64.img.xz`	Image for the Raspberry Pi 5, for the LordOS Imager (below) or Raspberry Pi Imager ("Use custom"), an SD card or an NVMe drive.
`lordos_0.8.5_amd64.deb`	The LordOS package for an existing Debian 13 on a PC (installed by `install.sh`, or with `apt install ./…`).
`lordos_0.8.5_arm64.deb`	The same package for Debian 13 on arm64.
`lordos_imager_0.8.5_universal.dmg`	LordOS Imager for Mac (both processor families, signed and notarized): writes LordOS to an SD card or a USB stick and prepares the Raspberry Pi 5's first boot.
`lordos_imager_0.8.5_x64_setup.exe`	LordOS Imager for Windows (64-bit installer; not code-signed yet, so the system asks before running it).
`lordos_imager_0.8.5_amd64.deb`	LordOS Imager for Linux (Debian 13 and similar, amd64; needs udisks2).
`install.sh`	The one-line installer for Debian 13: `curl -fsSL https://lordos.org/install.sh \| sh`. It checks the signature before installing.
`SHA256SUMS`	The SHA-256 of every file in this release.
`SHA256SUMS.sig`	The Ed25519 signature of `SHA256SUMS` with the LordOS release key (base64).
`lordos_0.8.5_<arch>.spdx.json`	Software bill of materials (SPDX 2.3) for each package: what it bundles and the Debian packages it depends on.

Verifying the downloads

The LordOS release public key is lordos-release.pub.pem (in the repository, or at https://lordos.org/lordos-release.pub.pem). Its fingerprint, the SHA-256 of the DER public key, is:

c7155b8e6bbbb180f907381994d06af76d333016cd6f3facf67cadd053ea108e

With OpenSSL 3, in the folder with the downloads:

openssl pkey -pubin -in lordos-release.pub.pem -outform DER | sha256sum   # must match the fingerprint
base64 -d SHA256SUMS.sig > SHA256SUMS.sig.bin
openssl pkeyutl -verify -pubin -inkey lordos-release.pub.pem -rawin -in SHA256SUMS -sigfile SHA256SUMS.sig.bin
sha256sum -c --ignore-missing SHA256SUMS

"Signature Verified Successfully" and "OK" for each downloaded file mean the files are the ones we published. Details: docs/SIGNING.md.

Navigation Menu

Repository navigation

LordOS 0.8.5-beta

Choose a tag to compare

Sorry, something went wrong.