Ondřej Surý and the work that keeps the internet running

At 13:38 UTC on 21 October 2026, Debian recorded the acceptance of a PHP source package into its stable security archive. The package was php8.4 8.4.27-1~deb13u1. The notice listed two critical security defects, the Debian PHP Maintainers team and the name of the person who signed the upload, Ondřej Surý. The message had the familiar appearance of archive traffic, down to the checksums and file sizes. For an administrator responsible for an affected server, it marked a concrete change. An upstream fix had reached the machinery that builds and distributes the software their organisation runs.

The name on the Debian upload

Surý is a Czech software engineer with two jobs that rarely appear together in the public imagination. He has worked on PHP packaging for Debian since the PHP 5 era, according to his repository site. At Internet Systems Consortium, he is director of DNS engineering and leads the BIND 9 engineering team alongside its quality assurance group. The IETF Datatracker also lists him as a chair of the DNS Operations working group and records several technical documents he wrote or co-wrote. Those three lines of work put him at the points where a security fix becomes an update, a protocol becomes software and software written by different organisations has to work together.

The Radio Prague International interview that drew attention to him was framed around the man who had saved the internet. Surý gave Ian Willoughby a less theatrical account. His job was to prepare the packages that other people could install. He recalled spending a couple of hours on the work, followed by time to compile the software. He was pleased that people who used his packages had a way to update. That account identifies the intervention. The PHP project issued the repaired source, and maintainers including Surý put it into forms that worked through established installation channels. The difference determines who to credit and where to look for evidence that a given machine was covered.

The Debian record is unusually useful because it gives that division of labour a documentary form. Its maintainer field names a team. Its changed-by field names Surý. Its changelog identifies the new upstream version and names the two vulnerabilities. The archive notice identifies the destination as the security suite for Debian trixie. Each field answers a different question. The PHP release explains what the development team published. The Debian record identifies an upload for a specific distribution suite. A host’s package information and runtime checks would answer the remaining question, whether that host was actually running a corrected build.

Take a hypothetical hosting business that runs dozens of unrelated customers’ websites. Its engineers have learned of the PHP defect while checking mail before a maintenance shift. They could theoretically compile the corrected source on their own. In practice, they already have systems that install distribution packages, account for the dependencies and detect service failures. Those systems rely on a maintainer producing a compatible package and putting it in the repository they use. The package changes what the team can do within its normal operating procedure. It turns a decision about rebuilding software into a decision about installing a known update, testing the services and managing deployment across the fleet.

There is a danger in reading too much into one archive timestamp. It records source acceptance, a particular event in the distribution process. It does not document when a binary became available to every architecture, how quickly a mirror served it, or when a customer restarted a process. The record is valuable because its claim is narrow. Every subsequent event can have its own timestamp and evidence. Treating source acceptance as a substitute for those events erases the part of the response that belongs to build systems, image publishers, hosting providers and the people on call.

Surý’s own repository describes the PHP packaging as work he does mostly in his free time. DDEV, whose development images depend on his work, reported that his fixed AMD64 packages reached back through branches that upstream PHP had ceased to support, as far as PHP 5.6. The scale of that version range is part of the story, with architecture and repository qualifications intact. A developer using a corrected legacy runtime could have received the fix through a dependency of a tool they knew by an entirely different name. A server operator following Debian’s security suite would have had a separate update route. Surý’s contribution is visible on both routes, but they are distinct publication arrangements.

The drama of the interview lies in that disparity between the work and its consequences. Someone who spends enough time with packages learns to read a changelog, judge what changed, adjust a build where necessary and recognise a result that is ready to publish. To a person watching from outside, the same few hours can look like improvisation under threat. The preparation is what makes the emergency look routine. It accumulates while there is no audience, when people are maintaining a recipe that will need to work again and accepting responsibility for problems they did not create.

That is a reason for IT professionals to recognise Surý beyond the October story. A web developer might recognise the PPA without recognising its maintainer. A network engineer may know BIND and have no reason to investigate a PHP archive. An engineer designing DNS software may encounter his name on an RFC that has nothing to do with either distribution. The overlap gives a fuller picture of maintenance as a profession. It involves holding a commitment across releases, keeping a connection between organisations usable and making sure other people’s systems can do something with the work.

Two bugs at the edge of a web request

PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. PHP’s public advisory describes both as critical vulnerabilities capable of unauthenticated remote code execution. The first involves a failure path in which PHP can run out of memory while internal request data is only partly initialised. Later cleanup may handle that data as if setup had finished. The second involves internal state that can remain reachable after the memory backing it has been freed. The PHP team pointed to a demonstrated pre-application attack against Apache’s mod_php configuration and advised updating web-serving installations across several interfaces, including PHP-FPM.

The word cleanup does an unusual amount of work here. A runtime expects to create temporary objects while processing incoming data and release them when it finishes. A failure can interrupt creation halfway through. Cleanup has to know which allocations exist, which objects were fully initialised and which fields can be read safely. If the implementation uses the same assumptions after an interrupted setup as it does after successful setup, the error handler can become part of the vulnerability. The visible request can look disposable. Its execution path still reaches memory operations inside the server-side process.

Stale state presents a different lifetime problem. Think of an internal pointer that is valid only while a request’s temporary storage is alive. When that storage goes away, any surviving pointer must cease to be a means of accessing it. The runtime may later reuse the memory for a different purpose. An operation that follows the stale pointer then deals with content or an object whose meaning has changed. A use-after-free is a violation of ownership across time. The attacker is interested in that gap because input and timing can influence what happens around it. The exact path from memory misuse to code execution is a property of the implementation and deployment, which is why the advisories distinguish conditions and tested interfaces.

In a web stack, application developers often think of authentication as a checkpoint at the entrance to their code. A request reaches a routing layer, then an authentication middleware decides whether to proceed. The runtime may already have received and interpreted parts of the request before that middleware runs. A demonstrated exploit that fires before the application starts therefore goes around the point where the application would normally make its decision. An authenticated page can sit behind unauthenticated runtime processing. That detail explains why familiarity with application permissions is insufficient when a defect lives in the layer serving the application.

Remote code execution describes the attacker’s ability to cause code to execute through network interaction. It leaves a separate question about the authority of the affected process. A PHP worker running under a dedicated unprivileged account normally has the permissions that account and its environment give it. Those permissions may include reading application configuration, accessing service credentials or writing to a directory used by the site. Additional containment can change the result, as can weak isolation or credentials that grant wider access. Calling every successful exploit a direct route to root would hide the work of evaluating the environment. Treating unprivileged code execution as minor would make the opposite mistake.

The PHP notice named fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its mailing-list announcement for PHP 8.5.12 was sent on 21 October and encouraged immediate upgrading. The consolidated PHP 8 changelog places the same release under 22 October. Dates in a release announcement and in a version changelog can appear different even while both documents identify the same release. For the incident timeline, the dated mail announcement and the Debian acceptance notice give two explicit events on the 21st. The changelog records the corrections within PHP’s release history.

The hard part before the release

The PHP Foundation’s account begins much earlier than the October uploads. In 2024, a core developer working through an issue from a Quarkslab audit found signs of the out-of-memory problem eventually associated with CVE-2026-109618. The audit had been arranged with OSTIF and funded by the Sovereign Tech Agency. The Foundation says that a possible exploit was theorised at the time without a concrete vector, while other findings had clearer impact. The early evidence was sufficient to raise concern and insufficient to settle the remediation trade-off. That period belongs in the story because it shows how much of the security work happened before the public deadline existed.

The Foundation describes several approaches under consideration, each with drawbacks. A change that forced extension authors to adjust their code would impose a coordination problem across independently maintained projects. An approach that made new forms of denial of service possible could replace one exposure with another. A change to core error handling could break compatibility even for programs with no unusual security requirements. The placement of a defect determines the cost of changing it. This one touched memory management and error handling, machinery that sits beneath a large body of code. The Foundation characterised the delay as a structural failure involving its decision process and limited engineering capacity.

The weight of the evidence changed in August 2026. The Foundation attributes the first report of unconditional remote code execution with the same root cause to a Calif researcher on 11 August, and describes related work from OpenAI and Wiz. Its account distinguishes between a suspected route to exploitation and a demonstrated way of reaching the vulnerable state. A reproduction gave the security team something concrete to reason against. It also changed the priority relative to other open work. The fact that the defect had a history reaching back to 2024 says little by itself about the experience of the distribution maintainers asked to act near the release date.

There are two distinct forms of specialised judgment here. Upstream engineers had to reason about a change inside PHP itself, with effects that could reach third-party extensions and supported operating systems. Downstream maintainers had to turn the result into deployable updates and work within their own build, compatibility and publication rules. The PHP2Shell response needed both kinds of knowledge. Credit given to Surý for the second kind leaves room for the years of upstream work and for the people who made the problem reproducible. It also explains why a maintainer could recall a few intense hours while the PHP Foundation described a much longer effort.

The PHP2Shell response in the public record

The records cover separate steps. In particular, the Debian upload establishes a source package’s acceptance and the DDEV account describes a downstream dependency and release. Evidence of an installed, running update belongs to the operator of the affected system.

Radio Prague’s framing invites the question of what happened because the packages arrived quickly. The available records support a narrower and stronger answer than any global estimate. Users of the affected packages had a route to install the correction through their existing update process. The public material reviewed here does not enumerate which customers were attacked, which attacks were prevented or the share of global PHP installations that used the packages. One can credit the people who shortened the available response path without inventing a count of servers saved.

The job hidden in a package name

A package maintainer works on the fit between a project and the operating system where it will run. In Debian’s acceptance record, the upstream tarball is listed separately from the Debian archive containing distribution-specific material. The source package descriptor and the build information are listed as separate files too. A distribution package has an identity and a release history of its own. Those additional files are part of how an archive and the people using it can tell which source they received, what Debian-specific changes accompanied it and which upload those pieces belonged to.

The significance of a package is easiest to see during the second installation. A first installation can be made to work by assembling files and changing settings by hand. At update time, the system needs to know which files it owns, what has changed and which decisions it can safely make on behalf of the administrator. Repeatable ownership of the installed software is what gives a package its operational weight. The maintainer has to think about the machine already running last week’s build and the new one that will be provisioned tomorrow, because both are legitimate customers of the same archive.

PHP packaging also serves people who use very different pieces of PHP. A command-line job, an Apache installation and a PHP-FPM service can all be relevant to an estate without sharing one execution path. Extensions carry their own dependencies. Configuration may vary by runtime interface or version. Surý’s project explicitly advertises co-installable branches, a practical answer for teams serving applications at different stages of compatibility. Co-installability increases the number of states worth considering. It is useful precisely because a migration can proceed one application at a time, and that same freedom means a host can retain an old runtime long after somebody assumes the move is complete.

A source patch may be short. Its packaging still has to respect how applications meet the runtime. To see the trade-off, imagine a site that uses a PHP database extension and relies on separate settings for scheduled tasks and web workers. The repair should preserve those expected connections while changing the vulnerable behaviour. A package that builds successfully but leaves an extension unavailable would carry a different operational failure into the update window. A package that updates one installation interface while the site runs another can leave the original problem intact. The update has to survive contact with the installations the maintainer has promised to serve.

The archive entry contains an example of how much can be recovered after the fact when the work is well recorded. The upstream version is explicit. The distribution revision is explicit. Two CVE identifiers are named. Checksums bind the entry to listed artifacts, and the upload is attributed to Surý under the PHP maintenance team. Someone reconstructing the incident later can distinguish this item from an upload into unstable or a build for another repository. A good change record lets a stranger reason about the release. It is a modest-looking form of incident documentation that often outlasts contemporary reporting.

The file name also restrains what a reviewer may infer. The version includes Debian packaging information, and the suite identifies the destination. Surý’s separately operated PHP repositories share ancestry with his Debian work, as he explains on the project site, while they have their own publishing channels. If a report gives only the upstream version, it omits evidence that distinguishes those channels. If it gives only the repository operator’s name, it omits evidence about the package and suite. Precision is possible because the supply chain leaves records at more than one level.

Three archives and three promises

Surý’s public packaging site points to an Ubuntu PPA and a separate package archive for Debian. The official Debian upload is a third channel in the story. A shared maintainer does not collapse these channels into one archive. Each has its own publication mechanism, scope and trust relationship. A reader may know all three as places where work by Surý appears. A computer must make a specific decision about where it gets the software, which revision is available to it and which signing credentials authenticate the metadata it receives. Those decisions have consequences that survive an emergency and persist across every subsequent upgrade.

In Debian, the first record to check in this incident is the acceptance of the PHP 8.4 source package into trixie security. Its distribution field and package revision describe exactly that upload. Surý’s project site explains the relationship between his official packaging and the third-party builds. An administrator using his Debian archive may see familiar package names and related packaging work. The administrator is nevertheless trusting a different publication channel and should follow its records for the version installed on that host. The version that fixes a vulnerability is a statement about a particular release channel, especially when two repositories use the same upstream code and each adds a distinct packaging revision.

The Ubuntu PPA illustrates why people make this choice in the first place. Application teams sometimes need a runtime branch the operating system does not supply in its default archive, or they may need several branches on one machine. Surý’s packaging site describes both co-installability and the Ubuntu channel. The archive lowers the amount of integration work required for that use case. The trade is that the operators take on a dependency outside the standard distribution security route. Whether they can carry that dependency is an organisational question as much as a technical one. Someone has to know why it exists, which hosts use it and who is expected to follow security notices for it.

APT’s archive authentication documentation makes the distinction concrete. It describes verification of signed Release metadata, with checksums linking archive metadata to package files. The package can be traced through that authenticated chain. Signature verification tells a host which archive it is trusting. The administrator still decides whether the archive’s maintainers, signing arrangements, availability and update practices are suitable. If a business discovers during a critical incident that most of its fleet depends on a source somebody added years ago, signature validation is working and its inventory is failing. Those two facts can coexist on the same well-configured machine.

Package origin can also be obscured by the ordinary language people use on an operations call. Someone says they run Debian PHP. They may mean PHP on Debian, the stock package from Debian, or a PHP package taken from a separate archive that targets Debian. Those descriptions sound close in a conversation and diverge when the team needs to identify a corrected build. Name the operating system, the package origin and the running interface separately. Doing so turns a loose description into evidence that another engineer can verify without already knowing the history of the machine.

The harder policy decision lies ahead of the incident. If an organisation installs a third-party archive for a version it needs, the dependency may remain after the project that justified it has been retired. The extra archive can still influence package selection. A later engineer may choose an unfamiliar version from it without seeing the original reason for adding it. The remedy is a short local record explaining who owns the decision and which software relies on it. The inventory should preserve the reason for an exception, because an unexplained exception is almost impossible to reassess intelligently once the original team has dispersed.

Surý’s own site gives bug reports a separate public channel and explains why mail is a poor queue for his repository issues. That may seem like administrative detail beside a security story. It defines where an operator’s evidence is likely to be seen and retained. A reproducible report includes the distribution, package version, architecture, configuration needed to reproduce the issue and the point at which behaviour diverges. Depositing that information where other people can find it makes the exchange useful to people beyond the reporter and the maintainer. In a volunteer-run publication channel, the organisation of attention is part of the maintenance work.

An old PHP branch and a new security fix

The PHP project publishes its own support schedule. A branch goes through active support and a later period restricted to critical security fixes, before reaching end of life under upstream policy. Distribution maintenance and commercial support can follow different schedules. The October release announcement names versions of four upstream PHP branches. DDEV’s October newsletter describes a separate range of fixed AMD64 packages extending back to PHP 5.6. The two records are consistent once one asks which organisation or person supplied the build and what commitment that channel had made.

A backport changes existing source so that a correction made elsewhere can be used on an older branch. The task depends on the age and structure of the branch. If the relevant code is almost identical, the adjustment may be straightforward. If the implementation has changed substantially, the maintainer has to identify the older branch’s equivalent code paths and judge what constitutes the same correction. An older version with a targeted backport can have a fix that its upstream version number would appear to exclude. Debian’s security FAQ explains the distribution’s general preference for targeted fixes in stable and why its advisories need to be read in terms of package revisions.

