project/security.md: expand on details

Based on feedback from Mastdon, mostly from Kurt.

URL: https://infosec.exchange/@kurtseifried/112884278368728658
Feedback-by: Kurt Seifried

Closes #500

project/security.md

@@ -37,12 +37,18 @@ innocent and well-meaning but has a disguised malicious intent.
 
 To mitigate such risks, we apply established procedures and techniques:
 
+- **GitHub**. The curl project uses <https://github.com/curl/curl> as its main
+  source code git repository since 2010. We rely on their hosting to secure
+  access as per our configuration.
 - **2FA required**. We require all maintainers with push access to git to have
   two-factor authentication enabled, to reduce the risk that attackers can
-  impersonate them and use their credentials to push source code changes.
+  impersonate them and use their credentials to push source code changes. We
+  rely on GitHub's 2fa setup.
 - **Reviews**. Every contribution that are proposed for inclusion in the
-  project is reviewed by a maintainer. It is also automatically checked,
-  tested and scanned by numerous tools.
+  project is reviewed by a maintainer. All changes are always done publicly in
+  the open to allow all interested parties to participate. No invitation
+  needed. All changes are also automatically checked, tested and scanned by
+  numerous tools before accepted.
 - **Readable code**. We believe in readable code that follows our code style.
   Easy to read makes it easy to debug. If code is hard to read it should be
   improved until it gets easy to read. With easy to read code, smuggling
@@ -54,21 +60,29 @@ To mitigate such risks, we apply established procedures and techniques:
   This includes fuzzers, static code analyzers, fault injectors and more.
 - **No binary blobs**. All files stored in version control, in the git
   repository is readable or is otherwise small and documented. There is no
-  place anywhere for any hidden encrypted payload.
+  place anywhere for any hidden encrypted payload. We run a scanner on all
+  files on every change to detect binary files and the few files that need to
+  remain looking binary are manually vetted and verified against a checksum.
 - **Reproducible builds**. curl releases are shipped as tarballs that are
-  hosted on the curl website. We provide documentation, docker setups and
-  setups etc that allows anyone wanting to easily reproduce our release builds
-  to generate identical images - proving that what we ship is only contents
-  taken from the git repository plus other correct and properly generated
-  contents.
-- **Signed commits**. Some - not all - of the committers sign commits to help
-  prove provenance.
+  hosted on the curl website (<https://curl.se). We provide documentation,
+  docker setups and configurations etc to allow anyone wanting to easily
+  reproduce our release builds to generate identical images - proving that
+  what we ship is only contents taken from the git repository plus other
+  correct and properly generated contents.
+- **Signed commits**. Over 90% - not all - of recent commits were signed to
+  help prove provenance. Signing commits is not yet a mandatory requirement
+  for committers but we hope to voluntarily increase the share over time and
+  make it mandatory soon.
 - **Signed releases**. Every release, every uploaded tarball, is signed by
   Daniel. This helps to prove that the files have not been tampered with since
-  they were produced.
+  they were produced. We have opted to not sign them by multiple persons only
+  because of the added complexity for the relatively small extra protection.
 - **Fix all vulnerabilities quickly**. Whenever we receive a security
   vulnerability report, we create and ship a fix in the next pending release.
-  Sometimes sooner than previously planned. With every fixed security
-  vulnerability we release a detailed description of the flaw including exact
-  commit that introduced the problem, recommendations for users and more.
-  Further, the security advisories get announced to the world.
+  Sometimes sooner than previously planned. Only in extremely rare cases does
+  it take longer than a release cycle, but in the name of accuracy and
+  correctness we do reserve the right to spend time on research to get it
+  right. With every fixed security vulnerability we release a detailed
+  description of the flaw including exact commit that introduced the problem,
+  recommendations for users and more. Further, the security advisories get
+  announced to the world.