Bug 27410 - nextcloud new security issues CVE-2020-8183 and CVE-2020-8233
Summary: nextcloud new security issues CVE-2020-8183 and CVE-2020-8233
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Backports (show other bugs)
Version: 7
Hardware: All Linux
Priority: Low normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL: https://nextcloud.com/changelog/
Whiteboard: MGA7-32-OK MGA7-64-OK
Keywords: validated_backport
Depends on: 27380 27621
Blocks:
  Show dependency treegraph
 
Reported: 2020-10-13 20:03 CEST by David Walser
Modified: 2020-11-21 13:35 CET (History)
7 users (show)

See Also:
Source RPM: nextcloud-15.0.14-1.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2020-10-13 20:03:27 CEST
openSUSE has issued an advisory on October 11:
https://lists.opensuse.org/opensuse-security-announce/2020-10/msg00020.html

The issues are fixed upstream in 18.0.7 and 19.0.1:
https://nextcloud.com/security/advisory/?id=NC-SA-2020-026
https://nextcloud.com/security/advisory/?id=NC-SA-2020-029

It looks like what we need to do is update the backported nextcloud in Mageia 7 and drop the superfluous nextcloud17 and nextcloud18 packages in Cauldron.
David Walser 2020-10-13 20:03:37 CEST

Priority: Normal => release_blocker

Comment 1 Morgan Leijström 2020-10-14 17:56:43 CEST
(In reply to David Walser from comment #0)
> It looks like what we need to do is update the backported nextcloud in
> Mageia 7 and drop the superfluous nextcloud17 and nextcloud18 packages in
> Cauldron.

Nextcloud 20 is released, so should be in cauldron; - drop other versions.

In mga7 backports replace current 18.x with latest 18, now 18.0.10

And add latest 19, now at 19.0.4

URL: (none) => https://nextcloud.com/changelog/
CC: (none) => fri

Comment 2 Morgan Leijström 2020-10-14 18:01:09 CEST
order should be
new 18
new 19
new 20
remove old 18 & 19
Comment 3 Aurelien Oudelet 2020-10-14 18:44:52 CEST
Hi, thanks for reporting this bug.
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)

Assignee: bugsquad => mageia
Keywords: (none) => Triaged

Comment 4 Marc Krämer 2020-10-19 10:20:51 CEST
someone working on this?

CC: (none) => mageia

Comment 5 David Walser 2020-10-21 04:19:00 CEST
nextcloud-19.0.4-1.mga8 uploaded for Cauldron by Joseph Wang.

Still need to drop nextcloud17 and nextcloud18 from Cauldron and update the mga7 backports package.
Comment 6 Morgan Leijström 2020-10-21 10:56:22 CEST
Thank you Joseph
Joseph Wang is the de facto maintainer.
Not knowing winch of the two email to use, I set both.

Assignee: mageia => joequant
CC: (none) => joequant

Comment 7 Morgan Leijström 2020-10-21 11:32:52 CEST
Input from Joseph: https://ml.mageia.org/l/arc/dev/2020-10/msg00246.html
Comment 8 Joseph Wang 2020-10-22 02:06:56 CEST
I've updated nextcloud 19 in cauldron.

Nextcloud 17 and nextcloud 18 should have already been dropped in cauldron.

I've updated the svn for core/backports.  Need someone to run the build.
Comment 9 Joseph Wang 2020-10-22 02:11:17 CEST
removed nextcloud18 fromm cauldron, that should have been gone long ago.

Also nextcloud20 hasn't been formally released and I'd like to get a formal release before trying to package.
Comment 10 David Walser 2020-10-22 02:40:20 CEST
You should submit the backport update.  There should be documentation on the wiki on how to do it.
Comment 11 David Walser 2020-10-22 04:47:25 CEST
Thanks for submitting that.

nextcloud-18.0.9-1.mga7
nextcloud-mysql-18.0.9-1.mga7
nextcloud-postgresql-18.0.9-1.mga7
nextcloud-sqlite-18.0.9-1.mga7

Note that you have not removed nextcloud17 and nextcloud18 from Cauldron yet.  Removing them from SVN does not make them disappear.  You have to obsolete them (the nextcloud package would be the logical place to do that).  Make sure get any subpackages that are still there.  I see these remaining:
nextcloud17-mysql-17.0.4-6.mga8.noarch.rpm
nextcloud17-postgresql-17.0.4-6.mga8.noarch.rpm
nextcloud17-sqlite-17.0.4-6.mga8.noarch.rpm
nextcloud18-mysql-18.0.5-1.mga8.noarch.rpm
nextcloud18-postgresql-18.0.5-1.mga8.noarch.rpm
nextcloud18-sqlite-18.0.5-1.mga8.noarch.rpm
Comment 12 Joseph Wang 2020-10-22 11:48:17 CEST
I put in a task-obsoletes that should nuke the packages.
Comment 13 David Walser 2020-10-22 12:46:00 CEST
You shouldn't use task-obsolete when there's a logical replacement package to hold the obsoletes.
Comment 14 Joseph Wang 2020-10-22 12:52:23 CEST
nextcloud17 and nextcloud18 were added in cauldron during mageia 8 development, and so I'd like to just nuke all references so that they don't appear in the any new rpm spec files going forward.
Comment 15 David Walser 2020-10-22 12:55:43 CEST
If they were Cauldron-only, then you can remove them from whichever spec file once they are fully removed from the distro tree.
Comment 16 Morgan Leijström 2020-10-25 14:18:18 CET
(In reply to Joseph Wang from comment #9)
> Also nextcloud20 hasn't been formally released and I'd like to get a formal
> release before trying to package.

20.0.0 was released October 3 https://nextcloud.com/changelog/#latest20 .  That said, i think it would be wise to wait for bugfix point release.

Apart from that: users - especially potential new users - of Nextcloud would like the latest major release also on the currently fully supported Mageia.


Wold you say it is safe for users to use the built-in updater for point releases?  If so, we need not ship point release updates.
Comment 17 David Walser 2020-10-25 17:54:54 CET
No, the built-in updater would mess up the package and defeat the purpose of it.  Either we package it or we don't.  (I suppose a possible alternative would be packaging a script that helps set up the upstream distribution of it correctly).
Comment 18 David Walser 2020-10-25 17:55:52 CET
Anyway this is now fixed for Cauldron and the Mageia 7 update is a backports request.  Package list in Comment 11.

Priority: release_blocker => Low
Assignee: joequant => qa-bugs
QA Contact: security => (none)
CC: (none) => joequant
Version: Cauldron => 7
Component: Security => Backports

Comment 19 Morgan Leijström 2020-10-25 18:36:28 CET
Good we are moving :)

Through the years we have mostly for long periods not kept up.

It would be valuable to have it documented in English and CLI commands what need to be done if getting it from upstream.  i.e install prerequisitieas, set up database, unzip https://download.nextcloud.com/server/releases/nextcloud-20.0.0.zip into where, and then...?


Another alternative to packaging it or describing exactly how to install manually, is to guide users to use upstream Docker images. Some small intro text and Mageia specifics in a page in our wiki, and point to https://hub.docker.com/_/nextcloud/
Comment 20 Joseph Wang 2020-10-26 02:39:24 CET
If you want to see what you need to do to get it working, just look at the RPM spec.  It's non-trivial.  The reason I've ended up maintaining the RPM is that I'm maintaining several separate instances of nextcloud in their own docker image, and installing by hand becomes impractical.

The builtin updater works reasonably well with the RPM.  The RPM downloads the package and then sets up the local environment so that things work from the Mageia side.  As long as you update the RPM to something that's newer than the current version, then the updater should work.

In fact the RPM relies on the updater to do most of the work of updating.  The purpose of the RPM is not so much to set up nextcloud but to make the necessary tweaks so that nextcloud fits into the Mageia environment.  There are a huge number of tiny annoying issues (for example, getting the user right).

I've got an nextcloud 20 rpm built, and I'll upload it to testing as soon as I verify that it works locally.
Comment 21 Joseph Wang 2020-10-26 06:00:45 CET
I just did a build of nextcloud19 for mageia 7 backports, and I built nextcloud20 for core/updates_testing in cauldron.
Comment 22 David Walser 2020-10-26 11:33:11 CET
So now we have two sets to push:
nextcloud-18.0.9-1.mga7
nextcloud-mysql-18.0.9-1.mga7
nextcloud-postgresql-18.0.9-1.mga7
nextcloud-sqlite-18.0.9-1.mga7
nextcloud-19.0.4-1.mga7
nextcloud-mysql-19.0.4-1.mga7
nextcloud-postgresql-19.0.4-1.mga7
nextcloud-sqlite-19.0.4-1.mga7
Comment 23 Morgan Leijström 2020-10-26 11:37:50 CET
Thank you for the explanations Joseph :)

So how do the user set it up using Mageia rpm - is https://wiki.mageia.org/en/OwnCloud#Installing and £Configuration still correct (except versions) ? 

(Gathering bits to make a new page)
Comment 24 Brian Rockwell 2020-10-29 18:29:18 CET
$ uname -a
Linux linux.local 5.7.19-desktop-3.mga7 #1 SMP Sun Oct 18 15:46:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I installed postgres 11 first.

I did not see nextcloud 18, but was able to pick Nextcloud 19.

The following 44 packages are going to be installed:

- apache-2.4.46-1.mga7.x86_64
- apache-mod_php-7.4.12-1.mga7.x86_64
- lib64apr-util1_0-1.6.1-3.mga7.x86_64
- lib64apr1_0-1.7.0-1.mga7.x86_64
- lib64php_common7-7.4.12-1.mga7.x86_64
- lib64zip5-1.5.2-1.mga7.x86_64
- nextcloud-19.0.4-1.mga7.noarch
- nextcloud-mysql-19.0.4-1.mga7.noarch
- nextcloud-postgresql-19.0.4-1.mga7.noarch
- nextcloud-sqlite-19.0.4-1.mga7.noarch
- php-cgi-7.4.12-1.mga7.x86_64
- php-ctype-7.4.12-1.mga7.x86_64
- php-curl-7.4.12-1.mga7.x86_64
- php-dom-7.4.12-1.mga7.x86_64
- php-exif-7.4.12-1.mga7.x86_64
- php-fileinfo-7.4.12-1.mga7.x86_64
- php-filter-7.4.12-1.mga7.x86_64
- php-ftp-7.4.12-1.mga7.x86_64
- php-gd-7.4.12-1.mga7.x86_64
- php-gettext-7.4.12-1.mga7.x86_64
- php-iconv-7.4.12-1.mga7.x86_64
- php-imagick-3.4.4-10.mga7.x86_64
- php-ini-7.4.12-1.mga7.x86_64
- php-intl-7.4.12-1.mga7.x86_64
- php-json-7.4.12-1.mga7.x86_64
- php-ldap-7.4.12-1.mga7.x86_64
- php-mbstring-7.4.12-1.mga7.x86_64
- php-mysqlnd-7.4.12-1.mga7.x86_64
- php-openssl-7.4.12-1.mga7.x86_64
- php-pcntl-7.4.12-1.mga7.x86_64
- php-pdo-7.4.12-1.mga7.x86_64
- php-pdo_mysql-7.4.12-1.mga7.x86_64
- php-pdo_pgsql-7.4.12-1.mga7.x86_64
- php-pdo_sqlite-7.4.12-1.mga7.x86_64
- php-posix-7.4.12-1.mga7.x86_64
- php-session-7.4.12-1.mga7.x86_64
- php-sysvsem-7.4.12-1.mga7.x86_64
- php-sysvshm-7.4.12-1.mga7.x86_64
- php-tokenizer-7.4.12-1.mga7.x86_64
- php-xmlreader-7.4.12-1.mga7.x86_64
- php-xmlwriter-7.4.12-1.mga7.x86_64
- php-zip-7.4.12-1.mga7.x86_64
- php-zlib-7.4.12-1.mga7.x86_64
- webserver-base-2.0-12.mga7.noarch

293MB of additional disk space will be used.

73MB of packages will be retrieved.

Is it ok to continue?


-----

This is a new install of Nextcloud on a VM

- go into services and start postgres

before you start httpd

in a terminal as root go to /etc/nextcloud
# touch CAN_INSTALL

logout of terminal

- start HTTPD

in your favorite local browser go to 127.0.0.1/nextcloud

it will lead you through the set up process.  In my case I chose default document path, but chose postgres as my database.

It went through the process and about 15 minutes later I had a working Nextcloud server.  Be aware to make this fully networkable you have to do firewall, set up acceptible IP's in the configuration, etc.

I set up a new user after the initial admin install and was able to save files.  I did not try the new apps.

Works for me.

CC: (none) => brtians1

Comment 25 Brian Rockwell 2020-10-29 18:46:50 CET
fyi - I tried some of the apps including talk.  Without a full group they appear to be working.

How do I expose NextCloud 18 for testing.  I guess I need to test upgrade as well.
Comment 26 Dave Hodgins 2020-10-29 19:30:32 CET
https://mirror.math.princeton.edu/pub/mageia/distrib/7.1/SRPMS/core/backports/

Nextcloud 16, 17 and 18 were added while Mageia 7 was cauldron, before m7
version freeze.

CC: (none) => davidwhodgins

Comment 27 Morgan Leijström 2020-10-29 21:10:09 CET
Good Brian :)
It seems a nextcloud wiki page can be simpler than our owncloud wiki page.

Mageia 7 released with Nextcloud 15 in core.
Not a development version freeze issue, but due to the use case we dont ship updates of NC like normal updates.

The reason we put updates to Nextcloud in backports is because we do not want  updates of NC to go into users system as easy as other updates, because they may not want to update immediately due to i.e they may need to continue using apps that are not yet updated by their developers to be compatible with the new version of NextCloud.

We ought to keep updating Nextcloud in backports continously for security reasons at least (point releases), and if possible upgrade to next major not too late because some users want new functionality.  When we release a new Mageia, the former release should have at least all major versions prior to the one in the new Mageia release, but it never hurt to have latest major release in any still supported Mageia. (i.e Nextcloud 20 in Mageia 7 soonish)
Comment 28 Brian Rockwell 2020-10-30 03:53:42 CET
Well that was an adventure.

Couldn't get nextcloud 15 installed due to previous upgrade to php on all of my VM instances.  Nextcloud 15 won't run new php out side of supported version.

So went to my nextcloud server running 15 and tried going straight to 19 and php latest.  that didn't go well.

So stepped it back and tried 16 - no luck with php
17 - no luck with php
18 - worked fine and pulled in old data fine, though by then I had to induce NextCloud to do an install and then it upgraded.  

Nextcloud-18.0.9-1.mga7 has been tested on i586 machine at current MGA7.

So, it appears there is an upgrade path to retain users and data with 18.0.9.

Giving this my Ok

<<more>>
Morgan, yes it isn't overly complicated, but does have some gotchas and can be confusing.  This isn't a beginner tool.  

The wiki page is pretty accurate, with a name change to NextCloud instead of OwnCloud it is still a good page.

Anybody else want to test before I okay this?
Comment 29 David Walser 2020-10-30 04:02:21 CET
Not relevant to this update, but based on your report, I'm curious; is it *really* neccessary to upgrade through every major version, thus forcing us to all the craziness we do with this package, or can you actually skip versions and upgrade safely?
Comment 30 Brian Rockwell 2020-10-30 04:05:16 CET
Sadly yes - in this case I lucked out.  But in past I had to go through each version.
Comment 31 Morgan Leijström 2020-10-30 07:13:59 CET
Well tried and progressed, Brian.

