This commit will not completely remove all Imake files, specifically
those for sections that have not been completed yet.
Also, the databases dir has been moved to databases-delete-later until
we have everything building and installed properly.
Summary:
cde/config/cf/DtInfo.tmpl - add RISCVArchitecture as little endian
cde/config/cf/Imake.cf - add AArch64Architecture for NetBSD
cde/config/cf/Imake.cf - add RISCVArchitecture for Linux
cde/config/cf/linux.cf - add RISCVArchitecture bit order
cde/lib/DtHelp/Imakefile - add -ljpeg for OpenBSD
These system can support PAM, but it requires a port of the NetBSD
module to do so. As a result, this support is disabled by default.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253073 for a
patch to add this support to the OS. Then you can set HasPamLibrary
to YES in the respective .cf files, rebuild CDE, and try it out.
Marco Ivaldi pointed me to some unsafe code in ParseJob.c. I do not
have a sun machine (well, not currently operational anyway), so the
code is not tested. But seriously, this is some horrible code. This
local parser for sun needs to be rewritten!
Summary:
cde/config/cf/DtInfo.tmpl - add RISCVArchitecture as little endian
cde/config/cf/Imake.cf - add AArch64Architecture for NetBSD
cde/config/cf/Imake.cf - add RISCVArchitecture for Linux
cde/config/cf/linux.cf - add RISCVArchitecture bit order
cde/lib/DtHelp/Imakefile - add -ljpeg for OpenBSD
These system can support PAM, but it requires a port of the NetBSD
module to do so. As a result, this support is disabled by default.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253073 for a
patch to add this support to the OS. Then you can set HasPamLibrary
to YES in the respective .cf files, rebuild CDE, and try it out.
Marco Ivaldi pointed me to some unsafe code in ParseJob.c. I do not
have a sun machine (well, not currently operational anyway), so the
code is not tested. But seriously, this is some horrible code. This
local parser for sun needs to be rewritten!
make distclean ignores the language definitions, as it should.
However, we had options that suggested that the Japanese locale was
supported. Distclean would decend into that locale directory and
fail, since of course we do not actually support that locale and it is
not currently buildable.
Remove a pile of old SGML stuff we no longer need in dtdocbook since
we use NSGMLS.
Use some TCL macros from m4/tcl.m4 to loacate and use information in
the tclConfig.sh script installed with TCL. I had to modify it to
export TCL_INCLUDE_SPEC, which was present but not imported.
So this is going to be tricky/painful getting this parser fully
operational. It's pretty hairy with various interdependencies and
generated code.
It's rather complicated how each sub dir depends on the previous one.
Also, the parser subdir has dependencies on the helptag subdir, and
vice-versa, so some hackery was needed to get that to work.
Due to the wierd interdepencencies between helptag and parser,
we disable parallel builds there.
This is some really horrible code and design - not surprising since it
dates to 1989.
I think it should just be removed -- who can maintain or refactor this
code?
Also, dthelp_htag1 is now built in pass1/parser/, not in
pass1/helptag/ as it used to be.
The localized/utils/merge utility used hardcoded temporary filenames
to do its thing. This prevented any Makefiles that called merge from
enabling parallel builds in order avoid the file collisions that would
result.
Now we:
- use filenames that embed the PID in them, making them unique
per-process
- place them in /tmp, rather than the current directory
As a result, we can now re-enable parallel builds for localized
app-defaults, config, and types.
The appmanager action files (/usr/dt/appconfig/appmanager/*) are now
created properly for the main 4 languages supported. As usual, the
en_US.UTF-8 locale is a symlink to C.
These files were previously created via the UDB database files via
imake. Obviously we aren't going to be using those in autotools.
So, each language now has an appmanager/ dir in
programs/localized/$LANG/ that will create them properly on a make and
make install. It uses a new appmgr.am template in localized/templates
to do this.
This also means all of these languages now can use the new actions
added by Antonis, even though they are not translated, they are at
least usable in those languages now.
Patch from Peter G.
Note, this is temporary - eventually we will want to use the system
nsgmls/onsgmls to handle this and remove our ancient copy of nsgmls.
Some of these functions were returning pointers cast as integers,
which of course is bad on a 64b LP64 systems.
This code should probably just be refactored at some point. There may
be other hidden issues, and all the casting just sucks.
This reverts commit 08b6281f60.
The Login manager is reponsible for setting the correct language
(LANG, etc) information before starting a CDE session.
This was supplied by Antonis Tsolomitis
<antonis.tsolomitis@gmail.com>, and allows you to hardcode a LANG
setting before starting up CDE, if your login manager does not do that
for you.
Marco Ivaldi <marco.ivaldi@mediaservice.net> has identified 3
vulnerabilities in CDE.
Two of them could affect our CDE (open-source version), while the 3rd
(sdtcm_convert) is Solaris specific.
The two vulnerabilities, both of which affect dtsession could allow a
local privilege escalation to root. A POC exists for Solaris. The
POC will not function on our CDE for two main reasons:
- the POC is Solaris specific
- The overflowed variables in question are allocated on the heap,
whereas in Solaris these variables are located on the stack.
The first vulnerability allows an extra long palette name to be used
to cause a crash via insufficient validation in
SrvPalette.c:CheckMonitor().
The second, which has not yet been assigned a CERT CVE resides in
SmCreateDirs.c:_DtCreateDtDirs() in libDtSvc. Due to insufficient
bounds checking, a crash or corruption can be achieved by using a very
long DISPLAY name.
This one is considered difficult to exploit, and no POC code is
available at this time. CDE 2.x code-bases are also listed as not
vulnerable, however some work has been done anyway to do some proper
bounds checking in this function.
The following text portions are copied from the relevant advisories,
which have not been released as of this writing.
NOTE: Oracle CDE does NOT use CDE 2.3.0a or earlier as mentioned
below. They are completely different code-bases):
Regarding CVE-2020-2692:
A buffer overflow in the CheckMonitor() function in the Common
Desktop Environment 2.3.0a and earlier, as distributed with Oracle
Solaris 10 1/13 (Update 11) and earlier, allows local users to gain
root privileges via a long palette name passed to dtsession in a
malicious .Xdefaults file.
Note that Oracle Solaris CDE is based on the original CDE 1.x train,
which is different from the CDE 2.x codebase that was later open
sourced. Most notably, the vulnerable buffer in the Oracle Solaris
CDE is stack-based, while in the open source version it is
heap-based.
Regarding the DtSvc bug, which does not currently have a CERT CVE:
A difficult to exploit stack-based buffer overflow in the
_DtCreateDtDirs() function in the Common Desktop Environment version
distributed with Oracle Solaris 10 1/13 (Update 11) and earlier may
allow local users to corrupt memory and potentially execute
arbitrary code in order to escalate privileges via a long X11
display name. The vulnerable function is located in the libDtSvc
library and can be reached by executing the setuid program
dtsession.
The open source version of CDE (based on the CDE 2.x codebase) is
not affected.
Jon Trulson