LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
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 04-19-2024, 11:02 AM   #4291
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,061

Rep: Reputation: Disabled

Quote:
Originally Posted by biker_rat View Post
Maybe its time to pull in a few small wayland centric desktops based on wlroots for next slackware release? labWC (wayland openbox), lxqt-2.0 (explains itself), & sway (wayland i3)? The total sum in additional bytes for all binaries for all three together is small. Maybe its time for some stuff fresher than blackbox, fluxbox, and fvwm?
Maybe lancsuk will have LXQt 2.0 ready after the week-end. Stay tuned

Last edited by Didier Spaier; 04-19-2024 at 11:07 AM.
 
Old 04-19-2024, 11:28 AM   #4292
gmgf
Senior Member
 
Registered: Jun 2012
Location: Bergerac, France
Distribution: Slackware
Posts: 2,217

Rep: Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006
Quote:
Originally Posted by Didier Spaier View Post
Maybe lancsuk will have LXQt 2.0 ready after the week-end. Stay tuned
I compiled it, here, on (current), it need a part of plasma6, it works, but there are widgets that seem bugged.

Last edited by gmgf; 04-19-2024 at 11:36 AM.
 
Old 04-19-2024, 12:20 PM   #4293
glennmcc
Member
 
Registered: Jan 2021
Location: North Jackson, Ohio (USA)
Distribution: slackware64-15.0
Posts: 518

Rep: Reputation: 292Reputation: 292Reputation: 292
l/glibc-2.39-x86_64-2.txz: Rebuilt.
This update fixes a security issue:
The iconv() function in the GNU C Library versions 2.39 and older may
overflow the output buffer passed to it by up to 4 bytes when converting
strings to the ISO-2022-CN-EXT character set, which may be used to crash
an application or overwrite a neighbouring variable.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2024-2961
(* Security fix *)

____________

affected from 2.1.93 before 2.40

_________________

v2.1.93 is from September of 2000

Soooo.... this bug has been "hiding" for over 23 years ?!?
 
Old 04-19-2024, 12:44 PM   #4294
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,511

Rep: Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475
Quote:
Originally Posted by glennmcc View Post
l/glibc-2.39-x86_64-2.txz: Rebuilt.
This update fixes a security issue:
The iconv() function in the GNU C Library versions 2.39 and older may
overflow the output buffer passed to it by up to 4 bytes when converting
strings to the ISO-2022-CN-EXT character set, which may be used to crash
an application or overwrite a neighbouring variable.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2024-2961
(* Security fix *)

____________

affected from 2.1.93 before 2.40

_________________

v2.1.93 is from September of 2000

Soooo.... this bug has been "hiding" for over 23 years ?!?
Yes, but on the bright side it seems rather useless for any sort of targeted attack.
 
2 members found this post helpful.
Old 04-19-2024, 01:26 PM   #4295
glennmcc
Member
 
Registered: Jan 2021
Location: North Jackson, Ohio (USA)
Distribution: slackware64-15.0
Posts: 518

Rep: Reputation: 292Reputation: 292Reputation: 292
Quote:
Originally Posted by volkerdi View Post
Yes, but on the bright side it seems rather useless for any sort of targeted attack.
Glad to hear that,
because it would be pretty-darned difficult for the 'average user'
to backport the security fix into all EOLed versions all the way back to Slackware v7.x
 
Old 04-19-2024, 02:08 PM   #4296
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,214

Rep: Reputation: 297Reputation: 297Reputation: 297
gdk-pixbuf-2.42.11
https://download.gnome.org/sources/g...2.42.11.tar.xz
 
Old 04-19-2024, 02:19 PM   #4297
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,508

Rep: Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329
Quote:
Originally Posted by volkerdi View Post
but on the bright side it seems rather useless for any sort of targeted attack.
Just like the hardware flaws on CPUs which arrived to become some pandemic (but academic) ways to gain fame, sometimes money and nothing more, while they slow down the computers all around the World.

I know, I know, they hypothetically matter for hosts servers of untrusted VMs. Which hypothetically may run Slackware as host...

Well, that's hypothetically, but the computers slow down is real.

Last edited by LuckyCyborg; 04-19-2024 at 02:28 PM.
 
1 members found this post helpful.
Old 04-19-2024, 06:14 PM   #4298
J_W
Member
 
Registered: Apr 2004
Location: Yamagata, JAPAN
Distribution: Slackware64-current
Posts: 189

Rep: Reputation: 123Reputation: 123
Issue after upgrading gdk-pixbuf2 to 2.42.11

Hi,

After upgrading gdk-pixbuf2 to "2.42.11", I found that gkrellm crashed with following messages.

Code:
gkrellm segmentation fault:    (create_monitor)
Warning: Unable to load any usable ISO8859 font
Error: Aborting: no font found
I reverted gdk-pixbuf2 to "2.42.10", then gkrellm works fine.
I have no idea how to fix this issue on gdk-pixbuf2-2.42.11.

===
[2024/04/20 11:30 Japan Time]
Thank you Pat for fixing this issue !
===

J_W

Last edited by J_W; 04-19-2024 at 09:30 PM.
 
Old 04-19-2024, 06:46 PM   #4299
saxa
Senior Member
 
Registered: Aug 2004
Location: Nova Gorica, Salvador
Distribution: Slackware
Posts: 1,214

Rep: Reputation: 297Reputation: 297Reputation: 297
Quote:
Originally Posted by biker_rat View Post
Maybe its time to pull in a few small wayland centric desktops based on wlroots for next slackware release? labWC (wayland openbox), lxqt-2.0 (explains itself), & sway (wayland i3)? The total sum in additional bytes for all binaries for all three together is small. Maybe its time for some stuff fresher than blackbox, fluxbox, and fvwm?
Why not ? I would be inclined to https://nwg-piotr.github.io/nwg-shell/ at first look seems way complete.
 
2 members found this post helpful.
Old 04-19-2024, 08:32 PM   #4300
garpu
Senior Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 1,544

Rep: Reputation: 900Reputation: 900Reputation: 900Reputation: 900Reputation: 900Reputation: 900Reputation: 900Reputation: 900
How's enlightenment these days with wayland? I've used it (off and on) for years and have always been impressed with it. I tried it a year or so ago, and it didn't play nicely with pipewire at the time. (Although that could've changed.)
 
1 members found this post helpful.
Old 04-21-2024, 05:39 AM   #4301
jloco
Member
 
Registered: Apr 2016
Location: Detroit, MI
Distribution: Slackware
Posts: 180

Rep: Reputation: 148Reputation: 148
Talking

Quote:
Originally Posted by saxa View Post
Why not ? I would be inclined to https://nwg-piotr.github.io/nwg-shell/ at first look seems way complete.
Whether this is a targeted attack or not, nwg-shell is available for slackware, packaged by your truly (or on SBo.)

But I would think simpler things, like sway, hyprland, labwc, etc fit the mold much better. There are a ton of required packages for the entire nwg-shell environment (including the aformentioned ones). But LxQT would be a perfect addition I believe (and 2.0 does work just fine!). The panel bug which was found, has been patched.
 
2 members found this post helpful.
Old 04-21-2024, 12:30 PM   #4302
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,508

Rep: Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329
Who miss the elogind-255.4 ?

I have tested and seems that it works fine after this commit:

https://github.com/elogind/elogind/c...f20197108a9dba

For your convenience, I have attached that patch bellow:

Code:
--- elogind-255.4_r2/src/login/elogind.c	2024-04-16 10:21:44.000000000 +0300
+++ elogind/src/login/elogind.c	2024-04-21 20:44:06.142658968 +0300
@@ -25,6 +25,7 @@
 #include "fd-util.h"
 #include "fileio.h"
 #include "fs-util.h"
+#include "logind-dbus.h"
 #include "mount-setup.h"
 #include "musl_missing.h"
 #include "parse-util.h"
@@ -100,6 +101,11 @@
                         log_debug_elogind( "sleep_fork PID %d waitpid() set status %d", m->sleep_fork_pid, status );
                         if ( WIFEXITED(status) || WIFSIGNALED(status) )
                                 m->sleep_fork_pid = 0;
+                        /* Tell people that they now may take a lock again */
+                        if ( m->sleep_fork_action->sleep_operation != _SLEEP_OPERATION_INVALID ) {
+                                (void) send_prepare_for( m, m->sleep_fork_action, false );
+                                m->sleep_fork_action = NULL; /* All done */
+                        }
                 }
         }
 
@@ -416,12 +422,13 @@
 int elogind_manager_new( Manager* m ) {
         int r = 0;
 
-        m->cgroups_agent_fd = -1;
-        m->pin_cgroupfs_fd  = -1;
-        m->test_run_flags   = 0;
-        m->do_interrupt     = false;
-        m->sleep_fork_pid   = 0;
-        m->tool_fork_pid    = 0;
+        m->cgroups_agent_fd  = -1;
+        m->pin_cgroupfs_fd   = -1;
+        m->test_run_flags    = 0;
+        m->do_interrupt      = false;
+        m->sleep_fork_pid    = 0;
+        m->tool_fork_pid     = 0;
+        m->sleep_fork_action = NULL;
 
         /* Init poweroff/suspend interruption */
         m->allow_poweroff_interrupts     = false;
diff -urN elogind-255.4_r2/src/login/logind-dbus.c elogind/src/login/logind-dbus.c
--- elogind-255.4_r2/src/login/logind-dbus.c	2024-04-16 10:21:44.000000000 +0300
+++ elogind/src/login/logind-dbus.c	2024-04-21 20:44:06.144658968 +0300
@@ -1730,7 +1730,11 @@
         return r;
 }
 
+#if 0 /// elogind needs to call this from elogind.c
 static int send_prepare_for(Manager *m, const HandleActionData *a, bool _active) {
+#else
+int send_prepare_for(Manager *m, const HandleActionData *a, bool _active) {
+#endif // 0
         int k = 0, r, active = _active;
 
         assert(m);
@@ -1902,6 +1906,7 @@
          * from the shutdown/sleep routines. Doing this in the main thread would
          * make it impossible to talk to ourselves.
          */
+        m->sleep_fork_action = a; /* Remember this for the SIGCHLD handler */
         forker = strjoina( "e-", handle_action_to_string( a->handle ) );
         t = safe_fork( forker,
                        FORK_LOG|FORK_REOPEN_LOG|FORK_DEATHSIG_SIGTERM|FORK_CLOSE_ALL_FDS|FORK_REARRANGE_STDIO,
@@ -1926,14 +1931,6 @@
                 log_error_errno( r, "%s: shutdown_or_sleep failed: %m", program_invocation_short_name );
         }
 
-        /* As elogind cannot rely on a systemd manager to call all
-         * sleeping processes to wake up, we have to tell them all
-         * by ourselves.
-         * Note: execute_shutdown_or_sleep() does not send the
-         *       signal unless an error occurred. */
-        if ( a->sleep_operation != _SLEEP_OPERATION_INVALID )
-                (void) send_prepare_for( m, a, false );
-
         log_debug_elogind("Exiting from %s", program_invocation_short_name);
 
         _exit( EXIT_SUCCESS );
diff -urN elogind-255.4_r2/src/login/logind-dbus.h elogind/src/login/logind-dbus.h
--- elogind-255.4_r2/src/login/logind-dbus.h	2024-04-16 10:21:44.000000000 +0300
+++ elogind/src/login/logind-dbus.h	2024-04-21 20:44:06.144658968 +0300
@@ -9,6 +9,10 @@
 #include "logind-user.h"
 #include "logind.h"
 
+#if 1 /// elogind needs to call this from elogind.c
+int send_prepare_for(Manager *m, const HandleActionData *a, bool _active);
+#endif // 1
+
 int manager_get_session_from_creds(Manager *m, sd_bus_message *message, const char *name, sd_bus_error *error, Session **ret);
 int manager_get_user_from_creds(Manager *m, sd_bus_message *message, uid_t uid, sd_bus_error *error, User **ret);
 int manager_get_seat_from_creds(Manager *m, sd_bus_message *message, const char *name, sd_bus_error *error, Seat **ret);
diff -urN elogind-255.4_r2/src/login/logind.h elogind/src/login/logind.h
--- elogind-255.4_r2/src/login/logind.h	2024-04-16 10:21:44.000000000 +0300
+++ elogind/src/login/logind.h	2024-04-21 20:44:06.146658968 +0300
@@ -84,6 +84,9 @@
         /* elogind might spawn processes to suspend/hibernate, so we need their PIDs to end them properly */
         pid_t sleep_fork_pid; /* for suspend/hibernate fork */
         pid_t tool_fork_pid;  /* for external tool fork */
+
+        /* To wake up sleeping consumers using the right operation, the manager must know what is going on. */
+        const HandleActionData *sleep_fork_action;
 #endif // 0
 
         Seat *seat0;

Last edited by LuckyCyborg; 04-21-2024 at 12:56 PM.
 
6 members found this post helpful.
Old 04-22-2024, 03:36 AM   #4303
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers)/Windows 11/Ubuntu (workstations)
Posts: 610

Rep: Reputation: 355Reputation: 355Reputation: 355Reputation: 355
Back to elogind-255.4!
@LuckyCyborg's approach means progress.
 
1 members found this post helpful.
Old 04-23-2024, 03:25 AM   #4304
teoberi
Member
 
Registered: Jan 2018
Location: Romania
Distribution: Slackware64-current (servers)/Windows 11/Ubuntu (workstations)
Posts: 610

Rep: Reputation: 355Reputation: 355Reputation: 355Reputation: 355
Perhaps Postfix should be recompiled to remove this:
Quote:
postfix/smtpd[]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 3.3.0 may not be compatible with OpenSSL 3.2.0
 
2 members found this post helpful.
Old 04-23-2024, 12:51 PM   #4305
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,511

Rep: Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475Reputation: 8475
Quote:
Originally Posted by teoberi View Post
Perhaps Postfix should be recompiled to remove this:
Doesn't 0001-openssl-micro-mismatch-nowarn.patch.gz take care of that?

EDIT: I see what I missed, thanks.
EDIT2: Actually, no I don't.

I take it this message is logged in the maillog? Any easy way for me to try to trigger this?

I've checked, and if the 0001 patch is applied, I don't get a hit grepping for "run-time library vs. compile-time header" in libpostfix-tls.so. Without the patch, I do.

Last edited by volkerdi; 04-23-2024 at 01:21 PM. Reason: more info
 
1 members found this post helpful.
  


Reply



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
Apache 2.4 requests to non-SSL site with "Upgrade-Insecure-Requests: 1" and no trailing / get redirected to default site owendelong Linux - Server 2 06-22-2021 02:08 PM
[SOLVED] Requests for -current (20151216) rworkman Slackware 3441 12-28-2017 03:50 PM

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

All times are GMT -5. The time now is 05:03 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
Open Source Consulting | Domain Registration