tag 671534 +confirmed
thanks
Well then if I or noone else can think of any more objections that is
what will happen. There is one other SSL related bug so they should get
looked at together - which will probably be after the package is
lintian and piuparts clean.
On 05/05/12 20:49, Clint Byrum wrote:
Excerpts from Nicholas Bamber's message of Sat May 05 12:00:49 -0700 2012:
On 05/05/12 19:51, Russ Allbery wrote:
Nicholas Bamber<nicho...@periapt.co.uk> writes:
Although in general I am all for standardization, I am not
actually clear about the use case here.
The typical case to which you refer is a browser-like client
talking to a webserver-like server using certificates checkable with
external authorities.
In the MySQL case both client and server must be using MySQL code
at some level and the certificates are likely to be managed by an
authority internal to the oganization.
I don't really agree with your last assumption... or at least this isn't
true of us at Stanford. We use commercial Comodo certificates for
anything internal that isn't just test/dev (and increasingly for that),
since we have a site-license for Comodo certificates and they're free.
There's no reason not to, and using a CA that's already built into various
software makes everything easier. (This is likely common for US
universities that are part of Internet2, since Internet2 negotiated a
general agreement with Comodo.)
But even apart from that, suppose it is managed by an authority internal
to the organization. The obvious thing to do with the certificate for
that internal CA on a Debian system is to put it into
/usr/local/share/ca-certificates and then let ca-certificates add it to
all the other trusted CAs. That way, certificates issued by your internal
CA will transparently work with anything on a Debian system that uses SSL,
not just web browsers.
We use that same /etc/ssl/certs infrastructure for our internal Usenet
server, for the certificates for our LDAP servers, our SMTP servers, and
so forth. (And indeed for LDAP and SMTP, even if you don't have free
commercial certificates, it's usually a good idea to get commercial
certificates so that you don't have to deal with the CA distribution
hassle.)
Also, it's worth mentioning that anyone can get free trusted certificates
that will be verified by the /etc/ssl/certs infrastructure from
cacert.org.
I suppose the drawback to using /etc/ssl/certs by default is that people
may not want to trust the commercial CA authorities by default, and there
are some reasons to be concerned about that. But, there, I think the risk
for MySQL in most ways in which it's used is probably lower than for the
web browser, since the MySQL clients are more likely to be on controlled
networks and therefore less likely to be prone to easy man-in-the-middle
attacks.
<< fixed top post>>
Russ,
What if the location were configurable via debconf. (I have not checked
if it is or not). The explanatory text could offer your choice as a
possible location.
I really dislike this idea. Debconf questions are for things that don't
have sane defaults. Perhaps if this were *low* priority and the default
was /etc/ssl/certs.
IMO, if you are centrally managing your own CA certs, you are more likely
to put them in /etc/ssl/certs than anywhere else. Why would we encourage
divergence from a positive pattern like that?
I think the idea is a good one, and would like to see it done at some
point.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
