Recent changes to this wiki:

devblog
diff --git a/devblog/debug_me_keyrings.mdwn b/devblog/debug_me_keyrings.mdwn
new file mode 100644
index 0000000..1b9aabc
--- /dev/null
+++ b/devblog/debug_me_keyrings.mdwn
@@ -0,0 +1,19 @@
+Releasing debug-me 1.20170520 today with a major improvement.
+
+Now it will look for the gpg key of the developer in keyring
+files in `/usr/share/debug-me/keyring/`, and tell the user which project(s)
+the developer is known to be a member of. So, for example, Debian
+developers who connect to debug-me sessions of Debian users will be
+identified as a Debian developer. And when I connect to a debug-me user's
+session, debug-me will tell them that I'm the developer of debug-me.
+
+This should help the user decide when to trust a developer to connect to
+their debug-me session. If they develop software that you're using, you
+already necessarily trust them and letting them debug your machine is not 
+a stretch, as long as it's securely logged. 
+
+Thanks to Sean Whitton for the idea of checking the Debian keyring, which
+I've generalized to this.
+
+Also, debug-me is now just an apt-get away for Debian unstable users,
+and I think it may end up in the next Debian release.

format
diff --git a/blog/entry/announcing_debug-me.mdwn b/blog/entry/announcing_debug-me.mdwn
index 6e3dd6b..c982da0 100644
--- a/blog/entry/announcing_debug-me.mdwn
+++ b/blog/entry/announcing_debug-me.mdwn
@@ -1,17 +1,15 @@
 Today I'm excited to release [debug-me](https://debug-me.branchable.com/),
 a program for secure remote debugging.
 
-<blockquote>
-Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
-needs to see your problem to understand it. Debug-me aims to make debugging
-fast, fun, and easy, by letting the developer access your computer remotely,
-so they can immediately see and interact with the problem. Making your
-problem their problem gets it fixed fast.
-
-debug-me session is logged and signed with the developer's GnuPG
-key, producing a chain of evidence of what they saw and what they did.
-So the developer's good reputation is leveraged to make debug-me secure.
-</blockquote>
+> Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
+> needs to see your problem to understand it. Debug-me aims to make debugging
+> fast, fun, and easy, by letting the developer access your computer remotely,
+> so they can immediately see and interact with the problem. Making your
+> problem their problem gets it fixed fast.
+> 
+> debug-me session is logged and signed with the developer's GnuPG
+> key, producing a chain of evidence of what they saw and what they did.
+> So the developer's good reputation is leveraged to make debug-me secure.
 
 I've recorded a [short screencast demoing debug-me](https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm).
 

