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.
 
 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,
 (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?
 
     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
 * 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]]
 
 > 
 > 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]]