Recent changes to this wiki. Not to be confused with my history.

Complete source to the wiki is available on gitweb or by cloning this site.

fix link again again
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d6ae982..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,2 +0,0 @@
-[[!meta redir="2017-02-22-password-managers/"]]
-[[!tag redirection]]
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
new file mode 100644
index 0000000..d6ae982
--- /dev/null
+++ b/blog/password-managers.mdwn
@@ -0,0 +1,2 @@
+[[!meta redir="2017-02-22-password-managers/"]]
+[[!tag redirection]]

fix broken link - the url was published on twitter already
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
new file mode 100644
index 0000000..d6ae982
--- /dev/null
+++ b/blog/password-hashers.mdwn
@@ -0,0 +1,2 @@
+[[!meta redir="2017-02-22-password-managers/"]]
+[[!tag redirection]]

remove cruft
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
index a96922d..878819c 100644
--- a/blog/2017-02-22-password-managers.mdwn
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -162,7 +162,7 @@ likely involve setting up a private Git repository for your team,
 something which may not be accessible to the average Linux
 user. Nothing keeps you, however, from sharing the `~/.password-store`
 directory through another file sharing mechanism like (say)
-[Syncthing][] or [Dropbox][]).
+[Syncthing][] or [Dropbox][].
 
 [Syncthing]: https://syncthing.net/
 [Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service)
@@ -350,7 +350,7 @@ them accessible to machines. The general idea of those projects is to
 store secrets in a central server and send them directly to relevant
 services without human intervention. This way, passwords are not
 actually shared anymore, which is similar in spirit to the approach
-taken by centralized authentication systems like [Kerberos][]). If you
+taken by centralized authentication systems like [Kerberos][]. If you
 are looking at password management for teams, those projects may be
 worth a look.
 

fix some broken links
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
index 34716f0..a96922d 100644
--- a/blog/2017-02-22-password-managers.mdwn
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -165,7 +165,7 @@ directory through another file sharing mechanism like (say)
 [Syncthing][] or [Dropbox][]).
 
 [Syncthing]: https://syncthing.net/
