Return ECMR public key (tang_pub) in /rec/$kid response

[sarroutbi]

• POST /rec/$kid now includes a tang_pub field in the response JWK containing the public part of the server's ECMR exchange key, with private material stripped via jose_jwk_pub(). Old clients ignore the unknown field — no backward compatibility impact.
• GET /version is a new endpoint returning server capabilities as structured JSON:

{"features":{"tang_pub":true},"tang_version":"15"}

Old Tang servers return 404 for this endpoint, giving clients a clean signal to fall back to legacy binding behavior.

• The /version endpoint respects the -e (endpoint) option, so /endpoint/version works consistently with /endpoint/adv and /endpoint/rec.

Embed the server's ECMR public key as a tang_pub field in the recovery response so that clients can obtain it at recovery time instead of persisting it on disk. The public key is a deep copy with private material stripped via jose_jwk_pub(), ensuring no secret data leaks.

The field is additive: old clients ignore the unknown JSON field, so existing Clevis bindings and recovery flows are unaffected.

[codecov]

Codecov Report

❌ Patch coverage is 52.94118% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.02%. Comparing base (83de399) to head (afcb6d0).
⚠️ Report is 5 commits behind head on master.

Files with missing lines	Patch %	Lines
src/tangd.c	52.94%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #164      +/-   ##
==========================================
+ Coverage   58.44%   59.02%   +0.57%     
==========================================
  Files           4        4              
  Lines         580      593      +13     
  Branches      147      152       +5     
==========================================
+ Hits          339      350      +11     
+ Misses        140      139       -1     
- Partials      101      104       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sergio-correia]

If I understand correctly, updated Clevis will stop storing the Tang public key in new bindings, regardless of capability discovery. Could we clarify the "fall back to legacy binding behavior" wording to reflect that? I think compatibility here means continuing to read existing legacy bindings, rather than creating new ones that retain the public key.

[sarroutbi]

If I understand correctly, updated Clevis will stop storing the Tang public key in new bindings, regardless of capability discovery. Could we clarify the "fall back to legacy binding behavior" wording to reflect that? I think compatibility here means continuing to read existing legacy bindings, rather than creating new ones that retain the public key.

No. adv is still stored in case of capability discovery failing. Otherwise, recover will fail. I am thinking in the case of a brand new Clevis updated with old Tang server:
1 - Brand new clevis will check capability
2 - Capability not available in Tang
3 - Brand new clevis needs to update adv in server for later recovery
Am I missing something?