Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? -- One does not see anything until one sees its beauty. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On Fri, Jul 28, 2006 at 10:03:13AM +0300, Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? The dh_ file can be shipped with ssl-cert2, preferably under a name that doesn't invade debhelper's namespace. As the packages are going to depend on ssl-cert2, making them build-depend on it is not a real burden. -- 1KB // Q: How do you spot a good inetd? // A: It build-depends on equivs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add if [ $1 = configure ]; then make-ssl-cert2 package fi and in postinst if [ $1 = purge ]; then make-ssl-cert2 -r package || true fi The dh_ script merely does this for you after adding any extra arguments to make-ssl-cert that you have requested with your debian/package.certificate file. So, if you are merely concerned that it is /possible/ to do it without a dh_ call, then it certainly is. But I think it is a good idea to use it, as if the policy changes in this respect then a rebuild is all that may be required. And also it gives the maintainer more chance that any problems can simply be reassigned to someone else. James Westby [P.S. I have put the source in bzr format here http://jameswestby.net/bzr/ssl-cert2/ so it's browsable over the web now] -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti: On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. I don't like it when people make using helper packages de facto required. And debhelper isn't standard (meaning that you can expect everyone to use it), merely very common. It is also very good, but its use must still remain optional. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Good. If that is documented in the ssl-cert2 package, then all is well. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
On (28/07/06 13:16), Lars Wirzenius wrote: pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti: I don't like it when people make using helper packages de facto required. And debhelper isn't standard (meaning that you can expect everyone to use it), merely very common. It is also very good, but its use must still remain optional. That is fair enough. I understand the desire for choice. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Good. If that is documented in the ssl-cert2 package, then all is well. http://jameswestby.net/bzr/ssl-cert2/README Probably requires updating to the new make-ssl-cert2 options. -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On Fri, 28 Jul 2006 10:53:22 +0100, James Westby [EMAIL PROTECTED] said: On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. It concerns me since I do not use helper packages in my packaging. Debhelper, while pretty popular, is by no means mandatory, or universal. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Well, my packages are not simple, but I still prefer to hand craft them. if [ $1 = configure ]; then make-ssl-cert2 package fi and in postinst if [ $1 = purge ]; then make-ssl-cert2 -r package || true fi The dh_ script merely does this for you after adding any extra arguments to make-ssl-cert that you have requested with your debian/package.certificate file. This is perfectly fine, as long as there is a man page for make-ssl-cert. So, if you are merely concerned that it is /possible/ to do it without a dh_ call, then it certainly is. But I think it is a good idea to use it, as if the policy changes in this respect then a rebuild is all that may be required. I would hope that such policy changes be very few, once stabilized, and any minor changes would be subsumed in make-ssl-cert. And also it gives the maintainer more chance that any problems can simply be reassigned to someone else. I prefer to actually maintain my packages, not seek excuses to reassign bug reports to other people. YMMV. manoj -- But was he mature enough last night at the lesbian masquerade? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On (28/07/06 12:12), Manoj Srivastava wrote:
On Fri, 28 Jul 2006 10:53:22 +0100, James Westby [EMAIL PROTECTED] said:
On (28/07/06 10:03), Lars Wirzenius wrote:
pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti:
But, yes, like all of debhelper it's just a convenience wrapper. If
your package is very simple then in the postinst add
Well, my packages are not simple, but I still prefer to hand
craft them.
Sorry, I mispoke slightly, I meant simple in terms of there certificate
requirements. That is happy just with a certificate in /etc/ssl/certs
and a key in /etc/ssl/private. Then it is very simple to do this. And
hopefully it is not too much more difficult for the packages that
require more than this (e.g. ftpd-ssl that required the cert and key to
be the same file, which should be easily possible with or without
debhelper).
This is perfectly fine, as long as there is a man page for
make-ssl-cert.
http://jameswestby.net/bzr/ssl-cert2/make-ssl-cert2.8
Requires a little tweaking, but then again so does the entire package.
I guess I must apologise for empasising the debhelper script in this,
all it dees is write the post{inst,rm} snippets for the maintainer. And
it is obviously possible for the maintainer to do this themselves.
Maybe I shouldn't have included the advantages to the package maintainer
comment in my summary. This is not the aim of the package, the aim is to
give the sysadmin more control and flexibilty about how to handle this
stuff, the benefits to the packager are just a result of using a central
system.
Obviously the maintainers are free to ignore this package completely,
but I hope it will be used as they will be able to see the benifits it
gives to the users.
I guess I should be happy that no-one has pointed out any flaws in my
design, or said that they do not wish to use the system. Then again this
might just mean that most people have ignored this thread.
Thanks,
James
--
James Westby
[EMAIL PROTECTED]
http://jameswestby.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
Warning, long email. Executive summary. == * More consistent handling of SSL certs would be nice. * The proposed ssl-cert package is not in good shape. ssl-cert2 from http://jameswestby.net/debian/ssl-cert2-0.1.tar.gz aims to * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ * Allow the admin more choice in managing these certs, a choice of - Ignore it completely, have a cert generated without any hassle, and all SSL applications working out of the box. - Have one certificate, and use a single command to regerate it (with values of your choice). - Have a sitewide certificate of your choice with one command. - Have a sitewide certificate, but individual certificates where needed (for multiple apache domains perhaps). - Have individual certs for everything with one command (and maybe a few answers to prompts). - Turn it off completely, run your own CA, create certificates when needed (and prodded that a new package will require a certificate). = On (30/06/06 10:51), Jaldhar H. Vyas wrote: In bug #376146, Martin Pitt wrote: In an effort to clean up the SSL certificate mess on Ubuntu servers, we recently converted all our supported Server packages to make use of the ssl-cert package instead of creating a package-specific self-signed SSL certificate. This allows admins to easily replace the certificate with a 'real' one without touching dozens of configuration files, and also provides a consistent setup out of the box. Is this is a good idea for Debian? I think it is but it doesn't make sense to switch dovecot over unless all the other ssl-cert using packages also do it. Is this possible in the etch timeframe? This thread generated some interest and discussion of the ways this could be done, so I looked in to how suitable it was to convert all of the packages. What I found was that there weren't many packages in Debian using ssl-cert. Most worrying was that the maintainers of apache and ssl-cert had stopped using it. Looking at the ssl-cert package it seems that it has plenty of problems, (e.g. #230485, #230791), and it doesn't implement the system discussed in this thread. To this end I decided to write a package myself to do the job. It is called ssl-cert2, it's not based on ssl-cert at all, but I couldn't think of an original name. I wanted to try and get some discussion about the architecture I have gone for, as I am sure I haven't though of everything. So, firstly it implements a system of symlinks that I think was the consensus in this thread, i.e. it creates ssl-cert2-sitewide.pem - ssl-cert2-snakeoil.pem so that the one symlink can be updated to change the certificate for all services. Each package then gets a link pointing at the -sitewide one, so that these links can be changed if the admin wants a separate cert for some service. One of the big complaints about ssl-cert was it's use of debconf, so I have tried to minimise this usage. There are debconf questions to create the snakeoil certificate, but at medium priority. I wanted to keep this so that preseeding might help out an admin later. My plan is to have a standalone program that manipulates the certificates. The default of this new package is therefore to link all certs to a central self-signed cert with guesses for CN and email ($(hostname) and [EMAIL PROTECTED]), and the debconf value from d-i for country if available. This should be enough for most packages to run, and the aim is to make it changeable by a single command to what the admin wants. The plan is to have a script that allows all of this to be managed easily, so you can do something like. manage-ssl-cert2 regenerate-sitewide which will prompt for values and recreate the snakeoil certificate (with a --no-prompt option to just regenerate if it expires or similar). also manage-ssl-cert2 replace-cert sitewide /some/cert to drop in a replacement (signed by a CA or similar). The system then does it's best to not interfere, for instance not changing/making a link if it points somewhere that the program doesn't think it can change without the admin's permission (by storing readlinks from the links when they were created). There could well be a --force option to make it ignore this and do it anyway. As for the packages themselves, the idea is that they merely add dh_sslcert2 to debian/rules, and assume that their certificates are created. The idea is that the system will place them there if the admin hasn't told it not to (for instance by turning off ssl-cert2 completely, which is very easy to do). They can also use debian/package.certificate files to set some preferences for how they would like their certificates. Notably the locations, but also owner, group etc., which will be respected if the admin configures ssl-cert2 to use individual certs (which we will
