merge remaining discussion from pad into agenda

[notmuch-wiki] / meetings / hd2015.mdwn

diff --git a/meetings/hd2015.mdwn b/meetings/hd2015.mdwn
index a9c14790f0d83da73ce1d33f8abd9e89d989cc05..0d4292ca673a0d02dfc0399fc48f66150822f807 100644 (file)
--- a/meetings/hd2015.mdwn
+++ b/meetings/hd2015.mdwn
@@ -20,33 +20,47 @@ Moving parts for secure e-mail
 * GnuPG (C)
 * Emacs UI (emacs lisp)
   * notmuch-emacs
-  * mml-mode
+  * mml-mode, mm multimedia rendering library
 * Alot / nmbug / nmbug-status (python)
   * python-bindings
 * webmail:
   * noservice (Clojure)
   * notmuch web (Haskell)
 
-Security concerns
------------------
-* wrong key selection during composition
-* reply (message mode defaults)
-* inline PGP
+Security and privacy concerns
+-----------------------------
 * message-id collisions
-* webmail authentication/authorization (muliple users?)
-* webmail message escaping (XSS, etc)
+* rendering "rich" messages
+  * network access in front ends
+  * safe rendering of HTML
+* rendering security information
+  * spoofing signatures
+  * partially signed messages
+* Oops I just sent...
+  * wrong key selection during composition
+  * reply (message mode defaults)
+  * opportunistic signing and encryption
+  * using markup for security
+* inline PGP
+* webmail
+  * authentication/authorization (multiple users?)
+  *  message escaping (XSS, etc)
 * shell injection
 * terminal escape sequences
 * S/MIME support
+  * signatures
+  * encryption
+  * integration with other keyrings
 * reproducible builds:
   [sphinx man pages](https://reproducible.debian.net/rb-pkg/testing/amd64/notmuch.html)
 
-### usability as security?
+Usability as security?
+----------------------
 
-* indexing encrypted mail
+* Indexing encrypted mail
+  * incremental re-indexing?
 * Memory Hole protected headers
-* key selection indicators during compositoin
-
+* Key selection indicators during composition
 
 Breakout sessions
 -----------------
@@ -57,41 +71,3 @@ Reportbacks
 -----------
 
 
-
--------------------------
-
-proposed session:
----------
-One of (at least my) primary motivations for working on Notmuch is reducing my dependence on cloud services, and supporting the secure sending and receiving of signed and encrypted mail.  Like any realworld piece of software, notmuch is far from perfect, and several areas related to privacy and security could clearly be improved. During this BoF we'd like to plan out some topics to work on in followup hacking sessions. Anyone is welcome, even if they don't feel like hacking on notmuch. Potential topics of discussion andhacking include:
-        * S/MIME signatures and encryption
-        * Improving the security of the Emacs MML mime composer
-        * Searching of GPG encrypted mail
-        * Auditing and fixing "webbug" style problems in front ends
-        * Making notmuch build reproducibly
-
----------
-
-more complete agenda:
-
-        * S/MIME signatures and encryption
-            * test suites
-            * integration with other keyrings
-            * signature only (easyish) versus encryption (more work)
-        * Improving the security of the Emacs MML mime composer
-            * automated "encrypt-when-i-have-keys-available" mode or other convenience functions?
-            * can an adversary force signatures based on quoted text?
-            * generate memory-hole-style messages
-        * Searching of GPG encrypted mail
-            * possible implementation mechanism: "notmuch reindex --with-filter=decrypt"
-        * Auditing and fixing "webbug" style problems in front ends
-            * can we instruct emacs to restrict all network access from notmuch?
-            * what other frontends might call out to the network?
-        * Making notmuch build reproducibly
-            * https://reproducible.debian.net/rb-pkg/unstable/amd64/notmuch.html
-        * Protect against spoofed signature verification?
-            * how do we deal with multipart messages where only a subtree is signed?
-            * are other sorts of spoofing possible?
-        * read and display memory-hole-style messages
-        * "safe" ways to display html parts (e.g. without text/plain alternatives)
-
-