Bug#141748: ITP: openca -- Open Source Certification Authority
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 <bam@snoopy.apana.org.au>
--
To UNSUBSCRIBE, email to debian-wnpp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: