Bug#1004180: [External] : Bug#1004180: mysql-8.0: should mysql-8.0 be removed from unstable?

[Lars Tangvald]

Hi,

This is on me. I've been working on getting updates ready, but let 
myself get bogged down with more long-running updates to the packaging 
(which is pretty outdated with regards to things like the standards 
version).


I'd like to make a better effort to keep it up-to-date (just focusing on 
keeping MySQL itself updated for now, I think).


--
Lars

On 22/01/2022 10:53, Salvatore Bonaccorso wrote:

Source: mysql-8.0
Version: 8.0.23-3
Severity: normal
X-Debbugs-Cc: car...@debian.org, 
t...@security.debian.org,locutusofb...@debian.org, lars.tangv...@oracle.com

Hi

While mysql-8.0 itself won't enter testing, the version in unstable is
as well only from february 2021, lacking behind several updates for
fixes in the Oracle CPUs.

Should mysql-8.0 be removed as well from unstable?

Regards,
Salvatore

Bug#992239: Security fixes from the July 2021 CPU

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.23
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for July 2021 lists CVEs affecting 
MySQL 8.0

that are fixed in 8.0.26

CVE list:

  - CVE-2019-17543 CVE-2021-2339 CVE-2021-2340 CVE-2021-2342
  - CVE-2021-2352 CVE-2021-2354 CVE-2021-2356 CVE-2021-2357
  - CVE-2021-2367 CVE-2021-2370 CVE-2021-2372 CVE-2021-2374
  - CVE-2021-2383 CVE-2021-2384 CVE-2021-2385 CVE-2021-2387
  - CVE-2021-2389 CVE-2021-2390 CVE-2021-2399 CVE-2021-2402
  - CVE-2021-2410 CVE-2021-2412 CVE-2021-2417 CVE-2021-2418
  - CVE-2021-2422 CVE-2021-2424 CVE-2021-2425 CVE-2021-2426
  - CVE-2021-2427 CVE-2021-2429 CVE-2021-2437 CVE-2021-2440
  - CVE-2021-2441 CVE-2021-2444 CVE-2021-22901


Ref: https://www.oracle.com/security-alerts/cpujul2021.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#988718: Security fixes from the April 2021 Patch Update

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.23
Severity: grave
Tags: security upstream fixed-upstream


The Oracle Critical Patch Update for April 2021 lists CVEs affecting MySQL 8.0 
that are fixed in 8.0.25

CVE list:
  CVE-2020-1971 CVE-2021-2144 CVE-2021-2146 CVE-2021-2160
  CVE-2021-2162 CVE-2021-2164 CVE-2021-2166 CVE-2021-2169
  CVE-2021-2170 CVE-2021-2171 CVE-2021-2172 CVE-2021-2174
  CVE-2021-2178 CVE-2021-2179 CVE-2021-2180 CVE-2021-2193
  CVE-2021-2194 CVE-2021-2196 CVE-2021-2201 CVE-2021-2202
  CVE-2021-2203 CVE-2021-2208 CVE-2021-2212 CVE-2021-2213
  CVE-2021-2215 CVE-2021-2217 CVE-2021-2226 CVE-2021-2230
  CVE-2021-2232 CVE-2021-2278 CVE-2021-2293 CVE-2021-2298
  CVE-2021-2299 CVE-2021-2300 CVE-2021-2301 CVE-2021-2304
  CVE-2021-2305 CVE-2021-2307 CVE-2021-2308 CVE-2021-3449
  CVE-2021-23841 CVE-2020-28196

Ref: https://www.oracle.com/security-alerts/cpuapr2021.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#980795: Security fixes from the January 2021 CPU

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.22
Severity: grave
Tags: security upstream fixed-upstream


The Oracle Critical Patch Update for October 2020 lists CVEs affecting MySQL 
8.0 that are fixed in 8.0.23

CVE list:
    - CVE-2021-1998 CVE-2021-2001 CVE-2021-2002 CVE-2021-2087
    - CVE-2021-2009 CVE-2021-2012 CVE-2021-2016 CVE-2021-2019
    - CVE-2021-2020 CVE-2021-2021 CVE-2021-2022 CVE-2021-2024
    - CVE-2021-2028 CVE-2021-2030 CVE-2021-2031 CVE-2021-2032
    - CVE-2021-2036 CVE-2021-2038 CVE-2021-2042 CVE-2021-2046
    - CVE-2021-2048 CVE-2021-2055 CVE-2021-2056 CVE-2021-2058
    - CVE-2021-2060 CVE-2021-2061 CVE-2021-2065 CVE-2021-2070
    - CVE-2021-2072 CVE-2021-2076 CVE-2021-2081 CVE-2021-2088
    - CVE-2021-2122

Ref: https://www.oracle.com/security-alerts/cpujan2021.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#972623: Security fixes from the October 2020 CPU

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.21
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2020 lists CVEs affecting 
MySQL 8.0

that are fixed in 8.0.22

CVE list:

    - CVE-2020-14672 CVE-2020-14765 CVE-2020-14769 CVE-2020-14771
    - CVE-2020-14773 CVE-2020-14775 CVE-2020-14776 CVE-2020-14777
    - CVE-2020-14785 CVE-2020-14786 CVE-2020-14789 CVE-2020-14790
    - CVE-2020-14791 CVE-2020-14793 CVE-2020-14794 CVE-2020-14799
    - CVE-2020-14800 CVE-2020-14804 CVE-2020-14809 CVE-2020-14812
    - CVE-2020-14814 CVE-2020-14821 CVE-2020-14827 CVE-2020-14828
    - CVE-2020-14829 CVE-2020-14830 CVE-2020-14836 CVE-2020-14837
    - CVE-2020-14838 CVE-2020-14839 CVE-2020-14844 CVE-2020-14845
    - CVE-2020-14846 CVE-2020-14848 CVE-2020-14852 CVE-2020-14860
    - CVE-2020-14861 CVE-2020-14866 CVE-2020-14867 CVE-2020-14868
    - CVE-2020-14869 CVE-2020-14870 CVE-2020-14873 CVE-2020-14878
    - CVE-2020-14888 CVE-2020-14891 CVE-2020-14893

Ref: https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#949994: [debian-mysql] Bug#949994: mysql-5.7: Security fixes from the January 2020 CPU

[Lars Tangvald]

Thanks. I'm waiting for maintainer access to the source package, and I 
should be able to finally get all these closed.


--
Lars

On 28.01.2020 08:20, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.26-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

See
https://www.oracle.com/security-alerts/cpujan2020.html#AppendixMSQL
for a list of CVEs affecting src:mysql-5.7.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=alqB5idfnDxLLAZZRzTyPF-_phj0QvZhm6Pp3-PiXx4=GnTMOde4S5uaLlMk05fv3wrC7xQppp--bnFjJiJ3vW0=

Bug#942443: [debian-mysql] Bug#942443: mysql-5.7: Security fixes from the October 2019 CPU

[Lars Tangvald]

CVE list for this:
CVE-2019-2910
CVE-2019-2911
CVE-2019-2914
CVE-2019-2922
CVE-2019-2923
CVE-2019-2924
CVE-2019-2938
CVE-2019-2946
CVE-2019-2948
CVE-2019-2960
CVE-2019-2969
CVE-2019-2974
CVE-2019-2993
CVE-2019-5443

We haven't been doing good at keeping this updated for the last releases 
(the idea was to get me DM access so I could handle these updates more 
completely, but that process got shifted to the backlog), but should 
hopefully get a better routine going soon.


--
Lars

On 16.10.2019 15:44, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.26-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

See
https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html#AppendixMSQL
for a list of CVEs affecting src:mysql-5.7.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=-ogVBfRz2X5KngEiEZkXWFx9kEc58BoIgntG0JdjTyk=z1VCXUIIvVAVfCTOV7ajcwEmRZNhw1y1PhM1Tvidurs=

Bug#919817: [debian-mysql] Bug#919817: mysql-5.7: Security fixes from the January 2019 CPU

[Lars Tangvald]

CVE List:

CVE-2018-0734
CVE-2019-2420
CVE-2019-2434
CVE-2019-2455
CVE-2019-2481
CVE-2019-2482
CVE-2019-2486
CVE-2019-2503
CVE-2019-2507
CVE-2019-2510
CVE-2019-2528
CVE-2019-2529
CVE-2019-2531
CVE-2019-2532
CVE-2019-2534
CVE-2019-2537

I'll build and test the update so we can get it uploaded.

--
Lars
On 19.01.2019 22:14, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.24-3
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

Details at
https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html#AppendixMSQL

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=V6YWmDTP8Up8aqe6FOgySAUbY7C2l8NgxQlnOECX4Yw=3kTGAVctD96CB83WxpUcWMWEa46FgDCXmzXLUox2QU4=

Bug#911221: [debian-mysql] Bug#911221: mysql-5.7: Security fixes from the October 2018 CPU

[Lars Tangvald]

Hi

5.7.24 has been released now. I'll prepare the upload for unstable.

--

Lars


On 17. okt. 2018 11:11, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.23-2
Severity: grave
Tags: security upstream

Hi

Details at
https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html#AppendixMSQL

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=oUNuxPUyTQQx5a12PpzMJwm47_jhWIY1scwAB-URt8w=aHrxW7S4046O6qppWp64O5oH-yk4WDK50_kcaUkm28o=

Bug#904121: [debian-mysql] Bug#904121: mysql-5.7: Security fixes from the July 2018 CPU

[Lars Tangvald]

Correction: This should be for 5.7.22, I think.

CVE List:

CVE-2018-0739
CVE-2018-2767
CVE-2018-3054
CVE-2018-3056
CVE-2018-3058
CVE-2018-3060
CVE-2018-3061
CVE-2018-3062
CVE-2018-3064
CVE-2018-3065
CVE-2018-3066
CVE-2018-3070
CVE-2018-3071
CVE-2018-3077
CVE-2018-3081

--
Lars
On 07/20/2018 06:16 AM, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.21-1
Severity: grave
Tags: security upstream

Hi

Details at
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixMSQL

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=Tq3zgUxLP9VPxRizyk970lApjdVTW2UvIdYPB8mMBTg=DzD9IdE2F3yP_VZ3HIvzbNqu8L292dV2gc4xenDaLZw=

Bug#904121: [debian-mysql] Bug#904121: mysql-5.7: Security fixes from the July 2018 CPU

[Lars Tangvald]

Also note 5.7.23 has not yet been released (it will be out by the end of 
the month).


--
Lars

On 07/20/2018 07:34 AM, Lars Tangvald wrote:

Correction: This should be for 5.7.22, I think.

CVE List:

CVE-2018-0739
CVE-2018-2767
CVE-2018-3054
CVE-2018-3056
CVE-2018-3058
CVE-2018-3060
CVE-2018-3061
CVE-2018-3062
CVE-2018-3064
CVE-2018-3065
CVE-2018-3066
CVE-2018-3070
CVE-2018-3071
CVE-2018-3077
CVE-2018-3081

--
Lars
On 07/20/2018 06:16 AM, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.21-1
Severity: grave
Tags: security upstream

Hi

Details at
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixMSQL 



Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=Tq3zgUxLP9VPxRizyk970lApjdVTW2UvIdYPB8mMBTg=DzD9IdE2F3yP_VZ3HIvzbNqu8L292dV2gc4xenDaLZw= 

Bug#895997: [debian-mysql] Bug#895997: mysql-5.7: Security fixes from the April 2018 CPU

[Lars Tangvald]

Hi,

We'll prepare the update once 5.7.22 has been released (the release is 
almost always before the advisory, but not this time).


--
Lars

On 04/18/2018 03:00 PM, Salvatore Bonaccorso wrote:

Source: mysql-5.7
Version: 5.7.21-1
Severity: grave
Tags: security upstream

Hi

Detail at
http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html#AppendixMSQL

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@alioth-lists.debian.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=M-8dedO8w3Vlx9Nb3v_HN_eQTPKU36yJj5mmQmreYMQ=4u-hjYaJFpbBqM1HT4QPVruRRxueCe_YeZ9D9iHlSNk=giGdjER9sPFOFvwIHCFZylKd-Z5TPXfU2B9xVfTo-D4=

Bug#853008: [debian-mysql] Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

On 01/31/2018 02:19 PM, Olaf van der Spek wrote:

Hi,


Anyone else have any good ideas on how to handle this?

I do. The solution is quite simple: do not, ever, remove user data / databases.

It makes everything so much simpler, both on the user side and on the
dev side. No weird questions when installing, no databases gone by
accident..

The problem is that MariaDB and MySQL use the same data location, so 
you'd instead get weird errors when trying to move to a variant/version 
that can't handle the old data (MySQL does not support migration from 
MariaDB, and MariaDB supports specific versions of MySQL). It's 
reasonable for a user to expect that purging one package would let them 
install the other without issues.


There is work going on to deal with this, which should both let users go 
back and forth between incompatible versions and make sure a package can 
only delete its own data.


--
Lars

Bug#878402: [debian-mysql] Bug#878402: Bug#878402: Security fixes from the October 2017 CPU

[Lars Tangvald]

On 10/19/2017 10:09 AM, Emilio Pozuelo Monfort wrote:

On 18/10/17 20:46, Salvatore Bonaccorso wrote:

Hi lars,

On Wed, Oct 18, 2017 at 03:51:26PM +0200, Lars Tangvald wrote:

Hi,

5.5.58 packages for Debian 7 and 8 are built, and pass the test suite.
Attached are debdiff files for Wheezy and Jessie (source is also pushed to
https://urldefense.proofpoint.com/v2/url?u=https-3A__anonscm.debian.org_cgit_pkg-2Dmysql_mysql-2D5.5.git=DwICaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg=00T7TUZCwXkig-wYCf-35nC5VNSQmjNOsNq0TOBoXBs=MPjTux6yCV6-5Si_VECXoTwgZxgsyNIHfNSpH1nq2ws=
 )
