Closed
Bug 555261
Opened 15 years ago
Closed 15 years ago
certdata.c: invalid length for nicknames containing multi-byte characters
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.7
People
(Reporter: christophe.ravel.bugs, Assigned: christophe.ravel.bugs)
References
Details
Attachments
(1 file)
947 bytes,
patch
|
alvolkov.bgs
:
review+
|
Details | Diff | Splinter Review |
{ (void *)"AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.", (PRUint32)39 }: length should be 27 instead of 39.
Similar issue with:
{ (void *)"T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3", (PRUint32)126 }
{ (void *)"EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1", (PRUint32)75 }
Assignee | ||
Comment 1•15 years ago
|
||
The issue is that certdata.perl counts \xXX as 4 bytes instead of 1. When the data is ready from certdata.txt, the \xXX sequence is not interpreted as an hexadecimal character but as 4 character. This is fine because we want to keep all these characters for the nickname string in certdata.c. But the length of the string need to be adjusted to take into account that once certdata.c is compiled, \xXX is actually only 1 byte.
Assignee | ||
Comment 2•15 years ago
|
||
This bug prevents PK11_FindCertFromNickname from being successful on these nicknames that contain multi-byte characters.
Priority: -- → P2
Assignee | ||
Comment 3•15 years ago
|
||
the "eval" function parses all the \xXX sequences (and others if present). The resulting string is the same as the one that will be generated by the C compiler in certdata.c.
The diffs in the generated certdata.c file are as follow:
< { (void *)"AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.", (PRUint32)39 },
---
> { (void *)"AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.", (PRUint32)27 },
18238c18238
< { (void *)"AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.", (PRUint32)39 },
---
> { (void *)"AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.", (PRUint32)27 },
19226c19226
< { (void *)"T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3", (PRUint32)126 },
---
> { (void *)"T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3", (PRUint32)66 },
19360c19360
< { (void *)"T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3", (PRUint32)126 },
---
> { (void *)"T\xc3\x9c\x42\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1 - S\xC3\xBCr\xC3\xBCm 3", (PRUint32)66 },
19602c19602
< { (void *)"EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1", (PRUint32)75 },
---
> { (void *)"EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1", (PRUint32)48 },
19729c19729
< { (void *)"EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1", (PRUint32)75 },
---
> { (void *)"EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1", (PRUint32)48 },
Assignee: nobody → christophe.ravel.bugs
Attachment #435247 -
Flags: review?
Assignee | ||
Updated•15 years ago
|
Attachment #435247 -
Flags: review? → review?(alexei.volkov.bugs)
Assignee | ||
Updated•15 years ago
|
Target Milestone: --- → 3.12.7
Comment 4•15 years ago
|
||
Comment on attachment 435247 [details] [diff] [review]
Fixes length for UTF8 strings
patch is good. Just make sure, that field that we feed to eval is always a text, meaning, that is it included in quotes. Otherwise it will try to treat it a text.
r=alexei
Attachment #435247 -
Flags: review?(alexei.volkov.bugs) → review+
Comment 5•15 years ago
|
||
> text, meaning, that is it included in quotes. Otherwise it will try to treat it
> a text.
Correction, not as a text, but as a code line.
Assignee | ||
Comment 6•15 years ago
|
||
The quotes are checked and added if needed by this code just above:
if( $fields[2] =~ /^"/ ) {
;
} else {
$fields[2] = "\"" . $fields[2] . "\"";
}
Assignee | ||
Comment 7•15 years ago
|
||
Committed along with the corrected certdata.c:
Checking in certdata.perl;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.perl,v <-- certdata.perl
new revision: 1.13; previous revision: 1.12
done
Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c
new revision: 1.60; previous revision: 1.59
done
I also changed the version of libnssckbi to 1.79:
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h
new revision: 1.24; previous revision: 1.23
done
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•15 years ago
|
||
With this fixed, certutil is able to find the cert by nickname. I don't know how to best input and output UTF-8 characters. I was able to do the input part using Perl:
$ certutil -L -d certdb -n "$(perl -e 'print eval("\"Builtin Object Token:AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.\"")')"
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
07:7e:52:93:7b:e0:15:e3:57:f0:69:8c:cb:ec:0c
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=AC Ra..z Certic..mara S.A.,O=Sociedad Cameral de Certific
aci..n Digital - Certic..mara S.A.,C=CO"
Validity:
Not Before: Mon Nov 27 20:46:29 2006
Not After : Tue Apr 02 21:42:02 2030
Subject: "CN=AC Ra..z Certic..mara S.A.,O=Sociedad Cameral de Certifi
caci..n Digital - Certic..mara S.A.,C=CO"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
ab:6b:89:a3:53:cc:48:23:08:fb:c3:cf:51:96:08:2e:
b8:08:7a:6d:3c:90:17:86:a9:e9:ed:2e:13:34:47:b2:
d0:70:dc:c9:3c:d0:8d:ca:ee:4b:17:ab:d0:85:b0:a7:
23:04:cb:a8:a2:fc:e5:75:db:40:ca:62:89:8f:50:9e:
01:3d:26:5b:18:84:1c:cb:7c:37:b7:7d:ec:d3:7f:73:
19:b0:6a:b2:d8:88:8a:2d:45:74:a8:f7:b3:b8:c0:d4:
da:cd:22:89:74:4d:5a:15:39:73:18:74:4f:b5:eb:99:
a7:c1:1e:88:b4:c2:93:90:63:97:f3:a7:a7:12:b2:09:
22:07:33:d9:91:cd:0e:9c:1f:0e:20:c7:ee:bb:33:8d:
8f:c2:d2:58:a7:5f:fd:65:37:e2:88:c2:d8:8f:86:75:
5e:f9:2d:a7:87:33:f2:78:37:2f:8b:bc:1d:86:37:39:
b1:94:f2:d8:bc:4a:9c:83:18:5a:06:fc:f3:d4:d4:ba:
8c:15:09:25:f0:f9:b6:8d:04:7e:17:12:33:6b:57:48:
4c:4f:db:26:1e:eb:cc:90:e7:8b:f9:68:7c:70:0f:a3:
2a:d0:3a:38:df:37:97:e2:5b:de:80:61:d3:80:d8:91:
83:42:5a:4c:04:89:68:11:3c:ac:5f:68:80:41:cc:60:
42:ce:0d:5a:2a:0c:0f:9b:30:c0:a6:f0:86:db:ab:49:
d7:97:6d:48:8b:f9:03:c0:52:67:9b:12:f7:c2:f2:2e:
98:65:42:d9:d6:9a:e3:d0:19:31:0c:ad:87:d5:57:02:
7a:30:e8:86:26:fb:8f:23:8a:54:87:e4:bf:3c:ee:eb:
c3:75:48:5f:1e:39:6f:81:62:6c:c5:2d:c4:17:54:19:
b7:37:8d:9c:37:91:c8:f6:0b:d5:ea:63:6f:83:ac:38:
c2:f3:3f:de:9a:fb:e1:23:61:f0:c8:26:cb:36:c8:a1:
f3:30:8f:a4:a3:a2:a1:dd:53:b3:de:f0:9a:32:1f:83:
91:79:30:c1:a9:1f:53:9b:53:a2:15:53:3f:dd:9d:b3:
10:3b:48:7d:89:0f:fc:ed:03:f5:fb:25:64:75:0e:17:
19:0d:8f:00:16:67:79:7a:40:fc:2d:59:07:d9:90:fa:
9a:ad:3d:dc:80:8a:e6:5c:35:a2:67:4c:11:6b:b1:f8:
80:64:00:2d:6f:22:61:c5:ac:4b:26:e5:5a:10:82:9b:
a4:83:7b:34:f7:9e:89:91:20:97:8e:b7:42:c7:66:c3:
d0:e9:a4:d6:f5:20:8d:c4:c3:95:ac:44:0a:9d:5b:73:
3c:26:3d:2f:4a:be:a7:c9:a7:10:1e:fb:9f:50:69:f3
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Basic Constraints
Critical: True
Data: Is a CA with no maximum path length.
Name: Certificate Key Usage
Critical: True
Usages: Certificate Signing
CRL Signing
Name: Certificate Subject Key ID
Data:
d1:09:d0:e9:d7:ce:79:74:54:f9:3a:30:b3:f4:6d:2c:
03:03:1b:68
Name: Certificate Policies
Data:
Policy Name: Certificate Policies AnyPolicy
Policy Qualifier Name: PKIX CPS Pointer Qualifier
Policy Qualifier Data: "http://www.certicamara.com/dpc/"
Policy Qualifier Name: PKIX User Notice Qualifier
Display Text: "mitaciones de garant.as de este certif
icado se pueden encontrar en la DPC."
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Signature:
5c:94:b5:b8:45:91:4d:8e:61:1f:03:28:0f:53:7c:e6:
a4:59:a9:b3:8a:7a:c5:b0:ff:08:7c:2c:a3:71:1c:21:
13:67:a1:95:12:40:35:83:83:8f:74:db:33:5c:f0:49:
76:0a:81:52:dd:49:d4:9a:32:33:ef:9b:a7:cb:75:e5:
7a:cb:97:12:90:5c:ba:7b:c5:9b:df:bb:39:23:c8:ff:
98:ce:0a:4d:22:01:48:07:7e:8a:c0:d5:20:42:94:44:
ef:bf:77:a2:89:67:48:1b:40:03:05:a1:89:ec:cf:62:
e3:3d:25:76:66:bf:26:b7:bb:22:be:6f:ff:39:57:74:
ba:7a:c9:01:95:c1:95:51:e8:ab:2c:f8:b1:86:20:e9:
3f:cb:35:5b:d2:17:e9:2a:fe:83:13:17:40:ee:88:62:
65:5b:d5:3b:60:e9:7b:3c:b8:c9:d5:7f:36:02:25:aa:
68:c2:31:15:b7:30:65:eb:7f:1d:48:79:b1:cf:39:e2:
42:80:16:d3:f5:93:23:fc:4c:97:c9:5a:37:6c:7c:22:
d8:4a:cd:d2:8e:36:83:39:91:90:10:c8:f1:c9:35:7e:
3f:b8:d3:81:c6:20:64:1a:b6:50:c2:21:a4:78:dc:d0:
2f:3b:64:93:74:f0:96:90:f1:ef:fb:09:5a:34:40:96:
f0:36:12:c1:a3:74:8c:93:7e:41:de:77:8b:ec:86:d9:
d2:0f:3f:2d:d1:cc:40:a2:89:66:48:1e:20:b3:9c:23:
59:73:a9:44:73:bc:24:79:90:56:37:b3:c6:29:7e:a3:
0f:f1:29:39:ef:7e:5c:28:32:70:35:ac:da:b8:c8:75:
66:fc:9b:4c:39:47:8e:1b:6f:9b:4d:02:54:22:33:ef:
61:ba:9e:29:84:ef:4e:4b:33:47:76:97:6a:cb:7e:5f:
fd:15:a6:9e:42:43:5b:66:5a:8a:88:0d:f7:16:b9:3f:
51:65:2b:66:6a:8b:d1:38:52:a2:d6:46:11:fa:fc:9a:
1c:74:9e:8f:97:0b:02:4f:64:c6:f5:68:d3:4b:2d:ff:
a4:37:1e:8b:3f:bf:44:be:61:46:a1:84:3d:08:27:4c:
81:20:77:89:08:ea:67:40:5e:6c:08:51:5f:34:5a:8c:
96:68:cd:d7:f7:89:c2:1c:d3:32:00:af:52:cb:d3:60:
5b:2a:3a:47:7e:6b:30:33:a1:62:29:7f:4a:b9:e1:2d:
e7:14:23:0e:0e:18:47:e1:79:fc:15:55:d0:b1:fc:25:
71:63:75:33:1c:23:2b:af:5c:d9:ed:47:77:60:0e:3b:
0f:1e:d2:c0:dc:64:05:89:fc:78:d6:5c:2c:26:43:a9
Fingerprint (MD5):
93:2A:3E:F6:FD:23:69:0D:71:20:D4:2B:47:99:2B:A6
Fingerprint (SHA1):
CB:A1:C5:F8:B0:E3:5E:B8:B9:45:12:D3:F9:34:A2:E9:06:10:D3:36
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
Email Flags:
Valid CA
Trusted CA
Object Signing Flags:
Valid CA
Trusted CA
---------
The output is still not completely correct. Who know how to do that ?
Comment 9•15 years ago
|
||
Christophe, in what manner is the "output still not completely correct" ?
I commend you for your excellent job of finding and diagnosing this problem
and fixing it.
I believe there are other NSS bugs that have reported that they could not
access a cert by it's UTF8 nickname. This bug is the solution to those
problems as well. Those bugs should be found and resolved as duplicates
of this one.
Assignee | ||
Comment 11•15 years ago
|
||
(In reply to comment #9)
> Christophe, in what manner is the "output still not completely correct" ?
The UTF-8 characters are not displayed correctly. They are replaced by 2 dots like in:
CN=AC Ra..z Certic..mara S.A.
Comment 12•15 years ago
|
||
Oh, that's because secu_PrintRawString only prints printable ASCII characters.
See https://mxr.mozilla.org/security/source/security/nss/cmd/lib/secutil.c#870
and https://mxr.mozilla.org/security/source/security/nss/cmd/lib/secutil.c#983
You need to log in
before you can comment on or make changes to this bug.
Description
•