| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
just as the rest of the Xserver is alsow doing
|
| |
|
|
|
|
|
| |
nxagentWindowTopLevel() and nxagentNeedConnectionChange() return Boolean
nxagentPixmapIsVirtual() and nxagentIsShmPixmap(), too.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
They have been changed to tri-state variables (1, 0 and UNDEFINED)
between nxagent 1.5.0-90 and -93, for no obvious reason.
|
|
|
|
|
| |
Many variables are used as Booleans. By adding the Bool define to
Options.h we can now make that visible.
|
|
|
|
| |
and add the missing init code.
|
|
|
|
|
|
|
| |
Adaptive, Composite, DeviceControl, DeviceControlUserDefined,
IgnoreVisibility, InhibitXkb, Nested, Menu, MagicPixel, Persistent,
Reset, ResetzKeyboardAtResume, SharedMemory, SharedPixmaps, Streaming,
UseDamage, ViewOnly, Xdmcp, Xinerama
|
|
|
|
| |
The already where Booleans but where not using True/False values everywhere
|
|
|
|
|
| |
There's no need/sense in having a tri-state with the third state being
UNDEFINED.
|
|
|
|
| |
Fixes ArcticaProject/nx-libs#903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backported from X.org:
From 446ff2d3177087b8173fa779fa5b77a2a128988b Mon Sep 17 00:00:00 2001
From: Matthieu Herrb <matthieu@herrb.eu>
Date: Thu, 12 Nov 2020 19:15:07 +0100
Subject: [PATCH] Check SetMap request length carefully.
Avoid out of bounds memory accesses on too short request.
ZDI-CAN 11572 / CVE-2020-14360
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Fixes ArcticaProject/nx-libs#972.
|
|
|
|
| |
Fixes ArcticaProject/nx-libs#983
|
|
|
|
| |
causing DEBUG output in regular builds.
|
|
|
|
| |
call (FreeFontName -> FreeFontNames). Fixes FTBFS on Ubuntu 14.04 and 16.04.
|
| |
|
|\
| |
| |
| | |
Attributes GH PR #963: https://github.com/ArcticaProject/nx-libs/pull/963
|
| | |
|
| |
| |
| |
| | |
(better macro name).
|
| |
| |
| |
| | |
Fixes ArcticaProject/nx-libs#941
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Png.c: In function ‘PngWriteData’:
Png.c:603:38: warning: declaration of ‘png_ptr’ shadows a global declaration [-Wshadow]
603 | static void PngWriteData(png_structp png_ptr, png_bytep data, png_size_t length)
| ~~~~~~~~~~~~^~~~~~~
Png.c:77:13: note: shadowed declaration is here
77 | png_structp png_ptr;
| ^~~~~~~
Png.c: In function ‘PngFlushData’:
Png.c:610:38: warning: declaration of ‘png_ptr’ shadows a global declaration [-Wshadow]
610 | static void PngFlushData(png_structp png_ptr)
| ~~~~~~~~~~~~^~~~~~~
Png.c:77:13: note: shadowed declaration is here
77 | png_structp png_ptr;
| ^~~~~~~
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"warning: declaration of '<something>' shadows a member of 'this'
This shows up in gcc 4.8.5 and has been fixed in gcc 5.0, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Change the variable names anyway to be on the safe side.
Fixes ArcticaProject/nx-libs#958
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In file included from Proxy.h:39:0,
from ServerProxy.h:32,
from ServerProxy.cpp:36:
Channel.h: In member function 'int Channel::handleEncodeIdentity(EncodeBuffer&, ChannelCache*, MessageStore*, const unsigned char*, unsigned int, int)':
Channel.h:369:3: warning: declaration of 'bigEndian' shadows a member of 'this' [-Wshadow]
{
^
Channel.h: In member function 'int Channel::handleDecodeIdentity(DecodeBuffer&, ChannelCache*, MessageStore*, unsigned char*&, unsigned int&, int, WriteBuffer*)':
Channel.h:378:3: warning: declaration of 'bigEndian' shadows a member of 'this' [-Wshadow]
{
^
RHEL7's g++ 4.8.5 reports this while Debian's g++ 10.2.0-15 does
not. This is described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 and fixed in gcc
5.0.
Rename the variables anyway to be on the safe side.
Fixes ArcticaProject/nx-libs#956
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
*** ERROR: ambiguous python shebang in /usr/bin/nxdialog: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
Fedora offers a pythfix.py but I could not test with that so I simply
used sed...
Fixes ArcticaProject/nx-libs#955
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
into 3.6.x
Attributes GH PR #961: https://github.com/ArcticaProject/nx-libs/pull/961
Approved by Ulrich Sibiller <uli42@gmx.de>, Tue, 03 Nov 2020 08:14:04 -0800
|
| | |
|
|/
|
|
| |
(better macro name).
|
|\
| |
| |
| | |
Attributes GH PR #949: https://github.com/ArcticaProject/nx-libs/pull/949
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==15332== 2,500 (96 direct, 2,404 indirect) bytes in 6 blocks are definitely lost in loss record 324 of 342
==15332== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15332== by 0x5748B9E: FontFileStartListFonts (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332== by 0x5748C4A: FontFileStartListFontsAndAliases (in /usr/lib/x86_64-linux-gnu/libXfont.so.1.4.1)
==15332== by 0x42859A: nxdoListFontsAndAliases (NXdixfonts.c:1163)
==15332== by 0x42C0E0: nxOpenFont (NXdixfonts.c:1541)
==15332== by 0x43392E: ProcOpenFont (NXdispatch.c:902)
==15332== by 0x434585: Dispatch (NXdispatch.c:482)
==15332== by 0x40EF77: main (main.c:355)
FontFileStartListFonts[AndAliases]() allocates some private data. This
data is used by subsequent calls of FontFileListNextFontOrAlias() in a
loop. (Only) the last call to that function will free() the private
data and return with BadFontName. FontFileListNextFontOrAlias() is
the only libXfont function that free()s the private data.
In nxagent the loop is exited as soon as a font exists both locally
and remote. Therefore the private data would never be free()d.
Solution: do not break the loop but store the first matching result
and let the loop run to the end, ignoring all following results.
Disadvantage: this can mean hundreds of extra iterations for
nothing. I have done no investigation of the time penalty this might
cause.
Unfortunately this is the only clean way I have found so far.
An unclean solution has also been implemented. It can be activated by
defining BREAK_XFONT_LOOP. In that case the private data is handled in
nxagent by taking assumptions about its structure (taken from the
libXfont source). That will break if libXfont changes its internal
handling of the private. Therefore it is discouraged.
An third alternative would be to drop using libXfont from the
system. Instead fork libXfont to the nx-libs tree, add some patches
link to that library statically.
Fixes ArcticaProject/nx-libs#586
|
|\
| |
| |
| | |
Attributes GH PR #952: https://github.com/ArcticaProject/nx-libs/pull/952
|