LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-03-2020, 05:58 PM   #16
baumei
Member
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 155

Original Poster
Rep: Reputation: 55

Hi "ehartman",

Thank you for the heads-up:
Quote:
Originally Posted by ehartman View Post
That is the latest, as distributed with 14.2 (compiled in 2016)
It even is the latest in -current, although a few times RE-compiled
Code:
kde-runtime-4.14.3-i586-8.txz	8998 KB 	11/01/2018 	12:00:00 AM
I have not been following Slackware-current, and had no idea it also used KDE4.

Prior to hearing of this I had been considering backporting bits of KDE from Slackware-current to Slackware-14.2, but not any more.
 
Old 05-03-2020, 10:35 PM   #17
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643
Just because it has the plasma name in it doesn't mean it is affected. plasma-workspace is a new project for Plasma5. Yes, it is likely that it pulled in code from various KDE4 projects, but that doesn't mean they're affected. If it was, it would've likely been covered in the CVE since the code can be checked (CVEs are still used on EOL'd software).

And if you actually looked at the descriptions of those packages rather than just grepping for plasma, you'd realize that only kde-base and kde-workspace are the likely precursors to plasma-workspace (kscreen's description may lead you to think it could be in plasma-workspace, but kscreen2 is in ktown, so it is unlikely). The rest are all addons to be used with a plasma-based desktop.
 
Old 05-03-2020, 11:02 PM   #18
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,631

Rep: Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845
Quote:
Originally Posted by baumei View Post
I have not been following Slackware-current, and had no idea it also used KDE4.
Yes, KDE/Plasma 5 hasn't been incorporated into the main -current (yet).
So -current currently still has KDE 4 and to replace that with 5 you have to use 'ktown' from Eric "AlienBob" Hameleers (slackware.nl/alien-kde/), which probably will make its way into -current yet.

AlienBob is the author of the "multilib" packages too
Quote:
Slackware for the x86_64 architecture (or Slackware64 for short) is a pure 64-bit Operating System, but by design it is "multilib-ready". This means, that is it is possible to add a layer of software that will allow you to run 32bit software without changes to either Slackware64 or these 32bit packages.
Furthermore, the multilib-enabled Slackware64 can compile 32bit binaries, if you add the right software to it.

This README contains instructions on how to use the packages in this directory to create a multilib Slackware64.

Last edited by ehartman; 05-03-2020 at 11:06 PM. Reason: added url for ktown
 
Old 05-04-2020, 12:52 AM   #19
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,425

Rep: Reputation: 693Reputation: 693Reputation: 693Reputation: 693Reputation: 693Reputation: 693
Quote:
Originally Posted by bassmadrigal View Post
This is the reason I don't like to run -current. I don't have the time to administer my computer as much as is needed to properly use -current.
Actually, it's what you make it. Once you install it, you can pretty much set it & forget it just like any other Slackware version.

My daily basher is Slackware64-current which I installed in August last year.
Quote:
Originally Posted by bassmadrigal View Post
But I don't think you'd need to take the drastic measure of removing KDE4 just because some vulnerabilities exist for it.
Yeah, if it was that bad it would surely have been removed already?
 
1 members found this post helpful.
Old 05-04-2020, 05:09 AM   #20
baumei
Member
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 155

Original Poster
Rep: Reputation: 55
Hi "bassmadrigal",

I do not agree with your idea expressed here:
Quote:
Originally Posted by bassmadrigal View Post
This is definitely a valid concern, but there are a lot more serious concerns with untrusted thumbdrives that has nothing to do with the software you run on your computer. You just flatout, should not plug in an untrusted device. The last time I plugged in a device that wasn't straight from the manufacturer was when my wife and I got our wedding photos back in 2014, but it came from our wedding photographer, so hardly untrusted.
Quite a few years ago I read an article in the computer security news realm which was about many USB flash-drives having been shipped by a particular manufacturer with malicious software installed on them. Today, I did a web-search for that news article, but I did not find it. However, I did find this article from ZDNet IBM Warns of Malware on USB Drives.

Also, I found an article saying that one way to attack the computers of an organization is to scatter a few infected flash-drives in the parking lot, because many of the employees would pickup the flash-drive, carry it into the building, and plug it into one of the organization's computers. Back when I was in charge of maintenance and operation of a flock of Windows computers I disabled 'autorun' for all drives, and ordinary users did not have the admin password needed to enable 'autorun'.

