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 b4a3604ea602896c2b6db9d1a258268b4e25815c..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


@@ -90,3 +102,11 @@ of) that step to Mozilla.
 Thoughts?
 
 --[[smcv]]
 Thoughts?
 
 --[[smcv]]

+
+> I always find it a little ackward that i have two different accounts on this wiki: one for OpenID, and the other (regular account) for email notifications (because of [[bugs/notifyemail_fails_with_some_openid_providers/]]). It seems to me those accounts should just be merged as one, ie. I was expecting to be able to choose a username when i registered with openid.
+> 
+> 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 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]]