[oe] [yocto] [meta-java][PATCH v2] ca-certificates-java: add recipe to generate trustStore

Richard Leitner richard.leitner at skidata.com
Fri Jun 15 08:03:46 UTC 2018


Hi André,
I've sent a patch [1] for master-next which fixes this issue.
Therefore you can simply ignore the request for an updated
version of this patch.

regards;Richard.L

[1] https://patchwork.openembedded.org/patch/151727/

On 06/13/2018 11:22 AM, richard.leitner at skidata.com wrote:
> Hi André,
> this commit of yours breaks the build on meta-java's current
> master-next branch with following message:
> 
> ERROR: ca-certificates-java-20170930-r0 do_fetch: Fetcher failure for URL: 'git://anonscm.debian.org/pkg-java/ca-certificates-java.git'. Unable to fetch URL from any source.
> 
> Therefore it will be removed from master-next.
> 
> It would be great if you could send an fixed version with
> the correct SRC_URI, which I think is:
> 	https://salsa.debian.org/java-team/ca-certificates-java.git
> 
> Furthermore may you also please update it to the latest
> version (20180516 if it's possible)?
> 
> Thank you very much!
> 
> regards;Richard.L
> 
> On 04/02/2018 08:43 AM, André Draszik wrote:
>> From: André Draszik <andre.draszik at jci.com>
>>
>> The OpenJDK-8 package currently comes with a trustStore
>> that was generated at OpenJDK-8-native build time from
>> *all* certificates available in the system, not just from
>> those that are marked as trusted.
>>
>> This isn't right...
>>
>> So this recipe hooks into the ca-certificates package and
>> (re-) creates the Java trustStore based on the
>> certificates trusted by the system, whenever they are
>> updated. This works both at image build time, as well as
>> during runtime on the target.
>>
>> It works by installing a hook into ca-certificates'
>> $SYSROOT/etc/ca-certificates/update.d/ that is passed the
>> added/removed certificates as arguments. That hook is then
>> updating the Java trustStore and storing it in
>> $SYSROOT/etc/ssl/certs/java/cacerts.
>>
>> The whole idea as well as the implementation of the hook
>> is borrowed from debian's ca-certificate-java package,
>> version 20170930 (the latest as of this commit).
>> Looking at the debian package, it appears like the same
>> binary trustStore ($SYSROOT/etc/ssl/certs/java/cacerts)
>> can be used by different versions of Java:
>>   * OpenJDK-7, 8, 9
>>   * Oracle Java 7, 8, 9
>>
>> The Java sources here can be compiled by any compatible
>> Java compiler, but the resulting jar file should only be
>> run by one of the compatible Java versions mentioned
>> above, so as to create a trustStore that can be read by
>> any of the Java versions mentioned above. We try to ensure
>> this using PACKAGE_WRITE_DEPS during image build time,
>> and by trying to find a compatible Java version inside
>> ${libdir_jvm} at runtime both during image build time and
>> on the target.
>>
>> Given there is nothing that we can RDEPENDS on that would
>> satisfy any of the above Java versions (either JDK or JRE),
>> we simply RDEPENDS on java2-runtime, and test
>> PREFERRED_RPROVIDER_java2-runtime to be satisfactory.
>> Given I can only test OpenJDK/OpenJRE 8 at the moment, only
>> those are actually allowed at the moment, though. This can
>> easily be extended upon confirmation.
>>
>> Final note - as per the debian package, there are three
>> cases when we can be called:
>>   1) as part of update-ca-certificates -> add / remove certs as instructed
>>   2) if first time install -> add all certs
>>   3) package update -> do nothing
>> We have no way to easily distinguish between first time install
>> and package update in OE, so the distinction between cases 2)
>> and 3) isn't perfect.
>>
>> Signed-off-by: André Draszik <andre.draszik at jci.com>
>>
>> ---
>> v2:
>> * Works with rm_work enabled. We can't use STAGING_LIBDIR_JVM_NATIVE
>>   in pkg_postinst as that is statically resolved to this recipe's
>>   native sysroot, which is of no use when building an image.
>>   Use the NATIVE_ROOT variable instead
>> * make the ca-certificates hook script less verbose (remove set -x)



More information about the Openembedded-devel mailing list