Daniel Stenberg wrote, On 2008-06-25 01:18: > Nelson B Bolyard <nelson <at> bolyard.com> writes: > > (replying a bit out of context to sorry if the threading is not kept > perfectly intact)
Welcome, Daniel! >>> 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. Cool. > 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. No doubt. But NSS is "upstream" of many many open and close source projects. We can't (and don't try to) monitor all the development going on in all the downstream projects that use NSS. We surely don't even know what all projects use NSS. I do try to USE products that use NSS when I can, when I have need for them. That's why I use Mozilla clients, and AOL Instant Messenger, Open Office, and others. > Of course I hope that I can contribute with input and feedback that helps > to improve NSS for the future. Please feel welcomed and invited to do so. >>> 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. 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. > 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. >> 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? Yeah, it depends on another product, NSPR, whose tarball is also available from ftp.mozilla.org, and which is also supplied in many distros. > 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. > 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. >> 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. Glad you're amused. :) I was showing my bad attitude towards blogs. I'm glad you've joined the NSS list/group. That's the right thing. >> 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. Hmm. Well, filing a bug there is best, and asking someone here to do it is a close second. I'd suggest that you register a mailing address with bugzilla.mozilla.org so that you can be added to the "CC list" for bugs of interest to you. Being registered with b.m.o has not proven to be a big trigger of spam (unless you consider the bugmail itself to be spam. :) Wan-Teh filed a bug today on your behalf. I'd suggest you add yourself to the cc list there. You can also add comments to it. https://bugzilla.mozilla.org/show_bug.cgi?id=441820 > 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 ([...] using it, APIs etc) On the web sites www.mozilla.org wiki.mozilla.org developer.mozilla.org all searchable with google, et. al. My favorite way to search for NSS docs is to use the search on the home page for www.mozilla.org. <http://www.mozilla.org/projects/security/pki/nss/#documentation> <http://www.mozilla.org/projects/security/pki/nss/release_notes.html> <http://developer.mozilla.org/en/docs/Category:NSS> <http://developer.mozilla.org/en/docs/NSS_reference> > * info about processes such as mailing lists, development and bug tracking That's on the web sites too, e.g. <http://www.mozilla.org/projects/security/pki/nss/> > * building from source <http://developer.mozilla.org/en/docs/NSS_reference:Building_and_installing_NSS> <http://www.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-build.html> > 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. 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. There is comparatively little documentation about that browser glue code, named PSM, I believe. see <http://www.mozilla.org/projects/security/pki/psm/index.html> There also exist browser build instructions on mozilla's sites, but they don't contain much info about NSS, and I don't point anyone to them when they ask anything about NSS. >> 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). Yup, listed right at the top of numerous web pages on mozilla.org, e.g. <http://www.mozilla.org/projects/security/pki/nss/index.html> <http://www.mozilla.org/projects/security/pki/nss/overview.html> <http://www.mozilla.org/projects/security/pki/nss/faq/index.html> <http://www.mozilla.org/projects/security/pki/nss/ref/ssl/index.html> <http://www.mozilla.org/projects/security/pki/nss/ssl/index.html> <http://www.mozilla.org/projects/security/pki/pkcs11/index.html> <http://www.mozilla.org/projects/security/pki/jss/index.html> ... _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
