[debian-mysql] Bug#671534: Use case?

[Nicholas Bamber]

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<nicholas at 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.