Sean Kelly and I have been investigating the state of the plone.org
LDAP database, and we have some recommendations to bounce off of the
We have about 58k accounts in the plone.org LDAP system, which
backends authentication for plone.org, dev.plone.org (trac) and is
synced to github. The vast, vast majority of these accounts (all but
about 2000) are pretty obviously bogus/spam accounts, and most of
these (but not all) were created back in the days when we had a
vulnerability (now closed) related to member portraits, which made it
worthwhile to try to create bogus user accounts for SEO spamming.
Sean and I believe we can easily nuke all of these accounts with
minimal collateral damage to legit accounts by removing all accounts
that are NOT members of a plone.org LDAP group (e.g. committers,
collective committers, etc.) AND also have not ever created a record
in the Trac database (e.g. a bug report or a comment) AND don't own an
item in http://plone.org/support/sites or
Can anybody think of a class of legitimate accounts that would be
excluded by the above logic?
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Plone-developers mailing list
On Wed, Mar 21, 2012 at 3:20 PM, William Deegan
> Perhaps generate the list of accounts and let people raise their hands if any should be kept?
On Thu, Mar 22, 2012 at 12:32 AM, Anthony Gerrard
> I'm sure we have but just in case please ensure you have a tested
> backup / restore procedure in place.
> On 21 March 2012 22:44, Laurence Rowe <l...@lrowe.co.uk> wrote:
>> To be completely sure you might need to look at all local role
>> assignments as well, if a user has none then they can just recreate
>> their account if needs be.
>> Another way might be to cross-check against login_time /
>> last_login_time (I forget which is updated)? And decide that any
>> account that has not logged in recently but would otherwise be removed
>> would become fair game. If people want to keep their accounts they can
>> just log in to plone.org. (This info is in portal_memberdata rather
>> than in ldap.)