]> git.cworth.org Git - notmuch-wiki/blobdiff - meetings/hd2015.mdwn
News for release 0.38.3
[notmuch-wiki] / meetings / hd2015.mdwn
index aa2995fbc8e9e0e3b04dfabcf460ea0fbced7a56..21f80756ebedb24aff7d02ecbefd755103ee2725 100644 (file)
@@ -7,6 +7,13 @@ What, Where, When
 
 * Video streaming should be [available](https://wiki.debconf.org/wiki/DebConf15/Videostream/Amsterdam)
 
+* We will probably use
+  [gobby](https://packages.debian.org/jessie/gobby) for collaborative
+  editing. Unfortunately the infinote backend for emacs-rudel seems
+  not work. After installing gobby (>= 5.0), run
+
+      % gobby infinote://gobby.debian.org/debconf15/bof/notmuch-privacy-and-security
+
 
 Agenda
 ======
@@ -20,7 +27,7 @@ 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:
@@ -29,27 +36,42 @@ Moving parts for secure e-mail
 
 Security and privacy concerns
 -----------------------------
-* privacy leaks rendering messages
 * message-id collisions
+* 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?)
-* webmail message escaping (XSS, etc)
+* 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)
+* decryption happens in the CLI rather than the UI
+  * when using the UI and the CLI on different machines (so called "remote" mode), this leads to some undesirable and odd behaviour:
+    * decrypted content is passed across a potentially insecure channel (though usually ssh)
+    * the CLI needs access to keys, which can be awkward or impossible
 
-### usability as security?
+Usability as security?
+----------------------
 
-* indexing encrypted mail
+* Indexing encrypted mail
+  * incremental re-indexing?
 * Memory Hole protected headers
-* key selection indicators during composition
-
+* Key selection indicators during composition
 
 Breakout sessions
 -----------------
@@ -60,31 +82,3 @@ Reportbacks
 -----------
 
 
-
--------------------------
-
-
-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)
-
-