Checked in the following released items:

xkeyboard-config-1.4.tar.gz
ttf-bitstream-vera-1.10.tar.gz
font-alias-1.0.1.tar.gz
font-sun-misc-1.0.0.tar.gz
font-sun-misc-1.0.0.tar.gz
font-sony-misc-1.0.0.tar.gz
font-schumacher-misc-1.0.0.tar.gz
font-mutt-misc-1.0.0.tar.gz
font-misc-misc-1.0.0.tar.gz
font-misc-meltho-1.0.0.tar.gz
font-micro-misc-1.0.0.tar.gz
font-jis-misc-1.0.0.tar.gz
font-isas-misc-1.0.0.tar.gz
font-dec-misc-1.0.0.tar.gz
font-daewoo-misc-1.0.0.tar.gz
font-cursor-misc-1.0.0.tar.gz
font-arabic-misc-1.0.0.tar.gz
font-winitzki-cyrillic-1.0.0.tar.gz
font-misc-cyrillic-1.0.0.tar.gz
font-cronyx-cyrillic-1.0.0.tar.gz
font-screen-cyrillic-1.0.1.tar.gz
font-xfree86-type1-1.0.1.tar.gz
font-adobe-utopia-type1-1.0.1.tar.gz
font-ibm-type1-1.0.0.tar.gz
font-bitstream-type1-1.0.0.tar.gz
font-bitstream-speedo-1.0.0.tar.gz
font-bh-ttf-1.0.0.tar.gz
font-bh-type1-1.0.0.tar.gz
font-bitstream-100dpi-1.0.0.tar.gz
font-bh-lucidatypewriter-100dpi-1.0.0.tar.gz
font-bh-100dpi-1.0.0.tar.gz
font-adobe-utopia-100dpi-1.0.1.tar.gz
font-adobe-100dpi-1.0.0.tar.gz
font-util-1.0.1.tar.gz
font-bitstream-75dpi-1.0.0.tar.gz
font-bh-lucidatypewriter-75dpi-1.0.0.tar.gz
font-adobe-utopia-75dpi-1.0.1.tar.gz
font-bh-75dpi-1.0.0.tar.gz
bdftopcf-1.0.1.tar.gz
font-adobe-75dpi-1.0.0.tar.gz
mkfontscale-1.0.6.tar.gz
openssl-0.9.8k.tar.gz
bigreqsproto-1.0.2.tar.gz
xtrans-1.2.2.tar.gz
resourceproto-1.0.2.tar.gz
inputproto-1.4.4.tar.gz
compositeproto-0.4.tar.gz
damageproto-1.1.0.tar.gz
zlib-1.2.3.tar.gz
xkbcomp-1.0.5.tar.gz
freetype-2.3.9.tar.gz
pthreads-w32-2-8-0-release.tar.gz
pixman-0.12.0.tar.gz
kbproto-1.0.3.tar.gz
evieext-1.0.2.tar.gz
fixesproto-4.0.tar.gz
recordproto-1.13.2.tar.gz
randrproto-1.2.2.tar.gz
scrnsaverproto-1.1.0.tar.gz
renderproto-0.9.3.tar.gz
xcmiscproto-1.1.2.tar.gz
fontsproto-2.0.2.tar.gz
xextproto-7.0.3.tar.gz
xproto-7.0.14.tar.gz
libXdmcp-1.0.2.tar.gz
libxkbfile-1.0.5.tar.gz
libfontenc-1.0.4.tar.gz
libXfont-1.3.4.tar.gz
libX11-1.1.5.tar.gz
libXau-1.0.4.tar.gz
libxcb-1.1.tar.gz
xorg-server-1.5.3.tar.gz

1 files changed, 476 insertions, 0 deletions

diff --git a/openssl/MacOS/Randomizer.cpp b/openssl/MacOS/Randomizer.cpp
new file mode 100644
index 000000000..cceb6bde4
--- /dev/null
+++ b/openssl/MacOS/Randomizer.cpp
@@ -0,0 +1,476 @@
+/* 
+------- Strong random data generation on a Macintosh (pre - OS X) ------
+		
+--	GENERAL: We aim to generate unpredictable bits without explicit
+	user interaction. A general review of the problem may be found
+	in RFC 1750, "Randomness Recommendations for Security", and some
+	more discussion, of general and Mac-specific issues has appeared
+	in "Using and Creating Cryptographic- Quality Random Numbers" by
+	Jon Callas (www.merrymeet.com/jon/usingrandom.html).
+
+	The data and entropy estimates provided below are based on my
+	limited experimentation and estimates, rather than by any
+	rigorous study, and the entropy estimates tend to be optimistic.
+	They should not be considered absolute.
+
+	Some of the information being collected may be correlated in
+	subtle ways. That includes mouse positions, timings, and disk
+	size measurements. Some obvious correlations will be eliminated
+	by the programmer, but other, weaker ones may remain. The
+	reliability of the code depends on such correlations being
+	poorly understood, both by us and by potential interceptors.
+
+	This package has been planned to be used with OpenSSL, v. 0.9.5.
+	It requires the OpenSSL function RAND_add. 
+
+--	OTHER WORK: Some source code and other details have been
+	published elsewhere, but I haven't found any to be satisfactory
+	for the Mac per se:
+
+	* The Linux random number generator (by Theodore Ts'o, in
+	  drivers/char/random.c), is a carefully designed open-source
+	  crypto random number package. It collects data from a variety
+	  of sources, including mouse, keyboard and other interrupts.
+	  One nice feature is that it explicitly estimates the entropy
+	  of the data it collects. Some of its features (e.g. interrupt
+	  timing) cannot be reliably exported to the Mac without using
+	  undocumented APIs.
+
+	* Truerand by Don P. Mitchell and Matt Blaze uses variations
+	  between different timing mechanisms on the same system. This
+	  has not been tested on the Mac, but requires preemptive
+	  multitasking, and is hardware-dependent, and can't be relied
+	  on to work well if only one oscillator is present.
+
+	* Cryptlib's RNG for the Mac (RNDMAC.C by Peter Gutmann),
+	  gathers a lot of information about the machine and system
+	  environment. Unfortunately, much of it is constant from one
+	  startup to the next. In other words, the random seed could be
+	  the same from one day to the next. Some of the APIs are
+	  hardware-dependent, and not all are compatible with Carbon (OS
+	  X). Incidentally, the EGD library is based on the UNIX entropy
+	  gathering methods in cryptlib, and isn't suitable for MacOS
+	  either.
+
+	* Mozilla (and perhaps earlier versions of Netscape) uses the
+	  time of day (in seconds) and an uninitialized local variable
+	  to seed the random number generator. The time of day is known
+	  to an outside interceptor (to within the accuracy of the
+	  system clock). The uninitialized variable could easily be
+	  identical between subsequent launches of an application, if it
+	  is reached through the same path.
+
+	* OpenSSL provides the function RAND_screen(), by G. van
+	  Oosten, which hashes the contents of the screen to generate a
+	  seed. This is not useful for an extension or for an
+	  application which launches at startup time, since the screen
+	  is likely to look identical from one launch to the next. This
+	  method is also rather slow.
+
+	* Using variations in disk drive seek times has been proposed
+	  (Davis, Ihaka and Fenstermacher, world.std.com/~dtd/;
+	  Jakobsson, Shriver, Hillyer and Juels,
+	  www.bell-labs.com/user/shriver/random.html). These variations
+	  appear to be due to air turbulence inside the disk drive
+	  mechanism, and are very strongly unpredictable. Unfortunately
+	  this technique is slow, and some implementations of it may be
+	  patented (see Shriver's page above.) It of course cannot be
+	  used with a RAM disk.
+
+--	TIMING: On the 601 PowerPC the time base register is guaranteed
+	to change at least once every 10 addi instructions, i.e. 10
+	cycles. On a 60 MHz machine (slowest PowerPC) this translates to
+	a resolution of 1/6 usec. Newer machines seem to be using a 10
+	cycle resolution as well.
+	
+	For 68K Macs, the Microseconds() call may be used. See Develop
+	issue 29 on the Apple developer site
+	(developer.apple.com/dev/techsupport/develop/issue29/minow.html)
+	for information on its accuracy and resolution. The code below
+	has been tested only on PowerPC based machines.
+
+	The time from machine startup to the launch of an application in
+	the startup folder has a variance of about 1.6 msec on a new G4
+	machine with a defragmented and optimized disk, most extensions
+	off and no icons on the desktop. This can be reasonably taken as
+	a lower bound on the variance. Most of this variation is likely
+	due to disk seek time variability. The distribution of startup
+	times is probably not entirely even or uncorrelated. This needs
+	to be investigated, but I am guessing that it not a majpor
+	problem. Entropy = log2 (1600/0.166) ~= 13 bits on a 60 MHz
+	machine, ~16 bits for a 450 MHz machine.
+
+	User-launched application startup times will have a variance of
+	a second or more relative to machine startup time. Entropy >~22
+	bits.
+
+	Machine startup time is available with a 1-second resolution. It
+	is predictable to no better a minute or two, in the case of
+	people who show up punctually to work at the same time and
+	immediately start their computer. Using the scheduled startup
+	feature (when available) will cause the machine to start up at
+	the same time every day, making the value predictable. Entropy
+	>~7 bits, or 0 bits with scheduled startup.
+
+	The time of day is of course known to an outsider and thus has 0
+	entropy if the system clock is regularly calibrated.
+
+--	KEY TIMING: A  very fast typist (120 wpm) will have a typical
+	inter-key timing interval of 100 msec. We can assume a variance
+	of no less than 2 msec -- maybe. Do good typists have a constant
+	rhythm, like drummers? Since what we measure is not the
+	key-generated interrupt but the time at which the key event was
+	taken off the event queue, our resolution is roughly the time
+	between process switches, at best 1 tick (17 msec). I  therefore
+	consider this technique questionable and not very useful for
+	obtaining high entropy data on the Mac.
+
+--	MOUSE POSITION AND TIMING: The high bits of the mouse position
+	are far from arbitrary, since the mouse tends to stay in a few
+	limited areas of the screen. I am guessing that the position of
+	the mouse is arbitrary within a 6 pixel square. Since the mouse
+	stays still for long periods of time, it should be sampled only
+	after it was moved, to avoid correlated data. This gives an
+	entropy of log2(6*6) ~= 5 bits per measurement.
+
+	The time during which the mouse stays still can vary from zero
+	to, say, 5 seconds (occasionally longer). If the still time is
+	measured by sampling the mouse during null events, and null
+	events are received once per tick, its resolution is 1/60th of a
+	second, giving an entropy of log2 (60*5) ~= 8 bits per
+	measurement. Since the distribution of still times is uneven,
+	this estimate is on the high side.
+
+	For simplicity and compatibility across system versions, the
+	mouse is to be sampled explicitly (e.g. in the event loop),
+	rather than in a time manager task.
+
+--	STARTUP DISK TOTAL FILE SIZE: Varies typically by at least 20k
+	from one startup to the next, with 'minimal' computer use. Won't
+	vary at all if machine is started again immediately after
+	startup (unless virtual memory is on), but any application which
+	uses the web and caches information to disk is likely to cause
+	this much variation or more. The variation is probably not
+	random, but I don't know in what way. File sizes tend to be
+	divisible by 4 bytes since file format fields are often
+	long-aligned. Entropy > log2 (20000/4) ~= 12 bits.
+	
+--	STARTUP DISK FIRST AVAILABLE ALLOCATION BLOCK: As the volume
+	gets fragmented this could be anywhere in principle. In a
+	perfectly unfragmented volume this will be strongly correlated
+	with the total file size on the disk. With more fragmentation
+	comes less certainty. I took the variation in this value to be
+	1/8 of the total file size on the volume.
+
+--	SYSTEM REQUIREMENTS: The code here requires System 7.0 and above
+	(for Gestalt and Microseconds calls). All the calls used are
+	Carbon-compatible.
+*/
+
+/*------------------------------ Includes ----------------------------*/
+
+#include "Randomizer.h"
+
+// Mac OS API
+#include <Files.h>
+#include <Folders.h>
+#include <Events.h>
+#include <Processes.h>
+#include <Gestalt.h>
+#include <Resources.h>
+#include <LowMem.h>
+
+// Standard C library
+#include <stdlib.h>
+#include <math.h>
+
+/*---------------------- Function declarations -----------------------*/
+
+// declared in OpenSSL/crypto/rand/rand.h
+extern "C" void RAND_add (const void *buf, int num, double entropy);
+
+unsigned long GetPPCTimer (bool is601);	// Make it global if needed
+					// elsewhere
+
+/*---------------------------- Constants -----------------------------*/
+
+#define kMouseResolution 6		// Mouse position has to differ
+					// from the last one by this
+					// much to be entered
+#define kMousePositionEntropy 5.16	// log2 (kMouseResolution**2)
+#define kTypicalMouseIdleTicks 300.0	// I am guessing that a typical
+					// amount of time between mouse
+					// moves is 5 seconds
+#define kVolumeBytesEntropy 12.0	// about log2 (20000/4),
+					// assuming a variation of 20K
+					// in total file size and
+					// long-aligned file formats.
+#define kApplicationUpTimeEntropy 6.0	// Variance > 1 second, uptime
+					// in ticks  
+#define kSysStartupEntropy 7.0		// Entropy for machine startup
+					// time
+
+
+/*------------------------ Function definitions ----------------------*/
+
+CRandomizer::CRandomizer (void)
+{
+	long	result;
+	
+	mSupportsLargeVolumes =
+		(Gestalt(gestaltFSAttr, &result) == noErr) &&
+		((result & (1L << gestaltFSSupports2TBVols)) != 0);
+	
+	if (Gestalt (gestaltNativeCPUtype, &result) != noErr)
+	{
+		mIsPowerPC = false;
+		mIs601 = false;
+	}
+	else
+	{
+		mIs601 = (result == gestaltCPU601);
+		mIsPowerPC = (result >= gestaltCPU601);
+	}
+	mLastMouse.h = mLastMouse.v = -10;	// First mouse will
+						// always be recorded
+	mLastPeriodicTicks = TickCount();
+	GetTimeBaseResolution ();
+	
+	// Add initial entropy
+	AddTimeSinceMachineStartup ();
+	AddAbsoluteSystemStartupTime ();
+	AddStartupVolumeInfo ();
+	AddFiller ();
+}
+
+void CRandomizer::PeriodicAction (void)
+{
+	AddCurrentMouse ();
+	AddNow (0.0);	// Should have a better entropy estimate here
+	mLastPeriodicTicks = TickCount();
+}
+
+/*------------------------- Private Methods --------------------------*/
+
+void CRandomizer::AddCurrentMouse (void)
+{
+	Point mouseLoc;
+	unsigned long lastCheck;	// Ticks since mouse was last
+					// sampled
+
+#if TARGET_API_MAC_CARBON
+	GetGlobalMouse (&mouseLoc);
+#else
+	mouseLoc = LMGetMouseLocation();
+#endif
+	
+	if (labs (mLastMouse.h - mouseLoc.h) > kMouseResolution/2 &&
+	    labs (mLastMouse.v - mouseLoc.v) > kMouseResolution/2)
+		AddBytes (&mouseLoc, sizeof (mouseLoc),
+				kMousePositionEntropy);
+	
+	if (mLastMouse.h == mouseLoc.h && mLastMouse.v == mouseLoc.v)
+		mMouseStill ++;
+	else
+	{
+		double entropy;
+		
+		// Mouse has moved. Add the number of measurements for
+		// which it's been still. If the resolution is too
+		// coarse, assume the entropy is 0.
+
+		lastCheck = TickCount() - mLastPeriodicTicks;
+		if (lastCheck <= 0)
+			lastCheck = 1;
+		entropy = log2l
+			(kTypicalMouseIdleTicks/(double)lastCheck);
+		if (entropy < 0.0)
+			entropy = 0.0;
+		AddBytes (&mMouseStill, sizeof (mMouseStill), entropy);
+		mMouseStill = 0;
+	}
+	mLastMouse = mouseLoc;
+}
+
+void CRandomizer::AddAbsoluteSystemStartupTime (void)
+{
+	unsigned long	now;		// Time in seconds since
+					// 1/1/1904
+	GetDateTime (&now);
+	now -= TickCount() / 60;	// Time in ticks since machine
+					// startup
+	AddBytes (&now, sizeof (now), kSysStartupEntropy);
+}
+
+void CRandomizer::AddTimeSinceMachineStartup (void)
+{
+	AddNow (1.5);			// Uncertainty in app startup
+					// time is > 1.5 msec (for
+					// automated app startup).
+}
+
+void CRandomizer::AddAppRunningTime (void)
+{
+	ProcessSerialNumber PSN;
+	ProcessInfoRec		ProcessInfo;
+	
+	ProcessInfo.processInfoLength = sizeof (ProcessInfoRec);
+	ProcessInfo.processName = nil;
+	ProcessInfo.processAppSpec = nil;
+	
+	GetCurrentProcess (&PSN);
+	GetProcessInformation (&PSN, &ProcessInfo);
+
+	// Now add the amount of time in ticks that the current process
+	// has been active
+
+	AddBytes (&ProcessInfo, sizeof (ProcessInfoRec),
+			kApplicationUpTimeEntropy);
+}
+
+void CRandomizer::AddStartupVolumeInfo (void)
+{
+	short			vRefNum;
+	long			dirID;
+	XVolumeParam	pb;
+	OSErr			err;
+	
+	if (!mSupportsLargeVolumes)
+		return;
+		
+	FindFolder (kOnSystemDisk, kSystemFolderType, kDontCreateFolder,
+			&vRefNum, &dirID);
+	pb.ioVRefNum = vRefNum;
+	pb.ioCompletion = 0;
+	pb.ioNamePtr = 0;
+	pb.ioVolIndex = 0;
+	err = PBXGetVolInfoSync (&pb);
+	if (err != noErr)
+		return;
+		
+	// Base the entropy on the amount of space used on the disk and
+	// on the next available allocation block. A lot else might be
+	// unpredictable, so might as well toss the whole block in. See
+	// comments for entropy estimate justifications.
+
+	AddBytes (&pb, sizeof (pb),
+		kVolumeBytesEntropy +
+		log2l (((pb.ioVTotalBytes.hi - pb.ioVFreeBytes.hi)
+				* 4294967296.0D +
+			(pb.ioVTotalBytes.lo - pb.ioVFreeBytes.lo))
+				/ pb.ioVAlBlkSiz - 3.0));
+}
+
+/*
+	On a typical startup CRandomizer will come up with about 60
+	bits of good, unpredictable data. Assuming no more input will
+	be available, we'll need some more lower-quality data to give
+	OpenSSL the 128 bits of entropy it desires. AddFiller adds some
+	relatively predictable data into the soup.
+*/
+
+void CRandomizer::AddFiller (void)
+{
+	struct
+	{
+		ProcessSerialNumber psn;	// Front process serial
+						// number
+		RGBColor	hiliteRGBValue;	// User-selected
+						// highlight color
+		long		processCount;	// Number of active
+						// processes
+		long		cpuSpeed;	// Processor speed
+		long		totalMemory;	// Total logical memory
+						// (incl. virtual one)
+		long		systemVersion;	// OS version
+		short		resFile;	// Current resource file
+	} data;
+	
+	GetNextProcess ((ProcessSerialNumber*) kNoProcess);
+	while (GetNextProcess (&data.psn) == noErr)
+		data.processCount++;
+	GetFrontProcess (&data.psn);
+	LMGetHiliteRGB (&data.hiliteRGBValue);
+	Gestalt (gestaltProcClkSpeed, &data.cpuSpeed);
+	Gestalt (gestaltLogicalRAMSize, &data.totalMemory);
+	Gestalt (gestaltSystemVersion, &data.systemVersion);
+	data.resFile = CurResFile ();
+	
+	// Here we pretend to feed the PRNG completely random data. This
+	// is of course false, as much of the above data is predictable
+	// by an outsider. At this point we don't have any more
+	// randomness to add, but with OpenSSL we must have a 128 bit
+	// seed before we can start. We just add what we can, without a
+	// real entropy estimate, and hope for the best.
+
+	AddBytes (&data, sizeof(data), 8.0 * sizeof(data));
+	AddCurrentMouse ();
+	AddNow (1.0);
+}
+
+//-------------------  LOW LEVEL ---------------------
+
+void CRandomizer::AddBytes (void *data, long size, double entropy)
+{
+	RAND_add (data, size, entropy * 0.125);	// Convert entropy bits
+						// to bytes
+}
+
+void CRandomizer::AddNow (double millisecondUncertainty)
+{
+	long time = SysTimer();
+	AddBytes (&time, sizeof (time), log2l (millisecondUncertainty *
+			mTimebaseTicksPerMillisec));
+}
+
+//----------------- TIMING SUPPORT ------------------
+
+void CRandomizer::GetTimeBaseResolution (void)
+{	
+#ifdef __powerc
+	long speed;
+	
+	// gestaltProcClkSpeed available on System 7.5.2 and above
+	if (Gestalt (gestaltProcClkSpeed, &speed) != noErr)
+		// Only PowerPCs running pre-7.5.2 are 60-80 MHz
+		// machines.
+		mTimebaseTicksPerMillisec =  6000.0D;
+	// Assume 10 cycles per clock update, as in 601 spec. Seems true
+	// for later chips as well.
+	mTimebaseTicksPerMillisec = speed / 1.0e4D;
+#else
+	// 68K VIA-based machines (see Develop Magazine no. 29)
+	mTimebaseTicksPerMillisec = 783.360D;
+#endif
+}
+
+unsigned long CRandomizer::SysTimer (void)	// returns the lower 32
+						// bit of the chip timer
+{
+#ifdef __powerc
+	return GetPPCTimer (mIs601);
+#else
+	UnsignedWide usec;
+	Microseconds (&usec);
+	return usec.lo;
+#endif
+}
+
+#ifdef __powerc
+// The timebase is available through mfspr on 601, mftb on later chips.
+// Motorola recommends that an 601 implementation map mftb to mfspr
+// through an exception, but I haven't tested to see if MacOS actually
+// does this. We only sample the lower 32 bits of the timer (i.e. a
+// few minutes of resolution)
+
+asm unsigned long GetPPCTimer (register bool is601)
+{
+	cmplwi	is601, 0	// Check if 601
+	bne	_601		// if non-zero goto _601
+	mftb  	r3		// Available on 603 and later.
+	blr			// return with result in r3
+_601:
+	mfspr r3, spr5  	// Available on 601 only.
+				// blr inserted automatically
+}
+#endif