Bug 500736 - \n characters are being incorrectly escaped on profile review form
\n characters are being incorrectly escaped on profile review form
Product: Dogtag Certificate System
Classification: Community
Component: CA (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Ade Lee
Chandrasekar Kannan
Depends On:
Blocks: 443788
  Show dependency treegraph
Reported: 2009-05-13 17:00 EDT by Ade Lee
Modified: 2015-01-05 20:16 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-22 19:35:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to fix (774 bytes, patch)
2009-05-13 17:07 EDT, Ade Lee
no flags Details | Diff

  None (edit)
Description Ade Lee 2009-05-13 17:00:32 EDT
Description of problem:
The fix for Bug 223353 allowed users to escape special characters like commas and quotes in the input and allow those to be displayed in all forms, and be added to the certificate.

In particular, the fix changed the following function:

    protected String escapeJavaScriptString(String v) {
        int l = v.length();
        char in[] = new char[l];
        char out[] = new char[l * 2];
        int j = 0;

        v.getChars(0, l, in, 0);

        for (int i = 0; i < l; i++) {
            char c = in[i];

            /* presumably this gives better performance */
            if ((c > 0x23) && (c != 0x5c)) {
                out[j++] = c;
            switch (c) {
            case '\n':
                out[j++] = '\\';
                out[j++] = 'n';

            case '\\':
                out[j++] = '\\';
                out[j++] = '\\';

Prior to this fix, the line :
    if ((c > 0x23) && (c != 0x5c)) {

used to say: if (c > 0x23) {

This resulted in (0x5c) "\" characters not being escaped - which was bad because we needed to include escaped \ characters.

The problem is that there are some profile inputs -- the Key and KeyId, in particular, which included the characters '\' and 'n' in their string, rather than the correct character '\n'.  In the  new code, this would be expressed as
"\\n" - rather than "\n" - which would be treated as a newline.

The result would be that the display would be too wide.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Ade Lee 2009-05-13 17:04:07 EDT
The "proper" fix might be to root out the inputs that have this problem and fix them to return strings with '\n' rather than "\n".

This is likely to be deep in the CA code, and may cause problems elsewhere.  I'm going to propose a hack instead.

Basically , we will change the escapeJavaScriptString() code to specifically treat the case of "\n" as one would treat a newline.

See patch.
Comment 2 Ade Lee 2009-05-13 17:07:32 EDT
Created attachment 343876 [details]
patch to fix

awnuk , please review.
Comment 3 Andrew Wnuk 2009-05-14 14:42:25 EDT
attachment (id=343876) +awnuk
Comment 4 Andrew Wnuk 2009-05-14 15:24:18 EDT
remark on attachment (id=343876)
in the line
if ((c == 0x5c) && (in[i+1] == 'n')) {
i+1 - may cross array boundary and it should be checked if it is lower then array length.
Comment 5 Ade Lee 2009-05-18 11:18:34 EDT
check added.

[builder@dhcp231-124 common]$ svn ci -m "Bugzilla Bug #500736 -  \n characters are being incorrectly escaped on profile review form" pki-common.spec ../../base/common/
Sending        base/common/src/com/netscape/cms/servlet/profile/ProfileServlet.java
Sending        dogtag/common/pki-common.spec
Transmitting file data ..
Committed revision 456.
Comment 6 Kashyap Chamarthy 2009-06-21 08:24:42 EDT
I tried to request a cert with the following details


when the request form is submitted, the above \n is escaped as \\
Comment 7 Ade Lee 2009-06-22 12:31:24 EDT
That is ok.  The basic manifestation of this bug was that \n characters that were added by the server in displaying certificate requests were being escaped.
The result of this was that when you looked at the certificate request in the agent pages, the page looked very wide (and you could see the escaped \n entries in the key and Key ID.

If this is not happening, then the bug can be considered as verified.
Comment 8 Kashyap Chamarthy 2009-06-23 03:52:38 EDT
Vefified. Thanks Ade.

Note You need to log in before you can comment on or make changes to this bug.