Closed Bug 508113 Opened 16 years ago Closed 15 years ago

Camellia cipher causes datatype misalignment on Windows CE

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Platform:
ARM
Windows CE
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: vlad, Assigned: vlad)

References

(Blocks 1 open bug)

Details

(Whiteboard: [nv][3.12.7])

Attachments

(2 files, 2 obsolete files)

fix v2.1 (checked in to Softoken 3.13 and 3.12.7)
1.08 KB, patch
vlad
: review+
nelson
: superreview+
Details | Diff | Splinter Review
Supplemental patch
1.41 KB, patch
nelson
: review+
Details | Diff | Splinter Review
Under Windows CE, I hit a datatype misalignment error when the camellia cipher is being used by NSS; the code in question is: 43796050 E1A03465 mov r3, r5, ror #8 43796054 E1A01464 mov r1, r4, ror #8 43796058 E0022007 and r2, r2, r7 4379605C E0200C66 eor r0, r0, r6, ror #24 43796060 E0233C65 eor r3, r3, r5, ror #24 43796064 E0211C64 eor r1, r1, r4, ror #24 43796068 E022246E eor r2, r2, lr, ror #8 4379606C E59DE014 ldr lr, [sp, #0x14] 43796070 E0000007 and r0, r0, r7 43796074 E0033007 and r3, r3, r7 43796078 E0011007 and r1, r1, r7 4379607C E0200466 eor r0, r0, r6, ror #8 43796080 E0233465 eor r3, r3, r5, ror #8 43796084 E0211464 eor r1, r1, r4, ror #8 * 43796088 E58E0008 str r0, [lr, #8] 4379608C E3A00000 mov r0, #0 43796090 E58E300C str r3, [lr, #0xC] 43796094 E58E2000 str r2, [lr] 43796098 E58E1004 str r1, [lr, #4] 4379609C E28DD018 add sp, sp, #0x18 437960A0 E8BD8FF0 ldmia sp!, {r4 - r11, pc} R0 = 0x4f725697 R1 = 0xc5d9ed27 R2 = 0x2daf2f20 R3 = 0x1265f1ef R4 = 0x27edd9c5 R5 = 0xeff16512 R6 = 0x9756724f R7 = 0x00ff00ff R8 = 0x00ff0000 R9 = 0x437b4ea0 R10 = 0x75541816 R11 = 0x03e03acd R12 = 0x09ad00fb Sp = 0x01affa98 Lr = 0x0246c004 Pc = 0x43796088 Psr = 0x60000010 Which is the end of camellia_decrypt256, specifically the PUTU32 calls (this one is io[2]). While the PUTU32/GETU32 macros are scary, since the values passed in are unsigned char *'s and they're being cast to a 32-bit pointer type (for which different alignment rules apply), in this particular case, lr is 4-byte-aligned, so the instruction in question shouldn't case an exception. Not sure what's going on. Reproducible using the test page at https://info.isl.ntt.co.jp/crypt/eng/camellia/index.html .
Ah! MSVC is lying. Looking at the stack, the value that was read into lr was actually 0x0246c005 , not 004 -- the debugger is (I think) treating it as an instruction return value, and so is stripping the thumb bit for whatever reason. The solution here is to rewrite PUTU32/GETU32 to not do the casts.
No, the solution is to fix the incorrect #ifdef on line 75 to not assume that MSVC builds only run on CPUs that have no alignment issues.
Attached patch fix (obsolete) — — Splinter Review
The alternate code path here reads/writes bytes at a time and thus works correctly; so let's just use it on ARM. This fixes the crash for me.
Assignee: nobody → vladimir
Attachment #392401 - Flags: review?(nelson)
Bob, since the Camellia and Seed code are not FIPS algorithms, are changes to their code also strictly FIPS controlled?
Whiteboard: [nv] → [nv] FIPS?
Attachment #392401 - Flags: review?(nelson) → review+
Comment on attachment 392401 [details] [diff] [review] fix I believe this fix is correct, but we'll have to wait and see if it it FIPS controlled before we can commit it.
Anything in the FIPS boundary is FIPS controlled. Once we file, that's it. Right now all changes need to be approved by the lab. For changes to non-FIPS algorithms, that has not been a problem (lab has given approval), but we are *really* close to filing, so I can't say if they would approve this change or not. Long term, we should try to support new, non-FIPS algorithms in their own token (or in a common, non-FIPS token) so they could be freely modified without worrying about FIPs validation (every validation we work to include less and less code in the actual module), but that's a 'far' future feature at this point. bob
Hmm.. how does this affect us getting this patch in for Firefox/Fennec on devices where we have alignment issues? Note that there may be a similar issue in AES256 though, for which I believe this is even more complicated... we're still tracking that down though as it seems to cause a hardware hang. We can disable Camellia via prefs if we need to, but that's going to be harder to do for AES256 and still maintain general web compat.
Vlad, on what other "devices" (CPUs) that have alignment issues do we build with MSVC? FUD is unwelcome. If you have a bug number for an issue with AES256, please cite it.
Eh? There is no FUD here -- I'm just wondering what the options are if we do run into something similar in a more core algorithm. No bug has been filed since we're still trying to track down exactly where that particular issue happened (and it's likely a hardware issue). These class of problems are appearing currently on Windows CE on ARM, because WinCE does not enable the ARM CPU's alignment fixup in hardware, and instead causes a fault.
Do we perform FIPS validation on ARM processors built with MSVC? Is FIPS source inspection or exercising of the binary? If the answers are "no" and "binary", then I think it should be straightforward to demonstrate that the produced binaries for validated configurations are bitwise identical, pre- and post- the supplied patch. I don't see FUD here, as the term is typically used -- I see a clear report of a defect in NSS, with excellent diagnostic work done, and a question about how to handle this case if (as vlad suspects, but as he clearly says has not finished investigating) it happens with AES256 as well. Is this not exactly the sort of bug report you want? When will FIPS certification be complete, so that we can again get improvements or fixes like these into the mainline NSS, rather than having to hack around them in Firefox, or ship a bespoke variant to some of our users in order to work around bugs? (Would it not be better for all ARM processors, regardless of compiler, to obey alignment constraints? Surely even the hardware fixup of unaligned accesses has an undesirable performance cost.)
Mike, the source code within the "FIPS boundary" is source controlled. It's not enough to say "after making this change to the sources, the binaries on certain platforms are still the same". If you choose to wait until the FIPS validation is over, and then change the sources with in the FIPS boundaries, the binaries built from those changed sources will not be able to claim FIPS compliance. What you want to do is get the change in BEFORE the evaluation is complete, so that it is covered in the evaluation, not after. The statement "there may be a similar issue in AES256" is FUD, pure and simple. It offers fear, uncertainty and doubt, and offers no basis on which to prove or refute the claim. FUD is unwelcome. When you can say "here is a bug in this source code on this CPU with this compiler" file a bug. Until then, please keep fear out of NSS bugzilla bugs.
I meant to write: "the binaries built from those changed sources will not be able to claim FIPS compliance ON ANY PLATFORM."
(In reply to comment #11) > The statement "there may be a similar issue in AES256" is FUD, pure and simple. > It offers fear, uncertainty and doubt, and offers no basis on which to prove > or refute the claim. FUD is unwelcome. When you can say "here is a bug in > this source code on this CPU with this compiler" file a bug. Until then, > please keep fear out of NSS bugzilla bugs. Sorry, you seem to have misunderstood. My statement was that with Camellia, if we can't modify the source, we can disable it. But, if there was a similar problem with AES256 (or with Barfle or Froboz or whatever hypothetical algorithm you prefer, but one that is more "core"), I was merely wondering what the options for fixing it would be. I asked this question because at the time it seemed like something inside the AES256 code was triggering a problem; I have no harder data than some logs and execution traces that aren't particularly damning to AES256, but do involve it; given that that's the only part of the code that I can't directly influence, I wanted to find out what the options were for getting a fix in there for affected platforms *should there be a problem*. I still don't think that question has been answered, though, and it's one that's going to have an impact on what we do here (both with this patch, and any potential future patch). We can certainly build for ARM using a custom patched branch of NSS, but I want to know if that's what we'll end up needing to do, as that's a complicated option.
If you wish to discuss hypotheticals, then a) this bug is probably the wrong place to do that, and b) you should be VERY CLEAR that you are discussing a hypothetical. Try writing something like "Let us suppose, for the sake of this discussion, that a similar bug exists in ...". That's quite different than saying "There may be a similar bug in xxx, and we are investigating it."
Mike, I want to reiterate here my call for the Fennec/WinCE folks to supply and administer a machine that can act as a Tinderbox for NSS on WinCE. If you want WinCE to be treated like a Tier 1 platform for NSS, it needs a Tinderbox. NSS has a lengthy test suite that tests every algorithm and protocol and combinations thereof, and NSS's Tinderboxes run that script, but it isn't run on WinCE/Fennec because neither Sun nor Red Hat (who supply all the existing Tinderbox machines) use the WinCE platform.
I believe that there's a bug on file about getting a WinCE platform racked and mounted as a tinderbox to deliver nightly builds, yes. ETA is a little later in August, I think?
I would estimate that we are about 1 week away from finishing this round of FIPS evaluation, at which point the FIPS code will effectively be frozen for a long time. If it can be done in the next week, I'm willing to make one last effort to get fixes in to the test lab before this is finished, like the one requested in this bug, but I have no reason to believe or even imagine that this is the last of these bugs for WinCE. I will not have any such reason until we've seen someone successfully run the entire NSS QA test suite on WinCE. I really don't want to keep going back to the test labs with "just one more fix for this platform" again and again. That means that it's time to run that test script NOW, TODAY. A month from now will be too late. Even a week from now will likely be too late.
Unless the NSS test script can be linked together into a .exe that I can just execute, and have it save its output into a file somewhere that I can copy, it's not going to be possible to run it in the near future. The target platform does not have sh, or any other kind of command interpreter, though we do have python running on it.
Unless and until the WinCE platform runs NSS's QA test suite, at least for the code in the FIPS boundary, it's not going to be possible to treat it as a Tier 1 platform in the foreseeable future. This present situation, in which the QA test suite has never been run, and people keep running into problems one at a time, problems that would be all experienced at once with a single test suite run, causes extremely urgent requests for fixes to keep dribbling in all through the FIPS evaluation period. This is unacceptable for FIPS code evaluation. FIPS code must be developed, debugged, then evaluated and certified.
(In reply to comment #14) > If you wish to discuss hypotheticals, then > a) this bug is probably the wrong place to do that, and > b) you should be VERY CLEAR that you are discussing a hypothetical. > Try writing something like "Let us suppose, for the sake of this discussion, > that a similar bug exists in ...". That's quite different than saying > "There may be a similar bug in xxx, and we are investigating it." OK, if that's what you'd like, that's fine, though I'll admit that I didn't expect such a strong reaction to someone sharing their suspicions given such clear indications that they were just suspicions. But: (In reply to comment #18) > I have no reason to believe or even imagine that this is the > last of these bugs for WinCE. I will not have any such reason until we've > seen someone successfully run the entire NSS QA test suite on WinCE. Are you speaking hypothetically here, in which case we should take it to another forum, or are there specific pieces of code that you believe we should look at? (I must admit that the above sounds to me like fear, uncertainty, and doubt by your definition, much more so than Vlad's hedged comment earlier in the bug!) > I really don't want to keep going back to the test labs with "just one more > fix for this platform" again and again. That means that it's time to run > that test script NOW, TODAY. A month from now will be too late. Even a > week from now will likely be too late. Does the NSS test suite still require MKS to run the SSL suite? I don't think we have that software, and I'm pretty sure we don't have it for WinCE. I don't think we even have cygwin, tbh -- I don't know of a port to WinCE, but I'll look around. (Reading http://www.mozilla.org/projects/security/pki/nss/testnss_32.html here. I'm also not sure these devices can handle the 2,048 TCP connection requirement, but I guess we can find out.) Can the test suite be run simply as a set of executables? We are in a cross-compiling configuration here (as is the common case for WinCE development, I think), so I don't know if the shell-based harness will be what we want to be running. Is there someone on the NSS team who can help us work through this issue? (In reply to comment #15) > Mike, I want to reiterate here my call for the Fennec/WinCE folks to supply > and administer a machine that can act as a Tinderbox for NSS on WinCE. I wasn't aware of that request until just now (the Mac requests came to me pretty directly, rather than via a bug report), but I'll follow up on it now, in the appropriate bug. > NSS has a lengthy test suite that tests every algorithm and protocol and > combinations thereof, and NSS's Tinderboxes run that script, but it isn't run > on WinCE/Fennec because neither Sun nor Red Hat (who supply all the existing > Tinderbox machines) use the WinCE platform. I thought in fact that Mozilla supplied some of the current Tinderboxes: http://blog.mozilla.com/seth/2009/06/02/nsprnssjss-mac-os-x-buildqatinderbox-support/ In that case the NSS/JSS team offered to host and maintain the systems if we could provide the hardware, but I can't tell quite from the bug that Gavin linked whether the same arrangement would work here. I'll check with Glen and see what he thinks. What does it mean to be a non-tier 1 platform? That might suffice for us for WinCE, since I suspect that we need only a subset of the wide range of NSS functionality on the device at this time, and don't need FIPS validation for our first release certainly. But I'm guessing about what non-tier 1 means. :-) If the FIPS test is or includes a source evaluation, though, we're finding bugs in the source which should affect the evaluation, unless I'm mistaken about something. If there's a problem on one platform, doesn't that mean that FIPS is invalid on all of them? It sounds like we're in the debugging phase for some of this code, and working together...mostly well...to fix the bugs that are found.
Mike, A portion of NSS sources is FIPS controlled. When we're getting ready to have another FIPS evaluation, we unfreeze those sources for a period of time, during which we are open to taking contributions of new algorithms, and/or support for new platforms. We expect that the contributors of new code will test the code thoroughly for the platforms on which the code is expected to run. Then, at some point, we semi-freeze the FIPS portion of the tree, and start the evaluation. During the evaluation, we can fix bugs found by the lab, and some (limited) serious bugs that we find, but we allow no new enhancements or changes that are inessential to the completion of the evaluation. The NSS tree remains in that state up until the point where the lab says "we're done with the evaluation" and sends their results off to NIST for certification. At that point, the FIPS evaluated code goes into a hard freeze again. Knowing this, it is important for any group that would add support for new algorithms or new platforms to complete their work in a reasonable time. This means running the tests and fixing all errors that are found by the tests in a timely fashion. When a group desires to add support for a new platform, they must ensure that ALL the algorithms run correctly on their new platform. That's their responsibility. The alternative is that the code doesn't run correctly on their platform when it becomes hard frozen. The Fennec/WinCE team has not run the test suite, not even the small portion of the test suite that tests just the FIPS validated code. So, they run into problems little by little, and the problems come dribbling in instead of being fixed in a short period of time. This bug is proof of that. Now, we're (estimated to be) one week away from the point where the lab says "we're done" and the hard freeze sets in, and the fennec bugs are still dribbling in and there's still no full test run. Assuming this is not corrected soon, then the probability seems high that more problems will be found on Fennec after the FIPS evaluation is done. The hard freeze is coming, and after it begins, some non-Tier-1 platform saying "but wait, we still have bugs" won't stop it. If that happens, Mozilla will be faced with a choice: a) Create a non-FIPS source branch for fennec, and put the fixes for fennec ONLY on that branch, and build fennec from that branch, and build NOTHING else (not FIPS platform) from that branch. Build the FIPS evaluated platforms from the FIPS evaluated source base, and build Fennec from its own branch. b) Apply the Fennec changes to the main source tree, and thereafter be unable to produce FIPS validated builds for ANY platform from that tree. The lab doesn't care about any platforms other than the ones we pay them to evaluate. It doesn't matter if the code is completely wrong for other platforms. That has no effect on their evaluation. But if you change a source code file that is common to both evaluated and non-evaluated platforms for the sake of a non-evaluated platform, that file can no longer be said to be FIPS evaluated/certified. Since Fennec in a non-evaluated platform, the problems that it has are irrelevant to the FIPS evaluations on the evaluated platforms, unless and until the Fennec problems result in changes to the common source code. The code that gets FIPS evaluated in the code that implements the actual crypto algorithms, and APIs that interface to it, and interfaces between it and the databases that contain keys. It's shared libs named softoken, freebl, and nssdbm. (Maybe I'm forgetting one more.) All the code outside of those areas is outside the scope of FIPS evaluation and can be changed at will without any ill effects on the FIPS evaluated code. THe code that implements the SSL protocol, or parses certificates, or builds certificate chains for validity testing is all outside the FIPS boundary. Testing the code outside the FIPS boundary is not critical to the FIPS evaluation, because that code will not be hard frozen when the lab is done. So, testing with hundreds or thousands of simultaneous SSL connections is not vital at this time, but testing the base algorithms, is vital. Testing all the crypto algorithms used in SSL and TLS is vital. It would be good to do at least ONE successful SSL and TLS connection with every cipher suite to help confirm that this has been satisfactorily tested. Regarding Tinderboxes, Mozilla did supply some X86 Mac "minis", and Sun did agree to set them up and run them as tinderboxes. Sun had some interest in X86 Macs as a potential server platform. But there is no similar interest in WinCE at Sun. (Note: we don't have any PPC macs, and consequently, PPC macs are not a Tier 1 platform for NSS). A Tier 1 platform is a platform that we ensure works in every new release. We make sure that a new release doesn't break a tier 1 platform, or we don't release it. We also make sure that new contributions of code don't break Tier 1 platforms. To do that, we MUST have a tinderbox for every Tier 1 platform. WinCE/Fennec is not a Tier 1 platform now, for that reason, and because it hasn't passed all the QA tests. Platforms are sometimes dropped from the Tier 1 list when they become old enough. We attempted to drop AIX and certain old versions of Linux in 3.12, but have found it necessary to reinstate them, at least for one more release. No, MKS is not required on any platform. I still use it, but our official builds use MSYS or MinGW or MozTools or something else that is free (not MKS, and not cygwin). I had discussions in the past with someone about the possibility of running tests in an emulated WinCE environment. It was suggested that the scripting might be able to run outside of the emulator. Maybe that's still worth pursuing. I had the NSS SSL tests running on WinCE back in 2001 using a similar scheme. Someone had some kind of very limited command line window tool back then. It was enough. Don't recall the details now. I'm willing to help advise any developer who wants to seriously try to cover the tests on a PDA platform, but I can't do much of the work.
So this bug stalled a bit, with regards to the original problem here -- what can be done with the patch?
Comment on attachment 392401 [details] [diff] [review] fix >+#if defined(_MSC_VER) && !defined(_M_ARM) It's better to use a whitelist of the CPUs that allow unaligned access here: #if defined(_MSC_VER) && defined(NSS_X86_OR_X64)
Vlad, you just missed our last change to the NSS crypto module by at most three days (see bug 507482 comment 2 and bug 507482 comment 14). Glen, if the FIPS lab gives us another chance to change the NSS crypto module, please remember to include the patch in this bug.
The hard freeze set in on 2009-08-13 with the release of NSS 3.12.4 RTM
So, this patch has been here for quite some time before that hard freeze date (which I don't think I knew about -- is there a notification of these pending dates somewhere that we can follow?) Is there a reason that it wasn't accepted by the NSS team before that hard freeze? Is there something we could have done to make it get there? This is a pretty frustrating situation, and it seems like we're just going to have to take a local patch to NSS in our Firefox tree in order to fix this defect, which is something that I would very much have liked to avoid. :-/
I suggest that we add - a Bugzilla keyword named fips-approved, or - a flag for attachments named approval-fips, or - a flag for bugs named blocking-fips so that we can search for such patches easily the next time we make changes to the NSS crypto module.
Mike, NSS entered FIPS evaluation months ago, and entered a freeze at that time. While in that evaluation, any changes made after that date required agreement and approval of the FIPS testing lab. The changes proposed for this bug were not accepted before the freeze. When the lab completed their testing, then no more changes are accepted for any reason. That's what happened last week.
Can we simply land this in the m-c NSS?
Attached patch fix v2 (obsolete) — — Splinter Review
Vlad, could you test this patch? I use the whitelist-style test that's used in des.c and sha512.c: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/des.c&rev=1.8&mark=406#403 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/sha512.c&rev=1.14&mark=106#101
Attachment #392401 - Attachment is obsolete: true
Attachment #395782 - Flags: review?(vladimir)
I believe the CPU also needs to be little-endian (because of the SWAP operation), so I updated the comment accordingly.
Attachment #395782 - Attachment is obsolete: true
Attachment #395784 - Flags: superreview?(nelson)
Attachment #395784 - Flags: review?(vladimir)
Attachment #395782 - Flags: review?(vladimir)
Attachment #395784 - Flags: superreview?(nelson) → superreview+
Comment on attachment 395784 [details] [diff] [review] fix v2.1 (checked in to Softoken 3.13 and 3.12.7) r=nelson for the SOFTOKEN_3_13_BRANCH only. We really should also fix that horrid SWAP macro and the macros that use it. I'd suggest replacing it with the SHA_HTONL macro from sha_fast.h. That is, I would suggest #including sha_fast.h here, and using SHA_HTONL instead of SWAP.
Comment on attachment 395784 [details] [diff] [review] fix v2.1 (checked in to Softoken 3.13 and 3.12.7) I checked in the patch on the SOFTOKEN_3_13_BRANCH (Softoken 3.13.0). Checking in camellia.c; /cvsroot/mozilla/security/nss/lib/freebl/camellia.c,v <-- camellia.c new revision: 1.2.8.1; previous revision: 1.2 done Vlad, could you paste the entire call stack of the crash? I'd like to know where the unaligned buffer comes from. Perhaps we can work around this bug (and improve performance) by aligning that buffer. Thanks!
Include sha_fast.h and use SHA_HTONL instead of SWAP.
Attachment #396037 - Flags: review?(nelson)
Vlad, don't worry about the call stack. I just remembered that our cipher test suite tests unaligned input and output buffers, so we need to fix this bug for our test suite to pass on Windows CE.
Yeah, this is one on many problems that might be caught if the WinCE guys would run NSS's test suite just once. :( I'm looking for a public server with which I can test this latest patch.
(In reply to comment #36) > Vlad, don't worry about the call stack. I just remembered that > our cipher test suite tests unaligned input and output buffers, > so we need to fix this bug for our test suite to pass on Windows > CE. Ok -- I can take a look and see where it's coming from anyway, as unaligned access may be more expensive on some of the other platforms (or trivially more expensive on x86 I guess, though I don't think that really matters these days). > I'm looking for a public server with which I can test this latest patch. The camellia page at NTT negotiates camellia when loaded over https: https://info.isl.ntt.co.jp/crypt/eng/camellia/ -- that's what I used to reproduce. (In reply to comment #37) > Yeah, this is one on many problems that might be caught if the WinCE guys > would run NSS's test suite just once. :( I honestly would if I could -- it is just not possible to do it, in the form that the test suite's currently in (without rewriting/reworking the whole thing). The only thing that I have that remotely resembles a command interpreter is python.
Comment on attachment 396037 [details] [diff] [review] Supplemental patch r=nelson works as expected on windows.
Attachment #396037 - Flags: review?(nelson) → review+
Comment on attachment 396037 [details] [diff] [review] Supplemental patch Checked in on the SOFTOKEN_3_13_BRANCH (Softoken 3.13.0). Checking in camellia.c; /cvsroot/mozilla/security/nss/lib/freebl/camellia.c,v <-- camellia.c new revision: 1.2.8.2; previous revision: 1.2.8.1 done
Attachment #395784 - Attachment description: fix v2.1 → fix v2.1 (suitable for Softoken 3.12.x)
Marked the bug fixed. I looked into implementing a workaround, and found that Vlad already disabled Camellia ciphers in bug 511808. I have reviewed his patch. It's also possible to work around this bug in NSS by copying input/output to/from aligned buffers, but I don't think that's worthwhile. If the FIPS lab gives us an opportunity to change the softoken, we should apply fix v2.1 (attachment 395784 [details] [diff] [review]).
Blocks: 511808
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.13
Attachment #395784 - Flags: review?(vladimir) → review+
Whiteboard: [nv] FIPS? → [nv] FIPS2010
Blocks: FIPS2010
Whiteboard: [nv] FIPS2010 → [nv]
Comment on attachment 395784 [details] [diff] [review] fix v2.1 (checked in to Softoken 3.13 and 3.12.7) I checked in this patch on the NSS trunk (3.12.7) for FIPS revalidation. Checking in camellia.c; /cvsroot/mozilla/security/nss/lib/freebl/camellia.c,v <-- camellia.c new revision: 1.3; previous revision: 1.2 done
Attachment #395784 - Attachment description: fix v2.1 (suitable for Softoken 3.12.x) → fix v2.1 (checked in to Softoken 3.13 and 3.12.7)
Whiteboard: [nv] → [nv][3.12.7]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: