PVA/SPVA: track SPVA version independently and move XDG keychain dir pva/<ver> -> spva/<n.n.n>

[george-mcintyre]

Summary

In the Secure PVAccess (SPVA) line of work, the SPVA release version is being decoupled from the PVXS library version. On the C++ side (PVXS / PVACMS) the SPVA version becomes a separately-tracked number, and the well-known TLS keychain directory changes from pva/<pvxs-version> to spva/<spva-version>.

Phoebus's core/pva/ is an independent Java PVA implementation and does not link the C++ PVXS code, so it cannot consume that version programmatically. It must hard-code the SPVA version (as it already hard-codes the PVA version today) and keep it in sync by hand.

Current behaviour

core/pva/src/main/java/org/epics/pva/PVASettings.java:

// Hard-coded, documented as "Matches PVXS versionString()"
private static final String PVA_VERSION = "1.5";

// Well-known TLS keychain auto-discovery location:
//   <xdg_config_home>/pva/<PVA_VERSION>/<filename>
final String path = config_home + File.separator + "pva"
                  + File.separator + PVA_VERSION
                  + File.separator + filename;

Used to auto-discover server.p12 and client.p12 under ~/.config/pva/1.5/ when EPICS_PVA(S)_TLS_KEYCHAIN is unset, mirroring the PVXS config.cpp fallback.

Requested changes

1. Replace the PVXS-derived PVA_VERSION with a hard-coded SPVA version constant (e.g. SPVA_VERSION), documented as manually mirroring the authoritative PVXS-side SPVA version, with a comment pointing at that source so the two stay in lockstep per SPVA release.

2. Change keychain auto-discovery from pva/<PVA_VERSION> to spva/<SPVA_VERSION>:

   • ~/.config/spva/<n.n.n>/server.p12
   • ~/.config/spva/<n.n.n>/client.p12

   (literal pva -> spva, and the version source changes from PVXS major.minor to the SPVA n.n.n.)

Scope / interop notes

• Java side uses only the config home path here (keychain discovery); there is no data-home / cert-DB usage, unlike the C++ tooling.
• The directory must match whatever PVXS / PVACMS adopt, or the Java client and C++ tools will look in different places for shared keychains. Recommend the same migration behaviour on all sides: fall back to the legacy pva/<ver> path when the new spva/<n.n.n> one is absent, so existing deployments keep working.

Context

This is the Phoebus-side counterpart of the SPVA version-tracking change being made in the PVXS and PVACMS repositories; those define the authoritative SPVA version and the spva/<n.n.n> convention. Phoebus tracks the same value by hand.

[george-mcintyre]

Related SPVA version-tracking issues

This is the Java/Phoebus side (hard-codes the SPVA version; cannot share the C++ code). Tracked together with the PVXS / PVACMS counterparts:

• slac-epics/pvxs-tls#27 — owner: defines the shared SPVA version, the spva/<n.n.n> directory convention, and the SPVA <n.n.n> / -spva-<n.n.n> version output
• slac-epics/pvxs-cms#32 — PVACMS build train consumes the shared SPVA version
• ControlSystemStudio/phoebus#3865 — this issue

(The slac-epics/* repositories are not publicly visible; references are provided for coordination.)