fix: install security provider before tls use

[Jasonvdb]

Closes #1425

This PR installs the bundled BouncyCastle security provider as the first step of App.onCreate, so swapping security providers can no longer race paykit's first TLS connection at start-up.

I found this while testing #1399. It is older than that PR: master fails at the same rate.

Description

• Fixes paykit refusing every TLS connection for the rest of the session after most cold launches made while signed in to a Pubky profile. The provider swap left a window of about a second in which no provider offered the "BKS" keystore. When paykit's first HTTPS call landed in that window, its certificate verifier class failed to initialise, and Java never retries a class whose initialiser failed
• Moves the swap into Crypto.installSecurityProvider() and calls it before super.onCreate() in App, where Hilt has not built anything yet, so the swap finishes before any service can open a connection. Crypto's constructor still calls it, and that second call finds BouncyCastle in place and does nothing
• Builds the replacement provider before removing the old one, so the gap with no "BC" provider drops from about a second to under 1 ms

Root cause

• Crypto's init runs on the main thread when MainActivity's ViewModels are created. It removed Android's built-in "BC" provider and only then constructed BouncyCastleProvider(), which took 0.8–1.1 s on the emulator. During that time no provider offered "BKS".
• Meanwhile App.onCreate → super.onCreate() injects PubkyAuthHandlerRegistrar → PubkyRepo.init → PaykitSdkService.initialize(), which launches republishIdentityIfNeeded(). That makes paykit's first HTTPS call on an IO thread 1.6–2.8 s after process start.
• Paykit bundles rustls-platform-verifier. The static initialiser of org.rustls.platformverifier.CertificateVerifier starts with KeyStore.getInstance(KeyStore.getDefaultType()), and the default type on Android is "BKS". Inside the window it throws KeyStoreException: BKS not found, the class is marked as failed for the whole process, and every later paykit certificate check throws NoClassDefFoundError until the app restarts.

Measurements

These were online cold launches on an Android emulator while signed in to a Pubky profile. A launch counts as broken when logcat shows BKS not found or the NoClassDefFoundError.

Build	Broken launches
master 6ba44a4	9/10
master 6ba44a4 with timing logs	8/8
#1399	13/15
master 6ba44a4 with this change	0/10

• 0/10 against 9/10 gives Fisher's exact p ≈ 1e-4.
• All 8 failures in the logged runs fell inside the removal window.
• With this change the provider is built 1.0–1.4 s after process start, and the removal and insertion happen in the same millisecond.
• This branch is based on 907f546. There Crypto.kt is unchanged and App only gained SubscriptionClockOffsetSync, but the change has not been re-measured on that base.
• Time to first frame stayed in the same range: 6.0–7.5 s with the change, against 6.8–8.1 s for the timing-log build. The constructor already ran on the main thread before the first frame; it now just runs earlier.
• Process starts with no UI and no push, such as a widget refresh or a worker, now also pay that cost in App.onCreate. Push starts already did, because FcmService injects Crypto.

Security

• Only the order changes. Certificate verification runs the same code with the same trust roots.
• Today's failure fails closed: TLS is refused, never weakened. This PR deliberately does not catch-and-retry, skip or soften verification, or switch paykit to bundled roots.
• A guard inside paykit would have to cover every native library that uses the platform verifier. Doing the swap first in App covers all of them.

Out of Scope

• Crypto.kt: putting the full BouncyCastle first in the global provider list changes JCA choices for the whole process. For example, paykit's CertPathValidator.getInstance("PKIX") resolves to BouncyCastle after the swap. The cleaner long-term fix is a private BouncyCastleProvider instance passed explicitly to Crypto's getInstance calls for key generation, key factories and ECDH. The Cipher calls should get it too: without BouncyCastle first they would resolve to Conscrypt, which might reject Blocktank's 16-byte GCM IVs. That needs its own tests, so it is left for a follow-up.

Design

N/A — no UI changes.

Preview

N/A

QA Notes

Journeys

N/A — not drivable; see Manual Tests.

Manual Tests

