openssl: Proposal to stop creating /etc/ssl/certs

openssl: Proposal to stop creating /etc/ssl/certs

[nate.karstens]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

Greetings,

The openssl recipe installs an empty folder /etc/ssl/certs. This is eventually where other recipes like ca-certificates can copy CA certificates for the system. We are working on a tool that can hot-swap those certificates at runtime. The only way to have this transition be seamless and atomic is to make /etc/ssl/certs a symlink to another folder that contains the actual certificates; to update the certificates we just replace the symlink.

Our recipe for this tool conflicts with the empty folder in the openssl package. We were wondering if it made sense to change the openssl recipe to no longer create this folder, the idea being that recipes that populate the folder (like ca-certificates) would be responsible for creating it.

Here is a link to the recipe:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb ( https://urldefense.com/v3/__https:/git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb__;!!EJc4YC3iFmQ!CgiLpD5LsQ6adCzphoFeUHIvQm-M8g2nkDA4_4gtF71eHm20Q0lGSwMahtdHA3ybWA$ )

Line 135 does contain a note that Debian sets up the SSL structure. Creating a placeholder for where CA certificates would eventually go makes sense with certain systems. There could be desktop distros that rely on the user to manually install the certs they need for their organization and providing a location for this would be helpful. I don’t think this makes sense for the typical embedded system where this folder is on a read-only filesystem.

I've just been testing locally with a bbappend that uses rmdir to remove the folder, but unless there are objections I will submit a patch that removes lines 137 (moving the 'mv' to the next line) and 144. I think line 152 can remain in case the variable is useful to anyone.

Thanks,

Nate Karstens
Marine Software Engineering
Garmin International, Inc.

[-- Attachment #2: Type: text/html, Size: 39205 bytes --]

Re: [OE-core] openssl: Proposal to stop creating /etc/ssl/certs

[Richard Purdie]

On Fri, 2020-10-30 at 10:25 -0700, nate.karstens via
lists.openembedded.org wrote:
> Greetings,
> 
> The openssl recipe installs an empty folder /etc/ssl/certs. This is
> eventually where other recipes like ca-certificates can copy CA
> certificates for the system. We are working on a tool that can hot-
> swap those certificates at runtime. The only way to have this
> transition be seamless and atomic is to make /etc/ssl/certs a symlink
> to another folder that contains the actual certificates; to update
> the certificates we just replace the symlink.
> 
> Our recipe for this tool conflicts with the empty folder in the
> openssl package. We were wondering if it made sense to change the
> openssl recipe to no longer create this folder, the idea being that
> recipes that populate the folder (like ca-certificates) would be
> responsible for creating it.
> 
> Here is a link to the recipe:
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> 
> Line 135 does contain a note that Debian sets up the SSL structure.
> Creating a placeholder for where CA certificates would eventually go
> makes sense with certain systems. There could be desktop distros that
> rely on the user to manually install the certs they need for their
> organization and providing a location for this would be helpful. I
> don’t think this makes sense for the typical embedded system where
> this folder is on a read-only filesystem.

If that folder is empty, I don't see why we can't rely on the
certificate providers to create it.

> I've just been testing locally with a bbappend that uses rmdir to
> remove the folder, but unless there are objections I will submit a
> patch that removes lines 137 (moving the 'mv' to the next line) and
> 144. I think line 152 can remain in case the variable is useful to
> anyone.

If you remove 152, it will break things as we do need the wrapped tool
to be able to find the certificates. I'm also wondering what is using
the link created by 144, it could be openssl itself. I suspect you may
want to leave it as a dangling symlink and just let the certificate
provider create the directory it points to?

Warnings about the dangling symlink may be why an empty directory is
being created?

Cheers,

Richard