 |
Hi, I removed the first patch as that was probably a reverse patch. Some comments on the second one, first of all thanks for doing this effort and it looks promising. Its however doesn't fully follow the design we discussed on the devel mailinglist. The StartTLS now starts already before the director is known and that is probably also why you need quite some workaround later on when you know that info. I had a look myself and I think I see a way in which things are less intrusive (and maybe only a little bit cleaner) when using a new Hello message e.g. Hello Director %s calling StartTLS ssl=%d The advantage of this is that we also directly get the director name and the TLS the remote side support.) I'm now implementing some ideas so if you can wait a bit I can attach my ideas and maybe you can use that as a basis to work on. Some small remarks about your patch, if you need a boolean that you need to pass on to some next function or down the stack it probably works better to use an extra variable in the JCR or the BSOCK. What I did in my initial coding is add it to the BSOCK as a bit field (there are already more of them). |
|
|
I like your method better. I will wait for your patches (do you think we should be doing starttls for the storage-deamon-fd communication too? or should we make that a separate bug?) |
|
|
The idea is no add StartTLS support to every connection. Attached are some design principles that implement the approach I explained above. It might not work quite right as its only a design example which compiles. But it has most things we probably need and some ideas to jump over the authentication and do TLS handshake first and then jump back in the code doing the authentication. This has the advantage that we don't recode the features to much and jump around a bit with goto's which are used anyway to have a single exit from function. Also the BSOCK has some new methods and fields to support StartTLS without adding to much overhead. This is seriously untested code but is probably a good basis to work further on. We need more for some connections but I think it can reuse most of the available infrastructure this patch adds. |
|
|
New version have TLSPSK |
- Anonymous
