🌱 Preserve Mozilla v5.8 old TLS profile and harden update script#2632
🌱 Preserve Mozilla v5.8 old TLS profile and harden update script#2632tmshort wants to merge 1 commit intooperator-framework:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Preserves the deprecated Mozilla v5.8 “old” TLS profile as a static Go source while updating the generator to track Mozilla’s latest TLS guidelines and adding guards/tests to prevent accidental regressions.
Changes:
- Move
oldTLSProfileinto a new staticold_profile.go(sourced from Mozilla v5.8) and remove it from generated data. - Harden
update-tls-profiles.shwith version-based early exit and schema validations; switch input tolatest.json/ v6. - Add unit tests for old profile invariants and for presence of the
X25519MLKEM768curve across profiles.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| internal/shared/util/tlsprofiles/tlsprofiles_test.go | Adds assertions to lock down old profile invariants and ensure X25519MLKEM768 is present in profiles. |
| internal/shared/util/tlsprofiles/old_profile.go | Introduces a static copy of Mozilla v5.8 “old” profile for backward compatibility. |
| internal/shared/util/tlsprofiles/mozilla_data.go | Updates generated header to track latest.json (v6) and removes generated “old” profile. |
| hack/tools/update-tls-profiles.sh | Switches generator input to latest.json, adds early exit on unchanged version, and validates input structure before generation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| echo "Mozilla TLS data is already at version ${NEW_VERSION}, skipping regeneration." | ||
| exit 0 | ||
| fi | ||
| echo "Updating Mozilla TLS data from version ${STORED_VERSION:-unknown} to ${NEW_VERSION}" |
There was a problem hiding this comment.
Is there any case where we want to fail here for a schema migration? It would have been good info in the recent profile jump to 6.0 to have log output that said "Updating Mozilla TLS data from version v5.7 to v6.0", but we'd still have the schema fracture.
There was a problem hiding this comment.
The additional checks that are added to the function now check for schema changes that impact generation.
|
|
||
| TMPFILE="$(mktemp)" | ||
| trap 'rm -rf "$TMPFILE"' EXIT | ||
|
|
There was a problem hiding this comment.
Is there any value in ensuring that the output is valid JSON? What if the URL location changes? Then we'll see the version failure which won't clearly indicate the problem.
There was a problem hiding this comment.
Not sure we need to go that far, if they change the format, they are messing with everyone. There will be a failure, though.
There was a problem hiding this comment.
Those checks would manifest the cases
invalid JSON
error retrieving schema
the same:
"ERROR: Could not read .version from ${INPUT}"
If the URL had an outage, or if they changed the schema again in another way that made it impossible to parse given the current assumptions, that would be the symptom.
There was a problem hiding this comment.
Maybe just catch and test the curl failures?
There was a problem hiding this comment.
It behaves better now.
fbafd47 to
2de30ac
Compare
| // X25519MLKEM768 (added in Go 1.24) is present in all three named profiles. | ||
| // This curve is part of the Mozilla recommendation and its presence should be | ||
| // guarded against accidental removal. | ||
| func TestX25519MLKEM768InProfiles(t *testing.T) { |
There was a problem hiding this comment.
We should probably also verify that MLKEM is in the schema retrieved in the script as well, no?
There was a problem hiding this comment.
Clarify? "MLKEM" itself as a string is not part of the profiles. Only "X25519MLKEM768"
There was a problem hiding this comment.
The test code validates that a specific profile is in the generated code. We should detect an omission of this policy earlier in the tooling if we validate it is included when retrieving the schema via the script.
There was a problem hiding this comment.
TBH, I'm not sure we should actually test against this particular curve in this way; and I'm also not sure we want to specify this kind of testing in the script itself, which should be somewhat agnostic to the resulting output. The only exception being ciphers that we know don't exist.
We still have a problem if a new curve is added, because we don't have the code for it (because we don't know what it is).
There was a problem hiding this comment.
In other words, I don't think this is really a valid test, and I think I'll remove it, because that curve may be superseded, and that's just fine. Explicit testing will just cause issues.
There was a problem hiding this comment.
Claude agrees:
Does the
TestX25519MLKEM768InProfilesfunction really add any value, when the set of key exchanges could be changed at any time?
No, not really — especially for the generated profiles. If Mozilla updates their curve recommendations and X25519MLKEM768 is removed or replaced in a future spec version, the test fails even though the generated code is correct. It's coupling the test to a specific curve choice that's entirely Mozilla's to change.
For the static oldTLSProfile it's slightly more defensible (the file won't change unless someone edits it), but that's already guarded by TestOldProfileCiphers verifying the full cipher list. The curves aren't tested there, but an accidental edit to old_profile.go would likely show up in git diff during make verify anyway.
Overall the test encodes a transient implementation detail rather than an invariant. I'd remove it.
2de30ac to
b4a4e74
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2632 +/- ##
=======================================
Coverage 68.95% 68.95%
=======================================
Files 139 139
Lines 9891 9891
=======================================
Hits 6820 6820
Misses 2562 2562
Partials 509 509
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
- Move oldTLSProfile to a static old_profile.go (removed from v6+ spec) - Add version-based early exit to update-tls-profiles.sh - Validate profile existence, tls_versions, ciphers, and curves fields - Make jq/sed/cat invocations null-safe and consistently quote variables - Add unit tests for old profile content; fix global state leak in tests Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Todd Short <tshort@redhat.com>
b4a4e74 to
4340f84
Compare
|
|
||
| version=$(${JQ} -r '.version' ${TMPFILE}) | ||
| # Extract stored version from current output file (may be empty on first run) | ||
| STORED_VERSION=$(grep '^// DATA VERSION:' "${OUTPUT}" 2>/dev/null | awk '{print $4}' || true) |
There was a problem hiding this comment.
nit: the "|| true" may be dropped here as the grep is in a pipe with awk and the overall result would never fail (as the awk command would not fail). Still looks more robust this way.
Description
Reviewer Checklist