I assume MOZ_BITS could be used with a '64' value someday, but it's '32' only nowadays and '16' is obsolete, is it not?

Yes, MOZ_BITS is obsolete. NSS use USE_64=1 to create a build for 64-bit Windows. We can remove the two Makefile.win files for nmake under 'dbm'. (By the way, we should probably remove config/javarules.mak js/jsd/jsdshell.mak js/jsd/jsd.mak which are also for nmake.)

Comment on attachment 392138 [details] [diff] [review] (Av1) Remove 2 Makefile.win for nmake [See bug 512482 comment 9] NB: Please, check if something like http://mxr.mozilla.org/mozilla/source/db/makefile.win is needed.

Comment on attachment 392141 [details] [diff] [review] (Cv1) Remove "MOZ_BITS == 16" blocks [Checkin: Comment 9] r=wtc. Serge, I just gave you CVS commit access to the NSPR trunk. Please check in this patch on the NSPR trunk in CVS (not Hg). Our tinderbox is the NSS tinderbox at http://tinderbox.mozilla.org/showbuilds.cgi?tree=NSS Thanks!

Comment on attachment 392138 [details] [diff] [review] (Av1) Remove 2 Makefile.win for nmake [See bug 512482 comment 9] r=wtc. mozilla/dbm is part of the "Security" module in CVS. My status in the Security module is lower, just a "peer", so I can't unilateral give you CVS commit access. One of us will check in this patch for you.

Wan-Teh, IINM the DBM source code is inside the FIPS boundary, because the shared library that includes that code is inside the boundary. Is it not?

Comment on attachment 392141 [details] [diff] [review] (Cv1) Remove "MOZ_BITS == 16" blocks [Checkin: Comment 9] http://bonsai.mozilla.org/cvsquery.cgi?module=NSPR&date=explicit&mindate=2009-08-04+11%3A07&maxdate=2009-08-04+11%3A07

Nelson, yes, DBM is inside the FIPS boundary. Thanks for the reminder.

With all the hi priority vulnerability issues being worked on now, I'm trying to understand why bugs like this one are being treated as high priority.

Comment on attachment 392139 [details] [diff] [review] (Bv1-MC) Remove (last) 3 *.mak [Checkin: Comment 12] http://hg.mozilla.org/mozilla-central/rev/e2cc9f1841d7

(In reply to comment #7) > (From update of attachment 392138 [details] [diff] [review]) > One of us will check in this patch for you. Any hint about when? (In reply to comment #10) > DBM is inside the FIPS boundary. What's the impact on check-in?

The impact is that it will not get checked into any release for NSS for a long time to come (like, possibly a year or more). It will get committed on a special branch of changes that are waiting for the NEXT FIPS release, which may be NSS 3.13.

(In reply to comment #14) Thanks for the explanation. Moving check-in action to bug 512482.

Wait, Maybe I'm hopelessly confused. In some comments above, we were discussing DBM. DBM is part of NSS. NSS suffers from FIPS-induced delays, but this is an NSPR bug. NSPR does not suffer any FIPS-induced delays. To the extent that this bug covers DBM, it is delayed by FIPS. To the extent that it is in NSPR, it is not delayed by FIPS.

(In reply to comment #16) That's how I understood it: > To the extent that this bug covers DBM, it is delayed by FIPS. Filed bug 512482. > To the extent that it is in NSPR, it is not delayed by FIPS. Morphed this very bug accordingly.

So, is the NSPR part of this bug all committed in CVS now?

(In reply to comment #18) Yes: comment 9.