Cacerts generation patch for IcedTea6 HEAD

[DJ Lucas]

On 12/21/2010 05:09 AM, Pavel Tisnovsky wrote:
> Hi all,
>
> I've created patch for cacerts generation prepared for IcedTea6 HEAD.
> This patch is heavily based on DJ Lucas's patch (thank you very much!)
> but I had to apply three changes:
>
> 1) I had to change the lines where the patch is applied to Makefile.am
> due to several changes in this file (it's understandable as the original
> patch is quite old and it's been prepared for older IcedTea version)
>
> 1) DEBUG_BUILD_OUTPUT_DIR macro is used instead of BUILD_OUTPUT_DIR when
> cacerts are about to be generated for debug build of IcedTea6 (already
> approved by DJ Lucas)
>
> 2) I also changed the decision logic which determinates whether the
> certificates have to be generated from one .crt file or from an existing
> list of .pem files. This ensures correct work in case when only file
> containing certificates is installed (this is RHEL 5 and RHEL 6 case:
> /etc/ssl/certs/ca-bundle.crt)
>
>
>
> I also tried to run JTReg against unpatched and patched IcedTea6. Here
> is diff:
>
<snip>
> +FAILED: lib/security/cacerts/VerifyCACerts.java
<snip>
> +FAILED: sun/security/rsa/TestCACerts.java
>
>
I realize it has been a while, but on a fresh build of IcedTea6-1.9.3 on 
a pure x86_64 machine, with the proposed patch applied (offsets and ac*# 
corrected), I do not see these additional test failures. I have others 
to look into, but those aren't related (likely due to me playing on the 
bleeding edge). I'll begin a build on x86 momentarily, and then start 
back on head when I can. Also, what is the content of the cert with 
95750816 hash? Is it expired or otherwise untrusted? I do not have this 
certificate in my chain. I'm using only Mozilla certdata.txt as the 
source for my distro CAs as any additional trusted certificates are left 
for the users' responsibility in my case. If maybe you can point me to 
the certificate package you were using, I could take a peek at it myself 
as well.

There are other options here too, like including a minimal one as is 
done with the proprietary JDK, distributing a fully populated one with 
an option to override it (though I think most will probably cringe at 
the idea of defining a default security policy), or throwing a warning 
in configure if a pre-populated cacerts file is not provided/found. A 
simple AC warning might even be enough. However, even with those other 
options in play, I'm still more partial to providing the _option_ to 
generate one on the fly using the already trusted certificates from the 
build machine. The big thing I wanted to see is that Joe or Jane User 
aren't left completely in the dark when they go to build their own copy 
of IcedTea and  the security tests are failing.

-- DJ


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.