From 6ec478de32b97ed62b660e6f9e9be02520dffb88 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 2 May 2024 06:37:45 +1000 Subject: [PATCH] meeting notes: 2024-05-01 --- meeting-notes/2024-05-01.md | 49 +++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 meeting-notes/2024-05-01.md diff --git a/meeting-notes/2024-05-01.md b/meeting-notes/2024-05-01.md new file mode 100644 index 00000000..03bcaa8a --- /dev/null +++ b/meeting-notes/2024-05-01.md @@ -0,0 +1,49 @@ +# SRT meeting 2024-05-01 + +Previous notes: +https://github.com/haskell/security-advisories/blob/main/meeting-notes/2024-04-17.md + +## CI security advice + +- Mihai published the draft: + https://github.com/haskell/security-advisories/blob/main/guides/github.md +- A couple more comments to handle, then it will be published to Discourse + +## Web area for SRT + +- FT will work to bootstrap this. We can publish our guides, + reports, and general information there. + +## Publishing our packages to Hackage + +- FT will begin on this in the next week. +- Discussion: do we want to set up auto-publish from GitHub? + - There is a GHA by Brandon Chinn to publish to Hackage. + - https://github.com/fourmolu/fourmolu/blob/main/.github/workflows/release.yml + - Does it work with subpackages? We would need to see. + - From supply chain security POV it's better to have an action + than having developers make the dist and publish themselves. + - Maybe this is a good topic for our second *guide* and/or a tool + to validate release tarball from the sources :) + - We will look into this after the initial package release to Hackage. + +## New meeting time + +- The when2meet tool does not seem to take timezones into account? +- We might need a second round / better tool :) +- FT will look for a better tool. Or else use same tool but in UTC. + +## The expanding scope of SRT + +- With cabal-audit proposed for our repo, the scope has expanded. + +- Advisory workload is low, so team does have capacity to own this + +- FT: I see cabal-audit as a transitional effort anyway; ideally we + do not have to own it forever and the capability can be absorbed + into Cabal itself. + +- Idea: cabal-audit lives in its own repo, not security-advisories repo + - Prerequisite: publish our packages + - Advantage: not "owned" by SRT, others might be more eager/willing to contribute. + - We will have the discussion in public, with the contributor MangoIV.