Many years ago I read an article about the firmware in a printer having been intentionally infected, so that it would later attack the computer to which it was connected; I did a web-search today looking for this article, but did not find it. However, I did find on HowToGeek this article USB Device Security Hole. Just because the article talks about Windows, does not mean that similar could not be done to Linux, MacIntosh, Android, and/or ChromeOS.

In my opinion, there is no way to tell by looking at any USB device whether it is worthy of being trusted, consequently I do not want software on the flock of computers which I maintain to have flaws in the handling of anything connected to USB. I do not trust flash-drives which are new and in the manufacturer's packaging any more than I would a random flash-drive found in the wild.

Last edited by baumei; 05-04-2020 at 10:36 AM.
 
1 members found this post helpful.
Old 05-04-2020, 12:18 PM   #21
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643
Quote:
Originally Posted by rkelsen View Post
Actually, it's what you make it. Once you install it, you can pretty much set it & forget it just like any other Slackware version.
I install -current when needed. I did it for my htpc since the AMD 2200G APU wasn't supported by 14.2. But then I've never updated it... since May of 2019. That means no security fixes or anything. On my desktop, I can at least do upgrade-all and I can expect that everything will still work fine. When on -current, if you try and upgrade to get your security fixes, you may end up with a slew of 3rd-party packages that are broken.

I haven't updated my htpc because I don't want to go through the effort of recompiling everything needed for kodi if it ends up broken after the update.

Quote:
Originally Posted by baumei View Post
Quite a few years ago I read an article in the computer security news realm which was about many USB flash-drives having been shipped by a particular manufacturer with malicious software installed on them. Today, I did a web-search for that news article, but I did not find it. However, I did find this article from ZDNet IBM Warns of Malware on USB Drives.

Also, I found an article saying that one way to attack the computers of an organization is to scatter a few infected flash-drives in the parking lot, because many of the employees would pickup the flash-drive, carry it into the building, and plug it into one of the organization's computers. Back when I was in charge of maintenance and operation of a flock of Windows computers I disabled 'autorun' for all drives, and ordinary users did not have the admin password needed to enable 'autorun'.

Many years ago I read an article about the firmware in a printer having been intentionally infected, so that it would later attack the computer to which it was connected; I did a web-search today looking for this article, but did not find it. However, I did find on HowToGeek this article USB Device Security Hole. Just because the article talks about Windows, does not mean that similar could not be done to Linux, MacIntosh, Android, and/or ChromeOS.
You basically agreed with my belief that the thumbdrive vulnerability in KDE is minor. There are much more serious threats out there that have nothing to do with what WM/DE, distro, or OS you're running.

Quote:
Originally Posted by baumei View Post
In my opinion, there is no way to tell by looking at any USB device whether it is worthy of being trusted, consequently I do not want software on the flock of computers which I maintain to have flaws in the handling of anything connected to USB. I do not trust flash-drives which are new and in the manufacturer's packaging any more than I would a random flash-drive found in the wild.
Yes, it is true you can't tell if they're compromised. However, if the choice is between a sealed thumbdrive from a trusted manufacturer vs some random thumbdrive I found in a parking lot, guess which one I'll trust? I can't use thumbdrives at work (I get locked out of my system if an unknown USB storage device is plugged in), but I do use them at home and in the car. These thumbdrives are from SanDisk and are sealed in the original packaging when I buy them.

And really, if you start worrying about the firmware on thumbdrives, what about the firmware on your motherboard, video card, harddrive, or all the firmware blobs on your phone? You have to have an inherent amount of trust when you use devices that are proprietary (and even open source, if you don't have time or knowledge to audit all the code yourself). There are minor vulnerabilities that are in KDE4 (and almost all of them can be easily worked around) but there are plenty of other attack vectors that are much more serious in nature (especially considering almost every Intel system for almost a decade had a remote privilege escalation bug and all the Spectre/Meltdown stuff that's come to light recently). Who knows what's lurking in your hardware and firmware, just waiting to be exploited...
 
Old 05-04-2020, 01:10 PM   #22
baumei
Member
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 155

Original Poster
Rep: Reputation: 55
Hi "ehartman",

Thank you for the URL to Ktown. I see AlienBob has a version of Ktown for Slackware 14.2.

