Simon Josefsson wrote:
>
> > The "correct" way to SSL-ify a program that does not already use NSPR
> > is to implement your own PRFileDesc. You will have to implement the
> > relevant I/O methods in PRIOMethods table.
>
> Aha! I didn't know that.
>
> So, is this picture about right: define a PRIOMethods table that point
> to my functions, use PR_CreateIOLayerStub() to get a PRFileDesc for
> the new layer, which I pass as the `model' parameter when I call
> SSL_ImportFD()? Then whenever the SSL layer wants to read anything,
> my callbacks will be used?
Yes, you got it right.
> Seems like much additional code and
> complexity without any real benefit over PR_ImportTCPSocket(), so I
> might stick with it for a while.
I have to say yes. As long as you understand the limitations of
PR_ImportTCPSocket() it is a convenient solution to your problem.
In your case it will work for you.
Another note: if you call PR_Close() on the imported PRFileDesc, it
will not only free the PRFileDesc but also close the Unix file
descriptor embedded in it. So your code should not close the Unix
file descriptor.
> The NSS tarball didn't include NSPR libraries, and the only binary
> distribution of NSPR I found was for Java. But I did not spend very
> much time searching.
OK, those jar files are actually zip files. So you can unpack them
with unzip. We are planning to provide NSPR 4.1.1 binary distributions
as tar.gz files on Unix and zip files on Windows to avoid this common
confusion.
Wan-Teh