devblog
diff --git a/blog/entry/announcing_debug-me.mdwn b/blog/entry/announcing_debug-me.mdwn
new file mode 100644
index 0000000..6e3dd6b
--- /dev/null
+++ b/blog/entry/announcing_debug-me.mdwn
@@ -0,0 +1,40 @@
+Today I'm excited to release [debug-me](https://debug-me.branchable.com/),
+a program for secure remote debugging.
+
+<blockquote>
+Debugging a problem over email/irc/BTS is slow, tedious, and hard. The developer
+needs to see your problem to understand it. Debug-me aims to make debugging
+fast, fun, and easy, by letting the developer access your computer remotely,
+so they can immediately see and interact with the problem. Making your
+problem their problem gets it fixed fast.
+
+debug-me session is logged and signed with the developer's GnuPG
+key, producing a chain of evidence of what they saw and what they did.
+So the developer's good reputation is leveraged to make debug-me secure.
+</blockquote>
+
+I've recorded a [short screencast demoing debug-me](https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm).
+
+<video controls width=400 title="debug-me demo" src="https://downloads.kitenet.net/videos/debug-me/debug-me-demo.webm"></video>
+
+And here's a [screencast about debug-me's chain of evidence](https://downloads.kitenet.net/videos/debug-me/debug-me-logs.webm).
+
+<video controls width=400 title="debug-me logs" src="https://downloads.kitenet.net/videos/debug-me/debug-me-logs.webm"></video>
+
+The idea for debug-me came from [[Re:_Debugging_over_email]], and then my
+[Patreon](https://www.patreon.com/joeyh) supporters picked debug-me in a
+poll as a project I should work on. It's been a fun month, designing the
+evidence chain, building a custom efficient protocol with space saving
+hacks, using websockets and protocol buffers and ed25519 for the first
+time, and messing around with low-level tty details. The details of
+debug-me's development are in my [[devblog]].
+
+Anyway, I hope debug-me makes debugging less of a tedious back and forth,
+at least some of the time.
+
+PS: Since debug-me's protocol lets multiple people view the same shell
+session, and optionally interact with it, there could be uses for it beyond
+debugging, including live screencasting, pair programming, etc.
+
+PPS: There needs to be a debug-me server not run by me, so someone
+please [run one](https://debug-me.branchable.com/servers/)..
diff --git a/devblog/debug_me_released.mdwn b/devblog/debug_me_released.mdwn
new file mode 100644
index 0000000..af34c17
--- /dev/null
+++ b/devblog/debug_me_released.mdwn
@@ -0,0 +1,15 @@
+debug-me is released! <https://debug-me.branchable.com/>
+
+I made one last protocol compatability breaking change before the release.
+Realized that while the websocket framing protocol has a version number,
+the higher-level protocol does not, which would made extending it very hard
+later. So, added in a protocol verison number.
+
+The release includes a tarball that should let debug-me run on most linux
+systems. I adapted the code from git-annex for
+[[blog/entry/completely_linux_distribution-independent_packaging]]. That
+added 300 lines of code to debug-me's source tree, which is suboptimal. But
+all the options in the Linux app packaging space are suboptimal. Flatpak
+and snappy would both be ok -- if the other one didn't exist and they
+were were installed everywhere. Appimage needs the program to be built against
+an older version of libraries.

devblog
diff --git a/devblog/debug_me_screencast_recording_and_server.mdwn b/devblog/debug_me_screencast_recording_and_server.mdwn
new file mode 100644
index 0000000..3c2d45b
--- /dev/null
+++ b/devblog/debug_me_screencast_recording_and_server.mdwn
@@ -0,0 +1,31 @@
+Recorded a 7 minute screencast demoing debug-me, and another 3 minute
+screencast talking about its log files. That took around 5 hours of work
+actually, between finding a screencast program that works well (I used
+kazam), writing the "script", and setting the scenes for the user and
+developer desktops shown in the screencast.
+
+While recording, I found a bug in debug-me. The gpg key was not available
+when it tried to verify it. I thought that I had seen gpg --verify
+--keyserver download a key from a keyserver and use it to verify but seems
+I was mistaken. So I changed the debug-me protocol to include the gpg
+public key, so it does not need to rely on accessing a keyserver.
+
+Also deployed a debug-me server, <http://debug-me.joeyh.name:8081/>. It's
+not ideal for me to be running the debug-me server, because when me and a
+user are using that server with debug-me, I could use my control of the
+server to prevent the debug-me log being emailed to them, and also delete
+their local copy of the log. 
+
+I have a plan to 
+<https://debug-me.branchable.com/todo/send_to_multiple_servers/>
+that will avoid that problem but it needs a debug-me server run by someone
+else. Perhaps that will happen once I release debug-me; for now the single
+debug-me server will have to do.
+
+Finally, made `debug-me --verify log` check all the signatures and hashes
+in the log file, and display the gpg keys of the participants in the
+debug-me session.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
+
+(Also, Sean Whitton has stepped up to get debug-me into Debian!)

correct spelling mistakes
diff --git a/devblog/debug_me_one_last_big_change.mdwn b/devblog/debug_me_one_last_big_change.mdwn
index c8f2fcc..51fa0c0 100644
--- a/devblog/debug_me_one_last_big_change.mdwn
+++ b/devblog/debug_me_one_last_big_change.mdwn
@@ -5,7 +5,7 @@ the order of two entered values could be ambiguous.
 And also, it makes for nicer graphs! In this one, I typed "qwertyuiop" with
 high network lag, and you can see that the "r" didn't echo
 back until "t" "y" "u" had been entered. Then the two
-divered states merged back together when "i" was entered
+diverged states merged back together when "i" was entered
 chaining back to the last seen "r" and last entered "u".
 
 [[debug-me.png]]
@@ -14,7 +14,7 @@ chaining back to the last seen "r" and last entered "u".
 [[debug_me_first_stage_complete]].)
 
 Having debug-me generate these graphs has turned out to be a very good
-idea. Makes analizing problems much easier.
+idea. Makes analyzing problems much easier.
 
 ----
 

update
diff --git a/devblog/debug_me_one_last_big_change.mdwn b/devblog/debug_me_one_last_big_change.mdwn
index 1a450ce..c8f2fcc 100644
--- a/devblog/debug_me_one_last_big_change.mdwn
+++ b/devblog/debug_me_one_last_big_change.mdwn
@@ -13,6 +13,9 @@ chaining back to the last seen "r" and last entered "u".
 (Compare with the graph of the same kind of activity back in
 [[debug_me_first_stage_complete]].)
 
+Having debug-me generate these graphs has turned out to be a very good
+idea. Makes analizing problems much easier.
+
 ----
 
 Also made `/quit` in the control window quit the debug-me session.

devblog
diff --git a/devblog/debug_me_one_last_big_change.mdwn b/devblog/debug_me_one_last_big_change.mdwn
new file mode 100644
index 0000000..1a450ce
--- /dev/null
+++ b/devblog/debug_me_one_last_big_change.mdwn
@@ -0,0 +1,28 @@
+Added an additional hash chain of entered values to the debug-me data
+types. This fixes the known problem with debug-me's proof chains, that
+the order of two entered values could be ambiguous.
+
+And also, it makes for nicer graphs! In this one, I typed "qwertyuiop" with
+high network lag, and you can see that the "r" didn't echo
+back until "t" "y" "u" had been entered. Then the two
+divered states merged back together when "i" was entered
+chaining back to the last seen "r" and last entered "u".
+
+[[debug-me.png]]
+
+(Compare with the graph of the same kind of activity back in
+[[debug_me_first_stage_complete]].)
+
+----
+
+Also made `/quit` in the control window quit the debug-me session.
+I want to also let the user pause and resume entry in the session, but
+it seems that could lead to more ambiguity problems in the proof chain,
+so I'll have to think that over carefully.
+
+debug-me seems ready for release now, except it needs some servers,
+and some packages, and a screencast showing how it works.
+
+----
+
+Today's work was sponsored by Trenton Cronholm on Patreon.

devblog
diff --git a/devblog/debug_me_one_last_big_change/debug-me.png b/devblog/debug_me_one_last_big_change/debug-me.png
new file mode 100644
index 0000000..0212a17
Binary files /dev/null and b/devblog/debug_me_one_last_big_change/debug-me.png differ

point to debug-me website
diff --git a/code.mdwn b/code.mdwn
index 2aa5ac7..104c3e3 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -6,6 +6,7 @@ occasionally basic websites about my software.
 The stuff that's swapped into my local cache at the moment.
 
 [[git-annex]]
+[[debug-me]]
 [[propellor]]
 [[keysafe]]
 [[concurrent-output]]
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index dbe9209..f448552 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -1,171 +1,7 @@
-A not yet implemented idea from [[blog/entry/Re:_Debugging_over_email]]:
+secure remote debugging with gpg signed proof chain.
 
-> I've noticed that once I am in a position to run some commands in the
-> environment that has the problem, it seems to be much easier to solve
-> it than when I'm trying to get the user to debug it remotely. This must
-> be partly psychological?
-> 
-> Partly, I think that the feeling of being at a remove from the system,
-> makes it harder to think of what to do. And then there are the times where
-> the user pastes some output of running some commands and I mentally skip
-> right over an important part of it. Because I didn't think to run one of
-> the commands myself.
+<https://debug-me.branchable.com>
 
-`debug-me` lets a developer access your shell remotely, to debug a problem,
-avoiding a tedious back-and-forth by email. When you start `debug-me`, it
-starts a shell, and generates an URL which you can give to the developer
-(or developers) to connect them to the session.
+Initial idea: [[blog/entry/Re:_Debugging_over_email]]  
 
-It's not normally a good idea to let someone run commands in a shell on
-your computer. To make this as safe as possible, `debug-me` uses the
-GPG web of trust. Everything the developer sends to `debug-me` is signed
-with their GPG key, in a way that produces a GPG signed proof of what the
-developer saw, and what they did in the `debug-me` session.
-If the developer does something Evil, you have the neccessary proof
-to adjust their reputation.
-
-### design
-
-#### client-server
-
-This needs to be client-server, because a end user's machine is probably
-buried behind NAT. 
-
-It should use HTTPS, because of stupid firewalls. Will need to
-use some form of long polling to get multiple messages promptly in
-both directions.
-
-The user's client picks which server to use, connects, and
-gets an URL, which developers' clients can connect to in order to enter
-the session. Sharing that URL should be the only way for anyone to view
-the session (other than the person running the HTTP server).
-
-Multiple clients can be connected, and all send inputs. The user's
-client will only accept inputs GPG signed with keys that the user
-has granted access.
-
-When a new client connects, the whole session is sent to it, so it
-gets caught up and can start adding inputs to the chain.
-
-Other clients can connect and only record the session. This allows a user
-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 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.
-
-#### proof
-
-The developer activity proof takes the form of a chain of outputs and inputs.
-In other words, what the developer was shown, and what they did in response,
-and so on. Each input is GPG signed and includes the SHA256 hash of a
-previous output or input.
-
-A `debug-me` session starts by generating an initial output.
-Probably this is a shell prompt. (To prevent replay attacks
-of debug-me sessions it should also include a timestamp and/or a random token.)
-
-The developer enters a command, and their client hashes the last seen
-output and includes that in a GPG signed message with the command. The
-ouput of the command then arrives, and is hashed and included in the next
-GPG signed input message, and so on.
-
-There are two kinds of inputs: Synchronous and asynchronous.
-
-A synchronous input must include the hash of the output that it was made
-in response to, and will only be accepted by the user's client when that
-output is the last one that was sent. This way it's always clear what
-the state of the debug-me session was when the developer saw the output
-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. (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
-would have plausible deniability about what they intended that input to do.
-Perhaps they were not sending Y in response to "delete disk?", but to a
-previous question. So, inputs should not be resent. To prevent that,
-no message is sent to indicate when an input is rejected.
-
-Synchronous input interacts badly with terminal echo, because sending an
-input causes an echo output, and if that output has not been received by the
-time the next letter is input, the next input sent will be rejected. To
-deal with this, an input can include an echo block. If the echo block has
-the same content as the sum of outputs sent since the output that the input
-is in response to, then the input will be accepted.
-
-For example:
-
-	1. output "prompt>"
-	2. input "t" (previous: 1)
-	3. output "t" (previous: 2)
-	4. input "o" (previous: 1, echo: "t") -- valid because "t" = 3
-	5. output "o" (previous: 4)
-	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.
-
-##### proof truncation
-
-A proof can be truncated at any point in the chain and still be a valid
-proof of what happened in the session up to that point.
-
-One use case for this is that a developer might run a command to display
-known sensitive data (eg `.ssh/id_rsa`).
-
-An interface to truncate a proof could also upload the truncated version of
-it to a server. There would need to be a way for the user to to remove the
-full proof from the server.
-
-#### interface
-
-Interface is as close to a ssh session as possible.
-
-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 their terminal to enclose it,
-when the terminal sizes vary.
-
-It would be possible to have the user manually vet inputs and outputs,
-rather than generating a GPG signed proof of the developer's activity.
-But, this would significantly complicate things, by needing to display
-on the user's terminal what inputs and outputs remain to be vetted.
-The complication of implementing that does not seem worth it.
-Especially because manual vetting would introduce lag.
-
-It might be nice to have an integrated chat, but again this complicates
-the terminal handing significantly. User and developer can just as well
-chat on IRC anyway. Or run `screen` within `debug-me` and use one window
-to chat in.
-
-#### installation
-
-For `debug-me` to be most useful, it will need to be included in major
-distributions. It should also be as easy as possible to install manually.
-
-It may be helpful for programs to bundle `debug-me`, at least
-until the standalone `debug-me` is widely available. For example, I can
-imagine including it in the standalone git-annex bundles.
-
-#### other uses
-
-Something like this could be used in a few other ways than debugging:
-
-* Let anyone connect in watch-only mode. Could be used for
-  broadcasting both debugging sessions and other activity.
-* Moderated mode where N people connect and M of them need to approve
-  an action before it's accepted. Could be used to add security, or for
-  pair programming where both in the pair need to agree what to do.
+Initial design thoughts: [[initial_design]]
diff --git a/code/debug-me/initial_design.mdwn b/code/debug-me/initial_design.mdwn
new file mode 100644
index 0000000..dbe9209
--- /dev/null
+++ b/code/debug-me/initial_design.mdwn
@@ -0,0 +1,171 @@
+A not yet implemented idea from [[blog/entry/Re:_Debugging_over_email]]:
+

(Diff truncated)
add gpg key
diff --git a/links/personal.mdwn b/links/personal.mdwn
index bef4558..e47b4c5 100644
--- a/links/personal.mdwn
+++ b/links/personal.mdwn
@@ -3,4 +3,5 @@
 [[blog]]  
 [[pics]]  
 [[contact_me|contact]]  
+[[GPG key|contact]]  
 [[todo]]

devblog
diff --git a/devblog/debug_me_final_polishing.mdwn b/devblog/debug_me_final_polishing.mdwn
new file mode 100644
index 0000000..2506f9f
--- /dev/null
+++ b/devblog/debug_me_final_polishing.mdwn
@@ -0,0 +1,14 @@
+Fixed a tricky race condition that I think was responsible for some
+recent instability seen in debug-me when connecting to a session.
+It's a bit hard to tell because it caused at least 3 different types
+of crashes, and it was a race condition.
+
+Made debug-me prompt for the user's email address when it starts up, and
+then the server will email the session log to the user at the end. There
+are two reasons to do this. First, it guards against the developer
+connecting to the session, doing something bad, and deleting the user's
+local log file to cover their tracks. Second, it means the server doesn't
+have to retain old log files, which could be abused to store other data on
+servers.
+
+Also put together a basic web site, <https://debug-me.branchable.com/>.

update
diff --git a/devblog/debug_me_gpg_key_verification.mdwn b/devblog/debug_me_gpg_key_verification.mdwn
index cf8c951..71fd465 100644
--- a/devblog/debug_me_gpg_key_verification.mdwn
+++ b/devblog/debug_me_gpg_key_verification.mdwn
@@ -50,3 +50,12 @@ because wotsap still has to download the WoT database. (Also,
 the version of wotsap in debian is [outdated and insecure](http://bugs.debian.org/800134))
 The decentralized way is for the user do some key signing, get into the WoT,
 and then gpg can tell them if the key is trusted itself.
+
+----
+
+debug-me is now nearly feature-complete!
+
+It has some bugs, and a known problem with the evidence chain that
+needs to be fixed. And, I want to make debug-me servers email logs
+back to users, which will change the websockets protocol, so ought to be
+done before making any release.

devblog
diff --git a/devblog/debug_me_gpg_key_verification.mdwn b/devblog/debug_me_gpg_key_verification.mdwn
new file mode 100644
index 0000000..cf8c951
--- /dev/null
+++ b/devblog/debug_me_gpg_key_verification.mdwn
@@ -0,0 +1,52 @@
+Working on making debug-me verify the developer's gpg key.
+Here's what the user sees when I connect to them:
+
+	** debug-me session control and chat window
+	Someone wants to connect to this debug-me session.
+	Checking their Gnupg signature ...
+	gpg: Signature made Sat Apr 29 14:31:37 2017 JEST
+	gpg:                using RSA key 28A500C35207EAB72F6C0F25DB12DB0FF05F8F38
+	gpg: Good signature from "Joey Hess <joeyh@joeyh.name>" [unknown]
+	gpg:                 aka "Joey Hess <id@joeyh.name>" [unknown]
+	gpg:                 aka "Joey Hess <joey@kitenet.net>" [unknown]
+	gpg: WARNING: This key is not certified with a trusted signature!
+	gpg:          There is no indication that the signature belongs to the owner.
+	Checking the Gnupg web of trust ...
+	Joey Hess's identity has been verified by as many as 111 people, including:
+	Martin Michlmayr, Kurt Gramlich, Luca Capello, Christian Perrier, Axel Beckert,
+	Stefano Zacchiroli, Gerfried Fuchs, Eduard Bloch, Anibal Monsalve Salazar
+	
+	Joey Hess is probably a real person.
+	
+	Let them connect to the debug-me session and run commands? [y/n] 
+
+And here's what the user sees when a fake person connects:
+
+	** debug-me session control and chat window
+	Someone wants to connect to this debug-me session.
+	Checking their Gnupg signature ...
+	gpg: Signature made Sat Apr 29 14:47:29 2017 JEST
+	gpg:                using RSA key
+	gpg: Good signature from "John Doe" [unknown]
+	gpg: WARNING: This key is not certified with a trusted signature!
+	gpg:          There is no indication that the signature belongs to the owner.
+	Primary key fingerprint: B2CF F6EF 2F01 96B1 CD2C  5A03 16A1 2F05 4447 4791
+	Checking the Gnupg web of trust ...
+
+	Their identity cannot be verified!
+
+	Let them connect to the debug-me session and run commands? [y/n] 
+
+The debug-me user is likely not be connected to the gpg web of trust,
+so debug-me will download the developer's key from a keyserver,
+and uses the <https://pgp.cs.uu.nl/> service to check if the developer's
+key is in the strong set of the web of trust. It prints out the best-connected
+people who have signed the developer's key, since the user might recognise some
+of those names.
+
+While relying on a server to determine if the developer is in the strong set is
+not ideal, it would be no better to have debug-me depend on wotsap,
+because wotsap still has to download the WoT database. (Also,
+the version of wotsap in debian is [outdated and insecure](http://bugs.debian.org/800134))
+The decentralized way is for the user do some key signing, get into the WoT,
+and then gpg can tell them if the key is trusted itself.

devblog
diff --git a/devblog/debug_me_control_window.mdwn b/devblog/debug_me_control_window.mdwn
new file mode 100644
index 0000000..940c6c7
--- /dev/null
+++ b/devblog/debug_me_control_window.mdwn
@@ -0,0 +1,44 @@
+I've been trying to write a good description of debug-me, and here's
+what I've got so far:
+
+Short description: "secure remote debugging"
+
+Long description:
+
+> Debugging a problem over email is slow, tedious, and hard. The developer
+> needs to see the your problem to understand it. Debug-me aims to make
+> debugging fast, fun, and easy, by letting the developer access your
+> computer remotely, so they can immediately see and interact with the
+> problem. Making your problem their problem gets it fixed fast.
+> 
+> A debug-me session is logged and signed with the developer's Gnupg
+> key, producing a chain of evidence of what they saw and what they did.
+> So the developer's good reputation is leveraged to make debug-me secure.
+> 
+> When you start debug-me without any options, it will connect to a debug-me
+> server, and print out an url that you can give to the developer to get
+> them connected to you. Then debug-me will show you their Gnupg key and who
+> has signed it. If the developer has a good reputation, you can proceed
+> to let them type into your console in a debug-me session. Once the
+> session is done, the debug-me server will email you the signed
+> evidence of what the developer did in the session.
+> 
+> If the developer did do something bad, you'd have proof that they cannot
+> be trusted, which you can share with the world. Knowing that is the case
+> will keep most developers honest.
+
+I think that's pretty good, and would like to know your thoughts, reader,
+as a prospective debug-me user.
+
+----
+
+Most of today was spent making `debug-me --control` communicate over a socket
+with the main debug-me process. That is run in a separate window,
+which is the debug-me session control and chat window. Things typed there
+can be seen by the other people involved in a debug-me session. And, the gnupg
+key prompting stuff will be done in that window eventually.
+
+Screenshot of the first time that worked. The "user" is on the left and the
+"developer" is on the right.
+
+[[screenshot.png]]
diff --git a/devblog/debug_me_control_window/screenshot.png b/devblog/debug_me_control_window/screenshot.png
new file mode 100644
index 0000000..01d425c
Binary files /dev/null and b/devblog/debug_me_control_window/screenshot.png differ

add
diff --git a/blog/entry/Exede_Surfbeam_2.mdwn b/blog/entry/Exede_Surfbeam_2.mdwn
new file mode 100644
index 0000000..809e639
--- /dev/null
+++ b/blog/entry/Exede_Surfbeam_2.mdwn
@@ -0,0 +1,108 @@
+My new satellite internet connection is from Exede, connecting to the
+ViaSat 1 bird in geosync orbit.  A few technical details that I've observed
+follow.
+
+## antagonistic by design
+
+The "Surfbeam 2 wifi modem" is a closed proprietary system. That is important
+because it's part of Exede's bandwidth management system. The Surfbeam tracks
+data use and sends it periodically to Exede. When a user has gone over
+their monthly priority data, Exede then throttles the bandwidth in various
+ways -- this throttling seems to be implemented, at least partially on the
+Surfbeam itself. (Perhaps by setting QoS flags?)
+
+So, if a user could hack their Surfbeam, they could probably bypass the
+bandwidth caps, or at least some of them. Perhaps Exede would notice
+eventually. Of course, doing so would surely violate the Exede TOS. If
+you're renting the modem, like I am, hacking a device you don't own might
+also subject you to criminal penalties. Needless to say, I don't plan to
+hack the SurfBeam. But
+[it's been hacked before](https://www.youtube.com/watch?v=7QTVi9CPQDw).
+
+So, this is a device that lives in people's homes and is
+antagonistic to them by design.
+
+## weird data throttling
+
+The way the Surfbeam reports data use back to Exede periodically and gets
+throttling configured has some odd effects sometimes. For example, the
+Surfbeam can be in throttled state left-over from the previous billing
+month. When a new billing month begins, it can remain throttled for
+some time (up to multiple hours) until it sends an update to Exede and
+they un-throttle it. Data downloaded at that time might still be counted as
+priority data even though it was throttled. I've seen some good indications
+of that happening, but am not sure yet.
+
+But, I've decided that the throttling doesn't matter for me. Why? ViaSat 1
+has many spot beams, and the working-class beam I'm in (most of it is in
+eastern Kentucky) does not seem to get a lot of use between 7 am and 4:30 pm
+weekdays. Even when throttled, I often get 300 kb/s - 1 mb/s speeds
+during the day, which is not a lot worse than the ~2.5 mb/s peak when
+unthrottled. And that's the time when I want to use broadband -- when the sun
+is shining and I'm at home at work/play. I'm probably going to switch to a
+cheaper plan with less priority data, because the priority data is not
+buying me much. This is a *big* change from the old FAP which rendered
+the satellite no faster than dialup.
+
+## a whole network in there
+
+Looking at the ports open on the Surfbeam, some very strange things
+turned up. First, there are not one, not two, but **three** separate IPs
+used by the device, and there are at least two and perhaps three distinct
+computers involved. There are a lot of flickering LEDs **inside**
+the box; a whole network in there.
+
+192.168.100.1 is the satellite controller. It's a Linux box, fingerprinted
+as kernel 3.10 or so (so full of security holes presumably), and it's running 
+thttpd/2.25b (doesn't seem to have any known holes). 
+It seems to have ssh and snmp, but with some port filtering that
+prevents access. (Note that the above exploit video confirms
+that snmp is running.) Some machine parsable data is exposed at
+<http://192.168.100.1/index.cgi?page=modemStatusData> and
+<http://192.168.100.1/index.cgi?page=triaStatusData>. (See
+([SurfStat program](https://github.com/blachniet/SurfStat/))
+
+192.168.1.1 is the wifi router. It has a dns server, an icslap proxy, and
+nmap thinks it's Linux 3.x with Synology DiskStation Manager (probably the
+latter is a false positive?) It has its own separate web server for
+configuration, which is not thttpd. I'm fairly sure this is a separate
+processor from the other IP address.
+
+192.168.100.2 responds to ICMP, but has no open ports at all. However, it
+seems to have filtered ssh, telnet, msrpc, microsoft-ds, and port 8090
+(probably http), so perhaps it's running all that stuff. This one
+is definitely a separate processor, located in the Satellite dish's
+TRIA (transmit receive integrated assembly). Verified by disconnecting the
+dish's coax cable and being unable to ping it.
+
+## lack of source code for GPLed software
+
+Exede did not provide anything to me about the GPL licensed source code on
+the Surfbeam 2. I'm not sure if they're legally required to do so in my
+case, since they're renting it to me?
+
+But, they do let you buy the device too, so it's interesting that nothing
+mentions the licenses of its software and where to get the source code.
+I'll try to buy it and ask for the source code eventually.
+
+## power use
+
+The Surfbeam pulls as much power as two beefy laptops, but it is beaming
+signals thousands of miles into space, so I give it a bit of a pass.
+I want to find a way to power it from DC power, but have not had any
+success with that so far, so am wasting more power to run it on an
+inverter.
+
+Its power supply is rated at 30v and 2.5 amps. Interestingly, I've seen a
+photo of another Surfbeam power supply that only pulls 1.5 amps. This and
+a different case with fewer (external) LEDs makes me think perhaps the
+installer stuck me with an old and less efficient version. Maybe they
+integrated some of those processors into a single board in a new version
+and perhaps made it waste less power as heat. Mine gets pretty warm.
+
+I'm currently only able to run it approximately one hour per hour of sun
+collected by the house. Still on dialup the rest of the time. With the
+ability to get on broadband when dialup is being painful, being on dialup
+the rest of the time is perfectly ok. Of course it helps that with tools
+like [[code/git-annex]], I'm very well tuned to popping up onto broadband
+briefly and making it count.

devbog
diff --git a/devblog/debug_me_finalizing_wire_format.mdwn b/devblog/debug_me_finalizing_wire_format.mdwn
new file mode 100644
index 0000000..98780d4
--- /dev/null
+++ b/devblog/debug_me_finalizing_wire_format.mdwn
@@ -0,0 +1,19 @@
+Went ahead and made debug-me use protocol buffers for its wire protocol.
+There's a nice haskell library for this that doesn't depend on anything
+else, and can generate them directly from data types, but I had to write a
+shim between the protobuf style data types and debug-me's internal
+data types. Took 250 lines of quite tedious code.
+
+Then I finally implemented the trick I thought of to leave out the previous
+hash from debug-me messages on the wire, while still including
+cryptograhically secure proof of what the previous hash was. That reduced
+the overhead of a debug-me message from 168 bytes to 74 bytes!
+
+I doubt debug-me's wire format will see any more major changes.
+
+How does debug-me compare with ssh? I tried some experiments, and
+typing a character in ssh sends 180 bytes over the wire, while doing the
+same in debug-me sends 326 bytes. The extra overhead must be due to using
+websockets, I guess. At least debug-me is in the same ballpark as ssh.
+
+Today's work was sponsored by Riku Voipio.

devblog
diff --git a/devblog/debug_me_polishing.mdwn b/devblog/debug_me_polishing.mdwn
new file mode 100644
index 0000000..d3f9495
--- /dev/null
+++ b/devblog/debug_me_polishing.mdwn
@@ -0,0 +1,30 @@
+Working on polishing up debug-me's features to not just work, but work
+well.
+
+On Monday, I spent much longer than expected on the problem that when a
+debug-me session ended, clients attached to it did not shut down.
+The session shutdown turned out to have worked by accident in one case,
+but it was lacking a proper implementation, and juggling all the threads
+and channels and websockets to get everything to shut down cleanly was
+nontrivial.
+
+Today, I fixed a bug that made `debug-me --download` fail while downloading a
+session, because the server didn't relay messages from developers, and so
+the proof chain was invalid. After making the server relay those messages,
+and handling them, that was fixed -- and I got a great feature for free:
+Multiple developers can connect to a debug-me session and all interact with
+it at the same time!
+
+Also, added timing information to debug-me messages. While time is relative
+and so it can't be proved how long the time was between messages in the
+debug-me proof chain, including that information lets `debug-me --download`
+download a session and then `debug-me --replay` can replay the log file
+with realistic pauses.
+
+Started on gpg signing and signature verification, but that has a user
+interface problem. If the developer connects after the debug-me session has
+started, prompting the user on the same terminal that is displaying the
+session would not be good. This is where it'd be good to have a library for
+[[blog/entry/multi-terminal_applications]]. Perhaps I should go build a
+prototype of that. Of perhaps I'll make debug-me wait for one developer to
+connect and prompt the user before starting the session.

introduce kaitai
diff --git a/devblog/debug_me_websockets/discussion.mdwn b/devblog/debug_me_websockets/discussion.mdwn
new file mode 100644
index 0000000..5e2c3f6
--- /dev/null
+++ b/devblog/debug_me_websockets/discussion.mdwn
@@ -0,0 +1,3 @@
+re. protobufs - i think that would be an improvement: it seems like a good idea to decouple language-specific data structures from the protocol, if only to make debugging easier, but it seems like a good idea also to allow for better extensibility (e.g. writing different client/servers implementations)...
+
+An interesting approach I have found is the language-neutral [kaitai.io](http://kaitai.io/) specification system. it's a YAML-like metadata description language that translates into multiple languages like Java, Python, PHP, Ruby, C++ but, unfortunately, not Haskell just yet. I find it an interesting alternative to protobufs because you are not bound by a certain data format - you can just write your own binary language (or port existing ones) by specifying its metadata clearly... --[[anarcat]]

update
diff --git a/devblog/debug_me_client-server_working.mdwn b/devblog/debug_me_client-server_working.mdwn
index 9cc0a96..b0bd508 100644
--- a/devblog/debug_me_client-server_working.mdwn
+++ b/devblog/debug_me_client-server_working.mdwn
@@ -1,5 +1,12 @@
 Got debug-me fully working over the network today. It's allllive!
 
+Hardest thing today was when a developer connects and the server needs to
+send them the backlog of the session before they start seeing current
+activity. Potentially full of races. My implementation avoids race
+conditions, but might cause other connected developers to see a stall in
+activity at that point. A stall-free version is certianly doable, but this
+is good enough for now.
+
 There are quite a few bugs to fix. Including a security hole in the proof
 chain design, that I realized it had when thinking about what happens whith
 multiple people are connected to a debug-me session who are all typing at

devblog
diff --git a/devblog/debug_me_client-server_working.mdwn b/devblog/debug_me_client-server_working.mdwn
new file mode 100644
index 0000000..9cc0a96
--- /dev/null
+++ b/devblog/debug_me_client-server_working.mdwn
@@ -0,0 +1,14 @@
+Got debug-me fully working over the network today. It's allllive!
+
+There are quite a few bugs to fix. Including a security hole in the proof
+chain design, that I realized it had when thinking about what happens whith
+multiple people are connected to a debug-me session who are all typing at
+once.
+
+(There have actually been 3 security holes spotted over the past day; the
+one above, a lacking sanitization of session IDs, and a bug in the server
+that let a developer truncate logs.)
+
+So I need to spend several mode days bugfixing, and also make it only allow
+connections signed by trusted gpg keys. Still, an initial release does not
+seem far off now.

update
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 882aec0..dbe9209 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -24,12 +24,6 @@ developer saw, and what they did in the `debug-me` session.
 If the developer does something Evil, you have the neccessary proof
 to adjust their reputation.
 
-As well as checking the GPG web of trust, `debug-me` can clone the git
-repository of the program that it's being used to debug, and check for GPG
-signed git tags and commits made using the developer's key. This helps you
-tell if the person connecting to `debug-me` is a developer of the program
-being debugged.
-
 ### design
 
 #### client-server
diff --git a/devblog/debug_me_websockets.mdwn b/devblog/debug_me_websockets.mdwn
index c9e7ce6..fd67d81 100644
--- a/devblog/debug_me_websockets.mdwn
+++ b/devblog/debug_me_websockets.mdwn
@@ -10,3 +10,11 @@ protocol buffers to make it less of a haskell-specific wire format.
 Currently, the client and server basically work; the client can negotiate
 a protocol version with the server and send messages to it, which the
 server logs.
+
+----
+
+Also, added two additional modes to debug-me. `debug-me --download url` will
+download a debug-me log file. If that session is still running, it keeps
+downloading until it's gotten the whole session. `debug-me --watch url`
+connects to a debug-me session, and displays it in non-interactive mode.
+These were really easy to implement, reusing existing code.

devblog
diff --git a/devblog/debug_me_websockets.mdwn b/devblog/debug_me_websockets.mdwn
new file mode 100644
index 0000000..c9e7ce6
--- /dev/null
+++ b/devblog/debug_me_websockets.mdwn
@@ -0,0 +1,12 @@
+Worked today on making debug-me run as a client/server, communicating using
+websockets.
+
+I decided to use the "binary" library to get an efficient serialization of
+debug-me's messages to send over the websockets, rather than using JSON.
+A typicaly JSON message was 341 bytes, and this only uses 165 bytes, which
+is fairly close to the actual data size of ~129 bytes. I may later use
+protocol buffers to make it less of a haskell-specific wire format.
+
+Currently, the client and server basically work; the client can negotiate
+a protocol version with the server and send messages to it, which the
+server logs.

update
diff --git a/blog/entry/propelling_containers.mdwn b/blog/entry/propelling_containers.mdwn
index 170f568..086a6ed 100644
--- a/blog/entry/propelling_containers.mdwn
+++ b/blog/entry/propelling_containers.mdwn
@@ -139,4 +139,11 @@ infinitelyNestedContainer = Systemd.container "evil-systemd"
 Strongly typed purely functional container deployment can only protect us
 against a certian subset of all badly thought out systems. ;)
 
+----
+
+Note that the above was written in 2014 and some syntatix details have
+changed. See the documentation for Propellor.Property.Chroot,
+Propellor.Property.Debootstrap,  Propellor.Property.Docker,
+Propellor.Property.Systemd for current examples.
+
 [[!meta title="propelling containers"]]

devblog
diff --git a/devblog/debug_me_signatures.mdwn b/devblog/debug_me_signatures.mdwn
new file mode 100644
index 0000000..640d8a6
--- /dev/null
+++ b/devblog/debug_me_signatures.mdwn
@@ -0,0 +1,23 @@
+Added signatures to the debug-me protocol today. All messages are signed
+using a ed25519 session key, and the protocol negotiates these keys.
+
+Here's a dump of a debug-me session, including session key exchange:
+
+	{"ControlMessage":{"control":{"SessionKey":[{"b64":"it8RIgswI8IZGjjQ+/INPjGYPAcGCwN9WmGZNlMFoX0="},null]},"controlSignature":{"Ed25519Signature":{"b64":"v80m5vQbgw87o88+oApg0syUk/vg88t14nIfXzahwAqEes/mqY4WWFIbMR46WcsEKP2fwfXQEN5/nc6UOagBCQ=="}}}}
+	{"ActivityMessage":{"prevActivity":null,"activitySignature":{"Ed25519Signature":{"b64":"HNPk/8QF7iVtsI+hHuO1+J9CFnIgsSrqr1ITQ2eQ4VM7rRPG7i07eKKpv/iUwPP4OdloSmoHLWZeMXZNvqnCBQ=="}},"activity":{"seenData":{"v":">>> debug-me session starting\r\n"}}}}
+	{"ActivityMessage":{"prevActivity":{"hashValue":{"v":"63d31b25ca262d7e9fc5169d137f61ecef20fb65c23c493b1910443d7a5514e4"},"hashMethod":"SHA256"},"activitySignature":{"Ed25519Signature":{"b64":"+E0N7j9MwWgFp+LwdzNyByA5W6UELh6JFxVCU7+ByuhcerVO/SC2ZJJJMq8xqEXSc9rMNKVaAT3Z6JmidF+XAw=="}},"activity":{"seenData":{"v":"$ "}}}}
+	{"ControlMessage":{"control":{"SessionKey":[{"b64":"dlaIEkybI5j3M/WU97RjcAAr0XsOQQ89ffZULVR82pw="},null]},"controlSignature":{"Ed25519Signature":{"b64":"hlyf7SZ5ZyDrELuTD3ZfPCWCBcFcfG9LP7Zuy+roXwlkFAv2VtpYrFAAcnWSvhloTmYIfqo5LWakITPI0ITtAQ=="}}}}
+	{"ControlMessage":{"control":{"SessionKeyAccepted":[{"b64":"dlaIEkybI5j3M/WU97RjcAAr0XsOQQ89ffZULVR82pw="},null]},"controlSignature":{"Ed25519Signature":{"b64":"kJ7AdhBgoiYfsXOM//4mcMcU5sL0oyqulKQHUPFo2aYYPJnu5rKUHlfNsfQbGDDrdsl9SocZaacUpm+FoiDCCg=="}}}}
+	{"ActivityMessage":{"prevActivity":{"hashValue":{"v":"2250d8b902683053b3faf5bdbe3cfa27517d4ede220e4a24c8887ef42ab506e0"},"hashMethod":"SHA256"},"activitySignature":{"Ed25519Signature":{"b64":"hlF7oFhFealsf8+9R0Wj+vzfb3rBJyQjUyy7V0+n3zRLl5EY88XKQzTuhYb/li+WoH/QNjugcRLEBjfSXCKJBQ=="}},"activity":{"echoData":{"v":""},"enteredData":{"v":"l"}}}}
+
+Ed25519 signatures add 64 bytes overhead to each message, on top of the
+64 bytes for the hash pointer to the previous message. But, last night I
+thought of a cunning plan to remove that hash pointer from the wire
+protocol, while still generating a provable hash chain. Just leave it out
+of the serialized message, but include it in the data that's signed.
+debug-me will then just need to try the hashes of recent messages until
+it finds one for which the signature verifies, and then it will know
+what the hash pointer is supposed to point to, without it ever having been
+sent over the wire! Will implement this trick eventually.
+
+Next though, I need to make debug-me communicate over the network.

add news item for moreutils 0.61
diff --git a/code/moreutils/news/version_0.56.mdwn b/code/moreutils/news/version_0.56.mdwn
deleted file mode 100644
index 5451197..0000000
--- a/code/moreutils/news/version_0.56.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-moreutils 0.56 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * ifdata: Fix error messages when a non-existent network interface
-     is queried. Closes: #[386754](http://bugs.debian.org/386754) Thanks, Nicolas Schier
-   * errno.docbook: Fix typo. Closes: #[749399](http://bugs.debian.org/749399)
-   * vidir: Create missing target directories. Closes: #[728688](http://bugs.debian.org/728688)
-     Thanks, Nicolas Schier"""]]
\ No newline at end of file
diff --git a/code/moreutils/news/version_0.61.mdwn b/code/moreutils/news/version_0.61.mdwn
new file mode 100644
index 0000000..56e22de
--- /dev/null
+++ b/code/moreutils/news/version_0.61.mdwn
@@ -0,0 +1,4 @@
+moreutils 0.61 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * chronic: Flush output more often to better preserve stdout,err ordering.
+     Thanks, Miroslav Šustek"""]]
\ No newline at end of file

typo
diff --git a/devblog/debug_me_first_stage_complete.mdwn b/devblog/debug_me_first_stage_complete.mdwn
index 42ce096..bca2f58 100644
--- a/devblog/debug_me_first_stage_complete.mdwn
+++ b/devblog/debug_me_first_stage_complete.mdwn
@@ -9,7 +9,7 @@ actual networked debug-me is done now. I only have to add signing,
 verification of gpg key trust, and http client-server to finish debug-me.
 
 (Also, I made `debug-me --replay debug-me.log` replay the log with
-realistic delays, like [[code/scriptreply]] or `ttyplay`. Only took a page
+realistic delays, like [[code/scriptreplay]] or `ttyplay`. Only took a page
 of code to add that feature.)
 
 ----

devblog
diff --git a/devblog/debug_me_first_stage_complete.mdwn b/devblog/debug_me_first_stage_complete.mdwn
new file mode 100644
index 0000000..42ce096
--- /dev/null
+++ b/devblog/debug_me_first_stage_complete.mdwn
@@ -0,0 +1,40 @@
+Solved that bug I was stuck on yesterday. I had been looking in the code
+for the developer side for a bug, but that side was fine; the bug was
+excessive backlog trimming on the user side.
+
+Now I'm fairly happy with how debug-me's activity chains look,
+and the first stage of developing debug-me is complete. It still doesn't do
+anything more than the `script` command, but all the groundwork for the
+actual networked debug-me is done now. I only have to add signing,
+verification of gpg key trust, and http client-server to finish debug-me.
+
+(Also, I made `debug-me --replay debug-me.log` replay the log with
+realistic delays, like [[code/scriptreply]] or `ttyplay`. Only took a page
+of code to add that feature.)
+
+----
+
+I'm only "fairly happy" with the activity chains because there is a
+weird edge case.. At high latency, when typing "qwertyuiop", this
+happens:
+
+[[debug-me.log.png]]
+
+That looks weird, and is somewhat hard to follow in graph form, but
+it's "correct" as far as debug-me's rules for activity chains go.
+Due to the lag, the chain forks:
+
+* It sends "wer" before the "q" echos back
+* It replies to the "q" echo with tyuio" before
+  the "w" echos back.
+* It replies to the "w" echo with "p"
+* Finally, all the delayed echos come in, and it sends
+  a carriage return, resulting in the command being run.
+
+I'd be happier if the forked chain explicitly merged back together,
+but to do that and add any provable information, the developer would have
+to wait for all the echos to arrive before sending the carriage return,
+or something like that, which would make type-ahead worse. So I think I'll
+leave it like this. Most of the time, latency is not so high, and so this
+kind of forking doesn't happen much or is much simpler to understand when
+it does happen.
diff --git a/devblog/debug_me_first_stage_complete/debug-me.log.png b/devblog/debug_me_first_stage_complete/debug-me.log.png
new file mode 100644
index 0000000..68a11ec
Binary files /dev/null and b/devblog/debug_me_first_stage_complete/debug-me.log.png differ

devblog
diff --git a/devblog/debug_me_chain_issues.mdwn b/devblog/debug_me_chain_issues.mdwn
new file mode 100644
index 0000000..5d6b80f
--- /dev/null
+++ b/devblog/debug_me_chain_issues.mdwn
@@ -0,0 +1,18 @@
+Working on getting the debug-me proof chain to be the right shape,
+and be checked at all points for valididity. This graph of a session
+shows today'ss progress, but also a bug.
+
+[[debug-me.log.png]]
+
+At the top, everything is synchronous while "ls" is entered and echoed back. 
+Then, things go asynchronous when " -la" is entered, and
+the expected echos (in brackets) match up with what really gets
+echoed, so that input is also accepted.
+
+Finally, the bit in red where "|" is entered is a bug
+on the developer side, and it gets (correctly) rejected
+on the user side due to having forked the proof chain. Currently stuck on
+this bug.
+
+The code for this, especially on the developer side, is rather hairy,
+I wonder if I am missing a way to simplify it.
diff --git a/devblog/debug_me_chain_issues/debug-me.log.png b/devblog/debug_me_chain_issues/debug-me.log.png
new file mode 100644
index 0000000..f9ef5de
Binary files /dev/null and b/devblog/debug_me_chain_issues/debug-me.log.png differ

oops
diff --git a/devblog/debug_me_half_days.mdwn b/devblog/debug_me_half_days.mdwn
index 1269ca5..8587494 100644
--- a/devblog/debug_me_half_days.mdwn
+++ b/devblog/debug_me_half_days.mdwn
@@ -35,4 +35,4 @@ when a person used debug-me to do something bad.
 Wrote a quick visualizor for debug-me logs using graphviz. This will be
 super useful for debug-me development if nothing else.
 
-[[!debug-me.log.png]]
+[[debug-me.log.png]]

devblog
diff --git a/devblog/debug_me_half_days.mdwn b/devblog/debug_me_half_days.mdwn
new file mode 100644
index 0000000..1269ca5
--- /dev/null
+++ b/devblog/debug_me_half_days.mdwn
@@ -0,0 +1,38 @@
+Two days only partially spent on debug-me..
+
+Yesterday a few small improvements, but mostly I discovered the
+[posix-pty](http://hackage.haskell.org/package/posix-pty) library, and
+converted debug-me to use it rather than wrangling ptys itself. Which
+was nice because it let me fix resizing. However, the library had a bug
+with how it initializes the terminal, and investigating and working around
+that bug used up too much time. Oh well, probably still worth it.
+
+----
+
+Today, made debug-me serialize to and from JSON. 
+
+	{"signature":{"v":""},"prevActivity":null,"activity":{"seenData":{"v":">>> debug-me session starting\r\n"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"fb4401a717f86958747d34f98c079eaa811d8af7d22e977d733f1b9e091073a6"},"hashMethod":"SHA256"},"activity":{"seenData":{"v":"$ "}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"cfc629125d93f55d2a376ecb9e119c89fe2cc47a63e6bc79588d6e7145cb50d2"},"hashMethod":"SHA256"},"activity":{"echoData":{"v":""},"enteredData":{"v":"l"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"cfc629125d93f55d2a376ecb9e119c89fe2cc47a63e6bc79588d6e7145cb50d2"},"hashMethod":"SHA256"},"activity":{"seenData":{"v":"l"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"3a0530c7739418e22f20696bb3798f8c3b2caf7763080f78bfeecc618fc5862e"},"hashMethod":"SHA256"},"activity":{"echoData":{"v":""},"enteredData":{"v":"s"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"3a0530c7739418e22f20696bb3798f8c3b2caf7763080f78bfeecc618fc5862e"},"hashMethod":"SHA256"},"activity":{"seenData":{"v":"s"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"91ac86c7dc2445c18e9a0cfa265585b55e01807e377d5f083c90ef307124d8ab"},"hashMethod":"SHA256"},"activity":{"echoData":{"v":""},"enteredData":{"v":"\r"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"91ac86c7dc2445c18e9a0cfa265585b55e01807e377d5f083c90ef307124d8ab"},"hashMethod":"SHA256"},"activity":{"seenData":{"v":"\r\n"}}}
+	{"signature":{"v":""},"prevActivity":{"hashValue":{"v":"cc97177983767a5ab490d63593011161e2bd4ac2fe00195692f965810e6cf3bf"},"hashMethod":"SHA256"},"activity":{"seenData":{"v":"AGPL\t    Pty.hs    Types.hs\t  debug-me.cabal  dist\r\nCmdLine.hs  Setup.hs  Val.hs\t  debug-me.hs\t  stack.yaml\r\n"}}}
+
+That's a pretty verbose way of saying: I typed "ls" and saw the list of
+files. But it compresses well. Each packet for a single keystroke will
+take only 37 bytes to transmit as part of a compressed stream of JSON,
+and 32 of those bytes are needed for the SHA256 hash. So, this is probably
+good enough to use as debug-me's wire format.
+
+(Some more bytes will be needed once the signature field is not empty..)
+
+It's also a good logging format, and can be easily analized to eg, prove
+when a person used debug-me to do something bad.
+
+Wrote a quick visualizor for debug-me logs using graphviz. This will be
+super useful for debug-me development if nothing else.
+
+[[!debug-me.log.png]]
diff --git a/devblog/debug_me_half_days/debug-me.log.png b/devblog/debug_me_half_days/debug-me.log.png
new file mode 100644
index 0000000..657346a
Binary files /dev/null and b/devblog/debug_me_half_days/debug-me.log.png differ

remove discussion from feed
diff --git a/devblog.mdwn b/devblog.mdwn
index 8b84e79..1ad7dab 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -1,7 +1,7 @@
 Joey blogs about his work here on a semi-daily basis. For lower post
 frequency and wider-interest topics, see the main [[blog]].
 
-[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*) or tagged(devblog)" show=365]]
+[[!inline pages="(page(devblog/*) and !page(devblog/*/*)) or internal(devblog/git-annex_devblog/*) or tagged(devblog)" show=365]]
 
 ----
 

devblog
diff --git a/devblog/debug_me_day_2.mdwn b/devblog/debug_me_day_2.mdwn
new file mode 100644
index 0000000..e388895
--- /dev/null
+++ b/devblog/debug_me_day_2.mdwn
@@ -0,0 +1,49 @@
+Proceeding as planned, I wrote 170 lines of code to make [[code/debug-me]]
+have separate threads for the user and developer sides, which send
+one-another updates to the activity chain, and check them for validity.
+This was fun to implement! And it's lacking only signing to be a full
+implementation of the debug-me proof chain.
+
+Then I added a network latency simulation to it and tried different
+latencies up to the latency I measure on my satellite internet link
+(800 ms or so)
+
+That helped me find two bugs, where it was not handling echo simulation
+correctly. Something is still not handled quite right, because when
+I put a network latency delay before sending output from the user
+side to the developer side, it causes some developer input to get rejected.
+So I'm for now only inserting latency when the developer is sending input
+to the user side. Good enough for proof-of-concept.
+
+Result is that, even with a high latency, it feels "natural" to type
+commands into debug-me. The echo emulation works, so it accepts
+typeahead.
+
+Using backspace to delete several letters in a row feels "wrong";
+the synchronousness requirements prevent that working when latency
+is high. Same problem for moving around with the arrow keys.
+Down around 200 ms latency, these problems are not apparent, unless
+you mash down the backspace or arrow key.
+
+How about using an editor? It seemed reasonably non-annoying at 200 ms
+latency, although here I do tend to mash down arrow keys and then it
+moves too fast for debug-me to keep up, and so the cursor movement stalls.
+
+At higher latencies, using an editor was pretty annoying. Where I might
+normally press the down arrow key N distinct times to get to the line
+I wanted, that doesn't work in debug-me at 800 ms latency. Of course,
+over such a slow connection, using an editor is the last thing you want to
+do anyway, and vi key combos like 9j start to become necessary (and work
+in debug-me).
+
+Based on these experiements, the synchronousness requirements are not as
+utterly annoying as I'd feared, especially at typical latencies.
+
+And, it seems worth making debug-me detect when several keys are pressed
+close together, and send a single packet over the network combining those.
+That should make it behave better when mashing down a key.
+
+----
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh)

diff --git a/devblog/debug_me_day_1/discussion.mdwn b/devblog/debug_me_day_1/discussion.mdwn
new file mode 100644
index 0000000..6736454
--- /dev/null
+++ b/devblog/debug_me_day_1/discussion.mdwn
@@ -0,0 +1 @@
+Not sure if you're aware of the Linux network emulation framework, but if not: [[https://wiki.linuxfoundation.org/networking/netem]] — that will let you simulate all kinds of terrible networks.

format
diff --git a/devblog/debug_me_day_1.mdwn b/devblog/debug_me_day_1.mdwn
index 0ac26d6..b83333a 100644
--- a/devblog/debug_me_day_1.mdwn
+++ b/devblog/debug_me_day_1.mdwn
@@ -27,6 +27,6 @@ time to finish that today, so next time.
 debug-me's git repository is available from
 <https://git.joeyh.name/index.cgi/debug-me.git/>
 
--- 
+---- 
 
 Today's work was sponsored by andrea rota.

blog update
diff --git a/blog/entry/starting_debug-me_and_a_new_devblog.mdwn b/blog/entry/starting_debug-me_and_a_new_devblog.mdwn
new file mode 100644
index 0000000..e550dd3
--- /dev/null
+++ b/blog/entry/starting_debug-me_and_a_new_devblog.mdwn
@@ -0,0 +1,10 @@
+I've started building [[code/debug-me]]. It's my birthday, and building a
+new program is kind of my birthday gift to myself, because I love starting
+a new program and seeing where it goes.
+(Also, my [Patreon](https://www.patreon.com/joeyh)
+backers wanted me to get on with building debug-me.)
+
+I also have a new [[devblog]]! Up until now, I've had a devblog that only
+covered work on git-annex. That one continues, but the new devblog is for
+development journaling for any project I'm working on.
+<http://joeyh.name/devblog/>
diff --git a/devblog/debug_me_day_1.mdwn b/devblog/debug_me_day_1.mdwn
new file mode 100644
index 0000000..0ac26d6
--- /dev/null
+++ b/devblog/debug_me_day_1.mdwn
@@ -0,0 +1,32 @@
+Started some exploratory programming on the [[code/debug-me]] idea.
+
+First, wrote down some data types for debug-me's proof of developer activity.
+
+Then, some terminal wrangling, to get debug-me to allocate a
+pseudo-terminal, run an interactive shell in it, and pass stdin
+and stdout back and forth to the terminal it was started in.
+At this point, debug-me is very similar to `script`, except 
+it doesn't log the data it intercepts to a `typescript` file.
+
+Terminals are complicated, so this took a while, and it's still not perfect,
+but good enough for now. Needs to have resize handling added, and for some
+reason when the program exits, the terminal is left in a raw state, despite
+the program apparently resetting its attributes.
+
+Next goal is to check how annoying debug-me's insistence on a
+synchronous activity proof chain will be when using debug-me across a
+network link with some latency. If that's too annoying, the design
+will need to be changed, or perhaps won't work.
+
+To do that, I plan to make debug-me simulate a network between the user and
+developer's processes, using threads inside a single process for now. The
+user thread will builds up an activity chain, and only accepts inputs from the
+developer thread when they meet the synchronicity requirements. Ran out of
+time to finish that today, so next time.
+
+debug-me's git repository is available from
+<https://git.joeyh.name/index.cgi/debug-me.git/>
+
+-- 
+
+Today's work was sponsored by andrea rota.

diff --git a/grep/identi.ca_posts/scuttlebutt/discussion.mdwn b/grep/identi.ca_posts/scuttlebutt/discussion.mdwn
index d5a1b6f..0c7f45b 100644
--- a/grep/identi.ca_posts/scuttlebutt/discussion.mdwn
+++ b/grep/identi.ca_posts/scuttlebutt/discussion.mdwn
@@ -4,4 +4,4 @@ Then today, looking over the project's github repos, I noticed an attempt at a [
 
 Although compared to keysafe's independent servers, it seems much _more_ possible for two people you know to both have been compromised (or just to collude, but presumably they'd have a good reason for doing so).
 
-- NickNovitski
+\- NickNovitski

diff --git a/grep/identi.ca_posts/scuttlebutt/discussion.mdwn b/grep/identi.ca_posts/scuttlebutt/discussion.mdwn
new file mode 100644
index 0000000..d5a1b6f
--- /dev/null
+++ b/grep/identi.ca_posts/scuttlebutt/discussion.mdwn
@@ -0,0 +1,7 @@
+I'm not a user of it yet, but by chance I noticed your activity mixed into the git-ssb-web feed the other day, including commits on keysafe, which I had never heard of before.
+
+Then today, looking over the project's github repos, I noticed an attempt at a [Shamir's Secret Sharing backup system](https://github.com/ssbc/ssb-horcrux).  It seems to work by just sending the shares to your choice of friends.  As I understand it, unlike email, it not possible for them to delete the message.
+
+Although compared to keysafe's independent servers, it seems much _more_ possible for two people you know to both have been compromised (or just to collude, but presumably they'd have a good reason for doing so).
+
+- NickNovitski

post
diff --git a/devblog/propellor_self_bootstrap_property.mdwn b/devblog/propellor_self_bootstrap_property.mdwn
new file mode 100644
index 0000000..0830345
--- /dev/null
+++ b/devblog/propellor_self_bootstrap_property.mdwn
@@ -0,0 +1,26 @@
+Worked for a while today on
+<http://propellor.branchable.com/todo/property_to_install_propellor/>,
+with the goal of making propellor build a disk image that itself contains
+propellor.
+
+The hard part of that turned out to be that inside the chroot it's
+building, /usr/local/propellor is bind mounted to the one outside the
+chroot. But this new property needs to populate that directory in
+the chroot. Simply unmounting the bind mount would break later properties,
+so some way to temporarily expose the underlying directory was called for.
+
+At first, I thought `unshare -m` could be used to do this, but for some
+reason that does not work in a chroot. Pity. Ended up going with a
+complicated dance, where the bind mount is bind mounted to a temp dir,
+then unmounted to expose the underlying directory, and once it's set up,
+the temp dir is re-bind-mounted back over it. Ugh.
+
+I was able to reuse Propellor.Bootstrap to bootstrap propellor inside the
+chroot, which was nice. 
+
+Also nice that I'm able to work on this kind of thing at home despite it
+involving building chroots -- yay for satelite internet!
+
+----
+
+Today's work was sponsored by Riku Voipio.

cleanup
diff --git a/blog/about.mdwn b/blog/about.mdwn
index 67df9d8..a26bc15 100644
--- a/blog/about.mdwn
+++ b/blog/about.mdwn
@@ -13,6 +13,7 @@ Besides the main blog, some other feeds are available:
 
 * [[archives]]
 * [[lay]] feed, which omits the technical bits
+* My [[devblog]], a day-to-day devlopment journal.
 * Some categories I blog about from time to time, including [[music]], 
   [[unicode]], [[code]] and [[wishlist]].
 * [[howto]] feed, containing some HOWTOs.
@@ -29,10 +30,6 @@ Besides the main blog, some other feeds are available:
 Also, my blog is aggregated on sites including:
 
 * [Planet Debian](http://planet.debian.org)
-* [Planet not Linux Journal](http://zgp.org/~dmarti/planet/)
-* [Hess Family blogs](http://kitenet.net/~family/blogs.html)
-* [LiveJournal](http://syndicated.livejournal.com/kitenet_joey/)
-* [BlogLines](http://bloglines.com/preview?siteid=1873751)
-* [advogato](http://www.advogato.org/person/joey/)
+* [Hess Family blogs](http://family.kitenet.net/blogs/)
 
 If you know of others, add them to [[Discussion]].

add the rest of my propellor devblog posts to the devblog
diff --git a/blog/entry/adding_docker_support_to_propellor.mdwn b/blog/entry/adding_docker_support_to_propellor.mdwn
index 0762f2b..cee21b1 100644
--- a/blog/entry/adding_docker_support_to_propellor.mdwn
+++ b/blog/entry/adding_docker_support_to_propellor.mdwn
@@ -69,5 +69,5 @@ a large reason for that is, I think, that its configuration file is just
 not expressive enough.
 
 [[!meta title="adding docker support to propellor"]]
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/birdplanesupermonoid.mdwn b/blog/entry/birdplanesupermonoid.mdwn
index 76fe1f1..3b2d234 100644
--- a/blog/entry/birdplanesupermonoid.mdwn
+++ b/blog/entry/birdplanesupermonoid.mdwn
@@ -1,5 +1,5 @@
 [[!meta title="it's a bird, it's a plane, it's a super monoid for propellor"]]
-[[!tag propellor haskell]]
+[[!tag propellor haskell devblog]]
 
 I've been doing a little bit of dynamically typed programming in Haskell,
 to improve [[code/Propellor]]'s `Info` type. The result is kind of
diff --git a/blog/entry/clean_OS_reinstalls_with_propellor.mdwn b/blog/entry/clean_OS_reinstalls_with_propellor.mdwn
index 0671fd2..82ba9a5 100644
--- a/blog/entry/clean_OS_reinstalls_with_propellor.mdwn
+++ b/blog/entry/clean_OS_reinstalls_with_propellor.mdwn
@@ -103,7 +103,6 @@ Oh BTW, you could parameterize a few Properties by OS, and Propellor
 could be used to install not just Debian or Ubuntu, but whatever Linux
 distribution you want. Patches welcomed...
 
-[[!tag propellor]]
-
 [[!meta title="clean OS reinstalls with propellor"]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/how_I_wrote_init_by_accident.mdwn b/blog/entry/how_I_wrote_init_by_accident.mdwn
index ba21253..5fca459 100644
--- a/blog/entry/how_I_wrote_init_by_accident.mdwn
+++ b/blog/entry/how_I_wrote_init_by_accident.mdwn
@@ -53,5 +53,5 @@ If that does happen, perhaps I'll eventually be able to remove 2 lines of code
 from propellor.
 
 [[!meta title="how I wrote init by accident"]]
-[[!tag code/propellor]]
+[[!tag code/propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/introducing_propellor.mdwn b/blog/entry/introducing_propellor.mdwn
index cb8fd46..e8d21a1 100644
--- a/blog/entry/introducing_propellor.mdwn
+++ b/blog/entry/introducing_propellor.mdwn
@@ -94,6 +94,6 @@ that is a lot of things to a lot of people --
 of the kind I see when I look at ansible -- vs the tools and experience
 to build just the thing you want without the cruft. Nice to have the latter!
 
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!meta date="Sun Mar 30 03:50:42 2014 -0400"]]
 [[!tag haskell]]
diff --git a/blog/entry/letsencrypt_support_in_propellor.mdwn b/blog/entry/letsencrypt_support_in_propellor.mdwn
index 01c52b6..a9f457c 100644
--- a/blog/entry/letsencrypt_support_in_propellor.mdwn
+++ b/blog/entry/letsencrypt_support_in_propellor.mdwn
@@ -65,4 +65,4 @@ this should result in multiple failure reports being sent (for 30 days I
 think) before a cert expires without getting renewed. But, I have not been
 able to test this.
 
-[[!tag propellor]]
+[[!tag propellor devblog]]
diff --git a/blog/entry/making_propellor_safer_with_GADTs_and_type_families.mdwn b/blog/entry/making_propellor_safer_with_GADTs_and_type_families.mdwn
index 5fedf87..bef754b 100644
--- a/blog/entry/making_propellor_safer_with_GADTs_and_type_families.mdwn
+++ b/blog/entry/making_propellor_safer_with_GADTs_and_type_families.mdwn
@@ -200,4 +200,4 @@ Anytime you can identify a class of bugs that can impact a complicated code
 base, and rework the code base to completely avoid that class of bugs, is a
 time to celebrate!
 
-[[!tag propellor haskell]]
+[[!tag propellor haskell devblog]]
diff --git a/blog/entry/propelling_containers.mdwn b/blog/entry/propelling_containers.mdwn
index c1959ac..170f568 100644
--- a/blog/entry/propelling_containers.mdwn
+++ b/blog/entry/propelling_containers.mdwn
@@ -1,4 +1,4 @@
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
 
 Propellor has supported docker containers for a "long" time, and it works
diff --git a/blog/entry/propelling_disk_images.mdwn b/blog/entry/propelling_disk_images.mdwn
index 5039f3f..4b460ca 100644
--- a/blog/entry/propelling_disk_images.mdwn
+++ b/blog/entry/propelling_disk_images.mdwn
@@ -116,4 +116,4 @@ until you think you have a full specification of it, and then
 use that to generate a new, clean disk image. Nice way to transition
 from sysadmin days of yore to a clean declaratively specified system.
 
-[[!tag propellor]]
+[[!tag propellor devblog]]
diff --git a/blog/entry/propellor-driven_DNS_and_backups.mdwn b/blog/entry/propellor-driven_DNS_and_backups.mdwn
index 2ad9610..70275cb 100644
--- a/blog/entry/propellor-driven_DNS_and_backups.mdwn
+++ b/blog/entry/propellor-driven_DNS_and_backups.mdwn
@@ -102,5 +102,5 @@ By the way, Propellor is now up to 3 thousand lines of code
 (not including Utility library). In 20 days, as a 10% time side project.
 
 [[!meta title="propellor-driven DNS and backups"]]
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/propellor_introspection_for_DNS.mdwn b/blog/entry/propellor_introspection_for_DNS.mdwn
index 432ad05..1542d50 100644
--- a/blog/entry/propellor_introspection_for_DNS.mdwn
+++ b/blog/entry/propellor_introspection_for_DNS.mdwn
@@ -93,5 +93,5 @@ main = do
 """]]
 
 [[!meta title="propellor introspection for DNS"]]
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/propellor_orchestration.mdwn b/blog/entry/propellor_orchestration.mdwn
index 594eac0..a9433f0 100644
--- a/blog/entry/propellor_orchestration.mdwn
+++ b/blog/entry/propellor_orchestration.mdwn
@@ -1,4 +1,4 @@
-[[!tag propellor]]
+[[!tag propellor devblog]]
 
 With the disclamer that I don't really know much about
 <a href="https://en.wikipedia.org/wiki/Orchestration_(computing)">orchestration</a>,
diff --git a/blog/entry/propellor_type-safe_reversions.mdwn b/blog/entry/propellor_type-safe_reversions.mdwn
index 9545318..e001cb9 100644
--- a/blog/entry/propellor_type-safe_reversions.mdwn
+++ b/blog/entry/propellor_type-safe_reversions.mdwn
@@ -43,5 +43,5 @@ revertable, and others not:
 """]]
 
 [[!meta title="propellor type-safe reversions"]]
-[[!tag propellor]]
+[[!tag propellor devblog]]
 [[!tag haskell]]
diff --git a/blog/entry/then_and_now.mdwn b/blog/entry/then_and_now.mdwn
index 1754554..3db58fb 100644
--- a/blog/entry/then_and_now.mdwn
+++ b/blog/entry/then_and_now.mdwn
@@ -62,5 +62,4 @@ of code, [[propellor_is_d-i_2.0]]); indeed I'm just adding generic useful stuff
 and building further stuff out of it without any particular end goal. Perhaps
 that's the real difference.
 
-[[!tag code/propellor]]
-[[!tag devblog]]
+[[!tag code/propellor devblog]]
diff --git a/blog/entry/type_safe_multi-OS_Propellor.mdwn b/blog/entry/type_safe_multi-OS_Propellor.mdwn
index fce26bb..d58f5ec 100644
--- a/blog/entry/type_safe_multi-OS_Propellor.mdwn
+++ b/blog/entry/type_safe_multi-OS_Propellor.mdwn
@@ -190,4 +190,4 @@ system questions.
 Also thanks to the Shuttleworth foundation, which funded this work
 by way of a Flash Grant.
 
-[[!tag propellor haskell]]
+[[!tag propellor haskell devblog]]
diff --git a/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn b/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
index 4c02901..e092b98 100644
--- a/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
+++ b/blog/entry/using_a_debian_package_as_the_remote_for_a_local_config_repo.mdwn
@@ -76,4 +76,4 @@ somewhere in /usr, and check them into a new empty repository as part of the
 generation of the upstream/master branch.
 
 [[!meta title="using a debian package as the remote for a local config repo"]]
-[[!tag code/propellor]]
+[[!tag code/propellor devblog]]

maybe add devbloggish blog posts to the devblog
diff --git a/blog/entry/then_and_now.mdwn b/blog/entry/then_and_now.mdwn
index 242d684..1754554 100644
--- a/blog/entry/then_and_now.mdwn
+++ b/blog/entry/then_and_now.mdwn
@@ -63,3 +63,4 @@ and building further stuff out of it without any particular end goal. Perhaps
 that's the real difference.
 
 [[!tag code/propellor]]
+[[!tag devblog]]
diff --git a/devblog.mdwn b/devblog.mdwn
index 5260c20..8b84e79 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -1,7 +1,7 @@
 Joey blogs about his work here on a semi-daily basis. For lower post
 frequency and wider-interest topics, see the main [[blog]].
 
-[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*)" show=365]]
+[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*) or tagged(devblog)" show=365]]
 
 ----
 

link to devblog
diff --git a/blog.mdwn b/blog.mdwn
index afef011..41ef4d0 100644
--- a/blog.mdwn
+++ b/blog.mdwn
@@ -24,7 +24,7 @@ Posts per month:
 
 My other blogs:
 
-* [git-annex dev blog](https://git-annex.branchable.com/devblog/)
+* [[devblog]]
 * [olduse.net blog](http://olduse.net/blog/)
 * [after 1 minute on my modem](https://1-minute-modem.branchable.com)
 

calendar does not work for aggregated pages, disable for now
diff --git a/devblog.mdwn b/devblog.mdwn
index 83a4adf..5260c20 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -1,12 +1,9 @@
 Joey blogs about his work here on a semi-daily basis. For lower post
 frequency and wider-interest topics, see the main [[blog]].
 
-[[!sidebar content="""
-[[!calendar type="month" pages="internal(devblog/*)"]]
-[[!calendar type="month" month="-1" pages="internal(devblog/*)"]]
-[[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
+[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*)" show=365]]
+
+----
 
 [[!aggregate expireage=365 name="git-annex devblog" feedurl="http://git-annex.branchable.com/devblog/index.rss" url="http://git-annex.branchable.com/devblog/"]]
-"""]]
 
-[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*)" show=365]]

syntax
diff --git a/devblog.mdwn b/devblog.mdwn
index 5a5d4c2..83a4adf 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -5,10 +5,8 @@ frequency and wider-interest topics, see the main [[blog]].
 [[!calendar type="month" pages="internal(devblog/*)"]]
 [[!calendar type="month" month="-1" pages="internal(devblog/*)"]]
 [[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
-"""]]
-
-[[!inline pages="page(devblog/*) and internal(devblog/git-annex_devblog/*)" show=365]]
-
-----
 
 [[!aggregate expireage=365 name="git-annex devblog" feedurl="http://git-annex.branchable.com/devblog/index.rss" url="http://git-annex.branchable.com/devblog/"]]
+"""]]
+
+[[!inline pages="page(devblog/*) or internal(devblog/git-annex_devblog/*)" show=365]]

syntax
diff --git a/devblog.mdwn b/devblog.mdwn
index 3c4e823..5a5d4c2 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -7,7 +7,7 @@ frequency and wider-interest topics, see the main [[blog]].
 [[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
 """]]
 
-[[!inline pages="internal(devblog/*) and !internal(devblog/*/*)" show=365]]
+[[!inline pages="page(devblog/*) and internal(devblog/git-annex_devblog/*)" show=365]]
 
 ----
 

syntax
diff --git a/devblog.mdwn b/devblog.mdwn
index b7acd13..3c4e823 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -7,7 +7,7 @@ frequency and wider-interest topics, see the main [[blog]].
 [[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
 """]]
 
-[[!inline pages="internal(devblog/*) and (not(internal(devblog/*/*)))" show=365]]
+[[!inline pages="internal(devblog/*) and !internal(devblog/*/*)" show=365]]
 
 ----
 

syntax
diff --git a/devblog.mdwn b/devblog.mdwn
index e4dd588..b7acd13 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -7,7 +7,7 @@ frequency and wider-interest topics, see the main [[blog]].
 [[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
 """]]
 
-[[!inline pages="internal(devblog/*) and not internal(devblog/*/*)" show=365]]
+[[!inline pages="internal(devblog/*) and (not(internal(devblog/*/*)))" show=365]]
 
 ----
 

avoid comments on non-aggregated posts
diff --git a/devblog.mdwn b/devblog.mdwn
index 7d6f648..e4dd588 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -7,7 +7,7 @@ frequency and wider-interest topics, see the main [[blog]].
 [[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
 """]]
 
-[[!inline pages="internal(devblog/*)" show=365]]
+[[!inline pages="internal(devblog/*) and not internal(devblog/*/*)" show=365]]
 
 ----
 

include aggregates
diff --git a/devblog.mdwn b/devblog.mdwn
index b4579db..7d6f648 100644
--- a/devblog.mdwn
+++ b/devblog.mdwn
@@ -2,12 +2,12 @@ Joey blogs about his work here on a semi-daily basis. For lower post
 frequency and wider-interest topics, see the main [[blog]].
 
 [[!sidebar content="""
-[[!calendar type="month" pages="page(devblog/*)"]]
-[[!calendar type="month" month="-1" pages="page(devblog/*)"]]
-[[!calendar type="month" month="-2" pages="page(devblog/*)"]]
+[[!calendar type="month" pages="internal(devblog/*)"]]
+[[!calendar type="month" month="-1" pages="internal(devblog/*)"]]
+[[!calendar type="month" month="-2" pages="internal(devblog/*)"]]
 """]]
 
-[[!inline pages="page(devblog/*)" show=365]]
+[[!inline pages="internal(devblog/*)" show=365]]
 
 ----
 

add
diff --git a/devblog.mdwn b/devblog.mdwn
new file mode 100644
index 0000000..b4579db
--- /dev/null
+++ b/devblog.mdwn
@@ -0,0 +1,14 @@
+Joey blogs about his work here on a semi-daily basis. For lower post
+frequency and wider-interest topics, see the main [[blog]].
+
+[[!sidebar content="""
+[[!calendar type="month" pages="page(devblog/*)"]]
+[[!calendar type="month" month="-1" pages="page(devblog/*)"]]
+[[!calendar type="month" month="-2" pages="page(devblog/*)"]]
+"""]]
+
+[[!inline pages="page(devblog/*)" show=365]]
+
+----
+
+[[!aggregate expireage=365 name="git-annex devblog" feedurl="http://git-annex.branchable.com/devblog/index.rss" url="http://git-annex.branchable.com/devblog/"]]

Added a comment: Why don't migrate to Gitlab ?
diff --git a/blog/entry/removing_everything_from_github/comment_3_6420818c60985d8505b39fbcb9dedafe._comment b/blog/entry/removing_everything_from_github/comment_3_6420818c60985d8505b39fbcb9dedafe._comment
new file mode 100644
index 0000000..633df04
--- /dev/null
+++ b/blog/entry/removing_everything_from_github/comment_3_6420818c60985d8505b39fbcb9dedafe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="contact@ea9ae169a77c027ab55860902818aa961a1bbd7c"
+ nickname="contact"
+ avatar="http://cdn.libravatar.org/avatar/1fb3da467b9d2c0a6fc65a5fefe4ab51"
+ subject="Why don't migrate to Gitlab ?"
+ date="2017-04-02T14:28:16Z"
+ content="""
+Why don't migrate to Gitlab ?
+"""]]

add slides
diff --git a/talks.mdwn b/talks.mdwn
index 8bc42d5..47c5414 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -106,3 +106,4 @@ by others.
 
 * "securely backing up gpg private keys.. to the cloud‽"
   - [video](https://media.libreplanet.org/u/libreplanet/m/securely-backing-up-gpg-private-keys-to-the-cloud/)
+  - [[slides|keysafe-libreplanet.pdf]]
diff --git a/talks/keysafe-libreplanet.pdf b/talks/keysafe-libreplanet.pdf
new file mode 100644
index 0000000..34477ac
Binary files /dev/null and b/talks/keysafe-libreplanet.pdf differ

add talk
diff --git a/talks.mdwn b/talks.mdwn
index a19524f..8bc42d5 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -105,4 +105,4 @@ by others.
 ## Libreplanet 2017, MIT
 
 * "securely backing up gpg private keys.. to the cloud‽"
-  March 26th 16:35
+  - [video](https://media.libreplanet.org/u/libreplanet/m/securely-backing-up-gpg-private-keys-to-the-cloud/)

Added a comment: wifi !
diff --git a/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment b/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment
new file mode 100644
index 0000000..035f9ac
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_3_2224279f5914e56f9c66c67645e74004._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="i@39b592a99fca04bf1d9fe736fdeb750089c19f24"
+ nickname="i"
+ avatar="http://cdn.libravatar.org/avatar/01aca4d340834af92eebe27a4c734de3"
+ subject="wifi !"
+ date="2017-03-23T17:02:02Z"
+ content="""
+As anarcat points out you can probably cover that distance with wifi. In Catalonia we have a huge commons network ([guifi.net][]) of more than 32.000 nodes with 16+ mile links and several optical fiber towns as well.
+
+[guifi.net]: https://guifi.net/
+
+Don't you have any wifi/wimax (LMDS) provider on your zone? The price and power consumption will be lower and the bandwidth and latency much better.
+"""]]

update
diff --git a/boxen.mdwn b/boxen.mdwn
index e904a9e..115afbf 100644
--- a/boxen.mdwn
+++ b/boxen.mdwn
@@ -12,15 +12,15 @@ Mostly mythical creatures.
 
 * [[darkstar]] {*}
 * [[gnu]] {*}
-* wildebeest (spare for gnu)
 * kiwi {*} (Anna's)
 * aquamiser2 {*} (Mark's)
-* garlic {*} (Maggie's)
 * [[kodama]]
 * [[phoenix]]
 * [[dragon]]
 * corvid
 * kraken
+* wildebeest
+* garlic (Maggie's)
 
 ## servers
 
@@ -39,9 +39,11 @@ Mostly birds.
 * [[finch]]
 * [[pell]] {*}
 * orca
-* [[clam]] {*}
 * [[diatom]]
 * [[elephant]] {*}
+* [[clam]] {*}
+* [[mayfly]] {*}
+* [[oyster]] {*}
 
 ## small machines
 
@@ -51,6 +53,7 @@ Mostly birds.
 * snail
 * [[stick]]
 * [[honeybee]] {*}
+* [[chip] {*}
 
 ## phones
 
diff --git a/boxen/chip.mdwn b/boxen/chip.mdwn
new file mode 100644
index 0000000..ca80868
--- /dev/null
+++ b/boxen/chip.mdwn
@@ -0,0 +1,4 @@
+PocketCHIP
+
+Runs Debian but I have not tried to install it from scratch yet, so it's
+not a clean install.
diff --git a/boxen/dragon.mdwn b/boxen/dragon.mdwn
index ab56b7c..6dbba30 100644
--- a/boxen/dragon.mdwn
+++ b/boxen/dragon.mdwn
@@ -1,7 +1,12 @@
+Librem 13 laptop, used as an alternate for my main laptop when traveling,
+or doing heavy CPU tasks (since it has a working fan).
+
+----
+
+### Previously
+
 Dragon is my old laptop, with a failing keyboard. Currently I use it as a
 print and ups server. It's also a tftp server (for machines that can't use
 tftp-hpa).
 
 It runs from a 1 gb flash disk, connected via a CF to IDE adapter.
-
-Dragon is currently down.
diff --git a/boxen/dragonfly.mdwn b/boxen/dragonfly.mdwn
index 0fd10b5..7e94a73 100644
--- a/boxen/dragonfly.mdwn
+++ b/boxen/dragonfly.mdwn
@@ -1,4 +1,4 @@
-Dragonfly is a WRT54GL that is the main access point for my house.
+Dragonfly is a WRT54GL that was the main access point for my house.
 
 Its access point is `00:1A:70:D6:D7:6C`, and its ESSID is
 'kitenet.net/wifi' on channel 1.
diff --git a/boxen/gnu.mdwn b/boxen/gnu.mdwn
index d7b2491..23c0417 100644
--- a/boxen/gnu.mdwn
+++ b/boxen/gnu.mdwn
@@ -1,8 +1,11 @@
 [[!meta title="Debian Linux on the Dell Mini 9"]]
 
-Gnu is my Dell Inspiron Mini 9. This page details getting Debian working on
+Gnu was my Dell Inspiron Mini 9. This page details getting Debian working on
 this machine, which comes pre-loaded with Ubuntu.
 
+(These days, I have a different box named GNU that is a Lenovo laptop.
+Used as the house's MPD server.)
+
 [[!toc ]]
 
 ## Installation
diff --git a/boxen/leech.mdwn b/boxen/leech.mdwn
index 7bfc040..85b7d1c 100644
--- a/boxen/leech.mdwn
+++ b/boxen/leech.mdwn
@@ -1 +1 @@
-Sheevaplug
+Sheevaplug. My dialup gateway.
diff --git a/boxen/mayfly.mdwn b/boxen/mayfly.mdwn
new file mode 100644
index 0000000..c2b75f4
--- /dev/null
+++ b/boxen/mayfly.mdwn
@@ -0,0 +1,5 @@
+Spare VM at cloudatcost. Tor bridge.
+
+This system is untrusted; it is used only for experimentation and services
+using untrusted data that I don't mind losing. The provider has been known
+to lose data in the past.
diff --git a/boxen/oyster.mdwn b/boxen/oyster.mdwn
new file mode 100644
index 0000000..c2b75f4
--- /dev/null
+++ b/boxen/oyster.mdwn
@@ -0,0 +1,5 @@
+Spare VM at cloudatcost. Tor bridge.
+
+This system is untrusted; it is used only for experimentation and services
+using untrusted data that I don't mind losing. The provider has been known
+to lose data in the past.

other users
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index c336753..882aec0 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -165,3 +165,13 @@ distributions. It should also be as easy as possible to install manually.
 It may be helpful for programs to bundle `debug-me`, at least
 until the standalone `debug-me` is widely available. For example, I can
 imagine including it in the standalone git-annex bundles.
+
+#### other uses
+
+Something like this could be used in a few other ways than debugging:
+
+* Let anyone connect in watch-only mode. Could be used for
+  broadcasting both debugging sessions and other activity.
+* Moderated mode where N people connect and M of them need to approve
+  an action before it's accepted. Could be used to add security, or for
+  pair programming where both in the pair need to agree what to do.

Added a comment: wifi?
diff --git a/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment b/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment
new file mode 100644
index 0000000..ec6f209
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_2_eca2f57b0afee52773a49d0afae33be5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat@2247195311694be5ed7cb48c341c2c9883b26686"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="wifi?"
+ date="2017-03-17T00:16:58Z"
+ content="""
+\"a few miles\" away seems like something that could be bridged with a high speed WiFi link. at the montreal mesh, we have successfully built a 3km link using 5GHz frequencies. this was done with two Ubiquity Powerbeam M5-400-ISO devices. it's obviously line of sight and unidirectional links, but it works well, from what i've heard.
+
+some basic docs are [here](https://wiki.reseaulibre.ca/nodes/nadjaf/) and [here](https://wiki.reseaulibre.ca/nodes/amman/), i can dig out more if you're interested... 
+"""]]

Added a comment
diff --git a/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment b/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment
new file mode 100644
index 0000000..a17f516
--- /dev/null
+++ b/blog/entry/end_of_an_era/comment_1_b35fcdc43d44d831b20d748c1ec29cb3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="kzwork@fc9840c54b25a443d3c2865ce991231b33b8196b"
+ nickname="kzwork"
+ avatar="http://cdn.libravatar.org/avatar/2f26e4f64eb5657f7d260bda02c7ba45"
+ subject="comment 1"
+ date="2017-03-16T23:12:17Z"
+ content="""
+If you have some wind around, you can have additional power source with wind generator.
+
+See this guy- did an amazing job for couple of bucks
+<http://www.mdpub.com/Wind_Turbine/>
+
+as a suplementary to your solar panels
+"""]]

fix feed url
diff --git a/grep.mdwn b/grep.mdwn
index 00fe74b..07b72b4 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="https://pump2rss.com/feed/joeyh@identi.ca.atom" url="http://identi.ca/joeyh"]]
+* [[!aggregate expirecount=25 name="identi.ca posts" feedurl="https://tmp.joeyh.name/pump.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/end_of_an_era.mdwn b/blog/entry/end_of_an_era.mdwn
new file mode 100644
index 0000000..6876f1c
--- /dev/null
+++ b/blog/entry/end_of_an_era.mdwn
@@ -0,0 +1,31 @@
+I'm at home downloading hundreds of megabytes of stuff.
+This is the first time I've been in position of "at home" + "reasonably fast
+internet" since I moved here in 2012. It's weird!
+
+[[!img pics/satdish1.jpg alt="Satellite internet dish with solar panels in foreground"]]
+
+While I was renting here, I didn't mind dialup much. In a way it helps
+to focus the mind and build interesting stuff. But since I bought the
+house, the prospect of only dialup at home ongoing became more painful.
+
+While I hope to get on the fiber line that's only a few miles away
+eventually, I have not convinced that ISP to build out to me yet. Not
+enough neighbors. So, satellite internet for now.
+
+[[!img pics/satsignal.png alt="9.1 dB SNR"]]
+
+[[!img pics/satspeed.png alt="speedtest results: 15 megabit down / 4.5 up with significant variation"]]
+
+Dish seems well aligned, speed varies a lot, but is easily
+hundreds of times faster than dialup. Latency is 2x dialup.
+
+The equipment uses more power than my laptop, so with the current solar
+panels, I anticipate using it only 6-9 months of the year. So I may be back
+to dialup most days come winter, until I get around to adding more PV
+capacity.
+
+It seems very cool that my house can capture sunlight and use it to beam
+signals 20 thousand miles into space. Who knows, perhaps there will even be
+running water one day.
+
+[[!img pics/satdish2.jpg alt="Satellite dish"]]
diff --git a/blog/pics/satdish1.jpg b/blog/pics/satdish1.jpg
new file mode 100644
index 0000000..b2dc63e
Binary files /dev/null and b/blog/pics/satdish1.jpg differ
diff --git a/blog/pics/satdish2.jpg b/blog/pics/satdish2.jpg
new file mode 100644
index 0000000..ad0cfc9
Binary files /dev/null and b/blog/pics/satdish2.jpg differ
diff --git a/blog/pics/satsignal.png b/blog/pics/satsignal.png
new file mode 100644
index 0000000..1422d7a
Binary files /dev/null and b/blog/pics/satsignal.png differ
diff --git a/blog/pics/satspeed.png b/blog/pics/satspeed.png
new file mode 100644
index 0000000..8e7ce0f
Binary files /dev/null and b/blog/pics/satspeed.png differ

libreplanet schedule
diff --git a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
index 6cdc637..8e784bd 100644
--- a/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
+++ b/blog/entry/Presenting_at_LibrePlanet_2017.mdwn
@@ -47,3 +47,5 @@ time to perhaps speak at it.
 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.
+
+<https://libreplanet.org/2017/program/>
diff --git a/talks.mdwn b/talks.mdwn
index d8e72a6..a19524f 100644
--- a/talks.mdwn
+++ b/talks.mdwn
@@ -105,4 +105,4 @@ by others.
 ## Libreplanet 2017, MIT
 
 * "securely backing up gpg private keys.. to the cloud‽"
-  March 25th/26th
+  March 26th 16:35

proof truncation
diff --git a/code/debug-me.mdwn b/code/debug-me.mdwn
index 6edabd4..c336753 100644
--- a/code/debug-me.mdwn
+++ b/code/debug-me.mdwn
@@ -122,6 +122,18 @@ 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.
 
+##### proof truncation
+
+A proof can be truncated at any point in the chain and still be a valid
+proof of what happened in the session up to that point.
+
+One use case for this is that a developer might run a command to display
+known sensitive data (eg `.ssh/id_rsa`).
+
+An interface to truncate a proof could also upload the truncated version of
+it to a server. There would need to be a way for the user to to remove the
+full proof from the server.
+
 #### interface
 
 Interface is as close to a ssh session as possible.

comment
diff --git a/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment b/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment
new file mode 100644
index 0000000..58f04c7
--- /dev/null
+++ b/blog/entry/removing_everything_from_github/comment_2_515f3a861997867c34f7c200fe23168b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-03T17:37:06Z"
+ content="""
+I don't know of any good way to do it. Ideally, git would have a way to
+signal a redirect from one mirror of a repository to another one, and could
+learn the new url.
+
+I have created empty repos on github with the same names as the deleted
+ones, and in their README put the url to use. Not an ideal solution as it
+could confuse people and scripts.
+
+In my case, all the projects were not hosted on github, only mirrored
+there (except for github-backup). So, googling will find their websites and
+git repos still.
+"""]]

Added a comment: removing github repos
diff --git a/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment b/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment
new file mode 100644
index 0000000..e41e75d
--- /dev/null
+++ b/blog/entry/removing_everything_from_github/comment_1_42830ab6235e14998e839846d403af9c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="behemothchess@68d40d10cca36e721f782d1a8e1f012f50cb327b"
+ nickname="behemothchess"
+ avatar="http://cdn.libravatar.org/avatar/62fbef5eb5f683a2505dbb60af6a7682"
+ subject="removing github repos"
+ date="2017-03-03T07:03:36Z"
+ content="""
+Hello,
+
+do you know of any way to leave a pointer on github to the new location?  
+You are famous :-) so you can just put the links in your blog,
+but if anyone at all cares about my hacks they won't find it unless I tell them there.  
+But I couldn't find any way - the \"bio\" is only twitter-size, 
+and there's no other text field I see that's independent of the repos themselves so it would survive their removal.
+
+Thanks.
+
+
+
+"""]]

wording
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 422014d..751e49c 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -39,7 +39,7 @@ Would they still have access to it under that license when the contract
 work was over? What does "affiliates" mean? Might it include other companies?
 
 Is it even legal for a TOS to require a license grant? Don't license grants
-normally involve some action on the licensor's part, like signing a
+normally involve an intentional action on the licensor's part, like signing a
 contract or writing a license down? All I did was loaded a webpage in a
 browser and saw on the page that by loading it, they say I've accepted the
 TOS. (I then set about [[removing_everything_from_Github]].)

typo
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 06161a3..422014d 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -129,7 +129,7 @@ this license if it was being analized in a courtroom?
 > through GitHub's functionality. You may grant further rights if you adopt
 > a license.
 
-This paragraph seems entirely innocious. So, what does your keen layer mind
+This paragraph seems entirely innocious. So, what does your keen lawyer mind
 see in it that I don't?
 
 How sure are you about your answers to all this? We're fairly sure we know

typo
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index b0ceffa..06161a3 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -78,7 +78,7 @@ to run as part of the process of rendering their website?
 
 Suppose that Github modified my software, does not distribute the modified
 version, but converts it to javascipt code and distributes that to their
-users to run as part of the process of rendering their website? If my
+users to run as part of the process of rendering their website. If my
 software is AGPL licensed, they would be in violation of that license, but
 doesn't this additional license allow them to modify and distribute my
 software in such a way?

update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 298a7bc..b0ceffa 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -36,7 +36,7 @@ affiliates, directors, subsidiaries, contractors, licensors, officers, agents,
 and employees". Does this mean that if someone say, does some brief
 contracting with Github, that they get my software under this license?
 Would they still have access to it under that license when the contract
-work was over?
+work was over? What does "affiliates" mean? Might it include other companies?
 
 Is it even legal for a TOS to require a license grant? Don't license grants
 normally involve some action on the licensor's part, like signing a

markdown
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 55abaf7..298a7bc 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -15,7 +15,7 @@ If I were looking over the TOS with my lawyers, I'd ask these questions...
 
 ----
 
-> 4. License Grant to Us
+> 4  License Grant to Us
 
 This seems to be saying that I'm granting an additional license to my
 software to Github. Is that right or does "license grant" have some other
@@ -100,7 +100,7 @@ they want to my software?
 
 ----
 
-> 5. License Grant to Other Users
+> 5  License Grant to Other Users
 
 > Any Content you post publicly, including issues, comments, and
 > contributions to other Users' repositories, may be viewed by others. By

sections
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index 3e5c1f4..55abaf7 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -13,6 +13,8 @@ important indeed, and not worth taking risks with.
 
 If I were looking over the TOS with my lawyers, I'd ask these questions...
 
+----
+
 > 4. License Grant to Us
 
 This seems to be saying that I'm granting an additional license to my
@@ -96,6 +98,8 @@ If that hypothetical Github App Store doesn't sell apps, but licenses
 access to them for money, would that be allowed under this license that
 they want to my software?
 
+----
+
 > 5. License Grant to Other Users
 
 > Any Content you post publicly, including issues, comments, and

update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
index a5f8ce8..3e5c1f4 100644
--- a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -132,6 +132,8 @@ How sure are you about your answers to all this? We're fairly sure we know
 how well the GPL holds up in court; how well would your interpretation of
 all this hold up?
 
+What questions have I forgotten to ask?
+
 ----
 
 And finally, the last question I'd be asking my lawyers:

blog update
diff --git a/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
new file mode 100644
index 0000000..a5f8ce8
--- /dev/null
+++ b/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS.mdwn
@@ -0,0 +1,140 @@
+The Internet saw Github's new TOS yesterday and collectively shrugged.
+
+That's weird..
+
+I don't have any lawyers, but the way Github's new TOS is written, I feel
+I'd need to consult with lawyers to understand how it might affect the
+license of my software if I hosted it on Github.
+
+And the license of my software is important to me, because it is the legal
+framework within which my software lives or dies. If I didn't care about my
+software, I'd be able to shrug this off, but since I do it seems very
+important indeed, and not worth taking risks with.
+
+If I were looking over the TOS with my lawyers, I'd ask these questions...
+
+> 4. License Grant to Us
+
+This seems to be saying that I'm granting an additional license to my
+software to Github. Is that right or does "license grant" have some other
+legal meaning?
+
+If the Free Software license I've already licensed my software under
+allows for everything in this "License Grant to Us", 
+would that be sufficient, or would my software still be
+licenced under two different licences?
+
+There are violations of the GPL that can revoke someone's access to software
+under that license. Suppose that Github took such an action with my software,
+and their GPL license was revoked. Would they still have a license to my
+software under this "License Grant to Us" or not?
+
+"Us" is actually defined earlier as "GitHub, Inc., as well as our
+affiliates, directors, subsidiaries, contractors, licensors, officers, agents,
+and employees". Does this mean that if someone say, does some brief
+contracting with Github, that they get my software under this license?
+Would they still have access to it under that license when the contract
+work was over?
+
+Is it even legal for a TOS to require a license grant? Don't license grants
+normally involve some action on the licensor's part, like signing a
+contract or writing a license down? All I did was loaded a webpage in a
+browser and saw on the page that by loading it, they say I've accepted the
+TOS. (I then set about [[removing_everything_from_Github]].)
+
+Github's old TOS was not structured as a license grant. What reasons might
+they have for structuring this TOS in such a way?
+
+Am I asking too many questions only 4 words into this thing? Or not enough?
+
+> Your Content belongs to you, and you are responsible for Content you post
+> even if it does not belong to you. However, we need the legal right to do
+> things like host it, publish it, and share it. You grant us and our legal
+> successors the right to store and display your Content and make
+> incidental copies as necessary to render the Website and provide the
+> Service.
+
+If this is a software license, the wording seems rather vague compared
+with other software licenses I've read. How much wiggle room is built
+into that wording? 
+
+What are the chances that, if we had a dispute and this came before a
+judge, that Github's laywers would be able to find a creative reading
+of this that makes "do things like" include whatever they want?
+
+Suppose that my software is javascript code or gets compiled to javascript
+code. Would this let Github serve up the javascript code for their users
+to run as part of the process of rendering their website?
+
+> That means you're giving us the right to do things like reproduce your
+> content (so we can do things like copy it to our database and make
+> backups); display it (so we can do things like show it to you and other
+> users); modify it (so our server can do things like parse it into a
+> search index); distribute it (so we can do things like share it with
+> other users); and perform it (in case your content is something like
+> music or video).
+
+Suppose that Github modified my software, does not distribute the modified
+version, but converts it to javascipt code and distributes that to their
+users to run as part of the process of rendering their website? If my
+software is AGPL licensed, they would be in violation of that license, but
+doesn't this additional license allow them to modify and distribute my
+software in such a way?
+
+> This license does not grant GitHub the right to sell your Content or
+> otherwise distribute it outside of our Service.
+
+I see that "Service" is defined as "the applications, software, products, and
+services provided by GitHub". Does that mean at the time I accept the TOS,
+or at any point in the future?
+
+If Github tomorrow starts providing say, an App Store service, that
+necessarily involves distribution of software to others, and they put my
+software in it, would that be allowed by this or not?
+
+If that hypothetical Github App Store doesn't sell apps, but licenses
+access to them for money, would that be allowed under this license that
+they want to my software?
+
+> 5. License Grant to Other Users
+
+> Any Content you post publicly, including issues, comments, and
+> contributions to other Users' repositories, may be viewed by others. By
+> setting your repositories to be viewed publicly, you agree to allow
+> others to view and "fork" your repositories (this means that others may
+> make their own copies of your Content in repositories they control).
+
+Let's say that company Foo does something with my software that
+violates its GPL license and the license is revoked. So they no longer are
+allowed to copy my software under the GPL, but it's there on Github. 
+Does this "License Grant to Other Users" give them a different license
+under which they can still copy my software?
+
+The word "fork" has a particular meaning on Github, which often includes
+modification of the software in a repository. Does this mean that other
+users could modify my software, even if its regular license didn't
+allow them to modify it or had been revoked?
+
+How would this use of a platform-specific term "fork" be interpreted in
+this license if it was being analized in a courtroom?
+
+> If you set your pages and repositories to be viewed publicly, you grant
+> each User of GitHub a nonexclusive, worldwide license to access your
+> Content through the GitHub Service, and to use, display and perform your
+> Content, and to reproduce your Content solely on GitHub as permitted
+> through GitHub's functionality. You may grant further rights if you adopt
+> a license.
+
+This paragraph seems entirely innocious. So, what does your keen layer mind
+see in it that I don't?
+
+How sure are you about your answers to all this? We're fairly sure we know
+how well the GPL holds up in court; how well would your interpretation of
+all this hold up?
+
+----
+
+And finally, the last question I'd be asking my lawyers:
+
+**What's your bill come to? That much? Is using Github worth that much to
+me?**

update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 6b583f8..086bdb0 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -9,6 +9,12 @@ response. The Free Software Foundation was also talking with them about it.
 It seems that Github doesn't care or has some reason to want to effectively
 neuter copyleft software licenses.
 
+The possibility that a Github TOS change could force a change to the license of
+your software hosted there, and that it's complicated enough that I'd have to
+hire a lawyer to know for sure, makes Github not worth bothering to use. 
+
+Github's value proposition was never very high for me, and went negative now.
+
 I am deleting my repositories from Github at this time.
 If you used the Github mirrors for
 [git-annex](http://source.git-annex.branchable.com/), 

update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 96155d9..6b583f8 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -17,6 +17,9 @@ If you used the Github mirrors for
 [etckeeper](http://source.etckeeper.branchable.com/),
 [myrepos](http://source.myrepos.branchable.com/),
 click on the links for the non-Github repos ([git.joeyh.name](https://git.joeyh.name/) also has mirrors).
+Also, github-backup has a 
+[new website and repository](https://github-backup.branchable.com/) 
+off of github.
 (There's an oncoming severe weather event here, so it
 may take some time before I get everything deleted and cleaned up.)
 

new website for github-backup
diff --git a/blog/entry/announcing_github-backup.mdwn b/blog/entry/announcing_github-backup.mdwn
index a7e96c2..89ac80a 100644
--- a/blog/entry/announcing_github-backup.mdwn
+++ b/blog/entry/announcing_github-backup.mdwn
@@ -1,7 +1,7 @@
 Partly as a followup to [[a Github survey]], and partly because
 I had a free evening and the need to write more haskell code, any haskell
 code, I present to you,
-**[github-backup](https://github.com/joeyh/github-backup)**.
+**[[code/github-backup]]**.
 
 github-backup is a simple tool you run in a git repository you cloned from
 Github. It backs up everything Github knows about the repository, including
diff --git a/code/github-backup.mdwn b/code/github-backup.mdwn
index 19531f8..7345210 100644
--- a/code/github-backup.mdwn
+++ b/code/github-backup.mdwn
@@ -1,7 +1,5 @@
 Backs up everything github knows about a repository, to the repository.
 
-Available in Debian, or <https://github.com/joeyh/github-backup>
-
-## News
+<https://github-backup.branchable.com>
 
 [[!inline pages="code/github-backup/news/* and !*/Discussion" show="3"]]
diff --git a/code/github-backup/news/new_website.mdwn b/code/github-backup/news/new_website.mdwn
new file mode 100644
index 0000000..a546c8b
--- /dev/null
+++ b/code/github-backup/news/new_website.mdwn
@@ -0,0 +1,6 @@
+github has moved away from github, to a new website:
+<https://github-backup.branchable.com/>
+
+This will be the last post to this RSS feed, so if you are subscribed to
+it, please update your subscription to use the new feed:
+<https://github-backup.branchable.com/news/index.rss>
diff --git a/code/github-backup/news/version_1.20160522.mdwn b/code/github-backup/news/version_1.20160522.mdwn
deleted file mode 100644
index fb4a64b..0000000
--- a/code/github-backup/news/version_1.20160522.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-github-backup 1.20160522 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Work around git weirdness in handling of relative path to GIT\_INDEX\_FILE
-     when in a subdirectory of the repository.
-   * Various updates to internal git and utility libraries shared
-     with git-annex.
-   * debian: Add lintian overrides for rpath.
-   * debian: Bump standards-version.
-   * Makefile: Pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc and on to
-     ld, cc, and cpp. This lets the Debian package build with various
-     hardening options. Although their benefit to a largely haskell program
-     is unknown."""]]
\ No newline at end of file
diff --git a/code/github-backup/news/version_1.20160922.mdwn b/code/github-backup/news/version_1.20160922.mdwn
deleted file mode 100644
index b9e1464..0000000
--- a/code/github-backup/news/version_1.20160922.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-github-backup 1.20160922 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Increase base bounds to 4.8 to get mapM\_ etc that works on Vector.
-   * Recommended build method is now to use stack, for more reliable builds.
-   * Explicitly list modules and other files in github-backup.cabal.
-   * The hackage .tar.gz now omits the debian directory and may omit other
-     source files in the future; the purpose of that tarball is to make
-     stack/cabal install work, not to be a complete source distribution.
-     Use git repository to get complete source.
-   * Various updates to internal git and utility libraries shared
-     with git-annex."""]]
\ 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
deleted file mode 100644
index e736fdd..0000000
--- a/code/github-backup/news/version_1.20161110.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-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
diff --git a/code/github-backup/news/version_1.20161118.mdwn b/code/github-backup/news/version_1.20161118.mdwn
deleted file mode 100644
index 81a7226..0000000
--- a/code/github-backup/news/version_1.20161118.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-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
diff --git a/code/github-backup/news/version_1.20170221.mdwn b/code/github-backup/news/version_1.20170221.mdwn
deleted file mode 100644
index 9ff447e..0000000
--- a/code/github-backup/news/version_1.20170221.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-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

link git.joeyh.name
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 61e82bf..96155d9 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -16,9 +16,9 @@ If you used the Github mirrors for
 [ikiwiki](http://source.ikiwiki.branchable.com/),
 [etckeeper](http://source.etckeeper.branchable.com/),
 [myrepos](http://source.myrepos.branchable.com/),
-click on the links for the non-Github repos. (There's an
-oncoming severe weather event here, so it may take some time before I get
-everything deleted and cleaned up.)
+click on the links for the non-Github repos ([git.joeyh.name](https://git.joeyh.name/) also has mirrors).
+(There's an oncoming severe weather event here, so it
+may take some time before I get everything deleted and cleaned up.)
 
 [Some commits to git-annex were pushed to Github this morning by
 an automated system, but I had *NOT* accepted their new TOS at that

typo
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
index 609f26b..61e82bf 100644
--- a/blog/entry/removing_everything_from_github.mdwn
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -4,7 +4,7 @@ neuters it entirely, so GPL licensed software hosted on Github has an
 implicit BSD-like license. I'll leave the full analysis to the lawyers,
 but see [Thorsten's analysis](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10).
 
-I contacted Github about this weeks ago, and received only an adonyne
+I contacted Github about this weeks ago, and received only an anodyne
 response. The Free Software Foundation was also talking with them about it.
 It seems that Github doesn't care or has some reason to want to effectively
 neuter copyleft software licenses.

blog update
diff --git a/blog/entry/removing_everything_from_github.mdwn b/blog/entry/removing_everything_from_github.mdwn
new file mode 100644
index 0000000..609f26b
--- /dev/null
+++ b/blog/entry/removing_everything_from_github.mdwn
@@ -0,0 +1,28 @@
+Github recently drafted an update to their Terms Of Service. The new TOS
+is potentially very bad for copylefted Free Software. It potentially
+neuters it entirely, so GPL licensed software hosted on Github has an
+implicit BSD-like license. I'll leave the full analysis to the lawyers,
+but see [Thorsten's analysis](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10).
+
+I contacted Github about this weeks ago, and received only an adonyne
+response. The Free Software Foundation was also talking with them about it.
+It seems that Github doesn't care or has some reason to want to effectively
+neuter copyleft software licenses.
+
+I am deleting my repositories from Github at this time.
+If you used the Github mirrors for
+[git-annex](http://source.git-annex.branchable.com/), 
+[propellor](http://source.propellor.branchable.com/), 
+[ikiwiki](http://source.ikiwiki.branchable.com/),
+[etckeeper](http://source.etckeeper.branchable.com/),
+[myrepos](http://source.myrepos.branchable.com/),
+click on the links for the non-Github repos. (There's an
+oncoming severe weather event here, so it may take some time before I get
+everything deleted and cleaned up.)
+
+[Some commits to git-annex were pushed to Github this morning by
+an automated system, but I had *NOT* accepted their new TOS at that
+point, and explicitly do **NOT** give Github or anyone any rights
+to git-annex not granted by its GPL and AGPL licenses.]
+
+See also: [PDF of Github TOS that can be read without being forced to first accept Github's TOS](https://tmp.joeyh.name/github-tos.pdf)

ps
diff --git a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
index 9e10cd7..ee291a5 100644
--- a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
+++ b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
@@ -23,3 +23,12 @@ and more about why it avoids git's SHA1 weaknesses, see
 My advice is, if you are using a git repository to publish or collaborate
 on binary files, in which it's easy to hide SHA1 collisions,
 you should switch to using git-annex and signed commits.
+
+PS: Of course, verifying gpg signatures on signed commits adds some
+complexity and won't always be done. It turns out that the current
+SHA1 known-prefix collision attack cannot be usefully used to generate
+colliding commit objects, although a future common-prefix collision
+attack might. So, even if users don't verify signed commits, I believe
+that repositories using git-annex for binary files will be as secure as
+git repositories containing binary files used to be.
+How-ever secure that might be..

blog update
diff --git a/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
new file mode 100644
index 0000000..9e10cd7
--- /dev/null
+++ b/blog/entry/making_git-annex_secure_in_the_face_of_SHA1_collisions.mdwn
@@ -0,0 +1,25 @@
+[git-annex](https://git-annex.branchabe.com/) has never used SHA1 by
+default. But, there are concerns about SHA1 collisions being used to
+exploit git repositories in various ways. Since git-annex builds on top of
+git, it inherits its foundational SHA1 weaknesses. Or does it?
+
+Interestingly, when I dug into the details, I found a way to make git-annex
+repositories secure from SHA1 collision attacks, as long as signed commits
+are used (and verified). 
+
+When git commits are signed (and verified), SHA1 collisions in
+commits are not a problem. And there seems to be no way to generate
+usefully colliding git tree objects (unless they contain really ugly binary
+filenames). That leaves blob objects, and when using git-annex, those are
+git-annex key names, which can be secured from being a vector for SHA1
+collision attacks.
+
+This needed some work on git-annex, which is now done, so look
+for a release in the next day or two that hardens it against
+SHA1 collision attacks. For details about how to use it, 
+and more about why it avoids git's SHA1 weaknesses, see
+<https://git-annex.branchable.com/tips/using_signed_git_commits/>.
+
+My advice is, if you are using a git repository to publish or collaborate
+on binary files, in which it's easy to hide SHA1 collisions,
+you should switch to using git-annex and signed commits.

reflow
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
index 5a58cdb..261c90b 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -18,7 +18,8 @@ a jump to 129 bytes after the current end of the firmware.
 resulting file as the input the the collision generation attack. (If you
 wan to target this being stored in a git repository, include a git blob
 header in the data used to generate the collision.)
-Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+Now you have two 128 byte chunks which when appended to the file in #1,
+result in two different, SHA1-colliding files.
 
 3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
 

reflow
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
index 613e804..5a58cdb 100644
--- a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -12,12 +12,13 @@ the other which does not. The good version can be distributed, and
 then replaced by the bad version without the replacement being noticed.
 
 1. Identify the first instruction run by the firmware at boot. Replace with
-a jump to 129 bytes after the current end of the firmware. Use the
+a jump to 129 bytes after the current end of the firmware. 
+
+2. Use the
 resulting file as the input the the collision generation attack. (If you
 wan to target this being stored in a git repository, include a git blob
 header in the data used to generate the collision.)
-
-2. Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
 
 3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
 

comment
diff --git a/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
new file mode 100644
index 0000000..613e804
--- /dev/null
+++ b/blog/entry/SHA1_collision_via_ASCII_art/comment_8_00b41dec622f07c94d57ec1e3a5966ec._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""HOWTO firmware collision"""
+ date="2017-02-27T15:31:55Z"
+ content="""
+Of course, what we really need to worry about is not ASCII art, but
+binary firmware published by git repository. The linux firmware repository, for example.
+
+Here's how to use the SHA1 collision generation attack to modify a firmware
+file so there are two versions, one of which runs a malicious exploit and
+the other which does not. The good version can be distributed, and
+then replaced by the bad version without the replacement being noticed.
+
+1. Identify the first instruction run by the firmware at boot. Replace with
+a jump to 129 bytes after the current end of the firmware. Use the
+resulting file as the input the the collision generation attack. (If you
+wan to target this being stored in a git repository, include a git blob
+header in the data used to generate the collision.)
+
+2. Now you have two 128 byte chunks which when appended to the file in #1, result in two colliding, but different files.
+
+3. At the end of each of the two different files, append the same payload. Since the SHA1 hash function is in the same state at the end of each file in #2, appending identical data to each file yields new files that also collide.
+
+The payload examines the memory in the 128 byte colliding area. If it sees the "good" version, it runs the instruction that was originally replaced with the jump, and jumps back to the second original instruction. If it sees the "bad" version, it runs the remainder of the payload, the exploit.
+
+Obviously there is some trickiness to do with relative addresses and returning registers to the original state when jumping back in the "good" version etc. But this should be very doable for any assembly programmer; it should even be possible to completely automate it.
+"""]]

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) {