Hi, thanks for your reply. It's actually good news for me. Some thoughts inline below...
On Apr 5, 3:12 am, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: > NSS depends on NSPR, and attempting to divorce NSS from NSPR is way more > work than (I think) you want to attempt to do. (Quite a few have tried > that and failed.) But the good news is that on systems that support POSIX > threads, NSPR uses POSIX threads under the hood. In a process that uses > POSIX threads, threads that run code that knows about and uses NSPR can > coexist quite nicely with threads that do not. IIRC, it's not necessary > for a thread to be created by NSPR to be usable by NSPR. IIRC, NSPR can > figure out that it's running on a previously unseen POSIX thread and setup > the necessary bookkeeping info for that thread, on the fly. That would work well for me. I have no problem with the NSPR being included, I just can't change my application to rely on NSPR for everything. If the TLS (plugins!) pull inthe NSPR that's fine, as long as they are still able to work with the rsyslog core, which manages the threads they run on. > So, I would say that, for you, the issue concerning the use of NSS+NSPR is > not POSIX threading (should be no problem), but rather is NSPR's sockets. > NSS requires NSPR sockets. The application that calls NSS to do SSL on > sockets must give NSS NSPR socket handles, not native OS FDs. Fortunately, > it's not too difficult to make NSPR socket handles out of OS FDs. That thankfully is not a problem at all. I plan to have an abstraction layer for the TLS functionality (with things along the lines of TLSOpen(), TLSClose(), TLSWrite(), ...) that can use whatever low- level socket implementation it needs to use. I even plan to include a non-TLS "TLS Pretenteder" for testing purposes. Obviously, I need to see how I handle certificates, but I'll prefer to solve these problems as I go along. > I'd say that the conversion of a Unix/Linux/POSIX app to NSS & NSPR is not > heavy lifting. But different folks have different thresholds of "heavy". :) That's the point - it's not a "conversion". Rsyslog heavily uses plugins, loadable modules. The core does not even know that there is some TLS functionality inside some of the plugins. As such, I can/will not touch the rsyslog core. Any need to change the core is a no-go. TLS is just a very small, yet obviously important, part of rsyslog's functionality. I am just pointing this out to convey the big picture. >From what I have read and heard so far, this should be possible. > Maybe someone from Red Hat can suggest some sample converted code from > their consolidation project for you to use as an example I initially thought to begin implementation of my TLS abstraction layer directly with NSS, which I would like to include if at all possible. But I begin to think that it may be smarter to start with GNUTls, get the interface stable and then come back with a focussed view and see how I can do it with NSS too. From what I have seen so far, GNUTls seems to have much better samples and documentation for stand-alone apps. Also it seems to require much less learning, as it is focussed on the TLS task and and does not come with the "burden" (from my POV) of the NSPR (which I seemingly need to understand at least partly, too). But I may be wrong here ;) In any case thanks again for your advise. Any more advise from you and others would definitely be much appreciated. Rainer _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