In the Slackware64 14.2 KDE package set, I see for Okular it says "okular-4.14.3-x86_64-2.txz 2015-Oct-25 08:02". When I run this Okular, it says the version is "0.20.3" --- so, it appears the "4.14.3" is adopted from the version number of the KDE set of software.

In Ktown for Slackware64 14.2, I see for Okular it says
"okular-17.08.3-x86_64-1alien.txz 2017-11-19 14:28". I expect the "17.08.3" is not the version of Okular, so I can not tell whether "CVE-2020-9359 KDE Okular before 1.10.0 allows code execution via an action link in a PDF document." is applicable, or not. (I guess I will have to download it, install it, and run it, in order to find out what the version is.)

----

In Ktown for Slackware64 14.2, for "plasma-workspace" it says
"plasma-workspace-5.11.3-x86_64-2alien.txz 2018-02-09 18:02". I am not certain, but it appears that the "5.11.3" is the version number of this workspace software (Do you happen to know?). If this is the version number, then CVE-2018-6790 and CVE-2018-6791 do apply to it. :-(
 
Old 05-04-2020, 01:24 PM   #23
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643
You shouldn't use ktown for 14.2. It is grossly outdated and hasn't been updated in 2.5 years. Newer versions of Plasma5 don't work on 14.2 without a massive overhaul of underlying libraries. The 14.2 version of ktown is not tested against a fully patched and updated 14.2, so it may break the system or leave ktown broken.
 
1 members found this post helpful.
Old 05-04-2020, 07:39 PM   #24
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,631

Rep: Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845Reputation: 845
Quote:
Originally Posted by baumei View Post
Hi "ehartman",

Thank you for the URL to Ktown. I see AlienBob has a version of Ktown for Slackware 14.2.
Yeah, but that one isn't maintained anymore, so is out-of-date.
Quote:
Here is KDE 5_17.11 for Slackware, consisting of the KDE Frameworks 5.40.0, Plasma 5.11.3 and Applications 17.08.3 on top of Qt 5.7.1.
it is from 2017, so not all that much newer then KDE 4.

Quote:
Do you happen to know?).
No, I do not use KDE and/or Plasma 5 at all. Ask AlienBob himself. I do know that the whole KDE/Plasma versioning is pure chaos, with the sets as a whole having one version number and the separate components having another. In the above quote you see the versions of the three major component sets.

PS: for -current it currently is
Quote:
I keep announcing that I will stop providing monthly updates, but Slackware seems stuck in its Qt4 based past, so here is one more attempt in order to give you the new Application Releases 20.04:

KDE 5_20.04 for Slackware, consisting of KDE Frameworks 5.69.0, Plasma 5.18.4 and Applications 20.04.0 on top of Slackware's Qt 5.13.2.
(both quotes from the README for that version of ktown).

Note that this version doesn't supply its own QT 5 anymore, as that did make its way into -current.

Last edited by ehartman; 05-04-2020 at 07:44 PM.
 
2 members found this post helpful.
Old 05-05-2020, 09:32 AM   #25
baumei
Member
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 155

Original Poster
Rep: Reputation: 55
Hi "bassmadrigal",

When in my "2020-05-03 16:36" posting I listed the six quotes of KDE package descriptions from Slackware 14.2, my purpose was to demonstrate that circa 2015/Oct at least some people considered KDE4 to have/be the "KDE Plasma Desktop". I think this is important, because it helps in understanding sentences such as this one, "An issue was discovered in soliduiserver/deviceserviceaction.cpp in KDE Plasma Workspace before 5.12.0." (CVE-2018-6791), to wit: the package description of kde-workspace-4.11.22 in Slackware 14.2 indicates it is part of KDE Plasma, and the version number is clearly before "5.12.0".

Quote:
Originally Posted by bassmadrigal View Post
The javascript vulnerability above doesn't have any ability to get into the system, it can just do some minor things like add bookmarks for a website.
I disagree. Before Meltdown, Spectre, and cousins were discovered it was normal that JavaScript did not run in a 'sandbox'. Since then, the web-browser programmers have been working on implementing a sandbox for JavaScript, and also working on tightening the cross-site restrictions. As I understand it, before the sandbox and/or XS-restrictions JavaScript could rather easily access whatever files to which the user had read-rights in the file-system. Well, KDE4 is ancient; pre-dates Meltdown/Spectre/&c.; has a 'unified' design; and has components for handling HTML, JavaScript, and such (e.g. "kwebkitpart" and "khtml") --> I thoroughly expect: the sandbox for JavaScript is not implemented in the applicable ancient code, the cross-site restrictions are light or nonexistent, and that any part of KDE4 which wants to access the Internet can call-up the WebKit or KHtml.

