JAR_find and JAR_find_next use PORT_Strcmp for pattern matching

RESOLVED FIXED in 3.12.7

Status

NSS
Tools
P2
normal
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: G. Richard Bellamy, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

3.12.4
3.12.7

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
Build Identifier: NSS_3_12_4_RTM

JAR_Context indicates that pattern* supports regular expressions, it does not.

Because verify_global calls JAR_find with a pattern of "*", and JAR_find_next uses PORT_Strcmp to test the pattern against the current pathname, it never traverses the tree.

The patch does not make pattern tests regex-aware, instead, by passing in a NULL for the pattern, JAR_find_next fully traverses the tree.

See the patch in Additional Information.

Reproducible: Always

Steps to Reproduce:
1. signtool -k testcert -v --verbosity test.jar
Actual Results:  
Should output information about the MF, SF, DSA and RSA files found in the JAR.

Expected Results:  
It does not output information about MF, SF, DSA and RSA files found in JAR.

Index: security/nss/cmd/signtool/verify.c
===================================================================
RCS file: /cvsroot/mozilla/security/nss/cmd/signtool/verify.c,v
retrieving revision 1.5
diff -U 3 -r1.5 verify.c
--- security/nss/cmd/signtool/verify.c	16 Jul 2004 00:04:47 -0000	1.5
+++ security/nss/cmd/signtool/verify.c	8 Apr 2010 19:36:52 -0000
@@ -170,7 +170,7 @@
     int	          retval = 0;
     char	  buf [BUFSIZ];
 
-    ctx = JAR_find (jar, "*", jarTypePhy);
+    ctx = JAR_find (jar, NULL, jarTypePhy);
 
     while (JAR_find_next (ctx, &it) >= 0) {
 	if (!PORT_Strncmp (it->pathname, "META-INF", 8)) {
(Reporter)

Comment 1

8 years ago
Created attachment 437930 [details] [diff] [review]
Patch file.
(Assignee)

Updated

8 years ago
OS: Linux → All
Hardware: x86 → All
Version: unspecified → 3.12.4
I confirm the bug.  I confirm that all other callers of JAR_Find pass NULL
for the second argument.  This is the only caller of JAR_find that passes
a non-NULL value, so it is tempting to change it to pass NULL also, since
this will have the immediately desired effect.  I could give the provided
patch an r+ on that basis.  Maybe I should.

But clearly JAR_find and JAR_find_next are broken, don't work as intended.
This patch works around that problem, rather than fixing it.  The flaw in
those functions is due to the following code (as Richard noted above)
in jar.c:

451             if (ctx->pattern && *ctx->pattern) {
452                 if (PORT_Strcmp ((*it)->pathname, ctx->pattern))
453                     continue;

Since NSS has a pattern matching function, I'd rather try using it here,
than giving up on JAR_find* ever working as intended.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Richard, 
Please try this patch to security/nss/lib/jar/jar.c as an alternative to your
patch to security/nss/cmd/signtool/verify.c

+#include "portreg.h"

-                if (PORT_Strcmp ((*it)->pathname, ctx->pattern))
+                if (PORT_RegExpSearch((*it)->pathname, ctx->pattern))
(Reporter)

Comment 4

8 years ago
Actually, that was my first attempt, but it produced a compile error, even after I changed the manifest.mn to require util:

gcc -o Linux2.6_x86_64_glibc_PTH_64_DBG.OBJ/jar.o -c -g -fPIC -DLINUX1_2 -D_XOPEN_SOURCE -DLINUX2_1  -ansi -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -DMOZILLA_CLIENT=1 -DDEBUG -UNDEBUG -DDEBUG_rbellamy -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNSS_X86_OR_X64 -DNSS_X64 -I../../../../dist/Linux2.6_x86_64_glibc_PTH_64_DBG.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -I../../../../dist/public/dbm -I../../../../dist/public/util  jar.c
jar.c: In function ‘JAR_find_next’:
jar.c:453: error: implicit declaration of function ‘PORT_RegExSearch’

I'm just not familiar enough with the build system yet to track this down, so I just did the simplest patch I could, given my limited time.

However, any guidance on how I would correct the above would be greatly appreciated, and I'll happily give it another shot.
Created attachment 438310 [details] [diff] [review]
alternative patch v1

Try this patch.  (Beware: This patch has Windows line endings)
Attachment #438310 - Flags: review?(rrelyea)
(Assignee)

Updated

8 years ago
Assignee: nobody → nelson
Priority: -- → P2
Target Milestone: --- → 3.12.7

Comment 6

7 years ago
Comment on attachment 438310 [details] [diff] [review]
alternative patch v1

r+

I also think exporting PORT_RegExpSearch is probably a good thing in itself as well.

bob
Attachment #438310 - Flags: review?(rrelyea) → review+
Bug 558160: JAR_find and JAR_find_next use PORT_Strcmp for pattern matching
r=rrelyea

Checking in jar/jar.c;        new revision: 1.6;  previous revision: 1.5
Checking in util/nssutil.def; new revision: 1.13; previous revision: 1.12
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Summary: verify_global in verify.c does nothing → JAR_find and JAR_find_next use PORT_Strcmp for pattern matching
You need to log in before you can comment on or make changes to this bug.