[Pkg-openssl-devel] Bug#642314: Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Loïc and others,

lets address the comment in the right order not in the order of
severity.

Am Mi den 21. Sep 2011 um 14:49 schrieb Loïc Minier:
>  The patch from Debian #628780 caused a regression with certificates
>  using CRLF line-endings,

Hmm.. I think, certificates on unix with CRLF line ending is broken and
should be fixed.

> which prompted me to take a look at the discussion here.  (Debian
> #642314 is the regression.)

Go ahead. I'm open for discussions. :-)

> a) link_hash_cert() only searches for "BEGIN CERTIFICATE", not for
>    "BEGIN X509 CERTIFICATE" or "BEGIN TRUSTED CERTIFICATE" which are
>    allowed in other parts of the file

I didn't see certificates with that strings. However, a fix would be
easy.

> b) this requires a tempdir with write permissions, which might be a
>    problem for certain deployments calling c_rehash

That is true. I think that a unix (linux) system without temp directory
is not supported. There are many stuff that doesn't work without.

Moreover the temp directory that is needed for this patch is only needed
on c_rehash run, not on the normal system work.

> c) this causes a lot of writes (each certificate is written to a
>    tempfile which gets deleted); again, this might be a problem if some
>    deployments run c_rehash on a large number of certificates

As I told above I do not think that this is an issue as you normally do
the c_rehash work only once upon a time but use the links much often.
And there are stuff that is using much more resources than this c_rehash
on certificate installation (namely the fsync stuff in apt that is
making it really slow but that's another story).

>  I'm particularly worried about c) because the whole point of c_rehash
>  is to speed up lookup when there is a large number of certificates
>  (e.g. client certificates).  If there is a large number of
>  certificates, then writing each of them to a tempfile is going to be
>  time consuming.  If there are many certificates, one can also imagine
>  that certificates are added/removed frequently, requiring frequent runs
>  of c_rehash.

Common, I do not think that you add and remove certificates such often.
Certificates have a validity range in years, not in hours.

>  The root problem here is really that the openssl command-line doesn't
>  support multiple certificates in a single file,

Right.

> so why not fix that instead?

could be a long term fix. But I do not think that debian should go a
lonesome way in this case. It could be interesting for upstream too.

>  In my eyes, the drawbacks of the patch are quite bad; perhaps it would
>  be a better idea to:

Feel free to improve it. It was a first step from me but I do not think
that it is perfect.

>  * split cacert.org.crt in two files, one per certificate; this would
>    also allow administrators to enable certificates selectively in
>    /etc/ca-certificates.conf

That is only one part of the solution. And the cacert certificate was in
two files in elder times. (Before etch I think; knows the devil why it
went to just one file.)

>  * document the limitation in openssl / ca-certificates that only the
>    first certificate gets picked up

A bad choice. In the particular case of cacert the most used certificate
is the second one. This ends in the fact that cacert is useless at all
in debian.

>  * optionally, we could let ca-certificates or c_rehash fail (if some
>    flag is set and) if multiple certificates are in a single file

The same bad choice.

I see some solutions:
- - Tune c_rehash the way that it fulfils the mentioned issues. (Should be
  easy)
- - Have two c_rehash tools. One for the users that want only hash one
  certificate per file and one for apt. That might be a bad solution as
  the one would remove the links from the other.
- - Introduce a complete new tool that handle the hashes. (Maybe in
  combination with the submitted fix of x509.)

Maybe there are other advices. All might be better than the state that
it had have before my patch.

Well, and it should not gets into oblivion that there are two
alternative method's to calculate the hash. (-subject_hash and
- -subject_hash_old) I think they must be created both.

Sorry that I do not see the relevance of your case 'c'. I really do not.

Regards
   Klaus
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus at Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQGcBAEBCgAGBQJOeivDAAoJEKZ8CrGAGfasdd4L/iijKRksL3mjFrn/28OY8m2I
xFEwmYyXvQ9Kioa39Tr3kkXIvGKs2XkTssJif4efL5g5DaCtjhPrNi1/UGKjBc8R
gYc2Op/ZEzWaDo8ekmGSsIqOIby3V/X33R+Bv1H7fEO/hz51vgNolTt+3z1eYK0m
SnBiBMe+Uq0Ds06PrQIv9lGCUFxmQ0m017dZ9ieGhTREE/mBDN12m7B+UU+kqDn4
ndPZ0Y0F5S5O9RUuWb7AYPoV6B07mC25ihU6N4UNJZWdasM6dOj7PdmwqoM5PtB6
8CS2hvdqZjTVBfoVTY8fzOoZK62fRbZQfaor5ZNl9iwj4zd+NanG56R1koqcnhjC
TohCrYZ0vb/fp0nAcvEw74GJaNNBAXNVp4ns6LoPTSxoj3du5temdtaXnOnnWr49
+HPGLbhmHcekz1Dgeqm/JCoh5j2U23+TLowDFUkaZI9MBUOQXmjK0oCqo2j6eHfu
YUUPSWyqLCE706k1VEYhOK9cVA6fN1ka3gEvaNGw1Q==
=NKqb
-----END PGP SIGNATURE-----