> Welcome to our merry little project!

Thank you for a warm welcome :)

>> I am an engineer at Google, and this is my first email to this mailing
>> list. I implemented item 7.6 of your "TODO" wish list ("Provide callback for
>> cert verification"), and I would like to contribute my changes back to the
>> project. Could someone point me to a list of instructions on how I can get
>> my changes reviewed and submitted?
>
> I think your description here is perfect to explain what the chances are,
> and then you can just make a patch (cvs diff -u) and post it to this very
> list and we'll give it a review and comments and you update the nits we find
> and repost the new patch and when everything is fine and dandy we commit!

Thanks, that's what I needed to know (sorry if I asked something too
obvious, it is my first contribution of this type).

>> First, I created an implementation-independent list of common SSL
>> certificate error codes
>
>> Second, I added code to save certificate [error] data as part of the
>> 'ssl_connect_data' data structure every time a secure connection needs to be
>> established and a new set of certificates is received from the server. I
>> save every certificate in binary along with the encoding method (DER is the
>> only encoding supported at the moment) and the certificate error data. If
>> there are multiple certificates in the chain, I save them all (I have a
>> hard-coded limit of 16 certificates per chain at the moment).
>
> What is the purpose of the saving of the certs? Ah, is that because you
> _first_ save them all and then call the verification callback(s)?

Yes, that's correct. There are two different ways to propagate the
certificate [error] data up. One is to do it separately for every
certificate in the chain. That is, for every certificate in the chain
once it is validated and the error data is available (if any), make a
callback to pass properly-encoded certificate [error] data up the
stack. I do not like this approach because the client code is unlikely
to be able to make the right decision before all the certificate data
is passed anyways. For example, for a browser client it would make
sense to present the user with a list of all the certificate errors in
the chain (probably in the order of their importance) and not to pop
up an error dialog every time a new error is discovered.

I therefore accumulate all the certificate and error chain data first
and only then do a callback. The client code then has all the
information necessary to make an informed decision about whether to
proceed with a connection or abort. This approach also saves a little
on the number of callbacks that are made.

>> Third, I provide a way for the client code to supply the stack with a
>> callback function to be called every time a new chain of certificates
>> is received and validated.
>
> That sounds like something people have asked for. And done in a SSL-library
> agnostic way is really cool!
>
> All in all these sounds like cool additions/fixes. We're just about to enter
> a two-week feature freeze so I would rather not commit anything like this
> until after 7.19.3 is out, but we can still work out the details and get it
> perfected in the mean time.

Thanks, that's good to know. I will be on vacation for the next two
weeks, but I will work with you to get this changes in when I come
back.

Vitaliy
Received on 2009-01-15