On Fri, Sep 19, 2008 at 6:01 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>> I bet you five bucks we can layer SSLClientSocket on top of
>> TCPClientSocket by creating a little nspr i/o layer that
>> talks to a memory buffer. I did this with OpenSSL some time
>> ago, I figure I can do it with nss
On Thu, Sep 18, 2008 at 2:55 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> I bet you five bucks we can layer SSLClientSocket on top of
> TCPClientSocket by creating a little nspr i/o layer that
> talks to a memory buffer. I did this with OpenSSL some time
> ago, I figure I can do it with nss, too.
I was looking at UploadDataStream a while back. I think the windows'isms
were just for reading a file from disk. I think the recommendation was
to make a very basic File class in base or net for reading/writing to a
file and use that class in UploadDataStream. We may even be able to use
some co
I had thought so, too, but on IRC there was some talk of using nss
but interfacing to the native keyring somehow. So who knows.
On Fri, Sep 19, 2008 at 12:58 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> I thought the plans for mac osx did not involve nss. I think we should do
> an implementat
I thought the plans for mac osx did not involve nss. I think we should do
an implementation based on the mac ssl apis so that we get good integration
w/ the keychain or what have you. right?
-darin
On Fri, Sep 19, 2008 at 12:40 PM, Dan Kegel <[EMAIL PROTECTED]>wrote:
>
> On Fri, Sep 19, 2008 a
On Fri, Sep 19, 2008 at 12:19 PM, Mike Pinkerton <[EMAIL PROTECTED]> wrote:
>>> we're "blocked" on getting the win32 out of SSLClientSocket to get http
>>> linking for TestShell
>>
>> Can't you just stub out the SSL bits of HTTP for now? Most (all?) of
>> the layout tests don't need SSL.
>
> Wel
Well, yeah I can certainly do that, but it sounded from the thread
that Dan was already heading down that road, and I wasn't sure how far
he'd gotten. In some quick stubbing, I also ran into windows'isms in
UploadDataStream. Wasn't sure about the plan there.
I wasn't sure how much of the wheel I
On Fri, Sep 19, 2008 at 10:58 AM, Mike Pinkerton <[EMAIL PROTECTED]> wrote:
> Coming into this thread late, I assume everything here applies for Mac
> as well? Right now we're "blocked" on getting the win32 out of
> SSLClientSocket to get http linking for TestShell, so I wanted to see
> if there w
Coming into this thread late, I assume everything here applies for Mac
as well? Right now we're "blocked" on getting the win32 out of
SSLClientSocket to get http linking for TestShell, so I wanted to see
if there was anything we could do to help out -- or if we needed to do
anything at all.
On Fr
On Thu, Sep 18, 2008 at 11:46 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>
> I think it will be very valuable to us to maintain our own layering
> here. It sounds like Dan and you have an idea of how to do it.
>
> Perhaps in parallel--or when time permits--we should work to add the
> APIs to NSS
On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>>
>>> In previous discussion with Darin, it seemed we
>>> wanted to use epoll rather than poll. This
>>> implies that we want to not use NSPR fo
On Thu, Sep 18, 2008 at 4:15 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> If you look at the implementation of the 'poll' method in NSS:
> http://mxr.mozilla.org/security/source/security/nss/lib/ssl/sslsock.c#1567
>
> there are two cases that depend on the internal state of the SSL
> PRFileDesc:
On Thu, Sep 18, 2008 at 3:34 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> On Thu, Sep 18, 2008 at 3:26 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>> I found that I documented the 'poll' method of PRFileDesc
>> http://developer.mozilla.org/en/NSPR_Poll_Method
>
> My guess is I don't need that at
On Thu, Sep 18, 2008 at 3:26 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> I found that I documented the 'poll' method of PRFileDesc
> http://developer.mozilla.org/en/NSPR_Poll_Method
My guess is I don't need that at all. I can tell just by looking at
my buffers what kind of I/O is needed, no n
On Thu, Sep 18, 2008 at 2:55 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> I bet you five bucks we can layer SSLClientSocket on top of
> TCPClientSocket by creating a little nspr i/o layer that
> talks to a memory buffer. I did this with OpenSSL some time
> ago, I figure I can do it with nss, too.
On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> Since we don't have access to the SSL state machine
> inside NSS's SSL library, we have to use PRFileDesc
> and PR_Recv and PR_Send, but we don't need to use
> PR_Poll. We can call the 'poll' method of PRFileDesc
> direct
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>
>> In previous discussion with Darin, it seemed we
>> wanted to use epoll rather than poll. This
>> implies that we want to not use NSPR for our
>> network I/O, and thus implies that we want to
>> write an NSPR I/O layer
On Wed, Sep 17, 2008 at 11:52 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>>> One more data point: we'll also need to support SSL over SOCKS one
>
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>> One more data point: we'll also need to support SSL over SOCKS one
>> day, and that means that the ClientSocket passed to SSLClientSocket
>> will n
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> One more data point: we'll also need to support SSL over SOCKS one
> day, and that means that the ClientSocket passed to SSLClientSocket
> will not be a TCPClientSocket. it will be a SOCKSClientSocket. the
> SOCKSClientS
One more data point: we'll also need to support SSL over SOCKS one
day, and that means that the ClientSocket passed to SSLClientSocket
will not be a TCPClientSocket. it will be a SOCKSClientSocket. the
SOCKSClientSocket will be layered on top of another ClientSocket,
which will be the TCPClient
On Tue, Sep 16, 2008 at 9:42 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> Here's what I'm thinking, please yell if it sounds wrong.
>
> When we implement SSLClientSocket on linux,
> we can do it with one-thread-per-connection,
> or with nonblocking I/O.
> Since all socket I/O goes through the brow
I agree that we should use nonblocking I/O instead of one-thread-per-connection.
On Tue, Sep 16, 2008 at 9:42 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> There's another design choice to make:
> whether to write an NSPR I/O layer so we can use
> our own TCPClientSocket for all network I/O,
> or
libevent is also written by a googler (Niels), I'm sure you could ask him if
there are any questions :)
-Ian
On Tue, Sep 16, 2008 at 11:25 AM, Elliot Glaysher (Chromium) <
[EMAIL PROTECTED]> wrote:
>
> >> Happily, Howard Chu recently posted a partial
> >> example of how to do the latter,
> >>
> h
>> Happily, Howard Chu recently posted a partial
>> example of how to do the latter,
>> http://groups.google.com/group/mozilla.dev.tech.crypto/msg/af4b5b6c71b70702
>>
>> I think the next step might be for me to write an
>> app demonstrating how to handle 500
>> simultanous ssl connections using ns
On Tue, Sep 16, 2008 at 9:42 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> When we implement SSLClientSocket on linux,
> we can do it with one-thread-per-connection,
> or with nonblocking I/O.
> Since all socket I/O goes through the browser process,
> one thread per connection would limit us to
> how
26 matches
Mail list logo
