From 7a6aba045c9904baa85be01034d5dc2c11eec12b Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <frase@frase.id.au>
Date: Thu, 17 Oct 2024 06:44:19 +1000
Subject: [PATCH] meeting notes: 2024-10-16

---
 meeting-notes/2024-10-16.md | 67 +++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100644 meeting-notes/2024-10-16.md

diff --git a/meeting-notes/2024-10-16.md b/meeting-notes/2024-10-16.md
new file mode 100644
index 0000000..642a353
--- /dev/null
+++ b/meeting-notes/2024-10-16.md
@@ -0,0 +1,67 @@
+# SRT meeting 2024-10-16
+
+Previously:
+https://github.com/haskell/security-advisories/blob/main/meeting-notes/2024-10-02.md
+
+## Call for Volunteers
+
+- FT sent each of the 4 application to the list
+- Upon discussion, we will accept 2
+- SRT members, please review and respond on the ML (the initial thread)
+
+## Stack traces proposal
+
+- CLC proposal:
+  https://github.com/haskell/core-libraries-committee/issues/285#issuecomment-2414727239
+- Discussion:
+    - For 2 decades people wanted stack traces, now we have them
+      there are doubts :D
+    - Most other languages are showing the stack trace
+    - Sensitive information in error messages is an application
+      developer's fault
+    - It's not unreasonable to want a way to disable the default
+      behaviour, or catch and suppress, if the actual program
+      structure (e.g. function names) is sensitive for some reason.
+    - The proposal Part 2 seems to suggest the stacktrace would be
+      leaked with `displayException` too, which might be used for
+      end-user facing message, perhaps it would be safer to only
+      print them through the main exception handler. That's how
+      python does it, printing an exception just show the error, the
+      stacktrace is only displayed by default from uncaught
+      exception. 
+
+## Draft quarterly report
+
+- call for volunteers update
+- advisory DB changes (1 new vuln, 0 historical, 2 reserved)
+- HSEC-2024-0003 update
+- haskell.org Apache httpd update
+- hackage-server "Reporting Vulnerabilities" link
+- tooling update
+    - CVSS 4.0 work (ongoing)
+    - GHA / Renovate progress
+
+## GHC hash collision
+
+- Simon PJ and FT think it is not a huge deal
+- But we should fix it.
+- Changing the Hash function is simple and buys us another 10-20
+  years (hopefully)
+
+### Documenting known weaknesses
+
+This is a good opportunity to take a look at the ways
+that the compiler/toolchain can be compromised by malicious
+source code, and document them.  Guide / blog post / GHC docs.
+
+Many of these would not warrant an HSEC-ID (especially structural
+issues that are impossible / very hard to fix), but we can still
+collect them and let the community know in a more formal way.
+
+## GHC numeric bug
+
+- Tristan will rebase the advisory draft #214
+
+## Updated major dependencies for hsec-tools
+
+#239 and #241