Re: How to log out of SDR?
Neil wrote: Neil wrote: I also notice that checkPassword(); logs out if there was a password. Can this behaviour be relied on, or should I call logoutSimple() too? To answer my own question, nsPK11Token::CheckPassword calls PK11_CheckUserPassword which is documented as logging out if the password is incorrect. I think this works because PK11_CheckUserPassword calls C_Login immediately without calling IsLoggedIn first. Anyway, I've checked in a patch to switch to using checkPassword() but that was almost certainly too late for SeaMonkey 2.0 The original log out bug seems to date back to the earliest that I can find an implementation for it, which is some time in 2002. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to log out of SDR?
Robert Relyea wrote: On 10/15/2009 02:39 AM, Neil wrote: Robert Relyea wrote: If you have no master password set, you have a token that doesn't have 'need login' set in it. NSS will treat such a token as always logged in. No matter how many times you log out, the token and it's keys are still available. What exactly are you seeing? What I'm seeing is that after calling logoutSimple(); login(false); then isLoggedIn() returns false. But with a master password, then logoutSimple(); login(false); will prompt for the password and isLoggedIn() returns true, assuming the password was correctly entered. And I'm not actually calling login myself; I want to leave the token logged out if there is a password, so that the next caller to login prompts. isLoggedIn appears to be returning exactly what NSS returns. What you need is the result of PK11_NeedLogin(). Unfortunately I'm not the caller of login or isLoggedIn, so I need something that will not log out if there's no password to log out, but not make isLoggedIn return false if there's no password (since once that happens there seems to be no way to make it true again). -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to log out of SDR?
Nelson B Bolyard wrote: By the way, I REALLY REALLY wish that the password manager would use that when you click the button to reveal the passwords, instead of doing what it does now, which forces you to re-enter the master password, even if you've JUST entered it. I think this is a holdover from the old wallet code, which didn't encrypt by default, so the UI only asked for the master password as a protective measure. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to log out of SDR?
Robert Relyea wrote: If you have no master password set, you have a token that doesn't have 'need login' set in it. NSS will treat such a token as always logged in. No matter how many times you log out, the token and it's keys are still available. What exactly are you seeing? What I'm seeing is that after calling logoutSimple(); login(false); then isLoggedIn() returns false. But with a master password, then logoutSimple(); login(false); will prompt for the password and isLoggedIn() returns true, assuming the password was correctly entered. And I'm not actually calling login myself; I want to leave the token logged out if there is a password, so that the next caller to login prompts. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to log out of SDR?
Nelson Bolyard wrote: I'll add these thoughts. I don't know of any way to log in to a token that has no password. IINM, such a token just comes up in a state that is similar to being already logged in. It's not surprising to me that forcefully logging it out leaves it in a state where it cannot log in again without being restarted. Maybe the solution is to make it so that it cannot be logged out, since it is not truly logged in. That could be done in NSS or in PSM or in the browser outside of PSM (I think). That might be possible if there was some easy way of determining whether there is a master password (without prompting the user for such password). This method would not need to leave the user logged in if they had previously been logged in with a password. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
How to log out of SDR?
This is probably PSM again, but I hope someone here can answer it, or point me somewhere. We have a both menuitem and a dialog that logs you out of the SDR, so that you need to reenter your Master Password to gain access to your stored certificates and other encrypted material, such as the login manager's password store. This works fine when you actually have a Master Password. However when you do not have a Master Password then it does not seem possible to log in again. Is this a case of: a) sdr.logoutAndTeardown(); is the wrong API to log out b) we're using the wrong API to log in when there is no password c) there's a bug in PSM and/or NSS? Thanks, Neil. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: XPCOM installation folders when using dependent DLLs?
Nelson Bolyard wrote: NSS certainly supports AES. NSS offers a C API. PSM is the primary provider of XPCOM wrappers for NSS. I'm not aware of what raw symmetric encryption capabilities PSM offers to the users of its XPCOM interfaces. Sadly, few PSM developers hang out here. For those wondering what that means in practical terms, PSM looks like any other Gecko component (since it uses XPCOM interfaces) so for example it can (within reason) be called directly from JavaScript. PSM is not the only way to call NSS functions. PSM manages the loading, initializing, shutting down, and unloading of NSS. Calling NSS through PSM has the potential advantage of avoiding all the potential problems of calling NSS while it is unloaded and/or uninitialized. But if some other code is certain that NSS is loaded and initialized, then it could call NSS directly. So, given that Polly was originally writing a binary component, that may well be a viable solution, as long as the calls are made at a safe point (e.g. a direct call into the binary component from extension UI). -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: XPCOM installation folders when using dependent DLLs?
Polly wrote: Neil wrote: Polly wrote: Tom, you asked what third party DLLs I'm using -- it's the openssl DLLs ssleay32.dll and libeay32.dll. One possible alternative might be to rewrite your code to use NSS? Thanks for the suggestion. As it happens, my requirements were for using AES, and it was my understanding that NSS's functionality is exposed in Firefox via PSM, and that PSM doesn't presently support AES. But as I said, I'm pretty wet behind the ears with Firefox, and would love to hear from more experienced devs if I've got this wrong. Cross-posting to mozilla.dev.tech.crypto in case someone there can enlighten you. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Spontaneous Master Password?
Some users of SeaMonkey 2.0b1 who have migrated from SeaMonkey 1.1.17 have been complaining that the resulting profile claims to have a master password. As I understand it, NSS uses the key3.db to tell whether or not a master password exists, and we do nothing more than copy the file during migration, so I am at a loss to explain why this might happen. At least one of the reporters has confirmed that his original profile has no master password. See bug 506638 for the gory details. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Nelson Bolyard wrote: Neil, if your code to do this is in a patch or checked in somewhere, a pointer to that code would be appreciated. I was going to email you a diff, but it turns out that there's an error in my methodology and I wasn't catching people misusing PL_strfree :-( -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Nelson Bolyard wrote: If you have public redistributable header files that declare the MSVCRT memory guards, please send a pointer to them. Thanks. I can't actually find the documentation I originally read about it; this is the nearest that I get from a search: http://msdn.microsoft.com/en-us/library/aa298452(VS.60).aspx -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Nelson Bolyard wrote: Benjamin Smedberg wrote, On 2009-03-31 08:35: In the other cases, we should just fix the bug, which is (I think) why Neil posted originally. I wish him Godspeed in fixing (or even filing) those bugs. I filed bugs 486404/5 yesterday, and have a possible patch for the former, but I'm not sure of the way forward for the latter. -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Nelson B Bolyard wrote: The problem is in the way that Mozilla builds JEMalloc for FF on Windows. They build a replacement for the Microsoft C RunTime Library. Ah, but I'm hoping that any solution that they manage to implement for the Mac will be portable to VC Express, since it will only replace NS_Alloc/Free, not malloc/free. But please tell us, which libjar has the horrifying number of mismatches? If it's NSS's, we'd like to know about them. I didn't even know NSS had a libjar! And it's not that horrifying, really. PORT_ZFree is a wrapper for PR_Free. The question is: is it correct to allocate with PL_strdup (part of NSPR) and free with PL_Free (also part of NSPR, but part of a separate NSPR shared library) ? I meant PR_Free. There is no PL_Free, AFAIK. There is PL_strfree though. Under which component should I file those bugs in pk12util? If the bug is in a source file under security/nss/cmd then component tools. Yes, it's pk12util.c itself. I don't have a tool that makes it easy. All I did was piggy-back on a feature of the MSVC debug heap, Another feature of the professional package only, sadly. I use VC2005Express... -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Nelson B Bolyard wrote: Neil wrote, On 2009-03-29 17:01: Firefox may want to switch to using the jemalloc allocator on the Mac. Well, I hope it won't mean for the Mac what it has meant on Windows. On Windows, the JEMalloc code can ONLY be built with the non-free professional version of Microsoft Visual Studio, and CANNOT be built with the free version. Consequently, developers who use the free version must build EVERYTHING themselves, and cannot mix and match libraries they build with libraries they download from Mozilla's site. This has greatly increased the perception, among many developers who develop for Windows, that Firefox has effectively reverted to being MoCo's corporate product, and not quite the truly open product that it once was, and still claims to be. It's open, but its components cannot be mixed and matched with builds from other builders, even for the same platform. I'm sure a similar system could be used to enable people to build using VC++ Express, using the jemalloc allocator only for NS_Alloc/Free etc. As I understand it, this is tricky because you can't globally replace malloc/free. While in theory it would be possible to replace NS_Free and/or PR_Free, this runs into problems when the code doesn't match its allocators. Right. In particular, I am counting NS_Free, PR_Free, PL_strfree and free as separate deallocators, Oh, it's worse than that. It you link a shared library or executable with the static version of the c run time on Windows, then that shared library/executable has its own heap. It's free is a different deallocator than the free in other shared libs. So, unless you're careful to completely avoid linking with static C run time libraries, every library's free is a separate deallocator. This wouldn't be so bad if everyone avoided using static c RTL, but Mozilla actually recommends that people DO use the static RTL, to work around the afore-mentioned problem with JEMalloc on Windows. :( Ah yes, I hadn't considered that someone might try to use free on memory allocated with malloc in a separate module. which might strike you as a bit harsh, as you probably only need to care about NS_Free. That's an interesting statement. It suggests some mismatch between the people you intended to read this message, and the people who actually read the dev-tech-crypto mailing list. Developers of NSS and NSPR _NEVER_ use NS_Free and never care about it. They all hang out in dev-tech-crypto. Thanks for clearing that up. Developers of PSM (which is part of Necko or Gecko, I think) care about all of those allocators you mentioned. They occasionally (but somewhat rarely, I think) hang out in dev-tech-crypto. I don't know where else they hang out. That's a shame, because I'd like to know! Developers of mail/news are yet a third breed. :) They don't hang out in dev-tech-crypto at all, AFAIK. (sniffle) Note that nsXPIDLCString and .Adopt() counts as an NS_Free, while nsCRT::strdup counts as a PR_Malloc, That sounds confusing. and I'm currently lumping PR_smprintf_free in with free, and PORT_Free with whatever it calls. Hmm. All the PR_ functions use free, which is the free for NSPR's heap. I think of all the PR_ functions as having their own heap, for which the free function (as seen by code outside of NSPR) is PR_Free. So, effectively, PR_smprintf_free is the same as PR_Free, both using NSPR's heap. You're right, I had misremembered. I put it down to the earlier confusion! PORT_Free is a wrapper for PR_Free. NSS tries pretty hard to only use NSPR's allocator for allocation of any objects whose addresses NSS may give out to its callers. NSS may occasionally use malloc/calloc/free for data items that are always purely private to NSS, never being passed to other libraries to (potentially) be freed by those other libraries. If you find a place where NSS allocates memory using a non-NSPR allocator and passes that memory to code outside of NSS to be freed, that's a bug. I instrumented the code and I ran all the mochitests (which include some SSL) and I could only find a few (20) allocator mismatches in Gecko/Toolkit. By comparison, there are a horrifying number of allocator mismatches in mailnews (nsDirPrefs.cpp on its own manages to use one deallocator for a variable allocated by one of three allocators) and several in libjar, narrowly relegating you to third in a hypothetical hall of shame. (I haven't filed bugs on mailnews or libjar yet either.) I wonder who is the you relegated to third place. NSS? PSM? mailnews? Which libjar? There are two. NSS has one used in NSS utility programs, and Firefox has one. Firefox doesn't use NSS's and NSS utilities don't use Firefox's. See http://mxr.mozilla.org/mozilla/find?string=jar%2Ftree=mozilla Thanks for the clarification. Using the above criteria, I found the following allocator mismatches under
Allocator mismatches
Firefox may want to switch to using the jemalloc allocator on the Mac. As I understand it, this is tricky because you can't globally replace malloc/free. While in theory it would be possible to replace NS_Free and/or PR_Free, this runs into problems when the code doesn't match its allocators. In particular, I am counting NS_Free, PR_Free, PL_strfree and free as separate deallocators, which might strike you as a bit harsh, as you probably only need to care about NS_Free. Note that nsXPIDLCString and .Adopt() counts as an NS_Free, while nsCRT::strdup counts as a PR_Malloc, and I'm currently lumping PR_smprintf_free in with free, and PORT_Free with whatever it calls. I instrumented the code and I ran all the mochitests (which include some SSL) and I could only find a few (20) allocator mismatches in Gecko/Toolkit. By comparison, there are a horrifying number of allocator mismatches in mailnews (nsDirPrefs.cpp on its own manages to use one deallocator for a variable allocated by one of three allocators) and several in libjar, narrowly relegating you to third in a hypothetical hall of shame. (I haven't filed bugs on mailnews or libjar yet either.) Using the above criteria, I found the following allocator mismatches under security/* nsNSSCallbacks.cpp: HandshakeCallback calls Adopt(cipherName) instead of Assign and PORT_Free. In fact, it can leak cipherName. nsNSSCertificate.cpp: several times it Adopt()s the result of CERT_Hexify, when it should use PORT_Free. nsNSSIOLayer.cpp: both adopts the result of and allocates an outparam using nsCRT::strdup, when both times it should use NS_strdup, while SSL_RevealURL allocates with PL_strdup but charCleaner uses PR_FREEIF. nsSSLStatus.cpp: allocates an outparam using PL_strdup, when it should use ToNewCString. pk12util.c: uses PR_Free for a string allocated with malloc, and PORT_ZFree for a string allocated with PL_strdup. Would you be interested in patches for some or all of these? Who would want to review them? -- Warning: May contain traces of nuts. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Validation (OCSP) Preferences
Kai Engert wrote: It will also mean that at runtime, each time the browser verifies a web site cert, we'll have to query two preferences instead of just one (see implementation of and callers to function GetIsOcspOn). Ah, I had overlooked that version; I thought it was all done via the pref observer in nsNSSComponent.cpp, but I think I have an idea that might resolve that: setting the security.OSCP.enabled pref to zero should also set the new pref appropriately. I think you work primarily on SeaMonkey. Given that the backend code is shared amongst multiple apps, what are your plans wrt Firefox, Thunderbird, etc? The UI code removal should be easy to port. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Validation (OCSP) Preferences
Bug 110161 turned on OCSP by default. It also followed this up by changing the UI from a group of three radio buttons to a checkbox and a pair of radiobuttons. However these three controls fight over the same preference. This makes for some hairy preference code, but also I noticed that if you used to use a specific signer, then if you turn OCSP off and close preferences then it will forget that fact, so you can't just turn it back on again. (With the old triple radiobutton this was obvious behaviour.) My suggestion is to create a new boolean security.OCSP.disabled pref that defaults to false and therefore does not affect existing behaviour but can be toggled through appropriate UI to override the security.OCSP.enabled pref. This will mean that the current checkbox and radiobuttons can by updated to refer to the separate preferences and the linked preference updating code can be removed. Assuming that nobody has any objections I hope to work on the backend later this week. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Wan-Teh Chang wrote: I'm not sure if it's still worth implementing the real fix now -- it is easier to ask the affected people to blow away their dist/public/nss directory in their build trees. Even in depend builds, Mozilla's root makefile still automatically blows away all of dist/include to avoid such problems... do dist/public and dist/private need to be added to that list too? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Wan-Teh Chang wrote: On Sun, Feb 24, 2008 at 3:15 AM, Neil [EMAIL PROTECTED] wrote: Even in depend builds, Mozilla's root makefile still automatically blows away all of dist/include to avoid such problems... do dist/public and dist/private need to be added to that list too? Yes, just add a comment to explain that dist/public and dist/private are used by NSS (its coreconf build system). They are equivalent to Mozilla's dist/include. I filed bug 419340. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Nelson Bolyard wrote: I'd like to get a dependency tools for Windows again. I guess there's one as part of Mozilla, but I don't want to have to build the whole browser to get a dependency tool. While the Mozilla build system can build its own, I'm not sure NSS is up to the task, specifically on cross-compiled builds... -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
It doesn't seem to be my cross-compiler; I updated my regular MSYS/VC7.1 build for comparison and lo and behold it won't compile pkix_pl_ldapcertstore.c either. A build on a third PC oddly fails to stop after that error and instead continues until it fails to load shlibsign due to a missing import. Nelson Bolyard wrote: Neil wrote, On 2008-02-22 17:05: On second thoughts the problem seems to be that someone is including pkix_pl_oscpcertid.h before pkixt.h Doesn't the compiler name the .c file that it's trying to compile when this error occurs? pkix_pl_ldapcertstore.c is the first - I fiddled with its includes but then other files don't compile instead. In any case, I'd guess the right fix is for pkix_pl_oscpcertid.h to include pkixt.h, since it depends on types defined there. Sadly that doesn't work either, this time failing to include pkix_pl_pki.h, still while compiling pkix_pl_ldapcertstore.c I think pkix_pl_ocspcertid.h tries to include pkixt.h via pkix_pl_common.h but the problem there is that pkix_pl_ocspcertid.h was included from pkix_pl_common.h via pkix_pl_ldapresponse.h so the recursive include guard prevents pkixt.h from being defined. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Nelson Bolyard wrote:
In any case, I'd guess the right fix is for pkix_pl_oscpcertid.h to include
pkixt.h, since it depends on types defined there.
The build still didn't succeed. This is also now with a normal MSYS
VC7.1 SeaMonkey build, which produces this (partial) output:
make[6]: Entering directory
`/c/seamonkey/mozilla/security/nss/lib/libpkix/pkix_pl_nss/module'
cl -Foc:/seamonkey/mozilla/nss/pkixmodule/pkix_pl_ldapcertstore.obj -c
-Od -Z7 -MDd -W3 -nologo -DXP_PC -DSHLIB_SUFFIX=\dll\
-DSHLIB_PREFIX=\\ -DSHLIB_VERSION=\\ -DDEBUG -D_DEBUG -UNDEBUG
-DDEBUG_Neil -DWIN32 -D_WINDOWS -D_X86_ -DWIN95 -DNSS_ENABLE_ECC
-DUSE_UTIL_DIRECTLY -Ic:/seamonkey/mozilla/dist/include/nspr
-Ic:/seamonkey/mozilla/dist/include
-Ic:/seamonkey/mozilla/dist/public/nss
-Ic:/seamonkey/mozilla/dist/private/nss
-Ic:/seamonkey/mozilla/dist/include
-Ic:/seamonkey/mozilla/dist/public/dbm
/c/seamonkey/mozilla/security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_ldapcertstore.c
pkix_pl_ldapcertstore.c
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2575) : error C2143:
syntax error : missing ')' before '*'
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2575) : error C2081:
'PKIX_PL_OcspCertID' : name in formal parameter list illegal
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2575) : error C2143:
syntax error : missing '{' before '*'
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2576) : error C2371:
'PKIX_PL_Date' : redefinition; different basic types
c:/seamonkey\mozilla\dist\public\nss\pkixt.h(145) : see
declaration of 'PKIX_PL_Date'
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2576) : error C2143:
syntax error : missing ';' before '*'
c:\seamonkey\mozilla\dist\private\nss\pkix_pl_pki.h(2577) : error C2370:
'PKIX_Boolean' : redefinition; different storage class
c:/seamonkey\mozilla\dist\public\nss\pkixt.h(191) : see
declaration of 'PKIX_Boolean'
(...further errors...)
I think the C2143/C2371 errors are caused by it failing to parse
PKIX_PL_OcspCertID. I'm really confused now - pkixt.h must be included,
so why isn't its typedef of PKIX_PL_OcspCertID being recognised?
--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Nelson Bolyard wrote: Neil, here's what I find strange about all this. The code you cite builds and runs, without error, continuously, on a whole bunch of tinderbox systems That's because a number of factors are required to trigger this bug: 1. The bug does not affect clobber builds, because dist/public/nss/pkixt.h is deleted by definition 2. The bug does not affect systems that support symlinks, because dist/public/nss/pkixt.h is simply a reference to the real pkixt.h, and so never goes out of date, and therefore it doesn't matter which pkixt.h the compiler uses. However with Windows depend builds, such as mine or tpol (see my other post regarding tpol), dist/public/nss/pkixt.h is stale, and causes the compilation errors. What does the NSS build system do to prevent stale headers from polluting dist/public/nss? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Step-by-step instructions on creating test email certificates
Nelson Bolyard wrote: That user cert you created doesn't have an email address in it. Sorry, my bad; I couldn't cut and paste and I overlooked the [EMAIL PROTECTED], in the command line for the email cert. I suggest you try both (in separate certs). They both seem to work, but I like the cert the modern way produces best. Oh, and one question. Is that p,p,p really necessary? The 'p' override flags should not be necessary. Please try -t ,,. Yes, that seems to work too. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Problems building trunk
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error *pkix_pl_OcspCertID_RegisterSelf(void *plContext);
PKIX_Error *
PKIX_PL_OcspCertID_Create(
PKIX_PL_Cert *cert,
PKIX_PL_Date *validity,
PKIX_PL_OcspCertID **object,
void *plContext);
Unfortunately pkixt.h contains
typedef struct PKIX_PL_OcspCertIDStruct PKIX_PL_OcspCertID;
I can't get my compiler to accept this. Is this a compiler bug?
--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Wan-Teh Chang wrote:
On Fri, Feb 22, 2008 at 4:35 PM, Neil [EMAIL PROTECTED] wrote:
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error *pkix_pl_OcspCertID_RegisterSelf(void *plContext);
PKIX_Error *
PKIX_PL_OcspCertID_Create(
PKIX_PL_Cert *cert,
PKIX_PL_Date *validity,
PKIX_PL_OcspCertID **object,
void *plContext);
Unfortunately pkixt.h contains
typedef struct PKIX_PL_OcspCertIDStruct PKIX_PL_OcspCertID;
I can't get my compiler to accept this. Is this a compiler bug?
Can you try adding a forward declaration to pkixt.h
struct PKIX_PL_OcspCertIDStruct;
before that typedef?
Actually I wasn't clear; it's pkix_pl_oscpcertid.h that my compiler
doesn't like, because it doesn't understand PKIX_PL_OcspCertID, but I
can try that forward declaration anyway if you like.
--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems building trunk
Neil wrote:
Wan-Teh Chang wrote:
On Fri, Feb 22, 2008 at 4:35 PM, Neil [EMAIL PROTECTED] wrote:
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error *pkix_pl_OcspCertID_RegisterSelf(void *plContext);
PKIX_Error *
PKIX_PL_OcspCertID_Create(
PKIX_PL_Cert *cert,
PKIX_PL_Date *validity,
PKIX_PL_OcspCertID **object,
void *plContext);
Unfortunately pkixt.h contains
typedef struct PKIX_PL_OcspCertIDStruct PKIX_PL_OcspCertID;
I can't get my compiler to accept this. Is this a compiler bug?
Can you try adding a forward declaration to pkixt.h
struct PKIX_PL_OcspCertIDStruct;
before that typedef?
Actually I wasn't clear; it's pkix_pl_oscpcertid.h that my compiler
doesn't like, because it doesn't understand PKIX_PL_OcspCertID, but I
can try that forward declaration anyway if you like.
On second thoughts the problem seems to be that someone is including
pkix_pl_oscpcertid.h before pkixt.h but I'm not sure how to verify this
as I'm cross-compiling, which isn't supported in NSS as far as I know.
--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Step-by-step instructions on creating test email certificates
Nelson B Bolyard wrote: Neil wrote, On 2008-02-20 16:33: It seems that building SeaMonkey will include certutil Do SM builds build all the NSS commands? That seems like a big waste. Sorry, I hadn't looked closely enough, I see that I have the source, but the first step would be to build certutil ;-) Would someone mind providing a command line that will do the job, preferably installing the certificate directly into my test profile (with the test email address [EMAIL PROTECTED])! Tell us a little more about the certs you want. Self signed? Self signed is fine; I'm not actually going to send mail with them, I just need to test the UI! -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Step-by-step instructions on creating test email certificates
I've been asked to review a patch that enhances the multiple identity UI in Thunderbird/SeaMonkey by allowing email certificates to be selected on a per-identity basis, rather than just for the main identity. It seems that building SeaMonkey will include certutil which looks as if it is more than capable of the task but unfortunately the raft of options make no sense at all to me nor was I able to find any examples of creating email certificates. Would someone mind providing a command line that will do the job, preferably installing the certificate directly into my test profile (with the test email address [EMAIL PROTECTED])! Thanks in advance, Neil. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Wan-Teh Chang wrote: NSS uses LD on Unix (including Linux and Mac OS X), and LINK on Windows, to refer to the linker. It also uses $LINK_DLL on Windows and $MKSHLIB everywhere else. How inconsistent :-( -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Wan-Teh Chang wrote: None of the NSS developers cross-compiles NSS. (The closest thing we do to cross-compilation is to build the Windows CE binaries on Windows 2000/XP.) So we're not familiar with how the Mozilla developers cross-compile NSS. I don't think many Mozilla developers cross-compile NSS either ;-) except perhaps Intel Mac - PPC. You'll see that the Mozilla developers override these make variables used by the NSS coreconf build system when cross-compiling NSS: 199 ifdef CROSS_COMPILE 200 DEFAULT_GMAKE_FLAGS += \ 201 NSINSTALL=$(NSINSTALL) \ 202 NATIVE_CC=$(HOST_CC) \ 203 CC=$(CC) \ 204 CCC=$(CXX) \ 205 LINK=$(LD) \ 206 AS=$(AS) \ 207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \ 208 RANLIB=$(RANLIB) \ 209 RC=$(RC) $(RCFLAGS) \ 210 OS_ARCH=$(OS_ARCH) \ 211 CPU_ARCH=$(TARGET_CPU) \ 212 $(NULL) 213 SKIP_CHK=1 214 endif Yes, and this is the cause of the third issue in my original post :-( I wonder why NSS uses LINK instead of LD? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Nelson B wrote: I suggest that you first try to get NSS to build for you in its stand-alone configuration, using only NSS's makefiles and not any of the other mozilla products' makefiles. Where would this be documented, with specific reference to cross compilation? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Using MSVC as a cross compiler
Myself using Interix and Mook using Wine have both tried to cross-compile Mozilla using MSVC as a cross compiler. Generally I would like to think that NSS has been the easiest part to cross compile, but here are the issues we ran into: 1. Because we're not using GCC or MSYS, rules.mk tries to run cygpath -w `pwd` which fails because we have no cygpath. 2. AR does not get set correctly because AR_FLAGS contains $@ 3. LINK fails to run because the environment contains LINK=link which it sees as a request to link link.obj 4. RC fails to run because some of the NSPR includes can't determine the target processor (_X86_ does not get defined) 5. Because he was using VC8 Mook also had some issues with manifests. I would be happy to write patches for these if you would advise me as to whether my ideas are useful. 1. I wrapped the code in a test for NATIVE_CC; Mook used CROSS_COMPILE but I think that relies on you exporting it from the shell. 2. AR='$(subst $@,$$@,$(AR) $(AR_FLAGS))' (Mook used a similar construct) 3. Mook prefixed LINK= $(LINK) to temporarily clear the variable; my suggestion is to rename $(LINK) to $(LD) in the makefile 4. Currently we work around this by preventing rc from including seccommon.h but I'd appreciate ideas for how to persuade NSS that i686 is _X86_ 5. I don't know about this, but I could ask Mook to chime in if you thought it would be useful. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS dll dependencies -- nspr4.dll and libnspr4.dll
Steve Mitchell wrote: It is confusing deploying JSS on Windows XP. The library jss4.dll depends on libnspr4.dll, not nspr4.dll as is installed with Firefox. Other dependent libraries such as nss3.dll depend on nspr4.dll. Should I copy and rename nspr4.dll to libnspr4.dll, or are these supposed to be different libraries? There is no useful guidance on the Using JSS page. --Steve Steve, there are 2 versions of NSPR libraries for Windows. They differ in their use of the underlying threading used. Are you trying to use the same NSS/NSPR libraries that Firefox uses? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
