david [Mon, 18 Mar 2002 03:21:18 +0000 (03:21 +0000)]
Code cleanup and minor speed improvements. For the record, accessing
an internally-managed property is nearly twice as fast as accessing
one tied to methods.
curt [Mon, 11 Mar 2002 23:03:19 +0000 (23:03 +0000)]
zlib-1.1.3 had a potential security flaw which is fixed by zlib-1.1.4:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zlib Advisory 2002-03-11
zlib Compression Library Corrupts malloc Data Structures via Double Free
Original release date: March 11, 2002
Last revised: March 11, 2002
Source: This advisory is based on a CERT advisory written
by Jeffrey P. Lanza http://www.kb.cert.org/vuls/id/368819
Systems Affected
* Any software that is linked against zlib 1.1.3 or earlier
* Any data compression library derived from zlib 1.1.3 or earlier
Overview
There is a vulnerability in the zlib shared library that may introduce
vulnerabilities into any program that includes zlib. This
vulnerability has been assigned a CVE name of CAN-2002-0059
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059
I. Description
There is a vulnerability in the decompression algorithm used by the
popular zlib compression library. If an attacker is able to pass a
specially-crafted block of invalid compressed data to a program that
includes zlib, the program's attempt to decompress the crafted data
can cause the zlib routines to corrupt the internal data structures
maintained by malloc.
The vulnerability results from a programming error that causes
segments of dynamically allocated memory to be released more than once
(aka. "double-freed"). Specifically, when inftrees.c:huft_build()
encounters the crafted data, it returns an unexpected Z_MEM_ERROR to
inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to
infblock.c:inflate_blocks(), the inflate_blocks function tries to free
an internal data structure a second time.
Because this vulnerability interferes with the proper allocation and
de-allocation of dynamic memory, it may be possible for an attacker to
influence the operation of programs that include zlib. In most
circumstances, this influence will be limited to denial of service or
information leakage, but it is theoretically possible for an attacker
to insert arbitrary code into a running program. This code would be
executed with the permissions of the vulnerable program.
II. Impact
This vulnerability may introduce vulnerabilities into any program that
includes the affected library. Depending upon how and where the zlib
routines are called from the given program, the resulting
vulnerability may have one or more of the following impacts: denial of
service, information leakage, or execution of arbitrary code.
III. Solution
Upgrade your version of zlib
The maintainers of zlib have released version 1.1.4 to address this
vulnerability. Any software that is linked against or derived from an
earlier version of zlib should be upgraded immediately. The latest
version of zlib is available at http://www.zlib.org
curt [Sun, 10 Mar 2002 22:49:01 +0000 (22:49 +0000)]
Additions to the binary file format to make it *much* more flexible.
For each major primative type: points, triangles, fans, and strips, you
can specify an index list of vertices, normals, colors, and texture
coordinates. You can skip any of these you like to save on space.
Note that the work for this has only been done in the file format reader
and writer. The FlightGear loader for instance still needs to have
support for this built in.
This is is one more small step towards runway lighting.
david [Sun, 3 Mar 2002 21:22:24 +0000 (21:22 +0000)]
Modified to add an optional parameter to writeProperties to allow
*all* properties to be written, rather than just the ones flagged as
archivable. Tony Peden requested this feature to make it easier for
people to document properties.
david [Tue, 19 Feb 2002 15:20:02 +0000 (15:20 +0000)]
IMPORTANT: backwards-incompatible change to properties.
The useDefault argument for the SGPropertyNode::tie(...) methods will
invoke the setter only when there is already a property value defined;
previously, the setter was always invoked, with a default value if
necessary.
curt [Mon, 11 Feb 2002 22:27:27 +0000 (22:27 +0000)]
Decouple sg_time code from the current time(NULL), i.e. you can run the
time calculations for an alternate calendar time (i.e. if the application
is being driven from an external source of data.)
Fix a bug in sg_binobj.cxx which disrupted the 'broken down time' globally
for the entire application.
curt [Mon, 4 Feb 2002 20:23:41 +0000 (20:23 +0000)]
Pass strings by const reference instead of by value,
Made fix_path() a private member function, SGPath::fix(),
Added bool SGPath::exists(),
Added an assignment operator that acts like SGPath::append().
curt [Sat, 29 Dec 2001 00:38:04 +0000 (00:38 +0000)]
Removed metakit and zlib from the configure/build process. The
developer will need to build and install these separately if they
don't have packages already installed by their system. See
README.metakit and README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source
code trees are included with the simgear distribution (and cvs.)
curt [Sat, 29 Dec 2001 00:35:34 +0000 (00:35 +0000)]
Removed metakit and zlib from the configure/build process. The
developer will need to build and install these separately if they don't
have packages already installed by their system. See README.metakit and
README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source code
trees are included with the simgear distribution (and cvs.)
curt [Fri, 28 Dec 2001 21:27:19 +0000 (21:27 +0000)]
Updates to build system to better support automake-1.5
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
david [Wed, 12 Dec 2001 02:28:28 +0000 (02:28 +0000)]
Added trace attributes to properties:
TRACE_READ - log a message whenever the property is read.
TRACE_WRITE - log a message whenever the property is written.
The second one works only when the property value is changed through
the property manager; tied variables and accessors are not polled for
value changes because of the performance hit.
These methods end up invoking private methods
SGPropertyNode::trace_read and SGPropertyNode::trace_write. By
setting breakpoints on these methods inside a debugger, it is possible
to debug property access and find what parts of a program are reading
or writing specific property values by doing a backtrace.
In the XML property files, users can use the attributes 'trace-read'
and 'trace-write' to control tracing; the value should be 'y' to
enable tracing or 'n' to disable it (the default).
curt [Wed, 5 Dec 2001 22:31:03 +0000 (22:31 +0000)]
In certain degenerate situations on the FlightGear side when the flight
model math blows up, the lat/lon could be nan. Thus updateLocal() could
potentially called with nan arguments if FlightGear is reiniting from a
blown up state. This is a bug in FlightGear, but I've added a simple
check to catch this so updateLocal() is robust if called under these
circumstances.
curt [Tue, 27 Nov 2001 03:17:43 +0000 (03:17 +0000)]
Christian M. says it's bad to chain one constructor call from another.
I can't find anything that addresses this in Stroustrup, but I also don't
see them doing this in any of their examples. So I have rewritten this
instance to use default arguments to accomplish the same thing. I imagine
there are other instances of this same sort of thing in other classes to
be fixed at a later date.
- added sg_xml_exception class
- changed return type of readXML from bool to void (uses an exception
to report problems now)
- removed XMLVisitor::error callback
- declared new readXML function that uses a path rather than a stream
- modified existing readXML function to take an optional path parameter
- implemented sg_xml_exception class
- implemented new readXML function with path instead of stream
- modified existing readXML function to use optional path parameter
- modified readXML to throw exceptions rather than returning a bool
value on error
- modified both readProperties functions to return void, and modified
file-name variant to invoke new readXML function
- readProperties and writeProperties will now throw exceptions if there
are file I/O problems
- replace error messages with exceptions
- tunnel sg_io_exception through from nested property read, since
the C-based Expat code cannot handle exceptions
- changed default value of "archive" attribute from "y" to "n"
- modified to write out non-archivable parents if they have an
archivable descendant (i.e. archive="n" no longer kills a whole
subbranch); this makes sense now that archive defaults to "n".
- don't save the flags -- let the program handle them itself
- produce slightly less verbose output; omit n="0" in elements
projects / simgear.git / log