Account

Register a name. Hand over the URL.

An account signs in with an issuer, registers a label, and publishes an encrypted build document. The installer fetches that URL. This page describes the portal, which is where you will do it.

The portal and the API are live.

The portal is not open yet. Its address is build.blunix.io.

Blubie, the Blunix cat, sits beside a small brass key lying at its paws.
For a label such as ada, the installer URL is https://ada.blnx.io/

Sign in

People use an issuer. The platform is a relying party. It does not run an OAuth server, and it does not keep a password.

  1. After Dark Systems SSO

    Our issuer, at adsas.id, and the only one today. The portal button says "Sign in with After Dark Systems SSO". It is OpenID Connect: authorization code with PKCE (S256), plus state and nonce. The scopes are openid email profile. The API checks the signed ID token against the issuer's keys, then sets a session cookie. The cookie is HttpOnly, Secure, and SameSite=Lax, and it lasts 12 hours. Signing out deletes the session. The client id and the issuer URL are public settings. The client secret is a Worker secret. It is not in this site or in the source.

  2. Google, designed for later

    OpenID Connect at https://accounts.google.com. Authorization code with PKCE. The audience has to be our client id, once that client exists.

  3. GitHub, designed for later

    GitHub user sign-in uses GitHub's OAuth 2.0 authorization-code endpoints. The same rules: allowlisted issuer, live expiry, matching audience, algorithm allowlist. none is rejected.

A token from any other issuer fails closed. Google and GitHub are not built. Only the portal's sign-in link starts a login.

The label

One account can hold many labels. Each label is one installer URL and one current ciphertext.

Publish

The browser composes the node document, generates the key, encrypts, and uploads ciphertext. The key stays in the browser and on the install card you save.

  1. The document is the build

    The machine hostname, the disk layout, the network (DHCP, or a static address, gateway, and DNS), the access profile, and the update channel, which is stable. The same schema the image accepts. Unknown fields are refused. A field named like key material is refused. A shell script is refused. The check happens before encrypt.

  2. A generated key, age passphrase mode

    You do not choose the key. The browser draws 100 bits from its CSPRNG and writes them as 20 characters in four groups of five. It encrypts with the age specification, stretched with scrypt, the way age defines it. There is no second cipher. The browser uses typage, served from the portal itself. Debian age decrypts on the machine.

  3. The server stores ciphertext

    The key is not uploaded, not hashed, not stored, and not logged. The install card is shown once, with a text file and an offline bundle to download. A lost key means that version is gone. Publish again for a new one. The account can see the size, the time, and the sha256 of the ciphertext. It cannot read the document back.

  4. Hand the URL to the installer

    The machine fetches https://ada.blnx.io/ over TLS, asks for the key with echo off, and decrypts locally. The sequence on the box is the install page.

Publishing again changes the file the next install fetches from the latest name. Taking a later document on a machine that is already installed is the service, which is designed, not built. A new image is a new release on the log.

What we keep

Only what the portal needs to work. Never your build key, your document in the clear, or a password.