What;s with the Vim security updates in 15?

marav · 09-24-2022, 09:03 PM

Quote:

Originally Posted by LuckyCyborg

in a stable release the software shouldn't be updated every day, right? OR I miss something?

I think that in a stable release, a software should be updated every time there is a security issue, event if it's every day (which is not really the case for Vim)

LuckyCyborg · 09-24-2022, 09:05 PM

Quote:

Originally Posted by marav

The majority of Vim CVEs, are more or less related to application crashes in very specific cases
For example, the latest CVE proof of concept:

Code:

vim -u NONE -i NONE -n -m -X -Z -e -s -S /home/fuzz/test/poc10_huaf.dat -c :qa!
=================================================================
==6729==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500000d910 at pc 0x559ab291177f bp 0x7ffd8c790370 sp 0x7ffd8c790360
READ of size 16 at 0x62500000d910 thread T0
...

nothing really scary in our daily use

IF there's nothing really scary in our daily use, WHY those CVEs needs to be fixed ASAP and new VIM packages are issued, WHEN a privilege escalation and remote code execution issue is still ignored since months?

Yes, I talk about the XWayland server from Slackware 15.0 , not patched even today.

https://www.phoronix.com/news/XWayland-22.1.3-Released

marav · 09-24-2022, 09:18 PM

Quote:

Originally Posted by LuckyCyborg

IF there's nothing really scary in our daily use, WHY those CVEs needs to be fixed ASAP and new VIM packages are issued, WHEN a privilege escalation and remote code execution issue is still ignored since months?

Yes, I talk about the XWayland server from Slackware 15.0 , not patched even today.

https://www.phoronix.com/news/XWayland-22.1.3-Released

CVE for the last 3 months:
Vim: 57
Linux Kernel: 108

Should we stop using Linux Kernel ?

LuckyCyborg · 09-24-2022, 09:23 PM

Quote:

Originally Posted by marav

CVE for the last 3 months:
Vim: 57
Linux Kernel: 108

Should we stop using Linux Kernel ?

Who knows?

BUT I cannot help to not notice that latest kernel on Slackware 15.0 is 5.15.63 while the latest from its LTS series is 5.15.70 . And please note that I talk about kernel releases, NOT about patches grabbed from Mr. Torvalds' personal git repository.

Maybe our BDFL can enlighten us WHY we have the VIM Of The Day , but not also the Kernel Of The Day in the Slackware 15.0 ?

And, again: no love yet for the XWayland server?

Hence, the huge attention which VIM gets from Slackware's part (compared with other, even more important packages, like the Kernel) makes me highly suspicious about it and its code quality.

marav · 09-24-2022, 09:40 PM

Quote:

Originally Posted by LuckyCyborg

Hence, the huge attention which VIM gets from Slackware's part (compared with other, even more important packages, like the Kernel) makes me highly suspicious about it and its code quality.

As I am
Either they code very badly, or they like easy money (as suggested by Mr. Volkerding)

I have my idea

Pithium · 09-25-2022, 09:45 AM

Quote:

Originally Posted by LuckyCyborg

I do not talk about its usefulness.

I talk about the VIM's code quality, which seems to be so questionable and ridiculous, that the VIM needs to receive daily security updates in the stable release of Slackware 15.0 - in a stable release the software shouldn't be updated every day, right? OR I miss something?

No matter how useful is a software, even it's presence in the system seems highly dangerous, considering that it receive a CVE every day and those CVEs seems so dangerous that they need to be fixed ASAP.

CVE's are created when an exploit is FOUND. Not when it first makes its way into the software. Somebody decided to audit an app that everyone assumes to be secure and found a few things, what's the problem here?

How many times does Pat have to update mozilla-firefox? I don't see you ranting about that. bind? httpd? curl? sendmail? THE KERNEL ITSELF?? You complain about the frequency of updates, but here you are on a website running a LAMP stack.

If this really is an issue for you, delete your LQ account, unplug from the internet and go live in the woods. Grow a nice big beard and come down to the city once every year to trade pelts for salt. Because nothing in Slackware is safe enough for your needs.

Or better yet, download the source code for VIM and fix it yourself. A man as smart as yourself should have no problem fixing all the problems with vim's code quality.

LuckyCyborg · 09-25-2022, 11:21 AM

Quote:

Originally Posted by Pithium

CVE's are created when an exploit is FOUND. Not when it first makes its way into the software. Somebody decided to audit an app that everyone assumes to be secure and found a few things, what's the problem here?