There is a second problem with version shorthand. Saying that a legacy branch received a fix can be technically accurate and operationally misleading if the audience hears that every deployment on that branch is now protected. A build can be limited to one distribution, release or CPU architecture. A provider may ship a patched image while another provider does not. The original application’s vendor may certify only some of the packages the organisation could install. Coverage is a statement about a build and a delivery route, followed by a deployment decision. The DDEV account attaches a specific architecture to its observation about Surý’s early packages, a detail worth preserving whenever the claim travels.

Imagine an application that still needs an older runtime because the business is halfway through replacing an integration. An urgent backport buys the team time to maintain the service while that work proceeds. It also creates a tempting excuse to defer the replacement again. The value of the backport depends on what the business does with the time. Treating the correction as a bridge gives it an end point. Treating it as indefinite coverage assumes a future package will exist whenever another bug appears, even when the people publishing the existing package have made no such promise.

Debian’s FAQ gives operators a way out of a common false alarm. A scanner may compare a displayed upstream version against a threshold and report an old branch as vulnerable. A distribution may have already repaired the specific defect inside its own revision. The reverse mistake is possible when a scanner sees a modern-looking version but has selected the wrong runtime on the host. The most useful vulnerability result identifies both the advisory and the actual package supplying the live process. It can be reviewed against the relevant archive, and it gives the person responsible for deployment something concrete to verify.

Upstream support, a stable distribution’s policy and a separately maintained legacy archive also differ in the classes of defect they address. A single backported CVE demonstrates a response to that CVE. A support schedule describes a continuing expectation over time. A paid arrangement may specify who is accountable for an answer within a period, depending on the actual terms. One observed security release says very little about the scope of the next release. The error is particularly costly when a team treats availability of an old version as proof that its whole dependency tree is being monitored.

DDEV’s story widens the meaning of a package audience. A user may believe they rely on a local development product and still depend indirectly on the package archive used to build its web server image. The project can publish a corrected image when it has corrected inputs, and the developer can adopt the updated tool through the channel they already use. A dependency can cross an image boundary without appearing in the user’s host package manager. An organisation tracing exposure has to look at both, especially if the same underlying software reaches it through operating system packages, development tools and vendor appliances.

The release inside the image

DDEV’s account identifies an intermediate customer that the story of a single administrator and a PHP package misses. The project consumes PHP packages as inputs to its web server image. Its October newsletter documents the fixed DDEV release, v1.25.5, and names both Surý and the PHP Foundation in explaining the work behind it. The project had to deliver the correction in a form its own users would recognise. From the user’s seat the object being upgraded was DDEV. From the archive maintainer’s seat it was PHP. The patched runtime moved between those views because the downstream project performed a separate release.

The distinction matters whenever a security response involves an image. A maintained tag may change to point to a fresh artifact. An already-running instance continues to have the filesystem and processes with which it was created until something replaces or changes it. An organisation can be up to date at the source repository and behind at deployment. Its registry may have an updated artifact while its orchestrator is still holding the earlier one. A developer testing a branch on a laptop may still have a local copy of the old image. The work is to identify these points and decide which of them needs an action.

A version record should also say where the runtime came from inside the image. If an image build consumes a distribution package, the build record or its published inventory can identify that package and version. If the image compiles upstream source directly, a version and the source provenance matter more than a package revision. A provider that embeds a runtime into an appliance may expose neither detail directly to the end customer and instead issue an advisory for a product update. The relevant unit of deployment changes with the channel. The team answering a customer’s security question still needs a credible account of how its own unit relates to the upstream defect.

The Dutch National Cyber Security Centre’s operational repository provides a view of this problem across products. It gathered information on affected software, detection and mitigation after the PHP2Shell disclosure. Its public tracker separates the broad PHP advisory from the problem of determining what was fixed in specific products. A product list records a collection of status assessments at a time, not the state of all exposed hosts. As maintainers publish and users deploy fixes, the list and the deployed estate can change at different speeds. The lesson for a company reviewing its inventory is to timestamp its evidence and avoid treating someone else’s product classification as a confirmation about an individual system.

For a hypothetical development team, the fastest way to learn how this chain works is to trace one service. A PHP branch appears in local configuration. A tooling release selects an image. An image build selects a package. A package release is associated with a source change. The on-call engineer may need only two of those records in an emergency. The person responsible for designing the maintenance process needs the connection between all four. A useful record allows a future responder to walk from the version they can observe to the advisory they need to answer.

There is an obvious temptation to write the downstream response out of a profile of one person. The picture is cleaner if Surý updates PHP and developers instantly inherit the benefit. The more accurate account gives downstream release teams credit and makes the dependency visible. DDEV’s documentation is valuable because it identifies its suppliers in public. Acknowledging a dependency is operational disclosure as well as gratitude. Customers can see why the corrected release appeared, what class of problem it addressed and which upstream groups were involved. That account offers better evidence than a reassuring sentence announcing that security was handled.

A corrected package and a running server

Imagine the operator of a small hosting company opening a terminal after the PHP2Shell announcement. The update completes, and php -v prints the expected release. There is a good chance that this result answers the question of what will happen the next time someone runs PHP from that terminal. The site, however, might use another PHP binary, an Apache module or a service on another machine. That is why the request path is the starting point for verification. The value of a package from Surý or any other maintainer is realized where a request reaches a process running the corrected code. The terminal cannot tell that story on its own.

PHP’s manual gives operators a vocabulary for the difference. Its php_sapi_name() function reports the interface through which the current program is running. The command line typically reports cli. A request served through FastCGI Process Manager reports fpm-fcgi, and Apache with PHP loaded as a module reports apache2handler. Those names describe the execution context. They are especially useful because Apache can also forward requests to FPM, so an Apache server header alone tells an operator little about where the interpreter lives. On an authorized, restricted diagnostic request, the SAPI and PHP version together say far more than a shell prompt or a public banner. Take the diagnostic endpoint down when the evidence is collected.

Start at the virtual host and follow the route. Nginx documents fastcgi_pass as accepting an address or a Unix socket. An Apache configuration can also send a request to a socket, as the PHP manual illustrates in its instructions for FPM status. From the effective web server configuration, match that destination to the service behind the socket and establish what it runs. Includes, upstream groups and hosting panels can hide a different destination from the one suggested by a default configuration file. For a cluster, the same exercise extends past the load balancer. The frontend hostname is a door number, while the routes behind it determine which processes actually need the update.

Consider a hypothetical host where two tenants use PHP 8.3 and a third uses PHP 8.4. The operator might find separate FPM services for the two branches, with two independently configured pools inside the 8.3 service. FPM documents separate pool settings for the listen address, worker user and process manager. Here pools and versions describe different dimensions. Two pools sharing one updated FPM service may use the same corrected interpreter, yet each pool still needs to be mapped to its site and checked for correct service after activation. A second PHP branch, or a separately launched instance of the same branch, may have an independent package and process lifecycle. Restarting the first service cannot attest to either.

That map makes the advisory actionable. PHP named 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as the first corrected releases of its supported branches on October 21. For a vendor build, match the full package revision to the vendor’s advisory for that distribution release and architecture. A PHP version printed inside a request may omit the downstream revision that distinguishes a fixed build from an older one. Conversely, an installed package list can be immaculate while the site still loads an interpreter from a private directory or runs inside an image. Package ownership of the FPM executable or Apache module, and the identity of the running service that uses it, connect those observations.

On a machine that uses APT, apt-cache policy can show the installed and candidate revisions along with the repositories that offer them. That establishes whether the available candidate is the one the operator expects and helps diagnose holds or selection rules that keep the old build installed. The security advisory or package changelog establishes which revision includes the fixes. A matching pair of CVE identifiers is more useful than an assumption about what a suffix means. For an image, the analogous evidence is the publisher’s advisory and the actual image digest deployed. For a private build, the evidence may be the source revision and build record. Each of those is evidence about an artifact until it is tied to a serving process.

Then comes activation. A package manager replaces files on disk, but a long-lived process may still be executing the old program or using an old loaded module. Wiz Research’s PHP2Shell guidance calls for restarting the relevant PHP services and workers after the update. On a system where PHP runs inside Apache, the Apache process lifecycle matters. If the web server only proxies requests to FPM, renewing the web server alone leaves the FPM runtime untouched. Use the platform’s documented restart or replacement procedure and verify that it loads the new binary or module. Package scripts sometimes do this automatically. A successful package transaction is a reason to check what happened, rather than a record of what serves every request.

There can be an interval between bringing up a new worker and taking the old one out of service. Apache’s documentation explains that a graceful restart allows children to finish their current requests. That behaviour can protect traffic during maintenance, but the operator still has to establish when old workers retired. In a fleet, a controlled rollout can drain or replace one group at a time and test it before moving to the next. The same distinction applies to FPM, where a replacement should be judged by the actual service and its workers. An observation taken as soon as the first new process answers does not cover the last old process. Start times, process identity and serving membership provide complementary evidence.

Platform matters because the object to replace changes. On a systemd host running a separately packaged FPM service, identify and restart the actual unit, which may have a versioned name. On Windows with FastCGI, use the deployment’s documented procedure to recycle the appropriate web worker and ensure the PHP FastCGI executables are renewed. In an orchestrated container deployment, publish or select the corrected application image and replace the old replicas. Restarting a container from its previous image can faithfully reproduce the exposure. Kubernetes documents both rollout status and the use of image digests to identify content. A rollout report has more value when it is paired with evidence of the image the serving replicas actually use.

Fresh PHP processes can still fail to serve useful traffic. The first meaningful test is an ordinary request to a dynamic route through the correct host name and frontend, one that cannot be satisfied entirely by a cache. An authorized local check can help identify each backend if the load balancer otherwise obscures which copy answered. Then check the traffic the service exists to handle. A publishing site might exercise sign-in and a normal upload, while a shop might exercise a test basket and its payment integration in an appropriate environment. The point of these tests is to catch configuration or dependency errors and establish that corrected workers can carry production traffic. They do not require running an exploit against production.

A short diagnostic response can give the running PHP version and SAPI without exposing the full configuration. PHP’s manual warns that the FPM status page exposes request URLs and resource information and should be limited to trusted callers. Keep verification private and gather only what is needed. An operator can compare pool status, the supervisor’s service state and the runtime behind a protected dynamic request. A single request through a load balancer does not establish which runtime every replica uses. Nor does an answer from the usual host cover a different virtual host or a distinct path routed to another service. The right depth of checking comes from the topology rather than the number of times someone refreshes a page.

PHP2Shell also makes normal error behaviour worth testing. In its advisory for CVE-2026-109618, PHP describes a delayed soft memory exhaustion response at a safe point and a hard threshold that terminates the process immediately. An application that used shutdown handling for emergency cleanup or telemetry cannot count on it after the hard threshold is crossed. The relevant tests are ordinary workloads near the service’s expected limits, preferably away from production. Large legitimate uploads and complex form submissions may reveal whether emergency changes to request limits still fit the application. If an operator changed memory or upload settings while waiting for packages, that local decision belongs in the change record alongside the package and restart.

Treat background services separately. A PHP worker that handles a message queue might use the same installed binary as a shell session while retaining code and configuration from before the package update. Restart it under the process supervisor and check that it rejoins the queue properly. Cron jobs that launch a fresh PHP process have a different lifecycle, and need a check of the binary they invoke. Reachability sets priorities. The published PHP2Shell exploits concern HTTP paths and do not make an ordinary CLI task equivalent to an internet-facing interpreter. An inventory that distinguishes those cases helps operators close the urgent exposure first without losing track of old runtimes that have a different maintenance window.

The update also has a boundary in time. It addresses future exploitation through the corrected paths after deployment. A prior compromise remains a separate possibility. The PHP2Shell research site points to irregular multipart traffic, unexpected worker exits and unusually large or malformed PHP session cookies as possible clues, with the explicit caveat that each is inconclusive. The vulnerable activity can take place below the application, so its logs can be incomplete. When the exposure and available evidence justify investigation, preserve relevant logs and telemetry while removing exposure. Compare edge and origin observations with worker errors and unexpected processes, file changes or outbound connections. A missing application error or an unremarkable home page cannot establish that nobody reached the bug.

If an organisation finds evidence of execution or memory disclosure, it has to reason about the worker’s actual access. An interpreter running as an unprivileged account may still read configuration, application credentials or other data in scope. Replacing PHP cannot revoke a token that was copied, erase a persistence mechanism or restore the integrity of a modified application. Containment, evidence collection and recovery belong to incident response, with the scope set by what the affected worker could touch. For the package rollout, the useful record is the advisory and artifact revision, the paths that used it, when the old workers stopped serving and what tests passed. For the investigation, that same record helps establish when the exposure ended.

The clocks of a security response

Once PHP engineers had reproducible evidence and a correction to prepare, the release depended on agreement across organisations. The timetable for coordinated disclosure begins with a practical asymmetry. The project can publish source code and a technical description, but users of Linux distributions or commercial platforms ordinarily deploy artifacts prepared by someone else. When the description becomes public, it gives defenders a way to assess their systems and gives attackers a clearer target. Advance access for vendors is meant to narrow the interval during which the details are known but a practical upgrade is unavailable. It allows time to build for several branches and architectures, test packages and stage announcements. In exchange, vendors are expected to keep unpublished material private. Each additional handoff improves the chance of a timely upgrade and creates another place where the agreement can fail.

The PHP Foundation’s retrospective dates the first public circulation of the identifiers to about 15:00 UTC on October 20. It says the accompanying severity score and release time were wrong and that no technical details leaked in that initial circulation. PHP brought forward its website notice to about 19:30 UTC and moved the release a day earlier, from October 22 to October 21 at 14:00 UTC. The mailing list preserves Jakub Zelenka’s advance announcement separately, a little after 19:33 UTC. It also says the team could release earlier if details appeared publicly or it saw evidence of active exploitation. That qualification matters. The new release time was a decision under changing conditions, rather than a guarantee.

The Foundation explains why it did not release at once. Distributors were still building the update, and a release that made the bugs public immediately would leave some users without an easy upgrade path. The remaining preparation time had concrete value. It gave downstream teams hours to finish work that the engine’s maintainers could not do on their behalf. The decision also carried a cost, since each hour gave others time to follow the circulating information. There was no universal countdown to safety. Upstream could set the disclosure hour, but it could not promise that a specific package mirror, managed host or customer’s production fleet would be ready at that hour.

What appeared later that evening was a different kind of disclosure. The Foundation says Calif mistakenly published a demonstration video around 20:00 UTC, after PHP had issued the advance notice. The video showed a working research proof of concept against several targets and gave away some additional detail. Removing it did not stop copies from circulating. In the Foundation’s account that circulation accelerated the development of other proofs of concept. The Foundation also says mitigation advice it started providing to some critical infrastructure operators around 23:00 UTC may have leaked. That is a qualified statement. A confirmed accidental video publication and possible circulation of privately shared defensive advice should not be compressed into a claim that an identified person distributed the entire attack.

A third event put a corrected artifact into public view. The PHP Foundation says Chainguard, which had received the patch in advance, published images containing the fix at 07:41 UTC on October 21, more than six hours before the coordinated release. A built artifact can convey information even when the underlying advisory is still private. Someone who can compare it with its predecessor can begin investigating what changed, while operators on other distributions may still have nothing supported to install. That is the Foundation’s account of why the timing mattered. It does not identify who first circulated the CVE numbers or prove who learned what from the published images. The events are documented separately, and the distinction is part of the story.

An attacker has a clock of their own. In its October 21 account, Amazon Threat Intelligence says its MadPot honeypots recorded a PHP2Shell exploitation attempt on October 17, before the public discussion of the identifiers. Amazon also reported further attempts before the 14:00 UTC release on October 21 and said it did not know whether those attempts would have worked on real systems. Its account does not explain how the October 17 sender acquired the information. The Foundation separately says the PHP security team inspected proofs of concept that appeared after the leak and identified no functional exploit among those it saw by release time. One account concerns traffic in a particular sensor network, the other what a different team found in material it examined.

For an operator, those records argue for an exposure window grounded in local evidence. Beginning a search exactly when the advisory went public might miss earlier activity. Beginning with a signal from a sensor on another network does not establish an incident in one’s own fleet. The time to preserve records depends on how long a vulnerable process was reachable and on what is available in each layer’s logs. An ingress can reveal a request that an application never got the chance to log. A host can show a worker failure with little detail about the client that caused it. Correlating the two is practical work that neither an advisory nor a detection feed can perform on an operator’s behalf.

Defensive services have yet another clock. A provider can roll out filtering at the edge while customers are still waiting for corrected packages or arranging maintenance. Cloudflare published protections for PHP2Shell, and Wiz warned that such temporary mitigations depend on the provider and the exploitation path. That distinction has operational teeth. A site may also accept traffic directly at its origin, through an old address, or through an internal route beyond the policy’s reach. A filter that catches one recognisable request pattern cannot prove that a second mechanism in the engine is covered. The emergency rule can buy time for a rollout, with normal traffic monitored for regressions. The corrected PHP runtime remains the durable action for the disclosed flaws.

A useful inventory is one that can be acted on before everybody agrees about the details of the exploit. Each entry needs an owner who can say which interpreter receives requests, which distribution or image supplies it and who has authority to change it. The inventory also needs a way to represent unknowns. In a hypothetical company, an old test host with a public DNS record and no current service owner may warrant more immediate work than an internal application with a well known interpreter and a team already staging the corrected release. An inventory that records only website names gives the incident lead no clear way to tell the difference. That is why a useful entry has a route, an artifact and an accountable person.

Responsibility can be divided without being diluted. The PHP team can identify the affected runtime behaviour and ship the source correction. Downstream maintainers can build and publish traceable artifacts for their users. A managed service can replace its workers and tell customers exactly which product tiers or regions it has covered. The application owner can verify which environment the site actually uses, test the deployment and investigate prior exposure where warranted. At each handoff, the recipient needs evidence they can act on. Surý’s work sits at a handoff with unusual reach. It gives an operator a specific artifact to deploy, and it gives the next person in the chain a version that can be compared with what is serving traffic.

An emergency ends at different times for different readers. A researcher may mark October 21 as the day findings became public. A maintainer might mark it as the date their corrected artifacts became available. A site operator can reasonably mark it only after the last affected instance was replaced or removed from service and the traffic path was checked. There may still be an investigation to finish if the system was reachable beforehand. A good record preserves these dates separately, so the next person can tell what is known, which route it applies to and who verified it. That is where a security release stops being a date in an announcement and becomes a change someone can account for.

The packaging talk that explains the engineer

Eleven years before the PHP2Shell release, Surý showed a LinuxDays audience how to open a Debian package and inspect its contents. The example in his slides was Knot DNS version 2.0.1-4 for AMD64. The talk separated the installed payload from the control information and maintainer scripts. It then took the audience through the corresponding source package and pointed to the names and records that described who worked on it. A Czech DNS server provided the specimen for a lesson about distribution maintenance. In the context of Surý’s work that choice makes sense. He helped lead the organisation that developed the software and took part in making it available through the operating system.

His slides also supplied a contemporary list of projects from a Debian portfolio dating to 2000. PHP and its extensions appeared beside DNS software and libraries, BIRD, Cyrus components and work on image formats. He identified team maintenance as the arrangement for most of the items. It would be easy to turn a long project list into a claim about breadth alone. The more interesting detail is how different the software is from the perspective of its users and how similar its packaging obligations are. A routing daemon, a library and a web runtime each need a maintainer who understands the project’s releases and the distribution’s expectations for installing or upgrading them.

The slides showed attendees what they could learn from a source package’s metadata. An architecture field describes where it can build or how its outputs relate to hardware. A build dependency expresses a condition that the builder must satisfy. A changelog and version make a revision visible to people who did not make it. Writing these details down lets another engineer take responsibility for the same artifact. The PHP2Shell archive entry later showed the same style of information under much greater pressure. The fields had names and meanings Debian contributors and their tools already understood. An urgent release passed through a form established for ordinary work.

Surý used his presentation to argue for building in a clean environment. A developer’s machine can have an extra library, a newer tool or a setting left over from earlier work. An accidental dependency can stay hidden for as long as everyone compiles the package on the same machine. A clean build asks whether the package declares what it needs. The distinction is one an administrator can recognise immediately. It is the difference between knowing how to stand up a machine again and knowing that a machine somebody set up once continues to work. A future maintainer inherits the first kind of knowledge through procedures they can test.

ISC’s profile fills in parts of the career the archive records cannot show. It records a bachelor’s degree in psychology and sociology and experience spanning system administration, system programming, software engineering and management. The breadth matters because an engineer with responsibility for a release sees both the implementation and the people waiting for it. There is no need to speculate about what he learned in a particular course or project. The documented work already shows him teaching people how to package, explaining design choices to registry operators and leading teams that maintain an implementation other organisations depend on.

There is another difference between the conference presentation and the later news interview. The conference audience arrived expecting a discussion of packaging and spent time on its details. The radio audience arrived through a story of danger and rescue. Surý’s explanation in the interview returned to the work itself. It was a matter of preparing and building packages, and of caring about whether their users received them in time. His account makes sense alongside the earlier teaching. An emergency compresses a familiar practice into a few conspicuous hours. The conference slides show some of what the listener could not see in those hours.

The Czech registry builds a name server

At the RIPE 63 meeting in Vienna on November 3, 2011, Ľuboš Slovák introduced a DNS server that his colleagues at the Czech registry had built. The presentation was the public unveiling of Knot DNS, then a beta release. One of the people who spoke from the floor was Ondřej Surý. The meeting minutes identify him as a co-developer. When the discussion turned to how a newcomer might earn operators’ confidence, Surý said the team had gathered two months of registry traffic to play back against its software. The announcement and the exchange put two questions side by side. Could the new server keep up with the established alternatives, and could it give operators answers they could trust?

Surý had joined CZ.NIC in 2005 as chief technology officer, according to his biography for the RIPE 64 programme committee. He came in to help build a new registry system, deployed in 2007, and was involved in the introduction of DNSSEC to .CZ in 2008. In 2009 he became head of the association’s newly created research and development department, CZ.NIC Labs. The two jobs show why a registry was a plausible home for a DNS research group. The registry system kept track of registrations and their details, while the DNS infrastructure made the resulting delegations available to the internet. Running both gave the organisation an immediate way to put experimental infrastructure software in contact with the work it was meant to do.

The dates tell a more precise story than the shorthand that Knot DNS began in 2011. Slovák’s slides put the start in 2009, with a very small development team. Two people joined the effort in 2010. A small trial release went out in September 2011 and was deployed on a limited scale. In Vienna that November, CZ.NIC was ready to publish the source and invite operators to try it. Surý was the head of research quoted by the registry and a contributor on record in the room. Slovák gave the presentation and later announced the stable release. This was a project with several named participants, backed by an institution that could supply engineering time, test traffic and some of its own domains.

An authoritative name server answers from the records for the zones it has been configured to serve. Suppose a resolver needs to look up a name under .CZ and has no usable answer in its cache. The root servers can direct it to the servers for .CZ. Those servers can in turn tell it which name servers handle the relevant delegated domain. The server responsible for that domain can then supply the requested record, or indicate that it does not exist. A registry’s server therefore has an essential part in finding the answer even when it does not have the final address. It publishes the delegation that lets the resolver take the next step.

The program working on behalf of the application is the recursive resolver. It can follow those referrals, ask several servers in succession and keep a record of what it learns so that subsequent clients can get an answer faster. The same words, name server, often refer to both jobs. Knot DNS took on just the authoritative job, so a deployment could use it to serve the contents of zones without offering clients a general lookup service. CZ.NIC’s separately named Knot Resolver is the project that performs the lookup and caching work. BIND, one of the benchmarks for the 2011 project, includes the ability to perform both jobs. That distinction helps explain what CZ.NIC could leave outside the design of Knot DNS.

The launch announcement framed the available choices from the perspective of a large domain registry. In that setting, CZ.NIC said, BIND and NSD were effectively the two established freely available choices. The scope of the claim matters. Different operators had different requirements, and at the same meeting EURid presented an additional implementation, YADIFA. Surý explained that CZ.NIC was looking for something with the flexibility operators associated with BIND and the speed they expected from NSD. He pointed to registrars as well as registries as possible users. One might publish a national zone with many delegations, while another might serve a large number of customer zones, each relatively small. Both could care about speed and continuous operation for different reasons.

Speed alone would not explain the decision to build a server from scratch. In the announcement, Surý made the case for independent implementations at the root and top level of the DNS. Two machines can back each other up when one loses power, yet both can be susceptible to the same bug if they run the same program. If differently written servers can interpret the same zone and give compatible answers, an implementation defect has fewer opportunities to disable the entire service. That is a different kind of protection from distributing servers across separate networks and locations, a practice recommended in the guidance for operating secondary DNS servers. An operator can arrange for both kinds of independence.

That protection depends on agreement at the protocol boundary. A standard zone transfer lets a secondary server obtain the same zone data from a primary even if the two run different software. A full transfer copies the whole zone. An incremental transfer can send just the differences, which is valuable when the zone is large but only a small number of records have changed. The files and data structures on either side may look entirely different. The two servers still need to agree on what the update means and what to publish. The freedom to write an independent implementation is useful precisely because the operator does not also need a separate kind of DNS for everyone who connects to it.

Slovák’s account of the original design focused on what the server did between receiving a query and emitting a reply. The team tried to make each lookup cheaper and reduce how many lookups it took to assemble an answer. The C program had several threads so that work could proceed in parallel, and the designers avoided locks in much of the code that had to handle that work. The talk described a scheme called read-copy-update. In broad terms, a reader can carry on using a coherent version of the data while an updater prepares a new version for subsequent readers. That matters when a busy server must keep answering questions while the data it is answering from changes.

The related operational feature was reconfiguration while running. Operators could add or remove a zone or change the interfaces on which the service listened without stopping the server outright. For a provider that manages many customer zones, those actions are part of ordinary service, and a restart has consequences for customers whose zones are unrelated to the change. The Vienna slides made this concrete with a small configuration specifying where to listen, which zone file to load and where to send logs. They also distinguished what was present from what was planned. Dynamic DNS updates, which let a client request changes to records over the protocol, were listed as future work even though operators could already reconfigure the running server.

The Vienna talk also showed the limits of treating queries per second as the whole story. CZ.NIC’s launch material reported roughly 200,000 on readily available hardware. The slides specified a four-core Intel Xeon machine, tests on Linux and FreeBSD, and the .CZ zone with DNSSEC denial records. In the ensuing discussion, an audience member asked how much memory the fast data structures required. Slovák said the amount varied with the zone file and gave an example of around four times its size on disk. He attributed the overhead to the lookup design and its data structures. An operator sizing a fleet needed that second number as well as the headline rate, and needed to check both against its own zone data.

Daniel Karrenberg, who had tested NSD, suggested sending identical queries to several implementations and comparing the replies. His old test code was still available, and he offered it to the Knot team. Surý’s reply about the registry traffic showed that the Czech developers were already pursuing comparison against actual queries. A workload assembled from live traffic can include odd requests and combinations that developers would not think to invent. A comparison still takes interpretation. Two replies may differ in the ordering of records without changing their meaning, while a small difference in referral or denial behaviour may send a resolver down a different path. The meeting notes preserve a practical exchange about how to find those differences rather than a simple claim of compatibility.

An attendee also asked what CZ.NIC would do to keep the software going. Surý said the Labs wanted to involve people from outside the organisation and were committed to fixing bugs and helping users deploy it over time. At launch, CZ.NIC had already put the beta to work on some of its own smaller domains, and it planned to introduce it on selected .CZ nodes. The slides still advised against treating the beta as production ready. The distinction is between a registry choosing a few places where it can observe its own experiment and asking outsiders to entrust their production DNS to a public release. The source code and mailing list let those outsiders look at the design, report failures and follow its progress before making that choice.

Slovák announced the first stable Knot DNS release in February 2012. CZ.NIC’s annual report singles out support for serving the root zone, which had been on the work list in Vienna. The same report describes a version 1.1 in the autumn with improvements to speed and incremental transfers, and says Knot DNS was already in use as an authoritative server for .CZ. That sequence separates the initial test on smaller domains from production service for the national domain. It also separates supporting root-zone service in the software from actually serving it for a root operator. Over time, Knot DNS documentation continued to list full and incremental transfers, while describing a broader set of capabilities including automatic signing and management of zones while the server is running.

A later migration shows the different places the same software can occupy. In the last week of April 2021, well after Surý had moved to ISC, CZ.NIC finished switching the system that generated and signed the .CZ zone. A hidden primary prepares the zone and makes it available to the public servers that answer queries. For this job the registry had long used BIND to generate the zone and local scripts to sign it. Technical director Zdeněk Brůna explained that Knot DNS could take over both parts. That change behind the public servers was distinct from the registry’s earlier decision to use Knot DNS at some of its public endpoints.

Brůna’s account of the migration shows what software diversity costs the people who put it into practice. CZ.NIC tested the change first, then moved test domains, its own production domains and other work before switching .CZ. During the transition, servers running NSD took longer than the BIND and Knot servers to accept updates from the new source. The team arranged to temporarily withdraw affected sites from public routing while restarting those instances and checking that they had loaded the new zone. At an isolated site, staff used a resolver to verify that the updated data could still be validated. The registry retained a way back if checks failed. Serving the same data through distinct programs gave the registry options, and exercising those options required operators to know the behaviour of each program.

The team behind BIND 9

When ISC hired Surý in September 2017, it described his job as Director of DNS Development. Its staff directory now calls the position Director of DNS Engineering, and a 2023 profile describes him leading the BIND 9 developers alongside the quality assurance group. He had gone from a registry building an alternative to BIND to the organisation responsible for BIND itself. The change put him in charge of an implementation with years of deployments and with responsibilities on both sides of a DNS lookup. ISC was already working on BIND 9 refactoring in 2017. The scope of his job was to lead an ongoing engineering effort while operators continued to run the software, report its problems and depend on its release schedule.

The Internet Systems Consortium traces its origin to 1994, when Rick Adams, Paul Vixie and Carl Malamud created an independent home for BIND’s development and maintenance. The software had a longer history stretching back to Berkeley. BIND 9 itself reached general availability in September 2000 and substantially rewrote the architecture of the preceding version. The original release announcement points to IPv6, signed DNS zones, improved portability and support for systems with multiple processors. It also introduces views, which let a single server present different DNS data to different sets of clients. The name and the continuity of the project can make the version number look like a straightforward upgrade, but the 2000 announcement records a substantial change in the program beneath it.

For an organisation evaluating an upgrade, what BIND does there matters more than a single description of the software. ISC describes its use to publish the signed DNS root and top-level zones, host many small zones and resolve names for large populations of subscribers. At a company it can provide different answers inside and outside the organisation. A change that seems safe for a provider serving a small set of popular zones might expose a different problem for a service keeping millions of cached records or publishing enormous numbers of separate zones. The range of uses explains why ISC’s developers need detailed bug reports and why the QA team has to decide which combinations of data, options and operating environments are most valuable to reproduce in the lab.

BIND’s institutional memory also resides with people who were working on it before Surý arrived. ISC’s history names Mark Andrews and Evan Hunt as the BIND 9 maintainers during the years when much of the rest of its DNS team was trying to build BIND 10. Andrews was part of the early BIND 9 group, and Hunt joined the core team in 2007. ISC ended its BIND 10 development in 2014 and put its effort back into BIND 9. The attempted successor made the alternative of an entirely new framework a real experience for the institution. The course ISC later took was to retain a running product and replace parts of its architecture in steps that could be tested, released and assessed separately.

