> > > We can use all the below ideas to fix this security bug: > > > > > > * The protocol you have proposed at > > > > > >
http://lists.gnu.org/archive/html/gnuherds-app-dev/2007-04/msg00155.html > > > > > > * The new E1_Entities field > > > E1_LastTimeStamp > > > > > > * At the registration and email modification processes we will send a
> > > "validation link" to the email before accepting the user request. > > > > > > If it is needed, we must follow talking about it. > > > > > > If you agree, I will carry out this task:
> > > Task: https://savannah.nongnu.org/task/index.php?6786 > > > > I think I do, but I just have to make sure we're talking about the same
> > thing. The bug report didn't really have much information, so I'll just > > summarize. There are several bugs in question: > > If you are going to develop the bug fix, please do not commit it. First
> send it to the list.
I probably won't have time.
> > - It is possible to submit a wrong email address at Person.php. This > > is a privacy issue (since the erroneous email may belong to someone else),
> > and a safety issue, since the user will be unable to receive a password > > retrieval email. > > We can not avoid the privacy issue, due to it is the fault of the user who > fill erroneously the email field.
> > I think there is not "safety issue". The user just not receive the email.
Which means they'll have to register again with a different email, if they ever forget their password. That's not user friendly.
> The fact that this email was used in an attempt to register twice will > be reported only in the email sent, to avoid the bug we are talking about. > No at the web page.
OK, even better!
> So, you can develop this bug fix, and send to the list your result, so as > to all we can fix or improve it. Along you develop it, we must follow > improving the proposed solution.
I don't think I'll have the time shortly, but I'll keep it in mind.
-- Victor Engmark Quidquid latine dictum sit, altum videtur - What is said in Latin, sounds profound