pe, 2005-09-30 kello 12:47 +0200, Fabio Tranchitella kirjoitti:
> Il giorno gio, 29/09/2005 alle 23.25 +0300, Lars Wirzenius ha scritto:
> > Yeah, it's a difficult situation, I guess. In my opinion, if the
> > certificates are important, the sysadmin shouldn't purge the package
> > (just remove it), and, anyway, they should back up the certificates
> > somewhere safe.
>
> I disagree, and I think the best way to deal with this type of problems
> is to leave the files on the filesystem. All in all, this is the same
> approach used for the users created by maintainers script, isn't it?
I think we're both right: I'm right in that if I install dovecot-common
and then immediately remove it, I should not have certificate files
lying around afterwards. You're right in that if the sysadmin modified
the certificates (for whatever reason), purging the package should not
remove them. Further, I think this problem appears in many (all?)
packages that create SSL/TLS certificates upon installation.
It would thus make sense to me to creates some helper commands to take
care of this properly. Something like:
openssl-autocreate-certificate $PACKAGENAME
openssl-autoremove-certificate $PACKAGENAME
plus other options, if necessary. Gnutls may want its own versions, I
don't know.
The first command would create a self-signed certificate with sensible
parameters and place it in the correct locations, named after the
package. It also stores the MD5 checksum (or full copy) of the key
in /var/lib/something. If such a certificate already exists, the command
obviously does nothing.
The second command would check that the certificate to be removed
matches the checksum (or full key) in /var/lib/something, and if so,
removes it, and if not, does nothing.
Does this sound sensible to you?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