The need for that work can be seen in the history of one function. ISC identified query_find as part of the work to simplify the core of BIND, and recorded a McCabe complexity score of 453 before refactoring it. The score counts independent paths through a function and is useful as an indication of how tangled its control flow has become. It does not by itself count bugs. It tells a developer trying to alter one behaviour that there are many ways execution can reach or bypass the new code. The 2017 refactoring also separated parts of the response policy system from the database used to store DNS data, making it easier to reason about the code that implements each job.

Networking offered an example of the pace at which a major replacement could happen. BIND’s original networking code had to work across a long list of operating systems with different interfaces and quirks. Petr Špaček, writing for ISC in 2023, described how BIND 9.16 adopted the libuv library for the part that talks to clients while retaining the original code for talking to other servers. BIND 9.18 extended the new networking approach through the rest of the networking engine where possible. Splitting the project meant one version temporarily used both systems. It also meant the team could ship and observe the first change without having to finish and validate the second half in the same release.

Another replacement concerned where BIND keeps DNS information. ISC’s old red-black tree implementation required locks on access, an arrangement designed when a server had far fewer cores contending for shared data. BIND 9.20 made a QP trie the default database. A trie arranges keys around parts of their names, and changing the database can alter how the server spends processor time and memory while looking records up. ISC kept the old implementation as a configurable fallback in the 9.20 branch. That gave operators a way to respond if the new default exposed a problem in their workload. It also let the developers gather experience with the new structure before the fallback itself could be taken out of the code.

The same staged approach appears in the way users see development. ISC’s history records that it opened its bug database to external users in July 2017, before Surý’s hiring, and moved BIND to public GitLab in February 2018, after he joined. The 2023 profile credits the period of his leadership with regular monthly development snapshots and says the team had produced more than 200 incremental releases across all BIND 9 branches by then. Snapshots give people outside ISC a chance to test work in progress sooner. Maintenance releases serve people whose deployments depend on an established branch. Counting the output of all branches makes sense when a correction often has to reach more than one supported version.

The QA team gives the development work another set of eyes and a different set of responsibilities. ISC’s 2025 development report identifies Michał Kępień as the group’s lead and describes Štěpán Balážik updating and reimplementing system tests, Andoni Duarte working on continuous integration and release engineering, and Nicki Křížek frequently managing releases. It notes Petr Špaček’s performance and protocol work and Michal Nowak’s troubleshooting. A separate profile gives examples of Nowak’s day-to-day work, including investigating failing tests, running stress tests on different operating systems and coordinating over package distribution. These are specific jobs within a shared process, and some work sits across the line between developing the server and establishing that a change can be shipped.

One kind of check exercises a small unit of code and another runs enough of the server to see how those units behave together. In a 2021 interview, Kępień described automated checks on proposed changes that built and tested BIND across several Linux distributions, FreeBSD and Windows where applicable at the time. Some runs used instrumentation to expose bad memory access or timing problems between threads. Others examined code without running it or enforced build and style rules. He counted roughly 70 jobs per revision of a proposed change at the time. Scheduled runs on maintained branches picked up tests that were too slow for every revision. This division reserved quick feedback for work under review and gave the team a recurring chance to spot failures that only longer tests could expose.

Randomized testing brings another kind of evidence. The ISC profile credits the team with expanding QA under Surý to include regular fuzz testing, which exercises parts of the software with many unusual inputs rather than only the examples a developer has written down. For a program that accepts network messages, boundary cases in parsing deserve particular attention. A system test can preserve an exact case that caused a failure in the past, while fuzz testing can find an unexpected variant that the test writer did not anticipate. Kępień said in 2021 that fuzz testing had started to uncover fewer problems in existing code, but still offered protection as new code arrived. Its value, in his account, changed as the code and tests matured.

Performance testing needs a human reading of the results. A comparison ISC published in December 2025 found that BIND 9.20 served most of its authoritative test profiles faster than 9.18, while the root-zone test returned fewer replies per second. In a test with a million zones, the newer branch used 28 percent more memory. ISC traced the increase to the larger pool of locks allocated to each zone to improve scalability, an overhead that became conspicuous when repeated a million times. The development branch subsequently used a shared pool instead. That comparison gives an operator with many small zones a concrete reason to check available memory. It also shows why release staff look beyond averages when they review a performance run.

In a resolver test, the choice of workload changes what the result means in another way. A recursive server starting with a cold cache has to do more work outside itself than one that already knows how to reach popular domains. In a March 2026 comparison, ISC measured both phases, varied how much traffic it sent, and looked at the distribution of reply times as well as memory and processor use. At the heaviest rate it reported substantially fewer timeouts for BIND 9.20 than 9.18 during startup. When both programs had settled into running at that rate, their memory use was approximately the same within the variability of the test. A figure from either moment alone would miss part of the experience of restarting a heavily used service.

At RIPE 91 in October 2025, Surý showed the release checklist to illustrate the work between an approved change and a published version. Before code freeze, QA checked for unresolved test failures on supported platforms and investigated drops in performance. Before tagging, someone verified that changes scheduled to go back to maintained branches had actually made it there and looked for unexpected configuration incompatibilities across versions. Staff prepared notes and checked them against the work in the release. The presentation counted documentation, packages and containers alongside the source. An operator who gets BIND through a system package needs that package to correspond to the source the team has approved, and needs a description of changes that may affect the installation.

Surý’s release slides also show that distribution has its own checks. The people signing the source archives compared them with the tagged revision before applying signatures, and QA verified signatures and checksums as part of preparing publication. Known issues had to be updated, download locations made public and support staff told what versions had shipped. A correction in a development branch and a correction reaching someone running a stable installation are separate events. The work between them is especially visible when several branches or distributions must be updated together. ISC’s published process gives readers a way to understand the interval between a change being accepted and the moment when operators can obtain and verify it.

The public can help the team reproduce behaviour that no test environment duplicates. Kępień pointed to actionable bug reports as particularly valuable when a failure depends on a certain platform, changing network conditions or an operator’s willingness to run a follow-up experiment. The person who runs the server may know when it started to misbehave and what changed just beforehand. The people who maintain it can isolate the responsible behaviour and, where practical, preserve it as a test. That relationship gives the move to an open development process practical meaning. Surý’s job is visible in the new networking code and the pace of releases, but it is also visible in whether the project can turn what an operator observed into a fix that reaches the next supported version.

The work of agreeing on DNS behaviour

The IETF lists Surý as one of three chairs of its active DNS Operations working group, alongside Benno Overeinder and Peter Thomassen. The charter covers deployment guidance and operational practice as well as maintenance and extension of the protocol. Those are different jobs from writing a DNS server. A server team can decide how to lay out its memory or organise a release. A working group considers behaviour that crosses organisational and implementation boundaries, where a decision made by one team will be encountered by clients and servers built by many others.

A protocol document is an agreement expressed in enough detail for separate implementers to work independently. The practical test is whether they reach the same result when they meet. A successful experiment inside one codebase leaves questions open at the boundary. The document has to account for the other side’s response, earlier implementations and conditions in which something is missing or fails. DNS makes this particularly visible because the operators of a client, its resolver, the relevant authority and the network path can all be different. Each organisation may update on its own timetable.

The working group’s charter describes several forms its documents can take. Deployment guidance may belong in a Best Current Practice or Informational RFC. Changes or extensions to the protocol can be advanced on the standards track or published as experimental work. An RFC number identifies a publication, and the document status tells the reader how to use it. The distinction matters when the name of a respected engineer is cited as the authority. The practical authority in a design review comes from the specification that applies, its status and the current operational evidence behind the proposed use.

Four specifications with different jobs

The documents cover different boundaries. SSHFP relates to host keys, EdDSA to signed DNS data, cookies to DNS transactions and catalog zones to configuration shared among servers. Their presence in one engineer’s record reflects the range of DNS work represented by the IETF’s profile.

The group works in public through records including its charter, mailing-list archive and published documents. The benefits resemble those of the Debian acceptance record, but the thing under review is different. The archive tells someone which artifacts entered a publication process. A standards record preserves a decision about shared behaviour. A future engineer can see the state of the document and identify associated work. Operators can contribute a deployment problem before an approach hardens into a requirement. Implementers can find questions they would otherwise rediscover separately while writing their own code.

There is no implication that a working-group chair approves everything under the group’s name or that a document author controls adoption. A chair’s listing is evidence of a role in the group’s work. An authorship line identifies responsibility for a particular document. Deployment has a much larger cast of operators and implementers. Surý’s interest lies in the combination of roles and the boundaries between them. When someone who has packaged software and led an implementation contributes to protocol work, he brings knowledge of what readers will have to do with the specification after it is published. The obligations of those readers remain their own.

DNSSEC and the life of a signing algorithm

When a zone operator signs DNS data, the signature may have to be checked by software the operator has never seen, long after the authoritative server has finished answering the query. A validating resolver starts from a trusted key and can follow a chain of authenticated delegations to the key that vouches for the data it receives. DNSSEC also gives it a way to verify certain claims about names or record types that do not exist. The design makes verification independent of the original exchange. A resolver can validate signed records it got from another source or retained in a cache, provided the necessary evidence remains valid. That independence is the reason a signature algorithm has to work as a common language.

In February 2017, Ondřej Surý of CZ.NIC and Robert Edmonds of Fastly published RFC 8080, which specifies how to use Ed25519 and Ed448 signatures in DNSSEC. The two are forms of the Edwards curve signature scheme known as EdDSA, already specified separately. The RFC makes the connection to DNS concrete. It assigns algorithm number 15 to Ed25519 and number 16 to Ed448, defines what goes in the public key and signature records, and shows worked examples. Those details let a signer and a validator produced by different organisations agree on the bytes. Agreement about the name of a cryptographic primitive is only a starting point when code must parse and verify what arrives in a real packet.

The sizes are unusually easy to state. An Ed25519 public key takes 32 bytes and its signature takes 64. An Ed448 public key takes 57 bytes and its signature takes 114. These lengths cover the key and signature material itself. The enclosing DNS records have other fields. Even so, those numbers matter because signatures travel with signed record sets, and signed answers sometimes include several such sets. On a path with a tight UDP size limit, extra bytes can determine whether the answer fits or needs another exchange over TCP. The wire cost recurs with each answer. A compact signature can reduce that cost, although it cannot guarantee that a complete response will fit.

The RFC specifies how to take the bytes that DNSSEC already defines for signing and process them with the selected EdDSA algorithm. This leaves existing DNS record structures and the chain of trust in place. It also means the integrity claim has a precise boundary. A signature authenticates the relevant record set, which can contain multiple records sharing a name, type, and class. It does not authenticate every field in the enclosing DNS packet, and it provides no confidentiality. A valid signature travels with the data because its usefulness is tied to the signed material and its validity period. The packets carrying it can vary as resolvers and servers communicate.

Four questions arrive after a method is specified. Should an operator use it to sign a zone? Should a resolver use it when validating? Should signing software implement it? Should validating software implement it? The answers can differ because the signer makes a choice that validators inherit. An operator can decide that there is no reason to generate a particular type of signature for a new zone. Validators still meet zones whose operators made a different choice, perhaps years earlier. A recommendation that applies to signing today can therefore coexist with a recommendation to continue validating old or uncommon signatures. Treating the two roles as identical would make a transition much harder to arrange.

Surý and Paul Wouters addressed this gap in RFC 8624, published in June 2019. That document revised the requirements and guidance for DNSSEC algorithms, bringing together considerations for people implementing the protocol and people deploying it. Its implementation table treated Ed25519 as recommended for both signing and validation, while Ed448 was optional for signing and recommended for validation. The text expected a growing role for Ed25519, but attached a condition about available software before treating it as a default for new deployments. Seen from 2019, the uncertainty was real. An algorithm could be standardised and technically attractive while the validators in service were still catching up. The document is historical evidence of that stage of adoption.

RFC 8624 is now obsolete. RFC 9904, published in November 2025 by Wes Hardaker and Warren Kumari, shifted the recommendations into the registries that the Internet Assigned Numbers Authority maintains. A registry entry can now identify an algorithm and separately state the current recommendations for using it and implementing it in each role. The system applies a parallel distinction to the digest algorithms used in delegation records. The registry becomes the place to check when deciding how to treat an algorithm today. RFC 8080 still answers the separate question of how to encode and verify Ed25519 and Ed448 for DNSSEC. Its job was never to freeze the advice for every future deployment.

The registry illustrates why that separation matters. It lists Ed25519 as recommended in all four signing and validation columns. Ed448 is permitted for use and implementation on the signing side and recommended in both validation columns. ECDSA on the P-256 curve with SHA-256, by comparison, is recommended for use and required to implement for both roles. A requirement to support an algorithm supplies a common capability among implementations. It does not oblige each zone to select it. Conversely, the fact that software can use a method is no assurance that every downstream system can check it. The status of a registry entry and the installed capabilities of a particular audience answer different questions.

The difference has a visible consequence when something goes wrong. If a resolver has a valid path to a supported algorithm and the signatures fail to verify, it can treat the data as bogus. Where the signed parent presents delegation records but the resolver supports none of their algorithms, DNSSEC’s rules allow the resolver to treat the delegation as insecure. That can mean the name still resolves while users of that validator get none of the expected DNSSEC assurance. Successful resolution alone cannot prove validation. A test of an algorithm change needs to establish which evidence the resolver could use and whether it treated the answers as authenticated, not merely that the final address appeared.

Key management presents a different problem from choosing an algorithm. A private key is kept on the signing side, while its public counterpart can be published in a DNSKEY record. In a common split, a zone signing key signs the zone’s data, and a key signing key signs the set of public keys. A parent normally publishes a Delegation Signer record, or DS, that identifies a child key through a digest and supports the next step in the chain. The work of protecting a private key and the work of keeping the public chain intact are related. A signer can use a sound algorithm, and every implementation can agree on it, while a stale DS or an expired signature makes the published result unusable.

An algorithm rollover brings all of this together. There are copies of the old public keys and signatures in caches, and the parent’s delegation records may have been published on a different schedule from the child’s updates. A conservative rollover gives the old and new signing paths enough time to coexist. The operator arranges the changes to child signatures and keys, and to the parent’s DS, so a resolver holding a permitted older copy still has a usable path. RFC 6781 describes several rollover patterns and gives special attention to differences between changing an ordinary key and changing the algorithm. The waiting periods do real work. A switch that looks complete on the primary server may be only partly visible elsewhere.

During such a migration, adding signatures under the new algorithm before retiring the old ones can increase answer size, even when the destination algorithm is more compact. An operator is temporarily paying the cost of both paths. It is also possible to have a clean result on an authoritative server used for testing while a secondary is still serving older data. Those conditions make the overlap useful to examine, alongside the desired steady state. A staged rollout is a distinct operating state with its own packet sizes and timing. Testing only at the end tells an operator little about whether clients could validate while the change was in progress.

Surý’s coauthorship on RFC 8080 and RFC 8624 captures two points in a standard’s life. One document made a pair of algorithms usable in DNSSEC by telling implementers exactly how to represent them. The other asked how the installed DNS community should make room for new methods and move away from aging ones. RFC 9904 adds a way for later standards work to revise that advice. The three steps distinguish a specification, a recommendation, and a migration. Each has a different audience and a different clock. They explain why publishing an algorithm number is only the beginning of the work required to make a cryptographic option useful across the public DNS.

The key share behind the headline

The script for the first root KSK ceremony gives Ondřej Surý a number. In the participant list for the ceremony held in Culpeper, Virginia, on June 16, 2010, the Czech engineer appears as Recovery Key Share Holder 2. The planned handover is set out as a transaction with a paper trail. The ceremony administrator calls the holder forward, the holder checks the package identifier and its contents, the receipt gets a time and signature, and a witness initials the entry. IANA’s July 2010 deployment presentation records the enrollment of the recovery holders at that ceremony. Its current roster still dates Surý’s appointment to 2010. The title beside his name identifies what he is trusted to keep and, just as clearly, limits what he can do with it.

The thing the holders help recover is the private half of the root zone’s key signing key, or KSK. To see why this matters, start with the other half. A validating resolver can use the published public key as a trust anchor, a starting point it already trusts before it evaluates answers. When the resolver follows a signed chain of delegations, it checks signatures and the links between zones, step by step. The process lets it judge whether a signed record is consistent with data published under the relevant authority. A resolver never needs the private root key to check that evidence. The operator needs that key to make the signatures at the top of the chain.

Even at the root, signing is divided. The practice statements published by IANA say that Public Technical Identifiers, or PTI, operates the root KSK. It uses that key to sign the root DNSKEY set, which contains the public keys for the zone, including the zone signing key. Verisign, as Root Zone Maintainer, uses the private half of the zone signing key, or ZSK, to sign the root’s other authoritative records. The root server operators serve the resulting zone. The distinction matters because the familiar shorthand about signing the internet conflates the keys, the publication process and the authority of every zone below the root. The root anchors a chain of evidence. Each signed child zone still produces its own signatures.

The two classes of outside volunteers serve different parts of that arrangement. A Cryptographic Officer brings a physical key to a scheduled ceremony. It opens an assigned safe deposit box inside the facility, where the officer’s activation credential is stored. Under the operator’s practice statement, the signing key in the hardware security module is activated using three of seven officer credentials for that module. IANA also asks the officers who attend to witness what happens and be prepared to vouch for the procedure to the wider community. The physical key and the credential inside the box are separate objects. A 2024 ceremony script makes the distinction between roles unusually easy to see. It lists the Czech engineer Ondřej Filip as a Cryptographic Officer and Ondřej Surý as a Recovery Key Share Holder.

The backup procedure uses five of seven. The operator retains encrypted copies of the private signing material. In the operator’s description of the Storage Master Key, the key protecting those copies is itself backed up under a threshold arrangement. Each recovery holder keeps a credential for one share in a sealed, tamper evident package, and the packages are kept in different places. The credential is neither the private signing key nor a piece that a holder could use to make a root signature. Meeting the recovery threshold is one requirement for reconstruction under the operator’s procedure. Access to the encrypted material and to the facilities and hardware where restoration can take place is governed by other controls.

The threshold makes both kinds of failure easier to reason about. In a hypothetical emergency, two missing shares would still leave enough of the original seven to meet a threshold of five. Three unavailable shares would leave only four, too few for that path at that moment. The same arithmetic makes one stolen or misused share insufficient for reconstruction. The design therefore has to care about both secrecy and availability. A credential secured so well that its custodian cannot retrieve it on short notice is of limited use in a recovery. Distributing credentials across people and locations reduces some shared risks, while coordination becomes part of the work whenever a group has to assemble.

Redundancy comes before that threshold. The operator’s practice statement describes geographically and logically separate key management facilities, with each equipped for production. Losing one site, one machine or one copy does not by itself call every recovery holder into action. IANA’s account of the role frames it around a widespread production failure that makes restoration from the protected backup necessary. In a hypothetical loss of equipment where an unaffected facility could continue to perform the required operations, that facility would be the useful redundancy. Surý’s responsibility begins much farther down the chain of contingencies. Reading the role as if he were an on-call signer for each incident misses the architecture that makes the credential worth keeping in reserve.

For the volunteer, the long periods between ceremonies have their own routine. IANA’s role description calls for evidence of continued safe custody and an attestation each year. It asks holders to maintain travel documents so that they can reach a facility at short notice, to provide information for periodic background checks and to return at intervals to validate or update the credentials. On retirement, a holder is expected to attend a documented transfer to a successor. Some of the most consequential work is therefore done when nothing has broken. The operator has to be able to establish that the custodian and the credential remain available years after the day they were brought together.

A recovery holder’s presence in a ceremony does not establish that a disaster has happened. The public agenda for April 25, 2024, in Culpeper makes the point. On the first day of the fifty-third root KSK ceremony, the objectives included signing for the third quarter of 2024, replacing recovery holders in slots one and six and reissuing recovery credentials. Those objectives appear alongside one another because the ceremony provides a controlled setting for different kinds of work. A credential can be enrolled or replaced under witness without being used to recover the private KSK from a disaster. The agenda documents the maintenance that keeps the contingency usable, rather than assigning every volunteer the same part in the signing.

The public record captures different views of a ceremony. The 2024 archive separates the live broadcast from the formal audit record, which includes dedicated camera footage, an annotated script and logs from the signing computer and hardware. The script records the sequence people are supposed to follow. The logs preserve what the equipment reports. IANA also publishes information about independent SOC 3 audits covering security, availability and processing integrity for the root KSK system. That gives an outside observer more than a photograph of people holding keys. It gives a set of records with different purposes, against which the institution can be asked to account for how an operation was run.

The audit trail goes back to the first ceremony. The 2010 script instructs witnesses to use a common time source for the written record and specifies who can enter the ceremony room and who must remain present. The participants assigned recovery credentials are called forward separately. The paperwork distinguishes the identity of each custodian from the identity of the package and asks witnesses to record the transfer. These are practical controls on the movement of objects. If a discrepancy is discovered later, it matters whether the institution can locate the point where the account breaks. An uninterrupted livestream might show what happened at a table. The signed custody record gives the operator a way to follow a particular credential after it leaves the room.

The archive also separates the date the key was made from the date that users could validate the signed root. After the June ceremony in Virginia came the July 12 ceremony in California. On July 15, 2010, IANA’s launch chronology records the publication of the root trust anchor and the start of service for the signed root with actual keys. The public act made the root available as a starting point for validation. Surý’s appointment belonged to the work that preceded that milestone and made continuity part of the design from the beginning. Publishing a public key establishes a point of reference. Keeping the corresponding signing capability recoverable is a different problem, one that outlasts the launch date.

The operator’s compromise procedures show why restoration cannot be the answer to every kind of loss. In a hypothetical hardware failure where the private key is still believed to be secret, putting that same key back into service preserves continuity with the public anchor already installed on validating systems. If the private key is believed compromised, restoring a legitimate backup cannot make an exposed key secret again. The practice statement covers emergency changes to trust anchors separately, with communication to the community and updates on the validating side. Recovery protects against losing the ability to use trusted material. A replacement addresses the different problem of material that can no longer safely be trusted.

IANA’s selection criteria put geography alongside integrity, independence and knowledge of the DNS. Volunteers must come from outside the organisations that operate the root zone. The geographic labels in the roster make that reach visible, without turning each share into the property or policy instrument of a country. Surý’s custody comes with obligations to the operator’s procedure and to the community that can inspect it. He has no unilateral ability through the role to sign records, change a delegation or take the network offline. His place in the system is precise. If a particular recovery path is needed and the operator calls for the credential, an independent person can bring the share entrusted to him, and a record can show how it was used.

A fingerprint for an SSH host

The other place where Surý’s name appears in the machinery of trust is a document about the first moments of an SSH connection. Consider a hypothetical engineer signing in to a machine that has just been provisioned. The SSH client can start an encrypted session, but first it has to decide which machine answered. Encryption alone leaves room for an impersonator to establish a session of its own. In the SSH transport protocol, the server supplies a host public key and proves possession of the corresponding private key as part of the key exchange. That proof becomes useful for identity only when the client has a sound reason to associate the public key with the hostname it meant to reach.

A common source of that association is a file of known host keys. After a key has been recorded there, a different key for the same host can trigger a warning or a refusal, depending on policy. On the first connection, there may be nothing local to compare with the key just received. In the hypothetical example, the engineer could obtain an expected fingerprint from a separate trusted source, such as a provisioning system controlled by the organisation. Accepting the first key and remembering it instead makes later changes visible, but leaves that first encounter exposed if an impostor answered. An independently published fingerprint gives the client evidence it did not get from the endpoint under examination.

RFC 4255, published in January 2006 by Jakob Schlyter and Wesley Griffin, defined SSHFP, the DNS resource record for this purpose. A zone publishes a digest of the encoded SSH host public key under the relevant DNS name. The client gets the public key from the SSH connection and can compute its own digest to compare with the DNS record. If the public key algorithm and the digest match an authenticated record, the client has grounds to accept that binding, subject to its own verification policy. Publishing the digest does not publish the host’s private key. The SSH server still has to prove possession of that private key during the exchange.

The record, DNS type 44, separates two algorithm choices that are easy to conflate. The first number identifies the kind of public key. The second identifies the hash that produces its fingerprint. What follows is the fingerprint itself, expressed in hexadecimal in a zone file. The digest is calculated over the SSH public key blob, rather than over a line copied from a terminal or the decorative text around a key file. This division means that a host can keep an existing RSA key while publishing a fingerprint of the same key made with a different hash. It can also introduce a different kind of host key and publish that key’s fingerprint in the same record format.

Surý, then identified with CZ.NIC, authored the standards track RFC 6594 in April 2012. His document added ECDSA as public key algorithm number 3 and SHA-256 as fingerprint type number 2. The new fingerprint type worked with the RSA and DSA keys already defined for SSHFP as well as the newly registered ECDSA keys. An ECDSA public key fingerprinted with SHA-256 would therefore begin with the pair of values 3 and 2. An RSA public key fingerprinted with the same hash would begin with 1 and 2. Neither pair dictates how SSH negotiates the rest of the session, and neither changes the cryptographic algorithms that sign the surrounding DNS zone.

The numbers preserve a useful division of labour. If a hypothetical service kept its RSA host key and published a SHA-256 digest, the server could retain the same key while DNS conveyed a new way to check its identity. If it switched to ECDSA, the relevant value in the first field would change as well. IANA’s registry later added Ed25519 and Ed448 through other RFCs. That continued growth illustrates why the fields are separate. New host key algorithms and new fingerprint algorithms may arrive on different schedules. A record that lets implementations interpret each field independently can grow without asking administrators to invent a new record type for every combination.

Surý’s RFC also settled a choice about what a verifier should do during the transition. It says that an implementation supporting SHA-256 must prefer the stronger fingerprint when both SHA-256 and SHA-1 fingerprints are available for a server. If the SHA-256 check is made and fails, the client is to reject the key rather than test the alternative SHA-1 fingerprint. The rule matters because two published digests otherwise invite a dangerous interpretation of compatibility. In a hypothetical mismatch where the old digest agrees and the stronger one disagrees, accepting the former would let weaker evidence erase the failure of stronger evidence. The RFC permits an orderly transition without asking a capable verifier to treat the two results as interchangeable.

At the other end of the comparison is the DNS answer itself. A person who can falsify an ordinary DNS reply may be able to provide a false fingerprint that agrees with a false SSH host key. RFC 4255 therefore makes authenticated DNS data a condition of trusting the match. With DNSSEC, a validator can check the signature over the SSHFP record set and trace the relevant links to a trust anchor. If the SSH client relies on another component to validate those signatures, the RFC requires a secure connection to the validator. A bare assertion from an untrusted resolver that an answer is authentic cannot establish the same property.

A missing fingerprint and a failed validation send the operator to different parts of the system. A valid signed response can prove that a name has no SSHFP record. A zone reached through an insecure delegation can have a fingerprint that the validator cannot authenticate as signed data. A response can also be expected to validate and fail, for example because a signature has expired. RFC 4033 distinguishes insecure data from bogus data. For an application, neither supplies the authenticated binding needed by SSHFP, but they are different diagnoses for the operator. An authenticated absence may simply reflect a decision not to publish. An insecure delegation means the chain stops short. A bogus answer points to a failure of the expected validation and calls for a different investigation.

Authentication begins even before the query. RFC 4255 discusses the case of someone typing an unqualified name such as a short machine label. In a hypothetical office setup, a local DNS search suffix may turn that label into one domain on the office network and another elsewhere. A fingerprint can be validly signed for the wrong full name and still be the wrong evidence for the user. The RFC recommends checking a local host key database first in that scenario, or using a trusted search path. The practical principle is that cryptography can check a binding for the name supplied. The client still has to know that this is the name the user intended.

A trusted match can have different consequences on different clients. The OpenBSD manual for OpenSSH documents VerifyHostKeyDNS as off by default. With the option set to yes, a key matching a secure DNS fingerprint can be trusted implicitly. With it set to ask, the match can be shown to the user, while confirmation of a new host key still follows the client’s strict host key checking setting. An insecure fingerprint is treated like the latter case even when DNS verification is set to yes. A team can publish an SSHFP record and see no change on clients that are not configured to consult it. The record gives clients a source of evidence. Local policy determines what they do with it.

That local policy is also where an implementation mistake can matter. In February 2025, OpenSSH’s release notes for 9.9p2 described a client logic error in versions 6.8p1 through 9.9p1. With VerifyHostKeyDNS enabled, an attacker on the network path could impersonate a server. The release fixed the error. The episode illustrates a limit of reviewing protocols only on paper. The requirement to authenticate the DNS record and compare it correctly with a host key is meaningful only if the client reliably enforces it. A bug in the path that interprets an option can remove a protection even when the zone operator has signed the records and the administrator has published the expected value.

There is an earlier boundary at the point of publication. As Schlyter and Griffin explain, signing a zone protects the fingerprint after it enters the signed data. It does not establish that the zone administrator received it from the legitimate machine. Consider a hypothetical operator who copies a fingerprint from the output of a connection to a newly commissioned server over the same untrusted path the record is intended to protect. The operator could inadvertently sign the impostor’s identity. Secure enrollment means obtaining the key material through trusted provisioning or transferring the fingerprint securely from the host administrator to the zone administrator. The OpenSSH utility can generate the record from a specified public key file. Choosing the right file remains a separate responsibility.

Routine changes can also leave DNS and the server telling different stories. Suppose a hypothetical team rolls a host key by replacing it on the machine first and publishing the new fingerprint moments later. Some resolvers may still return the old record from cache, and clients configured to require DNS evidence can lose access even though the new key belongs to the right machine. Publishing both authorized fingerprints for a planned interval can help an ordinary transition, provided the old key is still safe to accept. That condition matters. An overlap designed for continuity during rotation is the wrong convenience if the old private key is suspected of being stolen. The same deployment mechanism can serve two different goals that call for different timing.

RFC 4255 describes deletion of the relevant fingerprint as a possible revocation mechanism when a client can be configured to require the DNS check. That qualification carries real consequences. If the local policy accepts an already recorded key regardless of what DNS says, deleting the fingerprint does not itself revoke the local entry. Cached answers can also delay the disappearance of the old binding. An operator who needs an emergency withdrawal has to account for those copies and any independent trust paths. The other side of the choice is availability. A strict DNS requirement makes a validation failure a reason to stop connecting, even when a working SSH server is still at the expected address.

There is a broader allocation of authority in that choice. An organisation that relies on signed DNS for first contact lets the operator of the relevant zone, or a system allowed to update it, help decide which host key counts for a name. If a hypothetical intruder gains control of that publication path and the ability to intercept connections, the intruder can arrange for correctly signed DNS evidence that points to a key under their control. Validating the DNS signature proves that the signed zone vouched for the binding. It cannot establish that the system publishing the zone was well administered. The authority to publish SSHFP therefore belongs in the security review alongside the authority to provision the SSH host.

Host identity also has a narrow boundary at the other end. A verified fingerprint says something about the server key for a name, while user authentication decides whether a particular person or service may log in. SSHFP publishes no user credentials and grants no account permissions. DNSSEC does not hide the published fingerprint or replace encryption in the SSH transport. That distinction makes it possible to assess Surý’s contribution at the right scale. RFC 6594 made a specific check usable with a wider set of keys and a stronger digest, and specified how that check should behave in the presence of older evidence. The rest still depends on the people and systems responsible for the host, the zone and the client.

Cookies at a DNS boundary