The problem here is the overwhelming attention which VIM gets, in comparation with more important packages, like... the kernel?

Since Aug 26, 2022 when was pushed the last 5.15.63 kernel in Slackware 15.0 there was released another 7 (seven) releases up to today 5.15.70 and yet no one entered the game.

While the 5.15.63 released for stable Slackware 15.0 even seems like that have issues in particular 32bit kernels. See there an example:

https://www.linuxquestions.org/quest...mp-4175716553/

And still no love for the XWayland server and its known vulnerabilities.

If every software would have get equal attention, I would never complained.

BUT, we got VIM, VIM, VIM, VIM, VIM, VIM, VIM, VIM, VIM, VIM, and again VIM. No kernels, no XWayland server, God knows what other not.

Then I believe that I'm entitled to ask: WTF is wrong with VIM? It's the VIM's CVEs more important that the kernel's CVEs?

Quote:

Originally Posted by Pithium

How many times does Pat have to update mozilla-firefox? I don't see you ranting about that.

When the Mozilla Firefox will get daily updates in the stable Slackware 15.0 you can trust me that I will ask: WTF is wrong with Mozilla Firefox?

Quote:

Originally Posted by Pithium

bind? httpd? curl? sendmail? THE KERNEL ITSELF?? You complain about the frequency of updates, but here you are on a website running a LAMP stack.

If this really is an issue for you, delete your LQ account, unplug from the internet and go live in the woods. Grow a nice big beard and come down to the city once every year to trade pelts for salt. Because nothing in Slackware is safe enough for your needs.

Or better yet, download the source code for VIM and fix it yourself. A man as smart as yourself should have no problem fixing all the problems with vim's code quality.

I may ask you if you have been raised and educated in a communist country? Because what you did here is exactly what is a "Soviet Argument" ...

For those does not know what's a Soviet Argument: it's a speech style used when someone raise an issue, where someone else (like you) responds by not attacking the raised issue, but the complainer himself, his quirks and past. Usually it's accompanied with a "sending to woods" as a ritualistic claim that the complainer is not worth to live in his community, unless solves the issue himself.

Yeah, in the Soviet Union that's how they did with the people raising issues. They sent them into woods. Sometimes, that happened literally. In Siberia.

marav · 09-25-2022, 12:05 PM

Quote:

Originally Posted by LuckyCyborg

The problem here is the overwhelming attention which VIM gets, in comparation with more important packages, like... the kernel?

For slackware64-current

Code:

blackstar :: » grep -c kernel-source ChangeLog.txt  
50
blackstar :: » grep -c vim ChangeLog.txt    
50

It seems that we have given the same attention ;-)

LuckyCyborg · 09-25-2022, 12:10 PM

Quote:

Originally Posted by marav

For slackware64-current

Code:

blackstar :: » grep -c kernel-source ChangeLog.txt  
50
blackstar :: » grep -c vim ChangeLog.txt    
50

It seems that we have given the same attention ;-)

I do not talk about -current, as it's the development tree. I will not complain about -current even it goes mass-rebuild daily for months. Because it's -current and I've assumed the risks of using it.

My issue is the stable tree of Slackware 15.0 where the kernel CVE's seems to have updates in batches, the XWayland server is not fixed yet after months, while the VIM is uber-updated. Daily.

Code:

