Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

[Andras Korn]

On Wed, Jan 13, 2021 at 05:12:39PM -0800, Ryan Tandy wrote:

Hi,

> > Can you somehow make the library complain very loudly when an attempt is
> > made to use CACERTDIR, but the setting is ignored?
> 
> This is not sarcastic, but a good faith question: if it had printed
> something to stderr, would you have seen it?

Yes. I have sssd logging to stderr and use svlogd to write the messages to
files. Whatever the library printed on stderr would have appeared among the
sssd log messages.

> I don't think I have any way to
> make something appear in (for example) sssd's own log file.

Probably not. The realistic alternatives are stderr and syslog.

> In fact, it does already log a warning, but I suppose most applications
> using the library probably don't enable any log level.

Exactly. I had to use an (at the time) undocumented setting to turn up
libldap debugging in sssd to see what was going on.

> https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_4/libraries/libldap/tls_g.c#L187-190

Yes, this is the warning I eventually saw, once I knew where to look.

Since a configuration where no CA certificates are trusted and you still try
to use TLS is unlikely to be useful, I think a loud warning to stderr would
be appropriate in this case.

> On Wed, Jan 13, 2021 at 01:44:07PM +0100, Andras Korn wrote:
> > OK, looking further, part of the problem is that I didn't have
> > libldap-common installed, thus no /etc/ldap/ldap.conf.
> > 
> > Since this (and the accompanying manpage) is all that libldap-common
> > contains: what's the rationale for having these in a separate package?
> 
> Policy 8.2: "If your package contains files whose names do not change with
> each change in the library shared object version, you must not put them in
> the shared library package."

Okay, that makes sense. :(

I'm not sure what a good solution would be. It doesn't seem appropriate to
Depends on libldap-common, because libldap can definitely be used without
it; on the other hand, Debian does have sensible defaults for CAECERT & co,
but those are only enabled when the user installs a package that's merely
Recommended and thus easily missed.

As a user, my expectation would be not to have to configure CACERT* for
distribution packages, because the distribution has a well-known location
for system-wide trusted CA certificates; I would expect all packages to
default to using that. The status quo appears to violate the principle of
least surprise.

> > The libldap package only Recommends libldap-common (which is why I didn't
> > have it); however, it is libldap-common that enables the sensible defaults.
> > 
> > Why shouldn't libldap come with the sensible defaults itself?
> 
> It's your decision whether to install Recommends or not, but AFAIK it's
> generally not considered a bug if some feature or behaviour is missing when
> Recommends are not installed.

I don't think it's worthwhile to debate whether this is technically a bug or
not; it's an unfortunate situation, and I hope there is some way we (well,
mostly you and the other maintainers) can improve it.

> Why isn't the default in the code of libldap → this is upstream's decision,
> and I won't introduce a Debian-local change to override it, sorry.

In fact, it seems wrong that these defaults (and configuration) should be
specific to libldap; to me it would seem appropriate for Debian to ship
libgnutls so that by default it uses the CA certificate store of the
distribution. The upstream default of not trusting any certificates by
default makes sense for the upstream project, but not, IMO, for a
distribution that's expected to be integrated and self-consistent.

András

-- 
             Optimist: Someone who doesn't know all the facts yet.