On a DNS exchange over UDP, a server can receive a packet whose apparent sender never transmitted it. If the server replies with a much larger answer, the response goes to the owner of the forged source address. An attacker can use this difference to direct traffic at a third party. A client has its own concern when a forged answer arrives purporting to be from a server it queried. DNS Cookies add a small piece of evidence about the exchange. They raise the difficulty of some attacks by parties that cannot see the traffic. The aim is deliberately narrower than making the DNS private or verifying a domain’s published records.

The word cookie comes with misleading associations for anyone who knows it chiefly from browsing the web. This cookie is carried in the DNS protocol itself, through an extension option. A participating client sends a Client Cookie, a short value that a party away from the traffic should have difficulty guessing. A participating server can return that value along with a Server Cookie. The client can save the latter for later requests to the same server address. On receiving one back, the server can check whether it matches a value it would have generated. The two cookie values serve different readers. The client recognizes its own value, while the server verifies the token it supplied.

A valid Server Cookie gives the server some reason to believe that someone at the apparent source address has been able to receive a previous reply for this interaction. That claim is useful precisely because an attacker forging a source address usually cannot see the answer sent there. It leaves the server room to treat a request with a valid cookie differently from one without that evidence. For instance, the original cookie specification discusses how a server can avoid sending a large answer to an apparently unverified client. Receiving a prior reply is a limited claim. It says nothing about who is sitting at a machine, whether the query is wanted, or whether a participant can flood the service with packets it actually sends.

RFC 7873, which established DNS Cookies, left server implementations room to choose the calculation. That was workable where the same software both issued and verified a value. It could become a problem on an anycast service, where one service address can lead to several sites. Anycast makes the same service address reachable at multiple nodes. Routing decides which instance handles a given query, and changes to routes can send a later query somewhere else. A client sees continuity in the destination address and can send the same stored token. The software that receives it may be entirely different from the software that created it. If the implementations use different calculations, giving them the same secret will not make their tokens interchangeable.

RFC 9018, published in April 2021, is the answer Surý developed with Willem Toorop, Donald E. Eastlake 3rd, and Mark Andrews. It updates RFC 7873 by giving Server Cookie implementations a common construction. The original standard already recommended that members of an anycast set share a Server Secret. The revision adds the part needed to make that recommendation work across products. It specifies the format and the calculation, so a node can check a value generated at another site. Compatibility depends on both the method and the secret. A site with the right software and the wrong configured secret is as unable to verify a cookie as a site using an incompatible method.

The version defined in RFC 9018 has a 16 byte Server Cookie with a version field, reserved bytes, a timestamp, and a keyed tag calculated with SipHash-2-4. The calculation includes the Client Cookie and the source IP address as observed by the server, as well as the version, reserved bytes, and timestamp. The address contributes to the tag without having to appear in the token itself. In the same format, the Client Cookie adds another eight bytes to the option payload. The length is part of the security check. The implementation checks the layout before verification so bytes from an IPv4 case cannot be interpreted as though they belonged to a different set of fields in an IPv6 case.

Timestamps put an upper bound on how long a recorded Server Cookie can ordinarily be reused. RFC 9018 recommends accepting values up to an hour old, with a smaller allowance for clocks that put the issuance time slightly in the future. That allowance has a practical purpose for geographically dispersed servers. A shared secret does not synchronize clocks. Two nodes can calculate the same tag and still disagree on whether it is timely. A client can also lose the benefit of its old token if it starts reaching the service from a different source address. Verification must reflect the address the server sees, since that is the part of the interaction the token is meant to help confirm.

The document is more flexible about Client Cookies. A server ordinarily echoes the client’s value and uses it as an input for the Server Cookie. It does not have to know how the client made it. The client must use different Client Cookies for different server addresses, and the revised guidance considers privacy when choosing or changing those values. A long lived value reused across destinations could make it easier for cooperating servers to recognise a client across otherwise separate interactions. Interoperability does not require a common client recipe. Requiring one would solve the wrong problem, since the component that needs to recognise a Client Cookie is the client that chose it.

A change to the shared secret is a distributed operation. RFC 9018 describes a sequence in which every node first learns the new secret for verification, while all continue issuing cookies with the old one. Only after that preparation can the service start issuing cookies with the new secret. Both remain valid for verification while clients have time to acquire new tokens, after which the old secret is removed. Issuing comes after the ability to verify. Without that order, a node that moved early could hand clients tokens that other sites would immediately reject. The schedule protects continuity without requiring every site to change its issuance behaviour in the same instant.

The protocol has a way to recover from an invalid Server Cookie. When a client gets a suitable BADCOOKIE response, it can try the request again with the replacement cookie supplied by the server. RFC 7873 observes that repeated BADCOOKIE responses after such retries can point to a mismatch in an anycast group and recommends trying TCP after a further rejection of a fresh token. The retry pattern can reveal an inconsistent service. In a mixed deployment, testing one server in isolation may never produce that pattern. A more revealing test has one implementation issue a cookie and another check it, using the same configured secret and the same client address.

Cookies and DNSSEC can coexist because they answer different questions. DNSSEC can validate records that were signed earlier and obtained from a cache or other intermediary. A cookie is tied to the pair involved in a DNS exchange and offers no comparable basis for deciding that the answer represents the domain owner’s signed data. Someone who can see plaintext traffic can also observe the cookie and may be able to reuse it while it remains valid. The limits follow from what gets checked. DNS Cookies can make forgery, cache poisoning, or reflected amplification harder for certain off path attackers. They do not encrypt traffic, establish an end user’s identity, or make a signed answer trustworthy in place of DNSSEC validation.

The acknowledgments in RFC 9018 trace a practical test of this idea to the IETF 104 hackathon in Prague. They credit Witold Krecicki and Pieter Lexis for helping implement an interoperable cookie prototype in BIND 9, Knot, and PowerDNS. Those names make the problem tangible. One service address can outlast any particular combination of server programs, and an operator should be able to test that assumption before a deployment changes. The published RFC includes test vectors for independent implementations, covering cases such as a renewed cookie and an IPv6 query during a secret rollover. These let two developers compare results without having to share a codebase or a live network.

Catalog zones and the operations of scale

An authoritative DNS server can have an excellent copy of every zone it knows to serve and still be missing a zone that its operator expected it to have. Traditional zone transfers solved the problem of copying the contents of a zone from a primary to secondaries. They did not, by themselves, tell a secondary which zones should exist in its configuration. An operator adding a zone therefore had two kinds of work. The data had to be ready to transfer, and each secondary had to be told to ask for it. The inventory and the contents moved separately. As the number of zones or servers grew, keeping that inventory in sync became a task in its own right.

RFC 9432, published in July 2023, defines a catalog zone as a way to represent that inventory in DNS itself. Its seven authors, including Surý and Aram Sargsyan at Internet Systems Consortium, brought affiliations spanning several DNS projects and operators. The design uses ordinary DNS zone transfers to send the catalog, and software on the receiving side interprets certain records as instructions for provisioning. A configured consumer can learn that it needs to begin serving a member zone or stop serving one. A catalog transfer carries desired membership. The catalog does not contain the member zone’s ordinary records, which must still be supplied separately to the servers that are meant to answer for that zone.

The terms producer and consumer are useful because they identify who creates the catalog and who acts on it. These roles often align with primary and secondary in a straightforward deployment. A primary serves the catalog and member zones, and a secondary transfers the catalog before provisioning its members. The RFC leaves room for other arrangements. A consumer of a catalog need not be a secondary in every deployment, and a server can be configured to consume several catalogs. The provisioning relationship has its own roles. Keeping those roles distinct helps explain why receiving a catalog update and obtaining a usable copy of a member zone are separate events, even when the same two servers are involved in both.

The catalog is recognisable as an ordinary zone. It has a zone apex with the customary SOA and NS records. A TXT record below the apex identifies the schema, which is version 2 in RFC 9432. Under the catalog’s membership branch, a PTR record names each member zone. Its owner contains a label that identifies the member node within the catalog. The PTR points to the DNS name of the zone that should be provisioned. The member node and its target are distinct. That distinction lets an operator attach settings to a particular instance of a member and lets the protocol express a change in that instance even when the target zone name stays the same.

An operator still has to configure consumers to receive a particular catalog and interpret it as such. The transfer path, the identity of trusted senders, and the applicable local settings have to be established first. From there, a change can propagate using the usual DNS mechanisms for refreshing a zone, including a complete transfer or an incremental one. The primary can also send a DNS NOTIFY to prompt a refresh. The catalog is bootstrapped outside the catalog. A system cannot usefully accept provisioning from every arbitrary zone that happens to contain a similar record layout. The initial setup is where the operator chooses which feed has permission to affect the service.

Reusing transfer mechanisms leaves room for independent implementation without requiring one management API. ISC’s introduction to catalog zones documents BIND support for the earlier version 1 and the version 2 schema. PowerDNS’s authoritative server documentation describes version 2 production and consumption, along with consumption of version 1. It also identifies limitations around group templates and custom extensions. These accounts show that interoperability has a defined scope. Two systems can recognise the same standardised membership format even though their configuration commands, storage backends, and optional features differ. When a deployment depends on behaviour beyond membership, support for the catalog version is a starting point for compatibility checks.

The handling of groups makes that distinction especially clear. RFC 9432 defines how to convey group labels in the catalog, while leaving their meaning to an agreement between the producer and consumers. An operator could associate a label with a particular DNSSEC policy, provided the receiving systems were configured to apply that policy. Custom properties also have a place in the format, but putting one there does not give it universal meaning. A standard can transport a label without defining its policy. In a mixed installation, the operational question is what each receiving system actually does with that label and how it behaves if the setting is unknown.

The catalog itself and the zones listed inside it can advance at different speeds. A secondary might receive a notification about a member zone before the catalog update that tells it to provision that member. In another plausible sequence, it can receive a valid catalog update and still fail to fetch a member because that transfer is blocked or the source is unavailable. Receiving the instruction is not the same as serving the zone. An operator looking for evidence of completion can distinguish the catalog serial a consumer has loaded, the state of the member’s separate transfer, and the authoritative answers it is producing. Those observations identify which step is lagging without assuming a single atomic update across all servers.

Removal has a boundary of its own. A consumer must ignore a conflicting incoming member if it already has a zone by that name, except where a defined migration procedure applies. If a member disappears from a catalog, the consumer removes the zone and associated state only when that catalog supplied its configuration. It should not remove a separately configured zone merely because an entry with the same name was deleted. Authority to provision determines authority to remove. That rule matters when multiple catalogs feed a consumer or some zones remain under static configuration. A catalog’s contents are an instruction within an established relationship, rather than a universal instruction about every occurrence of a DNS name.

RFC 9432 gives operators a way to move a member between catalogs without automatically discarding its associated state. A change of ownership property in the old catalog can authorize a particular new catalog to take over. The member’s label matters in that handoff. Preserving it can preserve state, whereas a label change can signal that the consumer must reset the state and treat the member as newly added. A reset can affect local zone data or DNSSEC keys, depending on the deployment. The public name can stay while its local state changes. A handoff therefore has to distinguish a move of an existing configuration from a request to replace it with a fresh one.

The fact that catalog data uses the DNS wire format does not make it suitable for ordinary public queries. The RFC recommends limiting who can query a catalog and authenticating transfers and updates. TSIG is one way to authenticate a transfer, and the RFC also discusses appropriate forms of authenticated TLS. It advises against including shared TSIG secrets for member zones in the catalog data itself, although key identifiers can be carried there. Authentication grants a producer operational power. The RFC also recommends limiting the member names a consumer will accept, so the producer’s authority can be bounded. A valid transfer can establish where instructions came from while leaving it to the consumer to decide what that sender may provision.

A more mundane failure can be just as disruptive. A producer may generate an empty catalog when it meant to add a single zone. If the result is otherwise valid, consumers can read the missing entries as genuine removal instructions. The RFC calls out this possibility because one publisher can affect a large fleet. A correctly transferred mistake still takes effect. Checking the proposed membership against the prior version before publication, and watching for unexpected drops afterward, follow directly from that risk. Catalog expiry is a different condition. The RFC says the expired zone ceases to be processed as a catalog until it is fresh again. That distinction keeps a failure to refresh from being mistaken for an explicit instruction to remove everything.

The accomplishment of catalog zones is to make a recurring administrative decision portable. The producer can express membership once in a form that several consumers know how to interpret, using a distribution channel already familiar to DNS operators. Each consumer still needs to get the member data and apply its own authorized settings. Each operator still needs evidence that the intended authoritative service exists. The fleet shares an inventory, not a single fate. The distinction between inventory, transfers, and live answers gives operators places to look when the service falls short. It is also what keeps a DNS catalog useful when the servers that consume it do not share a vendor or a management system.

The economics of keeping a release channel open

A package repository can be useful long before anyone decides who should pay to keep it useful. A team solves a deployment problem one afternoon, the solution goes into a machine image, and six months later that image is where new servers start. The original decision may have saved the team from maintaining its own PHP builds or coordinating an application rewrite with an operating system upgrade. The saving recurs every time a server is replaced. Meanwhile, the people who keep the repository useful still have to do the next release. The benefit repeats automatically. The work that makes it possible has to be scheduled again and again.

Surý describes that arrangement plainly on the website for his PHP package archives. He says PHP packaging takes time and that he does it mostly in his free time. He asks people who use the packages to run a business to consider commercial support from Freexian, and people who find the packages useful to consider donating. The same page credits companies that support the project directly or through PHP LTS by Freexian. Those are different kinds of support. The acknowledgments establish that outside support exists. They do not tell us how much of Surý’s time is paid for, how the money is divided, or what any individual sponsor has been promised.

Consider the work behind an uneventful update. If a fix was written for a current PHP release but an older branch still needs it, someone has to understand the change well enough to adapt it without carrying over assumptions the old code cannot meet. The result must build, and the tests need to say something useful about whether it is safe to publish. A distributor has to decide which versions warrant that work. The expensive part is judgment. Freexian’s description of its own service spells out monitoring, triage, backporting relevant fixes and tests, and running the PHP regression suite. That describes its subscription work and helps explain what a finished package can hide.

Spare time can produce excellent software. The difficulty for a business comes when it plans around that spare time as though it already sits on a staffed schedule. The exact day an urgent update is needed may be the day another branch breaks, or an unrelated obligation takes precedence. Available time is a release input. For a subscriber that can count on a defined support channel, there is somewhere to bring that collision. For a user of a public repository offered on a best effort basis, the operator of the application has to decide how to handle the time between an upstream fix and a usable package.

The distinction has a practical expression in the Freexian offering. Freexian operates its PHP LTS service with Surý’s help and describes the public Surý’s package archive service as best effort. The commercial repositories are private, and subscribers have a direct channel for package and security issues. The scope of the subscription depends in part on the specific combination of PHP and Debian or Ubuntu releases a customer needs. Check the combination. Freexian’s published availability matrix distinguishes between packages that are available with security support and packages that are available without it. A procurement request that says only that the organisation needs support for PHP can miss the very case that prompted the purchase.

Nor does buying support relieve an operator of testing an update against its own application or deciding how to deploy it. There is a boundary between producing a regression-tested package and knowing whether a particular application will behave after rollout. Freexian publishes the included email support hours for each tier and says additional support is billed. Read what the subscription covers. An operator should check whether its immediate need is timely access to packages, help diagnosing a suspected packaging issue, or someone to work through an application incident. Those needs can overlap in an outage. Working out where they diverge is easier while both the customer and the provider have time to read the agreement.

The public repository and the paid service also solve different budgeting problems. A donation can sustain a project without asking its maintainer to rank the donor’s tickets ahead of everyone else’s. A recurring sponsorship can make it easier to plan recurring work. A contract can give a business a named place to escalate an issue and defined coverage it can match to its own commitments. Payment can buy different things. The terms determine whether it pays for some of the shared work, gives a customer a specific benefit, or does both. The public descriptions in Surý’s case are enough to draw that distinction without trying to reconstruct his accounts.