Fri Aug 26 04:02:20 UTC 2022
patches/packages/linux-5.15.63/*:  Upgraded.
  These updates fix various bugs and security issues.
  Be sure to upgrade your initrd after upgrading the kernel packages.
  If you use lilo to boot your machine, be sure lilo.conf points to the correct
  kernel and initrd and run lilo as root to update the bootloader.
  If you use elilo to boot your machine, you should run eliloconfig to copy the
  kernel and initrd to the EFI System Partition.
  For more information, see:
    Fixed in 5.15.39:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1974
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1975
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1734
    Fixed in 5.15.40:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1943
    Fixed in 5.15.41:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28893
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32296
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1012
    Fixed in 5.15.42:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1652
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1729
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21499
    Fixed in 5.15.44:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1789
    Fixed in 5.15.45:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2873
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1966
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32250
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2078
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1852
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1972
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2503
    Fixed in 5.15.46:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1184
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1973
    Fixed in 5.15.47:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34494
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34495
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32981
    Fixed in 5.15.48:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21125
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21166
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21123
    Fixed in 5.15.53:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2318
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33743
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33742
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33741
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33740
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26365
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33744
    Fixed in 5.15.54:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33655
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34918
    Fixed in 5.15.56:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36123
    Fixed in 5.15.57:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29900
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29901
    Fixed in 5.15.58:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21505
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1462
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36879
    Fixed in 5.15.59:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36946
    Fixed in 5.15.60:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26373
    Fixed in 5.15.61:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1679
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588
  (* Security fix *)

We can't have something like this also for VIM's CVEs? Nope? They are that dangerous, then?

Pithium · 09-25-2022, 12:43 PM

What are we crying about? A text editor used by sysadmins all over the world is getting security updates? Say it isn't so!

https://github.com/vim/vim/tags
https://linuxgalaxy.org/lcp/slackware/15.0/?arch=x86_64&pkg=vim

If Pat is updating vim on a daily basis then I demand that this be reflected in the changelog! Else I'm just gonna blame upstream.

marav · 09-25-2022, 12:48 PM

Quote:

Originally Posted by LuckyCyborg

I do not talk about -current, as it's the development tree. I will not complain about -current even it goes mass-rebuild daily for months. Because it's -current and I've assumed the risks of using it.

My issue is the stable tree of Slackware 15.0 where the kernel CVE's seems to have updates in batches, the XWayland server is not fixed yet after months, while the VIM is uber-updated. Daily.

We can't have something like this also for VIM's CVEs? Nope? They are that dangerous, then?

I understand what you mean, but there is no need to give false arguments.
Vim is updated once a week at best. More or less
6/09 - 10/09 - 14/09 - 18/09 - 23/09

henca · 09-25-2022, 01:55 PM

Quote:

Originally Posted by LuckyCyborg

Since Aug 26, 2022 when was pushed the last 5.15.63 kernel in Slackware 15.0 there was released another 7 (seven) releases up to today 5.15.70 and yet no one entered the game.

I can't say for sure how the choice is made which kernels should make it into Slackware security patches. However, I can say for sure that a comparison between the number of CVEs in an application like vim with the number of CVEs in the Linux kernel is not completely fair.

The Linux kernel is a rather large code base and of course it will contain more bugs. However, all CVEs in the Linux kernel does not apply to all Linux users. Some parts of the Linux source code goes into the compiled kernel. Some parts of the Linux source code goes into kernel modules. Depending upon your configuration, some parts of the Linux source code does not get compiled at all. Even most of the modules that you have compiled and installed will probably not be loaded.

Again, I can't say for sure how the choices are made, but it could be that some kernel CVEs are ignored simply because they do not apply to any of the original Slackware kernel configurations.

regards Henrik

montagdude · 09-25-2022, 07:47 PM

Quote:

Originally Posted by Pithium

What are we crying about? A text editor used by sysadmins all over the world is getting security updates? Say it isn't so!

Seriously. Quite the first-world problem.

henca · 09-26-2022, 01:59 AM

Quote:

Originally Posted by Pithium

What are we crying about? A text editor used by sysadmins all over the world is getting security updates? Say it isn't so!

The complaint by the original poster was that the pushed updates overwrites customized configuration files. This is annoying for any package doing so. I have a custom package which modifies the dpms settings in /etc/X11/app-defaults/XScreenSaver , every time xscreensaver is updated with a new package my custom settings are overwritten. If I remember right there was an agreement between Slackware and xscreensaver that Slackware were allowed to remove the update nag screen from xscreensaver if new releases of xscreensaver were pushed as Slackare updates. With such an agreement it would be nice if the xscrensaver configuration file had some kind of support of including files with custom settings.

regards Henrik

marav · 09-26-2022, 03:14 AM

Quote:

Originally Posted by henca

The complaint by the original poster was that the pushed updates overwrites customized configuration files. This is annoying for any package doing so. I have a custom package which modifies the dpms settings in /etc/X11/app-defaults/XScreenSaver , every time xscreensaver is updated with a new package my custom settings are overwritten. If I remember right there was an agreement between Slackware and xscreensaver that Slackware were allowed to remove the update nag screen from xscreensaver if new releases of xscreensaver were pushed as Slackare updates. With such an agreement it would be nice if the xscrensaver configuration file had some kind of support of including files with custom settings.

regards Henrik

As with Vim, it's up to the user, not the software, to deal with custom config files

Code:

! These resources, when placed in the system-wide app-defaults directory
! (e.g., /usr/lib/X11/app-defaults/XScreenSaver) will provide the default
! settings for new users.  However, if you have a ".xscreensaver" file in
! your home directory, the settings in that file take precedence.