From owner-svn-ports-head@freebsd.org Fri Jul 17 10:02:55 2015 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CE3B9A20FB for ; Fri, 17 Jul 2015 10:02:55 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52C65106E for ; Fri, 17 Jul 2015 10:02:53 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 64975 invoked from network); 17 Jul 2015 09:56:09 -0000 Received: from 2-228-102-65.ip191.fastwebnet.it (HELO ale.bitgold.com) (sysadmin@alexdupre.com@2.228.102.65) by lab.alexdupre.com with ESMTPSA; 17 Jul 2015 09:56:09 -0000 Message-ID: <55A8D138.2050901@FreeBSD.org> Date: Fri, 17 Jul 2015 11:56:08 +0200 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: Erwin Lansing CC: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r392140 - head/databases/mysql56-server References: <201507151349.t6FDn5Sf079974@svnmir.geo.freebsd.org> <20150717081711.GS63119@droso.dk> In-Reply-To: <20150717081711.GS63119@droso.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 10:02:55 -0000 Erwin Lansing wrote: >> URL: https://svnweb.freebsd.org/changeset/ports/392140 >> >> Log: >> Update to 5.6.25 release. > > Does this by any change fix this vulnerability? No, probably they are not going to fix this "vulnerability" because, even if it wasn't a great security choice and in fact it changed in mysql 5.7, it was the intended and documented behavior: > For MySQL client programs, this option permits but does not require the client to connect to the server using SSL. Therefore, this option is not sufficient in itself to cause an SSL connection to be used. For example, if you specify this option for a client program but the server has not been configured to enable SSL connections, the client falls back to an unencrypted connection. -- Alex Dupre