Allow to disable "Edit own comments" to limit Spam in large public trac

[matt@…]

Users are able to edit comments, and there is no email notification to let the admin know, a comment was edited. This can cause a lot of hidden spam in large public trac instances.

Proposals for a fix:

• Please add a new Permission TICKET_COMMENT_EDIT
• Set by default to logged in users for new Trac installs & possibly update
• We will disable it for our trac instance
• (optional but would be very nice) Add setting to enable email notifications on comment edits.

Rationale

We take great pride in keeping our Trac clean, free of spam, and high quality bug descriptions, comments, and community. New comments sent email notifications. We can verify each email from trac, and see if users added links in the content. This way we edit the comments, or delete the tickets, that are spammy.

However, email notifications are not sent when users edit their comments. Therefore, users can create a legit comment (or copy paste a previous comment which we wouldnt notice), then update it to add spam links in it.

we have already noticed one link added this way to a dodgy site.

Use case

I manage a large fully publicly available Trac instances, 3500 tickets some with hundreds of comments, for a major open source project. We were using an old version of Trac. we have updated to 1.0 and now use DB rather than sqlite which helps with performance and stability. Some of our tickets contain original research and a lot of interesting information, are linked from other websites etc. as a result, we also have a huge amount of spam of links from the trac to benefit from the SEO.

Thank you for your consideration of this and to release a new version. Thanks for Trac it's an amazing tool !!

[anonymous]

Reassigning to correct milestone.

[Christian Boos]

See TracPermissions#TicketSystem, there is nearly exactly what you requested there (TICKET_EDIT_COMMENT).

Keeping open for the notification idea, though not for 1.0.

[anonymous]

Thanks for the link, however I do not see TICKET_EDIT_COMMENT listed in Administration > Permissions, so it is not set.

It is not set, still authenticated users can edit their comments.

authenticated users have the following: TICKET_APPEND, TICKET_CREATE, TICKET_EDIT_CC

Do any of these ones include TICKET_EDIT_COMMENT ?

How should I configure to prevent authenticated users from edit comments?

Thanks!

[anonymous]

Note: I also tried, adding the permission and then deleting it, but same result, authenticated user could still edit comment.

[Christian Boos]

No, TICKET_EDIT_COMMENT is only granted as part of TICKET_ADMIN, otherwise it needs to be set specifically… You haven't given TICKET_ADMIN by any chance?

[anonymous]

To be exact I have the following set (only authenticated users can do things)

• '*' TICKET_CREATE TICKET_VIEW
• 'anonymous' BROWSER_VIEW CHANGESET_VIEW FILE_VIEW INCLUDE_URL LOG_VIEW MILESTONE_VIEW REPORT_SQL_VIEW REPORT_VIEW ROADMAP_VIEW SEARCH_VIEW TICKET_VIEW TIMELINE_VIEW WIKI_VIEW
• 'authenticated' TICKET_APPEND TICKET_CREATE TICKET_EDIT_CC

Is this a bug that it's enable by default when not explicitely specified, ie. it does not work? ;-)

[Christian Boos]

You're right, it's TICKET_EDIT_CC … Forgot to log out after having added it as admin ;-)

[Christian Boos]

Well, on demo-1.0, anonymous has TICKET_APPEND TICKET_CREATE TICKET_EDIT_CC TICKET_EDIT_DESCRIPTION TICKET_MODIFY TICKET_VIEW and no "Edit" comment button…

[anonymous]

because I guess it does not work for anonymous, since there's no way to know which anonymous, after the fact.

I deleted TICKET_EDIT_CC but still appears, so it looks like a bug?

[Christian Boos]

Ah, yes! It's by design, the "edit own comments" feature. I focused on the permission name and didn't even see that in the code (one line above…).

Well, I think we could make use of a [trac] trust_authenticated setting, then. It could be used in similar situation when we normally assume that authenticated users will do reasonable things with their own content (deleting their own attachments, etc.).

[anonymous]

I dont understand about the new setting. I think maybe the TICKET_EDIT_COMMENT should be changed so that, when it is not set, users do not have the permission to edit comments? To prevent problems, it could automatically set by default on updates from previous versions to 1.0.1 ?

