Skip to content

DFLOW-XXX - Add Windows Ruby certificate bundle support#12

Closed
RaniLinkov wants to merge 1 commit into
mainfrom
feature/DFLOW-97-ruby-windows
Closed

DFLOW-XXX - Add Windows Ruby certificate bundle support#12
RaniLinkov wants to merge 1 commit into
mainfrom
feature/DFLOW-97-ruby-windows

Conversation

@RaniLinkov

@RaniLinkov RaniLinkov commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

@RaniLinkov RaniLinkov closed this Jun 23, 2026
@RaniLinkov RaniLinkov deleted the feature/DFLOW-97-ruby-windows branch June 23, 2026 11:04
RaniLinkov pushed a commit that referenced this pull request Jun 24, 2026
@akushsky @claude @RaniLinkov
DFLOW-152 - JVM client setup (macOS)
b2cc3f6 
Adds a macOS client-side installer + validator that wires a corporate CA
into the JVM trust path so Maven / Gradle / sbt / Apache Ivy traffic
redirected through package-reroute validates correctly. JVM trust only —
does not configure Node/npm/Python and does not touch Docker credentials.
Pair with install_certs_macos.sh if you need those flows.

Based on the published research wiki (DFLOW-136):
  https://jfrog-int.atlassian.net/wiki/spaces/RTFACT/pages/2440101931

Sibling to DFLOW-150 (Linux). Single path on macOS — there is no
update-ca-trust fork because KeychainStore is broken per JDK-8321045:

  1. Build a per-user JKS truststore at
     ~/Library/Application Support/JFrog/package-route-jvm/truststore.jks
  2. Write a per-user LaunchAgent at
     ~/Library/LaunchAgents/com.jfrog.package-reroute.jto-env.plist
     calling `launchctl setenv JAVA_TOOL_OPTIONS=…` at RunAtLoad
  3. Bootstrap the agent into `gui/<uid>` so Dock-launched IDEs
     (IntelliJ, JetBrains Toolbox, `open -a …`) inherit the env var

The ~/.zshrc / ~/.bash_profile shortcut is deliberately NOT touched —
verified in the research wiki to silently fail for GUI-launched IDE
builds.

Files:
  install_certs_jvm_macos.sh              Installer (~540 lines).
  validate_certs_jvm_macos.sh             Companion validator.
  _jvm_macos_paths.sh                     Shared constants sourced by both.
  testing/test_install_certs_jvm_macos.sh 12-invariant smoke runner.
  .github/workflows/ci.yml                New test-macos-jvm job.
  README.md                               New "macOS (JVM)" section.

Hardening fixes folded in from a round of pr-review-toolkit review (5
agents, 21 findings: 5 Critical + 13 Important + 3 Minor):

  Critical:
  - validate_pem leaf-cert (CA:FALSE) check now works on stock macOS
    LibreSSL. The previous `openssl x509 -ext` flag is OpenSSL 3.x-only;
    LibreSSL silently failed → leaf certs accepted as trust anchors.
    New path parses `-noout -text` output (portable across both).
  - chown failure capture at both call sites (JKS dir + plist).
    Under --all-users a silent chown would leave root-owned plists in a
    user's ~/Library/LaunchAgents/, which launchd silently refuses to
    load — exactly the phantom-success the project bans.
  - --cert-name semantics clarified in constants file + --help. The
    previous "LaunchAgent label suffix" claim was wishful thinking; the
    flag is alias-cosmetic only.
  - Test runner docstring rewritten (cleanup runs only on positive
    cases) and the iter_all_users "mirrors install_certs_macos.sh"
    claim corrected (it's a stricter filter, not a mirror).

  Important:
  - get_single_target_user filter+order matches install_certs_macos.sh
    (SUDO_USER → /dev/console → logname; rejects loginwindow pseudo-user).
  - get_user_home eval-on-username fallback replaced with dscacheutil.
  - bootstrap_launch_agent retry bumped 5×100ms → 20×100ms to survive
    EDR exec latency; warn text no longer suggests a logout dance.
  - Validator --help documents the absence of --cert-name.
  - Validator final summary qualifies "All checks passed" with a WARN
    count so a green exit doesn't over-promise when launchctl getenv
    was skipped (no GUI session).
  - install_as_test_user / validate_as_test_user capture combined
    stdout/stderr to a tempfile; dump on UNEXPECTED exit only.
  - Smoke matrix gained 3 new invariants: --all-users iteration (#11),
    plist content validation via plutil -extract (#10), validate_pem
    warn-paths for 30-day-expiry and multi-cert bundle (#12).
  - Test #9 (launchctl getenv) now retries 20×100ms to mirror the
    installer.
  - CI workflow uses explicit `sudo env JAVA_HOME=… PATH=…` instead of
    --preserve-env, surviving future actions/setup-java renames. PATH
    includes /usr/sbin so chown is resolvable under sudo.

  Minor:
  - README requirements list names plutil/launchctl/dscl/stat.
  - README "five launch contexts" claim scoped to what the test
    actually verifies.
  - JKS_PASSWORD "not a secret" comment scoped to trustedCertEntry-only
    stores (PrivateKeyEntry would change the calculus).

Smoke matrix: 12/12 green locally on dev Mac, 12/12 green on CI
(Test (macOS JVM) job, macos-latest runner with Temurin 21).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
RaniLinkov added a commit that referenced this pull request Jun 25, 2026
@RaniLinkov @akushsky @claude
Dflow 140 jvm (#14)
6ebb49c 
* DFLOW-150 - JVM client setup (Linux)

Adds a Linux client-side installer + validator that wires a corporate CA
into the JVM trust path so Maven / Gradle / sbt / Apache Ivy traffic
redirected through package-reroute validates correctly. JVM trust only —
does not configure Node/npm/Python and does not touch Docker credentials.
Pair with install_certs_debian_ubuntu.sh if you need those flows.

Based on the published research wiki (DFLOW-136):
  https://jfrog-int.atlassian.net/wiki/spaces/RTFACT/pages/2440101931

Two lab-verified paths, auto-detected:

  Path A — update-ca-trust
    RHEL/Fedora/CentOS/Amazon-Linux when a JDK whose lib/security/cacerts
    symlinks to /etc/pki/ca-trust/extracted/java/cacerts is on PATH
    (Red Hat OpenJDK). Drops the CA into /etc/pki/ca-trust/source/anchors/
    and runs `update-ca-trust extract`. No env var.

  Path B — JKS + JAVA_TOOL_OPTIONS
    Everything else (Debian/Ubuntu, Amazon Corretto, Eclipse Temurin,
    SDKMAN, manual .tar.gz installs). Builds a JKS at
    /etc/ssl/package-route-jvm/truststore.jks containing only the customer
    CA; writes JAVA_TOOL_OPTIONS to /etc/environment plus the developer
    user's .bashrc/.zshrc. JDK-version-agnostic by construction.

Detection rule (detect_mode):
  1. No update-ca-trust on PATH                 -> Path B
  2. /etc/pki/ca-trust/extracted/java/cacerts absent -> Path B
  3. No `java` on PATH                          -> Path A (assumes Red Hat
       OpenJDK will follow via dnf; emits a loud end-of-run warning)
  4. `java`'s cacerts symlinks to RHEL store    -> Path A; else Path B

--mode java-tool-options / --mode update-ca-trust overrides detection.

Files:
  install_certs_jvm_linux.sh      Installer (mirrors install_certs_debian_ubuntu.sh patterns).
  validate_certs_jvm_linux.sh     Companion validator; subject-substring match.
  _jvm_linux_paths.sh             Shared constants sourced by both scripts so they cannot drift.
  testing/test_install_certs_jvm_linux.sh   Docker matrix runner (4 distros x 10 invariants).
  .github/workflows/ci.yml        New test-linux-jvm job runs the matrix runner.
  README.md                       New "Linux (JVM)" section with the full design + caveats.

Hardening fixes folded in from two rounds of pr-review-toolkit review:

  Critical:
  - --cert-name actually propagates to the Path B JKS alias and the validator
    accepts --cert-name so Path A's anchor file can be located when a
    non-default basename was used.
  - validate_pem rejects expired certs, leaf certs (CA:FALSE), warns on
    bundles (keytool -importcert -noprompt only imports the first cert).
  - install_via_update_ca_trust and validate_keystore_contains_subject
    capture keytool output explicitly; the previous pipefail+SIGPIPE
    pattern (... | grep -qi "$subject") silently turned real keytool
    failures into "subject not found" misdiagnoses AND real positive
    matches into false negatives.
  - validator detect_mode "both paths present" branch now routes the
    whole warn block to stderr; previously the warn lines leaked into
    the command-substitution capture and broke the case dispatch,
    yielding a silent exit-0 with NO checks run.

  Important:
  - validator FAILs (not OKs) when keytool is missing on the JKS path.
  - --all-users root check moved into parse_args (fast-fail exit 1).
  - update_user_shell_rc tracks RC_UPDATED and the final summary prints
    a loud WARNING when the per-user rc step was skipped.
  - --mode jto -> --mode java-tool-options for self-documenting CLI.
  - mktemp is -p $(dirname target) so `mv` is rename(2) (atomic), and an
    empty-awk-output check refuses to clobber /etc/environment.
  - --cert-name regex-validated to [A-Za-z0-9._-]+ to prevent path
    traversal in the anchor file path.
  - chown failure on the user's rc file captured + warned.
  - get_target_user verifies the picked username exists in /etc/passwd.

Smoke matrix (testing/test_install_certs_jvm_linux.sh): Ubuntu 22.04,
Debian 12, RHEL UBI 9, Amazon Linux 2023, in parallel. Per-container
invariants: positive install+validate, subject mismatch -> exit 1,
idempotent re-install (no duplicate lines/aliases), custom --cert-name
round-trips, path-traversal rejected, malformed PEM rejected, expired
CA rejected (skipped when openssl can't produce a verifiably-expired
test cert), leaf cert (CA:FALSE) rejected, forced --mode update-ca-trust
(Path A) on hosts with update-ca-trust, dual-artifact validator
regression test.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* DFLOW-152 - JVM client setup (macOS)

Adds a macOS client-side installer + validator that wires a corporate CA
into the JVM trust path so Maven / Gradle / sbt / Apache Ivy traffic
redirected through package-reroute validates correctly. JVM trust only —
does not configure Node/npm/Python and does not touch Docker credentials.
Pair with install_certs_macos.sh if you need those flows.

Based on the published research wiki (DFLOW-136):
  https://jfrog-int.atlassian.net/wiki/spaces/RTFACT/pages/2440101931

Sibling to DFLOW-150 (Linux). Single path on macOS — there is no
update-ca-trust fork because KeychainStore is broken per JDK-8321045:

  1. Build a per-user JKS truststore at
     ~/Library/Application Support/JFrog/package-route-jvm/truststore.jks
  2. Write a per-user LaunchAgent at
     ~/Library/LaunchAgents/com.jfrog.package-reroute.jto-env.plist
     calling `launchctl setenv JAVA_TOOL_OPTIONS=…` at RunAtLoad
  3. Bootstrap the agent into `gui/<uid>` so Dock-launched IDEs
     (IntelliJ, JetBrains Toolbox, `open -a …`) inherit the env var

The ~/.zshrc / ~/.bash_profile shortcut is deliberately NOT touched —
verified in the research wiki to silently fail for GUI-launched IDE
builds.

Files:
  install_certs_jvm_macos.sh              Installer (~540 lines).
  validate_certs_jvm_macos.sh             Companion validator.
  _jvm_macos_paths.sh                     Shared constants sourced by both.
  testing/test_install_certs_jvm_macos.sh 12-invariant smoke runner.
  .github/workflows/ci.yml                New test-macos-jvm job.
  README.md                               New "macOS (JVM)" section.

Hardening fixes folded in from a round of pr-review-toolkit review (5
agents, 21 findings: 5 Critical + 13 Important + 3 Minor):

  Critical:
  - validate_pem leaf-cert (CA:FALSE) check now works on stock macOS
    LibreSSL. The previous `openssl x509 -ext` flag is OpenSSL 3.x-only;
    LibreSSL silently failed → leaf certs accepted as trust anchors.
    New path parses `-noout -text` output (portable across both).
  - chown failure capture at both call sites (JKS dir + plist).
    Under --all-users a silent chown would leave root-owned plists in a
    user's ~/Library/LaunchAgents/, which launchd silently refuses to
    load — exactly the phantom-success the project bans.
  - --cert-name semantics clarified in constants file + --help. The
    previous "LaunchAgent label suffix" claim was wishful thinking; the
    flag is alias-cosmetic only.
  - Test runner docstring rewritten (cleanup runs only on positive
    cases) and the iter_all_users "mirrors install_certs_macos.sh"
    claim corrected (it's a stricter filter, not a mirror).

  Important:
  - get_single_target_user filter+order matches install_certs_macos.sh
    (SUDO_USER → /dev/console → logname; rejects loginwindow pseudo-user).
  - get_user_home eval-on-username fallback replaced with dscacheutil.
  - bootstrap_launch_agent retry bumped 5×100ms → 20×100ms to survive
    EDR exec latency; warn text no longer suggests a logout dance.
  - Validator --help documents the absence of --cert-name.
  - Validator final summary qualifies "All checks passed" with a WARN
    count so a green exit doesn't over-promise when launchctl getenv
    was skipped (no GUI session).
  - install_as_test_user / validate_as_test_user capture combined
    stdout/stderr to a tempfile; dump on UNEXPECTED exit only.
  - Smoke matrix gained 3 new invariants: --all-users iteration (#11),
    plist content validation via plutil -extract (#10), validate_pem
    warn-paths for 30-day-expiry and multi-cert bundle (#12).
  - Test #9 (launchctl getenv) now retries 20×100ms to mirror the
    installer.
  - CI workflow uses explicit `sudo env JAVA_HOME=… PATH=…` instead of
    --preserve-env, surviving future actions/setup-java renames. PATH
    includes /usr/sbin so chown is resolvable under sudo.

  Minor:
  - README requirements list names plutil/launchctl/dscl/stat.
  - README "five launch contexts" claim scoped to what the test
    actually verifies.
  - JKS_PASSWORD "not a secret" comment scoped to trustedCertEntry-only
    stores (PrivateKeyEntry would change the calculus).

Smoke matrix: 12/12 green locally on dev Mac, 12/12 green on CI
(Test (macOS JVM) job, macos-latest runner with Temurin 21).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* DFLOW-151 - JVM client setup (Windows)

Adds a Windows client-side installer + validator that wires a corporate
CA into the JVM trust path so Maven / Gradle / sbt / Apache Ivy traffic
redirected through package-reroute validates correctly. JVM trust only --
does not configure Node/npm/Python and does not touch Docker credentials.
Pair with install_certs_windows.ps1 for those flows.

Based on the published research wiki (DFLOW-136):
  https://jfrog-int.atlassian.net/wiki/spaces/RTFACT/pages/2440101931

Sibling to DFLOW-150 (Linux) and DFLOW-152 (macOS). Single path on
Windows -- there is no Windows-ROOT trustStoreType option because the
Gradle Daemon caches a stale store (gradle/gradle#6584):

  1. Build a per-user JKS truststore at
     %LOCALAPPDATA%\JFrog\package-route-jvm\truststore.jks
  2. Set JAVA_TOOL_OPTIONS at User scope via
     [Environment]::SetEnvironmentVariable(..., 'User')
     which writes HKCU\Environment AND broadcasts WM_SETTINGCHANGE.

No Administrator required (User-scope writes to HKCU\Environment without
elevation; %LOCALAPPDATA% is per-user).

Files:
  install_certs_jvm_windows.ps1              Installer (~370 lines).
  validate_certs_jvm_windows.ps1             Companion validator.
  _jvm_windows_paths.ps1                     Shared constants dot-sourced.
  testing/test_install_certs_jvm_windows.ps1 14-invariant smoke runner.
  .github/workflows/ci.yml                   New test-windows-jvm job.
  README.md                                  New "Windows (JVM)" section.

Hardening fixes folded in from a round of pr-review-toolkit review
(5 agents, 28 findings: 2 Critical + 21 Important + 5 Minor):

  Critical:
  - SetEnvironmentVariable round-trip verify. Windows 10 1607+ silently
    truncates user-env values > 2047 chars rather than throwing; future
    JTO extensions would corrupt HKCU. Now reads back and hard-fails on
    mismatch.
  - Test runner captures $LASTEXITCODE IMMEDIATELY after the native
    powershell.exe call, BEFORE the Out-String pipeline. Without this an
    intervening pipeline error leaves $rc carrying a stale value from a
    previous step and -ExpectFail can phantom-pass.

  Important production-code:
  - Require-Keytool now probes `keytool -help` to reject corrupt 0-byte
    stubs and broken-runtime keytools.
  - Build-JksTruststore post-import verify: runs keytool -list and asserts
    at least one trustedCertEntry, catching JBR-bundled keytool cases
    where rc=0 hides a non-standard java.security provider list.
  - Build-JksTruststore precondition checks for $env:LOCALAPPDATA
    existence + readability (OneDrive Known-Folder-Move, roaming-profile
    failures get actionable diagnostics).
  - Test-CaCertificate basicConstraints comment documents the legacy-cert
    behavior (extension absent -> accept, matches Linux/macOS siblings).
  - Maintenance comment on $prevEAP capture / restore.
  - Set-JavaToolOptions now quotes the trustStorePassword value.
  - Build-JksTruststore surfaces keytool's non-failure stderr warnings
    (JKS deprecation, weak-algo notices) on the success path.
  - Test-UserEnvVar regex anchors both branches so a path like
    $JksPath.bak.pkcs12 doesn't false-positive as a prefix match.
  - Test-UserEnvVar warns on Machine-scope sibling env vars to flag
    mixed-scope misconfig.
  - Validator's WarnCount infrastructure now actually fires on the
    Machine-scope path.

  Important test-runner:
  - Invoke-Keytool helper wraps inline `keytool -list` in tests with
    EAP=Continue, matching the installer/validator pattern. JDK 17+
    crypto-policy notices to stderr won't terminate the test.
  - Cleanup() switched from -ErrorAction SilentlyContinue to probe-then-
    warn so locked $JksDir from a leaked keytool.exe child surfaces.
  - openssl version banner + warning when < 3.2 (required by test #7).
  - 4 new tests raise the matrix from 10 to 14: JTO env var replaces on
    re-install (catches future append-mode regression), missing keytool
    fails cleanly, mandatory -UseCert no-args fails non-interactively,
    docstring split #10 -> #10+#11 (30-day expiry vs bundle warn).
  - Explicit exit 0 so child-rc from negative tests doesn't leak to the
    shell wrapper.

  Docs / future-proofing:
  - PowerShell 5.1+ named as a requirement in installer header.
  - README "JDK-version-agnostic" claim qualified ("across currently-
    supported JDKs; JKS format still read by JDK 8-25; future JDK
    dropping JKS would require a format bump").
  - README "covered for free" for Gradle auto-provisioned JDKs now
    cross-references the Gradle Daemon caveat.
  - README validation row clarifies that basicConstraints absent ->
    accept; CA:TRUE required only when extension present.
  - _jvm_windows_paths.ps1 header documents the "UTF-8 BOM +
    ASCII-only content" guard for PowerShell 5.1's Windows-1252
    default; em-dashes in source files terminate string literals
    mid-line under cp1252 decoding and the parser reports a baffling
    error 100+ lines later.

Smoke matrix: 14/14 green on windows-latest in CI (Test (Windows JVM)
job, Temurin 21 via actions/setup-java).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* DFLOW-140 - Use bundled JVM truststores on macOS and Windows

Signed-off-by: rani <ranil@jfrog.com>

* DFLOW-140 - Split Linux JVM trust installers

* DFLOW-140 - Add JVM truststore bundle builders

---------

Signed-off-by: rani <ranil@jfrog.com>
Co-authored-by: Michael Akushsky <michaelak@jfrog.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@gmininberg-jfrog gmininberg-jfrog gmininberg-jfrog approved these changes
@amitz-jfrog amitz-jfrog Awaiting requested review from amitz-jfrog amitz-jfrog is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@RaniLinkov @gmininberg-jfrog