Of course there is a myriad of things we could test, but this is a server known to have wrinkles, and as you say is no beginner tool.  Is seems weh have made it reasonable simple anyway, and it works.

I think we can OK it.

Just one question, did you use MariaDB in any test?
That seem to be the most commonly used alternative.

-----

Yes upstream always advise strongly against skipping any major.  It have been like that always.

PHP is one such thing, it may be that installed version N do not support new PHP, and version N+2 do not support old PHP, so in that case you need to upgrade Nextcloud to N+1, then PHP, then Nextcloud to N+2.  Just as an example.  Historically you have also had to do some fiddling i.e with database.  See my old notes https://wiki.mageia.org/en/OwnCloud#General_upgrading_cautions

Top that up with some users wanting the latest major, and some can not upgrade to latest major for a while. So ideally we should even do point releases due to security (and bug) fixes of not only latest but a bit elder majors too...

( That may even be a reason we should ideally ship at least two majors with any new Mageia release...  but let us neglect that...) 


I was asking earlier in this thread if we could say it is safe for users to do point upgrades using the built-in update function of Nextcloud. Then we at least only need to package one point version of any major per Mageia release, plus users can more quickly upgrade (we have often been very late).
Comment 32 David Walser 2020-10-30 12:22:02 CET
Morgan's notes continue to support the idea that it shouldn't be packaged at all.  Oh well.  I think you can OK this one.
Comment 33 Joseph Wang 2020-10-30 13:55:17 CET
> I was asking earlier in this thread if we could say it is safe for users to do > point upgrades using the built-in update function of Nextcloud. Then we at 
> least only need to package one point version of any major per Mageia release,
> plus users can more quickly upgrade (we have often been very late).

I think that's the intention.  Once you have installed nextcloud, you can use the autoupdate to keep the thing updated to the latest point release.

The RPM's are just a mechanism to unpack the files and then make them compatible with Mageia's setup.  Once you've installed the RPM, you can use the auto-update.  The only situation where the autoupdate would break is if you install an RPM which has a lower version than the version currently installed.

The only reason for maintaining multiple versions in backports is that nextcloud does not support jumping major versions.
Comment 34 Joseph Wang 2020-10-30 13:56:46 CET
As far as updating the wiki instructions.  I'd suggest installing the latest urpmi version of nextcloud from scratch, and then removing all of the instructions that turn out to be not necessary.

Also let me know if there is anything that can be automated that isn't.
Comment 35 Joseph Wang 2020-10-30 13:57:58 CET
Something that one might want to mention in the wiki is that there is a docker image joequant/nextcloud that's a docker container with nextcloud installed with mageia.
Comment 36 Brian Rockwell 2020-10-30 14:23:14 CET
Morgan,
I'll test MariaDB later today and then will confirm.

For some reason a Brooks and Dunn song comes to mind "My Maria".
Comment 37 David Walser 2020-10-30 16:09:01 CET
(In reply to Joseph Wang from comment #33)
> > I was asking earlier in this thread if we could say it is safe for users to do > point upgrades using the built-in update function of Nextcloud. Then we at 
> > least only need to package one point version of any major per Mageia release,
> > plus users can more quickly upgrade (we have often been very late).
> 
> I think that's the intention.  Once you have installed nextcloud, you can
> use the autoupdate to keep the thing updated to the latest point release.
> 
> The RPM's are just a mechanism to unpack the files and then make them
> compatible with Mageia's setup.  Once you've installed the RPM, you can use
> the auto-update.  The only situation where the autoupdate would break is if
> you install an RPM which has a lower version than the version currently
> installed.
> 
> The only reason for maintaining multiple versions in backports is that
> nextcloud does not support jumping major versions.

That doesn't quite make sense.  If we are packaging nextcloud itself, then an auto-updater would replace packaged files, and you shouldn't do that.

As far as a package to help unpack the upstream tarball and get things in the right locations, with correct ownership and permissions, that sounds like a better thing to package, but then you wouldn't be packaging nextcloud itself, so you could use the auto-updater.  In that case though, our package wouldn't need to be versioned with a particular nextcloud version, it would only need to be updated if the upstream distribution changed substantially, and it wouldn't require near as much maintenance or all of this backports nonsense.
Comment 38 Brian Rockwell 2020-10-30 18:22:38 CET
I've seen the nextcloud Client give notice for new version.

I've never seen that on the server.
Comment 39 Morgan Leijström 2020-10-30 19:16:11 CET
Yes once it is verified it works with MariaDB, IMO we can ship in mga7 backports... both 18.0.9 and 19.0.4 right ?



(In reply to Joseph Wang from comment #33)
> I think that's the intention.  Once you have installed nextcloud, you can
> use the autoupdate to keep the thing updated to the latest point release.

That is great!  Then 18 and 19 need not to be packaged in coming point versions for mga7 :)


> The RPM's are just a mechanism to unpack the files and then make them
> compatible with Mageia's setup.  Once you've installed the RPM, you can use
> the auto-update.

What is different when there is a new major version?
IMO the Mageia user (nextcloud admin) should check upstream documentation and release notes if there are special procedures to do, like checking allowed PHP versions, database touchup, whatever - before commencing major updates anyways.



(In reply to Joseph Wang from comment #35)
> docker image joequant/nextcloud that's a docker container with nextcloud
> installed with mageia.

Worth listing among other tips :)


(In reply to Joseph Wang from comment #34)
> As far as updating the wiki instructions.  I'd suggest installing the latest
> urpmi version of nextcloud from scratch, and then removing all of the
> instructions that turn out to be not necessary.

Sounds like a plan :)  ( Myself is very low on time though. Maybe later if noone have done it by then)


> Also let me know if there is anything that can be automated that isn't.
:)
Comment 40 Morgan Leijström 2020-10-30 19:19:47 CET
(In reply to Brian Rockwell from comment #38)
> I've seen the nextcloud Client give notice for new version.
> 
> I've never seen that on the server.

Surf log in into the server, and there is a bell icon close to top right corner.
It have a red dot if any update is available, click it and a dropdown list any available server and app updates.

On my android phone, the nextcloud client pops up such messages about nextcloud server and also app uppgrades, but the Mageia client do not (but its interface really seem like a work in progress, so it may in alter versions...)
Comment 41 Morgan Leijström 2020-10-30 23:06:24 CET
One question.
When updating to a newer Mageia package of Nextcloud, are we sure user customisations are kept (example: no configuration files overwritten with default)


----


For wiki page, a link to the Mageia nextcloud package spec file and some hint how to read it, so an interested advanced user/admin can understand what it does, and know where to change things if needed. 


----


Talking of scripts...

If we instead package only an install script that downloads nextcloud, unpack it and fixes things so it is suitable for Mageia...

Such package could be on normal updates, updated any time, and started by the user when he want.

That script could ask user (or take parameter) of which version user wants, it may well not be the latest major version user need to run.  And also optionally reset some configuration, but by default not overwrite users customisations.
Comment 42 Morgan Leijström 2020-10-31 00:00:49 CET
(In reply to Morgan Leijström from comment #41)
> For wiki page, a link to the Mageia nextcloud package spec file

http://svnweb.mageia.org/packages/backports/7/nextcloud/current/SPECS/nextcloud.spec
Comment 43 Morgan Leijström 2020-10-31 00:05:58 CET
(In reply to Joseph Wang from comment #33)
> Once you have installed nextcloud, you can
> use the autoupdate to keep the thing updated to the latest point release.

From latest spec, it seem we remove auto updater:


110 	# drop upstream update notification app
111 	rm -rf apps/updatenotification
112 	# also remove the actual updater
113 	rm -rf updater
Comment 44 David Walser 2020-10-31 00:07:26 CET
Which is as it should be if the package packages the nextcloud files themselves.
Comment 45 Brian Rockwell 2020-10-31 01:51:49 CET
$ uname -a
Linux linux.local 5.7.19-desktop-3.mga7 #1 SMP Sun Oct 18 15:46:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Installed MariaDB

then followed up with Nextcloud

To satisfy dependencies, the following package(s) also need to be installed:

- apache-2.4.46-1.mga7.x86_64
- apache-mod_php-7.4.12-1.mga7.x86_64
- lib64apr-util1_0-1.6.1-3.mga7.x86_64
- lib64php_common7-7.4.12-1.mga7.x86_64
- lib64zip5-1.5.2-1.mga7.x86_64
- nextcloud-mysql-19.0.4-1.mga7.noarch
- php-cgi-7.4.12-1.mga7.x86_64
- php-ctype-7.4.12-1.mga7.x86_64
- php-curl-7.4.12-1.mga7.x86_64
- php-dom-7.4.12-1.mga7.x86_64
- php-exif-7.4.12-1.mga7.x86_64
- php-fileinfo-7.4.12-1.mga7.x86_64
- php-filter-7.4.12-1.mga7.x86_64
- php-ftp-7.4.12-1.mga7.x86_64
- php-gd-7.4.12-1.mga7.x86_64
- php-gettext-7.4.12-1.mga7.x86_64
- php-iconv-7.4.12-1.mga7.x86_64
- php-imagick-3.4.4-10.mga7.x86_64
- php-ini-7.4.12-1.mga7.x86_64
- php-intl-7.4.12-1.mga7.x86_64
- php-json-7.4.12-1.mga7.x86_64
- php-ldap-7.4.12-1.mga7.x86_64
- php-mbstring-7.4.12-1.mga7.x86_64
- php-mysqlnd-7.4.12-1.mga7.x86_64
- php-openssl-7.4.12-1.mga7.x86_64
- php-pcntl-7.4.12-1.mga7.x86_64
- php-pdo-7.4.12-1.mga7.x86_64
- php-pdo_mysql-7.4.12-1.mga7.x86_64
- php-posix-7.4.12-1.mga7.x86_64
- php-session-7.4.12-1.mga7.x86_64
- php-sysvsem-7.4.12-1.mga7.x86_64
- php-sysvshm-7.4.12-1.mga7.x86_64
- php-tokenizer-7.4.12-1.mga7.x86_64
- php-xmlreader-7.4.12-1.mga7.x86_64
- php-xmlwriter-7.4.12-1.mga7.x86_64
- php-zip-7.4.12-1.mga7.x86_64
- php-zlib-7.4.12-1.mga7.x86_64
- webserver-base-2.0-12.mga7.noarch

292MB of additional disk space will be used.

This was a new build on a VM so followed steps as I did before.

Able to add users, add documents and run tools built in.  Working as designed from what I can tell.

Giving it the OK

Whiteboard: (none) => MGA7-32-OK MGA7-64-OK

Comment 46 Thomas Andrews 2020-11-01 16:41:18 CET
Lots of discussion here that's WAY above my pay grade, but based on Brian's successful tests I'm going to validate, anyway. 

Please, if now appropriate, could someone in the know remove the "triaged" keyword?

CC: (none) => andrewsfarm
Keywords: (none) => validated_backport

Comment 47 Morgan Leijström 2020-11-01 20:05:28 CET
Yes we are far beyond triage :)

Lets continue provide nextcloud frequent update
-OR-
Make it easy to manually/autoupdate

Keywords: Triaged => (none)

Comment 48 Morgan Leijström 2020-11-04 07:55:38 CET
First point release of 20.0.1 is out, so probably most important bugs in 20.x fixedreleased, so time to work on getting it in mga7 (and 8) if we are going to package all versions users want.



If we are good at pushing updates it is natural that the version in next Mageia core repository will be lower at least in point release than the version in an updated elder Mageia, due to the time from version freeze until release of Mageia.

Will the upgrade of Mageia then keep the newer Nextcloud of mga7 intact, and not try changing to the one in mga8?


Example: we keep updating Nextcloud in Mageia 7 so it is at say 20.0.7, and Mageia 8 will hold 20.0.2



Of course Mageia 8 can at that point hold latest release in backports, but backports is not usually enabled during upgrade.
Comment 49 David Walser 2020-11-04 12:43:38 CET
The only point of the packages in backports is upgrade stepping stones, so if mga8 ships with 20, mga7 only needs up through 19.
Comment 50 Morgan Leijström 2020-11-04 16:24:28 CET
That mean we aim to never have the latst major as update/backport.

So to keep up with nextcloud releases, Mageia packages is not the option.

Thus we need wiki instructions and/or install script how to install Nextcloud manually from upstream.
Comment 51 Morgan Leijström 2020-11-05 20:36:47 CET
(In reply to David Walser from comment #49)
> The only point of the packages in backports is upgrade stepping stones

We simply can not do like that because Mageia versions last much longer than several Nextcloud main versions takes to rot  :) 

Mageia 7 released with NC 15 in core.
Version 15 is now unsupported.
So is version 16.
And 17 too!
Users should now be at an updated point release of at least major 17.

We should at least provide supported versions if we at all care to package it, just to not be ashamed.

If we also want to keep users using it we should update the major version to at least one major below latest.
 - like we are doing now :)


To be very attractive we supply bleeding latest major too (now 20).

To be kind to users that for some compatibility reason can not upgrade yet we should either provide point updates for all upstreams supported major, OR suggest to users to do point release updates using the built in updater (and make sure it typically works)

I believe - correct me if i am wrong - that point release updates do not break compatibility with version dependencies (PHP, apache...).

If users thus can update point releases themselves, we are offloaded to only supply major versions.


---

Or as an alternative to all above: good wiki about installing and updating from upstream and maybe helpful script.
Comment 52 David Walser 2020-11-05 22:59:52 CET
We do provide the latest Nextcloud branch, in the newest stable Mageia at the time of its release.  The backports ones are meant to give you an upgrade path to the next version of Mageia.  That's all.
Comment 53 Morgan Leijström 2020-11-06 00:30:21 CET
1) Why delay major releases, there is still the same number to do.

2) If users can update point releases, we save time on not doing them.

We could put that time on other packages. (Or more work on Nextcloud, i.e have both 19 and 20 in mga8 for them who can not utilise NC20 yet)
Comment 54 Morgan Leijström 2020-11-06 10:13:35 CET
We have not yet shipped a client version compatible with server 19...

Depends on: (none) => 27380

Comment 55 Morgan Leijström 2020-11-06 10:22:41 CET
To see metered general adoption of version updates see fourth diagram at https://ncpw.mdns.eu/
Comment 56 Morgan Leijström 2020-11-16 12:00:12 CET
Hint on 20.0.1: Using a hired install, I realised they forgot to include a fix, so if you package it, replace OC_Helper.php with the one in git.

https://help.nextcloud.com/t/error-undefined-offset-3-at-var-www-nextcloud-lib-private-legacy-oc-helper-php-548/96265/10

https://github.com/nextcloud/server/issues/23595
Comment 57 Joseph Wang 2020-11-16 13:57:21 CET
added the oc_helper patch
Morgan Leijström 2020-11-17 17:32:27 CET

Depends on: (none) => 27621

Comment 58 Morgan Leijström 2020-11-19 10:48:05 CET
Client 3.0.3 is pushed, so server 19 can be pushed to mga7.

* We only lack our advisory *  Or not needed?
Comment 59 David Walser 2020-11-19 13:42:22 CET
Not needed for backports, but they have to be moved manually.  The updates script doesn't handle them.
Comment 60 Thomas Backlund 2020-11-21 13:35:43 CET
moved

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.