3.6.3-33 — SPIFFE v1/v2 URI-SAN principal extraction (DEPEND-89172)

Cut directly from feature branch sanju98/spiffe-v2-auth (7 commits ahead of branch-3.6 / 3.6.3-32) for early validation, ahead of PR #142 merge.

Adds server-side SPIFFE URI-SAN based client-identity extraction to X509AuthenticationUtil, always-on (not gated behind a feature flag):

• v2 (spiffe:///v2/): principal is the full path-after-/v2/ (the ILM UID).
• v1 workload (spiffe:///v1/wl/): principal is the bare app-name.
• v1 workload (spiffe:///v1/application/ or /v1/airflow/): principal is the full path with type prefix retained.
• User-identity URIs (/v/user/...) are never promoted to a service principal.
• Percent-encoded paths are rejected (defense-in-depth against %2F-smuggling and %75ser user-bypass).

See #142 for full context, review discussion, and test coverage (43 SPIFFE-related tests across X509AuthTest, X509SpiffeAuthIntegrationTest, ZkClientUriDomainMappingHelperTest).

3.6.3-32 — TLSv1.3 server support + remove default cipher overrides

Backports two upstream Apache ZooKeeper TLS fixes to branch-3.6 to resolve incident-12090 (TLS 1.3 client handshake failures against the LinkedIn fork's TLS 1.2-only server).

Changes

• ZOOKEEPER-4415 — server-side TLSv1.3 support. X509Util.defaultTlsProtocol() picks TLSv1.3 as the default SSLContext protocol when the running JDK supports it; SSLContextAndOptions.getEnabledProtocols() returns the JDK's default enabled-protocols list when ssl.enabledProtocols is unset.
• ZOOKEEPER-4912 — remove default cipher overrides. SSLContextAndOptions.getCipherSuites() returns null when ssl.ciphersuites is unset, letting the JDK supply its own default cipher list at SSLEngine construction time. Eliminates the JDK ↔ MP cipher-list drift footgun that caused the original incident-12090 Unsupported CipherSuite: TLS_CHACHA20_POLY1305_SHA256 failure on JDK 11.0.8.

Behaviour after this release

• Default server protocol: TLSv1.3 on JDKs that support it (with TLSv1.2 still in the enabled list), TLSv1.2 otherwise.
• Default cipher set: whatever the JDK chooses. No more hardcoded list in either the fork or downstream MPs.
• Per-deployment overrides via ssl.enabledProtocols / ssl.ciphersuites continue to work exactly as before.

Full PR

#143 — includes test plan, local validation evidence across client JDKs 8/11/17/21, performance comparison at ~10k ops/sec (≤1 % delta vs TLSv1.2), and PR-thread discussion.

Diff vs 3.6.3-31

Only PR #143. (Laxman's PR #140 already shipped in 3.6.3-31.)

Downstream

After Auto-ELR 2350 picks this up (~1h), bump product-spec.json in linkedin-multiproduct/zookeeper-server from 3.6.3-31 to 3.6.3-32 and roll through the standard sandbox-blr → ei4 → corp → prod pipeline.

3.6.3-31 — skip-snapshot leader election optimization (incident-10033 mitigation)

First production-bound release on branch-3.6 since 3.6.3-29 (Feb 2025). Single feature: an opt-in flag that lets Leader.lead() skip the synchronous startup snapshot in ZooKeeperServer.loadData(), mitigating incident-10033.

Note on 3.6.3-30: the 3.6.3-30 tag was an intentional no-op release (same content as 3.6.3-29) cut earlier today as a release-pipeline dry-run — used to validate that the 15-month-dormant release workflow (ci-jfrog-workflow.yml), JFrog publish credentials, and the ELR admission path were all still healthy before shipping an actual fix. It is not a production artifact; consumers should pin 3.6.3-31.

What's new

PR #140 — Skip synchronous startup snapshot during leader election

Motivation. Incident-10033 (4m47s outage on the prod Kafka ZK ensemble, 15M znodes). The synchronous snapshot at ZooKeeperServer.loadData() took 34–43s on production hardware, exceeded the 40s initLimit, and triggered a cycle of failed leader elections. The leader rewrote the identical snapshot four times before success came via DIFF sync (~55ms). Projected outage duration with the fix enabled: ~1s.

Change.

• ZooKeeperServer.loadData(boolean skipSnapshot) — new overload that conditionally skips the startup takeSnapshot() call. The no-arg loadData() delegates to loadData(false) for backward compatibility.
• Leader.lead() — invokes loadData(self.isSkipLeaderStartupSnapshot()) at the start of the discovery phase.
• QuorumPeer.skipLeaderStartupSnapshot — new volatile field, controlled by the system property zookeeper.leaderElection.skipStartupSnapshot (default false). JMX getter/setter exposed.
• ZooKeeperServer.loadData(true) log line — emits Skipping startup snapshot (periodic snapshot will persist state). lastProcessedZxid: 0x<hex>, dead sessions cleaned: <N> for rollout-monitoring correlation in Observe Logs.

Safety rationale.

• killSession() cleanup is idempotent on recovery — the cleaned sessions don't reappear because heartbeat refreshes have already stopped.
• Follower sync uses the in-memory DataTree (Leader.startForwarding / LearnerHandler.syncFollower), not the on-disk snapshot file. Followers receiving SNAP sync get state from RAM regardless of whether the leader wrote a fresh snapshot.
• SyncRequestProcessor takes periodic snapshots after quorum forms; the txn log + the most-recent prior snapshot are always a valid recovery surface even if the leader crashes before the next periodic write.
• The same change pattern was applied in branch-3.4 by Flavio Junqueira (ZOOKEEPER-1558, 2013) and never ported to 3.5+. He noted the snapshot was "not strictly necessary for correctness, but convenient."

Test coverage. New tests in ZooKeeperServerTest, QuorumPeerTest, and Zab1_0Test validate the skip / no-skip paths and the default behavior. A regression-guard test (Zab1_0Test.testFollowerPathUnaffectedBySkipFlag) verifies the flag stays leader-path-only — the follower DIFF sync continues to ignore it. Full local surefire run (3,184 / 3,187 tests passing on Apple Silicon, ~28 min) verified the broader test surface.

Configuration

Property	Type	Default	Effect when true
zookeeper.leaderElection.skipStartupSnapshot	system property	false	Leader.lead() skips the synchronous takeSnapshot() in loadData(). Periodic snapshots via SyncRequestProcessor continue normally.

Settable via JVM flag (-Dzookeeper.leaderElection.skipStartupSnapshot=true) or via QuorumPeer.setSkipLeaderStartupSnapshot(boolean) (JMX-reachable; the field is volatile so cross-thread writes are visible to the leader thread).

Compatibility & migration

• Default behavior is unchanged. With the flag at its default of false, this release is observationally identical to 3.6.3-29 on the same hardware. Bumping the dependency does not require any flag flip.
• Wire protocol unchanged. No ZAB / Learner / Observer changes.
• No restart semantics change beyond the optional skip. Followers, observers, and clients are unaffected.
• Rollback is a single cfg2 / JVM-property unset + restart. No binary downgrade needed — running servers with the flag unset behave exactly as 3.6.3-29.

Rollout guidance

Recommended phased enablement (covered in detail in the workspace plan):

1. EI (ei-ltx1 d2 + kafka) — 1 week.
2. Production non-critical (1 ensemble in prod-ltx1) — 2 weeks.
3. Production Tier0 non-Kafka non-D2 (e.g., shared, espresso) — 1 week.
4. Production Kafka (prod-ltx1 → lor1 → lva1) — 1 week per fabric. Highest payoff per incident-10033.
5. Production D2 (prod-ltx1 → lor1 → lva1) — 1 week per fabric.

Per-host verification during rollout — search Observe Logs for log.message:\"Skipping startup snapshot\" on flag-enabled hosts after any leader election; each elected leader should produce exactly one such line including its lastProcessedZxid.

Pre-release flag

Marked as --prerelease until EI Phase A passes its hold window. Promote to stable via:

gh release edit 3.6.3-31 --repo linkedin/zookeeper --prerelease=false

Acknowledgments

• @Sanju98 — review comments that drove the volatile correctness fix, the JMX-visibility analysis, and the lastProcessedZxid log enrichment.
• @adityaagg09 — second review + CODEOWNERS approval. Also enabled the EMU access changes that unblocked the merge.

Full changelog

3.6.3-29...3.6.3-31: 3.6.3-29...3.6.3-31

(3.6.3-30 is a no-op dry-run release; the actual change against the prior stable is the single squash commit 556551a3a.)

3.8.4-0

This is the first release,
We have upgraded the zookeeper open source version from 3.6.3 to 3.8.4,

Here is the list of all the detailed changes which we have imported :- https://docs.google.com/spreadsheets/d/1B8G3-VmnqolrxBeNAI2XptkVvy9-Y8D7B0TnYWp5zXg/edit?gid=85047633#gid=85047633

Here is the list of detailed analysis done :- https://docs.google.com/document/d/1Lo0YpYOrjmYUeCIV8zuiQApHL2mU1az1TgkcsiT-6p4/edit?tab=t.0#heading=h.8xbv1plslh0u

3.6.3-30 — pipeline-validation cut (no-op)

Pipeline-validation release — no code changes vs 3.6.3-29.

This release is cut from the same commit as 3.6.3-29 (43b5792355). It exists to validate that the ci-jfrog-workflow.yml GitHub Action is still healthy, JFrog publish credentials are valid, and the end-to-end fork → JFrog → ELR → MP-bump runbook works ahead of the next functional release (the TLSv1.3 + cipher-default backport in #143).

Changes vs 3.6.3-29: none. POM version bump only.

Do not consume in production MPs. Use 3.6.3-29 (or the upcoming 3.6.3-31 once #143 lands).

3.6.3-29

What's Changed

• Log remote socket address when we have auth fail by @abhilash1in in #124

Full Changelog: 3.6.3-28...3.6.3-29

3.6.3-28

What's Changed

• add ephemeral node creation throttled log message by @GrantPSpencer in #119
• Fix checkstyle error by @abhilash1in in #121
• Fix CI workflows by @abhilash1in in #122
• Fix CPP Unit Tests by @abhilash1in in #123
• ZOOKEEPER-4276. Serving only with secureClientPort fails by @abhilash1in in #120

Full Changelog: 3.6.3-27...3.6.3-28

Release 3.6.3-27 with ephemeral znode throttling

What's Changed

• Fix the build for branch-3.6 by @desaikomal in #115
• Fixed the build issue by @desaikomal in #116
• Limit the number of ephemeral nodes a session can create by @GrantPSpencer in #118

New Contributors

• @desaikomal made their first contribution in #115
• @GrantPSpencer made their first contribution in #118

Full Changelog: 3.6.3-26...3.6.3-27

Release 3.6.3-26 with logback support

What's Changed

• Use logback instead of log4j

Full Changelog: 3.6.3-25...3.6.3-26

Release 3.6.3-25 with new x509 ACL features

What's Changed

• Add allowedClientIdAsAclDomains property by @PapaCharlie in #114
• Add option to log but not enforce connection filtering, reset proposal stats through Admin server API by @abhilash1in in #112

New Contributors

• @PapaCharlie made their first contribution in #114

Full Changelog: 3.6.3-24...3.6.3-25