Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=10136#c3

Whiteboard: (none) => MGA3TOO has_procedure

Working fine on our production Moodle server at work (Mageia 4 i586).

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA4-32-OK

MGA4 64. Installation went fine but httpd failed to start.

sept. 10 14:10:08 localhost.localdomain httpd[11603]: AH00526: Syntax error on line 32 of /etc/httpd/conf/sites.d/moodle.conf:
sept. 10 14:10:08 localhost.localdomain httpd[11603]: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in...uration
sept. 10 14:10:08 localhost.localdomain systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
sept. 10 14:10:08 localhost.localdomain systemd[1]: Failed to start The Apache HTTP Server.
sept. 10 14:10:08 localhost.localdomain systemd[1]: Unit httpd.service entered failed state.

Solved after installing apache-mod_php manually. Since moodle restarts httpd at the end of installation, maybe this should be added as a Requires?

Apart from that, following the procedure from comment #1, it seems to work well. I created a course and a news and it worked.

CC: (none) => stormi

While mod_php is the most obvious (and certainly easiest) way to run a webapp, it's not the only way, so we don't have such Requires.  Basically you should know to install apache-mod_php if you want to run a webapp, that's the idea.  Also, Moodle doesn't restart httpd, httpd restarts itself due to a filetrigger.

ok, thanks, testing complete MGA4 64 then.

Testing complete mga3 32

Still need an advisory for this one David please.

Followed procedure linked to in comment 1 to install, create a course and then update to the new version. Dropped all tables in moodle database with phpmyadmin then completed the web based installation again with the update.

Whiteboard: MGA3TOO has_procedure MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure mga3-32-ok MGA4-32-OK MGA4-64-OK

Yes, upstream waits a week to release details on the security issues, so we'll have an advisory next week.

Testing complete mga3 64

Whiteboard: MGA3TOO has_procedure mga3-32-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK

Validating. Non-specific advisory uploaded which we can update later.

Could sysadmin please push to 3 & 4 updates

Thanks

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok MGA4-32-OK MGA4-64-OK
Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Note to sysadmins, please hold off on pushing until the advisory is updated (most likely Monday).  Thanks.

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0379.html

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

Details on the security issues fixed have been announced on September 15:
http://openwall.com/lists/oss-security/2014/09/15/1

To fix CVE-2014-4172, we need to update php-pear-CAS to 1.3.3 for Mageia 3 and Mageia 4.  Thomas, would you mind taking care of this?

CC: (none) => thomas
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

in updates_testing