As before, we unfortunately don't have a DD in our team that can sponsor the
upload, so we need assistance with that.

I will look into it for jessie-security then.


I'm not sure if the security team still handles Debian8, or if the lts team
does now?

Yes, Debian 8 Jessie is still yet handled by the security team.

And I will take of Debian 7 (wheezy). Thanks for preparing the update!

Cheers,
Emilio

Thanks for the help to both of you! :)

--
Lars

Bug#878398: [debian-mysql] Bug#878398: Security fixes from the October 2017 CPU

[Lars Tangvald]

CVE List for 5.7:

CVE-2017-3731
CVE-2017-10155
CVE-2017-10165
CVE-2017-10167
CVE-2017-10227
CVE-2017-10268
CVE-2017-10276
CVE-2017-10279
CVE-2017-10283
CVE-2017-10284
CVE-2017-10286
CVE-2017-10294
CVE-2017-10296
CVE-2017-10311
CVE-2017-10313
CVE-2017-10314
CVE-2017-10320
CVE-2017-10365
CVE-2017-10379
CVE-2017-10384

--
Lars

On 13. okt. 2017 12:34, Norvald H. Ryeng wrote:

Source: mysql-5.7
Version: 5.7.18-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2017 will be released on
Tuesday, October 17. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.7.20.

The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.alioth.debian.org_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwICAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg=7DikT9z1InjqtpgXAqPEvoncum9MvgyB0I0VEBgUepI=tXNrK89Tn-ffN2T5k0Ak03vcAwEkRO5OD3F-IEB8PjU=

Bug#878402: [debian-mysql] Bug#878402: Security fixes from the October 2017 CPU

[Lars Tangvald]

CVE List for 5.5:

CVE-2017-10268
CVE-2017-10378
CVE-2017-10379
CVE-2017-10384

--
Lars

On 13. okt. 2017 12:34, Norvald H. Ryeng wrote:

Source: mysql-5.5
Version: 5.5.57-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2017 will be released on
Tuesday, October 17. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.5.58.

The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.alioth.debian.org_cgi-2Dbin_mailman_listinfo_pkg-2Dmysql-2Dmaint=DwICAg=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=HPjEzLhETPj8fl9HCxxISaaV3f5tXDpGXDR3R2IELxg=dEyRpHvFwIr1RTEceqC6iy_yrzTaCF3pVSkZ3JFfOe4=0PVa9j2CKG1CAypoPA9B0-RLcMLbS5ifPg3jULC2EMw=

Bug#868798: [debian-mysql] Bug#868798: Security fixes from the July 2017 CPU

[Lars Tangvald]

CVE List for 5.7:

CVE-2017-3529
CVE-2017-3633
CVE-2017-3634
CVE-2017-3635
CVE-2017-3637
CVE-2017-3638
CVE-2017-3639
CVE-2017-3640
CVE-2017-3641
CVE-2017-3642
CVE-2017-3643
CVE-2017-3644
CVE-2017-3645
CVE-2017-3646
CVE-2017-3647
CVE-2017-3648
CVE-2017-3649
CVE-2017-3650
CVE-2017-3651
CVE-2017-3652
CVE-2017-3653
CVE-2017-3732

--
Lars

Bug#868788: Security fixes from the July 2017 CPU

[Lars Tangvald]

CVE list for 5.5:

CVE-2017-3635
CVE-2017-3636
CVE-2017-3641
CVE-2017-3648
CVE-2017-3651
CVE-2017-3652
CVE-2017-3653

--
Lars

Bug#868798: Security fixes from the July 2017 CPU

[Lars Tangvald]

Source: mysql-5.7
Version: 5.7.18-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for July 2017 will be released on
Tuesday, July 18. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.7.19.

We will update the bug with CVE numbers when they become available, and
test the update to ensure there are no packaging issues that need
addressing.

Regards,

Lars Tangvald

[1]
http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html

Bug#868788: Security fixes from the July 2017 CPU

[Lars Tangvald]

Source: mysql-5.5
Version: 5.5.55-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for July 2017 will be released on
Tuesday, July 18. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.5.57.

We will update the bug with CVE numbers when they become available, and 
test the update to ensure there are no packaging issues that need 
addressing.


Regards,

Lars Tangvald

[1] 
http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html

Bug#868445: [debian-mysql] Bug#868445: Bug#868445: mysql-server: Would like a way to suppress spurious ERROR 1547

[Lars Tangvald]

Hi,

I'll look into this (wouldn't normally take long since there aren't that many 
changes in 5.5, but most of us are on vacation) and get back to you.

That said, if this is not a regression/bug, then it _is_ likely to be a change 
made precisely for security reasons.
What exactly do you use the timestamp data for? There may be a better way of 
handling it than putting it as an extra column (e.g. getting data from 
information_schema, using triggers, etc).

--
Lars
- robie.ba...@ubuntu.com wrote:

> Hi David,
> 
> Thank you for your report.
> 
> On Sat, Jul 15, 2017 at 08:58:21AM -0400, David Lee Lambert wrote:
> > Some time ago, on my main Debian MySQL server, I added an extra
> > column to the "mysql.user" table of type "timestamp", for auditing
> > purposes.  It didn't cause any trouble at the time, but now when
> > I try to issue a GRANT statement I get the error
> > 
> > ERROR 1547 (HY000): Column count of mysql.user is wrong. Expected
> 42, found 43. The table is probably corrupted
> > 
> > Dropping the extra column gets me past the error, but I wish I
> could
> > keep that information. In fact, since the error showed up after
> "security"
> > updates on the Debian Stable branch, I consider it a REGRESSION.
> 
> I don't think it's reasonable to consider this a regression. A stable
> update (whether security or not) by definition must change some
> behaviour. In general, I think it's reasonable for such updates to
> assume that users haven't messed with internal data structures.
> Otherwise, how would a security update that must modify an internal
> data
> structure work?
> 
> In this particular case, it does appear unnecessary that there is an
> additional check here, but I won't conclude that without knowing
> exactly
> why it was done.
> 
> I'm happy to ask upstream on their view on this, and the reasoning
> for
> this change, and see if they think the error can be reduced to a
> warning
> in this case.
> 
> Robie
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#860326: [debian-mysql] Bug#860326: installation fails with server startup, some Auto-extending failing

[Lars Tangvald]

