CockroachDB 1.0.2 carries a Go cryptography fix into the database

A database's security can depend on arithmetic inside the language runtime used to build it. CockroachDB 1.0.2, released June 15, moves to Go 1.8.3 to include a security fix affecting elliptic-curve certificates, as well as a panic fix. The contemporary notes make the runtime version part of the database maintenance update.

That matters even when no SQL authentication setting changes. Certificate processing uses code beneath the SQL interface, and a fixed implementation has to reach the deployed database executable. Updating application queries cannot repair a flaw in the runtime's cryptographic arithmetic.

I consider this part of the cost of operating a database binary. Distributed SQL adds its own protocols, but its transport security still depends on the cryptographic implementation it incorporates. A database maintenance release is one way those upstream corrections reach the running service.

The upstream issue is a carry bug in P-256

The Go project's P-256 issue, opened April 19, describes a carry bug in the x86-64 implementation. Cloudflare reported the problem, and the report's author reproduced it against BoringSSL before checking a supplied correction. This is a concrete arithmetic defect, not a claim that elliptic-curve certificates as a category are unsuitable.

The original issue also qualifies exploitability. It says the defect is not obviously exploitable while declining to rule out an attack. That wording supports treating it as a security correction without inventing a demonstrated certificate forgery or an active exploitation campaign.

CockroachDB's release notes identify the affected certificate use and the fixed Go version included in 1.0.2. The relevant deployment action is therefore adopting the database build that includes the correction. A machine's separately installed Go compiler does not change code already incorporated into a previously built database executable.

The distinction between upstream fix and downstream adoption is useful. The language project can correct its implementation while deployed services continue using binaries built earlier. This maintenance release closes that delivery gap for the distributed CockroachDB artifacts.

Prepared statements must fail when their assumptions expire

The same release fixes prepared statements invalidated by schema changes. Such a statement now returns an error instead of an incorrect result. That is a correctness boundary between a statement's earlier preparation and the schema under which somebody later executes it.

A prepared statement preserves work based on the database structure it observed. A schema change can make those assumptions unusable. Returning an error lets the caller recognize that the earlier preparation no longer describes a valid execution. An incorrect result would conceal the disagreement behind an apparently successful query.

The notes also make timestamp parsing consistent between prepared and non-prepared statements. Prepared execution should not silently give a timestamp another interpretation merely because the client chose that protocol path. These fixes concern meaning across execution modes, separate from the runtime security update.

I prefer an explicit invalidation error to a plausible-looking result computed under obsolete assumptions. PostgreSQL-compatible clients often use prepared statements as ordinary infrastructure. Their use should not require accepting a weaker result-correctness contract during schema changes.

Pagination and index joins receive result fixes

Version 1.0.2 corrects several OFFSET defects, including incorrect results and a panic when the clause appears without LIMIT. It separately fixes LIMIT behavior in index joins and DISTINCT with omitted columns. These entries describe affected query forms, not merely a collection of crashes.

That distinction matters for application impact. A crash produces an obvious failure, while an incorrect result may look like a legitimate empty page, shortened result set, or duplicate elimination outcome. The release gives concrete SQL constructs that identify where result semantics changed.

Very large decimal values also receive a decoding fix. Together, these corrections show why a maintenance release can matter to applications that do not use the certificate type named in the security entry. The binary contains both the runtime update and repairs to existing SQL behavior.

Compatibility and cluster repair remain explicit

BEGIN now accepts the READ WRITE modifier for compatibility with Go's lib/pq driver. The release note presents that as accepted transaction syntax. It should not be confused with a new claim that arbitrary PostgreSQL transaction options are supported.

The replica allocator also stops removing replicas from a down node when no live node can receive them. This changes a repair decision under constrained cluster conditions. Recognizing that a replica is unavailable does not establish that the system has somewhere suitable to replace it.

Backup URLs are sanitized before being stored in the system jobs table, and startup logging includes more node configuration detail. These changes affect the information retained by operational facilities. For this release, the security and correctness scope spans the incorporated Go runtime, prepared execution after schema changes, and ordinary query forms whose previous results could be wrong.