Re: MySQL 5.5 EOL before Debian 8 LTS ends

2018-01-23 Thread Jan Ingvoldstad

On 2018-01-24 08:02, Moritz Mühlenhoff wrote:

That sounds far too disruptive for an LTS; better declare announce the server
part of mysql (where all the vulnerabilities apply) as unsupported in advance
and in December change the package to only build the libmysqlclient parts.
The client library part is usually not affected by any security issues and
that way you don't risk any regressions.

People then have a year to migrate their servers to jessie (or ideally
update/reimage to stretch)


Additionally, Oracle already provides MySQL 5.6 for both Wheezy and 
Jessie according to https://dev.mysql.com/downloads/repo/apt/, so there 
appears to be little need for the LTS team to make a specific effort to 
support MySQL 5.6 server when 5.5 security support reaches EOL.


Or are there plans in Oracle to drop support for old-stable etc.?
--
Cheers,
Jan



Re: MySQL 5.5 EOL before Debian 8 LTS ends

2018-01-23 Thread Moritz Mühlenhoff
On Tue, Jan 23, 2018 at 11:41:57AM +0100, Lars Tangvald wrote:
> I can't find much of anything that has changed from 5.5 to 5.6 in terms of
> default behavior, except for NO_ENGINE_SUBSTITUTION being the default
> sql_mode 
> (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution).
> I'll do some more digging, but I don't think there should be much impact on
> reverse-dependencies.
> 
> Some options were removed
> https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed).
> We did see quite a few regressions of that type for users upgrading from 5.5
> to 5.7, but almost all were because the default 5.5 config in Ubuntu
> packaging contained options that were removed in 5.7.

That sounds far too disruptive for an LTS; better declare announce the server
part of mysql (where all the vulnerabilities apply) as unsupported in advance
and in December change the package to only build the libmysqlclient parts.
The client library part is usually not affected by any security issues and
that way you don't risk any regressions.

People then have a year to migrate their servers to jessie (or ideally
update/reimage to stretch)

Cheers,
Moritz






Re: MySQL 5.5 EOL before Debian 8 LTS ends

2018-01-23 Thread Markus Koschany


Am 23.01.2018 um 11:41 schrieb Lars Tangvald:
> Hi,
> 
> On 01/22/2018 04:35 PM, Markus Koschany wrote:
[...]
>> I also think it makes sense to take a smaller step and upgrade from 5.5
>> to 5.6. Are there any known issues with 5.6 or can you share any
>> information about expected regressions with reverse-dependencies?
> I can't find much of anything that has changed from 5.5 to 5.6 in terms
> of default behavior, except for NO_ENGINE_SUBSTITUTION being the default
> sql_mode
> (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution).
> I'll do some more digging, but I don't think there should be much impact
> on reverse-dependencies.
> 
> Some options were removed
> https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often
> renamed). We did see quite a few regressions of that type for users
> upgrading from 5.5 to 5.7, but almost all were because the default 5.5
> config in Ubuntu packaging contained options that were removed in 5.7.

What do you (and other on this list) think about the following plan: We
could introduce a mysql-5.6 package already at the start of Jessie LTS
in June, so that LTS users are able to test this new version without
having to switch from 5.5. Then in 2019, when the security support for
MySQL has ended, we perform an upgrade from 5.5 to 5.6. Is this a viable
plan and could both packages coexist?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


testing wireshark for Wheezy LTS

2018-01-23 Thread Thorsten Alteholz

Hi everybody,

I uploaded version 1.12.1+g01b65bf-4+deb8u6~deb7u9 of wireshark to:

https://people.debian.org/~alteholz/packages/wheezy-lts/wireshark/

It contains patches for CVE-2018-5334, CVE-2018-5335 and CVE-2018-5336.

Please give it a try and tell me about any problems you met.

Thanks!
 Thorsten






Re: wheezy update of openafs

2018-01-23 Thread Benjamin Kaduk
On Tue, Jan 23, 2018 at 06:52:52PM +0100, Emilio Pozuelo Monfort wrote:
> On 23/01/18 17:29, Benjamin Kaduk wrote:
> > Hi all,
> > 
> > As recorded in #886799 (and the merged bugs), the recent linux
> > kernel updates including meltdown remediation also included a kernel
> > ABI change that breaks the openafs DKMS module (and non-DKMS module,
> > for what it's worth).  The fix for openafs is pretty simple; just
> > cherry-pick a couple of upstream patches, but it's not entirely
> > clear that this update should be considered a "security issue", and
> > thus I am unclear on what process at
> > https://wiki.debian.org/LTS/Development really applies.
> > Should I just find a DD to sponsor the upload to wheezy-security and
> > get the new package available, or is there some additional (review?)
> > step as there would for a non-LTS security update or SRU?
> 
> We could do some sort of a regression update. Or just a compatibility update.
> Call it what you want :)
> 
> Can you point to those patches?

