phosphor-certificate-manager refactoring.

[Jayanth Othayoth]

Proposal looks good,

Looking for patch sets related to this.

On Fri, Nov 22, 2019 at 2:39 PM Kurzynski, Zbigniew <
zbigniew.kurzynski at intel.com> wrote:

> Hi everyone,
> I think it is good time to do some code refactoring in
> phosphor-certificate-manager.
> The certificate manager supports few certificate types, each is managed by
> a separate service instance.
>         phosphor-certificate-manager at authority.service,
> phosphor-certificate-manager at bmcweb.service,
> phosphor-certificate-manager at nslcd.service
> Initially the certificate manager was designed to support single
> certificate file. But now one of its instances supports multiple files and
> the code for that case differs quite much from the rest.
> I would like to propose a small refactoring of this code in following
> steps:
>
> Step 1.
> Create a new subclass of Certificate. The base class will remain as is,
> focusing on single certificate approach, while its derived child will
> extend it with support for multiple certificates.
> The Manager class seems quite generic and I would leave it as is. Two
> instances will operate on the base Certificate class, while the third will
> use class derived from the Certificate.
>
> Step 2.
> Moving files:
>         1.
> meta-phosphor/recipes-phosphor/certificate/phosphor-nslcd-cert-config/env
>         2.
> meta-phosphor/recipes-phosphor/certificate/phosphor-nslcd-authority-cert-config/env
>         3.
> meta-phosphor/recipes-phosphor/certificate/phosphor-bmcweb-cert-config/env
> to repository phosphor-certificate-manager under a new directory 'service'
>
> Getting rid of below recipes and moving their functionality to
> phosphor-certificate-manager_git.bb if possible.
>         phosphor-bmcweb-cert-config.bb, phosphor-nslcd-cert-config.bb,
> phosphor-nslcd-authority-cert-config.bb
>
> Step 3.
> Changing the way of managing and storing TrustStore certificates.
>
> Now all certificates are stored and managed directly in a
> /etc/ssl/certs/authority/ , but files in that directory are subject to many
> restrictions like:
>         the files must be named using the subject name's hash and an
> extension of '.0',
>         If there are two files with the same hash they should have
> different extension number,
>         Extension numbers cannot have gaps, which is a problem when we
> delete some certificates.
>
> I propose to store certificate files in a separate location, where file
> names do not have such restrictions.
> And put in this folder /etc/ssl/certs/authority/ only soft links to
> original files.
> Each time when any of certificate will be changed/deleted/added the
> manager should simply delete all links from /etc/ssl/certs/authority and
> the recreate them by iterating all certs files.
>
> Please let me know if you have any concerns.
>
> -Zbigniew
> --------------------------------------------------------------------
>
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego
> adresata i moze zawierac informacje poufne. W razie przypadkowego
> otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej
> usuniecie; jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by
> others is strictly prohibited.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191127/692eaa9d/attachment.htm>