trac.edgewall.org: Saving, modifying/commenting on or attaching to tickets or wiki pages often fails with various CAPTCHA errors

[Philippe Cloutier <chealer@…>]

I have been contributing to Trac’s issue tracker for 3 days, triaging and contributing about 25 modifications to various tickets. The submissions required failed in more than 5 cases, all caused by spam filtering. I was subjected to CAPTCHA tests, and I got further―definitive―failures in most (if my memory is still worth something) cases. In many cases, I went back to the form. In most cases, I managed to workaround by modifying my comment. I even ended up changing my practices to accommodate the filters. In one case, the failure was so incomprehensible that I completely gave up my modification.

Documenting everything would be long and painful, but I will mention highlights. The most recurring pattern is failure to handle comments with links. Even a link to ​Kune ni povos (my “anti-personal” website) triggered errors repeatedly, asking me to solve CAPTCHAs, only to turn into a definitive failure all or most of the time. I remember a single submission resulting in requests to solve 4 or 5 consecutive CAPTCHAs, which I all docilely solved by carefully scrutinizing and clicking for 1 minute or more, only to yield a definitive error.

When Trac struggles saving, the first error reads something like the following screenshot:

Erreur de Captcha

• URL's blacklisted by dbl.spamhaus.org (www.philippecloutier.com[255.255.254])

Trac pense que votre soumission peut être du spam. Pour montrer qu'il en est autrement, répondez au test suivant.

Je ne suis pas un robot
reCAPTCHA
Confidentialité ― Conditions

Even as a senior computer scientist, this error is unclear, but I figured out Trac meant to say my comment contained a URL which was on the Spamhaus Domain Blocklist. Yet, the only URL in this case was to Kune ni povos, which is obviously not blocklisted. Even The Register was detected as blocklisted, which I ended up working around by removing the URL and replacing it with a textual description of the article I was referring to.

Occasionally, the initial error is even more obscure, showing an empty error rectangle (again inside an otherwise empty error box), as shown in this screenshot:

Another screenshot shows the definitive failure:
The link appears to be completely unhelpful.

All of these modifications were submitted from Firefox 147.0 via IP address 167.248.175.120:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

I remember using 2 Trac instances in the past year, and only noticed these issues on this one. It is unclear which version of Trac this instance runs, and whether it is vanilla; I cannot mention any affected Trac version, nor even confirm that this is a bug in the product.

This is pretty hard to diagnose without specific testing, but from what I remember of what I experienced, I guess this is a compound from several basic issues, probably including the following:

1. Formatting bugs displaying errors
2. A bug checking whether links are legitimate
3. At least 1 more bug causing false positives
4. A failure to display the error message in certain cases
5. A bug checking whether CAPTCHAs were solved

Additions following comment:9:

6. Even fields which remain unchanged can trigger false positives.
7. The use of italics can trigger false positives.

Although I cannot test, I guess ticket #8786 correctly diagnoses most of the underlying problem, i.e.:

1. the inability to get an account
2. regulars maintaining this website presumably not being subjected to these bugs.

The most efficient solution (at least long-term) must be to solve #8786 and/or have some of the webmasters eat their own dogfood.

This report is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications are broken. Please manually notify me when you write to me or report important progress. Due to this very bug, I struggle to display my full email address or link to my contact information from this ticket, but my email address is available on ​my contact page.

This report (including all comments and attachments I add to it) is offered under the terms of CC0 1.0 (unless otherwise noted).

---

Update 1: I realized while trying to save this very ticket that the bug(s) are not specific to modifications, but also occur on creation, so I removed a link and widened the scope.
Update 2: I apologize for attaching a mislabeled screenshot​, which this website does not let me delete.
Update 3: I realized while trying to attach the last screenshot that attaching files can also cause such errors (in this case, another one with an empty error message). I therefore uploaded the last screenshot to Kune ni povos instead and am widening the scope again.

[Philippe Cloutier <chealer@…>]

Screenshot of initial failure (typical case)

[Philippe Cloutier <chealer@…>]

ACTUAL screenshot of initial failure (typical case)

[Philippe Cloutier <chealer@…>]

Screenshot of initial failure (empty case)

[Philippe Cloutier <chealer@…>]

I experienced at least 3 such sequences while filing this ticket, each consisting of an initial error immediately followed by a definitive error.

Jun Omae: I fixed the screenshots, but thank you for integrating them anyway. Do not remove text even when it is included in screenshots, since these improve accessibility (notably copy-pasting) and ticket discoverability.

I trust you that most specific issues mentioned here belong to the SpamFilter plugin, however I am not convinced that assigning this to that component alone is a good thing. Although this may report issues with Trac products affecting other websites, severity-wise, the worse problem here is that these bugs prevent or severely discourage even seasoned, diligent and determined developers from contributing to this website in its current configuration. Unless these software issues can be quickly and durably fixed, I believe the priority should be to reduce this site’s reliance on these products. Since it seems impossible to associate a ticket with multiple components, feel free to split this one.

[Dirk Stöcker]

This is not a spam-filter problem, but a problem of the Trac webpage which has awful settings. I used to care for that, but as I cannot access that page at all from most of my machines because for IP blocking I no longer do so.

The IP blocking on the other hand prevents proper data for training, so the Bayes filter is bad. Old Captcha setups, old software versions of the spam-filter, old setups for the blocklists and so on make the current setup not really usable.

I tried to tell multiple times that the situations is unacceptable, but nothing changed.

Trac Spamfilter works fine on JOSM page with about 1500 write requests a day (and 99.3% of them SPAM). No valid requests are blocked and not detected Spam is extremely seldom). All that without any additional blockings beside the spam-filter.

[Philippe Cloutier <chealer@…>]

Greetings Dirk,

Replying to Dirk Stöcker:

This is not a spam-filter problem, but a problem of the Trac webpage which has awful settings

This tracks a general issue which compounds numerous basic issues, and I am skeptical that none of these issues are issues in the spam filter. You may be right that none of these is only caused by the code of the current spam filter plugin, but there is definitely something very wrong with this website’s spam filter.

In any case, thank you very much for your work on this website and for your reply.

---

Jun Omae: Thanks again for trying to clarify/fix the screenshot references. Much of my changes to the description sent together with comment:4 were involuntary, certainly mostly caused by at least 1 bug in Trac (surely including one reported here). I am now properly fixing these (as much as I can pending a fix for this bug).

[Philippe Cloutier <chealer@…>]

I experienced this once more, this time trying to fix the title of ticket #12724 while submitting comment 10. This triggered 2 errors, with the following message:

URL's blacklisted by dbl.spamhaus.org (add[255.255.254]), dbl.spamhaus.org (joe[255.255.254])

These errors follow the pattern of errors in changes which introduce links, except:

• I was not introducing any external link.
• I was not even modifying a field which already contained a link.

I only managed to workaround by dropping my change to the title. Considering that and the message, I assume:

1. The spam filter verified the contents of the Description field, even if I was not changing it.
2. The filter has false positives caused by use of italics in "Add to CC" and "Joe Smith" (I confirmed this while submitting this comment).

Even then, I got an extra error (one more with an empty message), which thankfully I could get over by solving the CAPTCHA.

---

It would obviously be very challenging for someone without significant IT expertise to figure out the causes/workarounds for such issues. This could therefore be a major factor explaining why the number of people without an account who have (successfully?) contributed to this issue tracker over the last 12 months, despite the high importance of this project, seems to be only 4:

1. Myself
2. Chris Shelton, in ticket #13876
3. Athari, in :comment:9:ticket:13141
4. An anonymous commenter, in :comment:10:ticket:12612

1 of those (#4) did not contribute a full sentence, and 2 (myself and Athari) reported issues with the spam filter. Athari gave up on including the link he inserted.

[Philippe Cloutier <chealer@…>]

I was unable to submit nothing but the following comment to ticket #11577:

I struggle to understand your description. Does this persist with Trac 1.6? If so, please provide reproduction steps.

I got an initial failure with an empty error message, solved the CAPTCHA, got a definitive failure with the same empty message, then went back to the form, retried and got an immediate definitive failure.

I do not know what exactly "highest" means and which other issues Trac has, but this should possibly be treated at highest priority.

[Philippe Cloutier <chealer@…>]

I'm sorry to report this even affects wiki pages. I gave up on my first attempt to edit a wiki page on this site, TracWiki, after it resulted in a sequence of 2 errors:

URL's blacklisted by dbl.spamhaus.org (universaleditbutton.org[255.255.254]), dbl.spamhaus.org (wikipedia.org[255.255.254])

This happened even though my edit does not introduce any link (in fact, it merely removes 1).

[Jun Omae]

Occasionally, the initial error is even more obscure, showing an empty error rectangle (again inside an otherwise empty error box), as shown in this screenshot:

When the submission doesn't meet the minimum karma and scores of all spam filters are positive, the message will be empty.

[pid 28370 140574186743552] 2026-02-28 07:54:16,104 Trac[main]
 WARNING: [60.114.142.152] HTTPInternalServerError: 500 Submission rejected as potential spam
 (<div class="message"><ul></ul></div>), <RequestWithSession "POST '/newticket'">,
 referrer 'https://trac.edgewall.org/newticket'

Proposed fix:

tracspamfilter/filtersystem.py

@@ -341 +341 @@
                            'earned only %d karma points (%d are required).',
                            abbrev, author, req.remote_addr, score,
                            self.min_karma)
-            rejects = []
-            out_reasons.sort()
-            for r in out_reasons:
-                rejects.append(tag.li(r))
-            msg = tag.div(tag.ul(rejects), class_='message')
+            if out_reasons:
+                rejects = []
+                out_reasons.sort()
+                for r in out_reasons:
+                    rejects.append(tag.li(r))
+                msg = tag.div(tag.ul(rejects), class_='message')
+            else:
+                msg = tag.div(
+                        tag.p("Your submission doesn't meet the minimum karma."),
+                        class_='message')
 
             self.reject_handler.reject_content(req, msg)
 

[Philippe Cloutier <chealer@…>]

Thank you Jun

Having any message is certainly better than nothing, but this one is effectively meaningless to the user (without a link explaining what "the minimum karma" means or complementary information).

Also, it is not correct to assign this whole ticket to the SpamFilter plugin. It is true that this specific bug is in that plugin, but there are other basic issues which must not be in the plugin, and in any case, fixing the plugin alone will not suffice.

[Dirk Stöcker]

Message fixed in r17925.

[Jun Omae]

2. The filter has false positives caused by use of italics in "Add to CC" and "Joe Smith" (I confirmed this while submitting this comment).

It seems to be caused by an issue of spam-filter at plugins/trunk/spam-filter/tracspamfilter/filters/url_blacklist.py@:116#L109​ (e.g. ... //add ... in a comment can trigger the issue).

Workaround is to use '' instead of // for italic-style.

[Jun Omae]

URLBlacklistFilterStrategy is temporarily disabled.

[Philippe Cloutier <chealer@…>]

Thank you very much Dirk and Jan

I agree with Jan that _geturls() appears broken. I do not understand the comment and my Python is bad, but I am confident that:

1. It returns false positives (non-URLs), like //Comment.
2. It fails to return URLs (like file:/etc/issue).
3. It logs a warning for perfectly normal URLs (like http://debian.org).
4. Even if a warning is logged for an actual URL, what it logs is incomplete (only part of the URL).

Submissions with phrases in italics should log a warning, so the logs should have a confirmation that this is what caused some of my errors (like the one with //Add to CC//).

[Jun Omae]

Replying to Philippe Cloutier <chealer@…>:

Thank you very much Dirk and Jan

(My name is Jun, not Jan…)

[Philippe Cloutier <chealer@…>]

My previous comment addressed Jun Omae. Jun, please accept my apologies for misnaming you.

[Jun Omae]

This is pretty hard to diagnose without specific testing, but from what I remember of what I experienced, I guess this is a compound from several basic issues, probably including the following:

1. Formatting bugs displaying errors
2. A bug checking whether links are legitimate

Please create new ticket with defect for spam-filter plugin.

4. A failure to display the error message in certain cases

Fixed in r17925 for Trac 1.6, however this instance is running with Trac 1.4, so not fixed yet here.

5. A bug checking whether CAPTCHAs were solved

Please create new ticket with enhancement for CAPTCHAs feature of spam-filter plugin (It's hard to tell from the display whether the user solves the CAPTCHAs, but I don't think it's a defect).

7. The use of italics can trigger false positives.

Please create new ticket with defect for URLBlackList of spam-filter plugin (see also comment:16).

[Philippe Cloutier <chealer@…>]

Replying to Jun Omae:

Replying to Philippe Cloutier <chealer@…>:

Thank you very much Dirk and Jan

(My name is Jun, not Jan…)

Right, thanks anyway. Again, I apologize and ask for your pardon.

I updated the description trying to use the screenshot I had to upload to my website, but for some reason, the Image macro is showing a link rather than displaying the image.

I confirm that I am now able to add links in ticket descriptions; thanks again Jun.

[Jun Omae]

Again, I apologize and ask for your pardon.

Of course, I accept your apology. No problem at all — unfamiliar names can be tricky.

[Philippe Cloutier <chealer@…>]

Thank you Jun. Indeed, in particular when they look like a more familiar one!

---

I recommend replacing _geturls() with a library call, or at least rewriting it based on an established algorithm/regex.

[Dirk Stöcker]

I agree with Jan that _geturls() appears broken. I do not understand the comment and my Python is bad, but I am confident that:

1. It returns false positives (non-URLs), like //Comment.

//Comment is a valid URL.

3. It logs a warning for perfectly normal URLs (like http://debian.org).

I think the main problem here is again settings. The previous default URL blacklists got out of service and return true for all calls to enforce fixing configs. Without a configuration update the strategy is thus unusable. Copying the defaults of the most recent version will help.

[Philippe Cloutier <chealer@…>]

Replying to Dirk Stöcker:

I agree with Jan that _geturls() appears broken. I do not understand the comment and my Python is bad, but I am confident that:

1. It returns false positives (non-URLs), like //Comment.

//Comment is a valid URL.

It’s a valid hier-part, but a hier-part alone is not a URL. To clarify, I was using "URL" in its strict sense (excluding so-called “relative URLs”).

3. It logs a warning for perfectly normal URLs (like http://debian.org).

I think the main problem here is again settings. The previous default URL blacklists got out of service and return true for all calls to enforce fixing configs. Without a configuration update the strategy is thus unusable.

Wow… thank you very much for that information Dirk

That being said, I fail to see what this has to do with #3. #3 is not about being suspicious, but about being “strange”. And neither http://debian.org nor http://trac.edgewall.org have anything strange (even if the domains were to be hijacked).

[Philippe Cloutier <chealer@…>]

Replying to Philippe Cloutier <chealer@…>:

I recommend replacing _geturls() with a library call, or at least rewriting it based on an established algorithm/regex.

I suppose using a library is non-trivial because of Trac markup. A pure parser (as requested in ticket #4431) would make it simple to use generic code (if the parser doesn't provide that itself).