-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the Release Process #188
Conversation
Signed-off-by: steve lasker <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #188 +/- ##
=======================================
Coverage 92.04% 92.04%
=======================================
Files 12 12
Lines 1973 1973
=======================================
Hits 1816 1816
Misses 108 108
Partials 49 49 ☔ View full report in Codecov by Sentry. |
|
||
The go-cose library is an sdk around underlying crypto libraries, tailored to COSE scenarios. | ||
The go-cose library does not implement cryptographic functionality, reducing the potential risk. | ||
To assure go-cose had the proper baseline, two [security reviews](./reports) were conducted prior to the [v1.0.0](https://github.com/veraison/go-cose/releases/tag/v1.0.0) release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To assure go-cose had the proper baseline, two [security reviews](./reports) were conducted prior to the [v1.0.0](https://github.com/veraison/go-cose/releases/tag/v1.0.0) release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for history in a policy doc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose was to reference the existing security reviews, to provide visibility and confidence in how we manage our policy. We have, and will do security reviews, but will not do them for all releases.
How do we create visibility to reviews, so it doesn't look like we're dismissing the need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this seems like a good baseline.
We can modify these policies as we encounter reason to, and as we learn from the experience of applying them.
You may consider noting that maintainer will update the release checklist and management policy based on feedback.
Signed-off-by: steve lasker <[email protected]> Co-authored-by: Orie Steele <[email protected]>
👍 See: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made few comments for you to have a look...
Signed-off-by: steve lasker <[email protected]>
…into steve/issue-169
Signed-off-by: steve lasker <[email protected]> Co-authored-by: Yogesh Deshpande <[email protected]>
Signed-off-by: steve lasker <[email protected]>
…into steve/issue-169
Signed-off-by: steve lasker <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
fixes #169