]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn
Merge branch 'master' of ssh://ikiwiki.branchable.com
[ikiwiki.git] / doc / bugs / notifyemail_fails_with_some_openid_providers.mdwn
index 90e2c790065ff11ccb5f54ccb37f8639998daa64..c4542c8d02357952b1eea3f7c45b287a0f263ae9 100644 (file)
@@ -65,3 +65,33 @@ It would probably be better to add a comment on the field as indicated above, bu
 Any other ideas? --[[anarcat]]
 
 > Note: it seems that my email *is* given by my OpenID provider, no idea why this is not working, but the fix proposed in my branch works. --[[anarcat]]
+
+>> Note: this is one of two patches i need to apply at every upgrade. The other being [[can__39__t_upload_a_simple_png_image:_prohibited_by_allowed__95__attachments___40__file_MIME_type_is_application__47__octet-stream...]]. --[[anarcat]]
+
+>>> Is there any sort of check that the owner of the given email address
+>>> wants to receive email from us, or way for the owner of that email
+>>> address to stop getting the emails?
+>>>
+>>> With passwordauth, if someone maliciously subscribes my email
+>>> address to high-traffic pages or something (by using it as the
+>>> email address of their wiki login), I can at least use
+>>> password-recovery to hijack their account and unsubscribe myself.
+>>> If they're signing in with an OpenID not associated with my
+>>> email address and then changing the email address in the userdb
+>>> to point to me, I don't think I can do that.
+>>>
+>>> With OpenID, I think we're just trusting that the OpenID provider
+>>> wouldn't give us an unverified email address, which also seems
+>>> a little unwise.
+>>>
+>>> It might be better to give ikiwiki a concept of verifying an
+>>> email address (the usual send-magic-token flow) and only be
+>>> willing to send notifications to a verified address?
+>>>
+>>> --[[smcv]]
+>>>
+>>>> hmm... true, that is a problem, especially for hostile wikis. but then any hostile site could send you such garbage - they would be spammers then. otherwise, you could ask the site manager to disable that account...
+>>>>
+>>>> this doesn't seem to be a very big security issue that would merit implementing a new verification mechanism, especially since we don't verify email addresses on accounts right now. what we could do however is allow password authentication on openid accounts, and allow those users to actually change settings like their email addresses. however, I don't think this should be blocking that functionality right now. --[[anarcat]]
+>>>>
+>>>> besides, the patch I am proposing doesn't make the vulnerability worse at all, it exists right now without the patch. my patch only allows users that **don't** have an email set (likely because their openid provider is more discreet) to set one... --[[anarcat]]