Track pinned versions of CI tooling
dougch opened this issue · comments
Security issue notifications
If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
Occasionally, upstream repositories go off-line, or remove older versions/artifacts that our CI depends on.
We've been collecting dependencies in an S3 bucket, but as pointed out, this creates issues when we're not testing with new enough tool chains.
Solution:
Start with a review of what's pinned, to see if these are actually still used, then track and nag when a dependence has a birthday.
- musl #4590
- SAW https://github.com/aws/s2n-tls/blob/main/codebuild/bin/install_saw.sh#L40
- aws-lc https://github.com/aws/s2n-tls/blob/main/codebuild/bin/install_awslc.sh#L39
- gnutls (non-nix) https://github.com/aws/s2n-tls/blob/main/codebuild/bin/install_gnutls37.sh#L55
- yices/z3 https://github.com/aws/s2n-tls/blob/main/codebuild/bin/install_z3_yices.sh#L34-L37
- nixpkgs https://github.com/aws/s2n-tls/blob/main/flake.nix#L4
(some of these might be historical artifacts)
Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
- RFC links: Links to relevant RFC(s)
- Related Issues: Link any relevant issues
- Will the Usage Guide or other documentation need to be updated?
- Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
- Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
- Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.
Out of scope:
Is there anything the solution will intentionally NOT address?
Related: #4479