Also, back when Meltdown/Spectre/&c. was new and much in the news, there was an article about someone which had written proof-of-concept JavaScript code to implement a successful attack using one of these vulnerabilities. Since we know one person was able to do this, it is reasonable to presume that quite a few other people have done (or could do) similarly.

Quote:
Originally Posted by bassmadrigal View Post
You shouldn't use ktown for 14.2. It is grossly outdated and hasn't been updated in 2.5 years. Newer versions of Plasma5 don't work on 14.2 without a massive overhaul of underlying libraries. The 14.2 version of ktown is not tested against a fully patched and updated 14.2, so it may break the system or leave ktown broken.
Yes, Ktown for Slackware 14.2 is old. However, KDE4 in Slackware 14.2 is about twice as old. Also, KDE4 is end-of-life. As I understand the situation, compared to KDE4, the software in Ktown for Slackware 14.2 is significantly more similar to the KDE code which is being actively maintained. In addition, my understanding of Slackware 14.2 is that the changes since 2017/Nov have been relatively minor. So, I do not see the veracity of your assertion, "You shouldn't use ktown for 14.2."

No, I do not agree with your belief:
Quote:
Originally Posted by bassmadrigal View Post
You basically agreed with my belief that the thumbdrive vulnerability in KDE is minor.
Though I am not an "expert" programmer I have done some programming, and am much better at it than many others. I know enough to realize that the flaw at work in CVE-2018-6791 is because of the lack of suitable 'input validation'. I expect the programmer either: did no input validation, or did not create good input validation --- and if the programmer did this in this instance, he/she probably did the same in all other code he/she wrote.

In recent years many programmers have been coming to understand that input validation is very important. I think it is likely that the code in KDE5 has significantly more input validation than the code in KDE4. So, I am strongly considering removing KDE4 from all of my Slackware 14.2 systems, and installing Ktown for Slackware 14.2. Yes, I would prefer this Ktown was newer, but I subscribe to the principle of making known improvements now, instead of doing nothing while waiting for the perfect fix.
 
Old 05-05-2020, 11:28 AM   #26
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643Reputation: 4643
Quote:
Originally Posted by baumei View Post
When in my "2020-05-03 16:36" posting I listed the six quotes of KDE package descriptions from Slackware 14.2, my purpose was to demonstrate that circa 2015/Oct at least some people considered KDE4 to have/be the "KDE Plasma Desktop". I think this is important, because it helps in understanding sentences such as this one, "An issue was discovered in soliduiserver/deviceserviceaction.cpp in KDE Plasma Workspace before 5.12.0." (CVE-2018-6791), to wit: the package description of kde-workspace-4.11.22 in Slackware 14.2 indicates it is part of KDE Plasma, and the version number is clearly before "5.12.0".
Yes, we've been over this. Plasma is not some new name that occured with the 5th generation of KDE. However, plasma-workspace is a new program that was introduced in Plasma5. But unless you can find the flaw in KDE4 packages, my assertion that the Plasma5 version of plasma-workspace is what is affected since that's all the CVE mentions is what I'm going to stick with.

To further my argument, CVE-2015-1308 specifically includes both kde-workspace 4.2.0 (KDE4) and plasma-workspace before 5.1.95 (Plasma5). If other CVEs applied to different KDE4 and Plasma5 packages, why not mention it on them?

Quote:
Originally Posted by baumei View Post
I disagree. Before Meltdown, Spectre, and cousins were discovered it was normal that JavaScript did not run in a 'sandbox'. Since then, the web-browser programmers have been working on implementing a sandbox for JavaScript, and also working on tightening the cross-site restrictions. As I understand it, before the sandbox and/or XS-restrictions JavaScript could rather easily access whatever files to which the user had read-rights in the file-system. Well, KDE4 is ancient; pre-dates Meltdown/Spectre/&c.; has a 'unified' design; and has components for handling HTML, JavaScript, and such (e.g. "kwebkitpart" and "khtml") --> I thoroughly expect: the sandbox for JavaScript is not implemented in the applicable ancient code, the cross-site restrictions are light or nonexistent, and that any part of KDE4 which wants to access the Internet can call-up the WebKit or KHtml.
I didn't say javascript can't access the system, but based on the opensuse bug report I linked earlier, they don't say anything about this vulnerability having the ability to access the system. I'm just talking about this specific vulnerability and what the bug reports state. If you want to audit the code or find some other reference that states that this is more serious than the opensuse developers state, go for it. I'd definitely be open to new information. But based on the current info, yours is just speculation. Also, sandboxing javascript is not new because of Spectre/Meltdown. Chrome/Chromium introduced sandboxing html rendering and javascript back in 2008. Although, I bet a lot more people have been working on adding or beefing up sandboxing in the recent years.

Quote:
Originally Posted by baumei View Post
Yes, Ktown for Slackware 14.2 is old. However, KDE4 in Slackware 14.2 is about twice as old. Also, KDE4 is end-of-life. As I understand the situation, compared to KDE4, the software in Ktown for Slackware 14.2 is significantly more similar to the KDE code which is being actively maintained. In addition, my understanding of Slackware 14.2 is that the changes since 2017/Nov have been relatively minor. So, I do not see the veracity of your assertion, "You shouldn't use ktown for 14.2."
If you want to run a 3 year old ktown that could possibly be broken when you install it, go for it. I'll stick with the included KDE4. Plus, ktown for 14.2 includes plasma-workspace-5.11.3, so at this point, there's no question that you'll be vulnerable to CVE-2018-6791 and CVE-2018-6790. You'll also be vulnerable to CVE-2019-14744 since this hasn't received the patch like -current and 14.2's KDE4. The rest will likely be about the same.

Quote:
Originally Posted by baumei View Post
No, I do not agree with your belief:

Though I am not an "expert" programmer I have done some programming, and am much better at it than many others. I know enough to realize that the flaw at work in CVE-2018-6791 is because of the lack of suitable 'input validation'. I expect the programmer either: did no input validation, or did not create good input validation --- and if the programmer did this in this instance, he/she probably did the same in all other code he/she wrote.
If you look at the commit that fixed this bug, it is a simple switch of a function. They switched mx.expandMacros to mx.expandMacrosShellQuote. I'm sure you, as a "better than many" programmer, have never missed something like this, right? If you've done any programming, you realize that there are a TON of functions out there, especially when you're in as big of a project as KDE. Forgetting to use one that validates input when on a notification popup doesn't mean that the whole system or anything that programmer touched is flawed. If so, you better stop using any software, because I guarantee you that just about any serious programmer has shipped something with a mistake. And that same mistake wasn't made with dolphin, so it doesn't seem to be some gross negligence, just a minor oversight.

Quote:
Originally Posted by baumei View Post
In recent years many programmers have been coming to understand that input validation is very important. I think it is likely that the code in KDE5 has significantly more input validation than the code in KDE4. So, I am strongly considering removing KDE4 from all of my Slackware 14.2 systems, and installing Ktown for Slackware 14.2. Yes, I would prefer this Ktown was newer, but I subscribe to the principle of making known improvements now, instead of doing nothing while waiting for the perfect fix.
This still doesn't refute that the thumbdrive issue is minor compared to some of the other vulnerabilities out there. If you plug in a drive and it has some commands in the label of the device and you open it through the notification popup (it only occurs when you open it via the notification, not if you open it directly in dolphin). So don't plug in thumbdrives of devices that you can't verify the label hasn't been tampered with and if you still need to plug it in, don't open it via the notification popup. How is this as bad as infected firmware or USB devices containing capacitors that discharge 240v when plugged in? One has a simple workaround (don't open thumbdrives via the notification popup) and the others have vulnerabilities in the USB system itself that have no workaround and doesn't care what WM/DE you use. You're making a mountain out of a molehill.

Anyway, I'm done with this argument. We're just going back and forth. If you think KDE4 is so vulnerable, don't use it. It's really as simple as that. If you're really worried about it, you can removepkg all the KDE packages, even though none of these bugs will affect you if you don't run KDE software. And you're also certainly free to try and run the old 14.2 version ktown on 14.2, but you're still going to be vulnerable (if it works at all).

Simply put, KDE4 (and ktown for 14.2) is old. There are known vulnerabilities (which can pretty much all be worked around if you're aware of them). None of them are so serious that your computer can get infected by just having them on the system. It is unlikely we're going to see any updated KDE4 packages for 14.2 and ktown for 14.2 has been abandoned for years. Either switch to -current and run ktown there, pick a new WM/DE, or stick with old, outdated, and vulnerable KDE4 (or old, outdated, and vulnerable ktown for 14.2 if it works).

Best of luck in your decision.
 
Old 05-07-2020, 08:29 AM   #27
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 174

Rep: Reputation: 124Reputation: 124
Eric announced on his blog today that he will be removing his 14.2 ktown packages in the upcoming weekend at the end of May since they haven't been updated since 2017:

https://alien.slackbook.org/blog/kto...-offline-soon/

I'm just relaying this news to this thread since there was discussion of replacing kde 4 with the 14.2 version of ktown/plasma5. Clearly he thinks it's unfit for use and is unwilling to provide packages that may be a security risk to its users. Please consider this if you did go and install those packages on your machine.

Last edited by 0XBF; 05-08-2020 at 05:16 PM. Reason: Updated date to match link change
 
2 members found this post helpful.
Old 05-07-2020, 03:23 PM   #28
baumei
Member
 
Registered: Feb 2019
Location: USA; North Carolina
Distribution: Slackware!
Posts: 155

Original Poster
Rep: Reputation: 55
Hi "0XBF",

Thank you for the heads-up. I expect Mr. Hameleers is correct about some parts of Ktown-5 for Slackware 14.2 being old enough to have at least some security holes.

The pickle here is: I imagine that some of the KDE4 software in the official Slackware 14.2 set, being perhaps twice as old and un-maintained by KDE for longer, has more and/or worse security holes.

On Wikipedia, I read that KDE4 was released on 2008/Jan/11, and version 4.14 was released on 2014/Aug/20. It is not clear when the last patch came out for KDE4, but it might be that the last single piece of software patched was on 2017/Nov/7. It may be that KDE4 was declared end-of-life sometime in 2015.

On Wikipedia, I read that KDE5/Plasma was released on 2014/Jul/15. It appears that Ktown for Slackware 14.2 is (at least mostly) version 5.8 of KDE, and according to Wikipedia version 5.8 was released on 2016/Oct/4. I see v5.8 was declared to be a long-term-support version; I do not know when the last patch was issued.

Last edited by baumei; 05-08-2020 at 05:35 PM.
 
Old 05-07-2020, 05:25 PM   #29
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 174

Rep: Reputation: 124Reputation: 124
I don't disagree with you in the fact that kde4 is getting old and could have security issues other than the ones already pointed out here. If support isn't being provided any longer then there's not much one can do, other than writing their own fixes; not the easiest thing for a large project like kde4.

I'm sure Pat must also be aware of the aging state of the software included in 14.2 as he's maintaining both 14.2 and the constantly upgrading current. If he removes kde4 then it'll have to come out of both 14.2 and current, which would mean he's putting in a replacement where current is concerned. The word is out that plasma 5 will be added to current so when Pat does anything about kde4 it'll most likely be to replace it with plasma 5, at which point were looking at a 15 release probably soon after and then 14.2/kde4 becomes moot.

When this actually happens is anyone's guess so until then I guess you can either not use it (or remove it) yourself if you feel it's a risk, or run it and mind the bugs as bassmadrigal pointed out. FWIW I have 3 out of 4 of my machines on current with plasma 5 already and my 14.2 stays in the command line when its on so I don't use kde4 anymore.
 
1 members found this post helpful.
Old 05-07-2020, 08:04 PM   #30
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,425

Rep: Reputation: 693Reputation: 693Reputation: 693Reputation: 693Reputation: 693Reputation: 693
Guys, 14.2 is actively receiving security patches... that includes KDE4.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Latest KDE Security Vulnerabilities Are Patched in Ubuntu and Debian, Update Now LXer Syndicated Linux News 0 08-20-2019 03:29 AM
LXer: GNOME and KDE team up on the Linux desktop, docs for Nvidia GPUs open up, a powerful new way to scan for firmware vulnerabilities, and LXer Syndicated Linux News 0 08-17-2019 02:00 PM
NetBSD vulnerabilities Sep 17, lotsa... unSpawn *BSD 5 10-15-2002 03:59 PM
SANS/FBI Releases the Twenty Most Critical Internet Security Vulnerabilities jeremy Linux - Security 4 10-07-2002 06:37 PM
More BIND vulnerabilities jeremy Linux - Security 0 01-31-2001 08:29 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:14 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration