trac.edgewall.org: Saving, modifying/commenting on or attaching to tickets 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 (first 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 the second screenshot​.

The third 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

I am filing this against the ITS component, but I did not test TracWiki, and according to ticket #8786, the same general problem affects it. 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 comment is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications seem to be broken, and I struggle to display my full email address or link to my contact information from this comment. My email address is available on Kune ni povos’s contact page.

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

---

Update: 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 first screenshot, Trac website―Initial failure.png​ , which this website does not let me delete.
Update 3: I realized while trying to attach the last (third) screenshot that attaching files can also cause such errors (in this case, another one with an empty error message). I therefore uploaded the third screenshot to Kune ni povos instead, as file #160 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.