Are there files in /var/lib/mysql (or other location if a custom datadir 
is used) or /etc/mysql before installation? Even if it's a "fresh" 
install there may be files present in those locations, and then MySQL 
would try to continue using them.
Older packages also didn't remove any of these files when purging (newer 
packages should ask if you want to erase data and config files completely).
Try renaming /etc/mysql and /var/lib/mysql (or just erase if you are 
sure you don't need anything there) before installing.


--
Lars

On 04/14/2017 05:03 PM, Eduard Bloch wrote:

Package: mysql-server
Version: 5.7.17-1
Severity: important

Situation: attempting to install mysql-server and some dependent
packages

Result: installation fails, the dpkg configuration phase is aborted.
Reason is mysql-server postinst, failing to start a systemd unit.

Stronger investigation is inconclusive. dpkg.log says this is a fresh
installation... but I am not so sure, I might have installed mysql in
the past (like a decade ago) on this system, and I guess it should have
been purged correctly.

Apr 14 12:51:05 whitestar systemd[1]: Starting MySQL Community Server...
Apr 14 12:51:06 whitestar systemd[1]: mysql.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 14 12:51:36 whitestar systemd[1]: Failed to start MySQL Community Server.
Apr 14 12:51:36 whitestar systemd[1]: mysql.service: Unit entered failed state.
Apr 14 12:51:36 whitestar systemd[1]: mysql.service: Failed with result 
'exit-code'.


2017-04-14T14:52:23.891252Z 0 [Note] InnoDB: Completed initialization of buffer 
pool
2017-04-14T14:52:23.893681Z 0 [Note] InnoDB: If the mysqld execution user is 
authorized, page cleaner thread priority can be changed. See the man page of 
setpriority().
2017-04-14T14:52:23.903988Z 0 [ERROR] InnoDB: The Auto-extending innodb_system 
data file './ibdata1' is of a different size 640 pages (rounded down to MB) 
than specified in the .cnf file: initial 768 pages, max 0 (relevant if 
non-zero) pages!
2017-04-14T14:52:23.904034Z 0 [ERROR] InnoDB: Plugin initialization aborted 
with error Generic error
2017-04-14T14:52:24.505591Z 0 [ERROR] Plugin 'InnoDB' init function returned 
error.
2017-04-14T14:52:24.505663Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE 
ENGINE failed.
2017-04-14T14:52:24.505682Z 0 [ERROR] Failed to initialize plugins.
2017-04-14T14:52:24.505696Z 0 [ERROR] Aborting

2017-04-14T14:52:24.505712Z 0 [Note] Binlog end
2017-04-14T14:52:24.505831Z 0 [Note] Shutting down plugin 'CSV'
2017-04-14T14:52:24.506954Z 0 [Note] /usr/sbin/mysqld: Shutdown complete



-- System Information:
Debian Release: 9.0
   APT prefers unstable-debug
   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-rc6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mysql-server depends on:
ih  mysql-server-5.7  5.7.17-1

mysql-server recommends no packages.

mysql-server suggests no packages.

-- no debconf information

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

On 04/24/2017 10:27 AM, Salvatore Bonaccorso wrote:

Hi Lars,

On Mon, Apr 24, 2017 at 07:59:36AM +0200, Lars Tangvald wrote:


On 04/21/2017 08:04 AM, Salvatore Bonaccorso wrote:

Hi Lars,

On Fri, Apr 21, 2017 at 06:07:40AM +0200, Lars Tangvald wrote:

Hi,

I lost internet connectivity where I am right now, so probably unable to get
this done until Monday. Could maybe use the previous debdiff for Jessie if
you're ok with closing the bug manually.
Also, I think we still don't have any active members in the maintainer team
with upload access for 5.5

Okay, I will look if I can take care of the upload for
jessie-security.

Regards,
Salvatore

Thanks! I was just about to push the update to git, but I see you already
did. Do you need anything more from us on this? Working with the LTS team
for wheezy-security.

No, it's fine at the moment. I'm still waiting for two builds. armhf
furthermore failed. Checking if that was temprary.

Was it a test failure?
There are some unstable tests I think we should identify (in unstable 
we've started disabling them and reporting upstream bug for each).


--
Lars

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

On 04/21/2017 08:04 AM, Salvatore Bonaccorso wrote:

Hi Lars,

On Fri, Apr 21, 2017 at 06:07:40AM +0200, Lars Tangvald wrote:

Hi,

I lost internet connectivity where I am right now, so probably unable to get
this done until Monday. Could maybe use the previous debdiff for Jessie if
you're ok with closing the bug manually.
Also, I think we still don't have any active members in the maintainer team
with upload access for 5.5

Okay, I will look if I can take care of the upload for
jessie-security.

Regards,
Salvatore


Thanks! I was just about to push the update to git, but I see you 
already did. Do you need anything more from us on this? Working with the 
LTS team for wheezy-security.


--
Lars

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Hi,

I lost internet connectivity where I am right now, so probably unable to 
get this done until Monday. Could maybe use the previous debdiff for 
Jessie if you're ok with closing the bug manually.
Also, I think we still don't have any active members in the maintainer 
team with upload access for 5.5


--
Lars

On 19. april 2017 15:30, Salvatore Bonaccorso wrote:

Hi Lars,

On Wed, Apr 19, 2017 at 04:26:30AM -0700, Lars Tangvald wrote:

Hi,


We've prepared and tested the update to MySQL 5.5.55 for Jessie.
Debdiff output is attached.
Only packaging changes are one refreshed patch and one that is no
longer needed (5.5.54 for Wheezy had an additional patch added,
which is also no longer needed).

Thanks for preparing the update.

CVE-2017-3302 is as well know nin BTS as #854713, can you add a bug closer for
this one as well? If it's too much of hassle, then leave it, and we close it
manually.

Ok, please upload to security-master.

Regards,
Salvatore

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Hi,
- car...@debian.org wrote:

> Hi Lars,
> 
> On Wed, Apr 19, 2017 at 04:26:30AM -0700, Lars Tangvald wrote:
> > Hi,
> > 
> > 
> > We've prepared and tested the update to MySQL 5.5.55 for Jessie.
> > Debdiff output is attached.
> > Only packaging changes are one refreshed patch and one that is no
> > longer needed (5.5.54 for Wheezy had an additional patch added,
> > which is also no longer needed).
> 
> Thanks for preparing the update.
> 
> CVE-2017-3302 is as well know nin BTS as #854713, can you add a bug
> closer for
> this one as well? If it's too much of hassle, then leave it, and we
> close it
> manually.
> 
> Ok, please upload to security-master.
> 
> Regards,
> Salvatore

Ah right, that's the bug for the patch in the Wheezy 5.5.54 packages. I'll add 
it.

--
Lars

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Whoops, that went to the wrong address...

Message just says that a patch added by the lts team to 5.5.54 doesn't apply on 
5.5.55 :)

--
Lars
- lars.tangv...@oracle.com wrote:

> Hei,
> 
> Denne patchen:
> https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git/tree/debian/patches/fix_use_after_free_in_mysql_prune_stmt_list.patch?h=debian/wheezy
> Ble lagt til (kun debian 7) for 5.5.54, og får konflikt i 5.5.55. Har
> du tid til å ta en titt og evt. lage oppdatert patch?
> 
> --
> Lars
> - norvald.ry...@oracle.com wrote:
> 
> > Source: mysql-5.5
> > Version: 5.5.54-0+deb8u1
> > Severity: grave
> > Tags: security upstream fixed-upstream
> > 
> > The Oracle Critical Patch Update for April 2017 will be released on 
> 
> > Tuesday, April 18. According to the pre-release announcement [1], it
> 
> > 
> > will contain information about CVEs fixed in MySQL 5.5.55.
> > 
> > The CVE numbers will be available when the CPU is released.
> > 
> > Please note that the MySQL release cycle has changed from every two
> > months to every three months. The releases are now synchronized
> with
> > the CPU announcements.
> > 
> > Best regards,
> > 
> > Norvald H. Ryeng
> > 
> > [1]
> >
> http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html
> > 
> > ___
> > pkg-mysql-maint mailing list
> > pkg-mysql-ma...@lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

Hei,

Denne patchen: 
https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git/tree/debian/patches/fix_use_after_free_in_mysql_prune_stmt_list.patch?h=debian/wheezy
Ble lagt til (kun debian 7) for 5.5.54, og får konflikt i 5.5.55. Har du tid 
til å ta en titt og evt. lage oppdatert patch?

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.5
> Version: 5.5.54-0+deb8u1
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for April 2017 will be released on  
> Tuesday, April 18. According to the pre-release announcement [1], it 
> 
> will contain information about CVEs fixed in MySQL 5.5.55.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Please note that the MySQL release cycle has changed from every two
> months to every three months. The releases are now synchronized with
> the CPU announcements.
> 
> Best regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#860544: [debian-mysql] Bug#860544: Security fixes from the April 2017 CPU

[Lars Tangvald]

CVE list for 5.5:

CVE-2017-3302
CVE-2017-3305
CVE-2017-3308
CVE-2017-3309
CVE-2017-3329
CVE-2017-3453
CVE-2017-3456
CVE-2017-3461
CVE-2017-3462
CVE-2017-3463
CVE-2017-3464
CVE-2017-3600

--
Lars

Bug#860547: [debian-mysql] Bug#860547: Security fixes from the April 2017 CPU

[Lars Tangvald]

CVE List for 5.7:

CVE-2017-3308
CVE-2017-3309
CVE-2017-3329
CVE-2017-3331
CVE-2017-3450
CVE-2017-3453
CVE-2017-3454
CVE-2017-3455
CVE-2017-3456
CVE-2017-3457
CVE-2017-3458
CVE-2017-3459
CVE-2017-3460
CVE-2017-3461
CVE-2017-3462
CVE-2017-3463
CVE-2017-3464
CVE-2017-3465
CVE-2017-3467
CVE-2017-3468
CVE-2017-3599
CVE-2017-3600

--
Lars

Bug#857444: [debian-mysql] Bug#857444: Bug#857444: Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled

[Lars Tangvald]

On 03/15/2017 09:01 AM, Otto Kekäläinen wrote:

Hello!


One way to make this an easier transition would be to have a
mysql-server package in stretch that's a dummy package that depends
on
default-mysql-server, and that has an upgrade notice about the
transition to mariadb that is happening.

The transition is supposed to be automatic already. Apparently it
didn't quite work in your setup. Can you please describe your setup in
details so that I can try to reproduce your upgrade and see how the
packages interact? What packages did you have installed in Jessie?
What repositories did you have enabled in Jessie? How did you upgrade,
what repositories where enabled during the upgrade when you ran
apt-get upgrade or apt-get dist-upgrade? How do you know if mysql was
or was not running after the upgrade, did you check with ps if you
have any mysqld processes at all? Was there some errors in syslog or
/var/log/mysql ?
When I did a quick test, I just replaced jessie with stretch in 
/etc/apt/sources.list, ran apt-get update and apt-get dist-upgrade


--
Lars

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#857444: [debian-mysql] Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled

[Lars Tangvald]

On 03/15/2017 07:25 AM, Gabriel Filion wrote:

Lars Tangvald:

- gabs...@lelutin.ca wrote:


Ugh, I fail at reportbug again :(

real sorry about the initial report.

here's the real description of the problem:


when upgrading from jessie to stretch, the upgrade goes through
without
an error but the end result is that mysql-server-5.5 gets removed and
mysql is not running anymore.

stretch is supposed to push ppl towards mariadb according to the
(still
work in progress) release notes, however mariadb doesn't get
installed.

There is no mysql-server, mysql-server-* or mysql-client-* packages
in
stretch so I believe this to be the source of the issue.

One can fix the problem either by adding default-mysql-server before
upgrading or after. however this poses a problem:

  * before the upgrade, the default-mysql-server package is only
available in jessie-backports
  * after the upgrade, you've gotten no notice at all about what's
happening and why the mysql server is not running and not upgraded.

One way to make this an easier transition would be to have a
mysql-server package in stretch that's a dummy package that depends
on
default-mysql-server, and that has an upgrade notice about the
transition to mariadb that is happening.



The mysql package names should be reserved for actual mysql packages (default-mysql, 
virtual-mysql etc. are named so because there isn't a better term for 
"mysql-ish"). While the current situation with mysql being half-uninstalled is 
pretty odd, we shouldn't automatically replace mysql-server with mariadb-server, as it 
can cause problems for users who want to keep using mysql, while those who are fine with 
either just need to install mariadb after the upgrade.

This sounds reasonable, but there are currently lots of mysql-* packages
missing from stretch.

I can currently only see mysql-common, mysql-sandbox, mysql-utilities,
mysql-workbench{,-data}, mysqltcl, mysqltuner.

there are neither packages for client nor server.

Yes, the release and security teams decided to drop MySQL from Stretch, 
(anything that won't work with MariaDB is also being removed).
But MySQL is still present in unstable and in upstream's repository 
(which will have Stretch packages). Having mysql-server point to MariaDB 
(which is what default-mysql is in Stretch) will cause issues with 
those, not to mention being wildly inaccurate.


I'm a bit confused on why the mysql server packages are automatically 
removed, though. I figured that when updating to new package archives 
that are missing a package, that package will be flagged as obsolete, 
and _suggested_ to the user for removal, so why does it happen 
automatically? It seems to be caused by the removal of libperl5.20, but 
I'm having trouble tracing the dependency on it (removing it manually 
gives a slightly different result, and the dependency isn't direct). It 
only removed mysql-server-5.5, not mysql-server-core-5.5 (so you still 
have the server, just not the service), so there might be a way to "fix" 
it, so users are told the package is obsolete without automatic removal.


--
Lars


--
Lars

Bug#857444: [debian-mysql] Bug#857444: mysql-server-5.5: upgrade from jessie to stretch leaves mysql server uninstalled

[Lars Tangvald]

- gabs...@lelutin.ca wrote:

> Ugh, I fail at reportbug again :(
> 
> real sorry about the initial report.
> 
> here's the real description of the problem:
> 
> 
> when upgrading from jessie to stretch, the upgrade goes through
> without
> an error but the end result is that mysql-server-5.5 gets removed and
> mysql is not running anymore.
> 
> stretch is supposed to push ppl towards mariadb according to the
> (still
> work in progress) release notes, however mariadb doesn't get
> installed.
> 
> There is no mysql-server, mysql-server-* or mysql-client-* packages
> in
> stretch so I believe this to be the source of the issue.
> 
> One can fix the problem either by adding default-mysql-server before
> upgrading or after. however this poses a problem:
> 
>  * before the upgrade, the default-mysql-server package is only
> available in jessie-backports
>  * after the upgrade, you've gotten no notice at all about what's
> happening and why the mysql server is not running and not upgraded.
> 
> One way to make this an easier transition would be to have a
> mysql-server package in stretch that's a dummy package that depends
> on
> default-mysql-server, and that has an upgrade notice about the
> transition to mariadb that is happening.
> 
> 
The mysql package names should be reserved for actual mysql packages 
(default-mysql, virtual-mysql etc. are named so because there isn't a better 
term for "mysql-ish"). While the current situation with mysql being 
half-uninstalled is pretty odd, we shouldn't automatically replace mysql-server 
with mariadb-server, as it can cause problems for users who want to keep using 
mysql, while those who are fine with either just need to install mariadb after 
the upgrade.

--
Lars

Bug#853008: [debian-mysql] Bug#853008: Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

On 02/21/2017 01:59 PM, Julian Gilbey wrote:

On Tue, Feb 21, 2017 at 01:27:44PM +0100, Lars Tangvald wrote:

I've looked at it some more, and I'm hesitant about including such a big
patch for a pretty rare scenario, which in the worst case does ask the
following:
  The /var/lib/mysql directory which contains the MySQL databases is about
  to be removed.
  .
  This will also erase all data in /var/lib/mysql-files as well as
  /var/lib/mysql-keyring.
  .
  If you're removing the MySQL package in order to later install a more
  recent version or if a different mysql-server package is already
  using it, the data should be kept.

My suggestion is that for now, we revert the patch that enabled the
purge-remove (meaning postrm will never delete anything or ask to do so) and
instead work on separating the data for the different packages so that
MariaDB and MySQL data isn't in the same location.

Hi Lars,

Does that mean that the whole remove section just gets removed from
the postrm, or that you put back the test for /usr/sbin/mysqld existing?

Best wishes,

Julian

Only reverting the commit would put it back, which I guess would be best 
since I think it can trigger if you first do apt-get remove and then 
apt-get purge (without installing a different variant between).


--
Lars

Bug#843959: [debian-mysql] Bug#843959: So I have to enable it, but don't need to run it, before each upgrade

[Lars Tangvald]

- jida...@jidanni.org wrote:

> So I have to enable it, but don't need to run it, before each
> upgrade.
> Not very logical.
> 
Yeah, I'm working on fixing the maintainer script to not rely on the service 
being enabled to work (and maybe give a nicer error than "exit code 1" if 
there's a running daemon it can't stop.

--
Lars
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#853008: [debian-mysql] Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

- j...@debian.org wrote:

> On Mon, Jan 30, 2017 at 06:38:16PM +, Robie Basak wrote:
> > > So how about this, just a sketch at the moment rather than a full
> > > patch?
> > 
> > Your sketch seems good to me, assuming that "dpkg-query --search"
> is
> > permitted from maintainer scripts (I know there are some
> re-entrancy
> > problems with some particular types of dpkg-related invocations?)
> > [...]
> > 
> > I wondered this too. But without thinking it through in more
> detail,
> > it'd certainly be better than what we have now.
> 
> Please find attached a patch against the current
> mysql-5.7/debian/master branch on alioth.  I have also updated the
> github branch for mariadb-10.1 to address the same issue (the one
> with
> a pull request to otto/mariadb-10.1).
> 
> It's been tested for upgrades, clean install, remove and purge.
> 
> Best wishes,
> 
>Julian


Thanks!

I'll look it over and test a little myself.

--
Lars

Bug#853008: [debian-mysql] Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

On 01/30/2017 10:28 AM, Robie Basak wrote:

Hi Julian,

Thank you for reporting this.

On Mon, Jan 30, 2017 at 09:24:46AM +0100, Lars Tangvald wrote:

Anyone else have any good ideas on how to handle this?

I think the root cause here is that both MySQL and MariaDB packaging
"own" /var/lib/mysql. This causes confusion because even though the
packages Conflict, one can still be purged while the other is installed.

I think that sharing /var/lib/mysql in this way leads to a slew of bugs,
and we should fix it in the long term so that the packaging doesn't do
this.

This is https://launchpad.net/bugs/1490071 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841345

Unfortunately fixing this properly is quite involved. I've had time to
think up a solution, but not had time to code it up yet, and I don't
expect to have the necessary time in the next few months.

Am I right in thinking that this could be triggered by installing MySQL
in jessie, upgrading to stretch, installing MariaDB if it isn't already,
and then purging MySQL? If so I agree with "serious" and so we should
find some stop-gap solution in the short term until the full fix above
can be implemented.

Could we work on unifying MySQL and MariaDB's handling of this? Use the
same debconf key and present the question for /var/lib/mysql in general,
making it clear that it applies to both MySQL and MariaDB. Then on
purge, if the answer was "yes, purge", then ask again to confirm that
the user does actually want it deleted both for MySQL and MariaDB (not
sure we can ask debconf questions in postrm though?). A goal should be
that all the code handling creation and deletion of /var/lib/mysql
should be common between MySQL and MariaDB. Either leave comments in the
maintainer scripts, or put the code in mysql-common from
src:mysql-defaults and Pre-Depend on it.

Would this be acceptable, both from technical implementation and UX
perspectives? Does Debian and/or stretch have string translation
deadlines or freezes?

Additionally we could have some hacks to try to determine if the
counterpart variant is installed and not do anything if it is. I think
hacks are fine in the short term because we have an open bug for a
proper solution, and the seriousness of this issue (if as above)
warrants it.

Opinions appreciated.

Robie
The trigger would basically just be to install and remove 
mysql-server-5.7 (which also happens when replacing it with a 
conflicting package), then install any other variant, then purge 
mysql-server-5.7.
I think an ok short-term solution is to make a .postrm script for 
mysql-server-core, and move the delete logic there with the check on 
/usr/sbin/mysqld restored, for both MariaDB and MySQL. Then we don't 
need to check on any specific packages, since we'd know any existing 
mysqld binary doesn't belong to the package being purged. If the user 
has installed a MariaDB, the deletion would be handled by 
mariadb-server-core being purged.


Looking at the debconf manual, only postinst is mentioned as a place not 
to use it (and it actually uses postrm and asking about deleting 
something as a usage example).


--
Lars

Bug#853008: [debian-mysql] Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Lars Tangvald]

On 01/29/2017 01:13 PM, Julian Gilbey wrote:

On Sat, Jan 28, 2017 at 09:21:13PM +, Julian Gilbey wrote:

Package: mysql-server-5.7
Version: 5.7.16-2
Severity: serious

Hello!

I'm really confused by the change in the postrm introduced in response
to LP: #1602945, and I simply do not understand the rationale of the
original bug report, and the comment there (and in the git commit log)
that "Remove the check on the server binary, since it shouldn't be
possible for another package to own that file anyway" is clearly
incorrect: during a postrm remove|purge run, if that file exists -
which it may well do, it will certainly belong to a different package,
such as mysql-server-5.8 or mariadb-server-10.1.

And looking at the existing postrms, I see that this is effectively
just Debian bug #307473 reopened.  That was regarded as critical!

The problem with the old code was that at the point it was run, 
usr/sbin/mysqld  _always_ existed, so it was just a big chunk of dead 
code. The code was just copied from the old packages that had a 
different structure. I think the code would need to be in the maintainer 
script for the package that has the server binary, so that it would run 
correctly after the package's own binary is removed, but that's 
-server-core, which doesn't run any postrm (we could add it, but part of 
the point of the core packages is that they don't run anything).


Anyone else have any good ideas on how to handle this?

--
Lars

Best wishes,

Julian

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#853139: RM: mysql-5.6 -- ROM; Superseded by mysql-5.7

[Lars Tangvald]

Package: ftp.debian.org
Severity: normal

The package is replaced by mysql-5.7 (dependencies moved to mysql-defaults)

Bug#851233: [debian-mysql] Bug#851233: Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

- car...@debian.org wrote:

> Hi Lars,
> 
> On Wed, Jan 18, 2017 at 06:41:40AM -0800, Lars Tangvald wrote:
> > 
> > - car...@debian.org wrote:
> > 
> > 
> > > > >With that fixed, and build with -sa (to include the orig
> tarball)
> > > > >please do upload to security-master.
> > > > Do we have access to upload here? I think the security team
> have
> > > handled the
> > > > upload in the past.
> > > 
> > > yes it nees to be a key in the DD keyring. Do you have a DD in
> the
> > > mysql-pkg team who could sponsor the upload?
> > > 
> > 
> > Not really, unfortunately (Otto is a DD, but he's only involved
> with
> > the MariaDB packaging).
> > It's an issue for us, since it also causes problems with uploads to
> > unstable.
> 
> Ok. I though in the past James Page was sponsoring the uploads.
> Alright, in that case, let me know when you have finished the
> packaging with the small changes mentioned, I can take care of
> sponsoring the upload.
> 
I might be going a bit senile, since I forgot he's got access as well, but for 
the last months he's been occupied, so I don't think he's available now.
I'll let you know when the new build is ready, thanks.

--
Lars
> Regards,
> Salvatore

Bug#851233: [debian-mysql] Bug#851233: Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

- car...@debian.org wrote:


> > >With that fixed, and build with -sa (to include the orig tarball)
> > >please do upload to security-master.
> > Do we have access to upload here? I think the security team have
> handled the
> > upload in the past.
> 
> yes it nees to be a key in the DD keyring. Do you have a DD in the
> mysql-pkg team who could sponsor the upload?
> 

Not really, unfortunately (Otto is a DD, but he's only involved with the 
MariaDB packaging).
It's an issue for us, since it also causes problems with uploads to unstable.

--
Lars

Bug#851233: [debian-mysql] Bug#851233: Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

Hi,

On 01/18/2017 12:39 PM, Salvatore Bonaccorso wrote:

Hi Lars,

On Wed, Jan 18, 2017 at 10:33:30AM +0100, Lars Tangvald wrote:

Hi,

The update builds and passes testing.
I've attached debdiff output for Wheezy and Jessie for this update. Aside
from the changelog, the only change to packaging is a patch for a test
(main.events_2) that was failing because of a hardcoded date.

Thanks for preparing the update.


diff -r mysql-5.5-5.5.53/debian/changelog 
../mysql-5.5/mysql-5.5/debian/changelog
0a1,14

mysql-5.5 (5.5.54-0+deb8u1) jessie-security; urgency=high

   * Imported upstream version 5.5.54 to fix security issues:
 - 
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
 - CVE-2017-3238 CVE-2017-3243 CVE-2017-3244 CVE-2017-3258
 - CVE-2017-3265 CVE-2017-3291 CVE-2017-3312 CVE-2017-3313
 - CVE-2017-3317 CVE-2017-3318
 (Closes: #851233)
   * Fix failing test main.events_2
 The test was failing due to hardcoded date (2017-01-01). Added patch
 pending upstream fix.

  -- Lars Tangvald <lars.tangv...@oracle.com>  Tue, 17 Jan 2017 13:04:58 +0100

This looks good, but see one change which seem included below:


5c19
< - CVE-2016-7440 CVE-2016-5584
---

 - CVE-2016-6662 CVE-2016-7440 CVE-2016-5584

Did you build not on top of the last update? Because we corrected the
CVE ids in the 5.5.53-0+deb8u1 upload. CVE-2016-6662 does not belong
there, and was already fixed in the DSA-3666-1 with mysql-5.5
5.5.52-0+deb8u1, cf. the resulting changelog for 5.5.53-0+deb8u1 in
https://bugs.debian.org/841050#62 for the DSA-3666-1 upload . I don't
remember exactly, but I though I had asked someone of the mysql
packaging team to import the final changes to the packaging
repository.
Aha, yes. I see the vcs hasn't got the 5.5.53 packages imported 
properly. I'll do the import and rebuild, thanks.

With that fixed, and build with -sa (to include the orig tarball)
please do upload to security-master.
Do we have access to upload here? I think the security team have handled 
the upload in the past.


--
Lars

Thanks for your work!

Regards,
Salvatore

Bug#851233: [debian-mysql] Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

CVE List for 5.5:

CVE-2017-3238
CVE-2017-3243
CVE-2017-3244
CVE-2017-3258
CVE-2017-3265
CVE-2017-3291
CVE-2017-3312
CVE-2017-3313
CVE-2017-3317
CVE-2017-3318

--
Lars
On 01/13/2017 09:19 AM, Norvald H. Ryeng wrote:

Source: mysql-5.5
Version: 5.5.53-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for January 2017 will be released on
Tuesday, January 17. According to the pre-release announcement [1], it
will contain information about CVEs fixed in MySQL 5.5.54.

The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851234: [debian-mysql] Bug#851234: Bug#851234: Security fixes from the January 2017 CPU

[Lars Tangvald]

CVE List for 5.6:

CVE-2016-8318
CVE-2016-8327
CVE-2017-3238
CVE-2017-3244
CVE-2017-3257
CVE-2017-3258
CVE-2017-3265
CVE-2017-3273
CVE-2017-3291
CVE-2017-3312
CVE-2017-3313
CVE-2017-3317
CVE-2017-3318

--
Lars
On 01/17/2017 09:48 PM, Lars Tangvald wrote:

I've built and tested the update, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:


Source: mysql-5.6
Version: 5.6.34-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for January 2017 will be released on

Tuesday, January 17. According to the pre-release announcement [1], it
  
will contain information about CVEs fixed in MySQL 5.6.35.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1]
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851235: [debian-mysql] Bug#851235: Bug#851235: Security fixes from the January 2017 CPU

[Lars Tangvald]

CVE List for 5.7:

CVE-2016-8318
CVE-2016-8327
CVE-2017-3238
CVE-2017-3244
CVE-2017-3251
CVE-2017-3256
CVE-2017-3257
CVE-2017-3258
CVE-2017-3265
CVE-2017-3273
CVE-2017-3291
CVE-2017-3312
CVE-2017-3313
CVE-2017-3317
CVE-2017-3318
CVE-2017-3319
CVE-2017-3320

--
Lars
On 01/17/2017 09:48 PM, Lars Tangvald wrote:

I've built and tested the updates, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:


Source: mysql-5.7
Version: 5.7.16-2
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for January 2017 will be released on

Tuesday, January 17. According to the pre-release announcement [1], it
  
will contain information about CVEs fixed in MySQL 5.7.17.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1]
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851233: [debian-mysql] Bug#851233: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the updates, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.5
> Version: 5.5.53-0+deb8u1
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.5.54.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851234: [debian-mysql] Bug#851234: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the update, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.6
> Version: 5.6.34-1
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.6.35.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851235: [debian-mysql] Bug#851235: Security fixes from the January 2017 CPU

[Lars Tangvald]

I've built and tested the updates, and will pass debdiffs on to the security 
team once the CVE list is available.

--
Lars
- norvald.ry...@oracle.com wrote:

> Source: mysql-5.7
> Version: 5.7.16-2
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> The Oracle Critical Patch Update for January 2017 will be released on 
> 
> Tuesday, January 17. According to the pre-release announcement [1], it
>  
> will contain information about CVEs fixed in MySQL 5.7.17.
> 
> The CVE numbers will be available when the CPU is released.
> 
> Regards,
> 
> Norvald H. Ryeng
> 
> [1]
> http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851156: [debian-mysql] Bug#851156: mysql-5.6: FTBFS in sid: Cannot find system editline libraries.

[Lars Tangvald]

5.7 has a fix for this in place (editline uses a different datatype in newer 
versions). At first glance it looks like it should be simple to apply the same 
fix for 5.6.

--
Lars
- a...@debian.org wrote:

> Source: mysql-5.6
> Version: 5.6.34-1
> Severity: serious
> Justification: fails to build from source (but built successfully in
> the past)
> 
> Hi,
> 
> building in an up-to-date minimal sid chroot fails with
> 
> [...]
> -- Check size of wctype_t
> -- Check size of wctype_t - done
> -- Check size of wint_t
> -- Check size of wint_t - done
> -- EDITLINE_INCLUDE_DIR /usr/include/editline
> -- EDITLINE_LIBRARY /usr/lib/x86_64-linux-gnu/libedit.so
> -- Performing Test EDITLINE_HAVE_HIST_ENTRY
> -- Performing Test EDITLINE_HAVE_HIST_ENTRY - Success
> -- Performing Test EDITLINE_HAVE_COMPLETION
> -- Performing Test EDITLINE_HAVE_COMPLETION - Failed
> CMake Error at cmake/readline.cmake:206 (MESSAGE):
>   Cannot find system editline libraries.
> Call Stack (most recent call first):
>   CMakeLists.txt:421 (MYSQL_CHECK_EDITLINE)
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> 
> Andreas
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#851156: [debian-mysql] Bug#851156: mysql-5.6: FTBFS in sid: Cannot find system editline libraries.

[Lars Tangvald]

Verified on my own build vm.
Looking at https://buildd.debian.org/status/package.php?p=mysql-5.6=sid 
the m68k build failed like this before as well, and it was last attempted more 
recently than the rest. So I'm guessing something we need is no longer 
available in the minimal sid chroot by default.

--
Lars

Bug#825084: Package links against libmysqlclient_r

[Lars Tangvald]

Hi,

There isn't really a way to verify the thread safety aside from what's 
in the test suite, but how old systems do you consider when you say «old 
boxes»? Ones with eol'ed versions of MySQL (< 5.5)?
In 5.5 and 5.6 there's no difference between libmysqlclient and 
libmysqlclient_r, as the latter was only included for backwards 
compatibility.

I can do some digging to find out exactly when _r was made a symlink.

--
Lars

Bug#844275: [debian-mysql] Bug#844275: mysql_config injects build flags which breaks the build for other packages

[Lars Tangvald]

Hi,

We've had a fix for this prepared for some time now, but haven't been 
able to find anyone to sponsor an upload to unstable. Do you know anyone 
who might be able to help?
It's ready to go from the mysql-5.7/debian/master branch at 
https://anonscm.debian.org/cgit/pkg-mysql/mysql.git


--
Lars

On 11/14/2016 12:39 AM, Michael Biebl wrote:

Package: libmysqlclient-dev
Version: 5.7.16-1
Severity: serious
File: /usr/bin/mysql_config

Hi,

I just tried to build the rsyslog package, which resulted in a build
failure:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../runtime
-I../.. -I../../grammar -I/usr/include/libfastjson -W -Wall
-Wformat-security -Wshadow -Wcast-align -Wpointer-arith
-Wmissing-format-attribute -Werror=implicit-function-declaration -g
-I/usr/include/mysql
-fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs
-fabi-version=2 -fno-omit-frame-pointer -pthread -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/rsyslog-8.22.0=.
-fstack-protector-strong -Wformat -Werror=format-security -W -Wall
-Wformat-security -Wshadow -Wcast-align -Wpointer-arith
-Wmissing-format-attribute -g -c ommysql.c  -fPIC -DPIC -o
.libs/ommysql_la-ommysql.o
gcc: error: .specs: No such file or directory


Looking a bit closer, this is a bug in mysql_config, which injects bogus
build flags.

# mysql_config --cflags
# mysql_config --cflags
-I/usr/include/mysql 
-fdebug-prefix-map=/build/mysql-5.7-Q0jPG6/mysql-5.7-5.7.16=. .specs 
-fabi-version=2 -fno-omit-frame-pointer -fno-expensive-optimizations

Marking as RC, as this breaks the build for other packages.



-- System Information:
Debian Release: stretch/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmysqlclient-dev depends on:
ii  libmysqlclient20  5.7.16-1
ii  zlib1g-dev1:1.2.8.dfsg-2+b3

libmysqlclient-dev recommends no packages.

libmysqlclient-dev suggests no packages.

-- no debconf information

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#847231: [debian-mysql] Bug#847231: mysql-server-core-5.7: fails to upgrade from 'jessie' - trying to overwrite /usr/share/man/man1/innochecksum.1.gz

[Lars Tangvald]

Hi,

On 12/06/2016 05:55 PM, Andreas Beckmann wrote:

Package: mysql-server-core-5.7
Version: 5.7.16-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

   Selecting previously unselected package mysql-server-core-5.7.
   (Reading database ...
(Reading database ... 17080 files and directories currently installed.)
   Preparing to unpack .../mysql-server-core-5.7_5.7.16-1_amd64.deb ...
   Unpacking mysql-server-core-5.7 (5.7.16-1) ...
   dpkg: error processing archive 
/var/cache/apt/archives/mysql-server-core-5.7_5.7.16-1_amd64.deb (--unpack):
trying to overwrite '/usr/share/man/man1/innochecksum.1.gz', which is also 
in package mysql-server-5.5 5.5.50-0+deb8u1
   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Thanks. As you say, it looks like we're missing a breaks/replaces on the 
server-core package.


--
Lars


cheers,

Andreas


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#844275: [debian-mysql] Bug#844275: Bug#844275: mysql_config injects build flags which breaks the build for other packages

[Lars Tangvald]

On 11/23/2016 11:10 AM, Norvald H. Ryeng wrote:

mysql_config and mysqlclient.pc pick up compile flags from the build
environment. We have a fix for this upstream, and I've backported it to
5.7.16 (see attachment).

I haven't tested it with sbuild/dpkg, so when applying this, please
verify that mysql_config and mysqlclient.pc don't pick up any flags
they shouldn't.

Regards,

Norvald

I've verified that libmysqlclient-dev built with this patch fixes the 
rsyslog build, so hopefully we can get a build uploaded that fixes this 
fairly soon.


--
Lars




___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#843520: [debian-mysql] Bug#843520: Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Lars Tangvald]

On 11/18/2016 08:00 AM, Lars Tangvald wrote:

Hi,

On 11/17/2016 06:02 PM, Jean Louis wrote:

I am sorry, that I filed bug in the wrong package, it was
unintentional mistake. It should be in mysql-server. And I know all
about specifics.

In my case, there is nothing that I have changed in my Mysql
configuration from the plain install. That is why I filed the
bug. Otherwise I would look first on my side.

And I was surprised it did not work, as I was used to the stability
and certainty when upgrading.

I could not find the solution

I was reading other bugs and I found:

[mysqld]
secure_file_priv = /var/lib/mysql

So I have put it in /etc/mysql/conf.d and now I got it working. Even I
don't even know what is it about, as being so lazy to read the
documentation. Sorry.

Still I think it should not be like that, the upgrade should go
smooth, especially for databases. Nothing angers me, thank you for
putting attention. I am supporter of free software and use Debian on
remote servers.

Jean Louis

Hi,

In this case, the server defaults to 
secure_file_priv=/var/lib/mysql-files, and will require this directory 
to be created.
This is a big change to make in a stable release, but the old behavior 
was a potential security risk, so we felt it was justified. The 
upgrade _should_ have created this directory automatically, so if it 
failed for you then there's probably something with your environment 
we didn't account for. If you have any console logs or mysql error 
logs from the update it would be good if you can attach them to the bug.


One important note, however:
The solution you note, setting secure_file_priv=/var/lib/mysql (the 
data directory) is not a good one. You should either set it to NULL or 
to a separate, empty directory owned by the mysql user.


The secure_file_priv setting determines where the server is allowed to 
read and write files using import/export operations. Setting it to the 
same location as the database will mean that any user of your database 
can get full access.



Correction here: You need the FILE privilege to use these operations.

--
Lars

Bug#843520: [debian-mysql] Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Lars Tangvald]

Hi,

On 11/17/2016 06:02 PM, Jean Louis wrote:

I am sorry, that I filed bug in the wrong package, it was
unintentional mistake. It should be in mysql-server. And I know all
about specifics.

In my case, there is nothing that I have changed in my Mysql
configuration from the plain install. That is why I filed the
bug. Otherwise I would look first on my side.

And I was surprised it did not work, as I was used to the stability
and certainty when upgrading.

I could not find the solution

I was reading other bugs and I found:

[mysqld]
secure_file_priv = /var/lib/mysql

So I have put it in /etc/mysql/conf.d and now I got it working. Even I
don't even know what is it about, as being so lazy to read the
documentation. Sorry.

Still I think it should not be like that, the upgrade should go
smooth, especially for databases. Nothing angers me, thank you for
putting attention. I am supporter of free software and use Debian on
remote servers.

Jean Louis

Hi,

In this case, the server defaults to 
secure_file_priv=/var/lib/mysql-files, and will require this directory 
to be created.
This is a big change to make in a stable release, but the old behavior 
was a potential security risk, so we felt it was justified. The upgrade 
_should_ have created this directory automatically, so if it failed for 
you then there's probably something with your environment we didn't 
account for. If you have any console logs or mysql error logs from the 
update it would be good if you can attach them to the bug.


One important note, however:
The solution you note, setting secure_file_priv=/var/lib/mysql (the data 
directory) is not a good one. You should either set it to NULL or to a 
separate, empty directory owned by the mysql user.


The secure_file_priv setting determines where the server is allowed to 
read and write files using import/export operations. Setting it to the 
same location as the database will mean that any user of your database 
can get full access.


--
Lars




On Tue, Nov 15, 2016 at 12:10:10PM +, Robie Basak wrote:

Hi Jean,

On Tue, Nov 15, 2016 at 12:08:18PM +0100, Jean Louis wrote:

sudo apt-get update
sudo apt-get upgrad

* What exactly did you do (or not do) that was effective (or
  ineffective)?

Starting or configuring mysql-server-5.5 hangs forever. System is broken.

* What was the outcome of this action?

It hangs forever.

Unfortunately I think this isn't enough for anyone to understand what
happened in your case. This is a problem statement, not a bug report.

Clearly a simple upgrade on a fresh install of jessie works; otherwise
we would have thousands of bug reports. Something must be different on
your system, but we do not know what that is. Please provide full steps
to reproduce your problem so that we may figure that out.


I see that several bugs have been filed and marked as RESOLVED, how
they can be resolved when it is happening over and over again.

Because they are different bugs with different root causes. This
particular issue was determined to be something that needs to be fixed
in akonadi packaging and is now being tracked in bug 843534. Presumably
though you have a different issue as you did not mention akonadi in your
bug report.

Please understand that your report cannot be addressed because you have
not provided enough information. If this angers you, try reading
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html which is a great
essay that explains this problem well.

Please file a new bug report with full steps on how to reproduce your
bug. If it turns out to have a common root cause, we can always mark it
as a duplicate later.

Robie

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

- lu...@debian.org wrote:

> On 14/11/16 at 02:47 -0800, Lars Tangvald wrote:
> > 
> > - lu...@debian.org wrote:
> > 
> > > On 13/11/16 at 22:59 -0800, Lars Tangvald wrote:
> > > > 
> > > > - lu...@debian.org wrote:
> > > > 
> > > > > > Do you have the logs from the last run?
> > > > > > While we could disable the test that's failing, it would be
> > > > > counterproductive since we can't reproduce the issue in any
> of
> > > our
> > > > > normal build environments.
> > > > > 
> > > > > This is the log without your patch applied
> > > > > 
> > > > > Lucas
> > > > 
> > > > Or did you mean with?
> > > 
> > > no, the log was without the patch. I did not keep the log with
> the
> > > patch
> > > 
> > > > It's failing in a different way. I think the way it's failing
> here
> > > is to do with insufficient system resources.
> > > 
> > > unlikely, that node has 64 cores and 256 GB of RAM.
> > >  
> > > Lucas
> > 
> > I got it backwards, then :)
> > A high number of cores might cause this if fs.aio-max-nr is set low
> (cat /proc/sys/fs/aio-max-nr | aio-nr), or rather, too low for the the
> parallelization used by the test run.
> > https://www.kernel.org/doc/Documentation/sysctl/fs.txt
> 
> Well, it was also failing on a more standard machine. The test suite
> should be robust to that...
> 
The original failure you reported was something else; a test failing because of 
an issue with the build environment. The patch I uploaded should make it more 
robust to that.

We could probably set some upper bound on the number of tests run in parallel 
based on the value of this setting, as Robie suggests.

--
Lars

> Lucas

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

- lu...@debian.org wrote:

> On 13/11/16 at 22:59 -0800, Lars Tangvald wrote:
> > 
> > - lu...@debian.org wrote:
> > 
> > > > Do you have the logs from the last run?
> > > > While we could disable the test that's failing, it would be
> > > counterproductive since we can't reproduce the issue in any of
> our
> > > normal build environments.
> > > 
> > > This is the log without your patch applied
> > > 
> > > Lucas
> > 
> > Or did you mean with?
> 
> no, the log was without the patch. I did not keep the log with the
> patch
> 
> > It's failing in a different way. I think the way it's failing here
> is to do with insufficient system resources.
> 
> unlikely, that node has 64 cores and 256 GB of RAM.
>  
> Lucas

I got it backwards, then :)
A high number of cores might cause this if fs.aio-max-nr is set low (cat 
/proc/sys/fs/aio-max-nr | aio-nr), or rather, too low for the the 
parallelization used by the test run.
https://www.kernel.org/doc/Documentation/sysctl/fs.txt

--
Lars

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

- lu...@debian.org wrote:

> > Do you have the logs from the last run?
> > While we could disable the test that's failing, it would be
> counterproductive since we can't reproduce the issue in any of our
> normal build environments.
> 
> This is the log without your patch applied
> 
> Lucas

Or did you mean with? It's failing in a different way. I think the way it's 
failing here is to do with insufficient system resources.

--
Lars

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

- lu...@debian.org wrote:

> > Do you have the logs from the last run?
> > While we could disable the test that's failing, it would be
> counterproductive since we can't reproduce the issue in any of our
> normal build environments.
> 
> This is the log without your patch applied
> 
> Lucas
And with the patch?

--
Lars

Bug#841592: Fwd: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

Forgot the bug

--
Lars--- Begin Message ---

- lu...@debian.org wrote:

> On 09/11/16 at 07:27 -0800, Lars Tangvald wrote:
> > 
> > - lu...@debian.org wrote:
> > 
> > >  
> > > Hi,
> > > 
> > > I don't think that my test is run as root. So it might be
> something
> > > else...
> > > 
> > > Lucas
> > 
> > The error message is access denied for 'root'@'localhost', but the
> test itself tries to log in as the current system user (it's supposed
> to be blank, but that's not working right), so it does seem to be
> running as root. However, if I try a full sbuild as root, there are
> some other tests that will fail too, so it doesn't seem like the test
> suite in general is running as root.
> > 
> > I've made a patch that should fix the test to actually specify a
> blank user. Are you able to test your build with the head of
> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/log/?h=mysql-5.7/ltangvald
> ?
> > It's the same as the 5.7.16 uploaded to unstable, just with that one
> extra commit.
> 
> Hi,
> 
> I can confirm that it does not fix the problem; sorry.
> 
> Lucas

Do you have the logs from the last run?
While we could disable the test that's failing, it would be counterproductive 
since we can't reproduce the issue in any of our normal build environments.

--
Lars
--- End Message ---

Bug#843959: [debian-mysql] Bug#843959: can't upgrade if not running all the time

[Lars Tangvald]

Hi, thanks for the report.

We're aware of the general issue (installation fails if service is disabled). 
It's also tracked here: 
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1592669
The most likely solution for this is:
If service is disabled but server isn't running: Start it in a more manual way, 
without networking, to run mysql_upgrade.
If service is disabled but server _is_ running (meaning we can't start the new 
one); Print a warning asking the user to run mysql_upgrade after restarting.

--
Lars


- jida...@jidanni.org wrote:

> Package: mysql-server
> Version: 5.7.16-1
> 
> Some of us don't see the point of having mysql running all the time.
> 
> So we disable it.
> 
> This causes:
> Setting up mysql-server-5.7 (5.7.16-1) ...
> insserv: warning: current start runlevel(s) (empty) of script `mysql'
> overrides LSB defaults (2 3 4 5).
> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script
> `mysql' overrides LSB defaults (0 1 6).
> mysql_upgrade: Got error: 2002: Can't connect to local MySQL server
> through socket '/var/run/mysqld/mysqld.sock' (2) while connecting to
> the MySQL server
> Upgrade process encountered error and will not continue.
> mysql_upgrade failed with exit status 11
> dpkg: error processing package mysql-server-5.7 (--configure):
>  subprocess installed post-installation script returned error exit
> status 1
> dpkg: dependency problems prevent configuration of mysql-server:
>  mysql-server depends on mysql-server-5.7; however:
>   Package mysql-server-5.7 is not configured yet.
> 
> dpkg: error processing package mysql-server (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  mysql-server-5.7
>  mysql-server
> 
> upon every upgrade.
> 
> Well why don't you start the server in this case,
> or have a configuration item:
> if $user_approves_is_set
> then
> start mysql
> do upgrade
> stop mysql
> fi
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

- lu...@debian.org wrote:

>  
> Hi,
> 
> I don't think that my test is run as root. So it might be something
> else...
> 
> Lucas

The error message is access denied for 'root'@'localhost', but the test itself 
tries to log in as the current system user (it's supposed to be blank, but 
that's not working right), so it does seem to be running as root. However, if I 
try a full sbuild as root, there are some other tests that will fail too, so it 
doesn't seem like the test suite in general is running as root.

I've made a patch that should fix the test to actually specify a blank user. 
Are you able to test your build with the head of 
https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/log/?h=mysql-5.7/ltangvald ?
It's the same as the 5.7.16 uploaded to unstable, just with that one extra 
commit.

--
Lars

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

On 11/09/2016 10:11 AM, Lars Tangvald wrote:

Forgot to add in the bug.

On 11/09/2016 10:01 AM, Lars Tangvald wrote:



On 11/09/2016 08:59 AM, Lucas Nussbaum wrote:

On 09/11/16 at 08:17 +0100, Lars Tangvald wrote:


On 11/07/2016 03:43 PM, Lucas Nussbaum wrote:

Hi,


I don't think it's random: the rebuild is automatically retried 
when it
fails. However, maybe a change in another package fixed it. If you 
have
a full build log, maybe you could diff it with me to see if a 
build-dep

changed, which could explain the result?

I plan to do another archive rebuild soon (probably over next 
week-end).

I'll double-check at this point.

Lucas

I was able to reproduce the failure:
It happens when the test is run as root. Since we haven't had this 
failure
before in the normal system, have you changed anything else about 
how the

package is built?

Nothing I know about, no.
  Lucas


5.7.16 was uploaded and seemed mostly fine, though I'm not too clear 
on how to read the results. Should be able to diff the log, though?
https://buildd.debian.org/status/logs.php?pkg=mysql-5.7=5.7.16-1=sid 

I'm fairly sure the issue is with the environment for the test run. 
It tries to log in as an anonymous user, but if the login command is 
run as root it will instead try to log in as 'root'@'localhost', 
which will fail. So I don't think updating to 5.7.16 will help.
I'll see if I can reproduce with a full sbuild run locally, but we 
might consider disabling the test pending it being reviewed upstream.


Another potential cause for this starting to happen now is that we 
recently fixed an issue in the build script where test failures 
wouldn't cause build failures, so this test might have failed in 
similar runs before (at build time) without it being noticed.



I've made a patch for this test so it can run as root, and will upload 
it to the git once I've built and tested so you can verify that it 
resolves the issue.
I don't think this is a critical issue, since it doesn't affect the 
package build system currently in unstable, and there is something in 
the build environment causing it, so not sure if we need to upload a fix 
right away or if it can wait?
Could it be related to sbuild version? I have 0.67, your failed build 
uses 0.7, while the Debian 5.7.16 build uses 0.65
Bit of a stretch, only somewhat related thing I can see in the changelog 
is (0.69):

- Set APT::Sandbox::User=root when running apt-get source in the
  build-procenv autopkgtest, to avoid stderr noise from current apt.

--
Lars

Bug#841592: [debian-mysql] Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

Forgot to add in the bug.

On 11/09/2016 10:01 AM, Lars Tangvald wrote:



On 11/09/2016 08:59 AM, Lucas Nussbaum wrote:

On 09/11/16 at 08:17 +0100, Lars Tangvald wrote:


On 11/07/2016 03:43 PM, Lucas Nussbaum wrote:

Hi,


I don't think it's random: the rebuild is automatically retried 
when it
fails. However, maybe a change in another package fixed it. If you 
have
a full build log, maybe you could diff it with me to see if a 
build-dep

changed, which could explain the result?

I plan to do another archive rebuild soon (probably over next 
week-end).

I'll double-check at this point.

Lucas

I was able to reproduce the failure:
It happens when the test is run as root. Since we haven't had this 
failure
before in the normal system, have you changed anything else about 
how the

package is built?

Nothing I know about, no.
  Lucas


5.7.16 was uploaded and seemed mostly fine, though I'm not too clear 
on how to read the results. Should be able to diff the log, though?
https://buildd.debian.org/status/logs.php?pkg=mysql-5.7=5.7.16-1=sid 

I'm fairly sure the issue is with the environment for the test run. It 
tries to log in as an anonymous user, but if the login command is run 
as root it will instead try to log in as 'root'@'localhost', which 
will fail. So I don't think updating to 5.7.16 will help.
I'll see if I can reproduce with a full sbuild run locally, but we 
might consider disabling the test pending it being reviewed upstream.


Another potential cause for this starting to happen now is that we 
recently fixed an issue in the build script where test failures wouldn't 
cause build failures, so this test might have failed in similar runs 
before (at build time) without it being noticed.


--
Lars

--
Lars

Bug#841163: [debian-mysql] Upload of MySQL 5.7.16 security update to unstable

[Lars Tangvald]

On 11/08/2016 10:53 PM, Dominic Hargreaves wrote:


Hi Lars,

Now uploaded.

Cheers,
Dominic.

Great, thanks!

--
Lars

Bug#843520: [akonadi-server] Fails to start after mysql upgrade

[Lars Tangvald]

Send the below to the incorrect address (it's largely rendered moot by the 
discussion about the kubuntu patch, but including it anyway):

The change in the MySQL default was made because the old default (unrestricted) 
was considered a potential security risk.
However, we also backported having NULL as a valid value for this, which would 
disable import/export operations unless user configures it differently.
 
Also note that the secure-file-priv option existed in older versions of MySQL 
as well, it just had a different default value (blank), so a config patch for 
akonadi would be backwards-compatible (but NULL would not be a valid option).

--
Lars

Bug#843618: [debian-mysql] Bug#843618: mysql-server-5.5: Fails to start after recent security update

[Lars Tangvald]

Hi,

It's probably something with your setup the upgrade logic can't handle 
correctly.
In 5.5.53, MySQL changes the inbuilt secure-file-priv (determined where 
the server can read/write data for import/export operations) default 
setting from blank, meaning the server has read/write access anywhere, 
to /var/lib/mysql-files, which should be automatically created by the 
postinst. This is a fairly big change, but it was felt the old behavior 
was a big enough security risk to justify it.
Do you have a special setup (partition, symlink, etc) for your /var/lib 
folders, so the default directory might not be possible to create/access?


Finally, setting secure-file-priv to your datadir is very strongly 
recommended against, as it pretty much gives any database user full 
database access.
We recommend either setting it to a separate location, or to NULL (only 
available in 5.5.53+), which will disable import/export operations for 
the server.


--
Lars

On 11/08/2016 11:58 AM, Thomas Braun wrote:

Package: mysql-server-5.5
Version: 5.5.53-0+deb8u1
Severity: important

Dear Maintainer,

after tonights security update my mysql server does not start anymore.

Looking in /var/log/mysql/error.log gives:
161108 11:18:02 mysqld_safe Starting mysqld daemon with databases from
/var/lib/mysql
161108 11:18:02 [Warning] Using unique option prefix key_buffer instead of
key_buffer_size is deprecated and will be removed in a future release. Please
use the full name instead.
/usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2)
161108 11:18:02 [ERROR] Failed to access directory for --secure-file-priv.
Please make sure that directory exists and is accessible by MySQL Server.
Supplied value : /var/lib/mysql-files
161108 11:18:02 [ERROR] Aborting

So it looks like that the new secure-file-priv option defaults to a different
folder than specified as datadir in my config.
I've not touched the mysql settings manually.

I've fixed the bug by adding the file
/etc/mysql/conf.d/fix-security-update-bug.cnf with contents

[mysqld]
secure_file_priv=/var/lib/mysql

Thanks for your work on the mysql packages,
Thomas

-- System Information:
Debian Release: 8.6
   APT prefers stable
   APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mysql-server-5.5 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  initscripts2.88dsf-59
ii  libc6  2.19-18+deb8u6
ii  libdbi-perl1.631-3+b1
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  lsb-base   4.1+Debian13+nmu1
iu  mysql-client-5.5   5.5.53-0+deb8u1
ii  mysql-common   5.5.53-0+deb8u1
iu  mysql-server-core-5.5  5.5.53-0+deb8u1
ii  passwd 1:4.2-3+deb8u1
ii  perl   5.20.2-3+deb8u6
ii  psmisc 22.21-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages mysql-server-5.5 recommends:
ii  libhtml-template-perl  2.95-1

Versions of packages mysql-server-5.5 suggests:
ii  heirloom-mailx [mailx]  12.5-4
pn  tinyca  

-- debconf information:
   mysql-server-5.5/postrm_remove_databases: false
   mysql-server-5.5/start_on_boot: true
   mysql-server/error_setting_password:
   mysql-server-5.5/nis_warning:
   mysql-server/password_mismatch:
   mysql-server-5.5/really_downgrade: false
   mysql-server/no_upgrade_when_using_ndb:

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841163: Upload of MySQL 5.7.16 security update to unstable

[Lars Tangvald]

Hi all,

We prepared a security upload for the Oracle October 2016 CPU, but we need 
someone with access to sponsor the upload to Debian unstable. Is anyone 
available to do this?
The source should be ready to go from 
https://anonscm.debian.org/cgit/pkg-mysql/mysql.git

--
Lars

Bug#841592: [debian-mysql] Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lars Tangvald]

Hi,

I can't reproduce this failure, with 5.7.15 or the 5.7.16 we've prepared 
for #841163
I think maybe this is an unstable test, in which case we can disable it 
until it's resolved upstream.

Could you retry the build and see if it happens again?

--
Lars

Bug#842011: [debian-mysql] Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Lars Tangvald]

- robie.ba...@ubuntu.com wrote:

> Hi Craig,
> 
> On Tue, Oct 25, 2016 at 08:01:26PM +1100, Craig Sanders wrote:
> > it's somewhat surprising that a package called default-mysql-client
> should
> > force the removal of both mysql-client and mysql-server packages.
> 
> Please could you explain your use case? What are you trying to do at
> a
> high level and why?
> 
> I agree that it's surprising that installing mariadb-client-10.0
> forces
> the removal of mysql-server-5.7. This appears to be because
> mysql-server-5.7 depends on mysql-client-5.7.
> 
> Lars, do you know why this is necessary? Is this something we can
> drop?
> 
SysV and upstart scripts use mysqladmin (which is in the client) to verify that 
the server is running. 5.7 has some inbuilt support for systemd, so for systemd 
at least it's not needed.

--
Lars
> > mariadb is NOT a drop-in replacement for mysql.
> 
> It does, however, take over various binary paths, so the equivalent
> (server<->server, client<->client) packages must conflict, or the
> MariaDB packaging needs to rename all the "mysql" names to "mariadb"
> names, or the MySQL packaging needs to stop using any "mysql" names,
> or
> we need extreme update-alternatives work. I don't see any other
> options.
> 
> The Debian MySQL maintainers team has always taken the first approach
> (they conflict so a particular system can have MariaDB or MySQL but
> not
> both). I don't believe we have any intention of changing this, but if
> you think we should, perhaps we should track that in a separate bug.
> 
> Separately, MySQL will be leaving testing shortly, so I'm surprised
> that
> you care. See bug 837615.
> 
> You said:
> 
> > default-mysql-client forces removal of mysql-server* and
> mysql-client*
> 
> Forcing the removal of mysql-server* seems to me to be surprising, so
> I'll leave this bug open to look into that.
> 
> Forcing the removal of mysql-client* is by design, so this is
> "wontfix"
> without further discussion. If you want to take this further then
> please
> could you file a separate bug for that ("mysql-client-* conflicts
> with
> mariadb-client-*), so we can distinguish between the different root
> causes? It will immediately be a wontfix but I welcome technically
> feasible arguments to have that changed.
> 
> Robie

Bug#841345: [debian-mysql] Bug#841345: mysql-server-5.7: Unable to switch from mariadb to mysql, "downgrade" is aborted

[Lars Tangvald]

- fsate...@debian.org wrote:

> On 19 October 2016 at 14:08, Lars Tangvald <lars.tangv...@oracle.com>
> wrote:
> >
> > - fsate...@debian.org wrote:
> >
> >> Package: mysql-server-5.7
> >> Version: 5.7.15-1
> >> Severity: important
> >>
> >>
> >> Switching from mariadb to mysql fails with the following error
> >> message:
> >>
> >> Aborting downgrade from (at least) 10.0 to 5.7.
> >> If are sure you want to downgrade to 5.7, remove the file
> >> /var/lib/mysql/debian-*.flag and try installing again.
> >>
> >>
> >> The test[1] seems to be a bit naive, given that mariadb uses the
> same
> >> flag file.
> >>
> >> Mariadb and mysql are supposed to be drop-in replacements, so
> >> switching
> >> between them should be supported.
> >>
> > This is a misunderstanding, unfortunately. MySQL and MariaDB are not
> drop-in replacements of each other.
> 
> Oh, bummer.
> 
> > MariaDB is able to read the databases of some MySQL versions (5.5
> and earlier and probably 5.6, since the database structure didn't
> change too much there), but as far as I know they don't yet support
> 5.7-created databases in any released version.
> > MySQL does not support running with a MariaDB-created database.
> >
> > While the flag system does need a redesign (there's an issue to
> track this at
> https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1490071) it's
> more likely the solution there will be to move the old versions data
> "out of the way", possibly with an option to try using it.
> 
> 
> Then mysql and mariadb should not share the /var/lib/mysql directory,
> and instead there should be a command to offer trying to "seed" the
> db
> using the other database's files.
> 
> -- 
> 
Yes, separating the actual files of the two seems a better long-term solution 
to me (and the packaging for both could check for the presence of the others 
and ask users if an attempt to import should be made).

But while this isn't a huge task for MySQL and MariaDB, I know there are other 
packages that use them with hard-coded paths, and they will start breaking. I'd 
say this is to be considered a bug in those packages, but it does mean it's not 
a small task.

--
Lars

Bug#841345: [debian-mysql] Bug#841345: mysql-server-5.7: Unable to switch from mariadb to mysql, "downgrade" is aborted

[Lars Tangvald]

- fsate...@debian.org wrote:

> Package: mysql-server-5.7
> Version: 5.7.15-1
> Severity: important
> 
> 
> Switching from mariadb to mysql fails with the following error
> message:
> 
> Aborting downgrade from (at least) 10.0 to 5.7.
> If are sure you want to downgrade to 5.7, remove the file
> /var/lib/mysql/debian-*.flag and try installing again.
> 
> 
> The test[1] seems to be a bit naive, given that mariadb uses the same
> flag file.
> 
> Mariadb and mysql are supposed to be drop-in replacements, so
> switching
> between them should be supported.
> 
This is a misunderstanding, unfortunately. MySQL and MariaDB are not drop-in 
replacements of each other. 
MariaDB is able to read the databases of some MySQL versions (5.5 and earlier 
and probably 5.6, since the database structure didn't change too much there), 
but as far as I know they don't yet support 5.7-created databases in any 
released version.
MySQL does not support running with a MariaDB-created database.

While the flag system does need a redesign (there's an issue to track this at 
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1490071) it's more 
likely the solution there will be to move the old versions data "out of the 
way", possibly with an option to try using it.

--
Lars

Bug#841050: [debian-mysql] Bug#841050: Security fixes from the October 2016 CPU

[Lars Tangvald]

Hi,

On 10/19/2016 10:18 AM, Moritz Muehlenhoff wrote:

Hi,

On Wed, Oct 19, 2016 at 09:10:59AM +0200, Lars Tangvald wrote:

So for Linux we consider this fixed in 5.5.52, but the complete fix
was in 5.5.53.

Is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837984
addressed in 5.5.53?

No, this hasn't been changed.
If you take a look at 
https://github.com/mysql/mysql-server/blob/5.5/scripts/mysqld_safe.sh 
(just search for 'i386') you'll see it restricts it to intel architectures.
This is a whitelist of where the --malloc-lib option is allowed to be 
set, and is restricted to the intel archs because we considered it of 
little use on other architectures.
If needs to be available on other architectures we could make a patch in 
the packaging to add them.



Should I remove the CVE from the Debian changelog entry?

That's not needed, we can add a comment to the Security Tracker.

Ok, thanks :)

--
Lars

Cheers,
 Moritz

Bug#841050: [debian-mysql] Bug#841050: Security fixes from the October 2016 CPU

[Lars Tangvald]

On 10/19/2016 08:21 AM, Salvatore Bonaccorso wrote:

Hi Lars, hi Norvald,

On Wed, Oct 19, 2016 at 08:03:00AM +0200, Lars Tangvald wrote:

The following CVEs are fixed in 5.5.53:
CVE-2016-6662 CVE-2016-7440 CVE-2016-5584

The listing of CVE-2016-6662 is confusing here. This should actually
already be addressed in 5.5.52, cf.
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

Any insight on why Oracle claims it to be only fixed in 5.5.53?

Regards,
Salvatore
The CPU listing concerns all platforms, and there were some additional 
complexities in the CVE for other platforms.
So for Linux we consider this fixed in 5.5.52, but the complete fix was 
in 5.5.53.

Should I remove the CVE from the Debian changelog entry?
I've got the updated packages built and tested, so should have the 
debdiff pretty much ready.


--
Lars

Bug#841163: [debian-mysql] Bug#841163: Security fixes from the October 2016 CPU

[Lars Tangvald]

The following CVEs are fixed by 5.7.16:
CVE-2016-5584 CVE-2016-6304 CVE-2016-6662 CVE-2016-7440

--
Lars

On 10/18/2016 10:24 AM, Norvald H. Ryeng wrote:

Source: mysql-5.7
Version: 5.7.15-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2016 will be released on 
Tuesday, October 18. According to the pre-release announcement [1], it 
will contain information about CVEs fixed in MySQL 5.7.16.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841050: [debian-mysql] Bug#841050: Security fixes from the October 2016 CPU

[Lars Tangvald]

Hi,

This might be an error in the CPU announcement (they sometimes get 
corrections after the initial announcement). I'll try to track down 
someone who's worked on this fix and ask.


--
Lars

On 10/19/2016 08:21 AM, Salvatore Bonaccorso wrote:

Hi Lars, hi Norvald,

On Wed, Oct 19, 2016 at 08:03:00AM +0200, Lars Tangvald wrote:

The following CVEs are fixed in 5.5.53:
CVE-2016-6662 CVE-2016-7440 CVE-2016-5584

The listing of CVE-2016-6662 is confusing here. This should actually
already be addressed in 5.5.52, cf.
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

Any insight on why Oracle claims it to be only fixed in 5.5.53?

Regards,
Salvatore

Bug#841050: [debian-mysql] Bug#841050: Security fixes from the October 2016 CPU

[Lars Tangvald]

The following CVEs are fixed in 5.5.53:
CVE-2016-6662 CVE-2016-7440 CVE-2016-5584

On 10/17/2016 10:05 AM, Norvald H. Ryeng wrote:

Source: mysql-5.5
Version: 5.5.52-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2016 will be released on 
Tuesday, October 18. According to the pre-release announcement [1], it 
will contain information about CVEs fixed in MySQL 5.5.53.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841049: [debian-mysql] Bug#841049: Security fixes from the October 2016 CPU

[Lars Tangvald]

The following CVEs are noted as fixed since 5.6.30:
CVE-2016-3492 CVE-2016-5507 CVE-2016-5584 CVE-2016-5609
CVE-2016-5612 CVE-2016-5616 CVE-2016-5617 CVE-2016-5626
CVE-2016-5627 CVE-2016-5629 CVE-2016-5630 CVE-2016-6304
CVE-2016-6662 CVE-2016-7440 CVE-2016-8283 CVE-2016-8284

--
Lars

On 10/17/2016 10:05 AM, Norvald H. Ryeng wrote:

Source: mysql-5.6
Version: 5.6.30-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2016 will be released on 
Tuesday, October 18. According to the pre-release announcement [1], it 
will contain information about CVEs fixed in MySQL 5.6.34.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#840855: [debian-mysql] Bug#840855: mysql-server: MySQL 5.7?

[Lars Tangvald]

MySQL 5.7 is available in unstable now :)

--
Lars

Bug#841050: [debian-mysql] Bug#841050: Security fixes from the October 2016 CPU

[Lars Tangvald]

As noted in the changelog for 5.5.53 at 
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-53.html,
MySQL 5.5.53 contains a change that requires packaging changes and could 
potentially impact users:


By default the server will restrict the server's access for SELECT INTO 
OUTFILE and LOAD DATA operations to /var/lib/mysql-files, and requires 
the directory to be present at startup.
This behavior can be changed at build-time to either turn such access 
off completely or make it unrestricted (current behavior).


We strongly recommend keeping the default behavior to improve the 
default security, i.e. change packaging to create the mysql-files 
directory. We're not aware of any other packages that rely on this 
functionality, but there is a risk of this change disrupting user workflows.


--
Lars

On 10/17/2016 10:05 AM, Norvald H. Ryeng wrote:

Source: mysql-5.5
Version: 5.5.52-0+deb8u1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2016 will be released on 
Tuesday, October 18. According to the pre-release announcement [1], it 
will contain information about CVEs fixed in MySQL 5.5.53.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#841049: [debian-mysql] Bug#841049: Security fixes from the October 2016 CPU

[Lars Tangvald]

As noted in the changelog for 5.6.34 at 
https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-34.html,
5.6.34 contains a change that requires packaging changes and could 
potentially impact users:


By default the server will restrict the server's access for SELECT INTO 
OUTFILE and LOAD DATA operations to /var/lib/mysql-files, and requires 
the directory to be present at startup.
This behavior can be changed at build-time to either turn such access 
off completely or make it unrestricted (current behavior).


We strongly recommend keeping the default behavior to improve the 
default security, i.e. change packaging to create the mysql-files 
directory. We're not aware of any other packages that rely on this 
functionality, but there is a risk of this change disrupting user workflows.


--
Lars

On 10/17/2016 10:05 AM, Norvald H. Ryeng wrote:

Source: mysql-5.6
Version: 5.6.30-1
Severity: grave
Tags: security upstream fixed-upstream

The Oracle Critical Patch Update for October 2016 will be released on 
Tuesday, October 18. According to the pre-release announcement [1], it 
will contain information about CVEs fixed in MySQL 5.6.34.


The CVE numbers will be available when the CPU is released.

Regards,

Norvald H. Ryeng

[1] 
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#840855: [debian-mysql] Bug#840855: Bug#840855: mysql-server: MySQL 5.7?

[Lars Tangvald]

On 10/15/2016 06:10 PM, Clint Byrum wrote:

Excerpts from Olaf van der Spek's message of 2016-10-15 17:59:36 +0200:

Package: mysql-server
Version: 5.5.52-0+deb8u1
Severity: wishlist

Dear Maintainer,

What's the plan for MySQL 5.7? AFAIK it was released in April, will it be 
included in Stretch?


The release and security teams have decided that MySQL will live only in
unstable for stretch due to the perceived complications with tracking
security patches in MySQL.

I have not heard anything from our most excellent active maintainers,
but I suspect they may decide it's not worth it to do the work to ship
5.7 in unstable only.

If you disagree with this position, I suggest you email the security
and release team to see if there's anything that can be done to change
it.

We're working on a 5.7 upload to unstable, and plan to maintain it there.

The current state of the packaging for testing/Stretch is noted in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837615 (for 5.6, since 
that's what is currently there)


--
Lars

Bug#837994: [debian-mysql] Bug#837994: Bug#837994: mysql-5.5: FTBFS on armhf

[Lars Tangvald]

Do you know how the build is set up? Parallelization, etc.

The hosts look the same, to me, so seems likely the build is simply 
unstable.


--

Lars

On 09/18/2016 12:03 PM, Lars Tangvald wrote:

Yeah, we'll look into it some more.
I've seen the sort of sudden exits without errors before if a host runs out of 
memory, but the requirements for building 5.5 are low and shouldn't have 
changed significantly.

--
Lars
- car...@debian.org wrote:


Control: severity -1 important

Hi Lars, hi all,

It finally worked on another buildd, namely henze,
https://db.debian.org/machines.cgi?host=henze

I'm lowering the severity to important since we have now all builds.
But before eventually closing it would be nice if we can get an idea
why it failed on the other attempts on the other buildds.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#837994: [debian-mysql] Bug#837994: Bug#837994: mysql-5.5: FTBFS on armhf

[Lars Tangvald]

Yeah, we'll look into it some more.
I've seen the sort of sudden exits without errors before if a host runs out of 
memory, but the requirements for building 5.5 are low and shouldn't have 
changed significantly.

--
Lars
- car...@debian.org wrote:

> Control: severity -1 important
> 
> Hi Lars, hi all,
> 
> It finally worked on another buildd, namely henze,
> https://db.debian.org/machines.cgi?host=henze
> 
> I'm lowering the severity to important since we have now all builds.
> But before eventually closing it would be nice if we can get an idea
> why it failed on the other attempts on the other buildds.
> 
> Regards,
> Salvatore

Bug#837994: [debian-mysql] Bug#837994: mysql-5.5: FTBFS on armhf

[Lars Tangvald]

build-stamp fails, but there's no error message that I can see

...

[  6%] Building CXX object 
extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dh.cpp.o
cd /«PKGBUILDDIR»/builddir-pic/extra/yassl/taocrypt && 
/usr/bin/arm-linux-gnueabihf-g++   -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 
-O3 -DBIG_JOINS=1 -felide-constructors -fno-exceptions -fno-rtti -fPIC 
-fno-strict-aliasing   -fPIC -fno-exceptions -fno-rtti -O2 -g -DNDEBUG 
-DDBUG_OFF -I/«PKGBUILDDIR»/builddir-pic/include 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/mySTL 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/include 
-I/«PKGBUILDDIR»/include-DHAVE_YASSL -DYASSL_PURE_C -DYASSL_PREFIX 
-DHAVE_OPENSSL -DMULTI_THREADED -fvisibility=hidden -o 
CMakeFiles/taocrypt.dir/src/dh.cpp.o -c 
/«PKGBUILDDIR»/extra/yassl/taocrypt/src/dh.cpp
/usr/bin/cmake -E cmake_progress_report 
/«PKGBUILDDIR»/builddir-pic/CMakeFiles
[  6%] Building CXX object 
extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dsa.cpp.o
cd /«PKGBUILDDIR»/builddir-pic/extra/yassl/taocrypt && 
/usr/bin/arm-linux-gnueabihf-g++   -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 
-O3 -DBIG_JOINS=1 -felide-constructors -fno-exceptions -fno-rtti -fPIC 
-fno-strict-aliasing   -fPIC -fno-exceptions -fno-rtti -O2 -g -DNDEBUG 
-DDBUG_OFF -I/«PKGBUILDDIR»/builddir-pic/include 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/mySTL 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/include 
-I/«PKGBUILDDIR»/include-DHAVE_YASSL -DYASSL_PURE_C -DYASSL_PREFIX 
-DHAVE_OPENSSL -DMULTI_THREADED -fvisibility=hidden -o 
CMakeFiles/taocrypt.dir/src/dsa.cpp.o -c 
/«PKGBUILDDIR»/extra/yassl/taocrypt/src/dsa.cpp

debian/rules:142: recipe for target 'build-stamp' failed
make[1]: *** [build-stamp] Error 1
make[1]: *** Waiting for unfinished jobs

...

--

Lars


On 09/16/2016 10:39 AM, Salvatore Bonaccorso wrote:

Source: mysql-5.5
Version: 5.5.52-0+deb8u1
Severity: serious
Justification: FTBFS

Hi

On armhf the latest security-update for mysql-5.5 5.5.52-0+deb8u1
fails to build. Attached is a build log for it.

Regards,
Salvatore


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#837883: [debian-mysql] Bug#837883: Bug#837883: mysql-server-5.7: Please upgrade to 5.7.15+ to fix recently discovered security issues

[Lars Tangvald]

Thanks, Bjoern. Did you run the dep8 test suite as well (I just started 
a full test run now, so no big deal either way)?


--

Lars


On 09/15/2016 12:54 PM, Bjoern Boschman wrote:

Hi,

I've updated the git repo after I did a successful build on jessie.
Someone with upload rights just needs to create a ~experimental tag 
and upload it.


@pkg-mysql: what's the plan for uploading mysql-5.7 to unstable?

Cheers
B

On Thu, Sep 15, 2016 at 9:54 AM Eric Valette > wrote:


Package: mysql-server-5.7
Version: 5.7.13-1~exp1
Severity: grave
Tags: upstream security
Justification: user security hole

CVE-2016-6662

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.20 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mysql-server-5.7 depends on:
ii  adduser3.115
ii  bsdutils   1:2.28.2-1
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.44
ii  libc6  2.24-2
ii  libgcc11:6.2.0-3
ii  libmecab2  0.996-2
ii  libstdc++6 6.2.0-3
ii  lsb-base   9.20160629
ii  mysql-client-5.7   5.7.13-1~exp1
ii  mysql-common   5.8+1.0.0
ii  mysql-server-core-5.7  5.7.13-1~exp1
ii  passwd 1:4.2-3.1
ii  perl   5.22.2-5
ii  psmisc 22.21-2.1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages mysql-server-5.7 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mysql-server-5.7 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-3
ii  s-nail [mailx] 14.8.10-1
pn  tinyca 

-- debconf information:
  mysql-server-5.7/postrm_remove_databases: false
  mysql-server-5.7/start_on_boot: true
  mysql-server/no_upgrade_when_using_ndb:
  mysql-server-5.7/nis_warning:
  mysql-server-5.7/really_downgrade: false
  mysql-server/password_mismatch:

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org

http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint



___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#821100: MySQL 5.5.49 for Oracle April 2016 CPU

[Lars Tangvald]

Hi,

- car...@debian.org wrote:

> Hi Lars,
> 
> On Wed, Apr 20, 2016 at 08:20:56AM +0200, Salvatore Bonaccorso wrote:
> > Hi Lars,
> > 
> > On Tue, Apr 19, 2016 at 12:27:51PM -0700, Lars Tangvald wrote:
> > > We've prepared MySQL 5.5.49 packages for Debian Wheezy and Jessie
> > > with fixes for the CVEs listed in Oracle's April CPU.
> > > The packages are built and tested and should be ready for upload,
> > > and I've attached the debdiff output for review.
> > > Of note is that due to upstream source changes we needed to remake
> a
> > > patch that was added for 5.5.46 to fix arm and powerpc build
> > > failures. New patch is larger, but should have the same behavior.
> > 
> > Okay.
> > 
> > Assuming some additional tests apart the testsuite have been done,
> > please proceed with the update (but with the following small
> change).
> > 
> > Use 5.5.49-0+deb7u1 instead of 5.5.49-0+deb7u1.1 for the version,
> > respectively 5.5.49-0+deb8u1 instead of 5.5.49-0+deb8u1.1.
> > 
> > Please remember to build the first upload for security master with
> -sa
> > to include the original source, then the second one without
> -sa.[*].
> > 
> > I (or someone else of the team) will release the DSA once the
> builds
> > are available.
> > 
> > Thanks already for your work on this update,
> > 
> > Regards,
> > Salvatore
> > 
> >  [*] since you (your sponsor) will not get a dak accepted mail,
> please
> >  either wait ~15 Minutes for the second upload to wait the first
> one
> >  is correctly processed or drop in in #debian-security to shortly
> >  confirm (or via mail is as well fine).
> 
> Do you have any status-update for this for us?
> 
> Regards,
> Salvatore

I fixed the version string, and the source is ready in our git repo, but there 
aren't many on our team with upload rights for 5.5, and they've been a bit 
swamped in work the last few days. Sorry for the delay, but we're hoping to get 
the upload done soon.

--
Lars

Bug#820173: RM: mysql-proxy/0.8.1-1.1 -- RoM; package eol

[Lars Tangvald]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The package has been eol'ed by upstream.
It never made it past the alpha stage, and there will be no further 
releases.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-11-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#772954: MySQL 5.7 does not include libmysqld-pic

[Lars Tangvald]

In MySQL 5.7 the libmysqld-pic package is no longer included and all 
dependencies on it should be changed to libmysqld-dev.

The build-dependency on mysql-server-core-5.6 | mysql-server-core also doesn't 
work as intended, as the mysql-server-core package was removed in 5.6. It 
should probably be changed to mysql-server-core-5.6 | virtual-mysql-server-core.

--
Lars

Bug#812812: [debian-mysql] Bug#812812: MySQL client library should ship a symbols file, or at least not have a Lintian override to hide the problem

[Lars Tangvald]

Hi,

I'll work on making sure this is added for the 5.7 packaging.

--
Lars
- Original Message -
From: robie.ba...@ubuntu.com
To: 812...@bugs.debian.org
Sent: Thursday, January 28, 2016 11:51:13 AM GMT +01:00 Amsterdam / Berlin / 
Bern / Rome / Stockholm / Vienna
Subject: [debian-mysql] Bug#812812: MySQL client library should ship a symbols 
file, or at least not have a Lintian override to hide the problem

Hi Otto,

On Tue, Jan 26, 2016 at 10:03:37PM +0200, Otto Kekäläinen wrote:
> The mysql-5.5 source package produces the libmysqlclient18 shared
> library, main file being libmysqlclient.so.18. So does the mysql-5.6
> package too (even using the same "18" version string oddly, are there
> no changes in the ABI?).

There aren't any intentional changes. There was some accidental
symbol breakage, but after investigation I think the conclusion was to
leave it as is because it was discovered after the fact and we couldn't
find that it actually broke anything. Oracle did reserve .19 for Debian
if we wanted to use that. If there is something broken such that we
should bump it, we still can, but I see no point if there is no impact.

After that was discovered, upstream overhauled the library symbols,
dropping a load of internal things and fixing it properly. This is in
5.7, there will be an ABI bump to .20, and I absolutely agree that we
must have a symbols file for it. Having that there in the first place
would have prevented the previous mess.

> 1) Drop the Lintian override immediately. This problem should not be
> hidden on purpose.

Done in VCS. Please that this override was historical and was not added
deliberately by any of the current maintainers. I don't see any need to
upload just for this though.

> 2) Add the symbols file and start tracking symbols.

We'll do this in 5.7, which we're working on actively right now. I hope
to see 5.7 landing within the next month, as I'd like to done before
Ubuntu's feature freeze. Given that we're going to bump the ABI, we
might as well fix this symbols problem at the same time as the imminent
bump.

Do you see any reason why we need to do it urgently, earlier?

> 3) If there are problems with the symbols changing from release to
> release, please address it in appropriate ways, e.g. dump the soname
> from .18 to .18.1 or .19 or what is most fit.

We'll bump to .20.

Robie

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#811428: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

Hi,

I'll get it sent over shortly.

--
Lars

On 01/25/2016 08:57 AM, Salvatore Bonaccorso wrote:

Hi Lars,

On Fri, Jan 22, 2016 at 08:25:30AM -0800, Lars Tangvald wrote:

Hi Salvatore,

I'll get the wheezy-security package built and tested and send an update as 
soon as it's done.

Great thanks!

In meanwhile could you please send the resulting debdiff for the
jessie-security upload to us, for a short review? If it is then fine
we can already have the jessie-security package uploaded to
security-master and let the buildd daemons pick the work.

Regards,
Salvatore

Bug#811428: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

Hi Salvatore,

I'll get the wheezy-security package built and tested and send an update as 
soon as it's done.

regards,
Lars Tangvald

- Original Message -
From: car...@debian.org
To: robie.ba...@ubuntu.com
Cc: 811...@bugs.debian.org, t...@security.debian.org
Sent: Thursday, January 21, 2016 8:15:30 PM GMT +01:00 Amsterdam / Berlin / 
Bern / Rome / Stockholm / Vienna
Subject: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the 
January 2016 CPU

Hi Robie,

On Thu, Jan 21, 2016 at 09:46:13AM +, Robie Basak wrote:
> Dear Security Team,
> 
> You have asked us to be prompt with helping to prepare security updates
> for you, and we have done so. We have kept the bug updated like you
> asked us last time. The sources are tested and ready. We notified the
> bug as requested, but haven't heard from you. Please let us know how you
> want to coordinate uploading this.

Thanks for preparing an update.

We usually would see a debdiff from the resulting built package (in
case of a new upstream import this can get big, so some autogenerated
files can be filtered out).

We have collected important information for us in advisory preparation
in https://wiki.debian.org/DebianSecurity/AdvisoryCreation especially
relevant from the developers point of view preparing the update
https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecurityDev .

The changelog itself looks good to me from a quick skim trough. It
addresses all the information we would like to have seen there (CVE
references, bug fixed, reference to Oracle CPU). Thank you.

Important question first: What is the status for the wheezy-security
package for those issues?

Plase make sure for the following: Once you have both, built the
jessie-security one with -sa to include the original orig.tar.gz and
the wheezy-security one explicitly without -sa to not include the orig
source tarball.

Then we need a bit of coordination for the upload order, since
mysql-5.5 is a special case with same source orig.tar.gz for both
wheezy and jessie. Someone of your team with GPG key in the DD keyring
might then upload first the jessie-security one to security-master,
and after it gets accepted there, upload the wheezy-security one.

Regards,
Salvatore

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#811428: [debian-mysql] Bug#811428: Bug#811428: Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

On 01/20/2016 12:59 AM, Clint Byrum wrote:

Is anyone working on the build/test/upload of the final binaries?
I'm working with Robie to get the upload ready. Dep8 tests have passed 
on stable, and the changes made by the security team for previous 
releases should all be merged into my github tree.


Once it's merged into Alioth we'll need someone to take over for tag and 
upload.


--
Lars Tangvald

Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

http://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git/  is updated.
I'll send a notice to the security team. They may want us to do the 
upload, in which case we'll need someone who has the permissions to do so :)


--
Lars Tangvald

Bug#811428: [debian-mysql] Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

The updated changelog containing the CPU information can be found at 
https://github.com/ltangvald/mysql-5.5
The final commit is the only change from 
https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git

--
Lars Tangvald

Bug#811428: [debian-mysql] Bug#811428: Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU

[Lars Tangvald]

The git tree is missing a copyright update made by the security team, 
which will need to be merged.


--
Lars Tangvald

On 01/19/2016 10:02 PM, Norvald H. Ryeng wrote:
The Critical Patch Update is out: 
http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html


The following vulnerabilities are fixed by upgrading from MySQL 5.5.46 
to 5.5.47:


CVE-2016-0505
CVE-2016-0546
CVE-2016-0597
CVE-2016-0598
CVE-2016-0600
CVE-2016-0606
CVE-2016-0608
CVE-2016-0609
CVE-2016-0596
CVE-2016-0616

Regards,

Norvald H. Ryeng

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#804214: [debian-mysql] Bug#804214: mysql-server-core-5.5: Mysql 5.5.46 freezes under load

[Lars Tangvald]

Hi,

Thanks for the report. We'll look into it.
This might be the same issue as https://bugs.mysql.com/bug.php?id=79185.

--
Lars

On 11/06/2015 10:24 AM, Eriksson, Ulric wrote:

Package: mysql-server-core-5.5
Version: 5.5.44-0+deb7u1
Severity: important

Dear Maintainer,

Last week, we upgraded two of our database servers from version
5.5.44-0+deb7u1 to 5.5.46-0+deb7u1. After the upgrade, we started
experiencing unpredictable freezes, where the database became
unresponsive. In this state, it was not possible to connect to it,
list processes or even shut it down normally. The only way to get
out of this state was to kill -9 mysqld, start up again and let it
do crash recovery. This happened several times on both servers,
usually at least once per day, usually at heavy load. The longest
a server went without a crash was 40 hours.

We established a 24/7 schedule to babysit the system, so that it
was possible to detect outages early. We also worked with consultants
from Percona who suggested several options for tuning the system,
none of which were effective in preventing the freezing.

There were no performance problems before or during the outages.

Eventually we decided that a downgrade to 5.5.44 was necessary.
This was done on November 3rd and the databases have been stable
since.

Mysql configuration files:

ueriksson@gib-ca-db01:~$ more /etc/mysql/my.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[isamchk]
key_buffer_size = 16M

[mysql]
default-character-set = utf8

[mysqld]
basedir = /usr
bind-address = 0.0.0.0
character-set-server = utf8
datadir = /var/lib/mysql
default-storage-engine = INNODB
expire_logs_days = 14
innodb_file_per_table
key_buffer_size = 16M
log-error = /var/log/mysql/mysql.log
long_query_time = 1
max_allowed_packet = 16M
max_binlog_size = 100M
max_connections = 151
myisam_recover = BACKUP
table_open_cache = 4000
pid-file = /var/run/mysqld/mysqld.pid
port = 3306
query_cache_limit = 1M
#query_cache_size = 16M
skip-external-locking
slow_launch_time = 1
socket = /var/run/mysqld/mysqld.sock
#thread_cache_size = 8
thread_stack = 256K
tmpdir = /tmp
transaction-isolation = READ-COMMITTED
user = mysql
#thread_cache_size=64


new_changes

innodb_buffer_pool_instances=8
innodb_stats_on_metadata=OFF
thread_cache_size=1000
query_cache_size=0
query_cache_type=0
innodb_flush_method=O_DIRECT

[mysqld_safe]
log-error = /var/log/mysql/mysql.log
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqldump]
max_allowed_packet = 16M
quick
quote-names


!includedir /etc/mysql/conf.d/

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/common.cnf
[mysqld]
bind-address = 0.0.0.0
datadir = /data/mysql
tmpdir = /data/tmp
max_connections = 2000
expire_logs_days = 14
#thread_cache_size = 64
log-bin-trust-function-creators = 1

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/compress.cnf
[mysqld]
innodb_file_format = Barracuda
innodb_old_blocks_time = 1000

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/memory.cnf
[mysqld]
# innodb tweak params
innodb_buffer_pool_size = 51G
innodb_log_file_size = 1800M
innodb_log_buffer_size = 16M

ueriksson@gib-ca-db01:~$ more /etc/mysql/conf.d/replication.cnf
[mysqld]
server-id = 11
auto-increment-increment = 1
auto-increment-offset = 1

log-slave-updates = true
log_bin = /data/log/mysql-bin.log
binlog-format = row
replicate-wild-ignore-table = mysql.%
replicate-wild-ignore-table = performance_schema.%
# Skip some errors
# 1396 = user error
# 1133 = set password error


-- System Information:
Debian Release: 7.9
   APT prefers oldstable-updates
   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/10 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mysql-server-core-5.5 depends on:
ii  libaio1 0.3.109-3
ii  libc6   2.13-38+deb7u8
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5
ii  libwrap07.6.q-24
ii  zlib1g  1:1.2.7.dfsg-13

mysql-server-core-5.5 recommends no packages.

mysql-server-core-5.5 suggests no packages.

-- no debconf information

___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint