Skip to content

Conversation

lrstewart
Copy link
Contributor

Release Summary:

Resolved issues:

resolves #ISSUE-NUMBER1, resolves #ISSUE-NUMBER2, etc.

Description of changes:

Describe s2n’s current behavior and how your code changes that behavior. If there are no issues this PR is resolving, explain why this change is necessary.

Call-outs:

Address any potentially confusing code. Is there code added that needs to be cleaned up later? Is there code that is missing because it’s still in development? If a callout is specific to a section of code, it might make more sense to leave a comment on your own PR file diff.

Testing:

How is this change tested (unit tests, fuzz tests, etc.)? What manual testing was performed? Are there any testing steps to be verified by the reviewer?
How can you convince your reviewers that this PR is safe and effective?
Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed?

Remember:

  • Any change to the library source code should at least include unit tests.
  • Any change to the core stuffer or blob methods should include CBMC proofs.
  • Any change to the CI or tests should:
    1. prove that the test succeeds for good input
    2. prove that the test fails for bad input (eg, a test for memory leaks fails when a memory leak is committed)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@lrstewart lrstewart added the do_not_merge PR might needs something before merging, even if approved and passing label Jul 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do_not_merge PR might needs something before merging, even if approved and passing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant