Re: MariaDB 10.3.39
Hi! FYI, MariaDB did an extra batch of releases in June. This message is about 10.3 series. No MariaDB 10.3.40 did not happen as 10.3 series it out of scope. However, thinking of cherry-picking 10.4 changes, I did however check the release notes of 10.4.30. The 3 top issues at https://mariadb.com/kb/en/mariadb-10-4-30-release-notes/ I tracked down to be commits: https://github.com/MariaDB/server/commit/928012a27ae2d1549f1b3e6975b9d22652bbea3a.patch https://github.com/MariaDB/server/commit/8f3bf593d24de9cd4744e71c86de80cd502786c7.patch https://github.com/MariaDB/server/commit/aa713f5ae20513b0c4d9a74ea3ba3ea3bbdcd719.patch None of the above applied cleanly on 10.3.39, so I gave up. The 4th issue in release notes is reverting a change that I checked was never on 10.3 series at all, so not relevant. As an extra experiment I mass applied all commits from 10.4 branch on 10.3 that applied easily in https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/38 and pushed to CI to see how much breaks. This type of backporting has never been done, so this is a bit of experimental, but I wanted to try it out and ask thoughts about if this makes sense from the LTS team. - Otto
#1036797 bullseye-pu: package mariadb-10.5 10.5.20-0+deb11u1
Hi LTS team! I filed on May 26th this but never got any reply from stable managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=103679 It is affected by only one minor CVE-2022-47015. The same CVE was already fixed in DLA-3444-1 with MariaDB 10.3.39 which was the LTS until two weeks ago. Since bullseye is LTS now, I just wanted to quickly get ack'ed by the LTS team that I should prepare this as for Bullseye? - Otto
New MariaDB releases in progress
Hello! FYI to avoid duplicate/conflicting work: MariaDB just released a batch of new security/maintenance releases. I am working to import 10.3, 10.5 and 10.11 into Debian (and eventually into Ubuntu). You can follow progress in real time via git commits showing up at https://salsa.debian.org/mariadb-team/mariadb-10.3 https://salsa.debian.org/mariadb-team/mariadb-10.5 https://salsa.debian.org/mariadb-team/mariadb I am currently at the Open Source Summit in Vancouver and doing this on the side, but cannot promise any exact schedule. - Otto
Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
> > On 19/03/2023 23:04, Otto Kekäläinen wrote:
> > > Following up on this topic, I noticed that I can't even manually
> > > override the Lintian image version at the moment as the
> > > Buster/Bullseye/Bookworm tags don't exist at
> > > https://salsa.debian.org/groups/salsa-ci-team/-/container_registries/295
> > >
> > > To fix this I filed now
> > > https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/407
> >
> > You can probably use the base:$(RELEASE) image and install lintian yourself.
> >
> > > I am a bit surprised I seem to be the only one running Salsa-CI when
> > > preparing stable/LTS uploads, this issue must have been making the
> > > pipeline red for everybody building RELEASE=bullseye/buster/stretch.
>
> Not really, because of this, from salsa-ci.yml:
>
> SALSA_CI_IMAGES_LINTIAN: ${SALSA_CI_IMAGES}/lintian:latest
That one I can override myself in a local Gitlab CI file. However I
cannot override the fact that the CONTAINER IMAGE lintian:bullseye
DOES NOT EXIST.
It needs to be built, hence my MR above.
The MR https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/407
is quite simple - please review/merge, it should take you only 2 mins.
- Otto
Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
Hi! Following up on this topic, I noticed that I can't even manually override the Lintian image version at the moment as the Buster/Bullseye/Bookworm tags don't exist at https://salsa.debian.org/groups/salsa-ci-team/-/container_registries/295 To fix this I filed now https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/407 I am a bit surprised I seem to be the only one running Salsa-CI when preparing stable/LTS uploads, this issue must have been making the pipeline red for everybody building RELEASE=bullseye/buster/stretch. On Sun, 15 Jan 2023 at 13:25, Otto Kekäläinen wrote: > > Hi! > > > > Do you use Salsa-CI (and Lintian v2.115.3) for quality assurance of > > > your packages before uploading to Debian Bullseye or Buster? > > > > Until a few minutes ago, no, I did not test using the latest version > > of Lintian from unstable. Rather, I was using the version in > > buster/bullseye/stretch instead, as that was what was so easily > > available inside the chroot. > > > > However, though, I've just spent a few minutes updating my setup such > > that I will use the version from unstable instead. > > Thanks for the info. Thus I will also use the Lintian 2.115 from > unstable to test all of my uploads. > > This means that I will need to do override updates that add the > brackets (example [1]) to paths in packages that are intended for > Buster/Bullseye because their Lintian overrides are intended for > v2.115. I am fine doing this now that I know that others are also > using latest Lintian for all packaging QA. > > Hopefully current Lintian maintainers will keep backwards > compatibility in mind and not introduce too many changes that make old > packages that were Lintian clean to error too much. > > [1] > https://salsa.debian.org/mariadb-team/galera-3/-/commit/e00e6b67e189ac2c93ba3bc87f4cdf202d8937af
Re: Upload MariaDB 1:10.3.37-0+deb10u1 ?
Hi! On Mon, 26 Dec 2022 at 14:08, Otto Kekäläinen wrote: > > On Mon, 5 Dec 2022 at 01:18, Utkarsh Gupta wrote: > > > > Hi Otto, > > > > On Mon, Dec 5, 2022 at 5:33 AM Otto Kekäläinen wrote: > > > I didn't get a reply to this, so asking again. > > > > I could take care of the upload but if you'd like to do that, please > > feel free to do so and I can take care of the paperwork. One quick > > thing I spotted in the target in d/ch is "buster". Could you please > > change that to "buster-security" instead? > > > > Let me know if you'd like to upload yourself or want me to take care > > of it. Thanks. > > Sorry for the late reply, but 10.3.37 does not include any CVE tracked > security fixes (https://mariadb.com/kb/en/security/) so I guess it > does not warrant a buster-*security* upload. I will just leave it at > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster as > the base for importing 10.3.38 in January/February. Upstream released today 10.3.38 but it does not have CVEs either: - https://mariadb.com/kb/en/mariadb-10-3-38-release-notes/ - https://mariadb.com/kb/en/security/ I can however prepare an upload to Debian LTS if you think it would be justified purely on maintenance/bugs fixed.
Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
Hi! > > Do you use Salsa-CI (and Lintian v2.115.3) for quality assurance of > > your packages before uploading to Debian Bullseye or Buster? > > Until a few minutes ago, no, I did not test using the latest version > of Lintian from unstable. Rather, I was using the version in > buster/bullseye/stretch instead, as that was what was so easily > available inside the chroot. > > However, though, I've just spent a few minutes updating my setup such > that I will use the version from unstable instead. Thanks for the info. Thus I will also use the Lintian 2.115 from unstable to test all of my uploads. This means that I will need to do override updates that add the brackets (example [1]) to paths in packages that are intended for Buster/Bullseye because their Lintian overrides are intended for v2.115. I am fine doing this now that I know that others are also using latest Lintian for all packaging QA. Hopefully current Lintian maintainers will keep backwards compatibility in mind and not introduce too many changes that make old packages that were Lintian clean to error too much. [1] https://salsa.debian.org/mariadb-team/galera-3/-/commit/e00e6b67e189ac2c93ba3bc87f4cdf202d8937af
Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
Hello! I am trying to revive this discussion. I am in particular interested in this: Do you use Salsa-CI (and Lintian v2.115.3) for quality assurance of your packages before uploading to Debian Bullseye or Buster? Did Lintian authors intend that the latest version in Debian Sid would be used to QA packages before upload to _any_ Debian release? On Sun, 20 Nov 2022 at 13:50, Otto Kekäläinen wrote: > > > > I do however have some challenges that some of the build jobs don't > > > honor the RELEASE variable. For example Lintian is run with the latest > > > 2.115 version and not the Bullseye/Buster version, so it leads to > > > failures that are not actual regressions. > > > > Can you briefly clarify what this reference to RELEASE refers to? I > > initially thought it was something specific to MariaDB, but your > > reference to Lintian suggests otherwise. Is it the: > > > > > > https://salsa.debian.org/salsa-ci-team/pipeline#changing-the-debian-release > > > > … variable? > > Yes. > > So for example in > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/457543 > the Lintian job > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/3538211 uses > Lintian v2.115.3 and fails on issues that are not relevant for the > Buster release. > > I could disable the Lintian check, but then I would miss some > potential real issues that I might have overlooked while importing a > new minor maintenance release on the Buster branch. > > I commented this in > https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/347 > as pointed out by Santiago. > > - Otto
Re: Upload MariaDB 1:10.3.37-0+deb10u1 ?
On Mon, 5 Dec 2022 at 01:18, Utkarsh Gupta wrote: > > Hi Otto, > > On Mon, Dec 5, 2022 at 5:33 AM Otto Kekäläinen wrote: > > I didn't get a reply to this, so asking again. > > I could take care of the upload but if you'd like to do that, please > feel free to do so and I can take care of the paperwork. One quick > thing I spotted in the target in d/ch is "buster". Could you please > change that to "buster-security" instead? > > Let me know if you'd like to upload yourself or want me to take care > of it. Thanks. Sorry for the late reply, but 10.3.37 does not include any CVE tracked security fixes (https://mariadb.com/kb/en/security/) so I guess it does not warrant a buster-*security* upload. I will just leave it at https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster as the base for importing 10.3.38 in January/February.
Re: Upload MariaDB 1:10.3.37-0+deb10u1 ?
Hi Emilio! I didn't get a reply to this, so asking again. On Sun, 20 Nov 2022 at 17:57, Otto Kekäläinen wrote: > > Hello Emilio! > > MariaDB 1:10.3.37-0+deb10u1 is ready for upload at > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster > > Do you want to take care of the upload?
Upload MariaDB 1:10.3.37-0+deb10u1 ?
Hello Emilio! MariaDB 1:10.3.37-0+deb10u1 is ready for upload at https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster Do you want to take care of the upload?
Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
> > I do however have some challenges that some of the build jobs don't > > honor the RELEASE variable. For example Lintian is run with the latest > > 2.115 version and not the Bullseye/Buster version, so it leads to > > failures that are not actual regressions. > > Can you briefly clarify what this reference to RELEASE refers to? I > initially thought it was something specific to MariaDB, but your > reference to Lintian suggests otherwise. Is it the: > > https://salsa.debian.org/salsa-ci-team/pipeline#changing-the-debian-release > > … variable? Yes. So for example in https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/457543 the Lintian job https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/3538211 uses Lintian v2.115.3 and fails on issues that are not relevant for the Buster release. I could disable the Lintian check, but then I would miss some potential real issues that I might have overlooked while importing a new minor maintenance release on the Buster branch. I commented this in https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/347 as pointed out by Santiago. - Otto
Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts
Hi! I was wondering how common is it for DDs to use Salsa-CI while doing quality assurance prior to Bullseye and Buster uploads? I have been using Salsa-CI since many years back, and the MariaDB releases in Buster and Bullseye were done during the Salsa-CI era, and I continue to run Salsa-CI for branches bullseye[1] and buster[2] prior to upload. I do however have some challenges that some of the build jobs don't honor the RELEASE variable. For example Lintian is run with the latest 2.115 version and not the Bullseye/Buster version, so it leads to failures that are not actual regressions. Is it worthwhile to push for Salsa-CI to be compatible with stable release maintenance use cases too? - Otto [1] https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bullseye [2] https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster
Upgrades from Stretch to Bullseye and from Buster to Bookworm broken
Hello LTS team! Users of Debian LTS are currently affected by a bug that prevents skipping Debian releases. If skipping a release is not possible in an upgrade, it makes using LTS kind of moot. For discoverability, I posted a summary and workaround steps at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755#62 I hope you find this useful. - Otto
Re: Please push to salsa.debian.org/mariadb-team/mariadb-10.3
Hi Emilio! Please try pushing now. I don't see any of your commits on https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster yet. On Sat, 8 Oct 2022 at 16:08, Otto Kekäläinen wrote: > > > btw, while importing my changes, I have noticed that I have a bunch of extra > > files in my debian/ dir. Which are neither in git, nor in the 10.3.34 buster > > update. Which is weird, because I based my update on upstream + > > 10.3.34-0+deb10u1. After some investigation, I found that the upstream > > tarball > > includes a debian/ dir with those extra files, and the gbp import filter > > removes > > them (but I didn't use gbp but uscan directly). Most of them are harmless, > > because they are for packages that we don't ship (e.g. > > debian/libmariadb3.postinst) but there is one in particular, > > debian/mariadb-server-10.3.triggers, which may be causing [1]. I'm > > investigating, will comment on that MR and if necessary do a deb10u2 upload > > without those files. > > Thanks Emilio for fixing it now! > > Please next time post your upload preparations for review as MRs next > time, so that CI can automatically detect some things, and we humans > maybe help too. The CI has already prevented many faulty changes from > getting into production. > > If I had the powers, I would make git tags the only way to upload, and > force Salsa to accept git tags only on commits that passed CI.. Maybe > we have that for Debian 16 or something.
Re: Please push to salsa.debian.org/mariadb-team/mariadb-10.3
Hi Emilio! On Sat, 8 Oct 2022 at 16:04, Otto Kekäläinen wrote: > > On Fri, 30 Sept 2022 at 04:31, Emilio Pozuelo Monfort > wrote: > > > > On 26/09/2022 05:39, Otto Kekäläinen wrote: > > > Hello Emilio! > > > > > > I see you uploaded: > > > https://tracker.debian.org/news/1362643/accepted-mariadb-103-110336-0deb10u1-source-into-oldstable/ > > > > > > I don't see the commits at > > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster - > > > please push there to avoid getting the versions out of sync and causing > > > unnecessary extra work for future maintenance of the package > > Sure! I am pushing the update package to the repository, but I'm having some > > trouble. Do you know what's going on? > > > > remote: GitLab: You are not allowed to push code to protected branches on > > this > > project. > > To salsa.debian.org:mariadb-team/mariadb-10.3.git > > ! [remote rejected] buster -> buster (pre-receive hook declined) > > ! [remote rejected] upstream -> upstream (pre-receive hook declined) > > ! [remote rejected] upstream/10.3.36 -> upstream/10.3.36 (pre-receive > > hook > > declined) > > error: failed to push some refs to > > 'salsa.debian.org:mariadb-team/mariadb-10.3.git' > > > > I have 'developer' role on salsa for mariadb, looks like I need maintainer > > role > > to be able to push to protected branches. Can you grant me that role? > > Sorry for the delay, did ^ now. Try pushing again. I don't see any of your commits on https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster yet..
Re: Please push to salsa.debian.org/mariadb-team/mariadb-10.3
> btw, while importing my changes, I have noticed that I have a bunch of extra > files in my debian/ dir. Which are neither in git, nor in the 10.3.34 buster > update. Which is weird, because I based my update on upstream + > 10.3.34-0+deb10u1. After some investigation, I found that the upstream tarball > includes a debian/ dir with those extra files, and the gbp import filter > removes > them (but I didn't use gbp but uscan directly). Most of them are harmless, > because they are for packages that we don't ship (e.g. > debian/libmariadb3.postinst) but there is one in particular, > debian/mariadb-server-10.3.triggers, which may be causing [1]. I'm > investigating, will comment on that MR and if necessary do a deb10u2 upload > without those files. Thanks Emilio for fixing it now! Please next time post your upload preparations for review as MRs next time, so that CI can automatically detect some things, and we humans maybe help too. The CI has already prevented many faulty changes from getting into production. If I had the powers, I would make git tags the only way to upload, and force Salsa to accept git tags only on commits that passed CI.. Maybe we have that for Debian 16 or something.
Re: Please push to salsa.debian.org/mariadb-team/mariadb-10.3
On Fri, 30 Sept 2022 at 04:31, Emilio Pozuelo Monfort wrote: > > On 26/09/2022 05:39, Otto Kekäläinen wrote: > > Hello Emilio! > > > > I see you uploaded: > > https://tracker.debian.org/news/1362643/accepted-mariadb-103-110336-0deb10u1-source-into-oldstable/ > > > > I don't see the commits at > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster - > > please push there to avoid getting the versions out of sync and causing > > unnecessary extra work for future maintenance of the package > Sure! I am pushing the update package to the repository, but I'm having some > trouble. Do you know what's going on? > > remote: GitLab: You are not allowed to push code to protected branches on this > project. > To salsa.debian.org:mariadb-team/mariadb-10.3.git > ! [remote rejected] buster -> buster (pre-receive hook declined) > ! [remote rejected] upstream -> upstream (pre-receive hook declined) > ! [remote rejected] upstream/10.3.36 -> upstream/10.3.36 (pre-receive > hook > declined) > error: failed to push some refs to > 'salsa.debian.org:mariadb-team/mariadb-10.3.git' > > I have 'developer' role on salsa for mariadb, looks like I need maintainer > role > to be able to push to protected branches. Can you grant me that role? Sorry for the delay, did ^ now. Try pushing again.
Please push to salsa.debian.org/mariadb-team/mariadb-10.3
Hello Emilio! I see you uploaded: https://tracker.debian.org/news/1362643/accepted-mariadb-103-110336-0deb10u1-source-into-oldstable/ I don't see the commits at https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster - please push there to avoid getting the versions out of sync and causing unnecessary extra work for future maintenance of the package. Thanks! PS. I am also happy to maintain the package in oldstable, but occasionally my uploads don't get accepted/reviewed and I end up wasting time.
Re: MariaDB security vulnerabilities
Hi! On Mon, Feb 14, 2022 at 4:04 AM Markus Koschany wrote: > > Hello, > > Just a heads-up. New CVE have been reported for MariaDB 10.3. It is likely > that > 10.1 in Stretch is affected as well. Otto Kekäläinen (maintainer) is currently > investigating if it is feasible to backport a newer MariaDB version to Stretch > because 10.1 is no longer supported upstream. Do we have any past experiences > how to handle MySQL/MariaDB updates if they are no longer supported? MariaDB 10.6 has so many changes in its build dependencies that making it build on Stretch library versions is probably too much work. Test build log at https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/2480109 MariaDB 10.3 at least builds: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/2498645 However the mariadb-plugin-myrocks installation fails due to missing run-time dependencies: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/2498653 MariaDB 10.3 is also easier as it can use the existing galera-3 package already in Stretch. Upstream support is until spring 2023. I think backporting MariaDB 10.3 might be feasible, but requires work. Is there really a lot of demand? - Otto
Change in libcrypt1 prevents upgrades from Buster to Bookworm
Hello! Are LTS folks aware about the change in libcrypt1 where tt was split out of libc into a separate package? Perl needs /lib/x86_64-linux-gnu/libcrypt.so.1 to run, and when it gets removed Perl immediately stops working, and thus no dpkg command will proceed anymore [1]. As it breaks dpkg, it affects to my understanding *all* upgrades from Stretch to Bookworm, and some upgrades from Bullseye to Bookworm too[2] on packages I maintain. This makes LTS kind of moot, as systems that want to stay on LTS and "skip" at least one release can no longer do so. What is your take here? If the issue is not fixed, then at least LTS should document it well for LTS users? - Otto (I am not on list, please use reply-to-all) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755 [2] https://salsa.debian.org/mariadb-team/galera-4/-/pipelines/300049
Re: Future of MariaDB in stretch-lts (was: Re: CVE-2020-15180: MariaDB)
> But what would be the point? You'd end up with a less-tested version > of 10.3 compared to regular buster and if people need to move from > 10.1 to 10.3, they can just as well upgrade to Buster. > > So, advise people to upgrade for anyone running the -server packages and > keep the client-side tools/libs around? I was just responding to Adam's and Holger's questions. But if telling users to simply upgrade to Buster is an option, then what is naturally the easiest route to take.
Re: Future of MariaDB in stretch-lts (was: Re: CVE-2020-15180: MariaDB)
Hello! > >> During the 10.5 packaging cycle I have tested building backports for > >> every commit (see e.g. > >> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/191851). > >> The galera-4 dependency is already available in > >> stretch-backports-sloppy. If you are interested in backports, that > >> could be a viable option. > > > > how compatible are 10.1 and 10.5? > > buster has 10.3, so if anything, we should upgrade to 10.3. However that's a > major upgrade, so before doing that, we should consider carefully consider > whether we can get 10.1 supported for longer (perhaps with some upstream > help). I could spend a bit of time testing a mariadb-10.3 backport from Buster to Stretch, but in order to do it, can you help me elsewhere? Currently my time is eaten up by mariadb-10.5 which I have not been able to get from unstable -> testing yet due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972564 - Otto
Re: Future of MariaDB in stretch-lts (was: Re: CVE-2020-15180: MariaDB)
On Tue, 3 Nov 2020 at 21:02, Holger Levsen wrote: .. > > What options do we have anyway? Does the LTS team think they should be > > responsible for providing security updates beyond what upstreams do? > > yes, that's what we often do. Not even MariaDB devs always manage to correctly take patches from MySQL X and apply them on MariaDB Y, so I think hand-picking the security fixes from a newer upstream and applying them on MariaDB 10.1 is probably too hard to do well in practice. > > Or are you thinking about providing backports? > > or we do this ;) This could be a feasible solution, but needs work. > > During the 10.5 packaging cycle I have tested building backports for > > every commit (see e.g. > > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/191851). > > The galera-4 dependency is already available in > > stretch-backports-sloppy. If you are interested in backports, that > > could be a viable option. > > how compatible are 10.1 and 10.5? There is no simple answer. MariaDB in general is pretty well backwards compatible, but the jump from 10.1 to 10.5 is several years of progress. As part of the pipeline that builds MariaDB 10.5 for stretch-backports there is also a job that automatically upgrades from Stretch MariaDB 10.1 to Sid MariaDB 10.5 and that works well. We are however missing a Stretch 10.1 -> Stretch-backports 10.5 test job. I'll do one now to get that tested. Thus I started testing in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1137667 This thing would need a lot of careful planning and testing. Unfortunately I don't have bandwidth for that right now, I've already spent way too much time with 10.5 packaging in Sid (and yet have not managed to get it into Testing due to https://bugs.debian.org/972564) and there were also a lot of work with 5.5-10.5 security updates last month, and have now a new 10.5.7 release is up next - all on top of my actual day job - so I can't promise any relevant progress right now, sorry.
Re: Future of MariaDB in stretch-lts (was: Re: CVE-2020-15180: MariaDB)
Hello! I don't have any particular plans. I'll keep updating the package for as long as upstream provides updates. For 10.1 the updates are indeed officially over now: https://mariadb.org/about/#maintenance-policy What options do we have anyway? Does the LTS team think they should be responsible for providing security updates beyond what upstreams do? Or are you thinking about providing backports? During the 10.5 packaging cycle I have tested building backports for every commit (see e.g. https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/191851). The galera-4 dependency is already available in stretch-backports-sloppy. If you are interested in backports, that could be a viable option. To decrease the risk of similar situations in the future (or decrease the time window for it), I am now putting all my effort into having 10.5 in Bullseye so that the official support period is as long as possible by using the latest possible upstream version. - Otto
CVE-2020-15180: MariaDB
Hello Debian LTS team! Regarding CVE-2020-15180 I have prepared updates for Ubuntu Trusty (5.5), Ubuntu Bionic (10.1), Focal (10.3), Groovy (10.3) and Debian Stretch (10.1), Buster (10.3) and Sid (10.5). The Debian and Ubuntu security teams have already processed these and DSA and USN are in the works. Last thing remaining is the coordination with the Debian LTS team about the Stretch update. Is there somebody in the LTS team who would like to review and approve a mariadb-10.1 1:10.1.45-0+debu1 for Stretch? Stretch changes: https://salsa.debian.org/mariadb-team/mariadb-10.1/-/compare/debian%2F10.1.45-0+deb9u1...stretch QA: https://salsa.debian.org/mariadb-team/mariadb-10.1/-/pipelines/185587 Unfortunately I don't have much more info about the security issue itself. The source diff shows some changes to the WSREP-API (Galera cluster code). There will be more info from secur...@mariadb.org at the end of the month as there is an embargo now to allow time for mysql-galera to ship an update. MariaDB and Percona have already released fixes. Release notes for reference: - https://mariadb.com/kb/en/mariadb-1056-release-notes/ - https://mariadb.com/kb/en/mariadb-10325-release-notes/ - https://mariadb.com/kb/en/mariadb-10147-release-notes/ - Otto
Re: CVE-2020-15180: MariaDB
Hello! I just realized Emilio represents the LTS team and he already took care of this. ke 21. lokak. 2020 klo 11.25 Otto Kekäläinen (o...@debian.org) kirjoitti: > > Hello Debian LTS team! > > Regarding CVE-2020-15180 I have prepared updates for Ubuntu Trusty > (5.5), Ubuntu Bionic (10.1), Focal (10.3), Groovy (10.3) and Debian > Stretch (10.1), Buster (10.3) and Sid (10.5). > > The Debian and Ubuntu security teams have already processed these and > DSA and USN are in the works. > > Last thing remaining is the coordination with the Debian LTS team > about the Stretch update. > > Is there somebody in the LTS team who would like to review and approve > a mariadb-10.1 1:10.1.45-0+debu1 for Stretch? > > Stretch changes: > https://salsa.debian.org/mariadb-team/mariadb-10.1/-/compare/debian%2F10.1.45-0+deb9u1...stretch > QA: https://salsa.debian.org/mariadb-team/mariadb-10.1/-/pipelines/185587 > > Unfortunately I don't have much more info about the security issue > itself. The source diff shows some changes to the WSREP-API (Galera > cluster code). There will be more info from secur...@mariadb.org at > the end of the month as there is an embargo now to allow time for > mysql-galera to ship an update. MariaDB and Percona have already > released fixes. > > Release notes for reference: > - https://mariadb.com/kb/en/mariadb-1056-release-notes/ > - https://mariadb.com/kb/en/mariadb-10325-release-notes/ > - https://mariadb.com/kb/en/mariadb-10147-release-notes/ > > > - Otto -- - Otto
MariaDB uploaders: Please use Salsa and Salsa-CI
Hello Emilio and anybody else who might at some point upload MariaDB to jessie-security or stretch-security! Please use as the starting point the latest version in the MariaDB team Salsa repos - mariadb-10.0 branch 'jessie' - mariadb-10.1 branch 'stretch' (from 2020 onwards LTS) I have prepared there Gitlab-CI automation that does not affect the package itself in any way, but does help quite a bit in ensuring that whatever you upload is well tested and unlikely to cause regressions. Do not just checkout the latest version in Jessie or Stretch, but work using the repository instead. Also, please push to the branch when you are done. I am happy to include LTS maintainers in the mariadb-team so you can use the official repository. (Emilio is already there.) Repo and example of pipeline: - https://salsa.debian.org/mariadb-team/mariadb-10.0/pipelines - https://salsa.debian.org/mariadb-team/mariadb-10.1/pipelines Slides on my talk on MariaDB packaging and Salsa-CI/Gitlab-CI use in case you are interested in the longer story: https://www.slideshare.net/ottokekalainen/how-mariadb-packaging-uses-salsaci-to-ensure-smooth-upgrades-and-avoid-regressions - Otto PS. I've done this all assuming the security uploads in this case do allow changes to the debian/gitlab-ci.yml file since it does not cause functional changes to the package itself and is perfectly safe.
Re: MySQL 5.5 EOL before Debian 8 LTS ends
> Thinking about this some more, maybe we could attempt this, backporting > security > fixes from MariaDB 10.1 or forward-porting them from MariaDB 5.5 (still > supported until April 2020). That way we don't force any 10.0 -> 10.1 > migration > on our users (though MySQL 5.5 users will still have to migrate). This will be > more work than backporting new upstream releases, but if we limit ourselves to > security fixes and possibly some minor stability fixes, it may be feasible. I am experimenting at https://salsa.debian.org/mariadb-team/mariadb-10.1/commits/jessie if it is feasible to get 10.1 running on Jessie at all. The good news is that it least builds without any modifications. The bad news is that mariadb-common depends on mysql-common (>= 5.6.25) to ensure /usr/share/mysql-common/configure-symlinks is available. Having and indentical mariadb-10.1 package in Jessie and Stretch would decrease the maintenance burden, but Jessie would also need an updated mysql-common package introduced..
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! to 3. tammik. 2019 klo 3.40 Robie Basak (robie.ba...@canonical.com) kirjoitti: > > Hi Otto and the LTS team, > > On Mon, Dec 31, 2018 at 10:50:34AM +0200, Otto Kekäläinen wrote: > > I think that is *if* makes sense to engineer some automatic upgrade path in > > an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. > > If this is explicitly opted in to by users then I have no objection. > > However since the MySQL -> MariaDB crossgrade is not easily reversible > (MariaDB modifies the on-disk schema/format), I don't think this is a > good idea to do automatically. Users may, on upgrade past Jessie, choose > to continue with MySQL coming from a source that isn't Debian stable > (eg. by using unstable, directly from upstream, or a change of > distribution). Automatically converting their database to not-MySQL > would make that difficult, and would be a violation of the stable > release promise for those users. I think that affected users would quite > rightly be upset about it. You can always cross-migrate via logical database dumps as .sql files instead of in-place binary files. Anyway the big question here is does the LTS team want to go through the hassle of doing a version upgrade in a stable release. I've tested that the current mariadb-10.1 version in Stretch also builds in Jessie as-is (https://salsa.debian.org/mariadb-team/mariadb-10.1/-/jobs), but some work should be invested into properly write gitlab-ci.yml tests and automation to ensure there are a minimal amount of surprises if real systems go though an upgrade. Anyway, as a first step MariaDB 10.1 should be put into jessie-backports so that those who want to opt-in for such a move right now, could do it. Do we have any contributors who would like to help out with this task?
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello Debian LTS team! I think that is *if* makes sense to engineer some automatic upgrade path in an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. Upgrading from MySQL 5.5 and MariaDB 10.0 to MariaDB 10.1 is pretty safe, and the maintenance period of MariaDB 10.1 would match the Debian LTS needs. MariaDB 10.1 is very stable, and already maintained in Stretch anyway. MariaDB 10.1 also has a good track record of being used for a massive MySQL 5.5 -> and MariaDB 10.0 -> upgrades, so it definitely is the least risky of the upgrade options now and in the long term. However, if such a feat is attempted, there should be extensive (and automatic) testing first. In order to prepare that I filed a MR on the Salsa-CI system that jessie would be a supported target for Salsa-CI in the first place.. https://salsa.debian.org/salsa-ci-team/images/merge_requests/26 If any of the Debian LTS members have write permissions to the Salsa-CI-team repos, please merge :)
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! pe 28. jouluk. 2018 klo 9.27 Jan Ingvoldstad (jan-debian-lts-2...@oyet.no) kirjoitti: > > On 2018-12-27 18:51, Lars Tangvald wrote: > > > Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a > > similar sort of risk. > > I don't know what the risk with switching to MariaDB 10.1 would be, but > as a general principle, MariaDB lags behind (the already annoyingly > delayed) Oracle security patches often days, sometimes weeks. Just to set facts clear: most of the Oracle CVE's are fixed in MariaDB releases way before the Oracle releases, some times even 6 months ahead. What happens when the Oracle CVEs are released is to a large degree just an update to the list of CVEs on what version of MariaDB fixed what. Sometimes there for sure are cases when Oracle publishes something first, but it would be very wrong to say that MariaDB is in any way 'annoyingly delayed'. If we take as an example MySQL 5.5.62 released on 2018-10-22, it contained the following CVE fixes: - CVE-2018-3133 - Fixed in MariaDB 5.5.59 released on 2018-01-19 - CVE-2018-3174 - Fixed in MariaDB 5.5.62 released on 2018-10-26 - CVE-2018-3282 - Fixed in MariaDB 5.5.62 released on 2018-10-26 Source: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html https://mariadb.com/kb/en/library/mariadb-5559-release-notes/ https://mariadb.com/kb/en/library/mariadb-5562-release-notes/ https://mariadb.com/kb/en/library/security/ However, the severity if these CVEs vary very much and there are many details that blur what should be used as a relevant argument and what not, so I would not use this as a main factor in the decision. > Based on our experience with a few thousand databases, though, upgrading > from 5.5 to 5.6 is as good as invisible for DB users and software using > MySQL. > > A few users noticed the differences between MySQL 5.5 and MariaDB 10.0 > (5.6-based), nearly no-one noticed the upgrade from MariaDB 10.0 to 10.3. MariaDB has a tradition of honoring backwards compatibility, thus the upgrade from 10.0 to 10.3 should go pretty smooth, but to be safe we should maybe build some gitlab-ci.yml file to test this particular scenario extensively to be safer. Pull requests on https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines are welcome :) > It would be very welcome if upgrade scripts in Debian would substitute > configuration options correctly, with the usual dselect option list of > "compare, keep current, install package maintainer's" versions. Good idea! Would you want to contribute such functionality to the MariaDB preinstall scripts (or even upstream mariadb_upgrade binary)? https://wiki.debian.org/Teams/MySQL/patches https://mariadb.org/get-involved/ > The risk mostly lies in software relying on the removed features listed > in the URL you linked > (https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html#mysql-nutshell-removals). > > As a side note, anyone using MySQL WorkBench with MariaDB 10.x or MySQL > 5.5 will probably be very annoyed about the version warnings. I expect > the current issues with 5.6 compatibility alerts to be fixed. :) This "bug" has been known for years and it does not look like Oracle will fix their product to be any more MariaDB-compatible (https://www.mysql.com/products/workbench/). Only thing here is to either patch it in Debian, or suggest users to migrate to alternatives (https://mariadb.com/kb/en/library/graphical-and-enhanced-clients/).
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! ke 19. jouluk. 2018 klo 18.01 Holger Levsen (hol...@layer-acht.org) kirjoitti: > > Also note that mariadb 10.0 is EOL in three months[2]. > > I think this rules out mariadb 10.0 as a sensible upgrade path here. > (Also, switching from mysql to mariadb in an LTS security upload???) Do we have any stats on how large the Debian 8 installation base is? I guess we could try to push for an extended maintenance or at least security update period for it if there are compelling arguments. Note that the Ubuntu 16.04 LTS release also has MariaDB 10.0.
