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)

3.12.6
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.7

People

(Reporter: christophe.ravel.bugs, Assigned: christophe.ravel.bugs)

References

Details

Attachments

(1 file)

{ (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 }
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.
This bug prevents PK11_FindCertFromNickname from being successful on these nicknames that contain multi-byte characters.
Priority: -- → P2
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?
Attachment #435247 - Flags: review? → review?(alexei.volkov.bugs)
Target Milestone: --- → 3.12.7
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+
> 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.
The quotes are checked and added if needed by this code just above: if( $fields[2] =~ /^"/ ) { ; } else { $fields[2] = "\"" . $fields[2] . "\""; }
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
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 ?
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.
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: