On Wed, Apr 17, 2002 at 12:40:07PM -0400, Noah Meyerhans wrote: > Now, I mean no offense by this at all, but shouldn't you leave the > packaging duties of this security-critical package to somebody with more
Openca is much much much simpler then Heimdal which I also package and is also a security critical package (maybe even more security critical then this package, because the KDC must run on a connected computer). I cannot guarantee the security of Heimdal, nor do I have a clue what each of these functions from each of these libraries does (although I could guess, and my guesses would be reasonably accurate), but strangely enough people still use it. Weird. > in-depth knowledge of how it works? It seems fairly obvious that you > have not yet actually used the package at all. Will you be using it [ with respect I think you are mistaken here; I had used it, but when writing my ITP I was reading the documentation at the same time, I realized it was slightly (but not hugely) different to the way I initially imagined. For instance, I had considered RA+Pub servers to be the same, because they run on the same computer, but upstream considers them as two seperate entities. ] > once it's packaged? If I'm going to be running OpenCA, I certainly want > to know that the packaging is done right. Judging from the bugs I have found in openca (CVS version at least), I don't think it is yet suitable for mission critical applications. Fixing these small but irritating bugs is a learning experience in itself. I gave up with the stable version because (from memory) I encountered bugs using it too, and files are installed in places that make made me feel uncomfortable (like putting data files below the directory containing the CGI scripts). I think if you use it, you are much more likely to encounter upstream problems then security problems with my packaging. As for using it, yes I am already using it (although not for anything mission critical). > It's not that I don't trust your ability to learn the package, but I > think it is unwise for somebody to be responsible for this package when > they're not really even clear on the basic functionality of it. I can't infleunce security of openca, that is largely up to: 1. the upstream authors. I haven't seen any security problems with the upstream code yet that could accidently give away a private CA key or mark a request as approved, but such a bug would be theoritically possible. 2. The installer/adminstrator. There are a number of tradeoffs you can use when installing openca, which I don't even attempt to deal with so far. For instance, should the CA run on a dedicated machine? Is this machine totally disconnected from the netwwork? If so, then http might be OK, otherwise https with client side certificate checking (to ensure remote user is a CA operator) might be appropriate. Should the RA run on a dedicated machine? 3. local policy for what certificates are valid and may be approved, etc. Yes, there is the additional security risk that sensitive information might be have the wrong file permissions allowing anyone to read that file (I think my permissions are overly strict just in case). However, the biggest challange in package the program is to ensure that all the files go into the correct packages, and some mechanism is in place to configure it. Of course, if anyone sees any problems (security or otherwise) in any of my packages and/or thinks that they could do a better job, then please let me know. Anyway, I can't package it yet, not until the next (unreleased) version of openssl suddenly appears in Debian. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]