Hello Günter,

A few comments, inlined for readability,

On Wed, Apr 3, 2013 at 10:07 PM, Guenter <lists_at_gknw.net> wrote:
> Hi Richard,
>
> On 03.04.2013 19:13, Richard Michael wrote:
>>
>> mk-ca-bundle currently wraps PEM certs at 76 chars. I suspect 64
>> chars would be more helpful, as it's consistent OpenSSL's (correct)
>> PEM output. It's a fairly trivial issue, but it may have consequences
>> of which I'm not aware. Any thoughts?
>
> I dont think this is worth to change;
> all base64 encoders/decoders I'm aware of can deal with any wrap; also its

0/ I am primarily concerned with the format of the CA bundle file, not
with the possibility of parsing the file with an encoder/decoder. I
have not investigated coders other than OpenSSL, but I believe you
[that they will handle 76 character wrapped PEMs].

> possible to let mk-ca-bundle.pl use OpenSSL for the conversion so that there
> should be no difference at all if you use that option - isnt this enough?

1/ (I assume you mean "-t"?) I did not notice, because -h does not
mention OpenSSL generated output. But --

First, this grows the output file size by quite a bit. That said, I
would do this for myself locally, the verbose ca-bundle content is
helpful. Thank you for mentioning it.

Second, the option "-t" is broken. The output file (">> $crt") used
in the TMP pipe is clobbered when the temp output file
("ca-bundle.crt.~") is renamed (to "$crt") at the end of the script.
:-)

Third, I wanted to change the default output of mk-ca-bundle.

> The non-openssl output would anyway look other even when wraped at 64 chars
> than the openssl one, and thus isnt directly comarable, and certainly not
> diff-able with a tool.

Do you mean that the 64 character wrapped MIME::Base64 output will not
be identical to the OpenSSL PEM Base64? In the certificates I examine
after my patch, the outputs were identical. Could you explain further
please?

>> Moreover, with a multitude of certificate formats and acronyms in the
>> SSL domain, it is useful to output consistently formatted PEM
>> certificates such that users are not confused by different "looking"
>> certificates, despite identical technical function.
>
> a holy wish ...

Not so holy! Such a user is me. :-) I was confused by 76 vs. 64
character PEMs when I was learning SSL subject matter many years ago.
So again, I think it would be helpful to be consistent [with openssl
and the PEM RFC] with the format of the bundle file.

> but what I think is worth to try is convincing the author of MIME::Base64 to
> add a parameter / setting to the module so that one can control the wrap ;-)

It's an XS C file; beyond what I am willing to take on for this issue.
 (Until I learn C and have a greater willingness to learn Perl XS
tools!) But I agree, a length parameter would be helpful. :-)

>
> Gün.

Regards.

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

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-04-03