On Thu, Feb 27, 2014 at 3:44 PM, Guenter <lists_at_gknw.net> wrote:
> thanks for coming here and considering to push your enhancements upstream
> ...
> but currently I'm not yet sure if your special add-ons are useful for a
> broader (lib)curl user community; they sound a bit like it would be better
> to create a new prorgam conv-certdata.pl or something like that ...
> dont get me wrong here (and I only express my personal oppinion) but in the
> past mk-ca-bundle.pl showed that it was sensible to changes done in
> certdata.txt, and the more checks are included the more sensible it will be
> (that's probaly also derived from the simple and/or stupid way I hacked it
> up initially) ...
> also since it is part of our libcurl project we all need to maintain it and
> try to keep it going for our purpose, and the more complex it becomes its
> probably also more complex to maintain from our side ...
>
> but that doesnt mean that I'm against any enhancements as long as these are
> done in a way which:
> - keep the script running on multiple platforms including Windows
> - keep current speed of the default mode

You're very welcome.

I agree that ultimately, a separate project could be better. However,
I know that there are already a significant number of links that point
to mk-ca-bundle as a way to get a list of certs from Mozilla in an
PEM/OpenSSL compatible format. As far as I'm concerned, the more
people that can benefit from this sort of thing the better. Plus, I
don't know that I really have the time to administer a real project,
even though it might be small. You might be surprised how long I've
been trying to get to this much ready.

At any rate, everything I've done is isolated to the mk-ca-bundle Perl
script and shouldn't affect platform compatibility. After all, most of
it is just string parsing. However, as I was preparing my original
email, I noticed that there's also a vb script version that I somehow
overlooked. I haven't updated that version, so I hope that won't be a
blocker. I also updated the man file, so

The speed using the default options isn't impacted. The only time
things slow down is in the full plain text output with the extra
hashes, as noted below.

>> Example (using y and z as placeholders for the TBD parameter flags):
>> perl mk-ca-bundle -y SERVER_AUTH,CODE_SIGNING -z NOT_TRUSTED
>> This would generate a bundle containing all certificates which are not
>> trusted for either SSL server auth or for code signing.
>>
>> ** Does anyone have an opinion on which flags are used for these
>> command line parameters? -p could be used for the purpose list, but an
>> intuitive letter for the trust level isn't available since both -t and
>> -l are already used.
>
> hmm, perhaps we can use -p in the sense of 'parameters' and then use a sytax
> like:
> -p purpose[:trust_level]

I hadn't considered that; it's a good idea. The way I have everything
working right now it wouldn't be a big change.

> ATM I've not looked into the script for longer, but IIRC the hash is done by
> openssl commandline, or? Cant we let this generate the additional hashes
> which is probably faster than doing it with perl?

That's correct, and what I was doing. Unfortunately, OpenSSL only
supports doing a single hash at a time so we have to iteratively call
it. For a single cert, that's not a problem, but when we do it ~150
times, it adds up. It's not a huge difference, but it is noticeable.
I'll see about adding a parameter to control the hashing.

>> When outputting the certificate, I also write out the certificate
>> trust information. I find this to be useful for troubleshooting.
>> ** Is this acceptable to everyone?
>
> hmmm, I would prefer to keep the current short format as is since the SSL
> backends must scan those files again and again, and skipping those
> 'comments' which are not used for SSL needs time;
> when doing the full output this would probably be ok - but perhaps also not
> bad to only do it optional ...
>
>
>> ** Should this be output only in plain text mode (flag -t)? I

Will do.

> since it appears that you did already all those enhancements, maybe you can
> post a patch with what you currently have which applies cleanly against
> current version in our GIT so that we can take a closer look and play a bit
> with it on different platforms?

Absolutely. I started off with this email since that's what the the
cURL website recommends. We're only using this internally, not
distributing it, so there's no problem altering it based on feedback.
I've pushed what I have right now my github fork
(https://github.com/watson81/curl/commit/520616e8405c6be70708fbac3f3591d6bdadf4ae)
and attached a patch as well. Unfortunately, this work isn't always my
top priority, so I'm not certain how quickly I'll get the above
changes ironed out.

Thanks,
Patrick

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html