On 13 February 2013 22:32, Giovanni Bajo <[email protected]> wrote:
> Il giorno 13/feb/2013, alle ore 12:14, Richard Jones <[email protected]> ha
> scritto:
>>
>> 2. fix the email password reset debacle (mostly written, not tested),
>
> Is this committed anywhere I can take a look?
It will be presently. In short, the old procedure was:
1. user enters username in form and is emailed a link back to PyPI
which embeds the username and password,
2. user clicks link and, on receiving both username and email address
a new password is generated and mailed to the email address.
If the user knows both the username and email address they can skip
straight to step 2.
The new scheme involves:
1. user enters username in "I've forgotten my password" form,
2. PyPI emails user with a link back to itself with a reset OTK (32
random chars from letters+digits) valid for 6 hours,
3. On clicking the link the user sees a password reset form where they
enter their new password, and
4. On submitting the reset form the OTK is deleted and password changed.
If an invalid username is entered PyPI will say so: the set of pypi
usernames is public anyway through APIs and general web scraping and
this behaviour is more user-friendly than the more common "I may or
may not have emailed you a reset email."
>> 5. add automated email sent to package role holders (maintainers and
>> owners) when their package is updated in any way.
>
> In my doc (task #12) I propose using a separate per-package security email,
> and in fact I was also proposing to ask confirmation by email, rather than
> just notify it.
I think it's reasonable for my initial implementation to just email
the maintainers to notify them, given that "updated in any way" would
include publication of releases or editing of release information.
> Basically, PyPI would warn the maintainer that the requested action is a
> security change for the package, and it needs to be confirmed through a link
> sent to the security email. A security email would be an email associated to
> each package, that must be different from the maintainer email (possibly even
> a different domain, in fact, though I'm not sure we want to enforce it rather
> than just suggest it). The email text must say "user X has requested change Y
> to package Z. If you are user X, click here to approve it". Only the
> maintainer that originated the change request can approve it through the
> link. The email can be an alias that forwards it to different maintainers,
> though.
Would that workflow apply for a release? Seems quite burdensome.
Requiring users to have different email addresses for the two is quite
unrealistic.
Richard
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
