RAD_MICROSOFT_MS_MPPE_ENCRYPTION_POLICY
RAD_MICROSOFT_MS_MPPE_ENCRYPTION_TYPES
RAD_MICROSOFT_MS_MPPE_RECV_KEY
RAD_MICROSOFT_MS_MPPE_SEND_KEY
These attributes may be supplied by a RADIUS server when MSCHAPv2 is
used to authenticate.
It *should* now be possible to build ppp with -DNODES and still support
CHAP/MSCHAP/MSCHAPv2/MPPE via a RADIUS server, but the code isn't yet
smart enough to do that (building with -DNODES just looses these
facilities).
Sponsored by: Monzoon
rad_request_authenticator()
Returns the Request-Authenticator relevant to the most recently received
RADIUS response.
rad_server_secret()
Returns the Shared Secret relevant to the most recently received
RADIUS response.
Neither of these functions should be necessary, however, the
MS-MPPE-Recv-Key and MS-MPPE-Send-Key Microsoft Vendor Specific
attributes are supplied in a mangled (encrypted) format, requiring
this information to demangle.
It's not clear whether these functions should be replaced with a
rad_demangle() function or whether these attributes are one-offs.
Sponsored by: Monzoon
as of 4.6-RELEASE (or earlier). This commit shouldn't have any immediate
effect, but we'll eventually use some stylesheet magic to remove
the historic release notes from the output stream. This will have
the effect of making the 5.0-RELEASE release notes contain material
only relevent to -CURRENT *or* recently MFC-ed to 4-STABLE.
The stylesheet fixes will follow later, once I work out a couple more
details. I wanted to get this commit done now, before anything gets
MFC-ed in the post-4.6 world (so we don't need to go back later and
figure this out).
If a historic release note gets modified, it may very well be
appropriate to remove its historic attribute.
goto target was so the cache could be freed. So free the cache after
done: rather then before done: (!)
Submitted by: Gavin Atkinson <gavin@ury.york.ac.uk>
Martin Blapp determined that the elf dynamic loader was at fault. In
particular, the loader uses alloca() to allocate a symbol cache on the
stack. Normally this would work just fine, but if the loader is called
from a threaded program and the object being loaded is fairly large the
alloca() can blow away the thread stack and effect other nearby thread
stacks as well. My testing showed that the symbol cache can be as large
as 250KBytes during the openoffice port build and install sequence. Martin
was able to work around the problem by disabling the symbol cache
(cache = NULL;). However, this solution is not adequate for commit because
it can cause an enormous cpu burden for applications which do a lot of
dynamic loading (e.g. like konqueror).
The solution is to use anonymous mmap() to temporarily allocate space to
hold the symbol cache. In testing I found that replacing the alloca()
with mmap() has no observable degredation in performance.
It should be noted that this bug does not necessarily cause an immediate
crash but can instead result in long term corruption and instability in
applications that load modules from threads. The bug is almost certainly
responsible for some of the instabilities found in konqueror, for example,
and possibly netscape too.
Sleuthing work by: Martin Blapp <mb@imp.ch>
X-MFC after: Before or after the 4.6 release depending on the release engineers
