Components and security

Your servers run more than the panel and the agent: a web server, a mail server, PHP in twelve series, an FTP server, a spam filter, a kernel. Every one of those gets security updates from somebody — Canonical, a vendor, or CoreCP itself — and the question an administrator would like to ask every day is: is there a known vulnerability in something I run, and is the fix out yet?

This page answers it. Open Servers → Components & security.

Only administrators see this. Resellers and end customers never see what software a server runs, let alone which holes it has.

What you read at the top

Six tiles, in the order you want to know them:

• Open findings — everything the watch does not yet see resolved.
• Critical — findings you have to act on today.
• Exploited in the wild — vulnerabilities on the American CISA's list of "known exploited". That is the heaviest category: somebody may already be inside.
• Fix late — an Ubuntu component for which Canonical has not delivered the fix within the deadline the platform keeps.
• End of support — series that end within ninety days, or already have.
• Servers affected — how many machines in your fleet have an open finding.

An amber bar above the tiles means the build server could not reach every feed this morning and used an earlier day's answer for it. That is not an error, but it is worth knowing that part of what you see is yesterday's. The bottom of the page lists every feed and whether it was fresh.

The register

The table is the register: every component the platform ships, with the class that says who keeps it up to date.

The most serious open finding sits at the top. Filter by class or search for a name or package; click a row to open the component.

What a finding says

The side panel shows the component's facts — which series the platform follows, where it comes from, when support ends, which feeds are read about it — and under them the findings as cards. Every card says five things:

1. How serious it is: critical, high, medium, low. Critical is a vulnerability that is being exploited, one the feed itself calls critical, or a fix that is late.
2. What kind of news it is: a security finding, a new release, a new major version to decide about, a series that is ending.
3. Which servers it touches — only machines that really run the vulnerable version, not "everything the package is installed on".
4. Whether a fix exists, and which version it is.
5. Which feed reported it, with a link to read more.

A finding the watch no longer sees — the fix is installed, the series is gone — is marked resolved. Also show resolved reads a component's history back.

What happens without you doing anything

• A critical finding (exploited, or late) sends a message at once: an e-mail to the alert address and a push notification to every device that has notifications on. Once per finding, not again every day.
• Every other finding is a line in your bell, under System.
• On Monday morning a weekly digest lands in your bell: what was found and resolved last week and what is still open. The same summary is at the bottom of this page.
• For a class C component the pipeline builds the fix and tests it on staging; when that succeeds you get the ready to roll out notification. The rollout itself stays your action, through Releases.

Nothing is ever installed from this page. The build server reads the feeds, compares them with what your fleet runs, and reports the difference.

Ready to roll out: what the build pipeline does for you

For a class C component nobody has to wait until you have time. As soon as the source has a new version, the pipeline does the whole run-up in one go:

1. Fetch the source. From Debian's archive, over that archive's signature and the checksums inside it. If the signature or a single file does not match, it stops there — nothing is built out of bytes that do not add up.
2. Build it. In a clean, fresh Ubuntu 26.04 environment with no network, so the package is what the source says and nothing else.
3. Sign it. Every package gets a signature and a bill of materials: which sources went into it and how each one was checked.
4. Put it in edge. That is where every build lands; nothing installs it yet.
5. Test it on staging. Exactly that version is installed on a staging server, and then the component itself is asked whether it still works: ProFTPD has to read its configuration and greet a client, Rspamd has to scan a message. Afterwards the test puts the server back on the version it had.
6. Green: on to beta. Those packages, and nothing else moves with them. You get the ready to roll out notification, with the severity, the deadline and the servers it touches.

Red is the end of the road. If the test fails nothing is promoted: the package stays in edge and you get a notification with the location of the test log, so the version your servers run keeps running until there is a better one.

The last step — rolling out to production — never happens by itself. The pipeline goes as far as beta and no further; production pulls when you start it from Releases.

Rolling out through the patch route

When a component is waiting in beta, the panel shows you — beside that finding, in the component's side panel — the button Roll out through the patch route. It is the only button on this page that does anything, and it does exactly one thing: it asks the servers you tick to install the version their own channel already offers.

What you see before you press it: which version, in which channel, and which servers. You can try it first — every server then says what it would install and installs nothing. After that you get one line per server: what moved, or that it was already current, or why it refused. Fifteen servers and one refusal is fourteen servers done and one line saying which one is not — not a red bar that hides the other fourteen.

Nothing goes to production this way. Putting a package into another channel is a person's act on the build server; this button cannot do it, and that is not a promise but how it is built.

What the server itself checks

A component we build ourselves is called the same as Ubuntu's package — proftpd-core stays proftpd-core. The server settles that in two ways:

• It picks ours. Not by version number (a higher number from Ubuntu would quietly take you off our patch), but by the channel the package came from.
• It checks the signature. For every package that comes from our channel the signed parts list is verified and the bytes on disk are held against it before anything is unpacked. If one byte is wrong nothing is installed, the server stays on the version it had, and the refusal lands in the log the panel reads. A package without a signature is not an exception but a refusal.

Packages from Ubuntu itself — including when you use our mirror — keep arriving through the nightly security updates.

Rolling back

If a new version turns out badly, you can go back. The previous version stays in the channel (the current one plus three older), and a rollback puts it back and holds it there until you want to move on. Ask for a version that is no longer there and the server says so, with the list of what it does have — you never get a server that quietly stops updating. Going back to Ubuntu's own build is allowed too: "our patch is the problem" is a valid answer.

From the terminal

You build from the machine where you run the other release tools (the pipeline itself works on the build server):

scripts/component-build list                    # what the pipeline can build
scripts/component-build proftpd --dry-run       # what a run would do
scripts/component-build proftpd --severity critical --cve CVE-2026-1234

On the build server, where the watch runs:

component-watch validate               # is the register valid?
component-watch sync --dry-run         # look, print, write nothing
component-watch show                   # the latest report
systemctl list-timers component-watch.timer

On the panel server:

corecp-panel components list           # the register with its open findings
corecp-panel components findings --component proftpd
corecp-panel components digest --force # write the weekly digest now

The register itself is infra/components/components.yaml in the source tree; docs/components.md describes how a component is added and how the feeds are read.