James, Thanks for the quick feedback... On 1/15/14, 3:08 PM, "James Peach" <jpe...@apache.org> wrote:
>On Jan 15, 2014, at 10:46 AM, Ron Barber <rbar...@yahoo-inc.com> wrote: > >> All, >> >> I have been asked to address TS-612 >> (https://issues.apache.org/jira/browse/TS-612) by Œthe man¹. I made a >> proposal on the ticket regarding configuration and would like some >> feedback at your leisure (well pretty quick since I am on it now). > >1. The 'builtin' dialog may be a problem, since traffic_server would be >the one running the dialog, and it's a couple of processes down the fork >chain. Was going to include it primarily for completeness (and for my testing it’s useful). Certainly I can remove it if it’s problematic (maybe it will create more questions), but just like it’s helpful for me, it may be useful to the person trying to implement/test his own exec or pipe solution. > >2. Compatibility with the Apache http dialog would be a good thing. >However, there's no ATS requirement to specify a dest_ip >(servername:portnumber in the httpd documentation), so I don't know that >it makes sense. > >Are you planning to implement the httpd prompt-minimization logic? > >It's difficult for me to see how a program could select a passphrase >using the http logic. It doesn't seem like there's a way for the program >to really know which key it is being prompted for. If the dialog was >specified in ssl_multicert.config, then it would be possible. Short answer: No. I thought that was a really cool feature in httpd so I looked at the implementation. Httpd tries each password that it has seen previously before asking for another password..in order to do that it would take refactoring of the SSL config code which is beyond what I have time for. > >While you are at it, consider whether we can consolidate the number of >places in our code that calls fork+exec into a libts API that looks a lot >like posix_spawn. Will look at that. > >While this is useful from a compatibility point of view, I'd like the >provisioning and protection of private keys to go much further. The linux >kernel keychain looks like the most promising infrastructure for key >management, and I'd like us to support that. Additionally, I think that >using a privileged helper (eg. traffic_manager?) is the right way to go >for accessing keys that are read-only for root, or protected in some >other fashion. I agree with the idea (not sure keychain capability is available in all supported OSs) but is outside of my time horizon (and knowledge base atm). > >J
