Re: TLS-SRP (was Re: J-PAKE in NSS)
On Wed, 9 Mar 2011, Anders Rundgren wrote: It is too late introducing TLS-SRP, the market will not use it. Uh? There's not just one single market that will or won't use a particular protocol feature. There are plenty of different areas where TLS is used and some of them will use TLS-SRP, and some even already are. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
On Mon, 7 Mar 2011, Brian Smith wrote: But Curl, that supports secret keys from version 7.21.4, with GnuTLS only at the moment but is pushing hard to get in in Openssl also, apparently has simply given up about having TSP-SRP support when compiled with NSS. Can I just add that we (in the curl project) haven't given up on anything - we're an open source project and we will of course support whatever our users and developers want and make happen. curl supports 7 different SSL libraries (including NSS) and if some of the libs don't have the necessary features, we provide these specific features only when built with a lib featuring them. TLS-SRP is an example of a feature that seemingly only GnuTLS delivers out of the box right now. An augmented PAKE user authentication protocol might be very useful for some things, but TLS-SRP seems very troublesome. IIRC, there are at least four deal-breaking problems with TLS-SRP as a substitute for PKI: There are places for both ways I'd say, and it seems there are users out there who think so. I don't think many people argue that it substitutes PKI to any greater extent. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Extrace Mozilla trusted certs into PEM files?
On Thu, 6 Aug 2009, Eddy Nigg wrote: Yes, that was Curl and here the link to the page http://curl.netmirror.org/docs/caextract.html and this is the tool: http://curl.netmirror.org/docs/parse-certs.txt Please don't use that site. It is an outdated mirror with old contents. :-( The current page is at http://curl.haxx.se/docs/caextract.html and you'll note that it features a different script. The old one was so kludgy, slow and hard to read we had to let it go. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Sat, 21 Mar 2009, John D wrote: I wonder how thread safe NSS' integration with libcurl actually is. No offense Daniel but after switching to gnutils with their macros all problems related to this matter are resolved. So be it. I'm absolutely sure on how we use NSS in libcurl, and the nss.c code is not even particularly big or complicated so basically everyone who wants to can go see. To the best of my knowledge, libcurl is using NSS as it is documented but as I've whined before on this very mailing list: the NSS API documentation is not exactly crystal clear in all aspects so of course things might not be perfectly done. I think it can be helpful to the NSS project and to libcurl's NSS-interfacing code if you'd follow Wan-Teh's advice and help us get some further details on those problems and thus possibly improve things. Even if you obviously can avoid them by switching to another lib. I don't understand why I would take offense but no, I didn't. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Fri, 20 Mar 2009, Nelson B Bolyard wrote: It would be inappropriate for NSS to defeat sigpipe's signal handler. The handling of that signal is the responsibility of the application, or code at a higher level than NSS. Perhaps it would be appropriate for libcurl to do that. SIGPIPE is a signal and signals are dreaded in multi-threaded apps in general. What useful purpose does it serve the users of NSS? libcurl protects all its own uses of socket functions against generating SIGPIPE, and it makes all libraries it use to do the same to the extent they allow. Mostly because we don't see any point in them. If NSS had a way to make them stop, libcurl would use it. Does it? And if its inappropriate for NSS to defeat sigpipe's signal handler, why isn't it the same for libcurl? And if it is, the responsibility comes to the application and then you get the mix of signals and threads. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Fri, 20 Mar 2009, Wan-Teh Chang wrote: But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that this is done for self protection, rather than as a documented service to the NSPR client. But doesn't this then contradict what was just said? But why only during initilization? If it's fine to survive a dead peer during init and not signal anything, why isn't it later? So the issue is why you receive SIGPIPE while calling NL_VersionCheck (). This implies that NSPR hasn't been initialized at that point. John D, what is calling NL_VersionCheck() before th PR_Init() call? libcurl does nothing SSL at all before calling PR_Init() as far as I can see!? -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Fri, 20 Mar 2009, John D wrote: Each thread created, will call a function that runs a curl easy setopt operation. John: Do you call the curl_global_init() before you start any threads and use libcurl? Can you get some further symbols in the stack trace to help me/us with seeing who calls what and when? NSS team: Is PR_Init() thread-safe? -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Fri, 20 Mar 2009, Wan-Teh Chang wrote: I didn't mean that SIGPIPE is ignored only during NSPR initialization. I meant that NSPR's initialization function calls sigaction to ignore SIGPIPE. Oh, well that might just've been me being thick sorry. Still I read you now loud and clear, thanks! -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSSSSL_VersionCheck Sigpipe with curl
On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote: NSS team: Is PR_Init() thread-safe? No, it is not thread-safe by definition, and must be called and completed before any other call to NSPR functions are made in any other thread. Typically, PR_Init is called in the primordial thread. Thank you. I suspected this, but the docs page said nothing about it so I felt I better ask. John, is that possibly the key to your problem? curl_global_init() is documented to be called first, it is documented not thread-safe and it calls PR_Init()... If curl_global_init() isn't called, libcurl will call it by itself on first use of another function but you're using threads so I would guess you get a bad race then and thus anything can happen! -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: selling the MITM
On Sat, 10 Jan 2009, Nelson B Bolyard wrote: http://www.ssl-inspector.com/ Others: http://www.finjan.com/content.aspx?id=190 http://www.breach.com/assets/files/downloads/breachviewssl_whitepaper.pdf http://hosteddocs.ittoolbox.com/541_BlueCoat_SSL_Accel_wp_v3d.pdf http://www.accusys.com/BCS_SSL_wp.pdf I've been curious on how these devices deal with self-signed certificates. Does anyone know? I mean does it hide them the same way or does it generate fake self-signed ones for those? -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Extracting and/or documenting Firefox's trusted root certs
On Wed, 20 Aug 2008, Wan-Teh Chang wrote: certutil: function failed: security library: bad database. 'DB' is the directory that contains your NSS databases. Thanks for that and sorry for not doing my home work properly. This turns out to generate a rather interesting list. Using my currently installed db set I get 126 names, but the certdata.txt file in the Mozilla CVS repo ( $Revision: 1.45 $ $Date: 2008/01/17 ) contains 124 (using make ca-bundle in the curl build tree). Diffing the list of names show my db contains 3 more names and one less than certdata.txt. Is this a bug in our source to PEM script, or what does it mean? I would expect the two lists to be identical, or is that just another bad assumption on my part? Are we using the wrong certdata.txt file? The file our script downloads and converts to PEM is this: The certdata.txt is downloaded from here: http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 The conversion script uses the openssl tool and is found here: http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Extracting and/or documenting Firefox's trusted root certs
On Thu, 21 Aug 2008, Kyle Hamilton wrote: The current certdata.txt in the repository is not the one that generated your version of Firefox. (There have been a couple of changes in the past couple of months, and no client releases.) But where is the certdata.txt that was used for my Firefox release then? The one I mentioned was last updated in January 2008. -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Extracting and/or documenting Firefox's trusted root certs
On Tue, 19 Aug 2008, Nelson Bolyard wrote: Here's a simple (?) shell script to do it. Great! certutil -L -h 'Builtin Object Token' -d DB What exactly is 'DB' in this context? My firefox 3 directory has three .db files, and trying them all one by one makes certutil with the command line above say: certutil: function failed: security library: bad database. (Debian Linux 32bit here, nss 3.12.0, Firefox 3.0.1 although named iceweasel...) -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Questions on NSS_Shutdown () and Firefox crash
On Sun, 17 Aug 2008, Kyle Hamilton wrote: OpenSSL does not have a root-certificate program. The official position (from http://www.openssl.org/support/faq.html#USER16) is that the job of OpenSSL is to create the code to make trust possible, not dictate who to trust. In fact, that same FAQ entry has a pointer to an article on extracting the certificates from Mozilla's certdata.txt. (I don't know if that file even exists in the current source, though; if it doesn't, perhaps it might be nice to send them a message on how to extract from the .db files?) I'd love to read such a description. (I even host such an extration service that provides the Mozilla bundle as a PEM file... so yes, that file still exists!) -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Questions on NSS_Shutdown () and Firefox crash
On Sat, 16 Aug 2008, Nelson B Bolyard wrote: curl is completely independent from browsers, and when installed in systems it usually uses the system-wide CA cert bundle. Of course it has command line options to allow the user to specify what CA bundle to use (or indeed other certs etc). Daniel, thank you for that observation. It tells me that cURL is designed around the OpenSSL idea that the set of trusted certs is a system-wide set, rather than a per-user set. Well, I don't think this is a curl or any other app thing. Most people install an app and they get some default install. Even NSS users such as Firefox bring a CA cert bundle that they think the user should use. For a typical user of curl or Firefox, they have no idea who provided the ca cert bundle or if it is user-specific or system-specific. Not to mention that many systems these days are private machines so system == user. This said, curl is an app that uses libcurl and libcurl can be built to use OpenSSL, GnuTLS or NSS and we make our best to not make the choice of SSL/TLS library affect how the app is used... Previously, someone criticized NSS, saying that it was designed for use only on single-user systems, a criticism that I dispute. NSS is very much oriented toward each user have his own set of trusted flags. In contrast to NSS, the idea that there is only one system-wide set of trusted certs, and that each user does not have his own set, is a very single-user-system approach. Now you're putting words in my mouth. At no point did I say that any of the other libs prevents or even makes it hard to use user-speciecied certs. I don't think they do. But they do make it easy to use PEM certificates, and Linux distros these days ship CA certs in PEM format. Lots of apps use that system-wide ca cert bundle (by default), but NSS built apps do not. The NSS-apps either don't have any ca cert bundle at all or they find out which one Firefox uses and get that... (or in Fedora's case they run a patch for NSS that makes it capable of reading the system-wide PEM file) Perhaps it is most appropriate for cURL to follow the OpenSSL system-wide cert store model when using OpenSSL, and to follow the NSS cert store for each user model when using NSS. Eeep. OpenSSL does not have a system-wide cert store model any more than NSS does afaik. Most Linux distros do however provide a system-wide ca cert bundle for all apps that can read PEM. (This does not force any user to use that bundle.) -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
On Sat, 26 Jul 2008, Nelson Bolyard wrote: As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that GnuTLS has flaws in its API but NSS most certainly also has flaws as well _and_ notable missing features that GnuTLS offers. Daniel, please tell us what features are missing that you would actually use if they were present! Well, I'm a newbie in NSS land so I don't know the full story of what has happened in your project that has lead to the results we see today. So I may of course now step on just about every toe you have! :-) But an obvious example of a shortcoming is concerning support for the PEM format for CA cert bundles and certs in general (as it is very awkward for me to document, use and describe for users they need to change their ways if they happen to build my app with NSS instead of OpenSSL or GnuTLS). It seems we have a situation where Fedora (Redhat?) provides some special plugin(s) for NSS that allows NSS to load and use PEM files where the native NSS doesn't. And of course, what some considers a feature, others may not. -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Use PEM formatted certs (was Re: Comparison of OpenSSL and NSS)
On Mon, 28 Jul 2008, Nelson B Bolyard wrote: NSS is quite capable of importing certificates in PEM format. Importing them where? If I want to use NSS for the TLS layer and I have the ca cert in a PEM format file, how can I make NSS use that file when I connect to the peer? My current code has a configure check and thus #ifdefs in the code for a PK11_CreateGenericObject() function that apparently can be used for this, but I've not found the source for that lib/plugin (libnsspem.so) so I've failed to test this myself. -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
On Sat, 26 Jul 2008, Michael Ströder wrote: http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/18#comment:1 (Well, they even aren't keeping their issue tracker spam-free...) Please, spam is hardly their fault and I don't think you help them any way by being rude. As a user of OpenSSL, NSS, yassl and GnuTLS I can certainly agree that GnuTLS has flaws in its API but NSS most certainly also has flaws as well _and_ notable missing features that GnuTLS offers. So no high horses here please. (and no, I'm not involved with the GnuTLS project but I brought up their comparison page here) -- / daniel.haxx.se___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
On Wed, 23 Jul 2008, Ruchi Lohani wrote: Since a lot of open source softwares are using NSS, I wish to know whether we have some documentation on specifics of OpenSSL and NSS and the advantages NSS has over OpenSSL. If so, can anybody direct me over that or just give a brief comparison of both. If you can stand a comparison that also involves GnuTLS, then the GnuTLS guys have one: http://www.gnu.org/software/gnutls/comparison.html -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ssh/sftp with nss/nspr?
On Fri, 18 Jul 2008, Matt Lawson wrote: 2. Implement the ssh and sftp protocols over NSS's SSL sockets myself If you go this route, I'd suggest you instead get libssh2 (www.libssh2.org) and just port it to be able to use NSS. It can currently be built to use either OpenSSL or GnuTLS so parts of that infrastructure is there already. -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support in cURL
On Wed, 25 Jun 2008, Nelson B Bolyard wrote: That sounds great. Of course there's no need to do anything LSB, you could just at this very moment establish a subdir (called say nss) that you use for your public headers and make sure that's the way all distros would use. We don't have much control over what the downstream distros do to (with) NSS. Getting them to all do something the same way has been compared to herding cats. That's one reason we're pursuing LSB. The distros DO seem to want to do things the same way when the LSB says to do that. Right, but if you would install your public headers in [prefix]/include/nss for example and that is what 'make install' does, and your pkg-config stuff (or whatever you provide) would _not_ do -I/usr/include/nss but assume that that applications would #include nss/header.h you would take a signigicant step towards herding the cats in the right direction. If you would do it, I don't see why any distro would not folllow. Distros that currently have taken a route that differs from that could easily just symlink (or similar) their way back to compliance. In my eyes, LSB is far too big and too much of a risk to just stall somewhere to be something to wait for. Besides, once you've decided how you think the CORRECT way is, all of us users can then go out and whine on our distros to follow the upstream suggested way of working these matters. The current flux is terrible for apps trying to use NSS. I'd be open to receiving any more specific information about specific problems in specific distros. The NSS team members just don't spend much time trying out all the different distros that use NSS, so we haven't collected much info about specific issues with specific distros. This specific problem in Debian vs Fedora: Debian: /usr/include/nss Fedora: /usr/include/nss3 Debian's pkg-config --cflags nss returns -I/usr/include/nss -I/usr/include/nspr My configure script can detect NSS fine on both these systems. It can detect how to build my app with NSS. But I cannot include nss/base64.h since I would need to do it #include base64.h and thus it collides with other headers named base64.h. In my case I have a private header using that name. In fact we also had a header called nss.h but we renamed that due to this problem. Did you ever try to build the 3.12 from the tarball? Yeah, it depends on another product, NSPR, whose tarball is also available from ftp.mozilla.org, and which is also supplied in many distros. Right, I've been told that now but it certainly was not clear to me when I picked a download. I just wanted to build NSS. First I of course strongly dislike that there's no install/build instructions in the tarball, Yeah, it would be good to put a readme in the tarball that at least points to the web site where all the docs are. I would prefer the build instructions to be bundled with the package I download, as plain text. A README or INSTALL that's easily found. then I dislike that I have to chase around in subdirs of the package to figure out where to build and then when I invoke what I think is the correct build line: There is a nice web page with detailed instructions on how to build NSS and NSPR, including how to get the tools if you don't have them (e.g. shell-like tools for Windows). We expect that people will look on mozilla.org for any docs. The tarball could say that, but doesn't. Right, and that's what parts of my complaint is about. I find the web site hard to navigate and get info from and including this info in the tarballs is normally done by open source products. By not doing this, you decide to act differently than the majority and I can't see any benefits from it. The least-surprise principle is generally good imo. I'll admit that I'm inpatient, but I also consider myself an experienced *nix and open source developer and I know (or thought I knew) exactly what I'm looking for. * docs ([...] using it, APIs etc) On the web sites www.mozilla.org wiki.mozilla.org developer.mozilla.org all searchable with google, et. al. First, this is still my opinion. You listing some URLs don't change this. Second, I want man pages for all functions my app uses or is likely to use. Third, to test your claim picked a random NSS function from libcurl's lib/nss.c file. I googled for SSL_CipherPrefSet to get to read your docs for it. I think it proves my point pretty good: I can't find any official NSS docs for it using google. Possibly one reason why this is hard is that on the NSS pages you tend to create very large html pages listing a vast amount of functions on each page. Actually, all the docs cited above are exactly about building and using NSS stand-alone, by itself, not as part of the browser. The API documentation cited above is all about NSS's own direct API, not about the C++ wrappers that are part of the browser. Right, but the site still
Re: NSS support in cURL
Nelson B Bolyard nelson at bolyard.com writes: (replying a bit out of context to sorry if the threading is not kept perfectly intact) Since NSS support has been added to cURL library, No kidding! When did that happen? Since about February 2007 and at least Fedora 9 ships curl build against NSS these days. I understand that I'll come out and appear as a complete whiner here but I'll ignore that for a second and I'll respond here and stand up for my criticism that is quite obvious if you follow the libcurl development. Of course I hope that I can contribute with input and feedback that helps to improve NSS for the future. Are there any plans going on to make the interface of curl and NSS easier and better ? There's work underway to add NSS to the LSB (the Linux System Base software). As part of that work, I think the issue of the correct path name for include files will get resolved in a consistent manner. That sounds great. Of course there's no need to do anything LSB, you could just at this very moment establish a subdir (called say nss) that you use for your public headers and make sure that's the way all distros would use. The current flux is terrible for apps trying to use NSS. That page mentions a failed attempt to build NSS 3.12 due to missing files of some sort, but it doesn't provide any details. Did you ever try to build the 3.12 from the tarball? First I of course strongly dislike that there's no install/build instructions in the tarball, then I dislike that I have to chase around in subdirs of the package to figure out where to build and then when I invoke what I think is the correct build line: make nss_build_all I pretty soon get this: gcc -o Linux2.6_x86_glibc_PTH_DBG.OBJ/nsinstall -g -fPIC -DLINUX1_2 -Di386 -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 -DDEBUG -UNDEBUG -DDEBUG_daniel -D_REENTRANT -DUSE_UTIL_DIRECTLY -I../../../dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/include -I../../../dist/public/coreconf -I../../../dist/private/coreconf Linux2.6_x86_glibc_PTH_DBG.OBJ/nsinstall.o Linux2.6_x86_glibc_PTH_DBG.OBJ/pathsub.o-lpthread -ldl -lc true -m 775 Linux2.6_x86_glibc_PTH_DBG.OBJ/nsinstall ../../../dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/bin make[2]: Leaving directory `/home/daniel/src/nss-3.12/mozilla/security/coreconf/nsinstall' make[1]: Leaving directory `/home/daniel/src/nss-3.12/mozilla/security/coreconf' make: *** No rule to make target ../../nsprpub/configure. Stop. make: *** [../../nsprpub/configure] Error 1 Problems with the tarball? Did I run the wrong build command? (This is on a recently dist-upgraded 32bit Debian Unstable) Suggestion: NSS problems don't get solved by bemoaning them on blog sites. That's the curl CVS repo. Calling that a blog site is only amusing. People should file bugs in bugzilla.mozilla.org, I actually considered that for a moment but then I got scared by all the complexity and feeling of unsurmountable amounts of information and data that is there. Also, I'm but the primary author of curl and libcurl and we can use five different SSL/TLS libraries and NSS is just one of them. If one of our possible third-party libs is a bit less fine than the others, I just document that knowledge to let my users know about it and then I go on with my life. curl can use something like 10-12 different third party libs and I don't keep up with them all. I'd say that NSS has several weak spots that need to be improved before it becomes a fine member of the big open source family: * docs (building it, using it, APIs etc) * info about processes such as mailing lists, development and bug tracking * building from source In my eyes, NSS seems to suffer from being used primarily as part of Mozilla's tools, so you don't have a proper project web site, docs and info setup for the NSS alone when used separate from everything else on mozilla.org. Like we use it in libcurl. Instead, all the NSS details drown in general Mozilla stuff and assumptions that I would know about mozilla things when all I want is info on NSS as a stand-alone library for SSL/TLS. or at least write to us here in this list (like you did, Ruchi, Thanks!). I didn't even understand what mailing list to use since there's no nss-users nor nss-dev list or anything. dev-tech-crypto you say? (I found your list today through your mention of libcurl when I searched gmane.org). -- / daniel.haxx.se ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
