[csw-maintainers] openssl migration: group 1 packages uploaded

[Dagobert Michelsen]

Hi Ben,

Am 09.10.2012 um 10:39 schrieb Ben Walton <bwalton at opencsw.org>:
> On Tue, Oct 9, 2012 at 8:55 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>>> Should that directory (and it's content) be split out from
>>> CSWlibssl-0-9-8 into a generic package then?
>> 
>> Why not let the directory be provided by both CSWlibssl0-9-8 and CSWlibssl1-0-0 ?
>> If the permissions are the same it wouldn't matter.
> 
> If it were only the directory I'd agree with you.  It's the files in
> the directory that make it worth splitting it out, I think.

Ok.

>>> I also wonder if the */dovecot.pem.CSW should be moved from a
>>> delivered file to a generated one?
>>> 
>>> Also, is there any interest in a CAS to handle creating SSL
>>> certificates at installation time?  I'd put one together if so.  I
>>> have a few packages that could uTSse it
>> 
>> Excellent idea! How would you handle the cn as it should match the DNS?
> 
> We should let the admins set that via a config file as we couldn't
> reliably determine this.

Like ssl_hostname in /etc/opt/csw/csw.conf defaulting to `hostname`.`domainname` ?

> Maybe they want the SSL cert to be defined
> with a a CN that is only CNAME'd to the primary DNS name of the
> system?  The approach I took in apache for the dummy certificate was
> to feed it some obviously fake info.  Maybe what we should do is setup
> basic dummy info and then allow overrides from a system config file:
> 
> CN=$(hostname)
> COUNTRY=...
> STATE=...
> ...
> 
> if [ -f /etc/opt/csw/cas-ssl.conf ]; then
>  . /etc/opt/csw/cas-ssl.conf

Ah, ok, a specific ssl config file. Would also be ok.

> else
>  echo "WARNING!!!"
>  ...
>  ...
> fi
> 
> $do_the_cert_gen_stuff
> 
> The locations for the private and public halves of the certificate
> would either need to be standardized into some directory or be
> configurable in the package.

I would put the certificate in the same directory as the CAS
containing the cert descriptions

> Also, we'd need to handle the package
> upgrade case where either the package generated file exists or has
> been replaced...neither case should see the files changed.  I'm
> thinking that the file tagged with the cswssl CAS could specify the
> locations for the public/private locations and the CAS script would
> just install this file and take no action if the targets exist.
> Removal would never touch the certificates.

Yes. And: Yes.

> The only real benefit to this approach over what we're currently doing
> is that it removes the postinstall or other delivery mechanism to a
> standardized framework.  Many (most?) sites will likely place their
> own certs with proper signature chains so our delivery of the original
> file is only a nicety.
> 
> Thoughts?


ATM lots of packages don't go the extra mile of generating a cert. I would
think having secure-by-default would be good.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896