Opened 14 years ago
Last modified 14 years ago
#10159 new defect
Allow admin to prevent display of traceback on error page
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | unscheduled |
Component: | general | Version: | |
Severity: | normal | Keywords: | bitesized |
Cc: | Thijs Triemstra | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
version parameter crashes with "ValueError: invalid literal for int() with base 10"
There is a bug right about here: http://trac.edgewall.org/wiki/PluginList?version=A the version parameter is casted into int without first checking if it's isdigit().
As a bonus, causing this bug will spit out a stack trace with the software versions.
Attachments (0)
Change History (7)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Hi,
I triggered the bug in a couple of tracs in the Internets and it seems that: a) The *stack* trace is shown in all tracs. Even in trac.edgewall.org. b) The ==== System Information ==== (which is the arguably dangerous part) is *not* shown on all tracs, but it is shown on 80% of them (google some tracs and try it). Is it a misconfiguration or wrong default settings of Trac? If this is a design decision it would be good if the default behavior is to *not* show anything internal in case of an error page.
comment:3 by , 14 years ago
The stack trace isn't shown on the error page, but it is contained in the page source for creating a ticket on trac.edgewall.org, so that's not optimal. OTOH, the traceback is immensely useful to us to determine what's wrong, so I guess it's a trade-off.
Looking at the code (for 0.12), the system and plugin information should only be shown if the user has TRAC_ADMIN
permission. The traceback is available to all users, contrary to what I have written in comment:1, so some information is leaked here. The Trac instances where the system information is shown to all users are running 0.11.7 or older.
So the only real issue here is the traceback. My feeling is that the traceback adds sufficient value to the error report that we can tolerate the slight internal information disclosure. Then again, this should probably be decided by each admin. So we could add a trac.ini
setting to disable the traceback, and in that case, to prevent the semi-automatic creation of a ticket on trac.edgewall.org, as it won't have enough information for us to debug the issue.
Thoughts?
comment:4 by , 14 years ago
Hi,
oh so 0.12 should hide system/plugin information according to TRAC_ADMIN. Cool!
wrt the traceback I don't have strong opinions. It's a slight internal information disclosure that would be nice to be disable-able. I guess that an enabled-by-default-but-disableble policy would be the best, if you want to write the code ;)
Thanks!
comment:6 by , 14 years ago
Description: | modified (diff) |
---|---|
Keywords: | bitesized added |
Milestone: | → unscheduled |
Summary: | version parameter crashes with "ValueError: invalid literal for int() with base 10" → Allow admin to prevent display of traceback on error page |
Let's put it like this: I am willing to integrate a well-written patch that implements comment:3, but I won't write it myself.
Yes, we know about that, and we actually use exactly this symptom to test the error page in the functional tests. The (undocumented) policy in Trac is that you should never get a "500 Internal Error" by clicking links and submitting forms, but if you edit the URL, all bets are off.
Note that this isn't a security issue, because the stack trace is only shown if you have
TRAC_ADMIN
permission.Suggesting "wontfix". If not, then the goal of this ticket should be to go through all uses of URL parameters and check that no combination can lead to a 500, which is a lot of work, for (IMO) little gain.