Hi all,
as promised, I tracked down the problem with translations:
Umlauts and accents and Russian characters were displayed as
two Unicode symbols each.
In lib/RT/Interface/Web.pm, I had to change the Mason encoding:
In NewApacheHandler and NewCGIHandler, the correct value is:
default_escape_flags => ‘n’,
otherwise it presents all non-ascii symbols as HTML entities, and that’s
bad for many languages.
In addition, in many Mason templates, this escaping is already turned off
for some hidden reasons, like this here:
share/html/Elements/TitleBoxStart: <%$titleright ? $titleright :
’ ’ |n %>
In lib/RT/I18N.pm, the procedure “encoding” referenced $self as an object reference,
but in fact it was a class name. Here’s the corrected version:
sub encoding {
my $class = shift;
my $self = {};
bless $self, $class;
With these fixups, the web interface works like charm, though some
words miss translations (I hope they will be updated before the 3.0 release).
I tested German, French, and Russian. I didn’t test the email interface.
Now the language is determined from the browser preferences.
It would be nice to have the menu for chosing the language,
both before logging in and after that.
Cheers,
Stan
Stan,
Your first change opens RT up to a cross-site scripting attack, as I
mentioned in January:
http://lists.fsck.com/pipermail/rt-devel/2003-January/002943.html
I suspect that what you really want is to tell mason to a different sort
of html escaping, rather than none. I’ll have a look at the fix to
encoding {}
-jOn Fri, Feb 28, 2003 at 07:42:52AM -0800, Stanislav Sinyagin wrote:
Hi all,
as promised, I tracked down the problem with translations:
Umlauts and accents and Russian characters were displayed as
two Unicode symbols each.
In lib/RT/Interface/Web.pm, I had to change the Mason encoding:
In NewApacheHandler and NewCGIHandler, the correct value is:
default_escape_flags => ‘n’,
otherwise it presents all non-ascii symbols as HTML entities, and that’s
bad for many languages.
In addition, in many Mason templates, this escaping is already turned off
for some hidden reasons, like this here:
share/html/Elements/TitleBoxStart: <%$titleright ? $titleright :
’ ’ |n %>
In lib/RT/I18N.pm, the procedure “encoding” referenced $self as an object reference,
but in fact it was a class name. Here’s the corrected version:
sub encoding {
my $class = shift;
my $self = {};
bless $self, $class;
With these fixups, the web interface works like charm, though some
words miss translations (I hope they will be updated before the 3.0 release).
I tested German, French, and Russian. I didn’t test the email interface.
Now the language is determined from the browser preferences.
It would be nice to have the menu for chosing the language,
both before logging in and after that.
Cheers,
Stan
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Stan,
Your first change opens RT up to a cross-site scripting attack, as I
mentioned in January:
http://lists.fsck.com/pipermail/rt-devel/2003-January/002943.html
I suspect that what you really want is to tell mason to a different sort
of html escaping, rather than none. I’ll have a look at the fix to
encoding {}
I’ll take a closer look. Can you give some examples of dangerous code
when not escaping?
Hi all,
as promised, I tracked down the problem with translations:
Umlauts and accents and Russian characters were displayed as
two Unicode symbols each.
In lib/RT/I18N.pm, the procedure “encoding” referenced $self as an object reference,
but in fact it was a class name. Here’s the corrected version:
Actually, it was the single caller that was calling this incorrectly. I
corrected the calling routine instead.
With these fixups, the web interface works like charm, though some
words miss translations (I hope they will be updated before the 3.0 release).
I tested German, French, and Russian. I didn’t test the email interface.
Feel free to contribute updates where you see them (this goes for
everybody)
Now the language is determined from the browser preferences.
It would be nice to have the menu for chosing the language,
both before logging in and after that.
Eventually, that would be ncie, yes. but it will not happen for 3.0,
which is currently scheduled for two weeks from tomorrow.
Cheers,
Stan
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
http://www.cgisecurity.com/articles/xss-faq.shtml is the faq you want to
read. And change #253 (what will be 2.1.77) is the change in RT where I
finished implementing the fix. your bug report about the encoding sub
was the key to the solution. thanks.
-jOn Fri, Feb 28, 2003 at 11:58:20AM -0800, Stanislav Sinyagin wrote:
— Jesse Vincent jesse@bestpractical.com wrote:
Stan,
Your first change opens RT up to a cross-site scripting attack, as I
mentioned in January:
http://lists.fsck.com/pipermail/rt-devel/2003-January/002943.html
I suspect that what you really want is to tell mason to a different sort
of html escaping, rather than none. I’ll have a look at the fix to
encoding {}
I’ll take a closer look. Can you give some examples of dangerous code
when not escaping?
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
http://www.cgisecurity.com/articles/xss-faq.shtml is the faq you want to
read. And change #253 (what will be 2.1.77) is the change in RT where I
finished implementing the fix. your bug report about the encoding sub
was the key to the solution. thanks.
so, only special characters need escaping, like < and >, and maybe few more.
I’ll try and write the Mason escape handler for that on Monday… if
nothing more urgent happens…
Nice weekend,
Stan
http://www.cgisecurity.com/articles/xss-faq.shtml is the faq you want to
read. And change #253 (what will be 2.1.77) is the change in RT where I
finished implementing the fix. your bug report about the encoding sub
was the key to the solution. thanks.
You sure you didn’t introduce a bug here Jesse?
I moved from 2.1.75 to 2.1.77 today and got this:
[Sat Mar 1 07:40:42 2003] [warn] FastCGI: server “/www/bugs.tendra.org/rt/bin/mason_handler.fcgi” restarted (pid 18736)
Insecure dependency in require while running setgid at /www/bugs.tendra.org/rt3/
lib/RT/I18N.pm line 81.
Compilation failed in require at /www/bugs.tendra.org/rt/bin/mason_handler.fcgi line 29.
[Sat Mar 1 07:40:44 2003] [warn] FastCGI: server “/www/bugs.tendra.org/rt/bin/mason_handler.fcgi” (pid 18736) terminated by calling exit with status ‘255’
This is with perl 5.8.0 on FreeBSD 4.8-STABLE.
The code in question is (diff between .75 and .77):
sub Init {
-
Load language-specific functions
- require $_ for glob(substr(FILE, 0, -3) . “/*.pm”);
Acquire all .po files and iterate them into lexicons
Removing this from I18N.pm allows me to continue, since it considers the
glob() to be tainted due to rt being setgid().
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / a capoeirista
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
I am the impossibility…
http://www.cgisecurity.com/articles/xss-faq.shtml is the faq you want to
read. And change #253 (what will be 2.1.77) is the change in RT where I
finished implementing the fix. your bug report about the encoding sub
was the key to the solution. thanks.
You sure you didn’t introduce a bug here Jesse?
Introduce, no. Unmask, yes. The answer is not to just delete that code,
as it actually matters. Instead, 2.1.78 tests and untaints the data, if
it’s safe.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Introduce, no. Unmask, yes. The answer is not to just delete that code,
as it actually matters. Instead, 2.1.78 tests and untaints the data, if
it’s safe.
Cool, thanks. 
Works as it should now.
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / a capoeirista
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
E pluribus unum…
I checked quickly German and Russian interfaces,
all look smooth. I didn’t yet test it with non-ASCII characters in the message
body. Looks like it will need the special Mason entity handler anyway…
Stan— Jeroen Ruigrok/asmodai asmodai@wxs.nl wrote:
-On [20030302 22:03], Jesse Vincent (jesse@bestpractical.com) wrote:
Introduce, no. Unmask, yes. The answer is not to just delete that code,
as it actually matters. Instead, 2.1.78 tests and untaints the data, if
it’s safe.
Cool, thanks.
Works as it should now.