how the WMF announced , the password-hashes and email addresses of
many users were public accessible in WikiLabs (and so ToolLabs) for 6
So please make sure that you and your bots get a new password as soon as
possible! A well known bot in the wrong hands is dangerous, so change
the password now – don’t wait if you get a mail by the WMF (I got none,
but be affected AFAIS).
Am 04.10.2013 21:59, schrieb Marc A. Pelletier:
> so I guess it ended up in your spam trap or something?
no, and that’s for a simple reason: The eMail-address is invalid and
bounces (just re-tried for myself) – gmx decided somewhen last year that
this syntax is invalid (what is correct, but they didn’t care for years)
and does not longer accept mails for it.
Now two question: Why does WMF didn’t notice the bounce and why did WMF
not use my SUL-mail-address? And following question 1: How many other
bounces happened without notice?
And yes, I accept your apology. I also overreacted a bit, I’m sorry too.
BTW: While I have a PGP-key for that mail-address I did not use it for
Re: [Toolserver-announce] Security issue in Wikipedia projects
On 10/04/2013 05:34 PM, DaB. wrote:
> Now two question: Why does WMF didn’t notice the bounce and why did WMF
> not use my SUL-mail-address? And following question 1: How many other
> bounces happened without notice?
Your second question is easy: the mail was sent to the email address
associated with the exposed account. I expect you have that email
address still on the project that was on the list, so this is where the
email was sent.
For your first question: we would notice mail being rejected by the MTA,
but not a bounce that came in after the fact. gmx.de did accept the
mail for delivery, but sent a bounce asynchronously. Since the from: of
the email points to OTRS, and OTRS rejects bounces to avoid starting
bounce loops, it got lost.
Sadly, we were under severe time pressure to warn as many users as
possible as quickly as possible, and it was not practical to construct a
mail system that was robust enough to handle edge cases. Since there
was a second layer of protection (ending sessions and forcing password
changes) that would come into play even for editors that had invalid or
no email set, this was viewed as the right compromise to avoid delaying
warning users by days.
It's of course preferable if editors get the email before they wonder
why their session timed out (because, as you yourself experienced, it's
a little confusing to end up being forced to change your password
without warning) -- but safeguarding the security of users quickly has