(In reply to Thomas Spuhler from comment #13)
> in updates_testing

Thanks!  It looks like it only got pushed for Mageia 3 though...

(In reply to David Walser from comment #14)
> (In reply to Thomas Spuhler from comment #13)
> > in updates_testing
> 
> Thanks!  It looks like it only got pushed for Mageia 3 though...

Ahh they're both there now.  Thanks again!

Advisory:
========================

Updated moodle and php-pear-CAS packages fix security vulnerabilities:

In Moodle before 2.6.5, users who had not yet posted the required answer in
a Q&A forum in order to access past posts were able to see the name of the
last person who had posted, as other authors are visible in
/mod/forum/view.php before the student has posted their own answer
(CVE-2014-3617).

A flaw in php-pear-CAS before 1.3.3, utilized by Moodle, has been found which
could potentially allow unauthorised access and privilege escalation
(CVE-2014-4172).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3617
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4172
https://moodle.org/mod/forum/discuss.php?d=269590
https://moodle.org/mod/forum/discuss.php?d=269591
https://moodle.org/mod/forum/discuss.php?d=269089
https://docs.moodle.org/dev/Moodle_2.6.5_release_notes
========================

Updated packages in core/updates_testing:
========================
moodle-2.6.5-1.mga3
php-pear-CAS-1.3.3-1.mga3
moodle-2.6.5-1.mga4
php-pear-CAS-1.3.3-1.mga4

from SRPMS:
moodle-2.6.5-1.mga3.src.rpm
php-pear-CAS-1.3.3-1.mga3.src.rpm
moodle-2.6.5-1.mga4.src.rpm
php-pear-CAS-1.3.3-1.mga4.src.rpm

URL: (none) => http://lwn.net/Vulnerabilities/611993/
Whiteboard: MGA3TOO has_procedure feedback => MGA3TOO has_procedure

Working fine on our production Moodle server at work (Mageia 4 i586) with the updated php-pear-CAS.

Note that this stuff is noarch, so just a quick test on either arch on Mageia 3 should be sufficient to validate this.  Thanks.

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA4-32-OK

moodle-2.6.5-1 was already pushed, so just testing it with updated php-pear-CAS. AFAICT if moodle login is OK then php-pear-CAS is OK, but no CAS to directly test it with.

Testing complete php-pear-CAS mga3 32 using moodle.

Whiteboard: MGA3TOO has_procedure MGA4-32-OK => MGA3TOO has_procedure mga3-32-ok MGA4-32-OK

Thanks Claire.  I think we're good to go.  Once the advisory is updated from Comment 16 into SVN, we can validate and ask the sysadmins to push php-pear-CAS and send out a new mail with the updated advisory.

Revalidating. Advisory updated from comment 16.

Could sysadmin please push php-pear-CAS to mga3 & 4. Moodle was pushed previously.

Thanks

Whiteboard: MGA3TOO has_procedure mga3-32-ok MGA4-32-OK => MGA3TOO has_procedure advisory mga3-32-ok MGA4-32-OK
Keywords: (none) => validated_update

We need a separate bug and advisory to handle any further pushes. We cannot reuse the same bug :(

We cannot update an advisory post-push as the advisory emails no longer match the website.

So really r1957 (or part of it) should be reverted and a new advisory created to follow this up with only php-pear-CAS in it.

CC: (none) => mageia

Closing then. Cloned as bug 14139 for php-pear-CAS.

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

Damnit, so this means we *never* sent out a valid advisory for the Moodle update.  That's part of the reason I did re-use this bug, I wanted a proper e-mail sent out.

(In reply to David Walser from comment #24)
> Damnit, so this means we *never* sent out a valid advisory for the Moodle
> update.  That's part of the reason I did re-use this bug, I wanted a proper
> e-mail sent out.

Well, once the advisory has been processed, there isn't much we can do. We can add more information and more links, but fundamentally changing the list of packages etc. is something we shouldn't do as it's misleading to change history like that.

My email contains:



MGASA-2014-0379 - Updated moodle packages fix security vulnerbilities

Publication date: 15 Sep 2014
URL: http://advisories.mageia.org/MGASA-2014-0379.html
Type: security
Affected Mageia releases: 3, 4

Description:
Updated moodle packages fix security vulnerbilities

Further information is unavailable at this time. This advisory will be
updated as details become available.

Please refer to the release notes in the references.

References:
- https://bugs.mageia.org/show_bug.cgi?id=14081
- https://docs.moodle.org/dev/Moodle_2.6.5_release_notes

SRPMS:
- 4/core/moodle-2.6.5-1.mga4
- 3/core/moodle-2.6.5-1.mga3






As it lists the affected SRPMS, we can't really go back and change that in the future.



I created a new bug+advisory for a similar issue (forgotten package) a few weeks back IIRC.

If you really want we could bump the rel of moodle again to have both it and php-pear-CAS in the same update.

Rather not have to test all this again just for administrative purposes.

Just because your tool cannot handle it doesn't mean it's not doable.  We've done this before, when something has gone wrong with an update and we had to address it, and yes we've used the same bug.  One example is missing a tainted package.

As I understand it, advisories can be updated in SVN and that'll be reflected in the advisory on the wiki automatically.  You can also send out a new e-mail.

Basically you can think of this as a package that should have been pushed with the update originally, but it wasn't, and you're pushing it now.  So if the advisory is already updated in SVN, just push the php-pear-CAS package and send out a new e-mail.  It can still be the same MGASA.  And I don't care if you have to work around the tool.

(In reply to David Walser from comment #27)
> Just because your tool cannot handle it doesn't mean it's not doable.

Well, it's not doable to recall and update emails that are already sent!

> We've
> done this before, when something has gone wrong with an update and we had to
> address it, and yes we've used the same bug.  One example is missing a
> tainted package.

I was not aware of this. Seems wrong to me to change history, but if that's the process I'll defer to your expertise/opinions here.

> As I understand it, advisories can be updated in SVN and that'll be
> reflected in the advisory on the wiki automatically.  You can also send out
> a new e-mail.

If an advisory is updated in SVN, then yes, the next time the advisory queue is processed, the website will be updated accordingly, but no new email will be sent.

The advisories system has a single field to track the state "email sent" and any further updates will not trigger a new mail.

If we wanted to implement this, we could add a system that would know when an advisory was last updated and have it trigger a new email (with " [updated]" appended to the subject) and update the email date in the saved state.

This would take some time however. We would have to somehow inject the last-modified date into the .adv files (we cannot rely on filesystem or VCS history hear as a "dump" format that is supported is devoid of filename/filesystem/VCS details), but it's obviously possible with a bit of work.

> Basically you can think of this as a package that should have been pushed
> with the update originally, but it wasn't, and you're pushing it now.  So if
> the advisory is already updated in SVN, just push the php-pear-CAS package
> and send out a new e-mail.  It can still be the same MGASA.  And I don't
> care if you have to work around the tool.

Sadly part of the processing is that it will validate all SRPMs to be moved before running. One of the previous flaws was that it might only partially process an update because the opposite problem - too many packages listed in the .adv file than actually exist! This happened a few times since I've been processing them, hence why I added in the validation - both before the publish stage (assigning of an ID) and before processing the actual move (the server side processing).

Just as the email currently has a single state saved, so to does the "move". We'd have to split out that state to be a per-package state and thus only process the moves that have not yet happened.


Add to this that updating advisories after publish circumvents one of the sanity checks that are done on publish - that the SRPMs exist. All you'd have to do is publish it, then update it with an invalid SRPM and we'd get our selves into a nasty state where any automated processing would fail to process the move.

Obviously all of the above is solvable but it just creates a larger problem space to solve - thus requiring much more complexity in processing. I've already make this process almost fully automated which saves a significant amount of time for sysadm. I'd be happy to look at implementing things as needed, but, to me, the simplest solution here is that we just have a rule whereby if an advisory is found to miss packages, that we issue a new advisory with the appropriate corrections, and add a back reference to the new advisory+bug to the old advisory (i.e. add metadata but never change the fundamental make up of the update!)

Happy to discuss further, but perhaps we should do that elsewhere - perhaps on sysadm ML.

Colin, this is an unusual case that happened because I asked that the original update not be pushed before the advisory was updated, and someone failed to read that and pushed it anyway.  The tool does not need to be updated to handle this one-off case.  We just need to push php-pear-CAS and send an updated e-mail (and get the wiki advisory updated to match the SVN one).  If that has to be done manually, that's fine.

In general, while I suppose it would be kind of nice to send a new e-mail when advisories are updated in SVN (which happens more often than you might thing, with CVE details being added after the fact), it's not necessary, and is part of the reason the e-mails contain a link to the advisory on the wiki, which may get updated later.

In this particular case, the original e-mail that was sent was not what was wanted, so I'd like a fresh corrected e-mail sent out.  Like I said, even though we have re-used bugs to correct problems in the same update in the past, sending a new e-mail still makes this an unusual case.  So, please just handle this one manually and don't worry about updating the tool.

To clarify where we are. The php-pear-CAS stuff was already removed from this advisory and bug 14139 created for that push. This bug was closed :) A separate advisory for php-pear-CAS (14139.adv) is already uploaded so please let's follow through with that instead.

No, I want a proper advisory sent out for CVE-2014-3617.

That shouldn't affect bug 14139 though (php-pear-CAS - CVE-2014-4172) which can be pushed as it is.

Perhaps this could be discussed via other means.