• Install, sign in to a Pubky profile, then cold-launch the app 10 times while online → logcat shows no BKS not found and no CertificateVerifier error on any launch — repeated cold launches checked through logcat are not in Capabilities

Automated Checks

• updated CryptoTest.kt — installSecurityProvider adds BouncyCastle when no BC provider exists, replaces an outdated BC provider at position 1, and leaves the installed provider in place on later calls, including the one from Crypto's constructor

[ovitrif]

@Jasonvdb is this critical for next release? it kinda seems so to me, pls db check and lmk.

it's currently on 2.6.0 milestone because I consider(ed) it critical

[Jasonvdb]

@ovitrif Yes, I'd treat it as critical for 2.6.0. On master, Paykit refused every TLS connection for the rest of the session after 9 of 10 cold launches while signed in to Pubky (emulator, master 6ba44a4). With this change it was 0 of 10. Once it fails, contact payments and Pubky profile reads stop working until the app is restarted. It fails closed (TLS is refused, never weakened), so it isn't a security hole, but it's a broken feature for most signed-in launches. Caveat: I only measured on an emulator. On a fast phone the race window may be smaller. The fix only changes the order of security provider set-up at start-up.

[greptile-apps]

Confidence Score: 4/5

[Critical risk] Installs cryptographic security provider before TLS initialization.

The PR appears safe to merge, with a non-blocking improvement needed in the test cleanup.

Findings

1.  Cleanup preserves changed settings ▶

Summary

Installs BouncyCastle before App.onCreate calls super.onCreate(), so injected services start after the provider swap.

• Builds the replacement before removing Android’s provider.
• Keeps later installation calls unchanged and adds provider tests.
• The new test cleanup should save the original provider before constructing Crypto.
• Jasonvdb acknowledged the extra background-start cost and deferred changing global provider priority until separate tests are available.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["App.onCreate"] --> B["Crypto.installSecurityProvider"]
    B --> C{"Bundled provider installed?"}
    C -->|Yes| D["Leave provider unchanged"]
    C -->|No| E["Build and install replacement"]
    D --> F["super.onCreate"]
    E --> F
    F --> G["Hilt builds services"]
    G --> H["Services can open TLS connections"]

Loading

_{Reviews (1) · Last reviewed commit: "chore: add changelog fragment"}

[github-actions]

Regtest APK

Built from a1478a1 (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[Jasonvdb]

@ovi-reviewer review

[ovi-reviewer]

Suggestion: 👍 Approve

Review: diff 4 files.
This fixes an Android provider startup race. iOS uses CryptoKit and secp256k1 without Java provider changes. iOS already uses the same Paykit rc56 through synonymdev/bitkit-ios#823, so it needs no matching change.

Findings:
2 inline (1 MEDIUM, 1 LOW)

QA:
Tests queued.

Replies:

@Jasonvdb: Yes, I’d treat it as critical for 2.6.0. (comment)

The reported session-long TLS failure blocks contact payments and Pubky profile reads, so this belongs in 2.6.0.

@Jasonvdb: @ovi-reviewer review (comment)

The review is complete. The ten online cold launches still need device testing.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

@ovi-reviewer review

[ovitrif]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T18:11:33.782047Z	a1478a1	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: a1478a18a6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ovi-reviewer]

Suggestion: 👍 Approve

Reaudit: diff 2 files.
No new findings; the rest is in the review.
This delta restores an Android startup note and adds an Android Hilt regression test; no shared protocol or iOS behavior changes.

QA:
Tests running.

Replies:

@chatgpt-codex-connector: Codex Review Summary (comment)

That status concerns the separate Codex review. This reaudit is complete; the cold-launch check still awaits device testing.

---

Reviewed by gpt-6.1-sol-medium via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovi-reviewer]

Verdict: ✅ Approve

Tests for the review: Test 1 passes.

QA:
Tested on Android 15 emulator.

🟢 Test 1

Test 1

Ten online cold launches while signed in produced no BKS not found or CertificateVerifier errors.

1.mp4

Checked Manual Test 1 in the PR description.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

utAck