I just pushed my current state to the packaging git repo at
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/log/?id=refs/heads/wheezy
, though I was planning to do a little more testing with a clean
build/etc. before requesting upload.

Note that the last several updates to openafs in wheezy were done by
the LTS team directly and not put into git, so I have some cleanup
commits to attempt to synchronize the state in git with the state in
the apt repo.  It seems that with the single-debian-patch scheme
openafs uses in wheezy, the debian-patch that is generated is not
done reproducibly, with files being changed appearing in different
order.  The extracted source package does not differ other than the
debian-changes file, though, which is I think as good as we can get.
(Starting with jessie we switched to using separated patches for
openafs.)

Thanks,

Ben



Re: wheezy update of openafs

2018-01-23 Thread Emilio Pozuelo Monfort
On 23/01/18 17:29, Benjamin Kaduk wrote:
> Hi all,
> 
> As recorded in #886799 (and the merged bugs), the recent linux
> kernel updates including meltdown remediation also included a kernel
> ABI change that breaks the openafs DKMS module (and non-DKMS module,
> for what it's worth).  The fix for openafs is pretty simple; just
> cherry-pick a couple of upstream patches, but it's not entirely
> clear that this update should be considered a "security issue", and
> thus I am unclear on what process at
> https://wiki.debian.org/LTS/Development really applies.
> Should I just find a DD to sponsor the upload to wheezy-security and
> get the new package available, or is there some additional (review?)
> step as there would for a non-LTS security update or SRU?

We could do some sort of a regression update. Or just a compatibility update.
Call it what you want :)

Can you point to those patches?

Cheers,
Emilio



wheezy update of openafs

2018-01-23 Thread Benjamin Kaduk
Hi all,

As recorded in #886799 (and the merged bugs), the recent linux
kernel updates including meltdown remediation also included a kernel
ABI change that breaks the openafs DKMS module (and non-DKMS module,
for what it's worth).  The fix for openafs is pretty simple; just
cherry-pick a couple of upstream patches, but it's not entirely
clear that this update should be considered a "security issue", and
thus I am unclear on what process at
https://wiki.debian.org/LTS/Development really applies.
Should I just find a DD to sponsor the upload to wheezy-security and
get the new package available, or is there some additional (review?)
step as there would for a non-LTS security update or SRU?

Thanks,

Ben



Re: MySQL 5.5 EOL before Debian 8 LTS ends

2018-01-23 Thread Lars Tangvald

Hi,

On 01/22/2018 04:35 PM, Markus Koschany wrote:

Hi,

Am 22.01.2018 um 13:42 schrieb Lars Tangvald:

Hi,

First off, thanks for handling the 5.5.59 update for Wheezy. I had the
security announcement date mixed up so picked it up too late, sorry.

MySQL 5.5 is expected to be EOL in December (it was first released
December 15, 2010, and we have 8 year security support), while Jessie
LTS is until April 2020
How are such cases handled? Will the source package be removed, or is it
possible to have it upgraded to a more recent version?

These are both possible options but given the significance of MySQL we
would rather prefer to upgrade to a supported release provided this is
viable for Jessie.


If an upgrade is possible, while we did a successful transition in
Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7,
requiring small changes to a lot of third-party packages as well as to
the default server behavior, so 5.6 (which is supported until 2021)
would be a better option.

I also think it makes sense to take a smaller step and upgrade from 5.5
to 5.6. Are there any known issues with 5.6 or can you share any
information about expected regressions with reverse-dependencies?
I can't find much of anything that has changed from 5.5 to 5.6 in terms 
of default behavior, except for NO_ENGINE_SUBSTITUTION being the default 
sql_mode 
(https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). 
I'll do some more digging, but I don't think there should be much impact 
on reverse-dependencies.


Some options were removed 
https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often 
renamed). We did see quite a few regressions of that type for users 
upgrading from 5.5 to 5.7, but almost all were because the default 5.5 
config in Ubuntu packaging contained options that were removed in 5.7.


--
Lars

Regards,

Markus