|
Home > Archive > Debian Developers > November 2006 > ca-certificates symlinks out of /etc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ca-certificates symlinks out of /etc
|
|
| martin f krafft 2006-10-31, 1:22 pm |
| ca-certificates installs about 100 certificates into
/etc/ssl/certs. However, these are not actually dropped into the
directory; instead, symlinks into /usr/share are put in place:
piper:/etc/ssl/certs# ls -la /etc/ssl/certs/cacert.org.pem
lrwxrwxrwx 1 root root 52 2006-10-31 18:56 /etc/ssl/certs/cacert.org.pem ->/usr/share/ca-certificates/cacert.org/cacert.org.crt
Since #350282 is still being discussed, I ended up doing
cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
on systems that needed access to all of CACert's certificates.
The recent ca-certificates upgrade overwrote this "configuration"
simply because my /bin/cat call actually changed a file in
/usr/share, where changes by the admin are not preserved. Yet, due
to the links in /etc/ssl/certs, the admin is given the impression
that these are configuration files and can thus be edited according
to Debian's holy conffile handling policy.
I consider this a bug, and even release-critical, and would say that
ca-certificates should use ucf to maintain the certificates in
/etc/ssl/certs. Arguments against that are to keep /etc small, but
at 444k I don't see ca-certificates being a culprit.
Comments?
Please don't tell me to use an editor that writes a new inode when
changing files. It's not a solution to the problem, even though it
would address the symptom.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"when faced with a new problem, the wise algorithmist
will first attempt to classify it as np-complete.
this will avoid many tears and tantrums as
algorithm after algorithm fails."
-- g. niruta
| |
| Alex Pennace 2006-10-31, 1:22 pm |
| On Tue, Oct 31, 2006 at 07:10:45PM +0100, martin f krafft wrote:
> Since #350282 is still being discussed, I ended up doing
>
> cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
>
> on systems that needed access to all of CACert's certificates.
>
> The recent ca-certificates upgrade overwrote this "configuration"
> simply because my /bin/cat call actually changed a file in
> /usr/share, where changes by the admin are not preserved. Yet, due
> to the links in /etc/ssl/certs, the admin is given the impression
> that these are configuration files and can thus be edited according
> to Debian's holy conffile handling policy.
The configuration being preserved is a set of symlinks, not the
contents of their targets.
Perhaps this will work better:
ln -s cacert-class3.pem /etc/ssl/certs/cacert.pem
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2006-10-31, 1:22 pm |
| * martin f krafft (madduck@debian.org) wrote:
> Since #350282 is still being discussed, I ended up doing
>
> cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
>
> on systems that needed access to all of CACert's certificates.
cat /my/favorite/editor >> /etc/alternatives/vi
cat /the/best/dictionary >> /etc/dictionaries-common/words
So much for my "configuration".
Thanks,
Stephen
| |
| martin f krafft 2006-10-31, 1:22 pm |
| also sprach Alex Pennace <alex@pennace.org> [2006.10.31.1917 +0100]:
> The configuration being preserved is a set of symlinks, not the
> contents of their targets.
I am fully aware of this. However, it's misleading, don't you think?
It's just not very typical for symlinks in /etc to be considered
configuration:
Symlinks "leaving" /etc, including ca-certificates:
piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec readlink -f {} \; | egrep -v '^/etc' | wc -l
210
Targets of symlinks "leaving" /etc, excluding ca-certificates:
piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec readlink -f {} \; | egrep -v '(^/etc|ca-certificates)' /var/lib/defoma/pango.d/pangox.aliases
/lib/linux-sound-base/noOSS.modprobe.conf
/lib/linux-sound-base/noOSS.modutils.conf
/lib/linux-sound-base/noOSS.discover1.conf
/usr/share/dict/web2
/lib/linux-sound-base/noOSS.hotplug.blacklist
/var/lib/defoma/fontconfig.d/fonts.conf
/lib/linux-sound-base/ALSA.discover2.conf
/usr/bin/Xorg
I'd go as far as claiming that all these are bugs or design
misdecisions.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"in contrast to the what-you-see-is-what-you-get philosophy,
unix is the you-asked-for-it,-you-got-it operating system."
--scott lee
| |
| martin f krafft 2006-10-31, 1:22 pm |
| also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.1948 +0100]:
> cat /my/favorite/editor >> /etc/alternatives/vi
alternatives are surely an exception, don't you think?
> cat /the/best/dictionary >> /etc/dictionaries-common/words
I don't see the reason why /etc/dictionaries-common/words should be
a symlink either. The right way to solve this would be to use
alternatives and provide a second file to which a user can add
additional words.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"for nasa, space is still a high priority."
- george w. bush
| |
| Alex Pennace 2006-10-31, 1:22 pm |
| On Tue, Oct 31, 2006 at 07:41:02PM +0100, martin f krafft wrote:
> I am fully aware of this. However, it's misleading, don't you think?
I cannot answer that from the average user perspective. However,
symlinks are quite handy and there is already an established base of
users who are familiar with symlinks-in-etc.
> It's just not very typical for symlinks in /etc to be considered
> configuration:
>
> Symlinks "leaving" /etc, including ca-certificates:
>
> piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec readlink -f {} \; | egrep -v '^/etc' | wc -l
> 210
>
> Targets of symlinks "leaving" /etc, excluding ca-certificates:
>
> piper:/etc> sudo find /etc -path /etc/alternatives -prune -o -type l -exec readlink -f {} \; | egrep -v '(^/etc|ca-certificates)' /var/lib/defoma/pango.d/pangox.aliases
> /lib/linux-sound-base/noOSS.modprobe.conf
> /lib/linux-sound-base/noOSS.modutils.conf
> /lib/linux-sound-base/noOSS.discover1.conf
> /usr/share/dict/web2
> /lib/linux-sound-base/noOSS.hotplug.blacklist
> /var/lib/defoma/fontconfig.d/fonts.conf
> /lib/linux-sound-base/ALSA.discover2.conf
> /usr/bin/Xorg
I'm surprised your report missed one of the most established
configuration symlinks of them all: /etc/localtime. I'm pointing that
out in particular because it has been around for as long as I can
remember, and serves its configuration function by pointing somewhere
under /usr/share.
All these symlinks allow programs to easily grab data and
configuration in one step. A program can open /etc/localtime and know
it is getting an up-to-date timezone file for the local timezone.
> I'd go as far as claiming that all these are bugs or design
> misdecisions.
Weakly disagree. That isn't to say that there is no problem: How can
we clear up the potential for confusion?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2006-10-31, 1:22 pm |
| * martin f krafft (madduck@debian.org) wrote:
> also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.1948 +0100]:
>
> alternatives are surely an exception, don't you think?
>
>
> I don't see the reason why /etc/dictionaries-common/words should be
> a symlink either. The right way to solve this would be to use
> alternatives and provide a second file to which a user can add
> additional words.
I'm truely unimpressed with the "users can't handle symlinks" argument.
There are other cases where symlinks in /etc have been used to capture
information (sendmail and/or SASL being another I've dealt with in the
past, also vservers) and in general I don't think there's anything
wrong with it. In all of these cases the files pointed to are not
intended to be modified but what file is used can be configured. I
believe the certificates are exactly this way (and, really, are quite
close to the alternatives setup).
Enjoy,
Stephen
| |
|
| On Oct 31, martin f krafft <madduck@debian.org> wrote:
> I consider this a bug, and even release-critical, and would say that
> ca-certificates should use ucf to maintain the certificates in
I don't. I think that symlinks to files somewhere are a good way to
solve this specific problem.
> /etc/ssl/certs. Arguments against that are to keep /etc small, but
> at 444k I don't see ca-certificates being a culprit.
444 kB is a lot of data. Everything counts.
--
ciao,
Marco
| |
| Agustin Martin 2006-10-31, 7:27 pm |
| On Tue, Oct 31, 2006 at 07:54:02PM +0100, martin f krafft wrote:
>
>
> I don't see the reason why /etc/dictionaries-common/words should be
> a symlink either. The right way to solve this would be to use
> alternatives and provide a second file to which a user can add
> additional words.
That symlink is set after a debconf question (at install time) or after a
selection script is run (select-default-wordlist). Manually setting
symlink is not the usual way of doing things here, although user can choose
it.
--
Agustin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mike Hommey 2006-10-31, 7:27 pm |
| On Tue, Oct 31, 2006 at 08:32:49PM +0100, martin f krafft <madduck@debian.org> wrote:
> also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2016 +0100]:
>
> How are certificate files not intended to be modified? If they
> expire? If they are incomplete?
Wouldn't you expect expired certificates handled by ca-certificates to
be updated by the package instead of by yourself ?
Mike
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-10-31, 7:27 pm |
| also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2016 +0100]:
> In all of these cases the files pointed to are not intended to be
> modified but what file is used can be configured.
How are certificate files not intended to be modified? If they
expire? If they are incomplete?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"gilmour's guitar sounds good
whether you've got a bottle of cider in your hand
or a keyboard and a mouse."
-- prof. bruce maxwell
| |
| Alex Pennace 2006-10-31, 7:27 pm |
| On Tue, Oct 31, 2006 at 08:32:49PM +0100, martin f krafft wrote:
> also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2016 +0100]:
>
> How are certificate files not intended to be modified? If they
> expire? If they are incomplete?
I see your point. ca-certificates may be a special case.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2006-10-31, 7:27 pm |
| * martin f krafft (madduck@debian.org) wrote:
> also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2016 +0100]:
>
> How are certificate files not intended to be modified? If they
> expire? If they are incomplete?
If they expire then they should be updated by the package. One does not
generally modify issued certificates. If the package isn't handling
certificate expiration then the point of having them packaged at all
pretty much goes away. Incomplete certificates would be a bug in the
package (by incomplete I expect you mean that somehow it's a partial
file, if you mean that some certificates are missing, then you're
certainly free to add those into that directory as regular files, or to
ask for inclusion of them in the package).
Thanks,
Stephen
| |
| Steve Langasek 2006-10-31, 7:27 pm |
| On Tue, Oct 31, 2006 at 07:10:45PM +0100, martin f krafft wrote:
> The recent ca-certificates upgrade overwrote this "configuration"
> simply because my /bin/cat call actually changed a file in
> /usr/share, where changes by the admin are not preserved. Yet, due
> to the links in /etc/ssl/certs, the admin is given the impression
> that these are configuration files and can thus be edited according
> to Debian's holy conffile handling policy.
> I consider this a bug, and even release-critical, and would say that
> ca-certificates should use ucf to maintain the certificates in
> /etc/ssl/certs. Arguments against that are to keep /etc small, but
> at 444k I don't see ca-certificates being a culprit.
Not release critical. You're welcome to debate whether it's a bug to ever
use symlinks in /etc, but Alex is right -- the historical understanding of
"configuration" here is the symlinks, not the targets.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frans Pop 2006-10-31, 7:27 pm |
| On Tuesday 31 October 2006 21:03, Stephen Frost wrote:
> If they expire then they should be updated by the package. One does
> not generally modify issued certificates. If the package isn't
> handling certificate expiration then the point of having them packaged
> at all pretty much goes away. Incomplete certificates would be a bug
> in the package (by incomplete I expect you mean that somehow it's a
> partial file, if you mean that some certificates are missing, then
> you're certainly free to add those into that directory as regular
> files, or to ask for inclusion of them in the package).
Which probably means that ca-certificates is a perfect candidate to be
updated on volatile.debian.net-soon-to-be-org for stable releases.
| |
| Joey Hess 2006-11-01, 1:44 am |
| Alex Pennace wrote:
>
> I'm surprised your report missed one of the most established
> configuration symlinks of them all: /etc/localtime.
I was more suprised that it explicitly excluded /etc/alernatives ..
--
see shy jo
| |
| Petter Reinholdtsen 2006-11-01, 7:23 am |
|
[Martin F Krafft]
> I consider this a bug, and even release-critical, and would say that
> ca-certificates should use ucf to maintain the certificates in
> /etc/ssl/certs. Arguments against that are to keep /etc small, but
> at 444k I don't see ca-certificates being a culprit.
>
> Comments?
I would say the bug is in the user expectations, not in the use of
symlinks. Blindly overwriting a "file" without checking if it is a
symlink seem like the bug to me. 
Friendly,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-01, 1:18 pm |
| also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2103 +0100]:
>
> If they expire then they should be updated by the package.
The problem with ca-certificate is that it follows policies which
I don't fully agree with. CAcert's level 3 certificate is not
included because CAcert has not been audited -- that process by
itself just smells commercial to me.
The package allows the user to cherry-pick the certificates to
enable anyway; why preselect?
> file, if you mean that some certificates are missing, then you're
> certainly free to add those into that directory as regular files,
> or to ask for inclusion of them in the package).
I don't want to maintain local certificates across the dozens of
machines on which I need them. And the package maintainer doesn't
seem too cooperative. See e.g. #352248 which has not received a note
yet.
also sprach Steve Langasek <vorlon@debian.org> [2006.10.31.2119 +0100]:
> Not release critical. You're welcome to debate whether it's a bug
> to ever use symlinks in /etc, but Alex is right -- the historical
> understanding of "configuration" here is the symlinks, not the
> targets.
I am not arguing that. I am arguing whether the setup isn't
misleading...
also sprach Joey Hess <joeyh@debian.org> [2006.10.31.2351 +0100]:
> Alex Pennace wrote:
>
> I was more suprised that it explicitly excluded /etc/alernatives ..
Would you edit the files in /etc/alternatives with an editor?
I see your point. However, /etc/alternatives deserves a special
treatment as it is unique in what it does and integrates with the
whole system.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"the vast majority of our imports come from outside the country."
- george w. bush
| |
| Stephen Frost 2006-11-01, 1:18 pm |
| * martin f krafft (madduck@debian.org) wrote:
> also sprach Stephen Frost <sfrost@snowman.net> [2006.10.31.2103 +0100]:
>
> The problem with ca-certificate is that it follows policies which
> I don't fully agree with. CAcert's level 3 certificate is not
> included because CAcert has not been audited -- that process by
> itself just smells commercial to me.
I don't see this as relevant to the debate about using symlinks in /etc.
> The package allows the user to cherry-pick the certificates to
> enable anyway; why preselect?
Because it's much more common for users to want at least some set of
certificates enabled on installation.
>
> I don't want to maintain local certificates across the dozens of
> machines on which I need them. And the package maintainer doesn't
> seem too cooperative. See e.g. #352248 which has not received a note
> yet.
What certificates are included and why sounds like an issue which
would be more appropriate for the technical committee to comment on,
given there's some disagreement regarding it. I don't believe this
is any reason to claim that using symlinks as configuration is an RC
bug.
As an aside, I'd probably side with the maintainer on this one (not that
I'm on the TC anyway). I don't really see being audited as being
'commercial' in some kind of bad way. Third-party audits are very
common and required by some governments (like the US) when working with
sensitive information. There's not exactly *fun* but having an external
conflict-free entity performing an audit is generally something I
consider a good thing.
> Would you edit the files in /etc/alternatives with an editor?
No, but you certainly might use 'cp' to overwrite them if you're don't
realize they're symlinks.
> I see your point. However, /etc/alternatives deserves a special
> treatment as it is unique in what it does and integrates with the
> whole system.
I really don't see how you can argue that it's acceptable for
alternatives but not for ca-certificates. I don't see that alternatives
being unique in what it does overall (as most packages are...) as
meaning that things which it does (symlinks as configuration) are only
acceptable for it to use. Either symlinks as configuration is bad and
should be done away with entirely, or they're acceptable and any package
is free to use them.
Thanks,
Stephen
| |
| Gabor Gombas 2006-11-02, 7:21 am |
| On Tue, Oct 31, 2006 at 07:10:45PM +0100, martin f krafft wrote:
> cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
>
> on systems that needed access to all of CACert's certificates.
Btw., mounting /usr read-only is a good way to prevent stupid bugs like
this. You can configure apt to re-mount it r/w when during package
install/removal so upgrade/install still works, and that catches 99% of
the cases you want to write under /usr. For the other 1% forcing you to
think and remount it manually is actually a good thing.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-02, 1:18 pm |
| also sprach Stephen Frost <sfrost@snowman.net> [2006.11.01.1605 +0100]:
>
> Because it's much more common for users to want at least some set
> of certificates enabled on installation.
Of course. But why not add other, common certificates, like CAcert
Class 3, and let the user decide whether to trust them? Anyway, as
others have said, this is another discussion.
> common and required by some governments (like the US) when working
> with sensitive information. There's not exactly *fun* but having
> an external conflict-free entity performing an audit is generally
> something I consider a good thing.
I think it's definitely good to see WebTrust be a cooperation
between US and Canadian accountants, but I am not sure whether this
qualifies as "conflict-free" for me here in .ch. In the end, it's
I who should decide whom I trust. But yeah, this is another matter
which I'll take up after etch.
>
> No, but you certainly might use 'cp' to overwrite them if you're
> don't realize they're symlinks.
I guess I've been doing Debian too long then. /etc/alternatives is
not something to me to touch without update-alternatives, and that's
the case even for Suse and Fedora.
I guess I'll have to add /etc/ssl/certs to the list of things Debian
does differently than the rest of the world.
Anyway, thanks for the discussion. I don't think I heard a single
argument for using symlinks, other than to save 440k of space in
/etc. I don't see how that's a reason for standard installations
these days.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
quantum mechanics: the dreams stuff is made of.
| |
| Gabor Gombas 2006-11-02, 1:18 pm |
| On Thu, Nov 02, 2006 at 12:01:12PM +0100, martin f krafft wrote:
> Anyway, thanks for the discussion. I don't think I heard a single
> argument for using symlinks, other than to save 440k of space in
> /etc.
Symlinks just make _sense_. It's the idiocy of other OSes to duplicate
data because they have no proper notion of symlinks. I always hate
arguments like this to "make things worse for people who know UNIX
because there are some dumb users who don't".
So, here is a constructive solution for those who do not like symlinks
in /etc:
- Rebuild OpenSSL with X509_CERT_DIR in crypto/cryptlib.h defined as
"/etc/ssl/certs:/var/ssl/certs". I did not test it, but looking at the
OpenSSL sources It Should Just Work.
- Change ca-certificates to create the symlinks in /var/ssl/certs
instead in /etc/ssl/certs, and make it clear that the user should not
manually alter the contents of /var/ssl/certs or else he/she should
keep both pieces when something breaks.
- Declare /etc/ssl/certs to be the playground of the local sysadmin. No
package should touch anything inside it.
That gives you the best of both wolds with minimal efforts.
Gabor
--=20
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
| |
| Gabor Gombas 2006-11-02, 1:18 pm |
| On Thu, Nov 02, 2006 at 02:24:33PM +0100, martin f krafft wrote:
> Why do the files need to be in /usr/share at all? Why not provide
> /etc/ssl/certs and /etc/ssl/certs/disabled and let the user use
> /bin/mv to enable/disable them.
Certificates are not configuration files so they should not be in
/etc.
On the other hand, the decision of which certificate files should be
USED _is_ a configuration decision, so that information should be under
/etc. So the current way of the certificates being under /usr/share and
symlinks to them being in /etc matches the intended (and expected) usage
of both /etc and /usr/share perfectly.
> At the same time, the debconf
> question about which ones to disable/enable could do exactly the
> same, and all the files would be proper configuration files that
> could be edited all the same.
The whole point of a certificate is that you CAN NOT edit it because
that would break the signature. You can only replace a certificate as a
whole, add a new one or delete an old one. Therefore it does not make
sense to list certificates as conffiles.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-02, 1:18 pm |
| also sprach Gabor Gombas <gombasg@sztaki.hu> [2006.11.02.1443 +0100]:
> Certificates are not configuration files so they should not be in
> /etc.
>
> On the other hand, the decision of which certificate files should
> be USED _is_ a configuration decision, so that information should
> be under /etc. So the current way of the certificates being under
> /usr/share and symlinks to them being in /etc matches the intended
> (and expected) usage of both /etc and /usr/share perfectly.
Yes, I am afraid I cannot argue this point, thank you for explaining
it very nicely.
I guess I am just trying to avoid at all cost having to point a lot
of configuration files on a lot of machines to
/etc/ssl/certs/local-cacert.pem and testing the result.
Sorry for the bother and thanks for staying strong.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"i dislike arguments of any kind. they are always vulgar, and often
convincing."
-- oscar wilde
| |
| martin f krafft 2006-11-02, 1:18 pm |
| also sprach Gabor Gombas <gombasg@sztaki.hu> [2006.11.02.1345 +0100]:
> Symlinks just make _sense_. It's the idiocy of other OSes to duplicate
> data because they have no proper notion of symlinks. I always hate
> arguments like this to "make things worse for people who know UNIX
> because there are some dumb users who don't".
Why do the files need to be in /usr/share at all? Why not provide
/etc/ssl/certs and /etc/ssl/certs/disabled and let the user use
/bin/mv to enable/disable them. At the same time, the debconf
question about which ones to disable/enable could do exactly the
same, and all the files would be proper configuration files that
could be edited all the same.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
NP: Porcupine Tree / Staircase Infinities
| |
| Joey Schulze 2006-11-04, 7:19 am |
| martin f krafft wrote:
> ca-certificates installs about 100 certificates into
> /etc/ssl/certs. However, these are not actually dropped into the
> directory; instead, symlinks into /usr/share are put in place:
>
> piper:/etc/ssl/certs# ls -la /etc/ssl/certs/cacert.org.pem
> lrwxrwxrwx 1 root root 52 2006-10-31 18:56 /etc/ssl/certs/cacert.org.pem -> /usr/share/ca-certificates/cacert.org/cacert.org.crt
>
> Since #350282 is still being discussed, I ended up doing
>
> cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem
Is /etc/ssl/certs/cacert.pem a configuration file at all? I.e. is it
meant to be site-edited/admin-edited? I would assume that all "files"
in /etc/ssl/certs/ contain only one certificate / upstream certificate
source.
> on systems that needed access to all of CACert's certificates.
Hmm. Why are the certificates in /etc/ssl/certs/cacert.pem used but
not those from /etc/ssl/certs/cacert-class3.pem?
There was a debconf question in which you could configure which
certificates you want to accept. Maybe you could accept the
cacert-class3 certificate as well?
> The recent ca-certificates upgrade overwrote this "configuration"
> simply because my /bin/cat call actually changed a file in
> /usr/share, where changes by the admin are not preserved. Yet, due
> to the links in /etc/ssl/certs, the admin is given the impression
> that these are configuration files and can thus be edited according
> to Debian's holy conffile handling policy.
Even worse, the directory listing is totally unreadable because of the
large number of certificates and links in this directory. Navigating
through it is no fun...
> I consider this a bug, and even release-critical, and would say that
> ca-certificates should use ucf to maintain the certificates in
> /etc/ssl/certs. Arguments against that are to keep /etc small, but
> at 444k I don't see ca-certificates being a culprit.
Maybe one improvement would be to reduce the number of links in this
directory to one per certificate. Currently for each certificate
provided by ca-certificates the certificate has a link to /usr/share/..
and the hash has a link to the other link. Wouldn't it be possible to
only create the hash link as a symbolic link to /usr/share/...?
> Please don't tell me to use an editor that writes a new inode when
> changing files. It's not a solution to the problem, even though it
> would address the symptom.
..oO( delink )
Regards,
Joey
--
Reading is a lost art nowadays. -- Michael Weber
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-04, 7:19 am |
| also sprach Joey Schulze <joey@infodrom.org> [2006.11.04.1252 +0100]:
> Hmm. Why are the certificates in /etc/ssl/certs/cacert.pem used but
> not those from /etc/ssl/certs/cacert-class3.pem?
Because I had to disable the use of CAdir and use CAfile instead,
due to performance issues:
http://people.debian.org/~terpstra/...bfc5029.en.html
> There was a debconf question in which you could configure which
> certificates you want to accept. Maybe you could accept the
> cacert-class3 certificate as well?
cacert-class3 is locally added. See #350282.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
NP: Incredible Expanding MindXXXX / Incredible Expanding MindXXXX
| |
| Joey Schulze 2006-11-04, 7:19 am |
| martin f krafft wrote:
> also sprach Joey Schulze <joey@infodrom.org> [2006.11.04.1252 +0100]:
>
> Because I had to disable the use of CAdir and use CAfile instead,
> due to performance issues:
>
> http://people.debian.org/~terpstra/...bfc5029.en.html
Hmm, why don't you use a CAfile which is not provided by the
package but one that is created by you on your own and which only
incorporates the certificates you want to accept? That way you
won't interfer with packaging.
Does enabling with debconf only those certificates you want to accept
not help as well?
>
> cacert-class3 is locally added. See #350282.
Hmm. When using the directory it should be sufficient to add the
missing hash link in /etc/ssl/certs?
openssl x509 -hash -noout -in cacert-class3.pem will calculate it.
Don't forget to add ".0" to the calculated name.
Regards,
Joey
--
Reading is a lost art nowadays. -- Michael Weber
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-04, 1:16 pm |
| also sprach Joey Schulze <joey@infodrom.org> [2006.11.04.1315 +0100]:
> Hmm, why don't you use a CAfile which is not provided by the
> package but one that is created by you on your own and which only
> incorporates the certificates you want to accept? That way you
> won't interfer with packaging.
Yes, this is the only solution it seems; but since I am talking
about at least 30 machines, and many tools, like postfix, OpenVPN,
Apache2 etc. using these certificates, changing it is not going to
be an easy endeavour and will require much testing.
> Does enabling with debconf only those certificates you want to
> accept not help as well?
As said, CAcert class 3 is not provided.
> openssl x509 -hash -noout -in cacert-class3.pem will calculate it.
> Don't forget to add ".0" to the calculated name.
c_rehash will do the same. You're right, I could also just remove
ca-certificates, or limit what it provides, and then all's well.
Thanks.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"what's your conceptual continuity? --
well, it should be easy to see:
the crux of the bisquit is the apopstrophe!"
-- frank zappa
| |
| Kurt Roeckx 2006-11-04, 1:16 pm |
| On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote:
>
> Maybe one improvement would be to reduce the number of links in this
> directory to one per certificate. Currently for each certificate
> provided by ca-certificates the certificate has a link to /usr/share/..
> and the hash has a link to the other link. Wouldn't it be possible to
> only create the hash link as a symbolic link to /usr/share/...?
I'm not sure the current c_rehash supports that. People (or scripts)
may want to run c_rehash on /etc/ssl/certs, at which point it would
remove the hash links, and you have nothing left.
We need something that says "those certificates should be in
/etc/ssl/certs", and I don't think the hash symlinks work for that.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Schulze 2006-11-04, 1:16 pm |
| Kurt Roeckx wrote:
> On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote:
>
> I'm not sure the current c_rehash supports that. People (or scripts)
> may want to run c_rehash on /etc/ssl/certs, at which point it would
> remove the hash links, and you have nothing left.
Are the hashes recalculated randomly? Which programs do that?
(since I was left with a missing hash several times, at least
I don't seem to have such a program installed)
Regards,
Joey
--
Reading is a lost art nowadays. -- Michael Weber
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kurt Roeckx 2006-11-04, 1:16 pm |
| On Sat, Nov 04, 2006 at 02:30:54PM +0100, Joey Schulze wrote:
> Kurt Roeckx wrote:
>
> Are the hashes recalculated randomly? Which programs do that?
> (since I was left with a missing hash several times, at least
> I don't seem to have such a program installed)
It seems there is an update-ca-certificates, which has a config file
(/etc/ca-certificates.conf) that says which certificates should be
enabled.
It runs c_rehash at the end of it, to regenerate the hashes.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2006-11-04, 1:16 pm |
| also sprach Kurt Roeckx <kurt@roeckx.be> [2006.11.04.1448 +0100]:
> It seems there is an update-ca-certificates, which has a config file
> (/etc/ca-certificates.conf) that says which certificates should be
> enabled.
... at which point it's really pointless to argue that the symlinks
to /usr/share in /etc/ssl/certs are configuration data to decide
which certificates are enabled.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"i am a deeply superficial person."
-- andy warhol
| |
| Joey Schulze 2006-11-04, 1:16 pm |
| Kurt Roeckx wrote:
>
> It seems there is an update-ca-certificates, which has a config file
> (/etc/ca-certificates.conf) that says which certificates should be
> enabled.
>
> It runs c_rehash at the end of it, to regenerate the hashes.
The name suggests that it comes from the ca-certificates package.
If something in this package is changed, it shouldn't be a real
showstopper to modify this script as well, should it?
Regards,
Joey
--
Reading is a lost art nowadays. -- Michael Weber
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|