OTRS Version(s)

Essentially, it all still applies. TBH I'm not clear on the unpatched security issues that OTRS upstream are referring to, but if they have CVEs (Common Vulnerabilities and Exposures reference number) then it's fairly easy to check whether the security issues have been patched in Debian or not. And if not, it should be possible to see why.

FWIW, I just searched the Debian Security tracker and can't see any open security issues against OTRS, so I would assume that they are all patched. FWIW, read more about the Debian security tracker here.

Debian Jessie (what v14.x is based on) is expected to receive backported security updates until April 2020.

With regards to OTRS version we'll have in the next major release (v15.0), I'm not sure what version it explicitly was at that point (when I posted before), but the link is still relevant, and that says that the version will be 5.0.16.

I see you answered this question before in 2016, and indicated you were possibly including v5 in your Core v15 build at: /forum/support/20160822/otrs-version-5

Considering we are two years from that post, will a newer version of OTRS be included, or is it still going to be v5?

Thank you! It's mostly gibberish to me in the Linux (Debian) World; I am learning slowly as I love how such OS and Appliances aren't your common "Windows" systems that are compromised daily. I have been using (Ubuntu for years) and recently Lubuntu on one of my older MacBooks just to learn basic operations and to be free from Windows for a bit... and I also use your Gallery and OpenVPN Appliance within my personal home farm - as I am a fan of the 'out of the box' approach.

Let me know what you find out.

I don't think he understands how Debian works.

He does raise some points that may be valid, but I would argue that if they aren't publicly announcing all known security issues (even if they don't intend to fix them), then they're doing it wrong. But as a software vendor, they're free to do it however they like. I do wish that they'd work with the Debian maintainer a little more closely though as IMO that would have the best outcome for all users.

Anyway, I'll respond over there shortly.

Jeremey,

I see on 1/9/2018, you shot Jojo a post for his input on your experience with Debian/OTRS. Did you get a chance to review his reply? If so, what is your take on his response? He seems pretty confident v3.3x isn't secure.

I am inclined to dispute the perspective presented by jojo as I know for a fact that at least on occasions the Debian Security Team DO develop their own security patches to backport fixes for security related issues in packaged software. Whether or not that directly relates to OTRS though, I'm not 100% clear.

The Debian Security team focus on "stable" (currently Debian Stretch, i.e. the basis of the upcoming v15.0) and "oldstable" (currently Debian Jessie, i.e. the basis of v14.x). Once "oldstable" support ends (12 mths after the release of a new "stable") the responsibility is handed to the LTS (Long Term Support) team, who continue the work. We have a close working relationship with the current Debian Project Leader, Chris Lamb. He is also part of the LTS team, so we get a fair bit of behind the scenes insight into Debian in general, including how things are done with regards to security.

Having said that, to be completely transparent, there is a possibility that there are unpatched security issues. All security issues that the Debian Security team (and/or LTS team) are aware of are triaged and on occasion they deem particular issues unimportant and/or low priority (for a range of possible reasons). These "unimportant" issues are still tracked, and often eventually fixed, but their priority is lowered and they are often released in batches (i.e. multiple "low level" and/or "unimportant" issues all patched at the same time). The importance of a security bug is considered in terms of how easy it is to leverage by an attacker, and how much damage could be done if it were. I.e. a bug which is easy to leverage (even if it doesn't do much damage), or a bug that is hard to use, but would produce devastating results, would generally both be classified as "serious".

It's also worthy of note that often the real issues with security vulnerabilities is not the individual issues themselves. But how they can be daisy chained by attackers. As a mythical example, an attacker may use a bug in OTRS to get access to Apache, then leverage a bug in Apache to gain access to the system, then leverage an OS level privilege exploit to gain access to your root user account. In many respects an OS such as Debian (who package everything) is in quite a unique position as they can consider the implications of how these different vulnerabilities could be used in conjunction. This also works back the other way too. I've seen multiple occasions where potential security issues in web apps have been mitigated by changes in webserver configuration (which are provided as auto-installed security updates in TurnKey).

Regardless, I have signed up for a user account over on the OTRS forums and will follow up with jojo. I'm particularly interested whether he has any specific information on any unpatched security issues in OTRS 3.3. If he can demonstrate that there are indeed any unpatched issues with concerning implications, we will certainly take it up direct with Debian, and would also consider switching to an upstream install (i.e. direct from OTRS) for v15.0. Unless there is a quick fix, we'd probably pull the current OTRS appliance too (until we have a fixed version), as well as developing documentation on how current users such as yourself could manually upgrade to an unaffected upstream version.

I'm not keen to do that if we don't have to though. Installing and maintaining servers with software installed from upstream is much more labour intensive both for us and for end users such as yourself. It also means that the risk of a particular server having unpatched security updates is much higher (especially when upstream release major versions that require significant changes). We try to release as often as we can, and always prioritise security issues (and pull appliances if there are known and unpatched issues). But we are not yet at a point where we can produce an updated appliance everytime upstream provides a new version. So IMO, as a general rule, using Debian packages is a much better end user experience and less work for us (so we can spend our limited resources doing other stuff).

See Thread (Last few comments) : http://forums.otterhub.org/viewtopic.php?f=62&t=38640&p=156498#p156498

Thoughts?

No worries, as a Web Developer, Security Officer and Systems Engineer; I know all about broken links/config/data (in the Windows World). I am just a "changelog" buff, I like to read the updates/features/upgrades to see if I am interested in upgrading or fine at the state I'm at (since upgrades/migrations can be a pain in general) - hence, me not wanting to move to the upstream OTRS as I'd have to figure out if I am secure/patched and configured properly on my own - yet at the same time, I'd like to feel confident in the security and stability of the design as well since I am still considering myself a (no0b) with Linux/Debian.

Changelogs also help me battle in conversations (i.e. upstream members); defending a system/vendor that takes pride in what they provide to their customers. 

I'm currently working with a third party web dev shop to upgrade the look and feel of the site. Once that is complete, we'll either fix the "updates" info so it works as it should, or we'll remove it altogether and point directly the the changelog in the build code. In the meantime, unfortunately, the workaround is to access the buildcode directly (as per above).

Note that the links I have provided above are specifically for the v14.2 release (they leverage git/GitHub's tagging system). If you view master, you will see the current state of the repo. Many appliances already have v15.0 code merged. FWIW, each appliance has a link to it's source code on GitHub. Generally the GitHub url is github.com/turnkeylinux-apps/APPLIANCE_NAME.