-[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service
+[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service)
 
 You can use multiple distinct databases easily using the
 `PASSWORD_STORE_DIR` environment variable. For example, you could have
@@ -356,7 +356,7 @@ worth a look.
 
 [Vault]: https://www.vaultproject.io/
 [SFLvault]: http://sflvault.org/
-[Kerberos]: https://en.wikipedia.org/wiki/Kerberos_(protocol
+[Kerberos]: https://en.wikipedia.org/wiki/Kerberos_(protocol)
 
 Furthermore, some password managers that support auto-typing were
 found to be vulnerable to HTML injection attacks: if some third-party

fix path to article
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
new file mode 100644
index 0000000..34716f0
--- /dev/null
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -0,0 +1,409 @@
+[[!meta title="A look at password managers"]]
+[[!meta date="2017-02-15T12:00:00-0500"]]
+[[!meta updated="2017-02-22T19:49:36-0500"]]
+
+[[!toc startlevel=2]]
+
+As we noted in an
+[[earlier article|blog/2017-02-18-passwords-entropy]], passwords are a
+liability and we'd prefer to get rid of them, but the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators, who have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank to their favorite
+social-networking site. Despite the
+[remarkable memory capacity of the human brain][], humans are actually
+terrible at recalling even short sets of arbitrary characters with the
+precision needed for passwords.
+
+[remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
+
+Therefore humans [reuse passwords][], make them trivial or guessable,
+write them down on little paper notes and stick them on their screens,
+or just reset them by email every time. Our memory is undeniably
+failing us and we need help, which is where password managers come
+in. Password managers allow users to store an arbitrary number of
+passwords and just remember a single password to unlock them all.
+
+[reuse passwords]: https://xkcd.com/792/
+
+But there is a large variety of password managers out there, so which
+one should we be using? At my previous job, an inventory was done of
+about [40 different free-software password managers][] in different
+stages of development and of varying quality. So, obviously, this
+article will not be exhaustive, but instead focus on a smaller set of
+some well-known options that may be interesting to readers.
+
+[40 different free-software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
+
+## KeePass: the popular alternative
+
+The most commonly used password-manager design pattern is to store
+passwords in a file that is encrypted and password-protected. The most
+popular free-software password manager of this kind is probably
+[KeePass][].
+
+[KeePass]: http://keepass.info/
+
+An important feature of KeePass is the ability to auto-type passwords in
+forms, most notably in web browsers. This feature makes KeePass really
+easy to use, especially considering it also supports global key bindings
+to access passwords. KeePass databases are designed for simultaneous
+access by multiple users, for example, using a shared network drive.
+
+KeePass has a graphical interface written in C\#, so it uses the Mono
+framework on Linux. A separate project, called [KeePassX][] is a
+clean-room implementation written in C++ using the Qt framework. Both
+support the [AES][] and [Twofish][] encryption algorithms, although
+KeePass recently added support for the [ChaCha20][] cipher. AES
+[key derivation][] is used to generate the actual encryption key for
+the database, but the latest release of KeePass also added using
+[Argon2][], which was the winner of the July 2015
+[password-hashing competition][]. Both programs are more or less
+equivalent, although the original KeePass seem to have more features
+in general.
+
+[KeePassX]: https://www.keepassx.org/
+[AES]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
+[Twofish]: https://en.wikipedia.org/wiki/Twofish
+[ChaCha20]: https://en.wikipedia.org/wiki/ChaCha20
+[key derivation]: http://keepass.info/help/base/security.html#secdictprotect
+[Argon2]: https://en.wikipedia.org/wiki/Argon2
+[password-hashing competition]: https://password-hashing.net/
+
+The KeePassX project has recently been forked into another project now
+called [KeePassXC][] that implements a set of new
+features that are present in KeePass but missing from KeePassX like:
+
+[KeePassXC]: https://keepassxc.org/
+
+* auto-type on Linux, Mac OS, and Windows
+* database merging — which allows multi-user support
+* using the web site's favicon in the interface
+
+So far, the maintainers of KeePassXC seem to be open to
+[re-merging the project][] "*if the original maintainer of KeePassX in
+the future will be more active and will accept our merge and
+changes*". I can confirm that, at the time of writing, the original
+[KeePassX project][] now has 79 pending pull requests and only one
+pull request was merged since the last release, which was 2.0.3 in
+September 2016.
+
+[re-merging the project]: https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934
+[KeePassX project]: https://github.com/keepassx/keepassx
+
+While KeePass and derivatives allow multiple users to access the same
+database through the merging process, they do not support multi-party
+access to a single database. This may be a limiting factor for larger
+organizations, where you may need, for example, a different password set
+for different technical support team levels. The solution in this case
+is to use separate databases for each team, with each team using a
+different shared secret.
+
+## Pass: the standard password manager?
+
+I am currently using [password-store][], or pass, as a password
+manager. It aims to be "*the standard Unix password manager*". Pass is
+a GnuPG-based password manager that features a surprising number of
+features given its small size:
+
+[password-store]: https://www.passwordstore.org/
+
+ * copy-paste support
+ * Git integration
+ * multi-user/group support
+ * pluggable extensions (in the upcoming 1.7 release)
+
+The command-line interface is simple to use and intuitive. The
+following, will, for example, create a pass repository, a 20 character
+password for your LWN account and copy it to the clipboard:
+
+        $ pass init
+        $ pass generate -c lwn 20
+
+The main issue with pass is that it doesn't encrypt the *name* of
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the
+passwords stored in `~/.password-store`. This is a deliberate design
+decision by the upstream project, as [stated][] by a mailing list
+participant, Allan Odgaard:
+
+[stated]: https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html
+
+> Using a single file per item has the advantage of shell completion,
+> using version control, browse, move and rename the items in a file
+> browser, edit them in a regular editor (that does GPG, or manually
+> run GPG first), etc.
+
+Odgaard goes on to point out that there are alternatives that do encrypt
+the entire database (including the site names) if users really need that
+feature.
+
+Furthermore, there is a [tomb plugin][] for pass that encrypts the
+password store in a [LUKS][] container (called a "[tomb][]"), although
+it requires explicitly opening and closing the container, which makes
+it only marginally better than using full disk encryption
+system-wide. One could also argue that password file names do not hold
+secret information, only the site name and username, perhaps, and that
+doesn't require secrecy. I do believe those should be kept secret,
+however, as they could be used to discover (or prove) which sites you
+have access to and then used to perform other attacks. One could draw
+a parallel with the SSH `known_hosts` file, which used to be plain
+text but is now hashed so that hosts are more difficult to discover.
+
+[tomb plugin]: https://github.com/roddhjav/pass-tomb
+[LUKS]: https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
+[tomb]: https://github.com/dyne/Tomb
+
+Also, sharing a database for multi-user support will require some sort
+of file-sharing mechanism. Given the integrated Git support, this will
+likely involve setting up a private Git repository for your team,
+something which may not be accessible to the average Linux
+user. Nothing keeps you, however, from sharing the `~/.password-store`
+directory through another file sharing mechanism like (say)
+[Syncthing][] or [Dropbox][]).
+
+[Syncthing]: https://syncthing.net/
+[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service
+
+You can use multiple distinct databases easily using the
+`PASSWORD_STORE_DIR` environment variable. For example, you could have
+a shell alias to use a different repository for your work passwords
+with:
+
+        alias work-pass="PASSWORD_STORE_DIR=~/work-passwords pass"
+
+Group support comes from a clever use of the GnuPG multiple-recipient
+encryption support. You simply have to specify multiple OpenPGP
+identities when initializing the repository, which also works in
+subdirectories:
+
+        $ pass init -p Ateam me@example.com joelle@example.com
+        mkdir: created directory '/home/me/.password-store/Ateam'
+        Password store initialized for me@example.com, joelle@example.com
+        [master 0e3dbe7] Set GPG id to me@example.com, joelle@example.com.
+         1 file changed, 2 insertions(+)
+         create mode 100644 Ateam/.gpg-id
+
+The above will configure pass to encrypt the passwords in the `Ateam`
+directory for me@example.com and joelle@example.com. Pass depends on
+GnuPG to do the right thing when encrypting files and how those
+identities are treated is entirely delegated to GnuPG's default
+configuration. This could lead to [problems][] if
+arbitrary keys can be injected into your key ring, which could confuse

(fichier de différences tronqué)
fix link to previous article
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 67fe64f..34716f0 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -4,18 +4,19 @@
 
 [[!toc startlevel=2]]
 
-As we noted in an [earlier article][], passwords are a liability and
-we'd prefer to get rid of them, but the current reality is that we do
-use a plethora of passwords in our daily lives. This problem is
-especially acute for technology professionals, particularly system
-administrators, who have to manage a lot of different machines. But it
-also affects regular users who still use a large number of passwords,
-from their online bank to their favorite social-networking
-site. Despite the [remarkable memory capacity of the human brain][],
-humans are actually terrible at recalling even short sets of arbitrary
-characters with the precision needed for passwords.
-
-[earlier article]: https://lwn.net/Articles/713806/
+As we noted in an
+[[earlier article|blog/2017-02-18-passwords-entropy]], passwords are a
+liability and we'd prefer to get rid of them, but the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators, who have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank to their favorite
+social-networking site. Despite the
+[remarkable memory capacity of the human brain][], humans are actually
+terrible at recalling even short sets of arbitrary characters with the
+precision needed for passwords.
+
 [remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
 
 Therefore humans [reuse passwords][], make them trivial or guessable,

final reformatting for blog
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 6662f09..67fe64f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -2,43 +2,48 @@
 [[!meta date="2017-02-15T12:00:00-0500"]]
 [[!meta updated="2017-02-22T19:49:36-0500"]]
 
-[[!toc levels=2]]
+[[!toc startlevel=2]]
 
-As we noted in an [earlier article](/Articles/713806/), passwords are a
-liability and we'd prefer to get rid of them, but the current reality is
-that we do use a plethora of passwords in our daily lives. This problem
-is especially acute for technology professionals, particularly system
+As we noted in an [earlier article][], passwords are a liability and
+we'd prefer to get rid of them, but the current reality is that we do
+use a plethora of passwords in our daily lives. This problem is
+especially acute for technology professionals, particularly system
 administrators, who have to manage a lot of different machines. But it
 also affects regular users who still use a large number of passwords,
-from their online bank to their favorite social-networking site. Despite
-the [remarkable memory capacity of the human
-brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+from their online bank to their favorite social-networking
+site. Despite the [remarkable memory capacity of the human brain][],
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed for passwords.
 
-Therefore humans [reuse passwords](https://xkcd.com/792/), make them
-trivial or guessable, write them down on little paper notes and stick
-them on their screens, or just reset them by email every time. Our
-memory is undeniably failing us and we need help, which is where
-password managers come in. Password managers allow users to store an
-arbitrary number of passwords and just remember a single password to
-unlock them all.
+[earlier article]: https://lwn.net/Articles/713806/
+[remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
+
+Therefore humans [reuse passwords][], make them trivial or guessable,
+write them down on little paper notes and stick them on their screens,
+or just reset them by email every time. Our memory is undeniably
+failing us and we need help, which is where password managers come
+in. Password managers allow users to store an arbitrary number of
+passwords and just remember a single password to unlock them all.
+
+[reuse passwords]: https://xkcd.com/792/
 
 But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, an inventory was done of
-about [40 different free-software password
-managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-in different stages of development and of varying quality. So,
-obviously, this article will not be exhaustive, but instead focus on a
-smaller set of some well-known options that may be interesting to
-readers.
+about [40 different free-software password managers][] in different
+stages of development and of varying quality. So, obviously, this
+article will not be exhaustive, but instead focus on a smaller set of
+some well-known options that may be interesting to readers.
+
+[40 different free-software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
-#### KeePass: the popular alternative
+## KeePass: the popular alternative
 
 The most commonly used password-manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
 popular free-software password manager of this kind is probably
-[KeePass](http://keepass.info/).
+[KeePass][].
+
+[KeePass]: http://keepass.info/
 
 An important feature of KeePass is the ability to auto-type passwords in
 forms, most notably in web browsers. This feature makes KeePass really
@@ -47,38 +52,45 @@ to access passwords. KeePass databases are designed for simultaneous
 access by multiple users, for example, using a shared network drive.
 
 KeePass has a graphical interface written in C\#, so it uses the Mono
-framework on Linux. A separate project, called
-[KeePassX](https://www.keepassx.org/) is a clean-room implementation
-written in C++ using the Qt framework. Both support the
-[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
-[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
-although KeePass recently added support for the
-[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES [key
-derivation](http://keepass.info/help/base/security.html#secdictprotect)
-is used to generate the actual encryption key for the database, but the
-latest release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
-the July 2015 [password-hashing
-competition](https://password-hashing.net/). Both programs are more or
-less equivalent, although the original KeePass seem to have more
-features in general.
+framework on Linux. A separate project, called [KeePassX][] is a
+clean-room implementation written in C++ using the Qt framework. Both
+support the [AES][] and [Twofish][] encryption algorithms, although
+KeePass recently added support for the [ChaCha20][] cipher. AES
+[key derivation][] is used to generate the actual encryption key for
+the database, but the latest release of KeePass also added using
+[Argon2][], which was the winner of the July 2015
+[password-hashing competition][]. Both programs are more or less
+equivalent, although the original KeePass seem to have more features
+in general.
+
+[KeePassX]: https://www.keepassx.org/
+[AES]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
+[Twofish]: https://en.wikipedia.org/wiki/Twofish
+[ChaCha20]: https://en.wikipedia.org/wiki/ChaCha20
+[key derivation]: http://keepass.info/help/base/security.html#secdictprotect
+[Argon2]: https://en.wikipedia.org/wiki/Argon2
+[password-hashing competition]: https://password-hashing.net/
 
 The KeePassX project has recently been forked into another project now
-called [KeePassXC](https://keepassxc.org/) that implements a set of new
+called [KeePassXC][] that implements a set of new
 features that are present in KeePass but missing from KeePassX like:
 
--   auto-type on Linux, Mac OS, and Windows
--   database merging — which allows multi-user support
--   using the web site's favicon in the interface
+[KeePassXC]: https://keepassxc.org/
+
+* auto-type on Linux, Mac OS, and Windows
+* database merging — which allows multi-user support
+* using the web site's favicon in the interface
 
-So far, the maintainers of KeePassXC seem to be open to [re-merging the
-project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
-"<span>if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes</span>". I can confirm
-that, at the time of writing, the original [KeePassX
-project](https://github.com/keepassx/keepassx) now has 79 pending pull
-requests and only one pull request was merged since the last release,
-which was 2.0.3 in September 2016.
+So far, the maintainers of KeePassXC seem to be open to
+[re-merging the project][] "*if the original maintainer of KeePassX in
+the future will be more active and will accept our merge and
+changes*". I can confirm that, at the time of writing, the original
+[KeePassX project][] now has 79 pending pull requests and only one
+pull request was merged since the last release, which was 2.0.3 in
+September 2016.
+
+[re-merging the project]: https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934
+[KeePassX project]: https://github.com/keepassx/keepassx
 
 While KeePass and derivatives allow multiple users to access the same
 database through the merging process, they do not support multi-party
@@ -88,17 +100,19 @@ for different technical support team levels. The solution in this case
 is to use separate databases for each team, with each team using a
 different shared secret.
 
-#### Pass: the standard password manager?
+## Pass: the standard password manager?
+
+I am currently using [password-store][], or pass, as a password
+manager. It aims to be "*the standard Unix password manager*". Pass is
+a GnuPG-based password manager that features a surprising number of
+features given its small size:
 
-I am currently using [password-store](https://www.passwordstore.org/),
-or pass, as a password manager. It aims to be "<span>the standard Unix
-password manager</span>". Pass is a GnuPG-based password manager that
-features a surprising number of features given its small size:
+[password-store]: https://www.passwordstore.org/
 
--   copy-paste support
--   Git integration
--   multi-user/group support
--   pluggable extensions (in the upcoming 1.7 release)
+ * copy-paste support
+ * Git integration
+ * multi-user/group support
+ * pluggable extensions (in the upcoming 1.7 release)
 
 The command-line interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
@@ -107,54 +121,55 @@ password for your LWN account and copy it to the clipboard:
         $ pass init
         $ pass generate -c lwn 20
 
-The main issue with pass is that it doesn't encrypt the *name* of those
-entries: if someone were to compromise my machine, they could easily see
-which sites I have access to simply by listing the passwords stored in
-`~/.password-store`. This is a deliberate design decision by the
-upstream project, as
-[stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
-by a mailing list participant, Allan Odgaard:
+The main issue with pass is that it doesn't encrypt the *name* of
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the
+passwords stored in `~/.password-store`. This is a deliberate design
+decision by the upstream project, as [stated][] by a mailing list
+participant, Allan Odgaard:
 
-<div class="BigQuote">
+[stated]: https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html
 
-Using a single file per item has the advantage of shell completion,

(fichier de différences tronqué)
publish managers article
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index ce5d80c..6662f09 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,5 +1,8 @@
-A look at password managers
-===========================
+[[!meta title="A look at password managers"]]
+[[!meta date="2017-02-15T12:00:00-0500"]]
+[[!meta updated="2017-02-22T19:49:36-0500"]]
+
+[[!toc levels=2]]
 
 As we noted in an [earlier article](/Articles/713806/), passwords are a
 liability and we'd prefer to get rid of them, but the current reality is
@@ -363,3 +366,11 @@ emerging as a convenient solution that could possibly replace
 traditional password managers as users switch from generic computing
 platforms to cloud-based infrastructure. We will cover password hashers
 and the major security challenges they pose in a future article.
+
+> *Note: this article [first appeared][] in the
+> [Linux Weekly News][].*
+
+[first appeared]: https://lwn.net/Articles/714473/
+[Linux Weekly News]: http://lwn.net/
+
+[[!tag debian-planet debian passwords lwn geek security crypto]]

note about unshare
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index e119b4d..0ff14c0 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -663,6 +663,16 @@ because of missing dependency, so you need to also run `apt-get
 install -f`.
 
 [netcat]: https://en.wikipedia.org/wiki/Netcat
+
+Another option is to use the "unshare" command, which launches another
+command in a different namespace:
+
+    sudo unshare -i -m -p -u -f chroot /path/mountpoint qemu-arm-static /bin/bash
+
+This can reuse chroots previously created for cowbuilder, but the
+filesystem separation works only if /path/mountpoint is really a
+different mountpoint. Otherwise changes in the filesystem affect the
+parent host, in which case you can just copy over the chroot.
 """]]
 
 There are a *lot* of different virtualization solutions you can use

add future work
diff --git a/blog/2015-12-14-yubikey-howto.mdwn b/blog/2015-12-14-yubikey-howto.mdwn
index 6e0722d..058f7b5 100644
--- a/blog/2015-12-14-yubikey-howto.mdwn
+++ b/blog/2015-12-14-yubikey-howto.mdwn
@@ -457,4 +457,47 @@ The workaround documented there is to add `disable-ccid` to
 `~/.gnupg/scdaemon.conf`. The proper fix is to uninstall `pcscd` and
 make sure you have the appropriate udev rule, as mentioned earlier.
 
+Future work
+===========
+
+I may try to put more stuff (like my workstation) on 2FA. Right now
+I'm using the [once](https://0xacab.org/guido/once) package to fake
+2FA, but it's basically useless because I'm also storing the passwords
+in OpenPGP-encrypted files. This is not really a 2FA, except maybe for
+timing issues.
+
+To use more OTP, I can't really use OATH, because there's a limited
+set of tokens I can configure there. One way around this would be to
+use U2F, which I originally described as "for the web", but for which
+there's an actually quite solid
+[pam package](https://packages.debian.org/sid/libpam-u2f). Plus this
+would enable more robust 2FA in a bunch of places. This would mean I
+could lose access if i lose the token, however, so I may need to think
+about having a backup token. Maybe recovery codes are all I need.
+
+I could also move *more* key material in the device. Right now, I use
+only for authentication, but there's no reason why (other than
+backups) than I wouldn't use it for a certification key. Encryption is
+tricker, because those keys can be
+[slow](http://www.fsij.org/gnuk/how-fast-gnuk-token.html), which
+doesn't matter for signing stuff, but decryption happens way more
+often and on larger things.
+
+I should also look at alternative device. The
+[FST-01](http://wiki.seeed.cc/FST-01/) looks a little bare-metal, but
+it's actually pretty solid, and can be encased in
+[plastic cray](https://www.fsij.org/gnuk/customizing-2017.html),
+[origami](http://www.fsij.org/gnuk/craftwork-fst-01.html),
+[string](http://www.fsij.org/gnuk/customizing-gnuk-token.html), an
+[eraser](http://www.fsij.org/gnuk/mono-the-eraser-case.html) and so
+many cute other ideas. A friend just took the cover off another USB
+key and used that.
+
+The FST-01 is just hardware though, you need to deploy the
+[Gnuk](http://www.fsij.org/doc-gnuk/) to it to get the usual
+signing/encryption primitives going. Which is cool because it means
+the same device can also serve other purposes, like a TRNG (the
+[NeuG](http://www.gniibe.org/memo/development/gnuk/rng/neug.html)). (Why
+do all those software project names sound like troll names? :)
+
 [[!tag debian-planet geek software debian hacking security crypto]]

privileged extension is a thing in f-droid now
diff --git a/hardware/phone/htc-one-s.mdwn b/hardware/phone/htc-one-s.mdwn
index ed48982..4d4e0ab 100644
--- a/hardware/phone/htc-one-s.mdwn
+++ b/hardware/phone/htc-one-s.mdwn
@@ -940,6 +940,10 @@ Future work
   routes inside the house without having to go outside for the GPS to
   get a fix.</del> Removing gapps made that work well, along with the
   fake GSM services described above.
+* Install F-Droid using the [privileged extension][] so we don't have
+  to tick the nasty "allow 3rd party APKs"
+
+[privileged extension]: https://gitlab.com/fdroid/privileged-extension
 
 [Yalp Store]: https://github.com/yeriomin/YalpStore
 

final review from LWN
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 360eb2f..ce5d80c 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -88,8 +88,8 @@ different shared secret.
 #### Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "<span>the standard Unix
-password manager</span>". `pass` is a GnuPG-based password manager that
+or pass, as a password manager. It aims to be "<span>the standard Unix
+password manager</span>". Pass is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
 -   copy-paste support
@@ -104,11 +104,11 @@ password for your LWN account and copy it to the clipboard:
         $ pass init
         $ pass generate -c lwn 20
 
-The main issue with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone were to compromise my machine, they could
-easily see which sites I have access to simply by listing the passwords
-stored in `~/.password-store`. This is a deliberate design decision by
-the upstream project, as
+The main issue with pass is that it doesn't encrypt the *name* of those
+entries: if someone were to compromise my machine, they could easily see
+which sites I have access to simply by listing the passwords stored in
+`~/.password-store`. This is a deliberate design decision by the
+upstream project, as
 [stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
 by a mailing list participant, Allan Odgaard:
 
@@ -126,7 +126,7 @@ the entire database (including the site names) if users really need that
 feature.
 
 Furthermore, there is a [tomb
-plugin](https://github.com/roddhjav/pass-tomb) for `pass` that encrypts
+plugin](https://github.com/roddhjav/pass-tomb) for pass that encrypts
 the password store in a
 [LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) container
 (called a "[tomb](https://github.com/dyne/Tomb)"), although it requires
@@ -167,8 +167,8 @@ subdirectories:
          1 file changed, 2 insertions(+)
          create mode 100644 Ateam/.gpg-id
 
-The above will configure `pass` to encrypt the passwords in the `Ateam`
-directory for me@example.com and joelle@example.com. `pass` depends on
+The above will configure pass to encrypt the passwords in the `Ateam`
+directory for me@example.com and joelle@example.com. Pass depends on
 GnuPG to do the right thing when encrypting files and how those
 identities are treated is entirely delegated to GnuPG's default
 configuration. This could lead to [problems](/Articles/697417/) if
@@ -193,17 +193,17 @@ algorithm GnuPG chose, you may want to try this pipeline:
         gpg: original file name=''
         test
 
-As you can see, `pass` is primarily a command-line application, which
-may make it less accessible to regular users. The community has produced
-different graphical interfaces that are either using `pass` directly or
+As you can see, pass is primarily a command-line application, which may
+make it less accessible to regular users. The community has produced
+different graphical interfaces that are either using pass directly or
 operate on the storage with their own GnuPG integration. I personally
-use `pass` in combination with
+use pass in combination with
 [Rofi](https://davedavenport.github.io/rofi/) to get quick access to my
 passwords, but less savvy users may want to try the
 [QtPass](https://qtpass.org/) interface, which should be more
-user-friendly. QtPass doesn't actually depend on `pass` and can use
-GnuPG directly to interact with the `pass` database; it is available for
-Linux, BSD, OS X, and Windows.
+user-friendly. QtPass doesn't actually depend on pass and can use GnuPG
+directly to interact with the pass database; it is available for Linux,
+BSD, OS X, and Windows.
 
 #### Browser password managers
 
@@ -227,8 +227,8 @@ in 2013.
 In Firefox, there's an optional, profile-specific master password that
 unlocks all passwords. In this case, the issue is that browsers are
 generally always open, so the vault is always unlocked. And this is for
-users that actually *do* pick a master password; users are often are
-often completely unaware that they should set one.
+users that actually *do* pick a master password; users are often
+completely unaware that they should set one.
 
 The unlocking mechanism is a typical convenience-security trade-off:
 either users need to constantly input their master passwords to login or
@@ -263,17 +263,16 @@ Another alternative password manager, briefly mentioned in the previous
 article, is the minimalistic
 [Assword](https://finestructure.net/assword/) password manager that,
 despite its questionable name, is also interesting. Its main advantage
-over `pass` is that it uses a single encrypted JSON file for storage,
-and therefore doesn't leak the name of the entries by default. In
-addition to copy/paste, Assword also supports automatically entering
-passphrases in fields using the
-[xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it uses GnuPG to encrypt passphrases. According to Assword
-maintainer Daniel Kahn Gillmor in email, the main issue with Assword is
-"interaction between generated passwords and insane password policies".
-He gave the example of the Time-Warner Cable registration form that
-requires, among other things, "letters and numbers, between 8 and 16
-characters and not repeat the same characters 3 times in a row".
+over pass is that it uses a single encrypted JSON file for storage, and
+therefore doesn't leak the name of the entries by default. In addition
+to copy/paste, Assword also supports automatically entering passphrases
+in fields using the [xdo](https://www.semicomplete.com/projects/xdotool)
+library. Like pass, it uses GnuPG to encrypt passphrases. According to
+Assword maintainer Daniel Kahn Gillmor in email, the main issue with
+Assword is "interaction between generated passwords and insane password
+policies". He gave the example of the Time-Warner Cable registration
+form that requires, among other things, "letters and numbers, between 8
+and 16 characters and not repeat the same characters 3 times in a row".
 
 Another well-known password manager is the commercial
 [LastPass](https://lastpass.com/) service which
@@ -301,10 +300,10 @@ access the encrypted database.
 
 When you share a password database within a team, how do you remove
 access to a member of the team? While you can, for example, re-encrypt a
-`pass` database with new keys (thereby removing or adding certain
+pass database with new keys (thereby removing or adding certain
 accesses) or change the password on a KeePass database, a hostile party
 could have made a backup of the database before the revocation. Indeed,
-in the case of `pass`, older entries are still in the Git history. So
+in the case of pass, older entries are still in the Git history. So
 access revocation is a problematic issue found with all shared password
 managers, as it may actually mean going through every password and
 changing them online.

try again
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 18c82d7..a329696 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2017-02-08T12:00:00-0500"]]
 [[!meta updated="2017-02-18T13:37:00-0500"]]
 
-[[!toc]]
+[[!toc startlevel=2]]
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
@@ -29,7 +29,7 @@ I use the word "password" instead of "PIN" or "passphrase", which all
 roughly mean the same thing: a small piece of text that users provide to
 prove their identity.
 
-#### What makes a good password?
+## What makes a good password?
 
 A "good password" may mean different things to different people. I will
 assert that a good password has the following properties:
@@ -107,7 +107,7 @@ Everything else should be in a password manager. Those tools are
 generally under your control and should allow large enough passwords
 that the compact property is not particularly important.
 
-#### Generating secure passwords
+## Generating secure passwords
 
 We'll look now at how to generate a strong, transferable, and memorable
 password. These are most likely the passwords you will deal with most of
@@ -243,7 +243,7 @@ words, doubling the word-list length only adds a single bit of entropy.
 It is actually much better to add a word to your password than words to
 the word list that generates it.
 
-#### Generating security tokens
+## Generating security tokens
 
 As mentioned before, most password managers feature a way to generate
 strong security tokens, with different policies (symbols or not, length,
@@ -307,7 +307,7 @@ routines to generate tokens, but the procedure is the same: read from
 the kernel's entropy source (and user-generated sources in case of
 KeePass) and transform that data into a transferable string.
 
-#### Conclusion
+## Conclusion
 
 While there are many aspects to password management, we have focused on
 different techniques for users and developers to generate secure but

fix toc
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 7cf40ba..18c82d7 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2017-02-08T12:00:00-0500"]]
 [[!meta updated="2017-02-18T13:37:00-0500"]]
 
-[[!toc levels=2]]
+[[!toc]]
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure

creating tag page tag/passwords
diff --git a/tag/passwords.mdwn b/tag/passwords.mdwn
new file mode 100644
index 0000000..534ea0b
--- /dev/null
+++ b/tag/passwords.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged passwords"]]
+
+[[!inline pages="tagged(passwords)" actions="no" archive="yes"
+feedshow=10]]

put passwords article online
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
new file mode 100644
index 0000000..7cf40ba
--- /dev/null
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -0,0 +1,328 @@
+[[!meta title="Reliably generating good passwords"]]
+[[!meta date="2017-02-08T12:00:00-0500"]]
+[[!meta updated="2017-02-18T13:37:00-0500"]]
+
+[[!toc levels=2]]
+
+Passwords are used everywhere in our modern life. Between your email
+account and your bank card, a lot of critical security infrastructure
+relies on "something you know", a password. Yet there is little standard
+documentation on how to generate good passwords. There are some
+interesting possibilities for doing so; this article will look at what
+makes a good password and some tools that can be used to generate them.
+
+There is growing concern that our dependence on passwords poses a
+fundamental security flaw. For example, passwords rely on humans, who
+can be coerced to reveal secret information. Furthermore, passwords are
+"replayable": if your password is revealed or stolen, anyone can
+impersonate you to get access to your most critical assets. Therefore,
+major organizations are trying to move away from single password
+authentication. Google, for example, is [enforcing two factor
+authentication for its employees](https://cloud.google.com/security/)
+and is considering abandoning [passwords on phones as
+well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
+although we have yet to see that controversial change implemented.
+
+Yet passwords are still here and are likely to stick around for a long
+time until we figure out a better alternative. Note that in this article
+I use the word "password" instead of "PIN" or "passphrase", which all
+roughly mean the same thing: a small piece of text that users provide to
+prove their identity.
+
+#### What makes a good password?
+
+A "good password" may mean different things to different people. I will
+assert that a good password has the following properties:
+
+-   high entropy: hard to guess for machines
+-   transferable: easy to communicate for humans or transfer across
+    various protocols for computers
+-   memorable: easy to remember for humans
+
+High entropy means that the password should be unpredictable to an
+attacker, for all practical purposes. It is tempting (and not uncommon)
+to choose a password based on something else that you know, but
+unfortunately those choices are likely to be guessable, no matter how
+"secret" you believe it is. Yes, with enough effort, an attacker can
+figure out your birthday, the name of your first lover, your mother's
+maiden name, where you were last summer, or other secrets people think
+they have.
+
+The only solution here is to use a password randomly generated with
+enough randomness or "entropy" that brute-forcing the password will be
+practically infeasible. Considering that a modern off-the-shelf graphics
+card can guess millions of passwords per second using freely available
+software like [hashcat](https://www.hashcat.net/hashcat/), the typical
+requirement of "8 characters" is not considered enough anymore. With
+proper hardware, a powerful rig can crack such passwords offline within
+about a day. Even though a recent [US National Institute of Standards
+and Technology (NIST)](https://www.nist.gov/) draft still
+[recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
+a minimum of eight characters, we now more often hear recommendations of
+[twelve
+characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
+or [fourteen
+characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
+
+A password should also be easily "transferable". Some characters, like
+`&` or `!`, have special meaning on the web or the shell and can wreak
+havoc when transferred. Certain software also has policies of *refusing*
+(or requiring!) some special characters exactly for that reason. Weird
+characters also make it harder for humans to communicate passwords
+across voice channels or different cultural backgrounds. In a more
+extreme example, the popular Signal software even resorted to [using
+only digits](https://whispersystems.org/blog/safety-number-updates/) to
+transfer key fingerprints. They outlined that numbers are "*easy to
+localize*" (as opposed to words, which are language-specific) and
+"*visually distinct*".
+
+But the critical piece is the "memorable" part: it is trivial to
+generate a random string of characters, but those passwords are hard for
+humans to remember. As [xkcd noted](https://xkcd.com/936/),
+"*through 20 years of effort, we've successfully trained everyone
+to use passwords that are hard for human to remember but easy for
+computers to guess*". It explains how a series of words is a
+better password than a single word with some characters replaced.
+
+Obviously, you should not need to remember all passwords. Indeed, you
+may store some in password managers (which we'll look at in another
+article) or write them down in your wallet. In those cases, what you
+need is not a password, but something I would rather call a "token", or,
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+"*high entropy, compact, and transferable string*". Certain APIs are
+specifically crafted to use tokens. [OAuth](https://oauth.net/), for
+example, generates "access tokens" that are random strings that give
+access to services. But in our discussion, we'll use the term "token" in
+a broader sense.
+
+Notice how we removed the "memorable" property and added the "compact"
+one: we want to efficiently convert the most entropy into the shortest
+password possible, to work around possibly limiting password policies.
+For example, some bank cards only allow 5-digit security PINs and most
+web sites have an upper limit in the password length. The "compact"
+property applies less to "passwords" than tokens, because I assume that
+you will only use a password in select places: your password manager,
+SSH and OpenPGP keys, your computer login, and encryption keys.
+Everything else should be in a password manager. Those tools are
+generally under your control and should allow large enough passwords
+that the compact property is not particularly important.
+
+#### Generating secure passwords
+
+We'll look now at how to generate a strong, transferable, and memorable
+password. These are most likely the passwords you will deal with most of
+the time, as security tokens used in other settings should actually
+never show up on screen: they should be copy-pasted or automatically
+typed in forms. The password generators described here are all operated
+from the command line. Password managers often have embedded password
+generators, but usually don't provide an easy way to generate a password
+for the vault itself.
+
+The previously mentioned xkcd cartoon is probably a common cultural
+reference in the security crowd and I often use it to explain how to
+choose a good passphrase. It turns out that someone actually implemented
+xkcd author Randall Munroe's suggestion into a program called
+[xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
+
+        $ xkcdpass
+        estop mixing edelweiss conduct rejoin flexitime
+
+In verbose mode, it will show the actual entropy of the generated
+passphrase:
+
+        $ xkcdpass -V
+        The supplied word list is located at /usr/lib/python3/dist-packages/xkcdpass/static/default.txt.
+        Your word list contains 38271 words, or 2^15.22 words.
+        A 6 word password from this list will have roughly 91 (15.22 * 6) bits of entropy,
+        assuming truly random word selection.
+        estop mixing edelweiss conduct rejoin flexitime
+
+Note that the above password has 91 bits of entropy, which is about what
+a fifteen-character password would have, if chosen at random from
+uppercase, lowercase, digits, and ten symbols:
+
+        log2((26 + 26 + 10 + 10)^15) = approx. 92.548875
+
+It's also interesting to note that this is closer to the entropy of a
+fifteen-letter base64 encoded password: since each character is six
+bits, you end up with 90 bits of entropy. xkcdpass is scriptable and
+easy to use. You can also customize the word list, separators, and so on
+with different command-line options. By default, xkcdpass uses the [2 of
+12](http://wordlist.aspell.net/12dicts-readme/#nof12) word list from [12
+dicts](http://wordlist.aspell.net/12dicts/), which is not specifically
+geared toward password generation but has been curated for "common
+words" and words of different sizes.
+
+Another option is the [diceware system](http://diceware.com/). Diceware
+works by having a word list in which you look up words based on dice
+rolls. For example, rolling the five dice "1 4 2 1 4" would give the
+word "bilge". By rolling those dice five times, you generate a five word
+password that is both memorable and random. Since paper and dice do not
+seem to be popular anymore, someone wrote that as an actual program,
+aptly called [diceware](https://github.com/ulif/diceware). It works in a
+similar fashion, except that passwords are not space separated by
+default:
+
+        $ diceware
+        AbateStripDummy16thThanBrock
+
+Diceware can obviously change the output to look similar to xkcdpass,
+but can also accept actual dice rolls for those who do not trust their
+computer's entropy source:
+
+        $ diceware -d ' ' -r realdice -w en_orig
+        Please roll 5 dice (or a single dice 5 times).
+        What number shows dice number 1? 4
+        What number shows dice number 2? 2
+        What number shows dice number 3? 6
+        [...]
+        Aspire O's Ester Court Born Pk
+
+The diceware software ships with a few word lists, and the default list
+has been deliberately created for generating passwords. It is derived
+from the standard diceware list with additions from the [SecureDrop
+project](https://securedrop.org/). Diceware ships with the [EFF word
+list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases)
+that has words chosen for better recognition, but it is not enabled by
+default, even though diceware recommends using it when generating
+passwords with dice. That is because the EFF list was added [later
+on](https://github.com/ulif/diceware/issues/26). The project is
+currently [considering](https://github.com/ulif/diceware/issues/33)
+making the EFF list be the default.
+
+One disadvantage of diceware is that it doesn't actually show how much
+entropy the generated password has — those interested need to compute it

(fichier de différences tronqué)
add quote from an article i read
diff --git a/sigs.fortune b/sigs.fortune
index c0d3956..33bb940 100644
--- a/sigs.fortune
+++ b/sigs.fortune
@@ -1041,3 +1041,8 @@ Si les élections n'étaient pas indispensables à la prospérité du
 capital, on ne nous les servirait pas partout, toujours, à coup de
 fric, à coup de flics.
                         - René Binamé
+%
+The most prudent course for any society is to start from the
+assumption that the Internet should be fundamentally outside the
+domain of capital.
+                        - The Internet's Unholy Marriage to Capitalism

new changes from LWN
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 4359267..360eb2f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -5,10 +5,10 @@ As we noted in an [earlier article](/Articles/713806/), passwords are a
 liability and we'd prefer to get rid of them, but the current reality is
 that we do use a plethora of passwords in our daily lives. This problem
 is especially acute for technology professionals, particularly system
-administrators, that have to manage a lot of different machines. But it
+administrators, who have to manage a lot of different machines. But it
 also affects regular users who still use a large number of passwords,
-from their online bank credentials to their favorite social networking
-site. Despite the [remarkable memory capacity of the human
+from their online bank to their favorite social-networking site. Despite
+the [remarkable memory capacity of the human
 brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed for passwords.
@@ -25,10 +25,10 @@ But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, an inventory was done of
 about [40 different free-software password
 managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-from the last eight years, in different stages of development and of
-varying quality. So, obviously, this article will not be exhaustive, but
-instead focus on a smaller set of some well-known options that may be
-interesting to readers.
+in different stages of development and of varying quality. So,
+obviously, this article will not be exhaustive, but instead focus on a
+smaller set of some well-known options that may be interesting to
+readers.
 
 #### KeePass: the popular alternative
 
@@ -39,21 +39,21 @@ popular free-software password manager of this kind is probably
 
 An important feature of KeePass is the ability to auto-type passwords in
 forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering it also supports global keybindings
-to access passwords. KeePass databases are also designed for
-simultaneous access by multiple users for example using a shared network
-drive.
+easy to use, especially considering it also supports global key bindings
+to access passwords. KeePass databases are designed for simultaneous
+access by multiple users, for example, using a shared network drive.
 
-KeePass is a graphical interface written in C\#, so it uses the Mono
-framework in Linux. A separate project, called
+KeePass has a graphical interface written in C\#, so it uses the Mono
+framework on Linux. A separate project, called
 [KeePassX](https://www.keepassx.org/) is a clean-room implementation
 written in C++ using the Qt framework. Both support the
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
 [Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
 although KeePass recently added support for the
-[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
-derivation is also used to generate the actual encryption key for the
-database, but the latest release of KeePass also added using
+[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES [key
+derivation](http://keepass.info/help/base/security.html#secdictprotect)
+is used to generate the actual encryption key for the database, but the
+latest release of KeePass also added using
 [Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
 the July 2015 [password-hashing
 competition](https://password-hashing.net/). Both programs are more or
@@ -66,7 +66,7 @@ features that are present in KeePass but missing from KeePassX like:
 
 -   auto-type on Linux, Mac OS, and Windows
 -   database merging — which allows multi-user support
--   favicon support
+-   using the web site's favicon in the interface
 
 So far, the maintainers of KeePassXC seem to be open to [re-merging the
 project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
@@ -78,8 +78,8 @@ requests and only one pull request was merged since the last release,
 which was 2.0.3 in September 2016.
 
 While KeePass and derivatives allow multiple users to access the same
-database through the merging process, they do not support multi-tiered
-access in a single database. This may be a limiting factor for larger
+database through the merging process, they do not support multi-party
+access to a single database. This may be a limiting factor for larger
 organizations, where you may need, for example, a different password set
 for different technical support team levels. The solution in this case
 is to use separate databases for each team, with each team using a
@@ -127,16 +127,18 @@ feature.
 
 Furthermore, there is a [tomb
 plugin](https://github.com/roddhjav/pass-tomb) for `pass` that encrypts
-the password store in a LUKS container, although it requires explicitly
-opening and closing the container, which makes it only marginally better
-than using full disk encryption system-wide. One could also argue that
-password file names do not hold secret information, only the site name
-and username, perhaps, and that doesn't require secrecy. I do believe
-those should be kept secret, however, as they could be used to discover
-(or prove) which sites you have access to and then used to perform other
-attacks. One could draw a parallel with the SSH `known_hosts` file,
-which used to be plain text but is now hashed so that hosts are more
-difficult to discover.
+the password store in a
+[LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) container
+(called a "[tomb](https://github.com/dyne/Tomb)"), although it requires
+explicitly opening and closing the container, which makes it only
+marginally better than using full disk encryption system-wide. One could
+also argue that password file names do not hold secret information, only
+the site name and username, perhaps, and that doesn't require secrecy. I
+do believe those should be kept secret, however, as they could be used
+to discover (or prove) which sites you have access to and then used to
+perform other attacks. One could draw a parallel with the SSH
+`known_hosts` file, which used to be plain text but is now hashed so
+that hosts are more difficult to discover.
 
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated Git support, this will
@@ -166,8 +168,8 @@ subdirectories:
          create mode 100644 Ateam/.gpg-id
 
 The above will configure `pass` to encrypt the passwords in the `Ateam`
-directory for `me@example.com` and `joelle@example.com`. `pass` depends
-on GnuPG to do the right thing when encrypting files and how those
+directory for me@example.com and joelle@example.com. `pass` depends on
+GnuPG to do the right thing when encrypting files and how those
 identities are treated is entirely delegated to GnuPG's default
 configuration. This could lead to [problems](/Articles/697417/) if
 arbitrary keys can be injected into your key ring, which could confuse
@@ -246,8 +248,8 @@ attacks, which is mentioned below.
 
 Finally, because browser-based managers generally lack a proper password
 generator, users may fail to use properly generated passwords, so they
-can then be easily broken. A password generator may actually be
-implemented soon in Firefox, according to this [feature
+can then be easily broken. A password generator has been requested for
+Firefox, according to this [feature
 request](https://bugzilla.mozilla.org/show_bug.cgi?id=376674) opened in
 2007, and there *is* a [password generator in
 Chrome](https://www.chromium.org/developers/design-documents/password-generation),
@@ -266,7 +268,7 @@ and therefore doesn't leak the name of the entries by default. In
 addition to copy/paste, Assword also supports automatically entering
 passphrases in fields using the
 [xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it also uses GnuPG to encrypt passphrases. According to Assword
+`pass`, it uses GnuPG to encrypt passphrases. According to Assword
 maintainer Daniel Kahn Gillmor in email, the main issue with Assword is
 "interaction between generated passwords and insane password policies".
 He gave the example of the Time-Warner Cable registration form that
@@ -274,13 +276,13 @@ requires, among other things, "letters and numbers, between 8 and 16
 characters and not repeat the same characters 3 times in a row".
 
 Another well-known password manager is the commercial
-[LastPass](https://en.wikipedia.org/wiki/Lastpass) service which
+[LastPass](https://lastpass.com/) service which
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free-software command-line client called
 [lastpass-cli](https://github.com/lastpass/lastpass-cli) about three
-years ago. Unfortunately, the server software of the
-[lastpass.com](https://lastpass.com/) service is still proprietary. And
-given that LastPass has had at least [two serious security
+years ago. Unfortunately, the server software of the lastpass.com
+service is still proprietary. And given that LastPass has had at least
+[two serious security
 breaches](https://en.wikipedia.org/wiki/LastPass#Security_issues) since
 that release, one could legitimately question whether this is a viable
 solution for storing important secrets.

first internal draft
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index de3be2a..4359267 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,370 +1,364 @@
-A review of password managers
------------------------------
-
-As we discussed in the
-[previous article](https://lwn.net/Articles/713806/), passwords are a
-liability and we'd prefer to get rid of them. But the current reality
-is that we do use a plethora of passwords in our daily lives. This
-problem is especially acute for technology professionals, particularly
-system administrators that have to manage a lot of different
-machines. But it also affects regular users who still use a large
-number of passwords, from their online bank credentials to their
-favorite social networking site. Despite the
-[remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+A look at password managers
+===========================
+
+As we noted in an [earlier article](/Articles/713806/), passwords are a
+liability and we'd prefer to get rid of them, but the current reality is
+that we do use a plethora of passwords in our daily lives. This problem
+is especially acute for technology professionals, particularly system
+administrators, that have to manage a lot of different machines. But it
+also affects regular users who still use a large number of passwords,
+from their online bank credentials to their favorite social networking
+site. Despite the [remarkable memory capacity of the human
+brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
-characters with the precision needed to use passwords. Humans, in
-short, are proving to be bad at generating high entropy and unique
-passwords that they can remember.
+characters with the precision needed for passwords.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
-trivial or guessable, write them down on little paper notes and
-stick them on their screens or just reset them by email every
-time. Our memory is undeniably failing us and we need help, which is
-where password managers come in. Password managers allow users to
-store an arbitrary number of passwords and just remember a single
-password to unlock them all.
+trivial or guessable, write them down on little paper notes and stick
+them on their screens, or just reset them by email every time. Our
+memory is undeniably failing us and we need help, which is where
+password managers come in. Password managers allow users to store an
+arbitrary number of passwords and just remember a single password to
+unlock them all.
 
 But there is a large variety of password managers out there, so which
-one should we be using? At my previous job, we have inventoried about
-[40 different free software password managers][] in the last 8 years,
-in different stages of development and quality. So obviously, this
-review will not be exhaustive, but instead focus on a smaller set of
-some well known alternatives that may be interesting to our
-readers.
+one should we be using? At my previous job, an inventory was done of
+about [40 different free-software password
+managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
+from the last eight years, in different stages of development and of
+varying quality. So, obviously, this article will not be exhaustive, but
+instead focus on a smaller set of some well-known options that may be
+interesting to readers.
 
-[40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
+#### KeePass: the popular alternative
 
-KeePass: the popular alternative
---------------------------------
-
-The most commonly used password manager design pattern is to store
+The most commonly used password-manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
-popular free software password manager of this kind is probably
-KeePass.
+popular free-software password manager of this kind is probably
+[KeePass](http://keepass.info/).
 
-An important feature of KeePass is the ability to auto-type passwords
-in forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering it also supports global
-keybindings to access passwords. KeePass databases are also designed
-for simultaneous access by multiple users for example using a shared
-network drive. 
+An important feature of KeePass is the ability to auto-type passwords in
+forms, most notably in web browsers. This feature makes KeePass really
+easy to use, especially considering it also supports global keybindings
+to access passwords. KeePass databases are also designed for
+simultaneous access by multiple users for example using a shared network
+drive.
 
-KeePass is a graphical interface written in C#, so it uses the Mono
+KeePass is a graphical interface written in C\#, so it uses the Mono
 framework in Linux. A separate project, called
-[KeePassX](https://www.keepassx.org/) is a cleanroom implementation
+[KeePassX](https://www.keepassx.org/) is a clean-room implementation
 written in C++ using the Qt framework. Both support the
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
-[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption
-algorithms, although KeePass recently added support for the
+[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
+although KeePass recently added support for the
 [ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
 derivation is also used to generate the actual encryption key for the
 database, but the latest release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
-2015
-[password hashing competition](https://password-hashing.net/). Both
-programs are more or less equivalent, although the original KeePass
-seem to be more featureful in general.
-
-I should finally note that the KeePassX project has recently been
-forked into another project now called
-[KeePassXC](https://keepassxc.org/) which implement a set of new
-features present in KeePass but missing from KeePassX like:
-
-* autotype on Linux, Mac OS and Windows
-* database merging - which allows multi-user support
-* favicon support
-
-So far the maintainers of KeePassXC are open to
-[re-merging the project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
-"if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes". I could confirm that,
-at the time of writing, the original
-[KeePassX project](https://github.com/keepassx/keepassx) now has 79
-pending pull requests and only one pull request was merged since the
-last 2.0.3 release in september.
+[Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
+the July 2015 [password-hashing
+competition](https://password-hashing.net/). Both programs are more or
+less equivalent, although the original KeePass seem to have more
+features in general.
+
+The KeePassX project has recently been forked into another project now
+called [KeePassXC](https://keepassxc.org/) that implements a set of new
+features that are present in KeePass but missing from KeePassX like:
+
+-   auto-type on Linux, Mac OS, and Windows
+-   database merging — which allows multi-user support
+-   favicon support
+
+So far, the maintainers of KeePassXC seem to be open to [re-merging the
+project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
+"<span>if the original maintainer of KeePassX in the future will be more
+active and will accept our merge and changes</span>". I can confirm
+that, at the time of writing, the original [KeePassX
+project](https://github.com/keepassx/keepassx) now has 79 pending pull
+requests and only one pull request was merged since the last release,
+which was 2.0.3 in September 2016.
 
 While KeePass and derivatives allow multiple users to access the same
 database through the merging process, they do not support multi-tiered
 access in a single database. This may be a limiting factor for larger
-organizations, where you may need, for example, a different password
-set for different technical support team levels. The solution in this
-case is to use a separate databases for each team, with each team
-using a different shared secret.
+organizations, where you may need, for example, a different password set
+for different technical support team levels. The solution in this case
+is to use separate databases for each team, with each team using a
+different shared secret.
 
-Pass: the standard password manager?
-------------------------------------
+#### Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a GnuPG-based password manager that
+or `pass`, as a password manager. It aims to be "<span>the standard Unix
+password manager</span>". `pass` is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
-* copy-paste support
-* git integration
-* multi-user/group support
-* pluggable extensions (in the upcoming 1.7 release)
+-   copy-paste support
+-   Git integration
+-   multi-user/group support
+-   pluggable extensions (in the upcoming 1.7 release)
 
-The commandline interface is simple to use and intuitive. The
+The command-line interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
 password for your LWN account and copy it to the clipboard:
 
-    pass init
-    pass generate -c lwn 20
+        $ pass init
+        $ pass generate -c lwn 20
 
 The main issue with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone would compromise my machine, they could
-easily see which sites I have access to simply by listing the password
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the passwords
 stored in `~/.password-store`. This is a deliberate design decision by

(fichier de différences tronqué)
final review before sending to jake
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 499faf1..de3be2a 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -2,15 +2,14 @@ A review of password managers
 -----------------------------
 
 As we discussed in the
-[previous article](https://lwn.net/Articles/713806/), passwords are
-terrible and we'd prefer to get rid of them. But the current reality
-is that we do use a plethora of passwords in our daily lives on the
-internet. This problem is especially acute for technology
-professionals, particularly system administrators that have to manage
-a lot of different machines. But it also affects regular users who
-still use a large number of passwords in their daily lives, from their
-online bank credentials to their favorite social networking
-site. Despite the
+[previous article](https://lwn.net/Articles/713806/), passwords are a
+liability and we'd prefer to get rid of them. But the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators that have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank credentials to their
+favorite social networking site. Despite the
 [remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed to use passwords. Humans, in
@@ -20,42 +19,22 @@ passwords that they can remember.
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
 stick them on their screens or just reset them by email every
-time. Our memory is undeniably failing us and we need help.
-
-When giving security training, I often recommend people use three
-different strategies for passwords:
-
- 1. use a "stateless password manager" in the browser, or use the
-    "master key feature" of browsers to store passwords for most
-    (unimportant) websites
- 2. use a password manager for more critical passwords (online bank
-    account, main email account, etc)
- 3. remember a small set of critical passwords (bank card PIN,
-    password manager passwords)
-
-Unfortunately, a recent code review of the stateless password manager
-I was using
-([Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en))
-made me change my mind about that recommendation, which I will explain
-in a later article. Furthermore, browser-based password managers have
-their own set of issues covered later in this article. Therefore, for
-users that can afford having a trusted computer regularly accessible,
-my recommendation is generally:
-
- 1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
- 2. use a real password manager for the rest
+time. Our memory is undeniably failing us and we need help, which is
+where password managers come in. Password managers allow users to
+store an arbitrary number of passwords and just remember a single
+password to unlock them all.
 
 But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, we have inventoried about
 [40 different free software password managers][] in the last 8 years,
 in different stages of development and quality. So obviously, this
 review will not be exhaustive, but instead focus on a smaller set of
-the most well known alternative that may be interesting to our
+some well known alternatives that may be interesting to our
 readers.
 
 [40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
-Keepass: the popular alternative
+KeePass: the popular alternative
 --------------------------------
 
 The most commonly used password manager design pattern is to store
@@ -70,15 +49,18 @@ keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
 network drive. 
 
-Keepass is a graphical interface written in C#, so it uses the Mono
+KeePass is a graphical interface written in C#, so it uses the Mono
 framework in Linux. A separate project, called
 [KeePassX](https://www.keepassx.org/) is a cleanroom implementation
-written on C++ and QT. Both support the AES and Twofish encryption
-algorithms, although Keepass recently added support for the ChaCha20
-cipher. AES key derivation is also used to generate the actual
-encryption key for the database, but the latest release of KeePass
-also added using [Argon2](https://en.wikipedia.org/wiki/Argon2) the
-winner of the July 2015
+written in C++ using the Qt framework. Both support the
+[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
+[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption
+algorithms, although KeePass recently added support for the
+[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
+derivation is also used to generate the actual encryption key for the
+database, but the latest release of KeePass also added using
+[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
+2015
 [password hashing competition](https://password-hashing.net/). Both
 programs are more or less equivalent, although the original KeePass
 seem to be more featureful in general.
@@ -86,7 +68,7 @@ seem to be more featureful in general.
 I should finally note that the KeePassX project has recently been
 forked into another project now called
 [KeePassXC](https://keepassxc.org/) which implement a set of new
-features present in KeePass like:
+features present in KeePass but missing from KeePassX like:
 
 * autotype on Linux, Mac OS and Windows
 * database merging - which allows multi-user support
@@ -95,15 +77,19 @@ features present in KeePass like:
 So far the maintainers of KeePassXC are open to
 [re-merging the project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
 "if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes". I could confirm that
-the original [KeePassX project](https://github.com/keepassx/keepassx)
-now has 79 pending pull requests and only one pull request was merged
-since the last 2.0.3 release in september.
-
-KeePass and derivatives do not support multi-tiered access in a single
-database. To restrict access between teams, operators will need to use
-separate databases for each team, with each team using a different
-shared secret.
+active and will accept our merge and changes". I could confirm that,
+at the time of writing, the original
+[KeePassX project](https://github.com/keepassx/keepassx) now has 79
+pending pull requests and only one pull request was merged since the
+last 2.0.3 release in september.
+
+While KeePass and derivatives allow multiple users to access the same
+database through the merging process, they do not support multi-tiered
+access in a single database. This may be a limiting factor for larger
+organizations, where you may need, for example, a different password
+set for different technical support team levels. The solution in this
+case is to use a separate databases for each team, with each team
+using a different shared secret.
 
 Pass: the standard password manager?
 ------------------------------------
@@ -116,7 +102,7 @@ features a surprising number of features given its small size:
 * copy-paste support
 * git integration
 * multi-user/group support
-* pluggable extensions
+* pluggable extensions (in the upcoming 1.7 release)
 
 The commandline interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
@@ -137,6 +123,19 @@ item has the advantage of shell completion, using version control,
 already alternative password managers that
 [use a single (encrypted) database]".
 
+Furthermore, there is a
+[tomb plugin](https://github.com/roddhjav/pass-tomb) that encrypts the
+password store in a LUKS container, although it requires to
+explicitely open and close the container which makes it only
+marginally better than using full disk encryption system-wide. One
+could also argue that password file names do not hold secret
+information, only the site name and username, maybe, and that doesn't
+deserve secrecy. I do believe those should be kept secret however, as
+they could be used to discover (or prove) which sites you have access
+to and then leveraged to perform other attacks. One could draw a
+parallel with the SSH `known_hosts` file, which used to be plain text
+but are now hashed so they are more difficult to discover.
+
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated git support, this will
 likely involve setting up a private git repository for your team,
@@ -176,7 +175,7 @@ recommend using full key fingerprints instead of user identifiers.
 
 Regarding the actual encryption algorithms used, GnuPG 1.4.18 and
 2.1.18, during my tests, seems to default to 256 bits
-[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
+AES for
 encryption, but that has not always been the case. The chosen
 encryption algorithm actually depends on the recipient's key
 preferences, which may vary wildly: older keys and version may use

answers from dkg
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 243163f..499faf1 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -263,14 +263,20 @@ Other notable password managers
 -------------------------------
 
 Another alternative password manager, briefly mentioned in the
-previous article, is the [assword](https://finestructure.net/assword/)
-password manager that, despite its questionable name, is also
-interesting. Its main advantage over `pass` is that it uses a single
-encrypted JSON file for storage, and therefore doesn't leak the name
-of the entries by default. In addition to copy/paste, assword also
-supports automatically entering passphrases in fields with the
+previous article, is the minimalistic
+[assword](https://finestructure.net/assword/) password manager that,
+despite its questionable name, is also interesting. Its main advantage
+over `pass` is that it uses a single encrypted JSON file for storage,
+and therefore doesn't leak the name of the entries by default. In
+addition to copy/paste, assword also supports automatically entering
+passphrases in fields with the
 [xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it also uses GPG to encrypt passphrases.
+`pass`, it also uses GPG to encrypt passphrases. According to dkg, the
+main issue with assword is "interaction between generated passwords
+and insane password policies", giving the example of the Time-Warner
+Cable registration form that requires, among other things, "letters
+and numbers, between 8 and 16 characters and not repeat the same
+characters 3 times in a row".
 
 Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service which

final review with dkg, asked him for comments
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index f415d98..243163f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -10,12 +10,12 @@ professionals, particularly system administrators that have to manage
 a lot of different machines. But it also affects regular users who
 still use a large number of passwords in their daily lives, from their
 online bank credentials to their favorite social networking
-site. Scientists
-[generally agree](https://www.scientificamerican.com/article/what-is-the-memory-capacity/)
-that the human memory is phenomenal, yet it can be hard for users to
-remember a set of abstract characters. Humans, in short, are proving
-to be bad at generating high entropy and unique passwords that they
-can remember.
+site. Despite the
+[remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+humans are actually terrible at recalling even short sets of arbitrary
+characters with the precision needed to use passwords. Humans, in
+short, are proving to be bad at generating high entropy and unique
+passwords that they can remember.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
@@ -60,7 +60,7 @@ Keepass: the popular alternative
 
 The most commonly used password manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
-popular free software password manager of the kind is probably
+popular free software password manager of this kind is probably
 KeePass.
 
 An important feature of KeePass is the ability to auto-type passwords
@@ -267,18 +267,10 @@ previous article, is the [assword](https://finestructure.net/assword/)
 password manager that, despite its questionable name, is also
 interesting. Its main advantage over `pass` is that it uses a single
 encrypted JSON file for storage, and therefore doesn't leak the name
-of the entries by default. It also supports automatically entering
-passphrases in fields with the
-[xdotool](https://www.semicomplete.com/projects/xdotool) library. It
-also uses GPG to encrypt passphrases. At this point, it's still a bit
-too early in the development for wider adoption, as it's missing
-features like git integration. It also lacks an easy way to show the
-password in cleartext easily (you can set the `ASSWORD_DUMP_PASSWORDS`
-environment and dump the JSON entry, but that is not "easy"), which is
-still, unfortunately, necessary in certain circumstances. I am sure
-that the assword authors will defend this decision as an
-anti-foot-shooting device, but I have often found it necessary to
-actually examine the password with my own eyes.
+of the entries by default. In addition to copy/paste, assword also
+supports automatically entering passphrases in fields with the
+[xdo](https://www.semicomplete.com/projects/xdotool) library. Like
+`pass`, it also uses GPG to encrypt passphrases.
 
 Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service which
@@ -297,22 +289,22 @@ surface that is not present in regular password managers. A
 [2014 study by University of California researchers](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei)
 showed that, out of 5 password managers studied, every one of them was
 vulnerable to at least one of the vulnerabilities studied. LastPass
-was, in particular, vulnerable to a "bookmarklet" and a CSRF
-(Cross-Site Request Forgery) attack.
+was, in particular, vulnerable to a CSRF (Cross-Site Request Forgery)
+attack that allows an attacker to bypass account authentication and
+access the encrypted database.
 
 Issues with password managers
 -----------------------------
 
-Most of the password managers face the problematic issue of access
-revocation when used with multiple users. When you share a password
-database within a team, how do you remove access to a member of the
-team? While you can, for example, re-encrypt a pass database with new
-keys (thereby removing or adding certain accesses) or you can change
-the password on a KeePass database, an hostile party could have always
-made a backup of the database before the revocation. Indeed, in the
-case of `pass`, older entries are even still in the git history... So
-access revocation, in shared password managers, actually means going
-through every password and changing it online.
+When you share a password database within a team, how do you remove
+access to a member of the team? While you can, for example, re-encrypt
+a pass database with new keys (thereby removing or adding certain
+accesses) or you can change the password on a KeePass database, an
+hostile party could have always made a backup of the database before
+the revocation. Indeed, in the case of `pass`, older entries are 
+still in the git history... So access revocation is a problematic
+issue found in all shared password managers, as it may actually mean
+going through every password and changing it online.
 
 This fundamental problem with shared secrets can be better addressed
 with a tool like [Vaultproject.io](https://www.vaultproject.io/) or
@@ -321,8 +313,12 @@ with easy ways to store dynamic tokens like API keys and service
 passwords and share them not only with other humans, but also make
 them accessible to machines. The general idea of those projects is to
 store secrets in a central server and send them directly to relevant
-services without human intervention. If you are looking at password
-management for teams, this may be worth a look.
+services without human intervention. This way, passwords are not
+actually shared anymore, which is similar, in spirit, to the approach
+taken by centralized authentication systems like
+[Kerberos](https://en.wikipedia.org/wiki/Kerberos_(protocol)). If you
+are looking at password management for teams, those projects may be
+worth a look.
 
 Furthermore, some password managers that support auto-typing were
 found to be vulnerable to HTML injection attacks: if some third-party
@@ -344,18 +340,26 @@ your phone to be that trusted device, yet a phone can be lost or
 stolen more easily than a traditionnal workstation or even a
 laptop. And while KeePass has Android and iOS ports, those do not
 resolve the question of how to share the password storage among those
-devices or how to backup those devices. To resolve those issues, people
-are naturally migrating their storage to third party storage servers
-out of their control ("the cloud"). This breaks a fundamental
-assumption in password managers, as the encrypted database can now
-possibly be attacked online. Therefore certain password managers are
-specifically designed for the cloud, like LastPass or web browser
-profile synchronization features, without necessarily addressing the
-inherent issues with cloud storage.
-
-Another approach to resolve those issues are the "stateless" or
-"deterministic" password managers that I generally refer to as
-"password hashers". Those could possibly replace password managers as
-users switch from generic computing platforms to cloud-based
-infrastructure. We will cover password hashers and the major security
-challenges they pose in a future article.
+devices or how to backup those devices.
+
+Password managers are fundamentally file-based, and the "file" concept
+seems to be quickly disappearing, faster than we technologists
+sometimes like to admit. Looking at some relatives' use of computers,
+I notice it is less about "files" than images, videos, recipes and
+various abstract objects that are stored in the "cloud". They do not
+use local storage so much anymore. In that environment, password
+managers lose their primary advantage, which is a local, somewhat
+offline file storage that is not directly accessible to attackerss.
+Therefore certain password managers are specifically designed for the
+cloud, like LastPass or web browser profile synchronization features,
+without necessarily addressing the inherent issues with cloud storage
+and opening up huge privacy and security issues that we absolutely
+need to address.
+
+This is where the "password hasher" design comes in. Also known as
+"stateless" or "deterministic" password managers, password hashers are
+emerging as a convenient solution that could possibly replace
+traditionnal password managers as users switch from generic computing
+platforms to cloud-based infrastructure. We will cover password
+hashers and the major security challenges they pose in a future
+article.

thorough review after dkg's feedback
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index c3d539e..f415d98 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,22 +1,25 @@
 A review of password managers
 -----------------------------
 
-While our dependency on password for authentication has often been
-decried as a serious security flaw that we should get rid of, the
-current reality is that we do use a plethora of passwords in our
-daily lives on the internet. This problem is especially acute for
-technology professionals, particularly system administrators that have
-to manage a lot of different machines. But it also
-affects regular users who still use a large number of passwords in
-their daily lives, from their online bank credentials to their
-favorite social networking site. Experiments have shown that the human
-memory is phenomenal, yet it can be hard for users to remember a set
-of abstract characters. Humans, in short, are proving to be bad at
-generating high entropy and unique passwords that they can remember.
+As we discussed in the
+[previous article](https://lwn.net/Articles/713806/), passwords are
+terrible and we'd prefer to get rid of them. But the current reality
+is that we do use a plethora of passwords in our daily lives on the
+internet. This problem is especially acute for technology
+professionals, particularly system administrators that have to manage
+a lot of different machines. But it also affects regular users who
+still use a large number of passwords in their daily lives, from their
+online bank credentials to their favorite social networking
+site. Scientists
+[generally agree](https://www.scientificamerican.com/article/what-is-the-memory-capacity/)
+that the human memory is phenomenal, yet it can be hard for users to
+remember a set of abstract characters. Humans, in short, are proving
+to be bad at generating high entropy and unique passwords that they
+can remember.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
-stick it on their screens or just reset them by email every
+stick them on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
 When giving security training, I often recommend people use three
@@ -42,28 +45,27 @@ my recommendation is generally:
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a real password manager for the rest
 
-This begs the question of which password manager to use.  There is a
-large variety of password managers out there. At my previous job, we
-have inventoried about
-[40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-in the last 8 years, in different stages of development and quality,
-even when limiting ourselves to free software projects. Other sites
-list
-[43 alternatives to the popular Keepass](http://alternativeto.net/software/keepass/?license=opensource)
-password manager. So obviously, this review will not be exhaustive,
-but instead focus on a smaller set of the most well known alternative
-that may be interesting to our readers.
+But there is a large variety of password managers out there, so which
+one should we be using? At my previous job, we have inventoried about
+[40 different free software password managers][] in the last 8 years,
+in different stages of development and quality. So obviously, this
+review will not be exhaustive, but instead focus on a smaller set of
+the most well known alternative that may be interesting to our
+readers.
+
+[40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
 Keepass: the popular alternative
 --------------------------------
 
-The most commonly used password manager design pattern may well be the
-one used by [KeePass](http://keepass.info/), which is a password
-manager encrypts passwords in a single, password-protected database.
+The most commonly used password manager design pattern is to store
+passwords in a file that is encrypted and password-protected. The most
+popular free software password manager of the kind is probably
+KeePass.
 
-One key feature of KeePass is the ability to auto-type passwords
+An important feature of KeePass is the ability to auto-type passwords
 in forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering they also support global
+easy to use, especially considering it also supports global
 keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
 network drive. 
@@ -101,7 +103,7 @@ since the last 2.0.3 release in september.
 KeePass and derivatives do not support multi-tiered access in a single
 database. To restrict access between teams, operators will need to use
 separate databases for each team, with each team using a different
-share secret.
+shared secret.
 
 Pass: the standard password manager?
 ------------------------------------
@@ -126,13 +128,20 @@ password for your LWN account and copy it to the clipboard:
 The main issue with `pass` is that it doesn't encrypt the *name* of
 those entries: if someone would compromise my machine, they could
 easily see which sites I have access to simply by listing the password
-stored in `~/.password-store`.
+stored in `~/.password-store`. This is a deliberate design decision by
+upstream, as
+[stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
+by a mailing list participant, Allan Odgaard: "Using a single file per
+item has the advantage of shell completion, using version control,
+[manipulate files directly], etc." As Odgaard then says, "there are
+already alternative password managers that
+[use a single (encrypted) database]".
 
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated git support, this will
 likely involve setting up a private git repository for your team,
 something which may not be accessible to the average Linux
-user. Nothing keeps you, however, to share the `~/.password-store`
+user. Nothing keeps you, however, from sharing the `~/.password-store`
 directory through another file sharing mechanism like (say)
 [Syncthing](https://syncthing.net/) or [Dropbox][].
 
@@ -145,7 +154,7 @@ with:
 
     alias work-pass="PASSWORD_STORE_DIR=~/work-passwords pass"
 
-Group support comes from a clever use of GPG multiple-recipient
+Group support comes from a clever use of GnuPG multiple-recipient
 encryption support. You simply have to specify multiple OpenPGP
 identities when initializing the repository, which also works in
 subdirectories:
@@ -158,11 +167,15 @@ subdirectories:
      create mode 100644 Ateam/.gpg-id
 
 The above will configure `pass` to encrypt the passwords in the
-`Ateam` directory to "me" and "joelle".
-
-A key issue of `pass` is that it depends on GnuPG to do the right
-thing when encrypting files. GnuPG 1.4.18 and 2.1.18, during my tests,
-seems to default to 256 bits
+`Ateam` directory to `me@example.com` and `joelle@example.com`. `pass`
+depends on GnuPG to do the right thing when encrypting files and how
+those identities are treated is entirely delegated to GnuPG's default
+configuration. This could lead to problems if arbitrary keys can be
+injected in your keyring which could confuse GnuPG. I would therefore
+recommend using full key fingerprints instead of user identifiers.
+
+Regarding the actual encryption algorithms used, GnuPG 1.4.18 and
+2.1.18, during my tests, seems to default to 256 bits
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
 encryption, but that has not always been the case. The chosen
 encryption algorithm actually depends on the recipient's key
@@ -214,34 +227,49 @@ that was
 
 In Firefox, there's an optional, profile-specific master password that
 unlocks all passwords. In this case the issue is that browsers are
-generally always opened and the vault is always unlocked... This is a
-typical convenience-security trade-off: either users need to
-constantly input their master passwords to login or they don't, and
-the passwords are available in the clear. In this case, Chromium's
-approach of actually asking users to unlock their vault seems
-preferable, even though they actually
+generally always opened and the vault is always unlocked...  And this
+is for users that actually *do* pick a master passwords; users are
+often are often completely unaware that they should set a master
+password.
+
+The unlocking mechanism is a typical convenience-security trade-off:
+either users need to constantly input their master passwords to login
+or they don't, and the passwords are available in the clear. In this
+case, Chromium's approach of actually asking users to unlock their
+vault seems preferable, even though they actually
 [refused to implement the feature for years](https://bugs.chromium.org/p/chromium/issues/detail?id=1397).
 
-Overall, I would recommend against using browser-based password
-managers. Even if they are not used for critical sites, you will end
-up with hundreds of such passwords that are vulnerable while the
-browser is running (in the case of Firefox) or at the whim of Google
-(in the case of Chromium). Furthermore, because they lack a proper
+Overall, I would recommend against using a browser-based password
+manager. Even if it is not used for critical sites, you will end up
+with hundreds of such passwords that are vulnerable while the browser
+is running (in the case of Firefox) or at the whim of Google (in the
+case of Chromium). Furthermore, the "autofill" feature that is
+often coupled with browser-based password managers is often vulnerable
+to serious attacks which we discuss below.
+
+Finally, because browser-based managers generally lack a proper
 password generator, users may fail to use
 [properly generated passwords](https://lwn.net/Articles/713806/) which
-can then be easily broken.
+can then be easily broken. A password generator may actually be
+implemented soon in Firefox, according to this
+[feature request](https://bugzilla.mozilla.org/show_bug.cgi?id=376674)
+opened in 2007, and there *is* a
+[password generator in Chrome](https://www.chromium.org/developers/design-documents/password-generation),
+but it is disabled by default and hidden in the mysterious
+[chrome://flags](http://blogs.adobe.com/cantrell/archives/2012/07/all-about-chrome-flags.html)
+secret URL.
 
 Other notable password managers
 -------------------------------
 

(fichier de différences tronqué)
add two recipes
diff --git a/recette.mdwn b/recette.mdwn
index af15014..0ad5ecf 100644
--- a/recette.mdwn
+++ b/recette.mdwn
@@ -19,3 +19,6 @@ Autres recettes
 * Ricardo:
   * [Pain naan](https://www.ricardocuisine.com/recettes/153-pain-naan)
   * [Mango lassi](https://www.ricardocuisine.com/recettes/6705-lassi-a-la-mangue#nutritionFactsItem)
+  * [Pâte à choux](https://www.ricardocuisine.com/recettes/4586-pate-a-choux-)
+* Autres:
+  * [Pad Thai](http://www.thaitable.com/thai/recipe/pad-thai)

add two recipes
diff --git a/recette.mdwn b/recette.mdwn
index af15014..0ad5ecf 100644
--- a/recette.mdwn
+++ b/recette.mdwn
@@ -19,3 +19,6 @@ Autres recettes
 * Ricardo:
   * [Pain naan](https://www.ricardocuisine.com/recettes/153-pain-naan)
   * [Mango lassi](https://www.ricardocuisine.com/recettes/6705-lassi-a-la-mangue#nutritionFactsItem)
+  * [Pâte à choux](https://www.ricardocuisine.com/recettes/4586-pate-a-choux-)
+* Autres:
+  * [Pad Thai](http://www.thaitable.com/thai/recipe/pad-thai)

add bits about gnupg algos
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index ad62a51..c3d539e 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -108,7 +108,7 @@ Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
 or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a gpg-based password manager that
+password manager". `pass` is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
 * copy-paste support
@@ -160,6 +160,26 @@ subdirectories:
 The above will configure `pass` to encrypt the passwords in the
 `Ateam` directory to "me" and "joelle".
 
+A key issue of `pass` is that it depends on GnuPG to do the right
+thing when encrypting files. GnuPG 1.4.18 and 2.1.18, during my tests,
+seems to default to 256 bits
+[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
+encryption, but that has not always been the case. The chosen
+encryption algorithm actually depends on the recipient's key
+preferences, which may vary wildly: older keys and version may use
+anything from 128 bits AES to
+[CAST5](https://en.wikipedia.org/wiki/CAST-128) or
+[Triple DES](https://en.wikipedia.org/wiki/Triple_DES). To figure out
+which algorithm GnuPG chose, you may want to try this pipeline:
+
+    $ echo test | gpg -e -r you@example.com | gpg -d -v
+    [...]
+    gpg: encrypted with 2048-bit RSA key, ID XXXXXXX, created XXXXX
+          "You Person You <you@example.com>"
+    gpg: AES256 encrypted data
+    gpg: original file name=''
+    test
+
 As you can see, `pass` is primarily a commandline application which
 makes it less accessible to regular users. The community has produced
 a different graphical interfaces that are either using `pass` directly

final review to get a first draft
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 5bce826..ad62a51 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -3,41 +3,44 @@ A review of password managers
 
 While our dependency on password for authentication has often been
 decried as a serious security flaw that we should get rid of, the
-current reality is that we have to use a plethora of passwords in our
+current reality is that we do use a plethora of passwords in our
 daily lives on the internet. This problem is especially acute for
-technology professionals and in particular sysadmins. But it also
-affects regular users which have to use a large number of passwords in
+technology professionals, particularly system administrators that have
+to manage a lot of different machines. But it also
+affects regular users who still use a large number of passwords in
 their daily lives, from their online bank credentials to their
 favorite social networking site. Experiments have shown that the human
 memory is phenomenal, yet it can be hard for users to remember a set
 of abstract characters. Humans, in short, are proving to be bad at
 generating high entropy and unique passwords that they can remember.
 
-Therefore humans [reuse passwords](https://xkcd.com/792/), choose
-trivial or guessable ones, write them down on little post-its and
+Therefore humans [reuse passwords](https://xkcd.com/792/), make them
+trivial or guessable, write them down on little paper notes and
 stick it on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
-For this purpose, I recommend people use three different strategies
-for passwords:
+When giving security training, I often recommend people use three
+different strategies for passwords:
 
- 1. use a password hasher in the browser, or use the "master key
-    feature" of browsers to store passwords for most (unimportant)
-    websites
+ 1. use a "stateless password manager" in the browser, or use the
+    "master key feature" of browsers to store passwords for most
+    (unimportant) websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
  3. remember a small set of critical passwords (bank card PIN,
-    password manager and hasher passwords)
+    password manager passwords)
 
-Unfortunately, a recent review of the code of the password hasher I
-was using has made me change my mind about that key recommendation,
-which I will explain in a later article. Furthermore, Chromium doesn't
-support using a master key, so that option is not portable. Therefore,
-for users that can afford having a trusted computer regularly
-accessible, my recommendation is generally:
+Unfortunately, a recent code review of the stateless password manager
+I was using
+([Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en))
+made me change my mind about that recommendation, which I will explain
+in a later article. Furthermore, browser-based password managers have
+their own set of issues covered later in this article. Therefore, for
+users that can afford having a trusted computer regularly accessible,
+my recommendation is generally:
 
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
- 2. use a password manager for the rest
+ 2. use a real password manager for the rest
 
 This begs the question of which password manager to use.  There is a
 large variety of password managers out there. At my previous job, we
@@ -169,22 +172,67 @@ user-friendly. QtPass doesn't actually depend on `pass` and can use
 `gpg` directly to interact with the `pass` database and is available
 for Linux, BSD, OS X and Windows.
 
-Other alternatives
-------------------
-
-One alternative, quickly mentionned in the previous article, is the
-[assword](https://finestructure.net/assword/) password manager that,
-despite its name, is also interesting. Its main advantage over pass
-is that it uses a single encrypted JSON file for storage, and
-therefore doesn't leak the name of the entries by default. It also
-supports automatically entering passphrases in fields with the
-[xdotool](https://www.semicomplete.com/projects/xdotool)
-program. It uses GPG to encrypt passphrases but it's still a bit
+Browser password managers
+-------------------------
+
+Most users are probably already using a password manager through their
+web browser "remember password" functionality. For example, Chromium
+will ask you to remember passwords and encrypt them with your
+operating system's facilities. In Windows this encrypts the passwords
+with your login password and in GNOME this will store the passwords in
+the gnome-keyring storage. If you synchronize your Chromium settings
+with your Google account, Chromium will store those passwords in
+Google's server, encrypted with a key that is...
+[stored in the Google Account itself](https://productforums.google.com/forum/#!topic/chrome/p0vglq4ZG-8)!
+So your passwords are then only as safe as your Google account. Note
+that this was
+[previously discussed here in 2010](https://lwn.net/Articles/388309/)
+although back then Chromium didn't synchronize with the Google cloud
+or encryption with the system-level keyrings back then, a facility
+that was
+[added only in 2013](https://arstechnica.com/information-technology/2013/11/google-finally-hides-passwords-from-snoopers-in-new-builds-of-chromium/).
+
+In Firefox, there's an optional, profile-specific master password that
+unlocks all passwords. In this case the issue is that browsers are
+generally always opened and the vault is always unlocked... This is a
+typical convenience-security trade-off: either users need to
+constantly input their master passwords to login or they don't, and
+the passwords are available in the clear. In this case, Chromium's
+approach of actually asking users to unlock their vault seems
+preferable, even though they actually
+[refused to implement the feature for years](https://bugs.chromium.org/p/chromium/issues/detail?id=1397).
+
+Overall, I would recommend against using browser-based password
+managers. Even if they are not used for critical sites, you will end
+up with hundreds of such passwords that are vulnerable while the
+browser is running (in the case of Firefox) or at the whim of Google
+(in the case of Chromium). Furthermore, because they lack a proper
+password generator, users may fail to use
+[properly generated passwords](https://lwn.net/Articles/713806/) which
+can then be easily broken.
+
+Other notable password managers
+-------------------------------
+
+Another alternative password manager, quickly mentioned in the
+previous article, is the [assword](https://finestructure.net/assword/)
+password manager that, despite its questionable name, is also
+interesting. Its main advantage over `pass` is that it uses a single
+encrypted JSON file for storage, and therefore doesn't leak the name
+of the entries by default. It also supports automatically entering
+passphrases in fields with the
+[xdotool](https://www.semicomplete.com/projects/xdotool) program. It
+also uses GPG to encrypt passphrases. At this point, it's still a bit
 too early in the development for wider adoption, as it's missing
-features like git integration or showing the password in cleartext
-easily.
-
-Another is the commercial
+features like git integration. It also lacks an easy way to show the
+password in cleartext easily (you can set the `ASSWORD_DUMP_PASSWORDS`
+environment and dump the JSON entry, but that is not "easy"), which is
+still, unfortunately, necessary in certain circumstances. I am sure
+that the assword authors will defend this decision as an
+anti-foot-shooting device, but I have often found it necessary to
+actually examine the password with my own eyes.
+
+Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service who
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free software commandline client called
@@ -240,13 +288,14 @@ Future of password managers?
 ----------------------------
 
 All the solutions discussed here assume you have a computer you
-regularly have access to, which is a usage pattern that is
-disappearing with a vast majority of the population. While KeePass has
+regularly have access to, which is a usage pattern that seems to be
+disappearing with a majority of the population. While KeePass has
 Android and iOS ports, it still poses the question of how to share the
 files. People are therefore using more and more "cloud-based" password
-managers like [LastPass](https://en.wikipedia.org/wiki/LastPass), or
-bookmarklets and other gizmos I have called password hashers. Those
-will possibly replace password managers as users switch from generic
-computing platforms to cloud-based infrastructure. We will cover
-password hashers and the major security challenges they pose in a
-future article.
+managers like LastPass or Chromium's synchronization feature. Another
+solution are bookmarklets and other "stateless" or "deterministic"
+password managers that I generally refer to as "password
+hashers". Those will possibly replace password managers as users
+switch from generic computing platforms to cloud-based
+infrastructure. We will cover password hashers and the major security
+challenges they pose in a future article.

fix some lastpass references
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index a38cb4c..5bce826 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -184,16 +184,26 @@ too early in the development for wider adoption, as it's missing
 features like git integration or showing the password in cleartext
 easily.
 
-Another is the commercial [LastPass]() service who
+Another is the commercial
+[LastPass](https://en.wikipedia.org/wiki/Lastpass) service who
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free software commandline client called
 [lastpass-cli](https://github.com/lastpass/lastpass-cli) about three
-years ago. Unfortunately, the server software of the lastpass.com
-service is still proprietary, and given they have had at least
+years ago. Unfortunately, the server software of the
+[lastpass.com](https://lastpass.com/) service is still proprietary,
+and given they have had at least
 [two serious security breaches](https://en.wikipedia.org/wiki/LastPass#Security_issues)
 since that release, one could legitimetly question whether this is a
 viable solution for storing important secrets.
 
+In general, web-based password managers have serious usability issues
+and expose a whole new attack surface that is not present in regular
+password managers. A
+[2014 study by University of California researchers](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei)
+showed that, out of 5 password managers studied, every one of them was
+vulnerable to at least one of the vulnerabilities studied. LastPass
+was, in particular, vulnerable to a "bookmarklet" and a CSRF (Cross-Site
+Request Forgery) attack.
 
 Issues with password managers
 -----------------------------
@@ -216,14 +226,15 @@ passwords and share them not only with other humans, but also make
 them accessible. If, however, you are looking at password management
 for teams, this may be worth a look.
 
-Furthermore, some password managers like LastPass that support
-auto-typing were found to be vulnerable to HTML injection attacks: if
-some third-party ad or content is able to successfully hijack the
-parent DOM content, they masquerade as a form that could fool
-auto-typing software as demonstrated by this
+Furthermore, some password managers that support auto-typing were
+found to be vulnerable to HTML injection attacks: if some third-party
+ad or content is able to successfully hijack the parent DOM content,
+they masquerade as a form that could fool auto-typing software as
+demonstrated by this
 [paper](http://crypto.stanford.edu/~dabo/pubs/abstracts/pwdmgrBrowser.html)
-[submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). KeePass
-was, fortunately, not vulnerable according to the security researchers.
+[submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). Fortunately,
+KeePass was not vulnerable according to the security researchers, but
+LastPass was, again, vulnerable.
 
 Future of password managers?
 ----------------------------

add new bug with scdaemon
diff --git a/blog/2015-12-14-yubikey-howto.mdwn b/blog/2015-12-14-yubikey-howto.mdwn
index a33c8f6..6e0722d 100644
--- a/blog/2015-12-14-yubikey-howto.mdwn
+++ b/blog/2015-12-14-yubikey-howto.mdwn
@@ -184,6 +184,23 @@ gpg-agent to be able to talk with the key:
  [Yubikey importing keys howto]: https://developers.yubico.com/PGP/Importing_keys.html
  [this howto]: https://blog.night-shade.org.uk/2015/04/ssh-support-in-gpg-agent-on-ubunt/
 
+[[!important """
+Note that you do not need `pcscd` in later versions of the GnuPG
+suite. In fact, it can even cause problems because of a bug in the
+2.1.18-4 version of scdaemon that fails to fallback to PC/SC mode when
+the CCID mode fails because `pcscd` is installed. If that sounds
+completely alien to you, don't worry, it was the same for me. Just
+make sure to uninstall `pcscd` and that have the following line in
+`/lib/udev/rules.d/60-scdaemon.rules` - if not, you can add it to a
+temporary file in `/etc/udev/rules.d/yubikey-neo-otp-ccid.rules`:
+
+    ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0111", MODE="664", GROUP="plugdev"
+
+See [[!debbug 854005]] and [[!debbug 854616]] for all the gory
+details. Those bugs were found while Debian 9.0 (`stretch`) was in
+testing, so they may have already been fixed.
+"""]]
+
 Well that failed. At this point, touching the key types a bunch of
 seemingly random characters wherever my cursor is sitting - fun but
 totally useless still. That was because I failed to reconnect the key:
@@ -437,6 +454,7 @@ it impossible to read the card at all. The symptom is this:
     gpg: OpenPGP card not available: No such device
 
 The workaround documented there is to add `disable-ccid` to
-`~/.gnupg/scdaemon.conf`.
+`~/.gnupg/scdaemon.conf`. The proper fix is to uninstall `pcscd` and
+make sure you have the appropriate udev rule, as mentioned earlier.
 
 [[!tag debian-planet geek software debian hacking security crypto]]

write conclusion and some minor changes
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 4ed7c9f..a38cb4c 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -22,7 +22,7 @@ For this purpose, I recommend people use three different strategies
 for passwords:
 
  1. use a password hasher in the browser, or use the "master key
-    feature" of Firefox to store passwords for most (unimportant)
+    feature" of browsers to store passwords for most (unimportant)
     websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
@@ -33,14 +33,15 @@ Unfortunately, a recent review of the code of the password hasher I
 was using has made me change my mind about that key recommendation,
 which I will explain in a later article. Furthermore, Chromium doesn't
 support using a master key, so that option is not portable. Therefore,
-I have reduced my recommendation to:
+for users that can afford having a trusted computer regularly
+accessible, my recommendation is generally:
 
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a password manager for the rest
 
-This begs the question of which password manager one should be using?
-There is a large variety of password managers out there. At my
-previous job, we have inventoried about
+This begs the question of which password manager to use.  There is a
+large variety of password managers out there. At my previous job, we
+have inventoried about
 [40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
 in the last 8 years, in different stages of development and quality,
 even when limiting ourselves to free software projects. Other sites
@@ -53,9 +54,9 @@ that may be interesting to our readers.
 Keepass: the popular alternative
 --------------------------------
 
-The most commonly used password manager design may well be the one
-used by [KeePass](http://keepass.info/), which is a password manager
-encrypts passwords in a single, password-protected database.
+The most commonly used password manager design pattern may well be the
+one used by [KeePass](http://keepass.info/), which is a password
+manager encrypts passwords in a single, password-protected database.
 
 One key feature of KeePass is the ability to auto-type passwords
 in forms, most notably in web browsers. This feature makes KeePass really
@@ -224,5 +225,17 @@ auto-typing software as demonstrated by this
 [submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). KeePass
 was, fortunately, not vulnerable according to the security researchers.
 
-
-Stay tuned for the last article in the series about password hashers.
+Future of password managers?
+----------------------------
+
+All the solutions discussed here assume you have a computer you
+regularly have access to, which is a usage pattern that is
+disappearing with a vast majority of the population. While KeePass has
+Android and iOS ports, it still poses the question of how to share the
+files. People are therefore using more and more "cloud-based" password
+managers like [LastPass](https://en.wikipedia.org/wiki/LastPass), or
+bookmarklets and other gizmos I have called password hashers. Those
+will possibly replace password managers as users switch from generic
+computing platforms to cloud-based infrastructure. We will cover
+password hashers and the major security challenges they pose in a
+future article.

review article, reshuffle, and expand pass section
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 7807226..4ed7c9f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,17 +1,5 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-Password managers and hashers: a review
----------------------------------------
+A review of password managers
+-----------------------------
 
 While our dependency on password for authentication has often been
 decried as a serious security flaw that we should get rid of, the
@@ -30,33 +18,27 @@ trivial or guessable ones, write them down on little post-its and
 stick it on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
-This is generally where security professionals teach users about
-password managers. I often recommend people use three different strategies for
-passwords:
+For this purpose, I recommend people use three different strategies
+for passwords:
 
- 1. use a password hasher
-    in the browser, or use the "master key feature" of Firefox to
-    store passwords for most (unimportant) websites
+ 1. use a password hasher in the browser, or use the "master key
+    feature" of Firefox to store passwords for most (unimportant)
+    websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
  3. remember a small set of critical passwords (bank card PIN,
     password manager and hasher passwords)
 
-Unfortunately, a recent review of the code and design of password
-hashers has made me change my mind about that key
-recommendation. Furthermore, Chromium doesn't support using a master
-key, so that recommendation is not portable. Therefore, I have reduced
-my recommendation to:
+Unfortunately, a recent review of the code of the password hasher I
+was using has made me change my mind about that key recommendation,
+which I will explain in a later article. Furthermore, Chromium doesn't
+support using a master key, so that option is not portable. Therefore,
+I have reduced my recommendation to:
 
- 1. remember a handful of strong passwords
+ 1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a password manager for the rest
 
 This begs the question of which password manager one should be using?
-Let's look at a few alternatives.
-
-Pass: the standard password manager?
-------------------------------------
-
 There is a large variety of password managers out there. At my
 previous job, we have inventoried about
 [40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
@@ -68,71 +50,32 @@ password manager. So obviously, this review will not be exhaustive,
 but instead focus on a smaller set of the most well known alternative
 that may be interesting to our readers.
 
-I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a gpg-based password manager that
-features a surprising number of features given its small size:
-copy-paste support, git integration, and multi-user support. The
-commandline interface is simple to use and intuitive. The following,
-will, for example, create a pass repository, a 20 character password
-for your LWN account and copy it to the clipboard:
-
-    pass init
-    pass generate -c lwn 20
-
-The main concern with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone would compromise my machine, they could
-easily see which sites I have access to simply by listing the password
-stored in `~/.password-store`. Also, multi-user support depends on git
-support, which will likely involve setting up a private git repository
-for your team, something which may not be accessible to the average
-Linux user. `pass` is primarily a commandline application which makes
-it less accessible as well, although the community has produced a
-different graphical interfaces that are either using `pass` directly
-or operate on the storage with their own GPG integration. I
-personally use `pass` in combination with
-[rofi](https://davedavenport.github.io/rofi/) to get quick access to
-my passwords, but your usage will probably vary.
-
 Keepass: the popular alternative
 --------------------------------
 
-Taking another approach, the well-known
-[KeePass](http://keepass.info/) password manager encrypts passwords in
-a single, password-protected database. Keepass is a graphical
-interface written in C#, so it uses the Mono framework in Linux. A
-separate project, called [KeePassX](https://www.keepassx.org/) is a
-cleanroom implementation written on C++ and QT. Both support the AES
-and Twofish encryption algorithms, although Keepass recently added
-support for the ChaCha20 cipher. AES key derivation is also used to
-generate the actual encryption key for the database, but the latest
-release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
-2015
-[password hashing competition](https://password-hashing.net/). Both
-programs are more or less equivalent, although the original KeePass
-seem to be more featureful in general.
+The most commonly used password manager design may well be the one
+used by [KeePass](http://keepass.info/), which is a password manager
+encrypts passwords in a single, password-protected database.
 
-One key feature of both programs is the ability to auto-type passwords
-in forms, most notably in web browsers. The makes those tools really
+One key feature of KeePass is the ability to auto-type passwords
+in forms, most notably in web browsers. This feature makes KeePass really
 easy to use, especially considering they also support global
 keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
-network drive. One feature missing compared with pass would be the
-possibility of encrypting a different parts of a database to different
-user groups: pass supports the use of `.gpg-id` files that list
-multiple key identifiers that must encrypt the subdirectory. In
-comparison, users would need to share different files with different
-passphrases in order to have different access levels.
-
-In both cases, access revocation is a sensitive issue: while you can
-re-encrypt a pass database with new keys (thereby removing or adding
-certain accesses) or you can change the password on a KeePass
-database, an hostile party could have always made a backup of the
-database before the revocation. Indeed, in the case of `pass`, older
-entries are even still in the git history... So access revocation, in
-shared password managers, actually means going through every password
-and changing it online.
+network drive. 
+
+Keepass is a graphical interface written in C#, so it uses the Mono
+framework in Linux. A separate project, called
+[KeePassX](https://www.keepassx.org/) is a cleanroom implementation
+written on C++ and QT. Both support the AES and Twofish encryption
+algorithms, although Keepass recently added support for the ChaCha20
+cipher. AES key derivation is also used to generate the actual
+encryption key for the database, but the latest release of KeePass
+also added using [Argon2](https://en.wikipedia.org/wiki/Argon2) the
+winner of the July 2015
+[password hashing competition](https://password-hashing.net/). Both
+programs are more or less equivalent, although the original KeePass
+seem to be more featureful in general.
 
 I should finally note that the KeePassX project has recently been
 forked into another project now called
@@ -151,6 +94,80 @@ the original [KeePassX project](https://github.com/keepassx/keepassx)
 now has 79 pending pull requests and only one pull request was merged
 since the last 2.0.3 release in september.
 
+KeePass and derivatives do not support multi-tiered access in a single
+database. To restrict access between teams, operators will need to use
+separate databases for each team, with each team using a different
+share secret.
+
+Pass: the standard password manager?
+------------------------------------
+
+I am currently using [password-store](https://www.passwordstore.org/),
+or `pass`, as a password manager. It aims to be "the standard unix
+password manager". `pass` is a gpg-based password manager that
+features a surprising number of features given its small size:
+
+* copy-paste support
+* git integration
+* multi-user/group support
+* pluggable extensions
+
+The commandline interface is simple to use and intuitive. The
+following, will, for example, create a pass repository, a 20 character
+password for your LWN account and copy it to the clipboard:
+
+    pass init
+    pass generate -c lwn 20
+
+The main issue with `pass` is that it doesn't encrypt the *name* of
+those entries: if someone would compromise my machine, they could
+easily see which sites I have access to simply by listing the password
+stored in `~/.password-store`.
+
+Also, sharing a database for multi-user support will require some sort
+of file-sharing mechanism. Given the integrated git support, this will
+likely involve setting up a private git repository for your team,
+something which may not be accessible to the average Linux
+user. Nothing keeps you, however, to share the `~/.password-store`
+directory through another file sharing mechanism like (say)

(fichier de différences tronqué)
hide unreleased article
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d5a4cb4..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,380 +0,0 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-In previous articles, we have seen how to generate passwords and
-security tokens, and a short review of the password managers available
-on Linux platforms. There is, however, a third way of managing
-passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing". You may know those as
-"deterministic or stateless password managers" but I find the
-"password manager" denomination to be confusing because it doesn't
-actually store any password.
-
-In this text, I use the word "password" for a random string used to
-unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is
-a password and the output of a password hasher is a token.
-
-What is a password hasher?
---------------------------
-
-A password hasher is a piece of software that turns a single master
-password into multiple passwords by hashing the master password and a
-unique token (generally the hostname) to create a site-specific
-password. To change the password, the user can modify the unique
-token, for example by appending a number. Certain password managers
-also have different settings to generate passwords of different
-lengths or compositions (symbols or not, etc) to accomodate different
-site-specific password policies.
-
-The biggest advantage of password hashers is obviously that you only
-need to remember a password. But contrary to password managers, you do
-not need to carry a password vault around: there's no "state" (other
-than site-specific settings, which can be easily guessed) to carry
-around. The whole concept of password hashers relies on the concept of
-one-way,
-[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-that take an input and generate an a unique fixed size string, from
-which it is impossible to guess the original input.
-
-Password hashers are generally written as a Javascript bookmarklet or
-browser plugin, and have been around for over a decade although people
-are generally aware of their existence.
-
-A short history of password hashers
------------------------------------
-
-Since the concept is actually so old, it may be useful to go over a
-short history of popular or notable password hashers, before we go
-into the specific issues related to the implementation of a password
-hasher.
-
-[Nic Wolff](http://angel.net/~nic/passwd.current.html)
-[claims](https://news.ycombinator.com/item?id=12892655) to be the
-first to have written such a program, all the
-[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-then the hashing algorithm was MD5, although Wolff has now updated the
-algorithm to use SHA-1 and still maintains his webpage for public
-use. Another ancient but unrelated implementation, is the Standford
-University Applied Cryptography's
-[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
-implementation was
-[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
-and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
-to generate tokens. Those implementations are the simplest essence of
-password hashers: the inputs are simply the site URL and a
-password. So the algorithms are, basically, for Wolff's:
-
-    token = base64(SHA1(password + domain))
-
-And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
-
-    token = base64(HMAC(MD5, password, domain))) # PwdHash
-
-Another unrelated implementation that is still around is
-[supergenpass](https://chriszarate.github.io/supergenpass/) is a
-bookmarklet that was
-[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-originally using MD5 as well but now supports SHA512 now although
-still
-[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-and still
-[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-with
-[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10). Note that Chris Zarate, the supergenpass author, actually
-credits Nic Wolff as the inspiration for his
-implementation. Supergenpass is still in active development and is
-available for the browser (as a
-[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
-(as an
-[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
-allows you to modify the password length, but also add an extra
-profile password which adds to the secret and generates a personalized
-[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces an interesting protection,
-only found later in Password Hasher Plus. So the
-[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
-
-    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
-
-Anothor popular implementation is the Wiijo password hasher,
-[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
-It was probably the first shipped as a
-[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wiijo's
-algorithm also improved on the above algorithms, as it uses HMAC-SHA1
-instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password hasher allows you to set different password
-policies (use digits, punctuation, mixed case, special characters and
-password length) and saves the site names it uses for future
-reference. It also happens that the Wiijo password hasher, in turn,
-took its inspiration on *different* project,
-[hashapass.com](http://www.hashapass.com/),
-[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on
-HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
-"can easily be generated on almost any modern Unix-like system using
-the following command line pattern":
-
-    echo -n parameter \
-    | openssl dgst -sha1 -binary -hmac password \
-    | openssl enc -base64 \
-    | cut -c 1-8
-
-So the
-[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
-here is obviously:
-
-    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
-
-... although in the case of Password Hasher, there is a special
-routine that takes the token and inserts random characters in locations
-determined by the sum of the values of the characters in the token.
-
-Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
-to Chrome and called it
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
-Like the original password hasher, the "plus" version also keeps those
-settings in the extension and uses HMAC-SHA-1 to generate the
-password, as it is designed to be backwards-compatible with the Wiijo
-password hasher. Woodruff did add an one interesting feature: a
-profile-specific secret key that gets mixed in to create the security
-token. Stealing the master password is therefore not enough to
-generate tokens anymore. This solves one security concern with
-Password Hasher: an hostile page could watch your keystrokes and steal
-your master password and use it to derive passwords on other
-sites. Having a profile-specific secret key, not accessible to the
-site's Javascript works around that issue, but one could argue that
-typing the master password directly in the password file, while
-convenient, is probably just a bad idea in retrospect. The final
-algorithm looks something like:
-
-    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
-
-Honestly, that seems rather strange, but it's what I read from the
-source code, which is available only after decompressing the extension
-nowadays. I would have expected the simplest version:
-
-    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
-
-Password Hasher Plus then takes the token and applies the same
-special character insertion routine as the Password Hasher.
-
-Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
-self-described "humanist and scuba diving fan" released the
-[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
-Android. Lesspass introduces numerous interesting functionalities. It
-is probably the first to include a
-[commandline version](https://github.com/lesspass/cli). It also
-[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
-more robust key derivation algorithm
-([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
-account the username on the site, allowing multi account support. The
-original release (version 1) used only 8192 rounds which is now
-considered too low. In the
-[bug report](https://github.com/lesspass/lesspass/issues/38) it was
-interesting to note that LessPass couldn't do the usual practice of
-running the key derivation for 1 second to determine the number of
-rounds needed as the results need to be deterministic. At first
-glance, the LessPass source code seems
-[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
-at first glance which is always a good sign, but of course, the devil

(fichier de différences tronqué)
hide unreleased articles
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d5a4cb4..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,380 +0,0 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-In previous articles, we have seen how to generate passwords and
-security tokens, and a short review of the password managers available
-on Linux platforms. There is, however, a third way of managing
-passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing". You may know those as
-"deterministic or stateless password managers" but I find the
-"password manager" denomination to be confusing because it doesn't
-actually store any password.
-
-In this text, I use the word "password" for a random string used to
-unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is
-a password and the output of a password hasher is a token.
-
-What is a password hasher?
---------------------------
-
-A password hasher is a piece of software that turns a single master
-password into multiple passwords by hashing the master password and a
-unique token (generally the hostname) to create a site-specific
-password. To change the password, the user can modify the unique
-token, for example by appending a number. Certain password managers
-also have different settings to generate passwords of different
-lengths or compositions (symbols or not, etc) to accomodate different
-site-specific password policies.
-
-The biggest advantage of password hashers is obviously that you only
-need to remember a password. But contrary to password managers, you do
-not need to carry a password vault around: there's no "state" (other
-than site-specific settings, which can be easily guessed) to carry
-around. The whole concept of password hashers relies on the concept of
-one-way,
-[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-that take an input and generate an a unique fixed size string, from
-which it is impossible to guess the original input.
-
-Password hashers are generally written as a Javascript bookmarklet or
-browser plugin, and have been around for over a decade although people
-are generally aware of their existence.
-
-A short history of password hashers
------------------------------------
-
-Since the concept is actually so old, it may be useful to go over a
-short history of popular or notable password hashers, before we go
-into the specific issues related to the implementation of a password
-hasher.
-
-[Nic Wolff](http://angel.net/~nic/passwd.current.html)
-[claims](https://news.ycombinator.com/item?id=12892655) to be the
-first to have written such a program, all the
-[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-then the hashing algorithm was MD5, although Wolff has now updated the
-algorithm to use SHA-1 and still maintains his webpage for public
-use. Another ancient but unrelated implementation, is the Standford
-University Applied Cryptography's
-[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
-implementation was
-[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
-and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
-to generate tokens. Those implementations are the simplest essence of
-password hashers: the inputs are simply the site URL and a
-password. So the algorithms are, basically, for Wolff's:
-
-    token = base64(SHA1(password + domain))
-
-And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
-
-    token = base64(HMAC(MD5, password, domain))) # PwdHash
-
-Another unrelated implementation that is still around is
-[supergenpass](https://chriszarate.github.io/supergenpass/) is a
-bookmarklet that was
-[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-originally using MD5 as well but now supports SHA512 now although
-still
-[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-and still
-[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-with
-[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10). Note that Chris Zarate, the supergenpass author, actually
-credits Nic Wolff as the inspiration for his
-implementation. Supergenpass is still in active development and is
-available for the browser (as a
-[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
-(as an
-[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
-allows you to modify the password length, but also add an extra
-profile password which adds to the secret and generates a personalized
-[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces an interesting protection,
-only found later in Password Hasher Plus. So the
-[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
-
-    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
-
-Anothor popular implementation is the Wiijo password hasher,
-[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
-It was probably the first shipped as a
-[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wiijo's
-algorithm also improved on the above algorithms, as it uses HMAC-SHA1
-instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password hasher allows you to set different password
-policies (use digits, punctuation, mixed case, special characters and
-password length) and saves the site names it uses for future
-reference. It also happens that the Wiijo password hasher, in turn,
-took its inspiration on *different* project,
-[hashapass.com](http://www.hashapass.com/),
-[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on
-HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
-"can easily be generated on almost any modern Unix-like system using
-the following command line pattern":
-
-    echo -n parameter \
-    | openssl dgst -sha1 -binary -hmac password \
-    | openssl enc -base64 \
-    | cut -c 1-8
-
-So the
-[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
-here is obviously:
-
-    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
-
-... although in the case of Password Hasher, there is a special
-routine that takes the token and inserts random characters in locations
-determined by the sum of the values of the characters in the token.
-
-Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
-to Chrome and called it
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
-Like the original password hasher, the "plus" version also keeps those
-settings in the extension and uses HMAC-SHA-1 to generate the
-password, as it is designed to be backwards-compatible with the Wiijo
-password hasher. Woodruff did add an one interesting feature: a
-profile-specific secret key that gets mixed in to create the security
-token. Stealing the master password is therefore not enough to
-generate tokens anymore. This solves one security concern with
-Password Hasher: an hostile page could watch your keystrokes and steal
-your master password and use it to derive passwords on other
-sites. Having a profile-specific secret key, not accessible to the
-site's Javascript works around that issue, but one could argue that
-typing the master password directly in the password file, while
-convenient, is probably just a bad idea in retrospect. The final
-algorithm looks something like:
-
-    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
-
-Honestly, that seems rather strange, but it's what I read from the
-source code, which is available only after decompressing the extension
-nowadays. I would have expected the simplest version:
-
-    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
-
-Password Hasher Plus then takes the token and applies the same
-special character insertion routine as the Password Hasher.
-
-Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
-self-described "humanist and scuba diving fan" released the
-[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
-Android. Lesspass introduces numerous interesting functionalities. It
-is probably the first to include a
-[commandline version](https://github.com/lesspass/cli). It also
-[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
-more robust key derivation algorithm
-([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
-account the username on the site, allowing multi account support. The
-original release (version 1) used only 8192 rounds which is now
-considered too low. In the
-[bug report](https://github.com/lesspass/lesspass/issues/38) it was
-interesting to note that LessPass couldn't do the usual practice of
-running the key derivation for 1 second to determine the number of
-rounds needed as the results need to be deterministic. At first
-glance, the LessPass source code seems
-[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
-at first glance which is always a good sign, but of course, the devil

(fichier de différences tronqué)
yet more soft, switch to slop/maim for screenshots
diff --git a/software/mytasks.desc b/software/mytasks.desc
index 22aeaf7..af189d0 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -52,6 +52,9 @@ Packages: list
  mercurial
  myrepos
  ncdu
+ nodejs
+ nodejs-legacy
+ npm
  org-mode
  org-mode-doc
  pastebinit
@@ -60,6 +63,9 @@ Packages: list
  python
  python3
  python-jedi
+ python-pytest
+ python-setuptools-scm
+ python-wheel
  python3-jedi
  python3-pip
  python-pip
@@ -69,8 +75,10 @@ Packages: list
  twine
  qemu
  quilt
+ sqlitebrowser
  subversion
  time
+ twine
  vim
  wget
 
@@ -80,10 +88,12 @@ Description: Anarcat's desktop setup
  Shitload of stuff that doesn't fit anywhere else.
 Packages: list
  arandr
+ aspell-fr
  calibre
  chromium
  diceware
  dict
+ electrum
  emacs
  exiftool
  fim
@@ -95,12 +105,13 @@ Packages: list
  hledger
  jmtpfs
  ledger
- ledger
+ ledger-el
  less
  libnotify-bin
  localepurge
  locales
  mlocate
+ maim
  monkeysign
  monkeysphere
  mpd
@@ -115,6 +126,7 @@ Packages: list
  offlineimap
  openntpd
  parcimonie
+ pavucontrol
  pass
  pcscd
  picard
@@ -127,7 +139,7 @@ Packages: list
  rofi
  rxvt-unicode
  scdaemon
- scrot
+ slop
  sxiv
  taffybar
  thunar
@@ -153,6 +165,9 @@ Description: Anarcat's authorship tools (TeX)
  This is mostly TeX-related packages
 Packages: list
  auctex
+ dict
+ libtext-multimarkdown-perl
+ pandoc
  texlive-latex-base
  texlive-latex-recommended
  texlive-latex-extra
@@ -187,6 +202,7 @@ Packages: list
  rsync
  sdparm
  siege
+ sipcalc
  socat
  sshfs
  strace

tiny change from lwn, and fix markup
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 4865aa5..d968f57 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -37,23 +37,23 @@ assert that a good password has the following properties:
 -   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes.  It is tempting (and not
-uncommon) to choose a password based on something else that you know,
-but unfortunately those choices are likely to be guessable, no matter
-how "secret" you believe it is. Yes, with enough effort, an attacker
-can figure out your birthday, the name of your first lover, your
-mother's maiden name, where you were last summer, or other
-secrets people think they have.
-
-The only solution here is to use a password randomly generated
-with enough randomness or "entropy" that brute-forcing the password will
-be practically infeasible. Considering that a modern off-the-shelf
-graphics card can guess millions of passwords per second using freely
-available software like [hashcat](https://www.hashcat.net/hashcat/), the
-typical requirement of "8 characters" is not considered enough anymore.
-With proper hardware, a powerful rig can crack such passwords offline
-within about a day. Even though a recent [US National Institute of
-Standards and Technology (NIST)](https://www.nist.gov/) draft still
+attacker, for all practical purposes. It is tempting (and not uncommon)
+to choose a password based on something else that you know, but
+unfortunately those choices are likely to be guessable, no matter how
+"secret" you believe it is. Yes, with enough effort, an attacker can
+figure out your birthday, the name of your first lover, your mother's
+maiden name, where you were last summer, or other secrets people think
+they have.
+
+The only solution here is to use a password randomly generated with
+enough randomness or "entropy" that brute-forcing the password will be
+practically infeasible. Considering that a modern off-the-shelf graphics
+card can guess millions of passwords per second using freely available
+software like [hashcat](https://www.hashcat.net/hashcat/), the typical
+requirement of "8 characters" is not considered enough anymore. With
+proper hardware, a powerful rig can crack such passwords offline within
+about a day. Even though a recent [US National Institute of Standards
+and Technology (NIST)](https://www.nist.gov/) draft still
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
 a minimum of eight characters, we now more often hear recommendations of
 [twelve
@@ -69,16 +69,16 @@ characters also make it harder for humans to communicate passwords
 across voice channels or different cultural backgrounds. In a more
 extreme example, the popular Signal software even resorted to [using
 only digits](https://whispersystems.org/blog/safety-number-updates/) to
-transfer key fingerprints. They outlined that numbers are "easy to
-localize" (as opposed to words, which are language-specific) and
-"visually distinct".
+transfer key fingerprints. They outlined that numbers are "*easy to
+localize*" (as opposed to words, which are language-specific) and
+"*visually distinct*".
 
 But the critical piece is the "memorable" part: it is trivial to
 generate a random string of characters, but those passwords are hard for
 humans to remember. As [xkcd noted](https://xkcd.com/936/),
-"through 20 years of effort, we've successfully trained everyone
+"*through 20 years of effort, we've successfully trained everyone
 to use passwords that are hard for human to remember but easy for
-computers to guess". It explains how a series of words is a
+computers to guess*". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
@@ -86,11 +86,11 @@ may store some in password managers (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
 as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
-"high entropy, compact, and transferable string". Certain APIs are
+"*high entropy, compact, and transferable string*". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are random strings that give
-access to services. But in our discussion, we'll use the term "token" in a broader
-sense.
+access to services. But in our discussion, we'll use the term "token" in
+a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
 one: we want to efficiently convert the most entropy into the shortest
@@ -221,17 +221,17 @@ posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own
-word list, which can make dictionary-based attacks harder. Indeed,
-with such word-based password generators, the only viable way to crack
-those passwords is to use dictionary attacks, because the password is so
-long that character-based exhaustive searches are not workable, as
-they would take centuries to complete. Changing from the
-default dictionary therefore brings some advantage against attackers.
-This may be yet another "security through obscurity" procedure, however:
-a naive approach may be to use a dictionary localized to your native
-language (for example, in my case, French), but that would deter only an
-attacker that doesn't do basic research about you, so that advantage is
-quickly lost to determined attackers.
+word list, which can make dictionary-based attacks harder. Indeed, with
+such word-based password generators, the only viable way to crack those
+passwords is to use dictionary attacks, because the password is so long
+that character-based exhaustive searches are not workable, since they
+would take centuries to complete. Changing from the default dictionary
+therefore brings some advantage against attackers. This may be yet
+another "security through obscurity" procedure, however: a naive
+approach may be to use a dictionary localized to your native language
+(for example, in my case, French), but that would deter only an attacker
+that doesn't do basic research about you, so that advantage is quickly
+lost to determined attackers.
 
 One should also note that the entropy of the password doesn't depend on
 which word list is chosen, only its length. Furthermore, a larger
@@ -269,8 +269,8 @@ was suggesting the following pipeline to generate the password:
 The above command reads a certain number of bytes from the kernel
 (`head -c $entropy /dev/random`) encodes that using the `base64`
 algorithm and strips out the trailing equal sign and newlines (for large
-passwords). This is what Gillmor described as a "high-entropy compact
-printable/transferable string". The priority, in this case, is to have a
+passwords). This is what Gillmor described as a "*high-entropy compact
+printable/transferable string*". The priority, in this case, is to have a
 token that is as compact as possible with the given entropy, while at
 the same time using a character set that should cause as little trouble
 as possible on sites that restrict the characters you can use. Gillmor
@@ -295,8 +295,8 @@ that this wastes entropy as the use of `tr` discards bits from
 entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
 when compared to base64. But in the end, the maintainer
 [argued](https://lists.zx2c4.com/pipermail/password-store/2016-December/002559.html)
-that reading "reading from `/dev/urandom` has no [effect] on
-`/proc/sys/kernel/random/entropy_avail` on Linux" and dismissed
+that reading "*reading from `/dev/urandom` has no \[effect\] on
+`/proc/sys/kernel/random/entropy_avail` on Linux*" and dismissed
 the objection.
 
 Another password manager, [KeePass](http://keepass.info/) uses its own

more fixes from LWN
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 0cb96b0..4865aa5 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -178,15 +178,14 @@ computer's entropy source:
 The diceware software ships with a few word lists, and the default list
 has been deliberately created for generating passwords. It is derived
 from the standard diceware list with additions from the [SecureDrop
-project](https://securedrop.org/). Diceware ships with the better
-crafted [EFF word
-list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases),
-but it is not enabled by default, even though diceware recommends using
-it when generating passwords with dice. That is because the EFF list was
-added [later on](https://github.com/ulif/diceware/issues/26). The
-project is currently
-[considering](https://github.com/ulif/diceware/issues/33) making the EFF
-list be the default.
+project](https://securedrop.org/). Diceware ships with the [EFF word
+list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases)
+that has words chosen for better recognition, but it is not enabled by
+default, even though diceware recommends using it when generating
+passwords with dice. That is because the EFF list was added [later
+on](https://github.com/ulif/diceware/issues/26). The project is
+currently [considering](https://github.com/ulif/diceware/issues/33)
+making the EFF list be the default.
 
 One disadvantage of diceware is that it doesn't actually show how much
 entropy the generated password has — those interested need to compute it
@@ -218,7 +217,7 @@ the bounds of 24 and 85 bits. That tool is also much less customizable
 than the other two: what you see here is pretty much what you get. The
 4096-word list is also hardcoded in the C source code; it comes from a
 [Usenet sci.crypt
-posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)+)
+posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own

tiny change
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 7cf6180..0cb96b0 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -45,7 +45,7 @@ can figure out your birthday, the name of your first lover, your
 mother's maiden name, where you were last summer, or other
 secrets people think they have.
 
-The only solution here is to use a password randomly-generated
+The only solution here is to use a password randomly generated
 with enough randomness or "entropy" that brute-forcing the password will
 be practically infeasible. Considering that a modern off-the-shelf
 graphics card can guess millions of passwords per second using freely

another dkg review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index d15a740..7cf6180 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -37,14 +37,15 @@ assert that a good password has the following properties:
 -   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. A password should be random and
-not be based on something else that you know, because that is likely to
-be guessable, no matter how "secret" you believe it is. Yes, with enough
-effort, an attacker can figure out your birthday, the name of your first
-lover, your mother's maiden name, where you were last summer, or other
+attacker, for all practical purposes.  It is tempting (and not
+uncommon) to choose a password based on something else that you know,
+but unfortunately those choices are likely to be guessable, no matter
+how "secret" you believe it is. Yes, with enough effort, an attacker
+can figure out your birthday, the name of your first lover, your
+mother's maiden name, where you were last summer, or other
 secrets people think they have.
 
-The only solution here is to use a completely random password, generated
+The only solution here is to use a password randomly-generated
 with enough randomness or "entropy" that brute-forcing the password will
 be practically infeasible. Considering that a modern off-the-shelf
 graphics card can guess millions of passwords per second using freely
@@ -88,7 +89,7 @@ as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are random strings that give
-access to services. But in our discussion, we'll use tokens in a broader
+access to services. But in our discussion, we'll use the term "token" in a broader
 sense.
 
 Notice how we removed the "memorable" property and added the "compact"
@@ -221,10 +222,11 @@ posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)+)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own
-word list, which makes dictionary-based attacks much harder. Indeed,
+word list, which can make dictionary-based attacks harder. Indeed,
 with such word-based password generators, the only viable way to crack
 those passwords is to use dictionary attacks, because the password is so
-long that exhaustive searches are not workable. Changing from the
+long that character-based exhaustive searches are not workable, as
+they would take centuries to complete. Changing from the
 default dictionary therefore brings some advantage against attackers.
 This may be yet another "security through obscurity" procedure, however:
 a naive approach may be to use a dictionary localized to your native

remove pandoc conversion cruft
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 14e2774..d15a740 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -75,9 +75,9 @@ localize" (as opposed to words, which are language-specific) and
 But the critical piece is the "memorable" part: it is trivial to
 generate a random string of characters, but those passwords are hard for
 humans to remember. As [xkcd noted](https://xkcd.com/936/),
-"<span>through 20 years of effort, we've successfully trained everyone
+"through 20 years of effort, we've successfully trained everyone
 to use passwords that are hard for human to remember but easy for
-computers to guess</span>". It explains how a series of words is a
+computers to guess". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
@@ -294,8 +294,8 @@ that this wastes entropy as the use of `tr` discards bits from
 entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
 when compared to base64. But in the end, the maintainer
 [argued](https://lists.zx2c4.com/pipermail/password-store/2016-December/002559.html)
-that reading "<span>reading from `/dev/urandom` has no \[effect\] on
-`/proc/sys/kernel/random/entropy_avail` on Linux</span>" and dismissed
+that reading "reading from `/dev/urandom` has no [effect] on
+`/proc/sys/kernel/random/entropy_avail` on Linux" and dismissed
 the objection.
 
 Another password manager, [KeePass](http://keepass.info/) uses its own

jon's review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index f3c37ba..14e2774 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -8,12 +8,12 @@ documentation on how to generate good passwords. There are some
 interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
-There is growing concern that our dependence on passwords pose
-fundamental security flaw. First, passwords rely on humans, who can
-be coerced to reveal secret information. Furthermore, passwords are
+There is growing concern that our dependence on passwords poses a
+fundamental security flaw. For example, passwords rely on humans, who
+can be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
-impersonate you to get access to your most critical assets. Therefore, major
-organizations are trying to move away from single password
+impersonate you to get access to your most critical assets. Therefore,
+major organizations are trying to move away from single password
 authentication. Google, for example, is [enforcing two factor
 authentication for its employees](https://cloud.google.com/security/)
 and is considering abandoning [passwords on phones as
@@ -21,9 +21,9 @@ well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. Note that in this text I use the word
-"password" instead of "PIN" or "passphrase", which all roughly mean the
-same thing: a small piece of text that users provide to
+time until we figure out a better alternative. Note that in this article
+I use the word "password" instead of "PIN" or "passphrase", which all
+roughly mean the same thing: a small piece of text that users provide to
 prove their identity.
 
 #### What makes a good password?
@@ -31,44 +31,43 @@ prove their identity.
 A "good password" may mean different things to different people. I will
 assert that a good password has the following properties:
 
--   high entropy - hard to guess for machines
--   transferable - easy to communicate for humans or transfer across
-    weird protocols for computers
--   memorable - easy to remember for humans
+-   high entropy: hard to guess for machines
+-   transferable: easy to communicate for humans or transfer across
+    various protocols for computers
+-   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. A password should be random, and
-not be based on something else that
-you know, because that is likely to be guessable, no matter how "secret"
-you believe it is. Yes, with enough effort, an attacker can figure out
-your birthday, the name of your first lover, your mother's maiden name,
-where you were last summer, or other silly secrets people think they
-have.
+attacker, for all practical purposes. A password should be random and
+not be based on something else that you know, because that is likely to
+be guessable, no matter how "secret" you believe it is. Yes, with enough
+effort, an attacker can figure out your birthday, the name of your first
+lover, your mother's maiden name, where you were last summer, or other
+secrets people think they have.
 
 The only solution here is to use a completely random password, generated
 with enough randomness or "entropy" that brute-forcing the password will
-be practically infeasible. Considering that modern off-the-shelf
-graphics card can guess millions of passwords per second, using freely
+be practically infeasible. Considering that a modern off-the-shelf
+graphics card can guess millions of passwords per second using freely
 available software like [hashcat](https://www.hashcat.net/hashcat/), the
 typical requirement of "8 characters" is not considered enough anymore.
 With proper hardware, a powerful rig can crack such passwords offline
-within about a day. Even though the recent [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) report still
+within about a day. Even though a recent [US National Institute of
+Standards and Technology (NIST)](https://www.nist.gov/) draft still
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
-a minimum of 8 characters, we now more often hear recommendations of [12
+a minimum of eight characters, we now more often hear recommendations of
+[twelve
 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
-or [14
+or [fourteen
 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
 
-A password should also be easily "transferable". Some characters like
-`&` or `!` have special meaning on the web or the shell and can wreak
-havoc when transferred. Certain software also have policies of
-*refusing* (or requiring!) some special characters exactly for that
-reason. Weird characters also make it harder for humans to communicate
-passwords across voice channels or different cultural backgrounds. In a
-more extreme example, the popular Signal software even resorted to
-[using only
-digits](https://whispersystems.org/blog/safety-number-updates/) to
+A password should also be easily "transferable". Some characters, like
+`&` or `!`, have special meaning on the web or the shell and can wreak
+havoc when transferred. Certain software also has policies of *refusing*
+(or requiring!) some special characters exactly for that reason. Weird
+characters also make it harder for humans to communicate passwords
+across voice channels or different cultural backgrounds. In a more
+extreme example, the popular Signal software even resorted to [using
+only digits](https://whispersystems.org/blog/safety-number-updates/) to
 transfer key fingerprints. They outlined that numbers are "easy to
 localize" (as opposed to words, which are language-specific) and
 "visually distinct".
@@ -82,15 +81,15 @@ computers to guess</span>". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
-may store some in password generators (which we'll look at in another
+may store some in password managers (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
-as Debian Developer Daniel Kahn Gillmor said in a private email, a
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
-example, generates "access tokens" that are basically random strings
-that give access to services. But in our discussion, we'll use tokens in
-a broader sense.
+example, generates "access tokens" that are random strings that give
+access to services. But in our discussion, we'll use tokens in a broader
+sense.
 
 Notice how we removed the "memorable" property and added the "compact"
 one: we want to efficiently convert the most entropy into the shortest
@@ -100,27 +99,26 @@ web sites have an upper limit in the password length. The "compact"
 property applies less to "passwords" than tokens, because I assume that
 you will only use a password in select places: your password manager,
 SSH and OpenPGP keys, your computer login, and encryption keys.
-Everything else should be in a password manager.
-Those tools are generally under your control and should allow large
-enough passwords that the compact property is not particularly
-important.
+Everything else should be in a password manager. Those tools are
+generally under your control and should allow large enough passwords
+that the compact property is not particularly important.
 
 #### Generating secure passwords
 
 We'll look now at how to generate a strong, transferable, and memorable
-password. This is most likely the passwords you will deal with most of
-the time, as security tokens should actually never show up on screen:
-they should be copy-pasted or automatically typed in forms. The password
-generators described here are all operated from the command line. It's
-also interesting to note that password managers often have embedded
-password generators, but usually don't provide an easy way to generate a
-password for the vault itself.
-
-The previously mentioned \#936 cartoon from xkcd is probably a common
-cultural reference in the security crowd and I often use it to explain
-how to choose a good passphrase. It turns out that someone actually
-implemented xkcd author Randall Munroe's suggestion into a program
-called [xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
+password. These are most likely the passwords you will deal with most of
+the time, as security tokens used in other settings should actually
+never show up on screen: they should be copy-pasted or automatically
+typed in forms. The password generators described here are all operated
+from the command line. Password managers often have embedded password
+generators, but usually don't provide an easy way to generate a password
+for the vault itself.
+
+The previously mentioned xkcd cartoon is probably a common cultural
+reference in the security crowd and I often use it to explain how to
+choose a good passphrase. It turns out that someone actually implemented
+xkcd author Randall Munroe's suggestion into a program called
+[xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
 
         $ xkcdpass
         estop mixing edelweiss conduct rejoin flexitime
@@ -136,19 +134,19 @@ passphrase:
         estop mixing edelweiss conduct rejoin flexitime
 
 Note that the above password has 91 bits of entropy, which is about what
-a 15 character password would have, if chosen from uppercase, lowercase,
-digits and 10 symbols:
+a fifteen-character password would have, if chosen at random from
+uppercase, lowercase, digits, and ten symbols:
 
         log2((26 + 26 + 10 + 10)^15) = approx. 92.548875
 
 It's also interesting to note that this is closer to the entropy of a
-15-letter base64 encoded password: since each character is 6 bits, you
-end up with 90 bits of entropy. xkcdpass is scriptable and easy to use.
-You can also customize the word list, separators, and so on with
-different command-line options. By default, xkcdpass uses the [2 of
+fifteen-letter base64 encoded password: since each character is six
+bits, you end up with 90 bits of entropy. xkcdpass is scriptable and
+easy to use. You can also customize the word list, separators, and so on
+with different command-line options. By default, xkcdpass uses the [2 of
 12](http://wordlist.aspell.net/12dicts-readme/#nof12) word list from [12
-dicts](http://wordlist.aspell.net/12dicts/) and is not specifically
-geared towards password generation but has been curated for "common
+dicts](http://wordlist.aspell.net/12dicts/), which is not specifically
+geared toward password generation but has been curated for "common
 words" and words of different sizes.
 
 Another option is the [diceware system](http://diceware.com/). Diceware
@@ -176,36 +174,38 @@ computer's entropy source:
         [...]

(fichier de différences tronqué)
my own final review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index f3ec250..f3c37ba 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -8,20 +8,11 @@ documentation on how to generate good passwords. There are some
 interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
-Recently, the US [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) made a new set of recommendations, the [Special
-Publication 800-63-3: Digital Identity
-Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
-standards of password requirements and practices, but that has yet to
-propagate to the industry. The publication also covers more than just
-passwords, but also password policies like expiration and so on, that
-are beyond the scope of this article.
-
 There is growing concern that our dependence on passwords pose
-fundamental security flaw. For example, passwords rely on humans, who can
+fundamental security flaw. First, passwords rely on humans, who can
 be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
-impersonate you to get access to your most critical assets. Major
+impersonate you to get access to your most critical assets. Therefore, major
 organizations are trying to move away from single password
 authentication. Google, for example, is [enforcing two factor
 authentication for its employees](https://cloud.google.com/security/)
@@ -30,10 +21,9 @@ well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. I will start by looking
-at basic password hygiene. Note that in this text I use the word
+time until we figure out a better alternative. Note that in this text I use the word
 "password" instead of "PIN" or "passphrase", which all roughly mean the
-same thing: a small piece of text that users are expected to provide to
+same thing: a small piece of text that users provide to
 prove their identity.
 
 #### What makes a good password?
@@ -47,8 +37,8 @@ assert that a good password has the following properties:
 -   memorable - easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. It may seem obvious to some, but a
-password should be random. It should not be based on something else that
+attacker, for all practical purposes. A password should be random, and
+not be based on something else that
 you know, because that is likely to be guessable, no matter how "secret"
 you believe it is. Yes, with enough effort, an attacker can figure out
 your birthday, the name of your first lover, your mother's maiden name,
@@ -61,9 +51,11 @@ be practically infeasible. Considering that modern off-the-shelf
 graphics card can guess millions of passwords per second, using freely
 available software like [hashcat](https://www.hashcat.net/hashcat/), the
 typical requirement of "8 characters" is not considered enough anymore.
-With proper hardware, a powerful offline rig can crack such passwords
-within about a day. Even though the NIST report still recommends a
-minimum of 8 characters, we now more often hear recommendations of [12
+With proper hardware, a powerful rig can crack such passwords offline
+within about a day. Even though the recent [National Institute of Standards and Technology
+(NIST)](https://www.nist.gov/) report still
+[recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
+a minimum of 8 characters, we now more often hear recommendations of [12
 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
 or [14
 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
@@ -93,7 +85,7 @@ Obviously, you should not need to remember all passwords. Indeed, you
 may store some in password generators (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
-as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+as Debian Developer Daniel Kahn Gillmor said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are basically random strings
@@ -107,10 +99,11 @@ For example, some bank cards only allow 5-digit security PINs and most
 web sites have an upper limit in the password length. The "compact"
 property applies less to "passwords" than tokens, because I assume that
 you will only use a password in select places: your password manager,
-SSH and OpenPGP keys, your computer login, and encryption keys, period.
+SSH and OpenPGP keys, your computer login, and encryption keys.
+Everything else should be in a password manager.
 Those tools are generally under your control and should allow large
 enough passwords that the compact property is not particularly
-important. Everything else should be in a password manager.
+important.
 
 #### Generating secure passwords
 
@@ -179,7 +172,9 @@ computer's entropy source:
         Please roll 5 dice (or a single dice 5 times).
         What number shows dice number 1? 4
         What number shows dice number 2? 2
-        What number shows dice number 3? [...]
+        What number shows dice number 3? 6
+        [...]
+        Aspire O's Ester Court Born Pk
 
 The diceware software ships with a few word lists, and the default has
 been deliberately geared toward generating passwords. It is derived from
@@ -188,16 +183,18 @@ project](https://securedrop.org/). It is interesting to note that, while
 diceware ships with the better crafted [EFF word
 list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases),
 it is not enabled by default, even though diceware recommends using it
-when generating passwords with dice. This is probably because the EFF
-list was added [later on](https://github.com/ulif/diceware/issues/26).
+when generating passwords with dice. That is because the EFF
+list was added [later on](https://github.com/ulif/diceware/issues/26)
+and they are
+[considering making the EFF list the default](https://github.com/ulif/diceware/issues/33).
 
 One disadvantage of diceware is that it doesn't actually tell you how
 much entropy the generated password has — you need to compute it
 yourself. The actual number depends on the word list: the default word
-list has about 13 bits of entropy per word, which means the default 6
-word passwords have about 78 bits of entropy:
+list has 13 bits of entropy per word (being exactly 8192 words long), which means the default 6
+word passwords have 78 bits of entropy:
 
-        log2(7776) * 6 = approx. 77.548875
+        log2(8192) * 6 = 78
 
 Both of these programs are rather new, having, for example, entered Debian
 only after the last stable release, so they may not be directly available for
@@ -218,27 +215,40 @@ better control over the level of entropy:
 For some reason, `passwdqc` restricts the entropy of passwords between
 the bounds of 24 and 85 bits. That tool is also much less customizable
 than the other two: what you see here is pretty much what you get. The
-word list is also hardcoded in the C source code.
+4096 word list is also hardcoded in the C source code and comes from
+an
+[old usenet post](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
+from 1997...
 
 A key feature of xkcdpass and diceware is that you can craft your own
 word list, which makes dictionary-based attacks much harder. Indeed,
 with word-based password generators, the only viable way to crack those
 passwords is to use dictionary attacks, because the password is so long
 that exhaustive searches are not workable. Changing from the default
-dictionary therefore brings a notable advantage against attackers. This
+dictionary therefore brings some advantage against attackers. This
 may be yet another "security through obscurity" procedure, however: an
 naive approach may be to use a dictionary localized to your native
 language (for example, in my case, French), but that would deter only an
 attacker that doesn't do basic research about you, so that advantage is
 quickly lost to determined attackers.
 
+One should also note that the actual entropy of the password doesn't
+depend on the actual word list chosen, but its length. Furthermore, a
+larger dictionnary only expands the search space logarithmically, or,
+in other words, doubling the word list length only adds a single bit
+of entropy so it is actually much better to add a word to your
+password than a word to the word list that generates it.
+
 #### Generating security tokens
 
 As mentioned before, most password managers feature a way to generate
 strong security tokens, with different policies (symbols or not, length,
 etc). In general, you should use your password manager's
 password-generation functionality to generate tokens for sites you
-visit. But how are those functionalities implemented?
+visit. But how are those functionalities implemented and what can you
+do if your password manager (for example Firefox's [master password
+feature](https://support.mozilla.org/en-US/kb/use-master-password-protect-stored-logins))
+does not actually generate passwords for you?
 
 [`pass`](https://www.passwordstore.org/), the standard UNIX password
 manager, delegates this task to the widely known
@@ -253,44 +263,43 @@ email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.htm
 It turns out that there are lots of ways to skin this particular cat. I
 was suggesting the following pipeline to generate the password:
 
-        $ head -c $entropy /dev/random | base64 | tr -d '\n='
+        head -c $entropy /dev/random | base64 | tr -d '\n='
 
 The above command takes a certain number from the kernel
 (`head -c $entropy /dev/random`) encodes that using the `base64`
 algorithm and strips out the trailing equal sign and newlines (for large
 passwords). This is what Gillmor described as a "high-entropy compact
-printable/transferable string". The priority, in this specific case, is
+printable/transferable string". The priority, in this case, is
 to have a token that is as compact as possible with the given entropy,
-while at the same time use a character set that should not cause as
+while at the same time use a character set that should cause as
 little trouble as possible on sites that restrict the characters you can
 use. Gillmor is a co-maintainer of the
 [Assword](https://finestructure.net/assword/) password manager, which
-chose base64 because it is widely available and understood, and only
+chose base64 because it is widely available and understood and only
 takes up 33% more space than the original 8-bit binary encoding. After
-an interesting discussion, the pass maintainer, Jason A. Donenfeld,
+a lengthy discussion, the pass maintainer, Jason A. Donenfeld,
 chose the following pipeline:
 
-        CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
-        CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
-        [...]
         read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
 
 The above is similar, except it uses `tr` to directly to read characters

(fichier de différences tronqué)
small changes after jake's comments
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 0363e9a..f3ec250 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -9,16 +9,16 @@ interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
 Recently, the US [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) made a new recommendation, the [Special
-Publication 800-63-3: Digital Authentication
+(NIST)](https://www.nist.gov/) made a new set of recommendations, the [Special
+Publication 800-63-3: Digital Identity
 Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
 standards of password requirements and practices, but that has yet to
 propagate to the industry. The publication also covers more than just
 passwords, but also password policies like expiration and so on, that
 are beyond the scope of this article.
 
-I also recognize that we should move away from passwords where possible.
-They pose a fundamental security flaw: the reliance on humans, who can
+There is growing concern that our dependence on passwords pose
+fundamental security flaw. For example, passwords rely on humans, who can
 be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
 impersonate you to get access to your most critical assets. Major
@@ -199,11 +199,13 @@ word passwords have about 78 bits of entropy:
 
         log2(7776) * 6 = approx. 77.548875
 
-Both of these programs are recent, having, for example, entered Debian
-only after the last stable release, so they may not be available for
+Both of these programs are rather new, having, for example, entered Debian
+only after the last stable release, so they may not be directly available for
 your distribution. The diceware method, of course, only needs a set of
-dice and a word list, so that is much more portable. But if you insist
-on using an older computer to generate your passphrase, you can take a
+dice and a word list, so that is much more portable, and both diceware
+and xkcdpass can be installed through
+[Pip](https://pip.pypa.io/). However, if this is all too complicated,
+you can take a
 look at [Openwall's passwdqc](http://www.openwall.com/passwdqc/), which
 generates more memorable passphrases while at the same time allowing for
 better control over the level of entropy:
@@ -220,7 +222,7 @@ word list is also hardcoded in the C source code.
 
 A key feature of xkcdpass and diceware is that you can craft your own
 word list, which makes dictionary-based attacks much harder. Indeed,
-with such pattern-based software, the only viable way to crack those
+with word-based password generators, the only viable way to crack those
 passwords is to use dictionary attacks, because the password is so long
 that exhaustive searches are not workable. Changing from the default
 dictionary therefore brings a notable advantage against attackers. This

first LWN unpublished draft
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 3a1272d..0363e9a 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -1,351 +1,308 @@
-How to reliably generate passwords and tokens
-=============================================
+Reliably generating good passwords
+==================================
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
-relies on "something you know", a password. Yet there is little
-standard documentation on how to generate good passwords. Recently,
-[NIST](https://www.nist.gov/) made a new recommendation, the
-[Special Publication 800-63-3: Digital Authentication Guidelines](https://pages.nist.gov/800-63-3/)
-which outlines new standards of password requirements and practices,
-but that has yet to propagate to the industry. The publication also covers more than
-just passwords, but also password policies like expiration and so on,
-that are beyond the scope of this article.
-
-I also recognize that we should move away from passwords where
-possible. They pose a fundamental security flaw: the reliance on
-humans, which can be coerced to reveal secret
-information. Furthermore, passwords are "replayable": if your password
-is revealed or stolen, anyone can impersonate you to get access to
-your most critical assets. Major
+relies on "something you know", a password. Yet there is little standard
+documentation on how to generate good passwords. There are some
+interesting possibilities for doing so; this article will look at what
+makes a good password and some tools that can be used to generate them.
+
+Recently, the US [National Institute of Standards and Technology
+(NIST)](https://www.nist.gov/) made a new recommendation, the [Special
+Publication 800-63-3: Digital Authentication
+Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
+standards of password requirements and practices, but that has yet to
+propagate to the industry. The publication also covers more than just
+passwords, but also password policies like expiration and so on, that
+are beyond the scope of this article.
+
+I also recognize that we should move away from passwords where possible.
+They pose a fundamental security flaw: the reliance on humans, who can
+be coerced to reveal secret information. Furthermore, passwords are
+"replayable": if your password is revealed or stolen, anyone can
+impersonate you to get access to your most critical assets. Major
 organizations are trying to move away from single password
-authentication. Google, for example, is
-[enforcing two factor authentication for their employees](https://cloud.google.com/security/)
-and is considering abandoning
-[passwords on phones as well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
+authentication. Google, for example, is [enforcing two factor
+authentication for its employees](https://cloud.google.com/security/)
+and is considering abandoning [passwords on phones as
+well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. This article aims at
-covering basic password hygiene techniques and software. Note that in this
-text I use the word "password" instead of "PIN" or "passphrase", which
-all roughly mean the same thing: a small piece of text that users are
-expected to provide to prove their identity.
-
-What is a good password
------------------------
-
-A "good password" may mean different things to different people. I
-will assert that a good password has the following properties:
-
- * high entropy - hard to guess for machines
- * transferable - easy to communicate for humans or transfer across
-   weird protocols for computers
- * memorable - easy to remember for humans
-
-High entropy means that the password should be unprecticable to an
-attacker, for all practical purposes. It may seem obvious to some, but
-a password should be random. It should not be based on something else
-that you know, because that is likely to be guessable by an attacker,
-however "secret" you believe it is. Yes, with enough efforts, an
-attacker can figure out your birthday, the name of your first lover,
-your mother's maiden name, where you were last summer or other silly
-secrets people think they have. The only solution here is to use a
-completely random password, generated with enough randomness or
-"entropy" that brute-forcing the password will be practically
-unfeasible. Considering that off the shelf modern graphics card can
-guess millions of passwords per second, using freely available
-software like [hashcat](https://www.hashcat.net/hashcat/), the typical
-requirement of "8 characters" is not considered enough anymore. With
-proper hardware, a powerful offline rig can crack such passwords
-within about a day.
-Even though the NIST report still recommends a minimum of 8
-characters, we now more often hear recommendations of
-[12 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
-or
-[14 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
+time until we figure out a better alternative. I will start by looking
+at basic password hygiene. Note that in this text I use the word
+"password" instead of "PIN" or "passphrase", which all roughly mean the
+same thing: a small piece of text that users are expected to provide to
+prove their identity.
+
+#### What makes a good password?
+
+A "good password" may mean different things to different people. I will
+assert that a good password has the following properties:
+
+-   high entropy - hard to guess for machines
+-   transferable - easy to communicate for humans or transfer across
+    weird protocols for computers
+-   memorable - easy to remember for humans
+
+High entropy means that the password should be unpredictable to an
+attacker, for all practical purposes. It may seem obvious to some, but a
+password should be random. It should not be based on something else that
+you know, because that is likely to be guessable, no matter how "secret"
+you believe it is. Yes, with enough effort, an attacker can figure out
+your birthday, the name of your first lover, your mother's maiden name,
+where you were last summer, or other silly secrets people think they
+have.
+
+The only solution here is to use a completely random password, generated
+with enough randomness or "entropy" that brute-forcing the password will
+be practically infeasible. Considering that modern off-the-shelf
+graphics card can guess millions of passwords per second, using freely
+available software like [hashcat](https://www.hashcat.net/hashcat/), the
+typical requirement of "8 characters" is not considered enough anymore.
+With proper hardware, a powerful offline rig can crack such passwords
+within about a day. Even though the NIST report still recommends a
+minimum of 8 characters, we now more often hear recommendations of [12
+characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
+or [14
+characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
 
 A password should also be easily "transferable". Some characters like
 `&` or `!` have special meaning on the web or the shell and can wreak
 havoc when transferred. Certain software also have policies of
 *refusing* (or requiring!) some special characters exactly for that
 reason. Weird characters also make it harder for humans to communicate
-passwords across voice channels or different cultural backgrounds. In
-a more extreme example, the popular Signal software even resorted to
-[using only digits](https://whispersystems.org/blog/safety-number-updates/)
-to transfer key fingerprints. They outlined that numbers are "easy to
+passwords across voice channels or different cultural backgrounds. In a
+more extreme example, the popular Signal software even resorted to
+[using only
+digits](https://whispersystems.org/blog/safety-number-updates/) to
+transfer key fingerprints. They outlined that numbers are "easy to
 localize" (as opposed to words, which are language-specific) and
 "visually distinct".
 
-But critical part of passwords is the "memorable" part: it is trivial
-to generate a random string of characters, but as those passwords are
-hard for humans to remember. As
-[XKCD explained](https://xkcd.com/936/), "through 20 years of effort,
-we've successfully trained everyone to use passwords that are hard for
-human to remember but easy for computers to guess". The XKCD cartoon
-explains how a series of words is a better password than a single word
-with some characters replaced.
+But the critical piece is the "memorable" part: it is trivial to
+generate a random string of characters, but those passwords are hard for
+humans to remember. As [xkcd noted](https://xkcd.com/936/),
+"<span>through 20 years of effort, we've successfully trained everyone
+to use passwords that are hard for human to remember but easy for
+computers to guess</span>". It explains how a series of words is a
+better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
-may store some in password generators (which we'll cover in the next
-article) or write them down in your wallet. In those case, what you
-need is not a password, but something I would rather call a "token",
-or, as Debian Developer Daniel Kahn Gillmor (dkg) said in a private
-email, a "high entropy, compact and transferable string". Certain APIs
-are specifically crafted to use tokens. Oauth, for example, generates
-"access tokens" which are basically random strings that give access to
-services. But in our discussion, we'll use tokens in a broader sense.
+may store some in password generators (which we'll look at in another
+article) or write them down in your wallet. In those cases, what you
+need is not a password, but something I would rather call a "token", or,
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+"high entropy, compact, and transferable string". Certain APIs are
+specifically crafted to use tokens. [OAuth](https://oauth.net/), for
+example, generates "access tokens" that are basically random strings
+that give access to services. But in our discussion, we'll use tokens in
+a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
-one: we want to efficiently convert the most entropy into the
-shortest password possible, to work around possibly limiting password
-policies. For example, some bank cards only allow 5-digit security
-PINs and most websites have an upper limit in the password length. The
-"compact" property applies less to "passwords" than tokens, because I
-assume that you will use only a passwords in a select places: your
-password manager, SSH and OpenPGP keys, your computer login and
-encryption keys, period. Those tools are generally under your control
-and should allow large enough passwords that the compact property is
-not important anymore. Everything else should be in a password
-manager.
-
-Generating secure passwords

(fichier de différences tronqué)
refer to nist for hash rounds?
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 9d99f62..d5a4cb4 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -329,6 +329,9 @@ and shove everything else in a password manager".
 internal notes
 --------------
 
+link to the NIST report for hash rounds?
+https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
+
 mental hash:
 
 http://scilogs.spektrum.de/hlf/mental-cryptography-and-good-passwords/

add notes about word lists
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index c22cf18..3a1272d 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -150,7 +150,11 @@ It's also interesting to note that this is closer to the entropy of a
 15-letter base64 encoded password: since each character is 6 bits, you
 end up with 90 bits of entropy. xkcdpass is scriptable and easy to
 use. You can also customize the word list, separators and so on with
-different commandline options.
+different commandline options. By default, xkcdpass uses the
+[2 of 12](http://wordlist.aspell.net/12dicts-readme/#nof12) word list
+from [12 dicts](http://wordlist.aspell.net/12dicts/) and is not
+specifically geared towards password generation but has been curated
+for "common words" and words of different sizes.
 
 Another option is the
 [diceware system](http://diceware.com/). Diceware works by having a
@@ -176,6 +180,16 @@ computer's entropy source:
     What number shows dice number 2? 2
     What number shows dice number 3? [...]
 
+The diceware software ships with a few word lists, and the default has
+been deliberately geared towards generating passwords. It is derived
+from the standard diceware list with additions from the
+[SecureDrop project](https://securedrop.org/). It is interesting to
+note that, while diceware ships with the better crafted
+[EFF wordlist](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases),
+it is not enabled by default, even though they recommend using it when
+generating passwords with dice. This is probably because the EFF list
+was added [later on](https://github.com/ulif/diceware/issues/26).
+
 One disadvantage of diceware is that it doesn't actually tell you how
 much entropy the generated password has - you need to compute it
 yourself. The actual number depends on the word list: the default word

finish conclusion
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index db15eaf..c22cf18 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -286,9 +286,15 @@ Keepass) and transform that data into a transferable string.
 Conclusion
 ----------
 
-While there are many aspects to password management, we have reviewed
-different techniques for users and developers to generate secure but
-also usable passwords.
+While there are many aspects to password management, we have focused
+on different techniques for users and developers to generate secure
+but also usable passwords. Generating strong yet memorable password is
+not a trivial problem as the security vulnerabilities of the `pwgen`
+software showed. Furthermore, left to their own device, users will
+generate passwords that can be easily guessed by a skilled attacker,
+especially if they can profile the user. It is therefore essential we
+provide easy tools for users to generate strong passwords and
+encourage users to store secure tokens in password managers.
 
 notes
 =====
@@ -297,27 +303,6 @@ do not redistribute this text without explicit approval.
 
 this section is not for publication.
 
-need some conclusion?
-
-> somewhere early on we should probably describe what we mean by
-> 'entropy' in this context
-
-why entropy is necessary:
-
-> it occurs to me that the article hasn't motivated why high entropy is
-> necessary.  I have a couple ways that i do that for people.  One thing
-> is "if a machine can guess a trillion passwords a second, how long would
-> it take it to guess your password?"  it's a good way of making something
-> that seems abstract ("entropy") into something concrete ("a thousand
-> years", or whatever)
->
-> Another useful analogy is to use a cylinder combination lock where each
-> wheel has 6 positions.  I've actually got one of these that i use with a
-> bunch of dice to show how the combinations stack up.  It's fun to ask
-> people "if i can test one setting per second, how many seconds will it
-> take me to brute-force this lock?"  most people think you're asking
-> something rhetorical, but then you can show them how to calculate it.
-
 more article ideas from dkg:
 
 >  * kernel entropy/RNG updates (see below)

jakes review, reverse order...
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index efc2632..db15eaf 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -1,26 +1,14 @@
 How to reliably generate passwords and tokens
 =============================================
 
-This article is the first in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
-relies on "something you know", a password. Yet there is very little
+relies on "something you know", a password. Yet there is little
 standard documentation on how to generate good passwords. Recently,
 [NIST](https://www.nist.gov/) made a new recommendation, the
 [Special Publication 800-63-3: Digital Authentication Guidelines](https://pages.nist.gov/800-63-3/)
 which outlines new standards of password requirements and practices,
-but that has yet to propagate to the industry, and covers more than
+but that has yet to propagate to the industry. The publication also covers more than
 just passwords, but also password policies like expiration and so on,
 that are beyond the scope of this article.
 
@@ -39,8 +27,7 @@ although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
 time until we figure out a better alternative. This article aims at
-covering basic password hygiene techniques and software, and also
-touches on fundamentals of entropy on Linux systems. Note that in this
+covering basic password hygiene techniques and software. Note that in this
 text I use the word "password" instead of "PIN" or "passphrase", which
 all roughly mean the same thing: a small piece of text that users are
 expected to provide to prove their identity.
@@ -56,14 +43,27 @@ will assert that a good password has the following properties:
    weird protocols for computers
  * memorable - easy to remember for humans
 
-It may seem obvious to some, but a password should be random. It
-should not be based on something else that you know, because that is
-likely to be guessable by an attacker, however "secret" you believe it
-is. Yes, with enough efforts, an attacker can figure out your
-birthday, the name of your first lover, your mother's maiden name,
-where you were last summer or other silly secrets people think they
-have. The only solution here is to use a completely random password,
-generated from a reliable entropy source, which we'll get to later.
+High entropy means that the password should be unprecticable to an
+attacker, for all practical purposes. It may seem obvious to some, but
+a password should be random. It should not be based on something else
+that you know, because that is likely to be guessable by an attacker,
+however "secret" you believe it is. Yes, with enough efforts, an
+attacker can figure out your birthday, the name of your first lover,
+your mother's maiden name, where you were last summer or other silly
+secrets people think they have. The only solution here is to use a
+completely random password, generated with enough randomness or
+"entropy" that brute-forcing the password will be practically
+unfeasible. Considering that off the shelf modern graphics card can
+guess millions of passwords per second, using freely available
+software like [hashcat](https://www.hashcat.net/hashcat/), the typical
+requirement of "8 characters" is not considered enough anymore. With
+proper hardware, a powerful offline rig can crack such passwords
+within about a day.
+Even though the NIST report still recommends a minimum of 8
+characters, we now more often hear recommendations of
+[12 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
+or
+[14 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
 
 A password should also be easily "transferable". Some characters like
 `&` or `!` have special meaning on the web or the shell and can wreak
@@ -77,24 +77,24 @@ to transfer key fingerprints. They outlined that numbers are "easy to
 localize" (as opposed to words, which are language-specific) and
 "visually distinct".
 
-But critical part of passwords is the "memorable" part: it is fairly
-easy to generate a random string of characters, but as those passwords
-are hard for humans to remember. As
+But critical part of passwords is the "memorable" part: it is trivial
+to generate a random string of characters, but as those passwords are
+hard for humans to remember. As
 [XKCD explained](https://xkcd.com/936/), "through 20 years of effort,
 we've successfully trained everyone to use passwords that are hard for
-human to remember but easy for computers to guess".
-
-Some will argue that you do not need to remember all
-passwords. Indeed, you may store some in password generators (which
-we'll cover in the next article) or write
-them down in your wallet. In those case, what you need is not a
-password, but something I would rather call a "token", or, as Debian
-Developer Daniel Kahn Gillmor (dkg) said in a private email, a "high entropy,
-compact and transferable string". Certain APIs are specifically
-crafted to use tokens. Oauth, for
-example, generates "access tokens" which are basically random strings
-that give access to services. But in our discussion, we'll use tokens
-in a broader sense.
+human to remember but easy for computers to guess". The XKCD cartoon
+explains how a series of words is a better password than a single word
+with some characters replaced.
+
+Obviously, you should not need to remember all passwords. Indeed, you
+may store some in password generators (which we'll cover in the next
+article) or write them down in your wallet. In those case, what you
+need is not a password, but something I would rather call a "token",
+or, as Debian Developer Daniel Kahn Gillmor (dkg) said in a private
+email, a "high entropy, compact and transferable string". Certain APIs
+are specifically crafted to use tokens. Oauth, for example, generates
+"access tokens" which are basically random strings that give access to
+services. But in our discussion, we'll use tokens in a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
 one: we want to efficiently convert the most entropy into the
@@ -109,68 +109,23 @@ and should allow large enough passwords that the compact property is
 not important anymore. Everything else should be in a password
 manager.
 
-How to generate a good password
--------------------------------
+Generating secure passwords
+---------------------------
 
-Most password managers feature a way to generate strong security
-tokens, with different policies (symbols or not, length, etc). In
-general, you should use your password manager's password generation
-functionality to generate tokens for sites you visit. But how are
-those functionalities implemented?
+We'll start by covering how to generate a strong, transferable and
+memorable password. This is most likely the passwords you will deal
+with most of the time, as security tokens should actually never show
+up on screen: they should be copy-pasted or automatically typed in
+forms. The password generators described here are all operated from
+the commandline. It's also interesting to note that password
+managers often have embedded password generators, but usually don't
+provide an easy way to generate a password for the vault itself.
 
-`pass`, the
-[standard UNIX password manager](https://www.passwordstore.org/),
-delegates this task to the widely known
-[pwgen](https://packages.debian.org/sid/pwgen) program. It turns out
-that `pwgen` has a pretty bad track record for security issues,
-especially in the default "phoneme" mode, that generates non-uniformly
-distributed passwords. While `pass` uses the more "secure" `-s` mode,
-I figured it was worth removing that dependency to discourage the use
-of `pwgen` in the default mode. I made a trivial patch to pass so that
-it generates passwords correctly on its own. The gory details are in
-[this email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.html). It
-turns out that there are lots of ways to skin this particular cat. I
-was suggesting we the following pipeline to generate the password:
-
-    head -c $entropy /dev/random | base64 | tr -d '\n='
-
-This is what dkg described as a "high-entropy compact printable/transferable string", as opposed to a "password"
-generator. The priority, in this specific case, is to have
-a security token that is as compact as possible with the given entropy, while
-at the same time use a character set that should not cause as little
-trouble as possible on sites that restrict the characters you can
-use. dkg is a co-maintainer of the
-[assword](https://finestructure.net/assword/) password manager, which
-chose base64 because it is widely available and understood,
-and only takes up 33% more space than the original 8-bit binary encoding. After an interesting
-discussion, the pass maintainer, Jason A. Donenfeld, chose the following pipeline:
-
-    CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
-    CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
-    [...]
-	read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
-
-A participant on the mailing list, Brian Candler, has
-[argued](https://lists.zx2c4.com/pipermail/password-store/2016-November/002472.html)
-that this wastes entropy and that the use of `tr` discards valuable
-entropy with
-[little gain in entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
-when compared to base64. But in the end, those concerns were
-dismissed by the maintainer.
-
-Another password manager, [KeePass](http://keepass.info/) uses its own
-routines to generate tokens, but the procedure is the same: read from
-the kernel's entropy source (and user-generated sources in case of
-Keepass) and transform that data into a transferable string.
-
-So that's for generating security tokens. But how do you
-chose the password for your password manager or for passwords you need
-to remember? This is where other password generators come in. The
-famous [#936 cartoon from XKCD](https://xkcd.com/936/) is probably a
-common cultural reference, and I often show it to people to explain
-how to choose a good passphrase. It turns out someone actually
-implemented Randall's suggestion into a program called
-[xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
+The previously mentioned #936 cartoon from XKCD is probably a common
+cultural reference in the security crowd, and I often use it to
+explain how to choose a good passphrase in training. It turns out
+someone actually implemented Randall's suggestion into a program

(fichier de différences tronqué)
finish review with dkg
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 0f683e5..efc2632 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -17,7 +17,7 @@ Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
 relies on "something you know", a password. Yet there is very little
 standard documentation on how to generate good passwords. Recently,
-[NIST](http://www.nist.gov/) made a new recommendation, the
+[NIST](https://www.nist.gov/) made a new recommendation, the
 [Special Publication 800-63-3: Digital Authentication Guidelines](https://pages.nist.gov/800-63-3/)
 which outlines new standards of password requirements and practices,
 but that has yet to propagate to the industry, and covers more than
@@ -26,7 +26,10 @@ that are beyond the scope of this article.
 
 I also recognize that we should move away from passwords where
 possible. They pose a fundamental security flaw: the reliance on
-humans, which can be coerced to reveal secret information. Major
+humans, which can be coerced to reveal secret
+information. Furthermore, passwords are "replayable": if your password
+is revealed or stolen, anyone can impersonate you to get access to
+your most critical assets. Major
 organizations are trying to move away from single password
 authentication. Google, for example, is
 [enforcing two factor authentication for their employees](https://cloud.google.com/security/)
@@ -37,7 +40,10 @@ although we have yet to see that controversial change implemented.
 Yet passwords are still here and are likely to stick around for a long
 time until we figure out a better alternative. This article aims at
 covering basic password hygiene techniques and software, and also
-touches on fundamentals of entropy on Linux systems.
+touches on fundamentals of entropy on Linux systems. Note that in this
+text I use the word "password" instead of "PIN" or "passphrase", which
+all roughly mean the same thing: a small piece of text that users are
+expected to provide to prove their identity.
 
 What is a good password
 -----------------------
@@ -60,34 +66,16 @@ have. The only solution here is to use a completely random password,
 generated from a reliable entropy source, which we'll get to later.
 
 A password should also be easily "transferable". Some characters like
-`&` or `!` have special meaning on the web or the shell and can wreck
+`&` or `!` have special meaning on the web or the shell and can wreak
 havoc when transferred. Certain software also have policies of
-*refusing* some special characters exactly for that reason. Weird
-characters also make it harder for humans to communicate passwords
-across voice channels or different cultural backgrounds. In a more
-extreme example, the popular Signal software even resorted to
+*refusing* (or requiring!) some special characters exactly for that
+reason. Weird characters also make it harder for humans to communicate
+passwords across voice channels or different cultural backgrounds. In
+a more extreme example, the popular Signal software even resorted to
 [using only digits](https://whispersystems.org/blog/safety-number-updates/)
-to transfer key fingerprints. They outlined 3 key properties of
-numbers for this purpose:
-
-> 1. Numbers are easy to localize. Using a wordlist from a single
->    language wouldn't be very accessible, trying to localize
->    wordlists to make cross-language comparisons possible is very
->    error prone, and encodings like hex, base32, or base64 are not
->    compatible with all alphabets. However, all supported languages
->    have a representation for base 10 digits that safety numbers can
->    easily be localized into.
->
-> 2. Numbers are visually and audibly distinct. Numeric
->    representations in all languages have a lot of evolution behind
->    them, and have been pushed towards visual and audible
->    distinguishability. Numeric encodings work well for both speed
->    and accuracy.
->
-> 3. Size. We worked to reduce the size of the encoded value to make
->    the comparison even easier. With the new encoding, users compare
->    12 groups of 5 digits with each other, which is half the size of
->    what needed to be compared with the previous hexadecimal format.
+to transfer key fingerprints. They outlined that numbers are "easy to
+localize" (as opposed to words, which are language-specific) and
+"visually distinct".
 
 But critical part of passwords is the "memorable" part: it is fairly
 easy to generate a random string of characters, but as those passwords
@@ -97,14 +85,19 @@ we've successfully trained everyone to use passwords that are hard for
 human to remember but easy for computers to guess".
 
 Some will argue that you do not need to remember all
-passwords. Indeed, you may store some in password generators or write
+passwords. Indeed, you may store some in password generators (which
+we'll cover in the next article) or write
 them down in your wallet. In those case, what you need is not a
-password, but something I would rather call a "token", or, as my
-friend Daniel Kahn Gillmor said in a private email, a "high entropy,
-compact and transferable string".
+password, but something I would rather call a "token", or, as Debian
+Developer Daniel Kahn Gillmor (dkg) said in a private email, a "high entropy,
+compact and transferable string". Certain APIs are specifically
+crafted to use tokens. Oauth, for
+example, generates "access tokens" which are basically random strings
+that give access to services. But in our discussion, we'll use tokens
+in a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
-one: we want to efficiently convert a high source of entropy into the
+one: we want to efficiently convert the most entropy into the
 shortest password possible, to work around possibly limiting password
 policies. For example, some bank cards only allow 5-digit security
 PINs and most websites have an upper limit in the password length. The
@@ -123,7 +116,7 @@ Most password managers feature a way to generate strong security
 tokens, with different policies (symbols or not, length, etc). In
 general, you should use your password manager's password generation
 functionality to generate tokens for sites you visit. But how are
-those functionality implemented?
+those functionalities implemented?
 
 `pass`, the
 [standard UNIX password manager](https://www.passwordstore.org/),
@@ -141,15 +134,15 @@ was suggesting we the following pipeline to generate the password:
 
     head -c $entropy /dev/random | base64 | tr -d '\n='
 
-This is what Gillmor described as a "high-entropy compact printable/transferable string", as opposed to a "password"
+This is what dkg described as a "high-entropy compact printable/transferable string", as opposed to a "password"
 generator. The priority, in this specific case, is to have
 a security token that is as compact as possible with the given entropy, while
 at the same time use a character set that should not cause as little
 trouble as possible on sites that restrict the characters you can
-use. Gillmor is a co-maintainer of the
-[assword](https://finestructure.net/assword/) password managers, which
+use. dkg is a co-maintainer of the
+[assword](https://finestructure.net/assword/) password manager, which
 chose base64 because it is widely available and understood,
-and incurs only a small space penalty (+33%). After an interesting
+and only takes up 33% more space than the original 8-bit binary encoding. After an interesting
 discussion, the pass maintainer, Jason A. Donenfeld, chose the following pipeline:
 
     CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
@@ -296,3 +289,29 @@ hopes that one or more of them can not be predicted by the attacker.
 already at 2200 words?
 
 re entropy: http://blog.cr.yp.to/20140205-entropy.html
+
+why entropy is necessary:
+
+> it occurs to me that the article hasn't motivated why high entropy is
+> necessary.  I have a couple ways that i do that for people.  One thing
+> is "if a machine can guess a trillion passwords a second, how long would
+> it take it to guess your password?"  it's a good way of making something
+> that seems abstract ("entropy") into something concrete ("a thousand
+> years", or whatever)
+>
+> Another useful analogy is to use a cylinder combination lock where each
+> wheel has 6 positions.  I've actually got one of these that i use with a
+> bunch of dice to show how the combinations stack up.  It's fun to ask
+> people "if i can test one setting per second, how many seconds will it
+> take me to brute-force this lock?"  most people think you're asking
+> something rhetorical, but then you can show them how to calculate it.
+
+more article ideas from dkg:
+
+>  * kernel entropy/RNG updates
+>
+>  * password policies for websites and other network services -- how not
+>    to be a terrible administrator
+>
+>  * legal/coercion risks for local machinery, and the tradeoffs if
+>    passwords aren't in use.

add a bunch of todos
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 8228e51..9d99f62 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -344,9 +344,22 @@ lesspass re HN!?
 re lastpass, 1password - proprietary server side, 2fa failure,
 mac-only... 
 
+need to review litterature about HMAC:
+
+https://benlog.com/2008/06/19/dont-hash-secrets/
+
+remember this? https://anarc.at/blog/2010-01-29-do-hash-secrets-also-use-hmac/
+
+need to review the master password arguments here:
+
+http://masterpasswordapp.com/security.html#strength
+
+still need to do a last review of the HN! discussion:
 
 https://news.ycombinator.com/item?id=12889807
 
+extracted notes, from https://news.ycombinator.com/item?id=12890997:
+
 1. A password is now ciphertext, not a block of line noise. Every time you transmit it, you are giving away potential clues of use to an attacker.
 
 2. The search space for possible passwords is bounded if you know the website. You are subject to key guessing attacks. If your key is short, pure serial guessing will break it fast.
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index fafc4ee..0f683e5 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -294,3 +294,5 @@ hopes that one or more of them can not be predicted by the attacker.
 
 ... but maybe that should be in a separate article, given that we're
 already at 2200 words?
+
+re entropy: http://blog.cr.yp.to/20140205-entropy.html

finish first draft for hashers
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index a8d7188..8228e51 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -14,7 +14,15 @@ In previous articles, we have seen how to generate passwords and
 security tokens, and a short review of the password managers available
 on Linux platforms. There is, however, a third way of managing
 passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing".
+and that is what I call "password hashing". You may know those as
+"deterministic or stateless password managers" but I find the
+"password manager" denomination to be confusing because it doesn't
+actually store any password.
+
+In this text, I use the word "password" for a random string used to
+unlock things, but "token" to represent a generated random string that
+the user doesn't need to remember. The input of a password hasher is
+a password and the output of a password hasher is a token.
 
 What is a password hasher?
 --------------------------
@@ -32,7 +40,11 @@ The biggest advantage of password hashers is obviously that you only
 need to remember a password. But contrary to password managers, you do
 not need to carry a password vault around: there's no "state" (other
 than site-specific settings, which can be easily guessed) to carry
-around.
+around. The whole concept of password hashers relies on the concept of
+one-way,
+[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
+that take an input and generate an a unique fixed size string, from
+which it is impossible to guess the original input.
 
 Password hashers are generally written as a Javascript bookmarklet or
 browser plugin, and have been around for over a decade although people
@@ -58,15 +70,23 @@ University Applied Cryptography's
 implementation was
 [published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
 and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses HMAC to generate
-tokens. Those implementations are the simplest essence of password
-hashers: the inputs are simply the site URL and a password.
+MD5 as an hashing algorithm, but at least it uses
+[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
+to generate tokens. Those implementations are the simplest essence of
+password hashers: the inputs are simply the site URL and a
+password. So the algorithms are, basically, for Wolff's:
+
+    token = base64(SHA1(password + domain))
+
+And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
+
+    token = base64(HMAC(MD5, password, domain))) # PwdHash
 
 Another unrelated implementation that is still around is
 [supergenpass](https://chriszarate.github.io/supergenpass/) is a
 bookmarklet that was
 [created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-originally using MD5 as well but now supports SHA256 now although
+originally using MD5 as well but now supports SHA512 now although
 still
 [limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
 and still
@@ -81,12 +101,15 @@ available for the browser (as a
 (as an
 [webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
 allows you to modify the password length, but also add an extra
-"secret password" to generate a personalized
+profile password which adds to the secret and generates a personalized
 [identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing although it seems unclear what the secret actually
-does other than change a small picture in the user interface.
+prevent phishing but it also introduces an interesting protection,
+only found later in Password Hasher Plus. So the
+[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
+
+    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
 
-Anthoer popular implementation is the Wiijo password hasher,
+Anothor popular implementation is the Wiijo password hasher,
 [created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
 It was probably the first shipped as a
 [browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
@@ -101,38 +124,220 @@ reference. It also happens that the Wiijo password hasher, in turn,
 took its inspiration on *different* project,
 [hashapass.com](http://www.hashapass.com/),
 [created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on HMAC-SHA-1.
+and also based on
+HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
+"can easily be generated on almost any modern Unix-like system using
+the following command line pattern":
+
+    echo -n parameter \
+    | openssl dgst -sha1 -binary -hmac password \
+    | openssl enc -base64 \
+    | cut -c 1-8
+
+So the
+[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
+here is obviously:
+
+    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
+
+... although in the case of Password Hasher, there is a special
+routine that takes the token and inserts random characters in locations
+determined by the sum of the values of the characters in the token.
 
 Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
 to Chrome and called it
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en). Woodruff
-also added interesting features of a profile-specific secret key that
-gets mixed in to create the security token. stealing the master
-password is therefore not enough to generate tokens anymore. Like the
-original password hasher, the "plus" version also keeps those settings
-in the extension and uses HMAC-SHA-1 to generate the password, as it
-is designed to be backwards-compatible with the Wiijo password hasher.
+[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
+Like the original password hasher, the "plus" version also keeps those
+settings in the extension and uses HMAC-SHA-1 to generate the
+password, as it is designed to be backwards-compatible with the Wiijo
+password hasher. Woodruff did add an one interesting feature: a
+profile-specific secret key that gets mixed in to create the security
+token. Stealing the master password is therefore not enough to
+generate tokens anymore. This solves one security concern with
+Password Hasher: an hostile page could watch your keystrokes and steal
+your master password and use it to derive passwords on other
+sites. Having a profile-specific secret key, not accessible to the
+site's Javascript works around that issue, but one could argue that
+typing the master password directly in the password file, while
+convenient, is probably just a bad idea in retrospect. The final
+algorithm looks something like:
+
+    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
+
+Honestly, that seems rather strange, but it's what I read from the
+source code, which is available only after decompressing the extension
+nowadays. I would have expected the simplest version:
+
+    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
+
+Password Hasher Plus then takes the token and applies the same
+special character insertion routine as the Password Hasher.
+
+Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
+self-described "humanist and scuba diving fan" released the
+[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
+Android. Lesspass introduces numerous interesting functionalities. It
+is probably the first to include a
+[commandline version](https://github.com/lesspass/cli). It also
+[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
+more robust key derivation algorithm
+([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
+account the username on the site, allowing multi account support. The
+original release (version 1) used only 8192 rounds which is now
+considered too low. In the
+[bug report](https://github.com/lesspass/lesspass/issues/38) it was
+interesting to note that LessPass couldn't do the usual practice of
+running the key derivation for 1 second to determine the number of
+rounds needed as the results need to be deterministic. At first
+glance, the LessPass source code seems
+[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
+at first glance which is always a good sign, but of course, the devil
+is in the details. One key feature it is missing from Password Hasher
+Plus is the profile-specific seed, although one could argue it should
+be more difficult, if not impossible, for a webpage Javascript script
+to steal keystrokes from a browser extension.
+
+The [algorithm][] then gets a little more interesting:
+
+    entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
+    where rounds = 10000 and length = 32
+
+[algorithm]: https://github.com/lesspass/core/blob/24c339e/src/v2.js#L15
+
+(Confused by the pbkdg2 implementation here:
+https://github.com/lesspass/core/blob/master/src/pbkdf2.js - ImportKey
+doesn't support PBKDF2?? it's just something to extract key material?
+and then later, why AES-CTR??)
+
+There is also a
+[lesspass-specific character picking routing](https://github.com/lesspass/core/blob/24c339e/src/v2.js#L78)
+(ie. not base64, and different from the original Password Hasher
+algorithm).
+
+A review of password hashers would hardly be complete without
+mentioning the [Master Password](http://masterpasswordapp.com/),
+probably the
+[definite algorithm](http://masterpasswordapp.com/algorithm.html) for
+password hashers. While the applications surrounding the project are
+not as refined (there is no web browser plugin and the
+[web interface](https://js.masterpasswordapp.com/) can't be easily
+turned into a bookmarklet), the algorithm has been well developed. In all the
+password managers reviewed here, Master Password uses one of the
+strongest key derivation algorithms out there,
+[scrypt](https://en.wikipedia.org/wiki/Scrypt):
+
+    key = scrypt( password, salt, cost, size, parallelization, length )
+    where
+    salt = "com.lyndir.masterpassword" + len(username) + name
+    cost = 32768

(fichier de différences tronqué)
add issue with 2.1.18
diff --git a/blog/2015-12-14-yubikey-howto.mdwn b/blog/2015-12-14-yubikey-howto.mdwn
index 21f8510..a33c8f6 100644
--- a/blog/2015-12-14-yubikey-howto.mdwn
+++ b/blog/2015-12-14-yubikey-howto.mdwn
@@ -425,4 +425,18 @@ can quickly be exhausted (and with good reason).
 To reset the counters, you should simply rerun the configuration
 procedure and replace the `users.oath` line with a new one.
 
+scdaemon problems in 2.1.18
+---------------------------
+
+[[!debbug 854005]] came up when 2.1.18 was released. It seems there's
+a problem with the new multi-device support in GnuPG 2.1.18 that makes
+it impossible to read the card at all. The symptom is this:
+
+    [991]anarcat@curie:~2$ LANG=C gpg --card-status
+    gpg: selecting openpgp failed: No such device
+    gpg: OpenPGP card not available: No such device
+
+The workaround documented there is to add `disable-ccid` to
+`~/.gnupg/scdaemon.conf`.
+
 [[!tag debian-planet geek software debian hacking security crypto]]

clarify theme and software licenses are distinct from content
it seems there was some confusion about the theme being under the same
license as the content, as intrigeri gave this attribution:
> Theme based on anarcat's Bootstrap theme, that is Copyleft ©
> 2002-2016 The Anarcat CC-BY-SA. Valid (X)HTML 5.
that is actually the content attribution, not the theme, which is
MIT. also mention the ikiwiki software and point to those attributions
and mention very quickly my other software.
diff --git a/meta/license.mdwn b/meta/license.mdwn
index 4e38797..ab7e1e9 100644
--- a/meta/license.mdwn
+++ b/meta/license.mdwn
@@ -1,18 +1,51 @@
 [[!meta title="Licensing"]]
 
+[[!toc levels=2 startlevel=2]]
+
+Software
+--------
+
+This site was generated with [ikwiki](https://ikiwiki.info/), which is
+generally © 2006-2011 Joey Hess, under the GPL-2+ license. See the
+[complete copyright file](http://sources.debian.net/src/ikiwiki/sid/debian/copyright/)
+for more information.
+
+Other software I produce is under an unrelated license, usually
+[GPL](https://en.wikipedia.org/wiki/GNU_General_Public_License) or
+[AGPL](https://en.wikipedia.org/wiki/Affero_General_Public_License)
+license, but each project usually has a specific license attached to
+it that supersedes this notice.
+
+Design
+------
+
+The design of this site falls under a different license, see the
+[source code](http://src.anarc.at/ikiwiki_bootstrap_anarcat.git/) for
+the ultimate reference. Right now, it is a
+[modified bootstrap theme](https://anarc.at/blog/2015-09-09-bootstrap/)
+licensed under a MIT license and, like all bootstrap derived themes,
+is "© 2011-2015 Twitter, Inc", but also © 2009-2015 Julian Andres
+Klode for the Ikiwiki adaptation and © 2016-2017 Antoine Beaupré for
+my modifications.
+
+Content
+-------
+
+The *content* of this site is released under a Creative Commons
+license, as such.
+
 <!-- copy-paste from https://creativecommons.org/choose/ -->
 
 <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
 
-[[!toc levels=2 startlevel=2]]
-
 Rationale
 ---------
 
-I use the Creative Commons license because it is simple, well-known,
-and easy to use. It also does the basics I expect from a free license
-in that it allows attribution and forces users to also apply similar
-terms to the license, or, to put it another way, it is "viral".
+For content, I use the Creative Commons license because it is simple,
+well-known, and easy to use. It also does the basics I expect from a
+free license in that it allows attribution and forces users to also
+apply similar terms to the license, or, to put it another way, it is
+"viral".
 
 I used to operate under the [GFDL][], but I disliked the
 incompatibility with the [[!wikipedia GPL]] and the lack of clarity of
@@ -67,9 +100,11 @@ Updates
 -------
 
  * pre-2012: no explicit license other than "Copyleft"
- * 2012-12-15: licensed under the [GFDL][] 1.2 license
- * 2013-09-13: license changed to [CC-BY-SA Unported 3.0][]
- * 2016-11-15: license changed to [CC-BY-SA International 4.0][]
+ * 2012-12-15: relicensed to the [GFDL][] 1.2 license
+ * 2013-09-13: relicensed to the [CC-BY-SA Unported 3.0][]
+ * 2016-11-15: relicensed to the [CC-BY-SA International 4.0][]
+ * 2017-02-02: clarify the theme and software licenses are distinct
+   from content
 
 [september]: http://web.archive.org/web/20130922114804/http://anarcat.koumbit.org/
 [CC-BY-SA Unported 3.0]: https://creativecommons.org/licenses/by-sa/3.0/

more work on hashers
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 111e12c..a8d7188 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -16,53 +16,121 @@ on Linux platforms. There is, however, a third way of managing
 passwords other than remembering them or encrypting them in a "vault",
 and that is what I call "password hashing".
 
+What is a password hasher?
+--------------------------
+
+A password hasher is a piece of software that turns a single master
+password into multiple passwords by hashing the master password and a
+unique token (generally the hostname) to create a site-specific
+password. To change the password, the user can modify the unique
+token, for example by appending a number. Certain password managers
+also have different settings to generate passwords of different
+lengths or compositions (symbols or not, etc) to accomodate different
+site-specific password policies.
+
+The biggest advantage of password hashers is obviously that you only
+need to remember a password. But contrary to password managers, you do
+not need to carry a password vault around: there's no "state" (other
+than site-specific settings, which can be easily guessed) to carry
+around.
+
+Password hashers are generally written as a Javascript bookmarklet or
+browser plugin, and have been around for over a decade although people
+are generally aware of their existence.
+
 A short history of password hashers
 -----------------------------------
 
-You may be surprised to learn that password hashing is actually a
-fairly old concept.
-
-So out with that one. I needed to find an alternative, here's what I
-have found:
-
- * [Nic Wolff](http://angel.net/~nic/passwd.current.html) 
-   [claims](https://news.ycombinator.com/item?id=12892655) to be the
-   first to have written such a program, all the
-   [way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-   then the algorithm was based on MD5, although Wolff has now updated
-   the algorithm to use SHA-1.
- * Standford's [pwdhash](https://crypto.stanford.edu/PwdHash) is also
-   old, having been
-   [published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/). Unfortunately,
-   that implementation was *not* updated and *still* uses MD5.
- * [supergenpass](https://github.com/chriszarate/supergenpass) is a
-   bookmarklet that was
-   [created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-   originally using MD5 as well but now supports SHA256 now although
-   still
-   [limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-   and still
-   [defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-   with
-   [not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-   (10). Note that Chris Zarate, the supergenpass author, actually
-   credits Nic Wolff as the inspiration for his implementation.
-
-
- * [Alzheimer password generator](https://github.com/viralpoetry/password-generator) -
+Since the concept is actually so old, it may be useful to go over a
+short history of popular or notable password hashers, before we go
+into the specific issues related to the implementation of a password
+hasher.
+
+[Nic Wolff](http://angel.net/~nic/passwd.current.html)
+[claims](https://news.ycombinator.com/item?id=12892655) to be the
+first to have written such a program, all the
+[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
+then the hashing algorithm was MD5, although Wolff has now updated the
+algorithm to use SHA-1 and still maintains his webpage for public
+use. Another ancient but unrelated implementation, is the Standford
+University Applied Cryptography's
+[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
+implementation was
+[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
+and unfortunately, that implementation was not updated and still uses
+MD5 as an hashing algorithm, but at least it uses HMAC to generate
+tokens. Those implementations are the simplest essence of password
+hashers: the inputs are simply the site URL and a password.
+
+Another unrelated implementation that is still around is
+[supergenpass](https://chriszarate.github.io/supergenpass/) is a
+bookmarklet that was
+[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
+originally using MD5 as well but now supports SHA256 now although
+still
+[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
+and still
+[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
+with
+[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
+(10). Note that Chris Zarate, the supergenpass author, actually
+credits Nic Wolff as the inspiration for his
+implementation. Supergenpass is still in active development and is
+available for the browser (as a
+[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
+(as an
+[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
+allows you to modify the password length, but also add an extra
+"secret password" to generate a personalized
+[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
+prevent phishing although it seems unclear what the secret actually
+does other than change a small picture in the user interface.
+
+Anthoer popular implementation is the Wiijo password hasher,
+[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
+It was probably the first shipped as a
+[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
+which greatly improved the security of the product as users didn't
+have to continually download the software on the fly. Wiijo's
+algorithm also improved on the above algorithms, as it uses HMAC-SHA1
+instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
+the plaintext. Password hasher allows you to set different password
+policies (use digits, punctuation, mixed case, special characters and
+password length) and saves the site names it uses for future
+reference. It also happens that the Wiijo password hasher, in turn,
+took its inspiration on *different* project,
+[hashapass.com](http://www.hashapass.com/),
+[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
+and also based on HMAC-SHA-1.
+
+Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
+to Chrome and called it
+[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en). Woodruff
+also added interesting features of a profile-specific secret key that
+gets mixed in to create the security token. stealing the master
+password is therefore not enough to generate tokens anymore. Like the
+original password hasher, the "plus" version also keeps those settings
+in the extension and uses HMAC-SHA-1 to generate the password, as it
+is designed to be backwards-compatible with the Wiijo password hasher.
+
+Last year, the [lesspass](https://lesspass.com/) extension was
+published  - interesting, but needs a server,
+see also
+[this discussion](https://news.ycombinator.com/item?id=12889807). v1
+has weak key derivation, and v2's key derivation exhausted my patience
+(takes more than 30 seconds to generate a password)
+
+https://github.com/myfreeweb/freepass
+http://masterpasswordapp.com/security.html#strength
+
+
+
+* [Alzheimer password generator](https://github.com/viralpoetry/password-generator) -
    similar, has a seed, but less usable
  * [getvau.lt](https://getvau.lt) - also only a web page, but crypto looks sound
- * [lesspass](https://lesspass.com/) - interesting, but needs a
-   server, see also
-   [this discussion](https://news.ycombinator.com/item?id=12889807). v1
-   has weak key derivation, and v2's key derivation exhausted my
-   patience (takes more than 30 seconds to generate a password)
  * [hash0](https://github.com/dannysu/hash0) - another one
  * [bpassword](https://www.alexhornung.com/code/bpasswd/) - uses bcrypt
 
-https://github.com/myfreeweb/freepass
-http://masterpasswordapp.com/security.html#strength
-
 The case against password hashers
 ---------------------------------
 

add olimex
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 75dec58..c847bf5 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -26,6 +26,24 @@ Extras:
 Modèles
 =======
 
+Olimex
+------
+
+They make a cheap DIY laptop called the
+[teres](https://www.olimex.com/Products/DIY%20Laptop/KITS/TERES-A64-BLACK/open-source-hardware),
+based on the allwinner chipset.
+
+ * 225EUR
+ * Quad Core Allwinner A64 64-bit Cortex-A53 processor
+ * LCD 11.6" 1366x768 pixels1GB DDR3L memory
+ * 4GB eMMC Flash
+ * WiFi 150Mb, BLE 4.0
+ * Camera
+ * Battery 7000mAh
+ * Weight 980 gr
+
+Backordered, of course (2017-02-02). See also the [announcement](https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source-hardware-and-software-hackers-friendly-laptop-is-complete/).
+
 x201
 ----
 

more work on the password series articles, first draft sent to lwn
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 1934637..111e12c 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,11 +1,70 @@
-[still a pre-draft, needs a full review before being submitted]
+This article is the second in the series of three about passwords.
 
-The case against "password hashers"
+ 1. The first article covers passwords, how to generate them and a
+    discussion about entropy.
+ 
+ 2. The second article covers password managers and evaluates a few
+    common software alternatives and practices.
+
+ 3. The third article covers password "hashers", that generate
+    multiple passwords from a single one, and that had become more
+    popular in recent years, while being somewhat controversial.
+
+In previous articles, we have seen how to generate passwords and
+security tokens, and a short review of the password managers available
+on Linux platforms. There is, however, a third way of managing
+passwords other than remembering them or encrypting them in a "vault",
+and that is what I call "password hashing".
+
+A short history of password hashers
 -----------------------------------
 
-[note: the remaining here is still only a bunch of notes and not even a draft yet.]
+You may be surprised to learn that password hashing is actually a
+fairly old concept.
+
+So out with that one. I needed to find an alternative, here's what I
+have found:
+
+ * [Nic Wolff](http://angel.net/~nic/passwd.current.html) 
+   [claims](https://news.ycombinator.com/item?id=12892655) to be the
+   first to have written such a program, all the
+   [way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
+   then the algorithm was based on MD5, although Wolff has now updated
+   the algorithm to use SHA-1.
+ * Standford's [pwdhash](https://crypto.stanford.edu/PwdHash) is also
+   old, having been
+   [published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/). Unfortunately,
+   that implementation was *not* updated and *still* uses MD5.
+ * [supergenpass](https://github.com/chriszarate/supergenpass) is a
+   bookmarklet that was
+   [created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
+   originally using MD5 as well but now supports SHA256 now although
+   still
+   [limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
+   and still
+   [defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
+   with
+   [not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
+   (10). Note that Chris Zarate, the supergenpass author, actually
+   credits Nic Wolff as the inspiration for his implementation.
+
+
+ * [Alzheimer password generator](https://github.com/viralpoetry/password-generator) -
+   similar, has a seed, but less usable
+ * [getvau.lt](https://getvau.lt) - also only a web page, but crypto looks sound
+ * [lesspass](https://lesspass.com/) - interesting, but needs a
+   server, see also
+   [this discussion](https://news.ycombinator.com/item?id=12889807). v1
+   has weak key derivation, and v2's key derivation exhausted my
+   patience (takes more than 30 seconds to generate a password)
+ * [hash0](https://github.com/dannysu/hash0) - another one
+ * [bpassword](https://www.alexhornung.com/code/bpasswd/) - uses bcrypt
 
+https://github.com/myfreeweb/freepass
+http://masterpasswordapp.com/security.html#strength
 
+The case against password hashers
+---------------------------------
 
 lesspass re HN!?
 
@@ -66,36 +125,6 @@ was suggesting ([password-hasher-plus][]) has a bunch of problems:
 
 [not considered cryptograhically secure]: http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure
 
-So out with that one. I needed to find an alternative, here's what I
-have found:
-
- * [nic wolff's](http://angel.net/~nic/passwd.current.html) - probably
-   the first implementation of this (see
-   [this claim](https://news.ycombinator.com/item?id=12892655))
- * [supergenpass](https://github.com/chriszarate/supergenpass) -
-   bookmarklet, one of the earliest ones, MD5, but also supports
-   SHA256 now although still
-   [limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-   and still [defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-   with
-   [not enough rounds](https://github.com/chriszarate/supergenpass/issues/82) (10)
- * [pwdhash](https://crypto.stanford.edu/PwdHash) - standford's
-   pwdhash - like the original password hasher, more or less. doesn't
-   have settings or private key, so trivial to derive master key from
-   password
- * [Alzheimer password generator](https://github.com/viralpoetry/password-generator) -
-   similar, has a seed, but less usable
- * [getvau.lt](https://getvau.lt) - also only a web page, but crypto looks sound
- * [lesspass](https://lesspass.com/) - interesting, but needs a
-   server, see also
-   [this discussion](https://news.ycombinator.com/item?id=12889807). v1
-   has weak key derivation, and v2's key derivation exhausted my
-   patience (takes more than 30 seconds to generate a password)
- * [lastpass](https://www.lastpass.com/) - proprietary server-side
- * [hash0](https://github.com/dannysu/hash0) - another one
- * [bpassword](https://www.alexhornung.com/code/bpasswd/) - uses bcrypt
-https://github.com/myfreeweb/freepass
-http://masterpasswordapp.com/security.html#strength
 
 It looks like they all suck in new exotic ways. So I have decided
 password hashing is not to be used anymore and that I needed to store
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 4741e92..7807226 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,10 +1,20 @@
-[still a pre-draft, needs a full review before being submitted]
+This article is the second in the series of three about passwords.
+
+ 1. The first article covers passwords, how to generate them and a
+    discussion about entropy.
+ 
+ 2. The second article covers password managers and evaluates a few
+    common software alternatives and practices.
+
+ 3. The third article covers password "hashers", that generate
+    multiple passwords from a single one, and that had become more
+    popular in recent years, while being somewhat controversial.
 
 Password managers and hashers: a review
 ---------------------------------------
 
 While our dependency on password for authentication has often been
-decried as a serious security flaw that needs to be removed, the
+decried as a serious security flaw that we should get rid of, the
 current reality is that we have to use a plethora of passwords in our
 daily lives on the internet. This problem is especially acute for
 technology professionals and in particular sysadmins. But it also
@@ -21,11 +31,10 @@ stick it on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
 This is generally where security professionals teach users about
-password managers. I used to recommend people use three strategies for
+password managers. I often recommend people use three different strategies for
 passwords:
 
  1. use a password hasher
-    (e.g. [password-hasher-plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd))
     in the browser, or use the "master key feature" of Firefox to
     store passwords for most (unimportant) websites
  2. use a password manager for more critical passwords (online bank
@@ -42,9 +51,8 @@ my recommendation to:
  1. remember a handful of strong passwords
  2. use a password manager for the rest
 
-In this article, I explain how to choose a password, give an overview
-of password managers available in Linux distributions. I also go over
-why password hashers are not considered a good security practice.
+This begs the question of which password manager one should be using?
+Let's look at a few alternatives.
 
 Pass: the standard password manager?
 ------------------------------------
@@ -69,8 +77,8 @@ commandline interface is simple to use and intuitive. The following,
 will, for example, create a pass repository, a 20 character password
 for your LWN account and copy it to the clipboard:
 
-   pass init
-   pass generate -c lwn 20
+    pass init
+    pass generate -c lwn 20
 
 The main concern with `pass` is that it doesn't encrypt the *name* of
 those entries: if someone would compromise my machine, they could
@@ -126,22 +134,49 @@ entries are even still in the git history... So access revocation, in
 shared password managers, actually means going through every password
 and changing it online.
 
+I should finally note that the KeePassX project has recently been
+forked into another project now called
+[KeePassXC](https://keepassxc.org/) which implement a set of new
+features present in KeePass like:
+
+* autotype on Linux, Mac OS and Windows
+* database merging - which allows multi-user support
+* favicon support
+
+So far the maintainers of KeePassXC are open to
+[re-merging the project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
+"if the original maintainer of KeePassX in the future will be more
+active and will accept our merge and changes". I could confirm that
+the original [KeePassX project](https://github.com/keepassx/keepassx)
+now has 79 pending pull requests and only one pull request was merged
+since the last 2.0.3 release in september.
+
 Other alternatives

(fichier de différences tronqué)
expand on the passwords article
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 6adff5d..acc880a 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -1,52 +1,176 @@
-How to chose a good password
-----------------------------
+How to reliably generate passwords and tokens
+=============================================
 
-Most of the password managers mentioned above feature a way to
-generate strong passwords, with different policies (symbols or not,
-length, etc) that people should generally use when creating new
-entries. `pass`, for example, delegates this task to the widely used
+This article is the first in the series of three about passwords.
+
+ 1. The first article covers passwords, how to generate them and a
+    discussion about entropy.
+ 
+ 2. The second article covers password managers and evaluates a few
+    common software alternatives and practices.
+
+ 3. The third article covers password "hashers", that generate
+    multiple passwords from a single one, and that had become more
+    popular in recent years, while being somewhat controversial.
+
+Passwords are used everywhere in our modern life. Between your email
+account and your bank card, a lot of critical security infrastructure
+relies on "something you know", a password. Yet there is very little
+standard documentation on how to generate good passwords. Recently,
+[NIST](http://www.nist.gov/) made a new recommendation, the
+[Special Publication 800-63-3: Digital Authentication Guidelines](https://pages.nist.gov/800-63-3/)
+which outlines new standards of password requirements and practices,
+but that has yet to propagate to the industry, and covers more than
+just passwords, but also password policies like expiration and so on,
+that are beyond the scope of this article.
+
+I also recognize that we should move away from passwords where
+possible. They pose a fundamental security flaw: the reliance on
+humans, which can be coerced to reveal secret information. Major
+organizations are trying to move away from single password
+authentication. Google, for example, is
+[enforcing two factor authentication for their employees](https://cloud.google.com/security/)
+and is considering abandoning
+[passwords on phones as well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
+although we have yet to see that controversial change implemented.
+
+Yet passwords are still here and are likely to stick around for a long
+time until we figure out a better alternative. This article aims at
+covering basic password hygiene techniques and software, and also
+touches on fundamentals of entropy on Linux systems.
+
+What is a good password
+-----------------------
+
+A "good password" may mean different things to different people. I
+will assert that a good password has the following properties:
+
+ * high entropy - hard to guess for machines
+ * transferable - easy to communicate for humans or transfer across
+   weird protocols for computers
+ * memorable - easy to remember for humans
+
+It may seem obvious to some, but a password should be random. It
+should not be based on something else that you know, because that is
+likely to be guessable by an attacker, however "secret" you believe it
+is. Yes, with enough efforts, an attacker can figure out your
+birthday, the name of your first lover, your mother's maiden name,
+where you were last summer or other silly secrets people think they
+have. The only solution here is to use a completely random password,
+generated from a reliable entropy source, which we'll get to later.
+
+A password should also be easily "transferable". Some characters like
+`&` or `!` have special meaning on the web or the shell and can wreck
+havoc when transferred. Certain software also have policies of
+*refusing* some special characters exactly for that reason. Weird
+characters also make it harder for humans to communicate passwords
+across voice channels or different cultural backgrounds. In a more
+extreme example, the popular Signal software even resorted to
+[using only digits](https://whispersystems.org/blog/safety-number-updates/)
+to transfer key fingerprints. They outlined 3 key properties of
+numbers for this purpose:
+
+> 1. Numbers are easy to localize. Using a wordlist from a single
+>    language wouldn't be very accessible, trying to localize
+>    wordlists to make cross-language comparisons possible is very
+>    error prone, and encodings like hex, base32, or base64 are not
+>    compatible with all alphabets. However, all supported languages
+>    have a representation for base 10 digits that safety numbers can
+>    easily be localized into.
+>
+> 2. Numbers are visually and audibly distinct. Numeric
+>    representations in all languages have a lot of evolution behind
+>    them, and have been pushed towards visual and audible
+>    distinguishability. Numeric encodings work well for both speed
+>    and accuracy.
+>
+> 3. Size. We worked to reduce the size of the encoded value to make
+>    the comparison even easier. With the new encoding, users compare
+>    12 groups of 5 digits with each other, which is half the size of
+>    what needed to be compared with the previous hexadecimal format.
+
+But critical part of passwords is the "memorable" part: it is fairly
+easy to generate a random string of characters, but as those passwords
+are hard for humans to remember. As
+[XKCD explained](https://xkcd.com/936/), "through 20 years of effort,
+we've successfully trained everyone to use passwords that are hard for
+human to remember but easy for computers to guess".
+
+Some will argue that you do not need to remember all
+passwords. Indeed, you may store some in password generators or write
+them down in your wallet. In those case, what you need is not a
+password, but something I would rather call a "token", or, as my
+friend Daniel Kahn Gillmor said in a private email, a "high entropy,
+compact and transferable string".
+
+Notice how we removed the "memorable" property and added the "compact"
+one: we want to efficiently convert a high source of entropy into the
+shortest password possible, to work around possibly limiting password
+policies. For example, some bank cards only allow 5-digit security
+PINs and most websites have an upper limit in the password length. The
+"compact" property applies less to "passwords" than tokens, because I
+assume that you will use only a passwords in a select places: your
+password manager, SSH and OpenPGP keys, your computer login and
+encryption keys, period. Those tools are generally under your control
+and should allow large enough passwords that the compact property is
+not important anymore. Everything else should be in a password
+manager.
+
+How to generate a good password
+-------------------------------
+
+Most password managers feature a way to generate strong security
+tokens, with different policies (symbols or not, length, etc). In
+general, you should use your password manager's password generation
+functionality to generate tokens for sites you visit. But how are
+those functionality implemented?
+
+`pass`, the
+[standard UNIX password manager](https://www.passwordstore.org/),
+delegates this task to the widely known
 [pwgen](https://packages.debian.org/sid/pwgen) program. It turns out
 that `pwgen` has a pretty bad track record for security issues,
 especially in the default "phoneme" mode, that generates non-uniformly
 distributed passwords. While `pass` uses the more "secure" `-s` mode,
-I figured it was worth removing that dependency and made a trivial
-patch to pass so that it generates passwords correctly on its own. The
-gory details are in
+I figured it was worth removing that dependency to discourage the use
+of `pwgen` in the default mode. I made a trivial patch to pass so that
+it generates passwords correctly on its own. The gory details are in
 [this email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.html). It
 turns out that there are lots of ways to skin this particular cat. I
 was suggesting we the following pipeline to generate the password:
 
     head -c $entropy /dev/random | base64 | tr -d '\n='
 
-This is what a friend described as a "high-entropy compact
-printable/transferable string generator", as opposed to a "password
-generator". The idea is that a "password" should be memorable as well
-as have high entropy. The priority, in this specific case, is to have
-a string that is as compact as possible with the given entropy, while
+This is what Gillmor described as a "high-entropy compact printable/transferable string", as opposed to a "password"
+generator. The priority, in this specific case, is to have
+a security token that is as compact as possible with the given entropy, while
 at the same time use a character set that should not cause as little
 trouble as possible on sites that restrict the characters you can
-use. base64 was chosen because it is widely available and understand
+use. Gillmor is a co-maintainer of the
+[assword](https://finestructure.net/assword/) password managers, which
+chose base64 because it is widely available and understood,
 and incurs only a small space penalty (+33%). After an interesting
-discussion, Jason A. Donenfeld chose the following pipeline:
+discussion, the pass maintainer, Jason A. Donenfeld, chose the following pipeline:
 
     CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
     CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
     [...]
 	read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
 
-Brian Candler has
+A participant on the mailing list, Brian Candler, has
 [argued](https://lists.zx2c4.com/pipermail/password-store/2016-November/002472.html)
 that this wastes entropy and that the use of `tr` discards valuable
 entropy with
 [little gain in entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
-when compared to base64. In the ensuing discussion, there was a
-mention of an
-[interesting talk at 32c3](https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy)
-about the kernel's entropy sources, where the presenter argues that
-you cannot "run out of entropy" and that using `/dev/urandom` is
-actually fine, even for cryptographic purposes...
+when compared to base64. But in the end, those concerns were
+dismissed by the maintainer.
 
-So that's for generating "compact high entropy strings" - how do you
+Another password manager, [KeePass](http://keepass.info/) uses its own
+routines to generate tokens, but the procedure is the same: read from
+the kernel's entropy source (and user-generated sources in case of
+Keepass) and transform that data into a transferable string.

(fichier de différences tronqué)
split password article in a series of three
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index a84fb1c..1934637 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,276 +1,5 @@
 [still a pre-draft, needs a full review before being submitted]
 
-Password managers and hashers: a review
----------------------------------------
-
-While our dependency on password for authentication has often been
-decried as a serious security flaw that needs to be removed, the
-current reality is that we have to use a plethora of passwords in our
-daily lives on the internet. This problem is especially acute for
-technology professionals and in particular sysadmins. But it also
-affects regular users which have to use a large number of passwords in
-their daily lives, from their online bank credentials to their
-favorite social networking site. Experiments have shown that the human
-memory is phenomenal, yet it can be hard for users to remember a set
-of abstract characters. Humans, in short, are proving to be bad at
-generating high entropy and unique passwords that they can remember.
-
-Therefore humans [reuse passwords](https://xkcd.com/792/), choose
-trivial or guessable ones, write them down on little post-its and
-stick it on their screens or just reset them by email every
-time. Our memory is undeniably failing us and we need help.
-
-This is generally where security professionals teach users about
-password managers. I used to recommend people use three strategies for
-passwords:
-
- 1. use a password hasher
-    (e.g. [password-hasher-plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd))
-    in the browser, or use the "master key feature" of Firefox to
-    store passwords for most (unimportant) websites
- 2. use a password manager for more critical passwords (online bank
-    account, main email account, etc)
- 3. remember a small set of critical passwords (bank card PIN,
-    password manager and hasher passwords)
-
-Unfortunately, a recent review of the code and design of password
-hashers has made me change my mind about that key
-recommendation. Furthermore, Chromium doesn't support using a master
-key, so that recommendation is not portable. Therefore, I have reduced
-my recommendation to:
-
- 1. remember a handful of strong passwords
- 2. use a password manager for the rest
-
-In this article, I explain how to choose a password, give an overview
-of password managers available in Linux distributions. I also go over
-why password hashers are not considered a good security practice.
-
-Pass: the standard password manager?
-------------------------------------
-
-There is a large variety of password managers out there. At my
-previous job, we have inventoried about
-[40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-in the last 8 years, in different stages of development and quality,
-even when limiting ourselves to free software projects. Other sites
-list
-[43 alternatives to the popular Keepass](http://alternativeto.net/software/keepass/?license=opensource)
-password manager. So obviously, this review will not be exhaustive,
-but instead focus on a smaller set of the most well known alternative
-that may be interesting to our readers.
-
-I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a gpg-based password manager that
-features a surprising number of features given its small size:
-copy-paste support, git integration, and multi-user support. The
-commandline interface is simple to use and intuitive. The following,
-will, for example, create a pass repository, a 20 character password
-for your LWN account and copy it to the clipboard:
-
-   pass init
-   pass generate -c lwn 20
-
-The main concern with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone would compromise my machine, they could
-easily see which sites I have access to simply by listing the password
-stored in `~/.password-store`. Also, multi-user support depends on git
-support, which will likely involve setting up a private git repository
-for your team, something which may not be accessible to the average
-Linux user. `pass` is primarily a commandline application which makes
-it less accessible as well, although the community has produced a
-different graphical interfaces that are either using `pass` directly
-or operate on the storage with their own GPG integration. I
-personally use `pass` in combination with
-[rofi](https://davedavenport.github.io/rofi/) to get quick access to
-my passwords, but your usage will probably vary.
-
-Keepass: the popular alternative
---------------------------------
-
-Taking another approach, the well-known
-[KeePass](http://keepass.info/) password manager encrypts passwords in
-a single, password-protected database. Keepass is a graphical
-interface written in C#, so it uses the Mono framework in Linux. A
-separate project, called [KeePassX](https://www.keepassx.org/) is a
-cleanroom implementation written on C++ and QT. Both support the AES
-and Twofish encryption algorithms, although Keepass recently added
-support for the ChaCha20 cipher. AES key derivation is also used to
-generate the actual encryption key for the database, but the latest
-release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
-2015
-[password hashing competition](https://password-hashing.net/). Both
-programs are more or less equivalent, although the original KeePass
-seem to be more featureful in general.
-
-One key feature of both programs is the ability to auto-type passwords
-in forms, most notably in web browsers. The makes those tools really
-easy to use, especially considering they also support global
-keybindings to access passwords. KeePass databases are also designed
-for simultaneous access by multiple users for example using a shared
-network drive. One feature missing compared with pass would be the
-possibility of encrypting a different parts of a database to different
-user groups: pass supports the use of `.gpg-id` files that list
-multiple key identifiers that must encrypt the subdirectory. In
-comparison, users would need to share different files with different
-passphrases in order to have different access levels.
-
-In both cases, access revocation is a sensitive issue: while you can
-re-encrypt a pass database with new keys (thereby removing or adding
-certain accesses) or you can change the password on a KeePass
-database, an hostile party could have always made a backup of the
-database before the revocation. Indeed, in the case of `pass`, older
-entries are even still in the git history... So access revocation, in
-shared password managers, actually means going through every password
-and changing it online.
-
-Other alternatives
-------------------
-
-One alternative that I should mention is the
-[assword](https://finestructure.net/assword/) password manager that,
-despite its name, is also interesting. It's main advantage over pass
-is that it uses a single encrypted JSON file for storage, and
-therefore doesn't leak the name of the entries by default. It also
-supports automatically entering passphrases in fields with the
-[xdotool](https://www.semicomplete.com/projects/xdotool)
-program. It also uses GPG to encrypt passphrases but it's still a bit
-too early in the development for wider adoption, as it's missing
-features like git integration or showing the password in cleartext
-easily.
-
-Another thing I haven't covered here is "secrets management" tools
-like [Vault](https://www.vaultproject.io/) or
-[SFLVault](http://sflvault.org/). Those tools aim to provide teams
-with easy ways to store dynamic tokens like API keys and service
-passwords and share them not only with other humans, but also make
-them accessible. If, however, you are looking at password management
-for teams, this may be worth a look.
-
-How to chose a good password
-----------------------------
-
-Most of the password managers mentioned above feature a way to
-generate strong passwords, with different policies (symbols or not,
-length, etc) that people should generally use when creating new
-entries. `pass`, for example, delegates this task to the widely used
-[pwgen](https://packages.debian.org/sid/pwgen) program. It turns out
-that `pwgen` has a pretty bad track record for security issues,
-especially in the default "phoneme" mode, that generates non-uniformly
-distributed passwords. While `pass` uses the more "secure" `-s` mode,
-I figured it was worth removing that dependency and made a trivial
-patch to pass so that it generates passwords correctly on its own. The
-gory details are in
-[this email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.html). It
-turns out that there are lots of ways to skin this particular cat. I
-was suggesting we the following pipeline to generate the password:
-
-    head -c $entropy /dev/random | base64 | tr -d '\n='
-
-This is what a friend described as a "high-entropy compact
-printable/transferable string generator", as opposed to a "password
-generator". The idea is that a "password" should be memorable as well
-as have high entropy. The priority, in this specific case, is to have
-a string that is as compact as possible with the given entropy, while
-at the same time use a character set that should not cause as little
-trouble as possible on sites that restrict the characters you can
-use. base64 was chosen because it is widely available and understand
-and incurs only a small space penalty (+33%). After an interesting
-discussion, Jason A. Donenfeld chose the following pipeline:
-
-    CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
-    CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
-    [...]
-	read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
-
-Brian Candler has
-[argued](https://lists.zx2c4.com/pipermail/password-store/2016-November/002472.html)
-that this wastes entropy and that the use of `tr` discards valuable
-entropy with
-[little gain in entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
-when compared to base64. In the ensuing discussion, there was a
-mention of an
-[interesting talk at 32c3](https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy)

(fichier de différences tronqué)
dnsdiag was shipped!
diff --git a/blog/2017-01-31-free-software-activities-january-2017.mdwn b/blog/2017-01-31-free-software-activities-january-2017.mdwn
index 4161806..fdc6d57 100644
--- a/blog/2017-01-31-free-software-activities-january-2017.mdwn
+++ b/blog/2017-01-31-free-software-activities-january-2017.mdwn
@@ -168,7 +168,7 @@ Debian uploads
 
 * [calibre 2.75.1 backport][] - thanks to Nicholas Steeves for finding
   out about the [security issues][] as well!
-* [dnsdiag 1.4.0][] - sponsored, in [NEW][]
+* [dnsdiag 1.4.0][] - sponsored, <del>in [NEW][]</del>, now [in unstable][]!
 * [monkeysign 2.2.3][] - a quick bugfix release to ship a good version
   in stretch, now finally with GnuPG 2.x support!
 * [pepper 0.3.3-3][] - just regular package maintenance
@@ -176,13 +176,12 @@ Debian uploads
   [upstream project][]
 * [tuptime 3.3.1][] - sponsored
 
+[in unstable]: https://tracker.debian.org/pkg/dnsdiag
 [tuptime 3.3.1]: https://packages.qa.debian.org/t/tuptime/news/20170116T220657Z.html
-
 [pepper 0.3.3-3]: https://packages.qa.debian.org/p/pepper/news/20170110T211734Z.html
-
 [monkeysign 2.2.3]: https://0xacab.org/monkeysphere/monkeysign/milestones/9
 [NEW]: https://ftp-master.debian.org/new.html
-[dnsdiag 1.4.0]: https://ftp-master.debian.org/new/dnsdiag_1.4.0-1.html
+[dnsdiag 1.4.0]: https://tracker.debian.org/news/836915
 [security issues]: https://security-tracker.debian.org/tracker/source-package/calibre
 [calibre 2.75.1 backport]: https://tracker.debian.org/news/836429
 [tty-clock 2.3]: https://tracker.debian.org/news/832699

add heading to clear up article
diff --git a/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
index 5d476ce..681ded1 100644
--- a/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
+++ b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
@@ -79,6 +79,9 @@ apparently).
 [vmdebootstrap]: https://vmdebootstrap.alioth.debian.org/
 [removed netboot support]: https://bugs.debian.org/849015
 
+Should I start yet another project?
+===================================
+
 So there's still a lot of work to do in this project to get it off the
 ground. I am still a bit hesitant in getting into this, however, for a
 few reasons:

link to new article
diff --git a/blog/2017-01-31-free-software-activities-january-2017.mdwn b/blog/2017-01-31-free-software-activities-january-2017.mdwn
index 8e46e5c..4161806 100644
--- a/blog/2017-01-31-free-software-activities-january-2017.mdwn
+++ b/blog/2017-01-31-free-software-activities-january-2017.mdwn
@@ -131,8 +131,8 @@ Stressant and a new computer
 ----------------------------
 
 I revived the [stressant](https://gitlab.com/anarcat/stressant)
-project and got a new computer. This will be covered in a separate
-article.
+project and got a new computer. This is be covered in a
+[[separate article|2017-01-31-new-desktop-testing-with-stressant]].
 
 Linkchecker forked
 ------------------

fix formatting
diff --git a/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
index 5ad8bf6..5d476ce 100644
--- a/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
+++ b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
@@ -102,8 +102,8 @@ days. I still think it's essential to have some connexion to metal to be
 autonomous in our communications, but I'm worried that focusing on such
 a project is another of my precious dead entreprises... )
 
-#2 is obviously where *you* people come in. Here's a few questions I'd
-like to have feedback on:
+Part #2 is obviously where *you* people come in. Here's a few
+questions I'd like to have feedback on:
 
 1. (How) do you perform stress-testing of your machines before putting
    them in production (or when you find issues you suspect to be

creating tag page tag/testing
diff --git a/tag/testing.mdwn b/tag/testing.mdwn
new file mode 100644
index 0000000..8507783
--- /dev/null
+++ b/tag/testing.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged testing"]]
+
+[[!inline pages="tagged(testing)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/stressant
diff --git a/tag/stressant.mdwn b/tag/stressant.mdwn
new file mode 100644
index 0000000..f4ef0e1
--- /dev/null
+++ b/tag/stressant.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged stressant"]]
+
+[[!inline pages="tagged(stressant)" actions="no" archive="yes"
+feedshow=10]]

*another* new article
diff --git a/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
new file mode 100644
index 0000000..5ad8bf6
--- /dev/null
+++ b/blog/2017-01-31-new-desktop-testing-with-stressant.mdwn
@@ -0,0 +1,136 @@
+[[!meta title="Testing new hardware with Stressant"]]
+
+I got a new computer and wondered... How can I test it? One of those
+innocent questions that brings hours and hours of work and
+questionning...
+
+[[!toc levels=2]]
+
+A new desktop: Intel NUC devices
+================================
+
+After reading up on [Jeff Atwood's blog][] and especially his article
+on the [scooter computer][], I have discovered a whole range of small
+computers that could answer my need for a faster machine in my office
+at a low price tag and without taking up too much of my precious desk
+space. After what now seems like a
+[[too short review|hardware/laptop]] I ended up buying a new
+[Intel NUC][] device [from NCIX.com][], along with [16GB of RAM][] and
+an amazing [500GB M.2 hard drive][] for around 750$. I am very happy
+with the machine. It's very quiet and takes up zero space on my desk
+as I was able to screw it to the back of my screen. You can see my
+review of the hardware compatibility and installation report in the
+[Debian wiki][].
+
+[Debian wiki]: https://wiki.debian.org/InstallingDebianOn/Intel/NUC6i3SYH
+
+I wish I had taken more time to review the possible alternatives - for
+example I found out about the amazing [Airtop PC][] recently and,
+although that specific brand is a bit too expensive, the space of
+small computers is far and wide and deserves a more thorough review
+than just finding the NUC by accident while shopping for laptops on
+[System76.com][]...
+
+[System76.com]: https://system76.com
+[Airtop PC]: http://airtop-pc.com/shop/
+
+Reviving the Stressant project
+==============================
+
+But this, and Atwood's [Is Your Computer Stable?][] article, got me
+thinking about how to test new computers. It's one thing to build a
+machine and fire it up, but how do you know everything is actually
+*really* working? It is common practice to do a basic stress test or
+[burn-in][] when you get a new machine in the industry - how do *you*
+proceed with such tests?
+
+Back in the days when I was working at [Koumbit][], I wrote a tool
+exactly for that purpose called [Stressant][]. Since I am the main
+author of the project and I didn't see much activity on it since I
+left, I felt it would be a good idea to bring it under my personal
+wing again, and I have therefore moved it to my [Gitlab][] where I
+hope to bring it back to life. Parts of the project's rationale are
+explained in an "Intent To Package" the "breakin" tool
+([[!debbug 707178]]), which, after closer examination, ended up
+turning into a complete rewrite.
+
+[burn-in]: https://en.wikipedia.org/wiki/Burn-in
+
+The homepage has a bit more information about how the tool works and
+its objectives, but generally, the idea is to have a live CD or USB
+stick that you can just plugin into a machine to run a battery of
+automated tests (memtest86, bonnie++, stress-ng and disk wiping, for
+example) or allow for interactive rescue missions on broken
+machines. At Koumbit, we had Debirf-based live images that we could
+boot off the network fairly easily that we would use for various
+purposes, although nothing was automated yet. The tool is based on
+Debian, but since it starts from boot, it should be runnable on any
+computer.
+
+I was able to bring the project back to life, to a certain extent, by
+switching to [vmdebootstrap][] instead of [debirf][] for builds, but
+that [removed netboot support][]. Also, I hope that Gitlab could
+provide with an autobuilder for the images, but unfortunately there's
+a [bug in Docker][] that makes it impossible to mount loop images in
+Docker images (which makes it impossible to build Docker in Docker,
+apparently).
+
+[bug in Docker]: https://github.com/docker/docker/issues/27886
+[vmdebootstrap]: https://vmdebootstrap.alioth.debian.org/
+[removed netboot support]: https://bugs.debian.org/849015
+
+So there's still a lot of work to do in this project to get it off the
+ground. I am still a bit hesitant in getting into this, however, for a
+few reasons:
+
+ 1. It's yet another volunteer job - which I am trying to reduce for
+    health and obvious economic reasons. That's a purely personal
+    reason and there isn't much you can do about it.
+
+ 2. I am not sure the project is useful. It's one thing to build a
+    tool that can do basic tests on a machine - I can probably just
+    build an live image for myself that will do everything I need -
+    it's another completely different thing to build something that
+    will scale to multiple machines and be useful for more various use
+    cases and users.
+
+(A variation of #1 is how everything and everyone is moving to the
+cloud. It's become a common argument that you shouldn't run your own
+metal these days, and we seem to be fighting an uphill economic battle
+when we run our own datacenters, rack or even physical servers these
+days. I still think it's essential to have some connexion to metal to be
+autonomous in our communications, but I'm worried that focusing on such
+a project is another of my precious dead entreprises... )
+
+#2 is obviously where *you* people come in. Here's a few questions I'd
+like to have feedback on:
+
+1. (How) do you perform stress-testing of your machines before putting
+   them in production (or when you find issues you suspect to be
+   hardware-related)?
+
+2. Would a tool like breakin or stressant be useful in your environment?
+
+3. Which tools do you use *now* for such purposes?
+
+4. Would you contribute to such a project? How?
+
+5. Do you think there is room for such a project in the existing
+   ecology of projects) or should I contribute to an existing project?
+
+Any feedback here would be, of course, greatly appreciated.
+
+[debirf]: http://cmrg.fifthhorseman.net/wiki/debirf
+[Gitlab]: https://gitlab.com/anarcat/stressant
+[Stressant]: https://redmine.koumbit.net/projects/stressant/
+[Koumbit]: https://koumbit.org/
+[Is Your Computer Stable?]: https://blog.codinghorror.com/is-your-computer-stable/
+[500GB M.2 hard drive]: http://secure1.ncix.com/products/?sku=136743
+[16GB of RAM]: http://secure1.ncix.com/products/?sku=125878
+[from NCIX.com]: http://secure1.ncix.com/products/?sku=122185
+[scooter computer]: https://blog.codinghorror.com/the-scooter-computer/
+[Jeff Atwood's blog]: https://blog.codinghorror.com/
+[intel nuc]: https://en.wikipedia.org/wiki/Next_Unit_of_Computing
+
+[[!tag debian-planet debian geek hardware stressant testing]]
+

creating tag page tag/linkchecker
diff --git a/tag/linkchecker.mdwn b/tag/linkchecker.mdwn
new file mode 100644
index 0000000..1fd2a0b
--- /dev/null
+++ b/tag/linkchecker.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged linkchecker"]]
+
+[[!inline pages="tagged(linkchecker)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/wallabag
diff --git a/tag/wallabag.mdwn b/tag/wallabag.mdwn
new file mode 100644
index 0000000..ab41b6d
--- /dev/null
+++ b/tag/wallabag.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged wallabag"]]
+
+[[!inline pages="tagged(wallabag)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/feed2tweet
diff --git a/tag/feed2tweet.mdwn b/tag/feed2tweet.mdwn
new file mode 100644
index 0000000..924332e
--- /dev/null
+++ b/tag/feed2tweet.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged feed2tweet"]]
+
+[[!inline pages="tagged(feed2tweet)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/golang
diff --git a/tag/golang.mdwn b/tag/golang.mdwn
new file mode 100644
index 0000000..8f39723
--- /dev/null
+++ b/tag/golang.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged golang"]]
+
+[[!inline pages="tagged(golang)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/wallabako
diff --git a/tag/wallabako.mdwn b/tag/wallabako.mdwn
new file mode 100644
index 0000000..98e09f4
--- /dev/null
+++ b/tag/wallabako.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged wallabako"]]
+
+[[!inline pages="tagged(wallabako)" actions="no" archive="yes"
+feedshow=10]]

new article
diff --git a/blog/2017-01-31-free-software-activities-january-2017.mdwn b/blog/2017-01-31-free-software-activities-january-2017.mdwn
new file mode 100644
index 0000000..8e46e5c
--- /dev/null
+++ b/blog/2017-01-31-free-software-activities-january-2017.mdwn
@@ -0,0 +1,236 @@
+[[!meta title="My free software activities, January 2017"]]
+
+[[!toc levels=2]]
+
+manpages.debian.org launched
+============================
+
+The [debmans][] package I had so lovingly worked on
+[[last month|2016-12-30-free-software-activities-november-december-2016]]
+is now officially abandoned. It turns out that another developer,
+[Michael Stapelberg][] wrote his own implementation from scratch,
+called [debiman][]. 
+
+<img
+src="https://camo.githubusercontent.com/d3abbe036e841354c80d931d61de8caefd721125/68747470733a2f2f64656269616e2e6769746875622e696f2f646562696d616e2f646562696d616e2d6c6f676f2e737667"
+align="right" />
+
+Both software share a similar design: they are both static site
+generators that parse an existing archive and call another tool to
+convert manpages into HTML. We even both settled on the same converter
+(`mdoc`). But while I wrote `debmans` in Python, `debiman` is written
+in [Go](http://golang.org/). `debiman` also seems much faster, being
+written with concurrency in mind from the start. Finally, `debiman` is
+more feature complete: it properly deals with conflicting packages,
+localization and all sorts redirections. Heck, it even has a pretty
+logo, how can I compete?
+
+While `debmans` was written first and was in the process of being
+deployed, I had to give it up. It was a frustrating experience because
+I felt I wasted a lot of time working on software that ended up being
+discarded, especially because I put so much work on it, creating
+[extensive documentation][], an almost complete test suite and even
+filing a [detailed core infrastructure best practices report][] In the
+end, I think that was the right choice: debiman seemed clearly
+superior and the best tool should win. Plus, it meant less work for
+me: Michael and Javier (the previous `manpages.debian.org` maintainer)
+did all the work of putting the site online. I also learned a lot
+about the [CII best practices program][],
+[flask](http://flask.pocoo.org/), [click](http://click.pocoo.org/5/)
+and, ultimately, the [Go programming language][] itself, which I'll refer
+to as [Golang][] for brievity. `debiman` definitely brought Golang
+into the spotlight for me. I had looked at Go before, but it seemed to
+be yet another language. But seeing Michael beat me to rebuilding the
+service really made me look at it again more seriously. While I really
+appreciate [Python][] and I will probably still use it as my language
+of choice for GUI work and smaller scripts, but for daemons, network
+programs and servers, I will seriously consider Golang in the future.
+
+[Go programming language]: https://en.wikipedia.org/wiki/Golang
+[Python]: https://www.python.org/
+[Golang]: https://golang.org/
+[CII best practices program]: https://bestpractices.coreinfrastructure.org/
+[detailed core infrastructure best practices report]: https://bestpractices.coreinfrastructure.org/projects/489
+[extensive documentation]: http://debmans.readthedocs.io/en/latest/
+
+The site is now [online](https://manpages.debian.org/) at
+<https://manpages.debian.org/>. I even got credited in the
+[about page](https://manpages.debian.org/about.html) which makes up
+for the disappointment.
+
+[debiman]: https://github.com/Debian/debiman/
+[Michael Stapelberg]: https://michael.stapelberg.de/
+[debmans]: https://gitlab.com/anarcat/debmans
+
+Wallabako downloads Wallabag articles on my Kobo e-reader
+=========================================================
+
+This obviously brings me to the latest project I worked on,
+[Wallabako][], my first Golang program ever. Wallabako is basically a
+client for the [Wallabag](http://wallabag.org/) application, which is
+a free software "read it later" service, an alternative to the likes
+of [Pocket][], [Pinboard][] or
+[Evernote][]. [[Back in April|2016-04-21-free-software-activities-april-2016]],
+I had looked downloading my "unread articles" into my new ebook
+reader, going through convoluted ways like implementing
+[OPDS support into Wallabag][], which turned out to be too difficult.
+
+[OPDS support into Wallabag]: https://github.com/wallabag/wallabag/issues/1253
+[Evernote]: https://en.wikipedia.org/wiki/Evernote
+[Pinboard]: https://en.wikipedia.org/wiki/Pinboard_(website)
+[Pocket]: https://en.wikipedia.org/wiki/Pocket_(application)
+[Wallabako]: https://gitlab.com/anarcat/wallabako/
+
+Instead, I used this as an opportunity to learn Golang. After reading
+the quite readable [golang specification][] over the weekend, I found
+the language to be quite elegant and simple, yet very powerful. Golang
+feels like C, but built with concurrency and memory (and to a certain
+extent, type) safety in mind, along with a novel approach to OO
+programming. 
+
+The fact that everything can be compiled in one neat little static
+binary was also a key feature in selecting golang for this project, as
+I do not have much control over the platform my E-Reader is running:
+it is a Linux machine running under the ARM architecture, but beyond
+that, there isn't much available. I couldn't afford to ship a Python
+interpreter in there and while there are solutions there like
+[pyinstaller][], I felt that it may be so easy to deploy on ARM. The
+borg team [had trouble][] building a ARM binary, restoring to tricks
+like building on a Raspberry PI or inside an emulator. In comparison,
+the native go compiler supports cross-compilation out of the box
+through a simple environment variable.
+
+[had trouble]: https://github.com/borgbackup/borg/issues/1018
+[pyinstaller]: http://www.pyinstaller.org/
+[golang specification]: https://golang.org/ref/spec
+
+So far Wallabako works amazingly well: when I "bag" a new article in
+Wallabag, either from my phone or my web browser, it will show up on
+my ebook reader then next time I open the wifi. I still need to "tap"
+the screen to fake the insertion of the USB cable, but we're
+[working on automating that][]. I also need to make the installation
+of the software much easier and improve the documentation, because so
+far it's unlikely that someone unfamiliar with Kobo hardware hacking
+will be able to install it.
+
+[working on automating that]: https://www.mobileread.com/forums/showthread.php?p=3467503
+
+Other work
+==========
+
+According to Github, I filed a bunch of bugs all over the place (25
+issues in 16 repositories), sent patches everywhere (13 pull requests
+in 6 repositories), and tried to fix everythin (created 38 commits in
+7 repositories). Note that excludes most of my work, which happens on
+Gitlab. January was still a very busy month, especially considering I
+had an accident which kept me mostly offline for about a week.
+
+Here are some details on specific projects.
+
+Stressant and a new computer
+----------------------------
+
+I revived the [stressant](https://gitlab.com/anarcat/stressant)
+project and got a new computer. This will be covered in a separate
+article.
+
+Linkchecker forked
+------------------
+
+After much [discussions][], it was decided to fork the [linkchecker][]
+project, which now lives in its own [organization][]. I still have to
+write community guidelines and figure out the best way to maintain a
+stable branch, but I am hopeful that the community will pick up the
+project as multiple people volunteer to co-maintain the project. There
+has already been pull requests and issues reported, so that's a good
+sign.
+
+[organization]: https://github.com/linkcheck/linkchecker
+[linkchecker]: https://github.com/wummel/linkchecker/
+[discussions]: https://github.com/wummel/linkchecker/issues/686
+
+Feed2tweet refresh
+------------------
+
+I re-rolled my pull requests to the [feed2tweet][] project: last time
+they were closed before I had time to rebase them. The author was okay
+with me re-submitting them, but he hasn't commented, reviewed or
+merged the patches yet so I am worried they will be dropped again.
+
+At that point, I would more likely rewrite this from scratch than try
+to collaborate with someone that is clearly not interested in doing
+so...
+
+[feed2tweet]: https://github.com/chaica/feed2tweet/
+
+Debian uploads
+--------------
+
+* [calibre 2.75.1 backport][] - thanks to Nicholas Steeves for finding
+  out about the [security issues][] as well!
+* [dnsdiag 1.4.0][] - sponsored, in [NEW][]
+* [monkeysign 2.2.3][] - a quick bugfix release to ship a good version
+  in stretch, now finally with GnuPG 2.x support!
+* [pepper 0.3.3-3][] - just regular package maintenance
+* [tty-clock 2.3][] - new upstream release, also got access to the
+  [upstream project][]
+* [tuptime 3.3.1][] - sponsored
+
+[tuptime 3.3.1]: https://packages.qa.debian.org/t/tuptime/news/20170116T220657Z.html
+
+[pepper 0.3.3-3]: https://packages.qa.debian.org/p/pepper/news/20170110T211734Z.html
+
+[monkeysign 2.2.3]: https://0xacab.org/monkeysphere/monkeysign/milestones/9
+[NEW]: https://ftp-master.debian.org/new.html
+[dnsdiag 1.4.0]: https://ftp-master.debian.org/new/dnsdiag_1.4.0-1.html
+[security issues]: https://security-tracker.debian.org/tracker/source-package/calibre
+[calibre 2.75.1 backport]: https://tracker.debian.org/news/836429
+[tty-clock 2.3]: https://tracker.debian.org/news/832699
+[upstream project]: https://github.com/xorg62/tty-clock
+
+Debian Long Term Support (LTS)
+==============================
+
+This is my 10th month working on [Debian LTS][], started by

(fichier de différences tronqué)
fix broken link
diff --git a/blog/2016-12-30-free-software-activities-november-december-2016.mdwn b/blog/2016-12-30-free-software-activities-november-december-2016.mdwn
index a91a6ff..a8530ba 100644
--- a/blog/2016-12-30-free-software-activities-november-december-2016.mdwn
+++ b/blog/2016-12-30-free-software-activities-november-december-2016.mdwn
@@ -6,7 +6,7 @@ Debian Long Term Support (LTS)
 ==============================
 
 Those were 8th and 9th months working on [Debian LTS][] started by
-[Raphael Hertzog at Freexian]. I had trouble resuming work in November
+[Raphael Hertzog at Freexian][]. I had trouble resuming work in November
 as I had taken a long break during the month and started looking at
 issues only during the last week of November.
 

add tons more soft i downloaded after install
diff --git a/software/mytasks.desc b/software/mytasks.desc
index e333a29..22aeaf7 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -18,8 +18,13 @@ Packages: list
  apt-listbugs
  aptitude
  bzr
+ cdbs
  curl
+ colordiff
  debian-el
+ debian-installer-9-netboot-amd64
+ syslinux-efi
+ pxelinux
  devscripts
  dia
  dpkg-dev-el
@@ -28,27 +33,40 @@ Packages: list
  emacs-goodies-el
  emacs25
  emacs25-common-non-dfsg
+ flake8
  git
  git-annex
  git-buildpackage
  git-email
  git-svn
+ golang
+ golang-mode
+ golint
+ graphviz
  ikiwiki
  info
  jq
  libterm-readkey-perl
+ linkchecker
  make-doc
  mercurial
  myrepos
+ ncdu
  org-mode
  org-mode-doc
  pastebinit
  perl-doc
  pv
  python
+ python3
  python-jedi
  python3-jedi
  python3-pip
+ python-pip
+ python-wheel
+ python-setuptools
+ python-setuptools-scm
+ twine
  qemu
  quilt
  subversion
@@ -64,21 +82,31 @@ Packages: list
  arandr
  calibre
  chromium
+ diceware
+ dict
  emacs
+ exiftool
+ fim
  firefox
  fonts-roboto
  fortunes
  gameclock
  gnutls-bin
+ hledger
+ jmtpfs
+ ledger
+ ledger
  less
  libnotify-bin
  localepurge
  locales
+ mlocate
  monkeysign
  monkeysphere
  mpd
  msmtp-mta
  mutt
+ ncdu
  needrestart
  needrestart-session
  notmuch
@@ -89,6 +117,7 @@ Packages: list
  parcimonie
  pass
  pcscd
+ picard
  pmount
  pinentry-qt
  python-certifi
@@ -110,6 +139,7 @@ Packages: list
  verbiste
  verbiste-gnome
  workrave
+ xkcdpass
  xmobar
  xmonad
  xplanet
@@ -125,6 +155,7 @@ Packages: list
  auctex
  texlive-latex-base
  texlive-latex-recommended
+ texlive-latex-extra
 
 Task: anarcat-sysadmin
 Section: user

precision diceware
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index a3a675e..a84fb1c 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -250,10 +250,7 @@ One disadvantage of diceware is that it doesn't actually tell you how
 much entropy the generated password has - you need to compute it
 yourself. The actual number depends on the word list: the default word
 list has about 13 bits of entropy per word, which means the default 6
-word passwords have about 78 bits of entropy. diceware is also less
-flexible in the word lists it accepts, as they need to be tailor-made
-for the diceware program (as opposed to the flat files that `xkcdpass`
-accepts).
+word passwords have about 78 bits of entropy. 
 
 Both of these programs are recent, having entered Debian only after
 the last stable release, so they may not be available on your
@@ -270,8 +267,9 @@ for better control over the level of entropy:
     Theme9accord=milan8ninety9few
 
 For some reason, `passwdqc` restricts the entropy of passwords between
-the bounds of 24 and 85 bits. That tool is also much less customisable
-than the other too: what you see here is pretty much what you get.
+the bounds of 24 and 85 bits. That tool is also much less customizable
+than the other too: what you see here is pretty much what you get. The
+wordlist is also hardcoded in the C source code.
 
 The case against "password hashers"
 -----------------------------------

first unfinished draft sent
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
new file mode 100644
index 0000000..a3a675e
--- /dev/null
+++ b/blog/password-hashers.mdwn
@@ -0,0 +1,387 @@
+[still a pre-draft, needs a full review before being submitted]
+
+Password managers and hashers: a review
+---------------------------------------
+
+While our dependency on password for authentication has often been
+decried as a serious security flaw that needs to be removed, the
+current reality is that we have to use a plethora of passwords in our
+daily lives on the internet. This problem is especially acute for
+technology professionals and in particular sysadmins. But it also
+affects regular users which have to use a large number of passwords in
+their daily lives, from their online bank credentials to their
+favorite social networking site. Experiments have shown that the human
+memory is phenomenal, yet it can be hard for users to remember a set
+of abstract characters. Humans, in short, are proving to be bad at
+generating high entropy and unique passwords that they can remember.
+
+Therefore humans [reuse passwords](https://xkcd.com/792/), choose
+trivial or guessable ones, write them down on little post-its and
+stick it on their screens or just reset them by email every
+time. Our memory is undeniably failing us and we need help.
+
+This is generally where security professionals teach users about
+password managers. I used to recommend people use three strategies for
+passwords:
+
+ 1. use a password hasher
+    (e.g. [password-hasher-plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd))
+    in the browser, or use the "master key feature" of Firefox to
+    store passwords for most (unimportant) websites
+ 2. use a password manager for more critical passwords (online bank
+    account, main email account, etc)
+ 3. remember a small set of critical passwords (bank card PIN,
+    password manager and hasher passwords)
+
+Unfortunately, a recent review of the code and design of password
+hashers has made me change my mind about that key
+recommendation. Furthermore, Chromium doesn't support using a master
+key, so that recommendation is not portable. Therefore, I have reduced
+my recommendation to:
+
+ 1. remember a handful of strong passwords
+ 2. use a password manager for the rest
+
+In this article, I explain how to choose a password, give an overview
+of password managers available in Linux distributions. I also go over
+why password hashers are not considered a good security practice.
+
+Pass: the standard password manager?
+------------------------------------
+
+There is a large variety of password managers out there. At my
+previous job, we have inventoried about
+[40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
+in the last 8 years, in different stages of development and quality,
+even when limiting ourselves to free software projects. Other sites
+list
+[43 alternatives to the popular Keepass](http://alternativeto.net/software/keepass/?license=opensource)
+password manager. So obviously, this review will not be exhaustive,
+but instead focus on a smaller set of the most well known alternative
+that may be interesting to our readers.
+
+I am currently using [password-store](https://www.passwordstore.org/),
+or `pass`, as a password manager. It aims to be "the standard unix
+password manager". `pass` is a gpg-based password manager that
+features a surprising number of features given its small size:
+copy-paste support, git integration, and multi-user support. The
+commandline interface is simple to use and intuitive. The following,
+will, for example, create a pass repository, a 20 character password
+for your LWN account and copy it to the clipboard:
+
+   pass init
+   pass generate -c lwn 20
+
+The main concern with `pass` is that it doesn't encrypt the *name* of
+those entries: if someone would compromise my machine, they could
+easily see which sites I have access to simply by listing the password
+stored in `~/.password-store`. Also, multi-user support depends on git
+support, which will likely involve setting up a private git repository
+for your team, something which may not be accessible to the average
+Linux user. `pass` is primarily a commandline application which makes
+it less accessible as well, although the community has produced a
+different graphical interfaces that are either using `pass` directly
+or operate on the storage with their own GPG integration. I
+personally use `pass` in combination with
+[rofi](https://davedavenport.github.io/rofi/) to get quick access to
+my passwords, but your usage will probably vary.
+
+Keepass: the popular alternative
+--------------------------------
+
+Taking another approach, the well-known
+[KeePass](http://keepass.info/) password manager encrypts passwords in
+a single, password-protected database. Keepass is a graphical
+interface written in C#, so it uses the Mono framework in Linux. A
+separate project, called [KeePassX](https://www.keepassx.org/) is a
+cleanroom implementation written on C++ and QT. Both support the AES
+and Twofish encryption algorithms, although Keepass recently added
+support for the ChaCha20 cipher. AES key derivation is also used to
+generate the actual encryption key for the database, but the latest
+release of KeePass also added using
+[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
+2015
+[password hashing competition](https://password-hashing.net/). Both
+programs are more or less equivalent, although the original KeePass
+seem to be more featureful in general.
+
+One key feature of both programs is the ability to auto-type passwords
+in forms, most notably in web browsers. The makes those tools really
+easy to use, especially considering they also support global
+keybindings to access passwords. KeePass databases are also designed
+for simultaneous access by multiple users for example using a shared
+network drive. One feature missing compared with pass would be the
+possibility of encrypting a different parts of a database to different
+user groups: pass supports the use of `.gpg-id` files that list
+multiple key identifiers that must encrypt the subdirectory. In
+comparison, users would need to share different files with different
+passphrases in order to have different access levels.
+
+In both cases, access revocation is a sensitive issue: while you can
+re-encrypt a pass database with new keys (thereby removing or adding
+certain accesses) or you can change the password on a KeePass
+database, an hostile party could have always made a backup of the
+database before the revocation. Indeed, in the case of `pass`, older
+entries are even still in the git history... So access revocation, in
+shared password managers, actually means going through every password
+and changing it online.
+
+Other alternatives
+------------------
+
+One alternative that I should mention is the
+[assword](https://finestructure.net/assword/) password manager that,
+despite its name, is also interesting. It's main advantage over pass
+is that it uses a single encrypted JSON file for storage, and
+therefore doesn't leak the name of the entries by default. It also
+supports automatically entering passphrases in fields with the
+[xdotool](https://www.semicomplete.com/projects/xdotool)
+program. It also uses GPG to encrypt passphrases but it's still a bit
+too early in the development for wider adoption, as it's missing
+features like git integration or showing the password in cleartext
+easily.
+
+Another thing I haven't covered here is "secrets management" tools
+like [Vault](https://www.vaultproject.io/) or
+[SFLVault](http://sflvault.org/). Those tools aim to provide teams
+with easy ways to store dynamic tokens like API keys and service
+passwords and share them not only with other humans, but also make
+them accessible. If, however, you are looking at password management
+for teams, this may be worth a look.
+
+How to chose a good password
+----------------------------
+
+Most of the password managers mentioned above feature a way to
+generate strong passwords, with different policies (symbols or not,
+length, etc) that people should generally use when creating new
+entries. `pass`, for example, delegates this task to the widely used
+[pwgen](https://packages.debian.org/sid/pwgen) program. It turns out
+that `pwgen` has a pretty bad track record for security issues,
+especially in the default "phoneme" mode, that generates non-uniformly
+distributed passwords. While `pass` uses the more "secure" `-s` mode,
+I figured it was worth removing that dependency and made a trivial
+patch to pass so that it generates passwords correctly on its own. The
+gory details are in
+[this email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.html). It
+turns out that there are lots of ways to skin this particular cat. I
+was suggesting we the following pipeline to generate the password:
+
+    head -c $entropy /dev/random | base64 | tr -d '\n='
+
+This is what a friend described as a "high-entropy compact
+printable/transferable string generator", as opposed to a "password
+generator". The idea is that a "password" should be memorable as well
+as have high entropy. The priority, in this specific case, is to have
+a string that is as compact as possible with the given entropy, while
+at the same time use a character set that should not cause as little
+trouble as possible on sites that restrict the characters you can
+use. base64 was chosen because it is widely available and understand
+and incurs only a small space penalty (+33%). After an interesting
+discussion, Jason A. Donenfeld chose the following pipeline:
+
+    CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
+    CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
+    [...]
+	read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
+
+Brian Candler has
+[argued](https://lists.zx2c4.com/pipermail/password-store/2016-November/002472.html)
+that this wastes entropy and that the use of `tr` discards valuable
+entropy with
+[little gain in entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
+when compared to base64. In the ensuing discussion, there was a
+mention of an

(fichier de différences tronqué)
note abotu ipv6
diff --git "a/services/r\303\251seau.mdwn" "b/services/r\303\251seau.mdwn"
index f717123..879888a 100644
--- "a/services/r\303\251seau.mdwn"
+++ "b/services/r\303\251seau.mdwn"
@@ -1,5 +1,7 @@
 Le réseau est constitué d'une ensemble d'interconnexions [[!wikipedia gigabit]] et d'un réseau [[wifi]] <del>connecté en partie avec le [[mesh]]</del> et un pare-feu roulant sous FreeBSD avec `pf`, nommée `roadkiller`.
 
+Update: ipv6 and dns work better with new router. see good test page: <http://en.conn.internet.nl/connection/>.
+
 Problèmes connus
 ================
 

add toc and update
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 6ae1842..75dec58 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -1,3 +1,7 @@
+[[!toc levels=2]]
+
+Update: i didn't buy a laptop, but a NUC. See [installation report](https://wiki.debian.org/InstallingDebianOn/Intel/NUC6i3SYH#preview).
+
 Besoins
 =======
 

new firefox config: middle click shouldn't visit url
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 741a9fa..bfbc0c2 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -106,10 +106,15 @@ I have set the following configuration options:
  * privacy.donottrackheader.enabled: true (maybe futile)
  * browser.safebrowsing.enabled: true (this downloads a list of sites
    in Mozille products, doesn't report indivudual sites to google...)
- * browser.search.defaultenginename: [searx.me](https://searx.me/) (default search engine)
+ * browser.search.defaultenginename: [searx.me](https://searx.me/)
+   (default search engine)
  * [browser.startup.page](http://kb.mozillazine.org/Browser.startup.page):
    3 (startup with previous session)
- * [network.cookie.cookieBehavior](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2): 1 (no third-party cookies)
+ * [network.cookie.cookieBehavior](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2):
+   1 (no third-party cookies)
+ * [middlemouse.contentLoadURL](http://kb.mozillazine.org/Middlemouse.contentLoadURL):
+   false (got used to chromium not doing that, and it seems too risky:
+   passwords can leak in DNS too easily if you miss the field)
 
 Remaining issues
 ----------------

remove dead links and old stuff
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 9429605..741a9fa 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -62,40 +62,16 @@ I usually have those extensions installed:
 [site engagement]: https://www.chromium.org/developers/design-documents/site-engagement
 [infamous privacy intrusions]: https://lwn.net/Articles/648392/
 
-Those are also interesting:
-
- * [keyconfig](http://extensionroom.mozdev.org/more-info/keyconfig)
- * [calendar](http://www.mozilla.org/projects/calendar/calext/download.html)
- * [del.icio.us](http://del.icio.us/help/firefox/extension) (devenu propriétaire)
- * [reload every](https://addons.mozilla.org/firefox/115/)
- * [fireftp](https://addons.mozilla.org/firefox/684/)?
- * [download statusbar](https://addons.mozilla.org/firefox/26/)? -
-   interesting idea, much nicer than the usual download dialog, but
-   not quite there yet: takes much-needed screen real-estate.
- * [cookie crumbler](https://addons.mozilla.org/firefox/1569/)? or
-   [cookie culler](https://addons.mozilla.org/firefox/82/)? (the first
-   allows clearing of certain cookies for testing, the second allows
-   for designating certain cookies as "protected" and not removed
-   automatically)
- * [sage](https://addons.mozilla.org/firefox/77/)?
-
 I removed those:
 
- * [mozex](http://mozex.mozdev.org/) (now "it's all text")
  * [adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865) -
    now selling ads! replaced with ublock
- * [Diigo toolbar](http://www.diigo.com/) que j'ai
-   [patché](/blog/2010-01-11-bridging-diigo-and-identica)
-   ([copie compilée](http://anarcat.ath.cx/dist/diigotoolbar-firefox-new.xpi)) -
-   i have my own software now (bookie / wallabag)
- * [Aviary](https://addons.mozilla.org/en-US/firefox/addon/11587) -
-   screenshot tool
  * [yslow](https://addons.mozilla.org/fr/firefox/addon/5369) - now
    more or less built-in
  * [firebug](https://addons.mozilla.org/firefox/1843/) - same
- * [webdevelopper toolbar](https://addons.mozilla.org/firefox/60/) (builtin)
- * [password hasher](https://addons.mozilla.org/fr/firefox/addon/3282)
-   (has security issues)
+ * [webdevelopper toolbar](https://addons.mozilla.org/firefox/60/) - builtin
+ * [password hasher](https://addons.mozilla.org/fr/firefox/addon/3282) -
+   has security issues
 
 I know about the following password hashers, which all have issues, so
 I am now using a regular password manager for my web passwords:

fix shortcut links
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 833d7b6..9429605 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -36,7 +36,7 @@ Debian, so not really an option for me right now.
 [ungoogled-chromium]: https://github.com/Eloston/ungoogled-chromium
 
 So long story short, I use firefox now. It's nice to root for the
-[[!wikipedia Browser_wars title="underdog"]] anyways.
+[[!wikipedia Browser_wars desc="underdog"]] anyways.
 
 Extensions
 ----------
@@ -44,16 +44,16 @@ Extensions
 I usually have those extensions installed:
 
 * [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
-  ([[!debpkg xul-ext-ublock-origin title="debian package"]],
+  ([[!debpkg xul-ext-ublock-origin desc="debian package"]],
   [source](https://github.com/gorhill/uBlock))
-* [it's all text!](https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) ([[!debpkg xul-ext-itsalltext title="debian package"]], [source](https://github.com/docwhat/itsalltext))
+* [it's all text!](https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) ([[!debpkg xul-ext-itsalltext desc="debian package"]], [source](https://github.com/docwhat/itsalltext))
 * [uMatrix](https://addons.mozilla.org/firefox/addon/umatrix/) (no
   debian package, [source](https://github.com/gorhill/uMatrix))
 * [wallabager](https://addons.mozilla.org/en-US/firefox/addon/wallabagger/)
   (no debian package,
   [source](https://github.com/wallabag/wallabagger)) 
 * [zotero](https://www.zotero.org/)
-  ([[!debpkg zotero-standalone title="zotero standalone debian package"]]
+  ([[!debpkg zotero-standalone desc="zotero standalone debian package"]]
   and
   [[!debpkg xul-ext-zotero title"zotero extension debian package"]])
 

add fix toc
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 909a056..833d7b6 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Firefox web browser configuration"]]
 
-[[!toc]]
+[[!toc levels=2]]
 
 History
 -------

fix links and headings
diff --git a/software/desktop.mdwn b/software/desktop.mdwn
index ffd7046..e0c5f07 100644
--- a/software/desktop.mdwn
+++ b/software/desktop.mdwn
@@ -32,9 +32,8 @@ Web browser: Firefox
 
 I always have a web browser opened, so that is a key tool for me
 since, unfortunately, everything seems to be moving inside a browser
-window... After using [[chromium]] for many years, I am now using
-Firefox, see the [[firefox]] page for more details.
-
+window... After using [[chromium]] for a few years, I am now back to
+using Firefox, see the [[firefox]] page for more details.
 
 Emails: notmuch
 ---------------
diff --git a/software/desktop/chromium.mdwn b/software/desktop/chromium.mdwn
index 4a7ed9c..c5accdd 100644
--- a/software/desktop/chromium.mdwn
+++ b/software/desktop/chromium.mdwn
@@ -1,9 +1,8 @@
-Web browser: Chromium
----------------------
+[[!meta title="Chromium web browser configuration"]]
 
 I used to use Chromium, but stopped because of privacy issues, see the
-parent [[desktop]] page for details. I may still use Chromium for
-webpage tests however.
+[[firefox]] page for details. I may still use Chromium for webpage
+tests however.
 
 Here's the extensions I have usually installed in Chromium:
 
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 1dbe521..909a056 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -1,3 +1,10 @@
+[[!meta title="Firefox web browser configuration"]]
+
+[[!toc]]
+
+History
+-------
+
 I have been a long time user of the "Mozilla" family of web
 browsers. My first web browser (apart from [[!wikipedia lynx]]) was
 probably the venerable [[!wikipedia Netscape Navigator]], which was
@@ -31,6 +38,9 @@ Debian, so not really an option for me right now.
 So long story short, I use firefox now. It's nice to root for the
 [[!wikipedia Browser_wars title="underdog"]] anyways.
 
+Extensions
+----------
+
 I usually have those extensions installed:
 
 * [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
@@ -109,7 +119,10 @@ see. horrible. Hashing needs 100k+ iterations of PBKDF, see
 i need to ditch my password hasher. Sad. Should probably make a blog
 post or page about this from <https://wiki.koumbit.net/GestionDesMotDePasse>.
 
-I use the following configurations:
+Configuration
+-------------
+
+I have set the following configuration options:
 
  * [browser.tabs.loadDivertedInBackground](http://kb.mozillazine.org/About:config_entries):
    true (fixes an issue where focus would change to the firefox window
@@ -122,6 +135,9 @@ I use the following configurations:
    3 (startup with previous session)
  * [network.cookie.cookieBehavior](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2): 1 (no third-party cookies)
 
+Remaining issues
+----------------
+
 My remaining concerns with Firefox, right now, are:
 
  * it's slower than Chromium: Firefox starts in about 2 seconds here

move firefox docs to a subpage, it is too big
diff --git a/software/desktop.mdwn b/software/desktop.mdwn
index abd6b0b..ffd7046 100644
--- a/software/desktop.mdwn
+++ b/software/desktop.mdwn
@@ -30,140 +30,11 @@ what Mr. Robot says is cool][]. Right? Right.
 Web browser: Firefox
 --------------------
 
-I have been a long time user of the "Mozilla" family of web
-browsers. My first web browser (apart from [[!wikipedia lynx]]) was
-probably the venerable [[!wikipedia Netscape Navigator]], which was
-eventually opened source into what was then called Pheonix and then
-[[!wikipedia Firefox]]. I eventually abandoned Firefox because of
-stability and features: an HTML5 video site would crash firefox, and
-when I tried it in Chromium, it worked, so I gave on up on Firefox
-then.
-
-But now (Jan 2017) I have switched back to Firefox, mostly because of
-privacy reasons. There are multiple privacy issues in Chromium (which
-is supposed to be the unbranded version of the Google Chrome browser).
-Some [infamous privacy intrusions][] were fixed, but others werent:
-bug [[!debbug 792580]] (phones home to [[!wikipedia DoubleClick]] and
-[[!wikipedia Google Analytics]]) was filed in 2015 and I confirmed it
-in 2016, and it's still not fixed. I have also found troubling the
-[site engagement][] profile that Chromium builds on you (which carries
-over into the Incognito mode). I also had concerns that Chromium would
-keep history indefinitely, but it looks like it actually
-[keeps it for 90 days][]. Firefox is now actually worst than Chromium
-in that regard as it keeps a [dynamic number of pages][] instead of a
-configurable delay. I also had problems with Chromium not opening tabs
-when it's lacking focus ([[!debbug 848930]]), a new regression that
-was really annoying as I visit a lot of websites... There's the
-[ungoogled-chromium][] project which attempts to correct all of those
-issues, but that is yet another browser, and it's not packaged in
-Debian, so not really an option for me right now.
-
-[ungoogled-chromium]: https://github.com/Eloston/ungoogled-chromium
-
-So long story short, I use firefox now. It's nice to root for the
-[[!wikipedia Browser_wars title="underdog"]] anyways.
-
-I usually have those extensions installed:
-
-* [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
-  ([[!debpkg xul-ext-ublock-origin title="debian package"]],
-  [source](https://github.com/gorhill/uBlock))
-* [it's all text!](https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) ([[!debpkg xul-ext-itsalltext title="debian package"]], [source](https://github.com/docwhat/itsalltext))
-* [uMatrix](https://addons.mozilla.org/firefox/addon/umatrix/) (no
-  debian package, [source](https://github.com/gorhill/uMatrix))
-* [wallabager](https://addons.mozilla.org/en-US/firefox/addon/wallabagger/)
-  (no debian package,
-  [source](https://github.com/wallabag/wallabagger)) 
-* [zotero](https://www.zotero.org/)
-  ([[!debpkg zotero-standalone title="zotero standalone debian package"]]
-  and
-  [[!debpkg xul-ext-zotero title"zotero extension debian package"]])
-
-[dynamic number of pages]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration
-[keeps it for 90 days]: https://support.google.com/chrome/answer/95589
-[site engagement]: https://www.chromium.org/developers/design-documents/site-engagement
-[infamous privacy intrusions]: https://lwn.net/Articles/648392/
-
-Those are also interesting:
-
- * [keyconfig](http://extensionroom.mozdev.org/more-info/keyconfig)
- * [calendar](http://www.mozilla.org/projects/calendar/calext/download.html)
- * [del.icio.us](http://del.icio.us/help/firefox/extension) (devenu propriétaire)
- * [reload every](https://addons.mozilla.org/firefox/115/)
- * [fireftp](https://addons.mozilla.org/firefox/684/)?
- * [download statusbar](https://addons.mozilla.org/firefox/26/)? -
-   interesting idea, much nicer than the usual download dialog, but
-   not quite there yet: takes much-needed screen real-estate.
- * [cookie crumbler](https://addons.mozilla.org/firefox/1569/)? or
-   [cookie culler](https://addons.mozilla.org/firefox/82/)? (the first
-   allows clearing of certain cookies for testing, the second allows
-   for designating certain cookies as "protected" and not removed
-   automatically)
- * [sage](https://addons.mozilla.org/firefox/77/)?
-
-I removed those:
-
- * [mozex](http://mozex.mozdev.org/) (now "it's all text")
- * [adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865) -
-   now selling ads! replaced with ublock
- * [Diigo toolbar](http://www.diigo.com/) que j'ai
-   [patché](/blog/2010-01-11-bridging-diigo-and-identica)
-   ([copie compilée](http://anarcat.ath.cx/dist/diigotoolbar-firefox-new.xpi)) -
-   i have my own software now (bookie / wallabag)
- * [Aviary](https://addons.mozilla.org/en-US/firefox/addon/11587) -
-   screenshot tool
- * [yslow](https://addons.mozilla.org/fr/firefox/addon/5369) - now
-   more or less built-in
- * [firebug](https://addons.mozilla.org/firefox/1843/) - same
- * [webdevelopper toolbar](https://addons.mozilla.org/firefox/60/) (builtin)
- * [password hasher](https://addons.mozilla.org/fr/firefox/addon/3282)
-   (has security issues)
-
-I know about the following password hashers, which all have issues, so
-I am now using a regular password manager for my web passwords:
-
-Password hasher alternatives:
-
- * [lesspass](https://lesspass.com/) - interesting, but needs a server, see also [this discussion](https://news.ycombinator.com/item?id=12889807). v1 has weak key derivation, and v2's key derivation exhausted my patience (more than 30 seconds to generate a password, wtf)
- * [pwdhash](https://crypto.stanford.edu/PwdHash) - standford's pwdhash - like the original password hasher, more or less. doesn't have settings or private key
- * [Alzheimer password generator](https://github.com/viralpoetry/password-generator) - similar, has a seed, but less usable
- * [supergenpass](https://github.com/chriszarate/supergenpass) - bookmarklet, one of the earliest ones, MD5
- * [nic wolff's](http://angel.net/~nic/passwd.current.html) - probably the first implementation of this (see [this claim](https://news.ycombinator.com/item?id=12892655))
- * [getvau.lt](https://getvau.lt) - also only a web page, but crypto looks sound
- * [lastpass](https://www.lastpass.com/) - proprietary server-side
- * [hash0](https://github.com/dannysu/hash0) - another one
- * [bpassword](https://www.alexhornung.com/code/bpasswd/) - uses bcrypt
-
-It looks like they all suck in new exotic ways. Heck, even the
-original password hasher is a simple hmac_sha256, from what i can
-see. horrible. Hashing needs 100k+ iterations of PBKDF, see
-[this](http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pbkdf2-sha256). So
-i need to ditch my password hasher. Sad. Should probably make a blog
-post or page about this from <https://wiki.koumbit.net/GestionDesMotDePasse>.
-
-I use the following configurations:
-
- * [browser.tabs.loadDivertedInBackground](http://kb.mozillazine.org/About:config_entries):
-   true (fixes an issue where focus would change to the firefox window
-   (and workspace!) when clicking links in other apps
- * privacy.donottrackheader.enabled: true (maybe futile)
- * browser.safebrowsing.enabled: true (this downloads a list of sites
-   in Mozille products, doesn't report indivudual sites to google...)
- * browser.search.defaultenginename: [searx.me](https://searx.me/) (default search engine)
- * [browser.startup.page](http://kb.mozillazine.org/Browser.startup.page):
-   3 (startup with previous session)
- * [network.cookie.cookieBehavior](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2): 1 (no third-party cookies)
-
-My remaining concerns with Firefox, right now, are:
-
- * it's slower than Chromium: Firefox starts in about 2 seconds here
-   whereas Chromium starts in less than a second (on `curie`, i3-6100U
-   4x2.3Ghz, 16GB of ram, on my laptop, it's even worst: about 7-8
-   seconds for Firefox and < 2 seconds for Chromium). since i usually
-   have the browser already started, that's kind of okay.
- * history retention settings are unclear
- * it has the "pocket" plugin enabled by default, which supports a
-   proprietary service, a questionable decision at best.
+I always have a web browser opened, so that is a key tool for me
+since, unfortunately, everything seems to be moving inside a browser
+window... After using [[chromium]] for many years, I am now using
+Firefox, see the [[firefox]] page for more details.
+
 
 Emails: notmuch
 ---------------
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 533b36c..1dbe521 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -1,2 +1,134 @@
-See the [[desktop]] page for my Firefox configuration, now that it's
-my defauilt browser.
+I have been a long time user of the "Mozilla" family of web
+browsers. My first web browser (apart from [[!wikipedia lynx]]) was
+probably the venerable [[!wikipedia Netscape Navigator]], which was
+eventually opened source into what was then called Pheonix and then
+[[!wikipedia Firefox]]. I eventually abandoned Firefox because of
+stability and features: an HTML5 video site would crash firefox, and
+when I tried it in Chromium, it worked, so I gave on up on Firefox
+then.
+
+But now (Jan 2017) I have switched back to Firefox, mostly because of
+privacy reasons. There are multiple privacy issues in Chromium (which
+is supposed to be the unbranded version of the Google Chrome browser).
+Some [infamous privacy intrusions][] were fixed, but others werent:
+bug [[!debbug 792580]] (phones home to [[!wikipedia DoubleClick]] and
+[[!wikipedia Google Analytics]]) was filed in 2015 and I confirmed it
+in 2016, and it's still not fixed. I have also found troubling the
+[site engagement][] profile that Chromium builds on you (which carries
+over into the Incognito mode). I also had concerns that Chromium would
+keep history indefinitely, but it looks like it actually
+[keeps it for 90 days][]. Firefox is now actually worst than Chromium
+in that regard as it keeps a [dynamic number of pages][] instead of a
+configurable delay. I also had problems with Chromium not opening tabs
+when it's lacking focus ([[!debbug 848930]]), a new regression that
+was really annoying as I visit a lot of websites... There's the
+[ungoogled-chromium][] project which attempts to correct all of those
+issues, but that is yet another browser, and it's not packaged in
+Debian, so not really an option for me right now.
+
+[ungoogled-chromium]: https://github.com/Eloston/ungoogled-chromium
+
+So long story short, I use firefox now. It's nice to root for the
+[[!wikipedia Browser_wars title="underdog"]] anyways.
+
+I usually have those extensions installed:
+
+* [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
+  ([[!debpkg xul-ext-ublock-origin title="debian package"]],
+  [source](https://github.com/gorhill/uBlock))
+* [it's all text!](https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) ([[!debpkg xul-ext-itsalltext title="debian package"]], [source](https://github.com/docwhat/itsalltext))
+* [uMatrix](https://addons.mozilla.org/firefox/addon/umatrix/) (no
+  debian package, [source](https://github.com/gorhill/uMatrix))
+* [wallabager](https://addons.mozilla.org/en-US/firefox/addon/wallabagger/)
+  (no debian package,

(fichier de différences tronqué)
link to ungoogled-chromium, add concerns with firefox
diff --git a/software/desktop.mdwn b/software/desktop.mdwn
index e586720..abd6b0b 100644
--- a/software/desktop.mdwn
+++ b/software/desktop.mdwn
@@ -53,10 +53,17 @@ keep history indefinitely, but it looks like it actually
 in that regard as it keeps a [dynamic number of pages][] instead of a
 configurable delay. I also had problems with Chromium not opening tabs
 when it's lacking focus ([[!debbug 848930]]), a new regression that
-was really annoying as I visit a lot of websites...
+was really annoying as I visit a lot of websites... There's the
+[ungoogled-chromium][] project which attempts to correct all of those
+issues, but that is yet another browser, and it's not packaged in
+Debian, so not really an option for me right now.
 
-So long story short, I use firefox now. I usually have those
-extensions installed:
+[ungoogled-chromium]: https://github.com/Eloston/ungoogled-chromium
+
+So long story short, I use firefox now. It's nice to root for the
+[[!wikipedia Browser_wars title="underdog"]] anyways.
+
+I usually have those extensions installed:
 
 * [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
   ([[!debpkg xul-ext-ublock-origin title="debian package"]],
@@ -147,6 +154,17 @@ I use the following configurations:
    3 (startup with previous session)
  * [network.cookie.cookieBehavior](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2): 1 (no third-party cookies)
 
+My remaining concerns with Firefox, right now, are:
+
+ * it's slower than Chromium: Firefox starts in about 2 seconds here
+   whereas Chromium starts in less than a second (on `curie`, i3-6100U
+   4x2.3Ghz, 16GB of ram, on my laptop, it's even worst: about 7-8
+   seconds for Firefox and < 2 seconds for Chromium). since i usually
+   have the browser already started, that's kind of okay.
+ * history retention settings are unclear
+ * it has the "pocket" plugin enabled by default, which supports a
+   proprietary service, a questionable decision at best.
+
 Emails: notmuch
 ---------------
 

add more software i installed on this workstation
diff --git a/software/mytasks.desc b/software/mytasks.desc
index 48e81ca..e333a29 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -27,21 +27,30 @@ Packages: list
  emacs
  emacs-goodies-el
  emacs25
+ emacs25-common-non-dfsg
  git
  git-annex
  git-buildpackage
  git-email
  git-svn
  ikiwiki
+ info
  jq
  libterm-readkey-perl
+ make-doc
  mercurial
  myrepos
+ org-mode
+ org-mode-doc
  pastebinit
  perl-doc
  pv
  python
+ python-jedi
+ python3-jedi
+ python3-pip
  qemu
+ quilt
  subversion
  time
  vim
@@ -57,10 +66,12 @@ Packages: list
  chromium
  emacs
  firefox
+ fonts-roboto
  fortunes
  gameclock
  gnutls-bin
  less
+ libnotify-bin
  localepurge
  locales
  monkeysign
@@ -79,6 +90,7 @@ Packages: list
  pass
  pcscd
  pmount
+ pinentry-qt
  python-certifi
  qalculate
  qalculate-gtk
@@ -86,11 +98,14 @@ Packages: list
  rofi
  rxvt-unicode
  scdaemon
+ scrot
  sxiv
+ taffybar
  thunar
  torbrowser-launcher
  transmission-qt
  trayer
+ tty-clock
  unattended-upgrades
  verbiste
  verbiste-gnome
@@ -184,6 +199,7 @@ Packages: list
  gmpc
  gmpc-plugins
  gtk-recordmydesktop
+ mediainfo
  mpc
  mpdtoys
  recordmydesktop

switch to firefox by default
diff --git a/software/desktop.mdwn b/software/desktop.mdwn
index 02136b7..e586720 100644
--- a/software/desktop.mdwn
+++ b/software/desktop.mdwn
@@ -27,101 +27,125 @@ what Mr. Robot says is cool][]. Right? Right.
 [i3]: http://i3wm.org/
 [Awesome]: https://awesome.naquadah.org/
 
-Web browser: Chromium
----------------------
+Web browser: Firefox
+--------------------
 
-So yes, i started using Google's free browser... Those are the
-critical extensions I always install and configure:
-
- * [uBlock][] - replaces adblock: blocks all adds and annoying stuff
-   online, and faster than adblock (note that there's a fork from the
-   original author named uBlock origin, which i am not using)
- * [uMatrix][] - replaces noscript, and better. blocks all
-   spyware and tracking devices, especially from Google and Facebook
-   everywhere.
- * [Edit with Emacs][] - to use my prefered editor on long text areas
- * [The Great Suspender][] - reduces memory usage significantly by
-   turning off old tabs
- * [Wallabag][] - to archive as "read it later", keeps tab count low
-
- [uBlock]: https://ublock.org/
- [uMatrix]: https://github.com/gorhill/uMatrix
- [The Great Suspender]: https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg
- [Wallabag]: https://chrome.google.com/webstore/detail/wallabagger/gbmgphmejlcoihgedabhgjdkcahacjlj
-
-I also have a few basic bookmarks and bookmarklets:
-
- * Local news: [radio-canada](http://ici.radio-canada.ca/),
-   [Le Devoir](http://www.ledevoir.com/), etc
- * [Local weather](http://meteo.gc.ca/city/pages/qc-147_metric_f.html)
- * <a href="javascript:location.href='http://web.archive.org/web/'+document.location.href;">Wayback</a>
-   (visit page on wayback machine)
- * <a href="javascript:void(window.open('https://web.archive.org/save/'+location.href));">Wayback
-   save</a> (save URL on wayback machine)
-
-Those I have installed on some profiles but not all, as they are not
-as useful:
-
- * [RSS feed subscription][] - allows for proper display and subscription of RSS feeds
- * [KB SSL Enforcer][] - chrome's version of [HTTPS everywhere][] (limited because of [issue #35897][] that makes it hard for chrome to block things a priori)
- * [Tab Menu][] (dead link) replaced with
-   [Quick tabs][] - to deal with the ever growing list of tabs
-   ([vertical tabs][] is also interesting, but no source available)
- * [WebRTC network limiter][] - tries to hide my IP address somewhat
-   more, probably breaking stuff more than anything
- * [Quick QR-Code][] - to transfer webpages to my phone quickly
-
- [Edit with Emacs]: https://chrome.google.com/webstore/detail/edit-with-emacs/ljobjlafonikaiipfkggjbhkghgicgoh
- [Speed Tracer (by Google)]: https://chrome.google.com/extensions/detail/ognampngfcbddbfemdapefohjiobgbdl
- [RSS feed subscription]: https://chrome.google.com/extensions/detail/nlbjncdgjeocebhnmkbbbdekmmmcbfjd
- [Tab Menu]: https://chrome.google.com/extensions/detail/galfofdpepkcahkfobimileafiobdplb
- [vertical tabs]: https://chrome.google.com/webstore/detail/verticaltabs/imimolldggofidcmfdkcffpjcgaggoaf
- [Quick tabs]: https://chrome.google.com/webstore/detail/quick-tabs/jnjfeinjfmenlddahdjdmgpbokiacbbb
- [KB SSL Enforcer]: https://chrome.google.com/extensions/detail/flcpelgcagfhfoegekianiofphddckof
- [HTTPS everywhere]: http://www.eff.org/https-everywhere
- [issue #35897]: https://code.google.com/p/chromium/issues/detail?id=35897
- [Quick QR-Code]: https://chrome.google.com/webstore/detail/quick-qrcode/ijoeanckpfaegjkbdmbihinbdpgpcbba
- [WebRTC network limiter]: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia
-
-I stopped using:
-
- * [Bookie][] - to manage my bookmarks - replaced by Wallabagg
- * [Password Hasher Plus][] - my web passwords manager, see also
-   [my password management policy][] - not good, more details to come
- * [httpswitchboard][], now replaced by [uMatrix][] et [uBlock][]
- * [Chrome Apps & Extensions Developer Tool][] - it was allowing me to
-   control extensions updates better, but is not free software
- * [Web Developer][] - mostly builtin now
- * [Diigo Web Highlighter and Bookmark][] - i use my own bookmark
-   manager, [Bookie][]
- * [Flashblock][] - i use built in flashblocking, or just disable
-   flash to use HTML5
- * [Disconnect][] - i use http switchboard now
- * [Notscripts][]) - complains about missing html5 storage, maybe i
-   have a too old chromium? it doesn't block inline scripts anyways
- * [ScriptNo][] - replaced with [uMatrix][]
- * [AdBlock+ Element Hiding Helper][] - seems to duplicate adblock
- * [Awesome screenshot][] - i use shutter now + it's a horrible [pile of spyware now][]
- * RSS Live Links - <del>doesn't actually provide live bookmarks
-   folders, couldn't figure it out</del> kind of working, but a pain
-   to configure
- * Session Manager - i don't actually need that: it's builtin to
-   chrome now
-
- [Bookie]: https://chrome.google.com/webstore/detail/bookie/knnbmilfpmbmlglpeemajjkelcbaaega
- [Password Hasher Plus]: https://chrome.google.com/extensions/detail/glopbmohkffbnplcjbbbfmmimfhfnhgd
- [my password management policy]: https://wiki.koumbit.net/GestionDesMotDePasse
- [httpswitchboard]: https://github.com/gorhill/httpswitchboard
- [Chrome Apps & Extensions Developer Tool]: https://chrome.google.com/webstore/detail/chrome-apps-extensions-de/ohmmkhmmmpcnpikjeljgnaoabkaalbgc
- [Web Developer]: https://chrome.google.com/extensions/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
- [Diigo Web Highlighter and Bookmark]: https://chrome.google.com/extensions/detail/oojbgadfejifecebmdnhhkbhdjaphole
- [Flashblock]: https://chrome.google.com/extensions/detail/gofhjkjmkpinhpoiabjplobcaignabnl
- [AdBlock+ Element Hiding Helper]: https://chrome.google.com/extensions/detail/chmimgmjdabgiilljdjfbonifbhiglao
- [Disconnect]: https://chrome.google.com/extensions/detail/jeoacafpbcihiomhlakheieifhpjdfeo
- [Notscripts]: https://chrome.google.com/extensions/detail/odjhifogjcknibkahlpidmdajjpkkcfn
- [ScriptNo]: https://chrome.google.com/webstore/detail/scriptno/oiigbmnaadbkfbmpbfijlflahbdbdgdf
- [Awesome screenshot]: https://chrome.google.com/extensions/detail/alelhddbbhepgpmgidjdcjakblofbmce
- [pile of spyware now]: https://mig5.net/content/awesome-screenshot-and-niki-bot
+I have been a long time user of the "Mozilla" family of web
+browsers. My first web browser (apart from [[!wikipedia lynx]]) was
+probably the venerable [[!wikipedia Netscape Navigator]], which was
+eventually opened source into what was then called Pheonix and then
+[[!wikipedia Firefox]]. I eventually abandoned Firefox because of
+stability and features: an HTML5 video site would crash firefox, and
+when I tried it in Chromium, it worked, so I gave on up on Firefox
+then.
+
+But now (Jan 2017) I have switched back to Firefox, mostly because of
+privacy reasons. There are multiple privacy issues in Chromium (which
+is supposed to be the unbranded version of the Google Chrome browser).
+Some [infamous privacy intrusions][] were fixed, but others werent:
+bug [[!debbug 792580]] (phones home to [[!wikipedia DoubleClick]] and
+[[!wikipedia Google Analytics]]) was filed in 2015 and I confirmed it
+in 2016, and it's still not fixed. I have also found troubling the
+[site engagement][] profile that Chromium builds on you (which carries
+over into the Incognito mode). I also had concerns that Chromium would
+keep history indefinitely, but it looks like it actually
+[keeps it for 90 days][]. Firefox is now actually worst than Chromium
+in that regard as it keeps a [dynamic number of pages][] instead of a
+configurable delay. I also had problems with Chromium not opening tabs
+when it's lacking focus ([[!debbug 848930]]), a new regression that
+was really annoying as I visit a lot of websites...
+
+So long story short, I use firefox now. I usually have those
+extensions installed:
+
+* [uBlock Origin](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
+  ([[!debpkg xul-ext-ublock-origin title="debian package"]],
+  [source](https://github.com/gorhill/uBlock))
+* [it's all text!](https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) ([[!debpkg xul-ext-itsalltext title="debian package"]], [source](https://github.com/docwhat/itsalltext))
+* [uMatrix](https://addons.mozilla.org/firefox/addon/umatrix/) (no
+  debian package, [source](https://github.com/gorhill/uMatrix))
+* [wallabager](https://addons.mozilla.org/en-US/firefox/addon/wallabagger/)
+  (no debian package,
+  [source](https://github.com/wallabag/wallabagger)) 
+* [zotero](https://www.zotero.org/)
+  ([[!debpkg zotero-standalone title="zotero standalone debian package"]]
+  and
+  [[!debpkg xul-ext-zotero title"zotero extension debian package"]])
+
+[dynamic number of pages]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration
+[keeps it for 90 days]: https://support.google.com/chrome/answer/95589
+[site engagement]: https://www.chromium.org/developers/design-documents/site-engagement
+[infamous privacy intrusions]: https://lwn.net/Articles/648392/
+
+Those are also interesting:
+
+ * [keyconfig](http://extensionroom.mozdev.org/more-info/keyconfig)
+ * [calendar](http://www.mozilla.org/projects/calendar/calext/download.html)
+ * [del.icio.us](http://del.icio.us/help/firefox/extension) (devenu propriétaire)
+ * [reload every](https://addons.mozilla.org/firefox/115/)
+ * [fireftp](https://addons.mozilla.org/firefox/684/)?
+ * [download statusbar](https://addons.mozilla.org/firefox/26/)? -
+   interesting idea, much nicer than the usual download dialog, but
+   not quite there yet: takes much-needed screen real-estate.
+ * [cookie crumbler](https://addons.mozilla.org/firefox/1569/)? or
+   [cookie culler](https://addons.mozilla.org/firefox/82/)? (the first
+   allows clearing of certain cookies for testing, the second allows
+   for designating certain cookies as "protected" and not removed
+   automatically)
+ * [sage](https://addons.mozilla.org/firefox/77/)?
+
+I removed those:
+
+ * [mozex](http://mozex.mozdev.org/) (now "it's all text")
+ * [adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865) -
+   now selling ads! replaced with ublock
+ * [Diigo toolbar](http://www.diigo.com/) que j'ai
+   [patché](/blog/2010-01-11-bridging-diigo-and-identica)
+   ([copie compilée](http://anarcat.ath.cx/dist/diigotoolbar-firefox-new.xpi)) -
+   i have my own software now (bookie / wallabag)
+ * [Aviary](https://addons.mozilla.org/en-US/firefox/addon/11587) -
+   screenshot tool
+ * [yslow](https://addons.mozilla.org/fr/firefox/addon/5369) - now
+   more or less built-in
+ * [firebug](https://addons.mozilla.org/firefox/1843/) - same
+ * [webdevelopper toolbar](https://addons.mozilla.org/firefox/60/) (builtin)
+ * [password hasher](https://addons.mozilla.org/fr/firefox/addon/3282)
+   (has security issues)
+
+I know about the following password hashers, which all have issues, so
+I am now using a regular password manager for my web passwords:
+
+Password hasher alternatives:
+
+ * [lesspass](https://lesspass.com/) - interesting, but needs a server, see also [this discussion](https://news.ycombinator.com/item?id=12889807). v1 has weak key derivation, and v2's key derivation exhausted my patience (more than 30 seconds to generate a password, wtf)
+ * [pwdhash](https://crypto.stanford.edu/PwdHash) - standford's pwdhash - like the original password hasher, more or less. doesn't have settings or private key
+ * [Alzheimer password generator](https://github.com/viralpoetry/password-generator) - similar, has a seed, but less usable
+ * [supergenpass](https://github.com/chriszarate/supergenpass) - bookmarklet, one of the earliest ones, MD5
+ * [nic wolff's](http://angel.net/~nic/passwd.current.html) - probably the first implementation of this (see [this claim](https://news.ycombinator.com/item?id=12892655))
+ * [getvau.lt](https://getvau.lt) - also only a web page, but crypto looks sound
+ * [lastpass](https://www.lastpass.com/) - proprietary server-side
+ * [hash0](https://github.com/dannysu/hash0) - another one

(fichier de différences tronqué)
add yalp store to list of apk downloaders
diff --git a/hardware/phone/htc-one-s.mdwn b/hardware/phone/htc-one-s.mdwn
index 4dc4952..ed48982 100644
--- a/hardware/phone/htc-one-s.mdwn
+++ b/hardware/phone/htc-one-s.mdwn
@@ -925,7 +925,7 @@ Future work
   doesn't actually encrypt the sd card.
 * <del>Remove the Google Apps completely</del> Done: [Open Gapps][] is not really
   open, and features the app store and google play services, which we
-  we can workaround with stuff like [Raccoon][], [gplaycli][] or
+  we can workaround with stuff like [Raccoon][], [gplaycli][], [Yalp Store][] or
   [APK Downloader][] (to download APKs without the Play Store) and
   [MicroG][] for a free software version of the Google Play services
 * <del>Install the official Signal using the above, since we *want* to make
@@ -941,6 +941,8 @@ Future work
   get a fix.</del> Removing gapps made that work well, along with the
   fake GSM services described above.
 
+[Yalp Store]: https://github.com/yeriomin/YalpStore
+
 [lack of voice support]: https://github.com/LibreSignal/LibreSignal/issues/10
 [Wifi to determine location]: https://f-droid.org/repository/browse/?fdid=org.fitchfamily.android.wifi_backend
 [VoIP.ms SMS supports GCM-less push notifications]: https://github.com/michaelkourlas/voipms-sms-client/issues/37

add qemu alias
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 284dfbe..e119b4d 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -648,7 +648,15 @@ host, which should be the gateway. `10080` is an arbitrary port above
 
 Ports can also be forwarded from the host to the VM using the `-net`
 command. For example, `-net user,hostfwd=tcp::10022-:22 -net nic`
-would allow the host to connect to the VM's SSH server.
+would allow the host to connect to the VM's SSH server. I ended up
+setting up the following shell alias:
+
+    # qemu: specify architecture, enable serial port and common port
+    # forwards (HTTP and SSH), enable KVM support and don't write the
+    # image by default (can be worked around with C-a s at
+    # runtime). graphical display still enabled for POLA (some VMs don't
+    # have serial), can be turned off with -display none.
+    alias qemu="qemu-system-x86_64 -serial mon:stdio -net user,hostfwd=tcp::10080-:80 -net user,hostfwd=tcp::10022-:22 -net nic -enable-kvm -snapshot"
 
 `.deb` files can be installed with `dpkg -i`, which will likely fail
 because of missing dependency, so you need to also run `apt-get

easier copy-paste
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index ca85e51..284dfbe 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -578,8 +578,7 @@ machine as debootstrap only creates a chroot, which virtual machines
 do not necessarily understand. Here is how to create the virtual
 machine disk using [vmdebootstrap][].
 
-    DIST=sid
-    ARCH=amd64
+    DIST=sid ARCH=amd64
     sudo vmdebootstrap --serial-console --enable-dhcp --convert-qcow2 --verbose --distribution=$DIST --arch=$ARCH --image=$DIST-$ARCH.qcow2
 
 [vmdebootstrap]: https://vmdebootstrap.alioth.debian.org/

revert lines in headers, looks ugly on frontpage
diff --git a/local.css b/local.css
index 0eabef1..7c3b1e1 100644
--- a/local.css
+++ b/local.css
@@ -23,19 +23,3 @@
 /* bootstrap should deal with this, but ikiwiki doesn't assign the right style and anyways our width is smaller than necessary */
 table, table.table { width: inherit; }
 table { font-size: inherit; } /* why the heck does chrome override font-size for tables?! */
-
-/* disinguish headers levels better */
-h1 {
-    border-bottom:1px solid #888;    
-}
-h2 {
-    border-bottom:1px solid #aaa;    
-}
-h3 {
-    border-bottom:1px solid #ccc;    
-}
-h4,h5,h6 {
-    border-bottom:1px solid #eee;
-}
-/* remove duplicate border */
-.page-header { border-bottom: none; }

fixup
diff --git a/local.css b/local.css
index beb5859..0eabef1 100644
--- a/local.css
+++ b/local.css
@@ -37,4 +37,5 @@ h3 {
 h4,h5,h6 {
     border-bottom:1px solid #eee;
 }
-header { border-bottom: none; }
+/* remove duplicate border */
+.page-header { border-bottom: none; }

remove duplicate header
diff --git a/local.css b/local.css
index 7355c9d..beb5859 100644
--- a/local.css
+++ b/local.css
@@ -37,3 +37,4 @@ h3 {
 h4,h5,h6 {
     border-bottom:1px solid #eee;
 }
+header { border-bottom: none; }

distinguish levels better
diff --git a/local.css b/local.css
index 7c3b1e1..7355c9d 100644
--- a/local.css
+++ b/local.css
@@ -23,3 +23,17 @@
 /* bootstrap should deal with this, but ikiwiki doesn't assign the right style and anyways our width is smaller than necessary */
 table, table.table { width: inherit; }
 table { font-size: inherit; } /* why the heck does chrome override font-size for tables?! */
+
+/* disinguish headers levels better */
+h1 {
+    border-bottom:1px solid #888;    
+}
+h2 {
+    border-bottom:1px solid #aaa;    
+}
+h3 {
+    border-bottom:1px solid #ccc;    
+}
+h4,h5,h6 {
+    border-bottom:1px solid #eee;
+}

rename a drive
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index f21ad4b..f0ff354 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -20,7 +20,7 @@ particulier [[services/mail]].
 ## Offsite
 
  * `green_crypt1`: 1.5TB WD "green" hard drive, encrypted, bup backups
- * `barracuda_crypt`: 2TB Seagate barracuda drive, encrypted,
+ * `barracuda_crypt2`: 2TB Seagate barracuda drive, encrypted,
    `git-annex` archive, previously `/srv`, but stripped of private
    data - see
    [this post about reinit](http://git-annex.branchable.com/todo/reinit_should_work_without_arguments/)

security upgrade on ikiwiki
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index a1941b6..78d0895 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -146,23 +146,26 @@ On any given upgrade, the following patches need to be applied:
 
 ### bugfixes
 
-I am only carrying one patch now in Ikiwiki. I dropped the [[!iki bugs/notifyemail fails with some openid providers]] patch because of the impeding doom of OpenID.
-
-Here is the only patch left:
+There are two patches left:
 
  * [[!iki todo/git-annex_support]]
+ * [[!iki todo/admonitions]]
+
+I dropped the [[!iki bugs/notifyemail fails with some openid providers]] patch because of the impeding doom of OpenID.
 
 To apply this patch:
 
     cd src/ikiwiki
-    release=debian/3.20141016.3
+    release=debian/3.20141016.4
     git rebase $release dev/git-annex-support
     git diff $release..dev/git-annex-support | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )
     git diff $release..dev/git-annex-support | ( cd /usr/share/perl5 ; sudo patch -p1 )
+    # not sure about that rebase
+    git rebase origin/master admonitions
     git diff origin/master..admonitions IkiWiki/Plugin/admonition.pm | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )
     git diff origin/master..admonitions IkiWiki/Plugin/admonition.pm | ( cd /usr/share/perl5 ; sudo patch -p1 )
-    git diff origin/master..admonitions doc/style.css | ( cd /usr/share/ikiwiki/basewiki ; sudo patch -p2 )
     git diff origin/master..admonitions doc/style.css | ( cd /usr/share/ikiwiki/basewiki ; sudo patch -p2 --dry-run )
+    git diff origin/master..admonitions doc/style.css | ( cd /usr/share/ikiwiki/basewiki ; sudo patch -p2 )
 
 ### New feature: markdown WYSIWYG!
 
@@ -194,6 +197,15 @@ patching file templates/albumprev.tmpl
 patching file templates/albumviewer.tmpl
 """]]
 
+2017-01-14: security upgrade
+----------------------------
+
+Upstream did a security update in Jessie from
+[3.20141016.3](https://tracker.debian.org/news/671435) to
+[3.20141016.4](https://tracker.debian.org/media/packages/i/ikiwiki/changelog-3.20141016.3). I
+did reapplied the git-annex and admonition patches since those are
+still useful.
+
 2016-05-08: security upgrade
 -----------------------------
 

citation apte des binamés
diff --git a/sigs.fortune b/sigs.fortune
index b4e61d2..c0d3956 100644
--- a/sigs.fortune
+++ b/sigs.fortune
@@ -1036,3 +1036,8 @@ Work expands so as to fill the time available for its completion.
 On reconnait la grandeur et la valeur d'une nation à la façon dont
 celle-ci traite ses animaux.
                         - Mahatma Gandhi
+%
+Si les élections n'étaient pas indispensables à la prospérité du
+capital, on ne nous les servirait pas partout, toujours, à coup de
+fric, à coup de flics.
+                        - René Binamé

update disk setup
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index 6f741c3..f21ad4b 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -8,7 +8,7 @@ particulier [[services/mail]].
 ## Internal
 
  * `srv`: 4TB (3.6TiB) SATA; video, mp3, external backups, postcasts and so on
-   * `/srv/video`: 1.3TiB
+   * `/srv/video`: 1.3TiB, git-annex `backup` group
  * `marcossd1`: 480GB SSD; `/home`, `/var`, `/usr` and so on...
 
 ## External
@@ -16,17 +16,20 @@ particulier [[services/mail]].
  * `calyx`: 1.5TB iOmega external backup drive, encrypted, `borg`
    backups (currently ~700GB)
  * `archive0`: 160GB Maxtor hard drive, clear, `git-annex` for `mp3`
- * `barracuda_crypt`: 2TB Seagate barracuda drive, encrypted,
-   `git-annex` archive, previously `/srv`, but stripped of private
-   data - see
-   [this post about reinit](http://git-annex.branchable.com/todo/reinit_should_work_without_arguments/)
 
 ## Offsite
 
  * `green_crypt1`: 1.5TB WD "green" hard drive, encrypted, bup backups
- * `green_crypt0`: 1.5TB WD "green" hard drive, encrypted, `git-annex` backups
+ * `barracuda_crypt`: 2TB Seagate barracuda drive, encrypted,
+   `git-annex` archive, previously `/srv`, but stripped of private
+   data - see
+   [this post about reinit](http://git-annex.branchable.com/todo/reinit_should_work_without_arguments/)
+   git-annex `incrementalbackup`
+ * `green_crypt0`: 1.5TB WD "green" hard drive, encrypted, `git-annex`
+   backups - at hacim's house, git-annex `backup` group
  * `markov`: office workstation backup of `mp3`, unmaintained
 
+
 ## bill of material
 
  path                 | backup location        | notes

sort
diff --git a/software/mytasks.desc b/software/mytasks.desc
index 1f1cb95..48e81ca 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -3,11 +3,11 @@ Section: user
 Description: Anarcat's graphic design software
  My graphic design tools. Not much, since I don't do much of that.
 Packages: list
- inkscape
+ dia
  gimp
+ inkscape
  sane
  xsane
- dia
 
 Task: anarcat-developer
 Section: user
@@ -117,11 +117,15 @@ Description: Anarcat's sysadmin tools
  .
 Packages: list
  apacheutils
+ borgbackup
+ borgbackup-doc
  ccze
  curl
  dnsutils
  etckeeper
+ gparted
  hdparm
+ i7z
  iftop
  ioping
  ipcalc
@@ -129,6 +133,7 @@ Packages: list
  mtr-tiny
  netcat
  nmap
+ oping
  passwdqc
  powertop
  pv
@@ -138,16 +143,11 @@ Packages: list
  siege
  socat
  sshfs
- i7z
- borgbackup
- borgbackup-doc
- gparted
- oping
- tuptime
  strace
  swaks
  tcpdump
  tor
+ tuptime
  whois
 
 Task: anarcat-comms
@@ -156,12 +156,12 @@ Description: Anarcat's communication tools
  Mostly consists of mail and IRC stuff (irssi, mutt, thunderbird,
  offlineimap).
 Packages: list
- irssi-plugin-xmpp
+ bsd-mailx
  irssi-plugin-otr
+ irssi-plugin-xmpp
  irssi-scripts
  mutt
  offlineimap
- bsd-mailx
 
 Task: anarcat-mailserver
 Section: user
@@ -177,46 +177,46 @@ Description: Anarcat's multimedia tools
  This is mp3, ogg tools, audio recording and playing software, video
  playing screencasting software, etc.
 Packages: list
+ audacious
+ audacity
+ darktable
  exfalso
+ gmpc
+ gmpc-plugins
+ gtk-recordmydesktop
  mpc
  mpdtoys
+ recordmydesktop
  sox
- xawtv-tools
- xbmc
- gmpc
- gmpc-plugins
- audacious
- audacity
  vlc
- recordmydesktop
- gtk-recordmydesktop
  wodim
+ xawtv-tools
+ xbmc
  youtube-dl
- darktable
 
 Task: anarcat-ham
 Section: user
 Description: Anarcat's HAM tools
  Just gpredict really.
 Packages: list
+ chirp
+ fldigi
+ gnuradio
  gpredict
+ grig
  ibp
- chirp
- owx
  multimon
- gnuradio
- uhd
+ owx
  splat
+ uhd
  xastir
- grig
- fldigi
 
 Task: anarcat-gis
 Section: user
 Description: Anarcat's GPS tools
  Not much, just viking and qlandkartegt...
 Packages: list
- qlandkartegt
- josm
  gpsbabel
+ josm
+ qlandkartegt
  stellarium

Created . Edited .