Exclude working directory from library path (CVE-2016-1238)

[git.ikiwiki.info.git] / doc / todo / separate_authentication_from_authorization.mdwn

diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn
index de7c5b7631314bd49891f8b4313cf11be6f8039d..1eca0dced15a672e6a6b09acd29b29d56c707c60 100644 (file)
--- a/doc/todo/separate_authentication_from_authorization.mdwn
+++ b/doc/todo/separate_authentication_from_authorization.mdwn
@@ -12,6 +12,11 @@ owner (and maybe their outsourced service providers), but not available
 to random third parties. The principle of least astonishment would suggest
 that we should do the same here.
 
+> This part is now addressed by cloaking email addresses:
+> `smcv@debian.org` → `smcv@02f3eecb59311fc89970578832b63d57a071579e`
+> (that's the sha1sum of `mailto:smcv@debian.org`, as used in FOAF).
+> --[[smcv]]
+
 (The expectation of privacy for direct git commits is rather different:
 I think we can expect direct git committers to know that they
 should either set a plausible non-email-address in their git identity,
@@ -35,6 +40,13 @@ Here is a sketch of a different account model that would address that:
     users with / in their names, which would make their user-page into a
     subpage?
 
+    > I have fixed passwordauth to not let urls be registered. It seems this
+    > was not quite a security hole; it didn't let registering a username that
+    > already existed, so if an openid was an admin, as long as the user logged
+    > in using that openid, someone else couldn't come along and passwordauth
+    > collide with it. (Might be exploitable if you could guess an openid that
+    > was going to be added as an admin later though.) --[[Joey]]
+
 * If passwordauth is enabled, accounts may have a password. Users can
   authenticate to an account that has a password by entering that password.
   The username is always the account name (because there's little reason
@@ -95,12 +107,6 @@ Thoughts?
 > 
 > Also, when you talk about "separating authentication from authorization", i immediately thought of [[todo/ACL/]] and [[todo/Zoned_ikiwiki/]], so i thought i could mention those... having stability in the usernames would help in the design of those... --[[anarcat]]
 
-> I'm not against this, but I don't anticipate having resources to do any
-> work on it either. --[[Joey]]
-
-> I have fixed passwordauth to not let urls be registered. It seems this
-> was not quite a security hole; it didn't let registering a name that
-> already existed, so if an openid was an admin, as long as the user logged
-> in using that openid, someone else couldn't come along and passwordauth
-> collide with it. (Might be exploitable if you could guess an openid that
-> was going to be added as an admin though.) --[[Joey]]
+> I'm not opposed to this, but I don't anticipate having resources to do any
+> work on it either. (I do hope to obscure email addresses from git
+> commits.) --[[Joey]]