This should be fixed in Cauldron with the upgrade of the rt package to 4.2.12. It should still be fixed in Mageia 5, where upgrading it to the new version is not really an option due to the new dependencies.

CC: (none) => shlomif
Version: Cauldron => 5
Whiteboard: MGA5TOO, MGA4TOO => (none)

I'll give you one more week to do that, if no progress I'll drop it. No one seems to care about it anyway..

@Sander:

rt is for some days fixed on Cauldron by Shlomi with release 4.2.12 see comment 1

CC: (none) => geiger.david68210

(In reply to David GEIGER from comment #3)
> @Sander:
> 
> rt is for some days fixed on Cauldron by Shlomi with release 4.2.12 see
> comment 1

Not in Mageia 5, and this package has been abandoned in Mageia for several years.  Granted it's partly my fault for not realizing that request-tracker == rt sooner, but this package has had no maintainer, and it's quite clear that it should be dropped, as I said at the beginning of this bug.

Dropped from cauldron.

"The version we have is only affected by CVE-2015-5475, not CVE-2015-6506."

"This should be fixed in Cauldron with the upgrade of the rt package to 4.2.12. It should still be fixed in Mageia 5, where upgrading it to the new version is not really an option due to the new dependencies."

However, rt 4.0.24 fixed CVE-2015-5475, and it should have been easy to upgrade mga5 to this version (with no additional dependencies).

https://bestpractical.com/release-notes/rt/4.0.24

"Granted it's partly my fault for not realizing that request-tracker == rt sooner, but this package has had no maintainer"

And this probably also resulted in people interested in the package not seeing new versions tracked on check.mageia.org, but the upstream source name is 'rt'.

However, this seems a very feeble reason to drop the package and not provide updates mga5.

I would be willing to build packages for updates_testing for mga5 and test, but only if we can have rt back in cauldron.

(I had already had an rt 4.2.x package built ready to commit before this bug was logged, but hadn't had a chance to test it).

I shouldn't have to negotiate with you to provide a security update to an existing package in a stable release.  If you can do it, do it.  If we can count on you to continue to maintain the package in the future and take care of future security updates as well, feel free to revive it in Cauldron.  Just don't revive it and expect someone else to take care of it.

Another Debian advisory for this misnamed package:
https://www.debian.org/security/2017/dsa-3882

Fedora advisory for this from August 3:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/6TJA64LR2HQCCZ5PJKDMVQSNZGFMAZHE/

Upstream advisory from June 15 notes that these issues are fixed in 4.0.25:
https://forum.bestpractical.com/t/security-vulnerabilities-in-rt-2017-06-15/32016

pushed in updates_testing for mageia 5:

src.rpm:
        rt-4.0.25-1.mga5
        perl-Encode-2.640.0-1.mga5

CC: (none) => mageia
Assignee: bgmilne => qa-bugs

The package's first update in 4.5 years!  :D  Note that 4.0.x is EOL.

Advisory to come later.

References:
http://lists.bestpractical.com/pipermail/rt-announce/2013-May/000226.html
http://lists.bestpractical.com/pipermail/rt-announce/2015-February/000273.html
http://lists.bestpractical.com/pipermail/rt-announce/2015-August/000279.html
http://lists.bestpractical.com/pipermail/rt-announce/2017-June/000297.html

perl-Encode-2.640.0-1.mga5
rt-4.0.25-1.mga5
rt-mailgate-4.0.25-1.mga5

from SRPMS:
perl-Encode-2.640.0-1.mga5.src.rpm
rt-4.0.25-1.mga5.src.rpm

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

Updated rt packages fix security vulnerabilities:

RT 4.0.0 and above are vulnerable to a limited privilege escalation leading to
unauthorized modification of ticket data.  The DeleteTicket right and any
custom lifecycle transition rights may be bypassed by any user with
ModifyTicket (CVE-2012-4733).

RT 3.8.0 and above include a version of bin/rt that uses semi-predictable
names when creating tempfiles.  This could possibly be exploited by a
malicious user to overwrite files with permissions of the user running bin/rt
(CVE-2013-3368).

RT 3.8.0 and above allow calling of arbitrary Mason components (without
control of arguments) for users who can see administration pages.  This could
be used by a malicious user to run private components which may have negative
side-effects (CVE-2013-3369).

RT 3.8.0 and above allow direct requests to private callback components.
Though no callback components ship with RT, this could be used to exploit an
extension or local callback which uses the arguments passed to it insecurely
(CVE-2013-3370).

RT 3.8.3 and above are vulnerable to cross-site scripting (XSS) via attachment
filenames.  The vector is difficult to exploit due to parsing requirements.
Additionally, RT 4.0.0 and above are vulnerable to XSS via maliciously-crafted
"URLs" in ticket content when RT's "MakeClicky" feature is configured
(CVE-2013-3371).

RT 3.8.0 and above are vulnerable to an HTTP header injection limited to the
value of the Content-Disposition header.  Injection of other arbitrary
response headers is not possible.  Some (especially older) browsers may allow
multiple Content-Disposition values which could lead to XSS.  Newer browsers
contain security measures to prevent this (CVE-2013-3372).

RT 3.8.0 and above are vulnerable to a MIME header injection in outgoing email
generated by RT (CVE-2013-3373).

RT 3.8.0 and above are vulnerable to limited session re-use when using the
file-based session store, Apache::Session::File.  RT's default session
configuration only uses Apache::Session::File for Oracle (CVE-2013-3374).

RT 3.0.0 and above, if running on Perl 5.14.0 or higher, are vulnerable to a
remote denial-of-service via the email gateway; any installation which accepts
mail from untrusted sources is vulnerable, regardless of the permissions
configuration inside RT.  This denial-of-service may encompass both CPU and
disk usage, depending on RT's logging configuration (CVE-2014-9472).

RT 3.8.8 and above are vulnerable to an information disclosure attack which
may reveal RSS feeds URLs, and thus ticket data (CVE-2015-1165).

RSS feed URLs can also be leveraged to perform session hijacking, allowing a
user with the URL to log in as the user that created the feed (CVE-2015-1464).

RT 4.0.0 and above are vulnerable to a cross-site scripting (XSS) attack via
the user and group rights management pages (CVE-2015-5475).

RT 4.2.0 and above are vulnerable to a cross-site scripting (XSS) attack
via the cryptography interface.  This vulnerability could allow an attacker
with a carefully-crafted key to inject JavaScript into RT's user interface.
Installations which use neither GnuPG nor S/MIME are unaffected.

RT 4.0.0 and above are vulnerable to an information leak of cross-site request
forgery (CSRF) verification tokens if a user visits a specific URL crafted by
an attacker (CVE-2017-5943).

RT 4.0.0 and above are vulnerable to a cross-site scripting (XSS) attack if an
attacker uploads a malicious file with a certain content type. Installations
which use the AlwaysDownloadAttachments config setting are unaffected. This
fix addresses all existant and future uploaded attachments (CVE-2016-6127).

RT 4.0.0 and above are vulnerable to timing side-channel attacks for user
passwords. By carefully measuring millions or billions of login attempts, an
attacker could crack a user's password even over the internet. RT now uses a
constant-time comparison algorithm for secrets to thwart such attacks
(CVE-2017-5361).

RT's ExternalAuth feature is vulnerable to a similar timing side-channel
attack. Both RT 4.0/4.2 with the widely-deployed RT::Authen::ExternalAuth
extension, as well as the core ExternalAuth feature in RT 4.4 are vulnerable.
Installations which don't use ExternalAuth, or which use ExternalAuth for
LDAP/ActiveDirectory authentication, or which use ExternalAuth for
cookie-based authentication, are unaffected. Only ExternalAuth in DBI
(database) mode is vulnerable.

RT 4.0.0 and above are potentially vulnerable to a remote code execution
attack in the dashboard subscription interface. A privileged attacker can
cause unexpected code to be executed through carefully-crafted saved search
names. Though we have not been able to demonstrate an actual attack owing to
other defenses in place, it could be possible (CVE-2017-5944).

RT 4.0.0 and above have misleading documentation which could reduce system
security. The RestrictLoginReferrer config setting (which has security
implications) was inconsistent with its implementation, which checked for a
slightly different variable name.

Note that any custom email templates should be updated to ensure that values
interpolated into mail headers do not contain newlines, which will ensure
that they themselves are not vulnerable to a similar issue to CVE-2013-3373.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4733
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3368
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3369
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3370
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3371
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3372
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3373
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3374
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9472
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1165
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1464
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5475
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5943
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6127
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5361
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5944
http://lists.bestpractical.com/pipermail/rt-announce/2013-May/000226.html
http://lists.bestpractical.com/pipermail/rt-announce/2015-February/000273.html
http://lists.bestpractical.com/pipermail/rt-announce/2015-August/000279.html
http://lists.bestpractical.com/pipermail/rt-announce/2017-June/000297.html

Background
----------
No previous updates, apparently (the Bugzilla link stuck).
 $ urpmq -i rt
...
Summary     : Request tracker
Description :
RT is an enterprise-grade ticketing system which enables a group of people
to intelligently and efficiently manage tasks, issues, and requests submitted
by a community of users.
 $ urpmq -l rt | grep /bin/
 /usr/bin/rt
 /usr/bin/rt-crontool
plus loads of pages (perhaps invoked from the program) in:
 /usr/share/rt/html/

CC: (none) => lewyssmith

Something strange here: om my laptop I have two trace files, one 
execve("/usr/sbin/rt-setup-database", ["rt-setup-database", "--action", "init", "rttest"], [/* 47 vars */]) = 0
the other
execve("/usr/bin/rt", ["rt"], [/* 79 vars */]) = 0
both dated 2017-05-18. I cann't imagine myself doing tests and not leaving any trace of it in the bug.

CC: (none) => herman.viaene

And version 4.0.8 is installed on my laptop.

MGA5-32 on Asus A6000VM Xfce
No installation issues.
Tutorial rather opaque for me.
I think I used in May rt to test some other library. By looking at the trace I got so far as to initiate its database as root.
# rt-setup-database --action init rttest
In order to create or update your RT database, this script needs to connect to your  mysql instance on localhost (port '') as root
Please specify that user's database password below. If the user has no database
password, just press return.

Password: 
Working with:
Type:	mysql
Host:	localhost
Port:	
Name:	rt4
User:	rt_user
DBA:	root
Now creating a mysql database rt4 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs.
Granting access to rt_user@'localhost' on rt4.
Done.
Now inserting RT core system objects.
Done.
Now inserting data.
Done inserting data.
Done.

Haven't got so far to even connect to this. Tomorrow is another day.

The documentation in the README file is not apted to the Mageia installation.
E.g. it supposes being installed in /opt , but there is nothing there.
In fact, all defaults seem reasonable, and after the previous step just point the browser to http://localhost/rt and wait (at least on my old slow laptop) for the login screen. The default is user "root" password "password" and this gets you to "RT at a glance" which is kind of dashboard for the application.
I won't go any further here, unless someone objects, I OK this.

Whiteboard: (none) => MGA5-32-OK

Dave: I had just done this massive advisory in parallel. You got in first!
I propose to try this update for M5/x64, since it encompasses so many accumulated corrections. Thanks yet again to Herman for beating the path.

Testing M5/84

BEFORE the update, I installed:
 rt-4.0.8-11.mga5
 rt-mailgate-4.0.8-11.mga5
 perl-Encode-2.620.0-4.mga5
'rt' asked for:
# urpmi rt
I fodloni 'perl(UNIVERSAL::require)' dibyniaeth, bydd angen un o'r pecynnau canlynol:
 1- perl-UNIVERSAL-require-0.170.0-4.mga5.noarch: Require modules from a variable (gosod)
 2- perl-first-0.0.1-2.mga5.noarch: Use the first loadable module in a list (gosod)
Beth yw eich dewis? (1-2)1
which means "which of the following requirements do you want?"
I tried first 'perl-first' (which, like the first, pulled in a total of 65 pkgs);
The rpm installation finishes with a brief summary of things to do, notably the use of 'rt-setup-database'. This has no man page, but:
 $ rt-setup-database -h
shows its options.

BUT when it came to running:
 # rt-setup-database --action init
this *failed* with a lot of error msgs about compilation failures, starting with:
"Can't locate UNIVERSAL/require.pm in @INC (you may need to install the UNIVERSAL::require module)"

So the rpm installation question seems incorrect, and it sufficed to install
 perl-UNIVERSAL-require          [rather than perl-first]
after which:
 # rt-setup-database --action init
worked broadly as noted in Comment 16, to the final "Done". But much more messily - there were many interspersed errors:
"Use of uninitialized value $innodb in lc at /usr/lib/perl5/vendor_perl/5.20.1/RT/Handle.pm line 270, <STDIN> line 1."
and similar but longer for lines 270 & 273.
I wonder whether this is something cured by the update, since Herman did not have these - may have installed the update directly?

I then did as proposed:
 # systemctl restart httpd

After which, http://localhost/rt did indeed show the login screen - root /password  initially. Played with it a bit, created a post, added a title to it later, changed the root password (obscure to find). It looks nice & basically worked.
---------------------------
continued below...

M5/64 cont.
AFTER UPDATE:
 rt-4.0.25-1.mga5
 rt-mailgate-4.0.25-1.mga5
 perl-Encode-2.640.0-1.mga5

The update said it is necessary to do (so I did) after any version upgrade:
 # rt-setup-database --action upgrade
In order to create or update your RT database, this script needs to connect to your  mysql instance on localhost (port '') as root
Please specify that user's database password below. If the user has no database
password, just press return.

Password: 
Working with:
Type:	mysql
Host:	localhost
Port:	
Name:	rt4
User:	rt_user
DBA:	root
Enter RT version you're upgrading from: 4.0.8

Going to apply following upgrades:
* 4.0.9
* 4.0.12
* 4.0.13
* 4.0.18
* 4.0.19

Enter RT version if you want to stop upgrade at some point,
  or leave it blank if you want apply above upgrades: 

IT'S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 4.0.9
Now inserting data.
Processing 4.0.12
Now populating database schema.
Processing 4.0.13
Now populating database schema.
Processing 4.0.18
Now inserting data.
Processing 4.0.19
Now populating database schema.
Now inserting data.
Done.
----
http://localhost/rt behaved as previously. Logged in OK as root with previously changed password. Everythinh looks the same. Added another reminder to the original post, struggled with 'search' to find it - but did in the end.

This update looks OK. Validating it.

Keywords: (none) => validated_update
Whiteboard: MGA5-32-OK advisory => MGA5-32-OK advisory MGA5-64-OK
CC: (none) => sysadmin-bugs

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

http://advisories.mageia.org/MGASA-2017-0325.html

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