The broader evidence helps explain why the money question is easy to miss. Sam Boysel and Frank Nagle’s 2024 Open Source Software Funding Report, based on a survey conducted with GitHub and the Linux Foundation, found that employee labour represented 86 percent of the value reported by the 159 organisations that supplied contribution data. The report’s estimate of $7.7 billion in annual organizational contributions extrapolates from the survey using assumptions about the wider distribution of contributions. Much of the value took the form of paid time. The estimate is neither an observed global total nor a measure of what reaches infrastructure projects of any particular size. It offers no estimate of what reaches this repository.

That labour finding matters to a team considering how to contribute. In the authors’ account, many organisations could describe their contributions in general terms yet had trouble supplying details such as the hours contributed. Consider a hosting company whose staff already investigate a packaging problem in the course of serving customers. An engineer can be given paid time to turn the investigation into a test case the maintainer can use. That contribution may appear nowhere in a donations ledger. Make the contribution visible. Otherwise the company may have little record of the time it committed, and little basis for deciding whether it can commit the same time in the next release cycle.

Tidelift’s 2024 maintainer survey looked at the problem from the other side. It drew answers from 437 people who maintain at least one open source project. Sixty percent described themselves as unpaid hobbyists when asked to choose a description of their role. When people could select among several possible sources of income, 47 percent reported that they did not get paid to maintain projects. Even the word paid needs care. A nominal amount and an income that makes it possible to set aside a working day can both count as compensation. The vendor recruited through a social campaign, so the answers describe people who chose to participate rather than a representative census of maintainers.

That survey also found that paid maintainers often reported being able to spend more time on maintenance because of their compensation. Tidelift found a relationship between compensation and having co-maintainers, while pointing out that the direction of influence was unclear. Larger teams might attract more funding, and funding might help teams find and retain more contributors. Time can go into sharing the work. A useful implication is to fund the work that allows someone else to take a turn, whether that means pairing through a release, reviewing a second maintainer’s first upload, or paying for test infrastructure both people can use. Compensation alone does not turn an observer into a release operator.

A historical comparison shows the range of things that funding can cover. In May 2014, the Linux Foundation announced that its Core Infrastructure Initiative would fund two full-time core developers for OpenSSL. It also announced separate funding for the Open Crypto Audit Project to audit the code. The initiative described other kinds of support it could fund, including computing and test infrastructure. Staffing and independent review were separate investments. The point of the comparison is the specificity of the commitments. Developer time creates room to fix and maintain software. An audit can bring a different set of eyes to it. The announcement does not establish the cost of running a PHP package archive or prescribe the same arrangement for Surý’s project.

Closer to Surý’s work, Freexian publishes activity reports for the separate Debian LTS service it funds. Its February 2026 report says 20 contributors were paid to work on Debian LTS that month and links to individual activity reports and published advisories. It also describes work on issues in newer Debian releases. The work is visible after payment. A reader can see examples of packages fixed and follow links to individual advisories. This reporting makes the model concrete without inviting a claim about the staffing of PHP LTS. They are separate services. The Debian report shows what one provider can make public about the work its support finances.

There is a reason to care about how the money arrives. A grant can pay for a test suite, a first migration away from a brittle builder, or a review that has a clear end. A repository must still answer for every package and platform it says it will support when the next issue appears. Recurring promises need recurring capacity. On the other hand, a recurring subscription to extended support may also let an organisation postpone a migration that still needs to happen. For a buyer, the money is most useful if the time it buys has an explicit purpose, like testing a replacement runtime while keeping the existing deployment within a defined support window.

Good contributions also match the bottleneck. Offering a new feature can give a project something useful, but the maintainer then owns the feature’s interaction with every release the project keeps alive. A small, well documented reproducer for an existing bug, complete with the affected system version and a demonstration of the failure, can shorten a task already in the queue. Ask what work can be removed. A sponsor that wants more release capacity might fund sustained triage or a shared build worker instead of another visible feature. The maintainer is better placed to identify which activity is constraining output. The user is better placed to describe where a delay costs them.

A company can account for its repository dependency before it needs an emergency purchase. That accounting can start with the engineering time it would need to replace the channel and which services would wait while it did so. The company can then compare an ongoing contribution, a subscription with suitable coverage, or an internally staffed alternative. The comparison is against replacement work. An invoice may be easier to count than the time spent rebuilding packages or rushing a migration, but each is a real cost to the operator. This is a way to budget for dependency risk without pretending a public package has an invisible price tag attached to it.

Surý’s repository makes this unusual bargain visible because he explains both where his labour comes from and where a business can go for a different support relationship. Someone testing an application on a spare machine can make use of that labour without first negotiating a contract. A company that has built a substantial service around the same release channel has enough information to ask what it should fund and what it should arrange separately. Dependence changes the planning question. The relevant test is whether the team can explain how its service will keep moving when the next fix takes longer than hoped, whoever ultimately prepares it.

Making the dependency survivable

The planning question becomes more concrete if an operator starts with a replacement machine. Imagine a production host fails while the usual package source is temporarily unreachable. The running hosts may carry on, yet the team cannot quickly replace the one it has lost. A second version of the exercise starts with a fix that has arrived from upstream but has not reached the team’s package channel. One case is about getting back to a known state. The other is about getting beyond it. Recovery and maintenance are different jobs. A plan that covers only the packages already on disk is useful for the first case and incomplete for the second.

A second operator should be able to read the inventory without asking its author. An entry for a critical runtime should identify the source of the installed packages, the operating system release, the package versions, and the paths by which changes reach production. An application may also depend on extensions that move on a different schedule from the runtime itself. Record where the package came from. In this article’s operational reading, it is useful to keep that record alongside the deployment configuration so the next person can tell whether two otherwise similar hosts receive fixes from the same channel. The record should explain why the choice was made and who can revisit it.

An independent record of source and build inputs answers a more precise question. Version 1.2 of the SLSA specification describes build provenance as a way to trace build output back to the source that produced it. Its suggested format can identify the builder, the output, the external parameters and known resolved inputs, such as the exact commit obtained from a repository reference. Provenance describes a particular build. A team can use that information to decide what it accepts from a supplier or what it needs to investigate when a version comes into doubt. The strength of the evidence depends on how it was generated and verified. A hand-maintained inventory serves a related but different purpose.

Reproducible Builds sets a separate test. Given the same source, relevant build environment and instructions, another party must be able to recreate the specified artifacts bit for bit. The comparison is with the output, rather than whether a build command completed without error. Two packages might install and pass the same application tests while still differing in bytes. An independent comparison tests the result. A source tree, a documented build command and a matching artifact produced on the original builder do not establish that someone else can repeat the result. Conversely, identical results support a claim about how an artifact was produced without proving the source is free of vulnerabilities.

Debian’s build information format shows some of the detail involved. A Debian source package build can record fields such as the architecture, installed build dependencies and file checksums in a build information file. The Reproducible Builds documentation also explains that build environments can depend on versions, configuration flags and settings such as locale. Write down what would otherwise disappear. The value for a prospective successor is that these details can be inspected without asking what used to be installed on someone’s machine. The file still has to be retained, its dependencies must be obtainable, and the instructions must be usable. Nothing about the format alone establishes the reproducibility of an individual package from Surý’s repository.

Retention helps with a different piece of the recovery problem. Debian’s snapshot service illustrates the principle by making historical versions from the Debian archive accessible by date and version. That does not mean a third-party archive is captured by the same service. An operator may choose to keep approved binaries or known working machine images for critical systems where it has the right to retain them. A snapshot buys a starting point. It cannot supply a security update published after it was taken. A team that restores from an older image needs a way to identify the fixes it missed and bring the replacement forward before treating it as an ordinary current host.

A repository handover has to address the work that happens after that starting point. Someone must know which branches are supported, how a change gets approved, where tests run, how to interpret a failure and what evidence should accompany publication. The useful measure of the documentation is whether a second person can execute it in a test setting and explain why the outcome is safe. Have a second person run a release. The exercise can expose steps that sound obvious in a short document because the author already knows which build error can be ignored and which is a reason to stop. Those decisions belong in the handover as much as the commands.

Debian offers an institutional example of sharing the work. Its Developer’s Reference describes collaborative package maintenance, including ways to record a primary maintainer and co-maintainers or to use a team address with named people responsible for a package. It also recommends setting up access to the sources used for builds. The names are tied to duties. Debian warns against listing every team member as an uploader for each package regardless of involvement, since that gives a false impression of coverage. The practice is an example for a separate repository to learn from. Debian’s package roles do not themselves grant rights over a third-party archive.

The same reference distinguishes a temporary intervention from a long-term takeover. An eligible contributor may use a non-maintainer upload to fix an issue under Debian’s procedures. The package salvaging procedure is meant for someone who intends to maintain an eligible package for a prolonged period and gives the current maintainer notice and an opportunity to respond. A fix and a succession serve different purposes. An independent repository can make a similar distinction in its own rules. A person trusted to prepare an emergency patch does not necessarily want to decide which platforms the channel will support in a year, and the people depending on the channel benefit from knowing where that authority sits.

Shared ownership also has to reach beyond the source tree. GitHub’s documentation recommends at least two organisation owners so that projects do not become inaccessible when one owner is unreachable. That is an example of separating an organisation’s continuity from a person’s availability. Map the other points of control. In the operational analysis here, a release channel might also depend on a registrar account, a builder, a place to publish artifacts, a security mailbox and the ability to authorize a signing key transition. A second GitHub owner can help recover the code organisation. The rest of the service still needs its own accountable owners and routes to recovery.

More owners improve availability only if they can take over without weakening the controls that make the archive trustworthy. Giving several people a shared credential makes it harder to know who used it and harder to remove one person’s access later. Making every contributor an administrator creates a different problem. Give people the access their role needs. As a design choice, an organisation can give individuals separate identities, reserve full control for a small group, and rehearse recovery with the people who are supposed to use it. For particularly sensitive publication changes, a second person’s review can limit the damage from one compromised account, provided the project can actually staff that review.

Account recovery deserves to be rehearsed in its own right. GitHub says its support staff will not restore access to a two-factor account when the user has lost the required credentials and recovery methods. An operator should therefore check that authorized people have appropriate recovery options and that the organisation still has another owner if one individual loses access. Test recovery before it is needed. Applying the same principle to the larger release channel means working out how a new operator can regain control of publication and how users would recognise a legitimate change. The aim is a documented transfer of authority with a clear record of who approved it.

An operator with no role in the upstream project still has decisions to make. Moving to a distribution’s own packages can simplify the number of support relationships, if the distribution carries a compatible runtime and the required extensions. Buying support can cover combinations a team cannot yet retire. Keeping a private mirror may help with availability when access and redistribution terms allow it. Building internally gives the team more control and gives it another maintenance job. Each option changes who acts next. These choices are best tested on a representative application while the original channel is still working. Until then, the team knows that it has options in theory but little about how long each would take.

The temptation in a migration is to measure success by whether the application starts. A replacement package may have different defaults, a different update cadence, or a different selection of compatible extensions. An operator should test the paths where the application writes data, calls outside services and runs scheduled jobs, as well as whether it serves an ordinary request. Rehearse a real switch. A team also needs to know whether it can roll back safely after writes have occurred and who decides when to do so. That preparation can turn a change of package source into planned work and reveal where an apparent shortcut would create a second emergency.

A support plan can be evaluated with the same exercise. Suppose a security issue affects an unusual pair of runtime and operating system releases that an application still uses. The team should be able to find the provider’s coverage for that pair, know how to raise the issue, and identify who will check and deploy the resulting update. If it relies on a private archive, it should also know which authorized people can renew access. Follow the problem to deployment. A useful contract defines some of those obligations, while some remain with the customer. A donation can help sustain the project even where it does not create any of those obligations.

This kind of planning can benefit maintainers too. A team that knows which version is affected can file a narrower bug report. A team that can rebuild an artifact can help distinguish a packaging change from a fault in the application. A team that has a viable path away from an old runtime can eventually stop asking someone to carry that branch. Prepared users impose less emergency work. The claim here is about the possible effect of a good operating practice, rather than a description of who does what around Surý’s package archive today. The same distinction matters when a project seeks co-maintainers. Making the work teachable gives others a practical route to contributing without assuming they will volunteer.

The goal of these measures is to keep a useful dependency from becoming a decision nobody else knows how to revisit. A traceable package gives a team a way to establish what it installed. A working rebuild gives another engineer a way to compare or reconstruct what was produced. A rehearsed transfer of access gives the next operator a way to publish. A support agreement can make clear who will take the first call. Continuity is something people can demonstrate. Surý’s work matters in part because it has saved other people from having to solve these problems alone. Those who rely on it can do their part by making their own next move possible.

The radio interview began with the question of whether Surý felt time running out. He talked about the people who were going to install his packages and his pleasure at being able to help them. It is a narrow answer to a grand description, and it has the advantage of giving the audience somebody else to picture. There is an engineer at the other end of the release, deciding which machines can be updated first and whether the service came back. Surý’s work reached that engineer as an installable update. The usefulness of the work was apparent to both people even if they never exchanged a word.

A professional who learns his name should be able to attach it to a record. In Debian that can be an archive entry signed on the day of a critical release. In DNS it can be a specification with a problem and a set of authors, or the documentation for a server maintained by a team. These records are more durable than the epithet attached to an interview. They locate a person inside an institution that carries responsibility past the moment of public attention. That is the scale on which a long career in maintenance becomes visible.

The best reason to remember Ondřej Surý is the ordinariness of the action described in October. He knew how to prepare an update, he had somewhere trusted to put it and the people who needed it knew how to receive it. The work over the preceding years made each of those facts possible. When the next security notice arrives for something else, the people responsible for it will need their own version of that arrangement. A fix reaches people because someone has spent time building the way it will travel.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

I’m cold-blooded in these situations, says Czech “who saved the internet”
Ian Willoughby’s Radio Prague International interview records Surý’s explanation of his packaging role, the work involved and his reaction to the attention.

Accepted php8.4 8.4.27-1~deb13u1 (source) into stable-security
Debian’s archive notice documents the 21 October acceptance time, the trixie security suite, the package revision, both CVEs and Surý’s signature.

Security advisory: Critical remote code execution vulnerabilities, update now
The PHP project identifies the affected web-serving interfaces, describes the two vulnerability mechanisms and gives the four upstream corrected versions.

PHP 8.5.12 Released
The PHP mailing-list announcement supplies the dated release event and names both critical vulnerabilities.

PHP 8 ChangeLog
The PHP 8 branch changelog records the release and the fixes identified by the two advisory IDs.

DEB.SURY.ORG
Surý’s project site documents his Debian and PHP work, the Debian archive and Ubuntu PPA, co-installable branches and the project’s reporting and support arrangements.

DDEV October 2026: PHP2Shell Fixed in v1.25.5, Thanks to Ondřej Surý and the PHP Foundation
DDEV documents the early fixed AMD64 builds, their legacy branch coverage and delivery of fixed PHP in its downstream web server image.

Supported Versions
The PHP project describes the stages of upstream branch support and publishes its branch schedule.

Debian security FAQ
Debian explains stable security updates, backported fixes and how to check affected package revisions.

apt-secure(8)
Debian’s APT manual explains archive authentication, signed Release metadata and the limits of the trust chain.

php2shell vulnerabilities (CVE-2026-109618, CVE-2026-109619)
The Dutch National Cyber Security Centre repository documents the incident and tracks product-specific status, detection and mitigation information.

Balíš, balím, balíme
Surý’s 2015 LinuxDays slides document his Debian portfolio, show the structure of the Knot DNS package and explain clean package builds.

Meet an ISC Engineer – Ondřej Surý!
ISC’s profile documents his leadership of BIND 9 engineering, career background and work at CZ.NIC.

Ondřej Surý
The IETF profile documents Surý’s working-group role and his published RFCs.

Domain Name System Operations (dnsop)
The IETF working-group page names its chairs and records its charter, scope and public working arrangements.

Today’s PHP Security Release, and How We’re Strengthening PHP Security
The Foundation documents the 2024 audit, the engineering trade-offs, the vulnerability reports, coordinated disclosure and the organisation of the upstream response.

RCE via OOM corruption
CVE-2026-109618. mod_php startup and shutdown sequence, FPM exits its child on failed startup but remains susceptible to other paths, RCE validation on Apache prefork with multiple workers, soft and hard OOM thresholds, incomplete nature of mitigations.

RCE via stale global state
CVE-2026-109619. Same-worker requirement for producer/consumer, worker lifecycle effect, mod_php fatal backtrace RCE and mod_php plus FPM session lifecycle RCE, warning about log coverage.

Upcoming Critical PHP Security Release
Official mailing-list record timestamp 19:33:47 UTC on October 20, updated schedule October 21 at 14:00 UTC, and conditions for bringing release forward. Distinct record from website pre-announcement.

PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
Research team’s own timeline of Drupal and WordPress confirmations, August 24 reporting, September acknowledgment of Wiz reports and October 21 public disclosure.

PHP2Shell — AI uncovers critical vulnerabilities in the backbone of the web
Restart every relevant PHP service and worker after patching, WAF and setting changes as partial measures, indicators and detection limits, risk of memory exposure and effects of hard OOM.

Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
First observed October 17 attempt, unknown information source, further October 21 attempts before disclosure, uncertain applicability of attempts to production systems.

Cloudflare deploys protections against php2shell vulnerability
Direct provider account of WAF protection and recommendation to apply PHP update alongside it.

php_sapi_name
Runtime interface labels cli, apache2handler and fpm-fcgi.

phpversion
Function for querying the currently running PHP version.

Configuration
FPM pool configuration, listener and worker parameters.

Status Page
Pool status, example Apache socket forwarding configuration, exposure warning and access restriction.

Module ngx_http_fastcgi_module
FastCGI upstream as address or Unix-domain socket.

Stopping and Restarting Apache HTTP Server
Graceful restart behavior, including existing children finishing their current requests.

apt-cache(8)
APT policy command for examining the version selection state.

systemctl
Service unit inspection and restart.

FastCGI <fastCgi>
IIS FastCGI handler mappings and per-site full executable path configuration.

Images
Immutable content identity via image digest.

kubectl rollout status
Observing status of a rollout.

Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile
General incident response and recovery context.

RIPE 63 — DNS Working Group minutes, session 1, section E “Knot – DNS, a new high-performance authoritative name server — Ľuboš Slovák, CZ.NIC”
Conference minutes identify Slovák as the presenter and Surý as a co-developer. Surý described gathering two months of CZ.NIC traffic for replay and CZ.NIC’s long-term maintenance plans. Daniel Karrenberg’s NSD comparison offer and the memory footprint discussion are recorded in section E. Section F covers the contemporaneous presentation of EURid’s YADIFA.

It’s Knot DNS!
Slovák’s November 3, 2011 presentation documents the 2009 project start, two additional developers in 2010, September 2011 limited release and November beta, scope and protocols, reconfiguration, original read-copy-update design, benchmark hardware and datasets, and rollout plans.

CZ.NIC přichází s vlastním DNS serverem. Významně tak přispívá ke stabilitě internetu
Launch announcement identifies Surý as head of research, documents the rationale for diverse independent implementations at the root and TLD level, BIND/NSD design goal, prospective users, beta availability, C, GPLv3, threading and reported rate of around 200,000 queries per second. Site timestamp is November 2 but dateline and conference slides are November 3.

RIPE Programme Committee | RIPE 64
Surý’s section dates CZ.NIC hiring as CTO to 2005, new registry deployment to 2007, his work on the .CZ DNSSEC launch to 2008, and appointment to head CZ.NIC Labs to 2009.

RFC 9499: DNS Terminology
Authoritative and recursive roles, caching, referral and zone terminology, AXFR and IXFR.

RFC 2182: BCP 16: Selection and Operation of Secondary DNS Servers
Best Current Practice on selecting secondaries and the significance of geographical and network diversity.

Knot Resolver
CZ.NIC’s other Knot project is a caching resolver and identifies Knot DNS as the distinct authoritative server.

February 2012 – knot-dns-users – lists.nic.cz
Slovák announces the first stable version of Knot DNS and links the 1.0.0 archive.

Annual Report of the CZ.NIC Association
English 2012 report, section 8.2, says Knot DNS 1.0 added root-zone support, 1.1 brought speed and incremental-transfer improvements and Knot DNS was serving .CZ by then.

Introduction — Knot DNS 3.6.2 documentation
Authoritative-only scope, parallel operation, management while serving, full and incremental transfers and automatic DNSSEC signing features.

Generování a podepisování zóny .CZ prošlo servisní prohlídkou, původní součástky nahradil systém Knot DNS
Technical director Zdeněk Brůna’s first-person account of replacing BIND and local signing scripts with Knot on the hidden primary in late April 2021. Documents the phased deployment, NSD restart and temporary withdrawal of affected prefixes, isolated resolver test of DNSSEC and the rollback plan.

2017 Retrospective
Surý was hired from CZ.NIC in September as Director of DNS Development. Refactoring and steps towards opening the bug database also appear in the annual report.

The ISC Team
Staff directory lists Surý as Director of DNS Engineering and Michał Kępień as BIND 9 QA Manager and Software Developer.

About Us
Describes the institutional origin, independent funding and development role and Berkeley predecessors.

The History of BIND
Names ISC founders, early BIND 9 developers, Andrews and Hunt as maintainers in the BIND 10 years, 2014 return of effort to BIND 9, July 2017 bug database and February 2018 GitLab opening, query_find complexity and other original refactoring targets.

Announcing the release of BIND 9.0.0
Contemporary first general availability notice, architectural rewrite, IPv6, DNSSEC, portability, multiprocessor support and views.

BIND 9
BIND roles and deployments across root and TLD publishing, internal and external enterprise zones, hosting and large recursive services.

25 years of BIND 9 architecture
Petr Špaček explains BIND 9.16’s partial switch to libuv and 9.18’s fuller adoption, and old database locks, architecture and hardware context.

2025 BIND 9 Development Report
Development and QA personnel, Kępień as QA lead, and the QP-trie database as default in 9.20 with a configurable old database fallback.

Meet an ISC Engineer – Michal Nowak!
Nowak’s individual QA work including system and unit test debugging, stress tests, packaging coordination and CI.

Questions and Answers about BIND 9 Quality Assurance
Kępień on cross-platform builds and unit and system tests, sanitizers, 70 jobs per merge request revision at the time, scheduled checks, fuzzing, performance and value of actionable operator reports.

Performance Improvements in BIND 9.20 in Authoritative Configurations – December 2025
Published benchmark tables show throughput improvement for most profiles, regression for root-zone test, 28% memory increase in million-zone scenario, cause and subsequent lock pool change.

BIND 9.20 Resolver performance compared to 9.18
Compares cold and warm cache, different levels of traffic, CPU, memory and latency. Strong reduction in timeouts in heaviest-load cold-cache case and similar memory use at steady state.

Open-Source Release Engineering — Streamlining the release process from git
Surý’s October 22, 2025 RIPE 91 slides on components of a release and the actual QA checklist, including tests, backports, configuration compatibility, notes, tags, release archives, signatures, and publication.

Streamlining the release process from the git
ISC’s landing page identifies Surý as speaker and links the RIPE 91 talk, slides and recording.

RFC 8080 — Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
Surý and Robert Edmonds, February 2017, DNSKEY and RRSIG encodings and lengths, assignments 15 and 16, and examples.

RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
The earlier algorithm definitions and parameter choices that RFC 8080 maps into DNSSEC.

RFC 4033 — DNS Security Introduction and Requirements
DNSSEC data origin authentication, authenticated denial, chain of trust, and lack of confidentiality.

RFC 4035 — Protocol Modifications for the DNS Security Extensions
Resolver validation procedure, secure and insecure outcomes and absence of supported algorithm in an authenticated DS RRset.

RFC 7766 — DNS Transport over TCP – Implementation Requirements
UDP response size limits and truncation and the role of TCP for larger signed responses.

RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
Paul Wouters and Surý, June 2019, historical Ed25519 and Ed448 implementation guidance and Ed25519 adoption caveat.

RFC 9904 — DNSSEC Cryptographic Algorithm Recommendation Update Process
November 2025 publication by Wes Hardaker and Warren Kumari, explicitly obsoletes RFC 8624, shifts recommendation columns to IANA and distinguishes use from implementation.

Domain Name System Security (DNSSEC) Algorithm Numbers
Current Ed25519, Ed448 and ECDSA P-256 with SHA-256 recommendations across use, implementation, signing and validation.

RFC 6781 — DNSSEC Operational Practices, Version 2
Key storage and roles, parent DS publication, cache timing, conservative algorithm rollover and emergency planning.

RFC 7873 — Domain Name System (DNS) Cookies
DNS COOKIE extension flow, client and server role, off-path protection, response sizing, BADCOOKIE replacement and TCP retry.

RFC 4786 — Operation of Anycast Services
Defines anycast as one service address present in several locations, with routing determining the serving instance.

RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
April 2021 author list and update to RFC 7873, shared format and secret, tag, age limits, rotation stages, privacy guidance, on-path limits, test vectors and Prague prototype acknowledgments.

RFC 9432 — DNS Catalog Zones
July 2023 coauthorship and affiliations, schema, transfer and provisioning roles, versioning, security, group properties, clashes, removal, change of ownership, reset, catalog expiry, malformed and empty catalog implications.

A short introduction to Catalog Zones
BIND versions 1 and 2 and manual configuration and transfer behavior.

Catalog Zones (RFC 9432)
PowerDNS supports producing and consuming schema version 2, consuming version 1, and documents limits on group templates and custom extensions.

Trusted Community Representatives
IANA’s current roster lists Ondřej Surý, CZ, as Recovery Key Share Holder 2 (2010–), and separately identifies officers and other recovery holders.

Root KSK Ceremony 1
June 16, 2010 in Culpeper; first ceremony objectives and its published materials.

ICANN DNSSEC Key Ceremony Scripts
Participant page lists Surý as RKSH2; handover and ledger on pp. 15–16 describe the custody check, receipt and witness, and prologue details the common clock and access controls.

DNSSEC for the Root Zone
July 2010 IETF 78 deployment presentation, lists Surý among the original recovery holders and records their enrollment at Ceremony 1.

DNSSEC Project Archive
Timeline records June 16 and July 12 ceremonies and July 15, 2010 anchor publication and signed root availability.

DNSSEC Practice Statement for the Root Zone KSK Operator
Ninth edition effective October 7, 2026. §§1.3, 2.2, 4.1–4.2, 4.4–4.5, 5.2, 5.4, 6 and appendix. PTI and Verisign roles, signing hierarchy, anchor publication, HSM access, three-of-seven signing activation, five-of-seven SMK recovery, encrypted backups and separate access roles, geography and redundancy, emergency rollover and audit records.

DNSSEC Practice Statement for the Root Zone ZSK Operator
Verisign generates the ZSK and signs the root zone. Distinguishes KSK-signed key set from ZSK signing.

Trusted Community Representative Roles
Officers bring box keys and witness regular ceremonies. Recovery holders keep credentials for widespread production failure, provide annual evidence and attestation, maintain travel eligibility, undergo periodic checks and validation, and transfer custody on retirement.

Criteria for Trusted Community Representatives
Independence from root management organizations, integrity, DNS knowledge, and geographic and cultural breadth.

Root KSK Ceremony 53 Day 1
April 25, 2024 Culpeper ceremony objectives included Q3 ZSK signing, replacing holders 1 and 6 and reissuing credentials. Separate public broadcast and formal audit materials, scripts, footage, software and hardware logs.

Audit Programs
SOC 3 controls for security, availability and processing integrity of root KSK operations.

RFC 4253: The Secure Shell (SSH) Transport Layer Protocol
Host key and proof of private key possession in key exchange, and client decision about server identity.

RFC 4252: The Secure Shell (SSH) Authentication Protocol
SSH user authentication runs over the transport layer and is distinct from authenticating the server’s host key.

RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
Schlyter and Griffin, January 2006. §§2–4 define record and key/algorithm match, validation/secure transport, local trust policy, publication path, revocation if required, and search-path risks.

RFC 6594: Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records
O. Sury, CZ.NIC, April 2012. §§3–7 assign ECDSA algorithm 3 and SHA-256 fingerprint type 2, define preference and rejection over SHA-1 and give examples.

DNS SSHFP Resource Record Parameters
Separate public key and hash registries; Ed25519 added by RFC 7479 and Ed448 by RFC 8709.

ssh_config(5)
VerifyHostKeyDNS default no and behavior of yes and ask with secure and insecure fingerprints, and interaction with StrictHostKeyChecking.

ssh-keygen(1)
The -r option prints an SSHFP record for the given name using the specified public key.

OpenSSH 9.9p2 release notes
February 18, 2025 release; fixes CVE-2025-26465, on-path server impersonation when VerifyHostKeyDNS enabled in OpenSSH 6.8p1–9.9p1.

Root DNSSEC KSK Ceremony 53-1
Proposed script, participant roles page identifies Ondrej Filip as CO3 and Ondřej Surý as RKSH2.

PHP LTS by Freexian
Identifies Freexian as operator with Surý’s help. The availability table defines a platform as a PHP and operating system release pair and distinguishes security-supported and unsupported available packages. The tier table publishes included email support, charges for extra hours, and mirror and sharing provisions.

Frequently Asked Questions about PHP LTS
Explains the private archives, scope tied to subscribed platforms, distinction between Surý’s public archive best effort and direct commercial support, and monitoring, triage, backporting and regression testing. Also describes customer sharing provisions and compares the co-installable runtime and extension packaging with Debian.

2024 Open Source Software Funding Report
Full report by Sam Boysel and Frank Nagle, with GitHub and Linux Foundation participation. Results give the 86 percent employee-labor share among 159 respondents reporting contribution figures, the $7.7 billion extrapolation and its assumptions, and limits on reporting labor hours.

The 2024 Tidelift State of the Open Source Maintainer Report
Introduction describes recruitment and 437 responses. Pages 4–6 distinguish self-described unpaid hobbyists and the association with co-maintainers without claiming causality. Pages 8 and 13–15 cover paid time and the alternate question in which 47 percent identified no payment.

The Linux Foundation’s Core Infrastructure Initiative Announces New Backers, First Projects to Receive Support and Advisory Board Members
May 2014 announcement of funding for two full-time OpenSSL core developers, separate funding for the Open Crypto Audit Project audit, and broader permissible categories such as computing and test infrastructure.

Monthly report about Debian Long Term Support, February 2026
Separate Debian LTS team reports 20 paid contributors, links to individual reports and Debian LTS advisories, and notes contributions to newer Debian versions.

Provenance
Approved SLSA 1.2 overview distinguishing source and build provenance and identifying build provenance as a way to track a build output to the source used.

Build: Provenance
Approved SLSA 1.2 specification for build definition, external parameters, known resolved dependencies, builder identifier and output subject. Explains an exact commit as a resolved dependency for a repository reference.

Definitions
Defines reproducible builds by independent recreation of identical specified artifacts given source, build environment and instructions. Describes attributes such as versioned dependencies, configuration flags and locale.

deb-buildinfo(5)
Debian build information format documentation, including architecture, checksums, build environment and installed build dependencies.

snapshot.debian.org
Lists Debian archives and explicitly describes retrieval by date and version.

5. Managing Packages
Debian Developer’s Reference distinguishes non-maintainer upload, package salvaging, and collaborative or team maintenance. Includes notice to existing maintainers, source access, designated maintainers/uploaders, and caveats against indiscriminate listing of uploaders.

Maintaining ownership continuity for your organization
GitHub’s recommendation to have at least two organization owners, and description of the scope of ownership.

GitHub Account Recovery Policy
Explains two-factor account recovery options and inability of staff to restore access outside the published recovery methods. Applies to GitHub and is used as an illustration of recoverability.

Cover image: Photograph from Ondřej Surý’s official GitHub profile, adapted to a 16:9 aspect ratio.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.