Would it be possible to move this ticket be back to 1.0 roadmap, as it has security / spam implications? Thanks so much for your help!

[Christian Boos]

The proposed setting is a generalization of the SpamFilter "trust authenticated users" setting ( [spam-filter] trust_authenticated), which allow authenticated users to by-pass the spam filtering entirely.

And speaking about the SpamFilter, that's the other important issue here, it looks like the edited comment is not submitted to the spam filter at all…

So yes, I agree we need to do something about this in 1.0-stable.

[anonymous]

Well, I think we could make use of a [trac] trust_authenticated setting, then. It could be used in similar situation when we normally assume that authenticated users will do reasonable things with their own content (deleting their own attachments, etc.).

Can you please explain what you meant in this comment. When the setting will enabled what will happen?

Thanks for pushing to 1.0! :) looking forward to the new release!

[Remy Blank]

FTR, this was discussed starting with comment:165:ticket:454 and decided in comment:176:ticket:454.

Replying to cboos:

Well, I think we could make use of a [trac] trust_authenticated setting, then. It could be used in similar situation when we normally assume that authenticated users will do reasonable things with their own content (deleting their own attachments, etc.).

I don't like the idea of changing the scope of permissions with config options. Permissions should have a fixed meaning, independent of other configuration. I know you were against it in #454, but I would prefer introducing TICKET_EDIT_OWN_COMMENT for this case. Sure, a more flexible permission system like you described in that comment would be great, but it's not going to happen anytime soon, and in the meantime a new permission feels like the cleanest solution.

(BTW, aren't we missing a check for TICKET_APPEND for authenticated users? In the current state, authenticated users can edit their own comments even if they only have TICKET_VIEW. This feels wrong.)

[matt@…]

Would it be possible to disable the ability to edit comments? How can we prevent spammers from editing comment and adding spam? it is not possible to monitor those edits so we need to disable the ability. please help, thanks so much!

[Remy Blank]

You can simply remove the TICKET_EDIT_COMMENT permission. But please ask such questions on the MailingList or IrcChannel. Thank you.

[anonymous]

No I cant simply remove TICKET_EDIT_COMMENT because it is not set already. The bug is that, this permission is not set and yet users can edit their own comments ! See comment in this ticket: #comment:10

I don't understand why this bug is not acknowledged or taken seriously. We have no solution at this stage. It would be so easy for anyone to write a bot spamming thousands of comments (ie. create real comments then edit their comment and add spam links). I hope we're not waiting for someone to write such bot and spam public trac instances before it's being taken seriously?

Summary: this is a security issue as well as a generic bug. Thanks so much for your help!

[Remy Blank]

Replying to anonymous:

No I cant simply remove TICKET_EDIT_COMMENT because it is not set already.

Oh, right, TICKET_EDIT_COMMENT is to allow editing all comments. Well, as mentioned in comment:14, I would accept a patch adding the TICKET_EDIT_OWN_COMMENT permission and using it in the right locations, so that comment editing can be disabled completely. I think it's much better than the option suggested in comment:12, because it allows finer-grained control over whom is allowed to edit comments, no only "all authenticated users".

[matt@…]

we'd be happy to make a small donation by paypal for such patch + instructions on how to apply :-) thanks so much!

[btjanes@…]

Added, this is much needed.

[Ryan J Ollos]

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

[Ryan J Ollos]

See #11425 for showing ticket comment edit events in timeline.

See #12719 for possible solution to this ticket.

[Ryan J Ollos]

Closing this as a duplicate of #12719, which barring any problems I'll commit in 1.3.x.

Replying to Remy Blank:

(BTW, aren't we missing a check for TICKET_APPEND for authenticated users? In the current state, authenticated users can edit their own comments even if they only have TICKET_VIEW. This feels wrong.)

This has been addressed in the proposed changes for #12719.

[Ryan J Ollos]

Replying to Christian Boos:

And speaking about the SpamFilter, that's the other important issue here, it looks like the edited comment is not submitted to the spam filter at all…

Reported in #12722.