[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Refreshing mysql-connector-java


On 07/06/2020 10:48, Salvatore Bonaccorso wrote:
> On Fri, Jun 05, 2020 at 09:23:12AM +0200, Sylvain Beucler wrote:
> [...]
>> Hi Salvatore,
>> On 04/06/2020 20:41, Salvatore Bonaccorso wrote:
>>> On Mon, May 25, 2020 at 07:47:56PM +0200, Moritz Mühlenhoff wrote:
>>>> On Mon, May 25, 2020 at 10:22:50AM +0200, Sylvain Beucler wrote:
>>>>> Hi Security Team,
>>>>> What is your view on updating mysql-connector-java 5.1.42->5.1.49 for
>>>>> Stretch?
>>>> We can update to 5.1.49, yes. We've had to update it to new 5.1.x
>>>> releases in the past and I don't remember any issues. The fact
>>>> that there's zero information totally sucks, but there's nothing
>>>> we can do either (apart from removing it as we did a year ago).
>>>> Looking at the debdiff from https://www.beuc.net/tmp/debian-lts/mysql-connector-java/
>>>> the remaining change would be to change the version number to
>>>> 5.1.49-1~deb9u1 and the targets distro to stretch-security.
>>> I'm a bit late to the party, but just want to give my 2 cents on the
>>> versioning scheme. Agreed here to not use the really-something
>>> variant. usually I think this is usefull when you have rebased
>>> soemthing to a *higher* version, but need to rollback. Example:
>>> graphicsmagick/1.4+really1.3.35+hg16296-1
>>> or
>>> lxc/1:3.1.0+really3.0.4-3
>>> (other examples exists)
>> OK. I had used +really for the ELTS package to test what I should do in
>> the event that there would be objections or major delays in bumping to
>> 5.1.49 in other suites, like e.g.:
>> https://security-tracker.debian.org/tracker/source-package/tomcat7
>> 7.0.56-3+really7.0.100-1+deb8u1 < 7.0.75-1
> You are right, this indeed can be a use case as well for the +really
> syntax (this case did not come to my mind). Though I think this should
> only be done (within Debian for the respective ssupported security
> wise suites) if the later suite version contains all the fixes (and
> not so introducing a regression).

In that regard, let's note that tomcat7 is a tricky example, because the
version in stretch is trimmed-down and only provides libservlet, hence
does not need to have the same level of fixes.


Reply to: