Download and Release Information

DACS software is available at no cost.
It is officially distributed in source form only - you must build it,
although in most cases this is not difficult.
A Debian GNU/Linux release of DACS is
available, however.
DSS does not prepare or manage that distribution.

Starting with version 1.4.26, DACS is
not available on SourceForge - get it from the links in the
table below.
Releases prior to 1.4.26 may be available as
tarballs
on
SourceForge.net.

Important release notes, change summaries,
and post-release notifications are posted on this page,
and when a significant bug is found after release, we will
post a notice here, sometimes with a solution.
Please review this information before installing
DACS or if you are
experiencing any problems with DACS.
We apologize for any inconvenience and try to fix all known bugs
in the next release.
Patches and bug fix releases are sometimes available - please inquire.

Information that appears here about older releases may be superseded
by changes made in newer releases; this also applies to such things as the
renaming of programs and files.
A bug reported for a specific release may also be present in earlier releases.

As mentioned elsewhere,
we like to think that development of DACS
is guided largely by the needs of its users,
so we need your input
to do a good job!
Your requests and suggestions are important for us to continue to focus
our efforts on solving problems that are important to you.

We do not require you to register your copy of
DACS, but we would appreciate
hearing from you
if you decide to use it.
The anonymous information you provide can help us to focus development and
will be taken into account when we consider making changes,
particularly changes that are incompatible with earlier releases.

IMPORTANT

DACS MAY USE AND IMPLEMENT CRYPTOGRAPHIC FUNCTIONALITY.
Although DACS is developed, maintained,
and distributed from Canada, it may
fall under certain import, export, and/or use restrictions in other parts of
the world.
DACS may implement or adapt ad hoc,
enhanced, standardized,
or published cryptographic algorithms, or use cryptographic functionality
provided by OpenSSL,
other third-party software, or
operating system libraries and system calls.

Export and/or import and/or use of strong cryptography software, providing
cryptography hooks, or merely communicating technical details about
cryptographic software is illegal in some parts of the world.
YOU ARE STRONGLY ADVISED
to pay close attention to any laws that may apply when you import,
export, or use DACS,
or even communicate about it.
We are not liable for any violations you make - it is your responsibility.

What You Need

A recent release of one of the officially supported platforms:
FreeBSD, GNU/Linux, or Mac OS X

GNU make (gmake) and GCC (or Clang)

Third-party software: Apache 2.2/2.4, OpenSSL, and Expat

If you require certain optional features,
you will need to obtain some additional third-party software,
such as Berkeley DB, Samba, or OpenLDAP.
Sometimes this software is already installed on your system.

Bugs and Support

If you are having a problem with DACS,
after first reviewing the release notes and post-release notes for your version,
the next thing to do is check your DACS log files
and Apache log files (you may need to bump up your logging level to get
additional information as to what is happening).
You should also consult the FAQ
and Tips.
Whenever possible, you should always run the latest release of
DACS and check that you are compiling with
the correct version of third-party software.

Please see the support area
for information on reporting bugs and other assistance.
Technical support and maintenance packages are available.

Downloads and Release History

To unpack a tarball into a subdirectory named after the tarball file
with the extension removed,

For a .tgz tarball, (e.g., dacs-1.4.39.tgz):

% gunzip < dacs-1.4.39.tgz | tar -xf -

For a .tbz tarball (e.g., dacs-1.4.39.tbz):

% bunzip2 < dacs-1.4.39.tbz | tar -xf -

For a .txz tarball, (e.g., dacs-1.4.39.txz):

% unxz < dacs-1.4.39.txz | tar -xf -

The decompression commands should be available on practically all platforms
that are suitable for building DACS.

DACS Version 1.4.39

Release Notes

Apart from various third-party package and platform upgrades,
this release introduces new support for NTLM authentication using
a modified version of
libdsm
as a (mutually exclusive) alternative to the original
Samba-based implementation.
For a very long time, Samba 3.x has been used by DACS solely for its
implementation of NTLM authentication.
But because Samba 3.x has not been supported by the Samba team for
quite some time,
and Samba 4.x has proved to be difficult to build on DACS platforms
and is not a drop-in replacement for Samba 3.x in any case,
we want to use something much smaller, simpler, and easier to build than Samba.

Samba 3.x can still be used by this version of DACS.
But Samba dependencies will be deprecated and eventually removed from DACS.
Although it is currently functional and tested,
the new implementation using libdsm is not fully
integrated or documented within the main DACS build.
This will be improved in the next release.

The Windows/NTLM authentication method is completely optional, so the
following notes are probably only of interest to those who require it
and would prefer not to use the original implementation that depends
on Samba.
If you want to try the new implementation, do this before building DACS:

Unpack the DACS tarfile

Chdir to dacs-1.4.39/src/libdsm

There are a few steps to follow but it is quite straightforward.
The README in that directory has detailed instructions.
Briefly:

Obtain the source code for two GNU libraries:
libtasn1 and
libiconv.
No changes to those libraries are required.

Build both libraries in place, then build the modified libdsm.
A program called ntlmauth will be built
and you should use it to test authentication against your Windows server.

If all goes well,
build DACS as you normally would, except instead of configuring
it using --with-samba use --with-libdsm=./libdsm.
Then test authentication again, this time using dacsauth
(refer to
dacsauth(1)
and
local_ntlm_authenticate for examples).

If you are satisfied with the results of your testing,
complete your installation of DACS and verify that
dacs_authenticate also works
correctly.
The only change you may need to make to dacs.conf is to
specify OPTION 'SAMBA_PORT="0"' in the appropriate
Auth clause.
The new implementation knows which port(s) to try.

Please report any problems so that they can be addressed in the
next release.

Change Summary

New NTLM authentication implementation, enabled by
--with-libdsm=...

Minor functional improvements to the crypto test utility
(built by "make test" but not installed):

A compilation error may occur when building against the new NTLM
authentication code.
Edit defs.mk.in and find the line (approx. line 371) where
NTLM_LIBS is defined and a space incorrectly follows a -L
flag:

NTLM_LIBS=... -L $(DSMDIR)/libtasn1/install/lib ...

Delete the space and rerun configure
to regenerate defs.mk.

A bug in configuration processing has been discovered whereby
the uri_expr attribute of a Jurisdiction element may
be incorrectly evaluated, leading to a runtime configuration error.
This bug appears to be present going back several earlier versions of DACS.

Here is a simple fix that you can safely make to any recent-ish
version of DACS provided it compiles after making the change.
In src/conf.c, look in process_conf() for this code at
approximately line 2034:

Change Summary

Do not check/set mode of a log file that does not exist or is
not a regular file.

Install the JSON .rnc schemas with the XML DTDs.

Allow dacs_signout(8) to emit JSON documents.

Added the DACS_SIGNOUT_RESULT parameter to a
SIGNOUT_HANDLER URL and extended SIGNOUT_HANDLER
to explicitly allow a user-specified signout handler URL to
override a default URL.
See
dacs_signout(8)
and
dacs.conf(5)
for details.

Post-Release Notes

Nothing yet.

DACS Version 1.4.38

Release Notes

This release primarily upgrades platforms and
third-party support packages,
but it also incorporates new cryptographic hashing capabilities.

Post-Release Notes

Nothing yet.

DACS Version 1.4.37

Release Notes

This release primarily upgrades platforms and
third-party support packages.
Additional HMAC digest algorithms are now provided.
A self-contained arbitrary precision integer arithmetic library
is now included in the distribution.

Change Summary

Post-Release Notes

Nothing yet.

DACS Version 1.4.35

Release Notes

This release addresses some bugs,
adds some new secure password digest algorithms
(such as the new SHA-3 digest algorithms),
changes the format of the DACS password file,
and platform upgrades.
There was an important bug fix to DACS_ACS processing.
The DTD/RNC for dacs_version has been modified.
Please refer to the distribution's README and manual pages
for additional details.

If you are a) upgrading from 1.4.34 and
b) were using DACS password files and
c) have accounts that use the new parameterized digest methods introduced
in 1.4.34,
there has been a format change to those account entries.
Simple manual editing of those accounts or a password reset is required,
otherwise sign-on to those accounts will fail.
See the
PASSWORD_DIGEST
directive for details.

Minor changes to DTD/RNC for dacs_version; dacsversion/dacs_version emits
list of available digests

Changed DACS password file format to explicitly identify digest
algorithm plus any parameters; this is backward compatible except for
1.4.34 pbkdf2/scrypt, which will have to be adjusted manually

Added hex character escapes within strings (e.g., "hi\xa" or "hi\x0A")

Bug fix: CGI form data subtype parsing

Bug fix: configure was not looking for gmake correctly

Removal of support for InfoCards, previously announced as deprecated,
is in progress.
Related code will probably remain in distribution indefinitely
but is unlikely to build.

Post-Release Notes

dacs_token(8) may function incorrectly
due to a bug in key initialization.

DACS Version 1.4.34

Release Notes

This release primarily addresses some minor bugs,
adds some new secure password digest algorithms,
and upgrades third-party support packages.

If you are upgrading,
please note that there have been a small number of important
changes to site.conf-std.
If you have not modified your site.conf (and you shouldn't have),
you should copy site.conf-std to it.

Post-Release Notes

DACS_ACS=-check_only does not work correctly sometimes,
apparently due to a subtle recent change in Apache's behaviour.
A fix has been developed for Apache 2.2/2.4 and is being tested.

Using -lfetch in the build seems to be unnecessary
and can result in OpenSSL library conflicts.
This could sometimes result in sslclient
getting a SEGV in OPENSSL_ia32_cpuid immediately upon program
startup (which was initially very mysterious).

The method of parameterizing scrypt and pbkdf2 introduced in this
release will be replaced with a more general and explicit method
(doing away with global defaults) in the upcoming bug fix release.
Because this may result in minor configuration and DACS password file
incompatibilities (only with respect to 1.4.34 and future releases),
consider waiting for the next release if you plan to use scrypt or pbkdf2.

DACS Version 1.4.33

Release Notes

This release primarily addresses some important bugs,
improves documentation, and upgrades third-party support packages.

Change Summary

Eliminate calls to gethostbyname(3),
which is pseudo-deprecated and recently associated with
security-related bugs.

Fixes for mod_auth_dacs's handling of internal redirects to avoid
losing DACS HTTP cookies in some contexts

Enhancements to local_http_authentication to optionally
accept an auth_reply.dtd document from the web service it invokes.
This allows a generic web service to authenticate a username/password
and specify the username, lifetime of credentials, and role string if
authentication succeeds.

Post-Release Notes

A new SSL/TLS vulnerability, the SSL FREAK attack, has been announced.
See advisory
CVE-2015-0204
and this
vulnerability checker.
Several important OpenSSL bugs were announced on
19-Mar-2015
and
11-Jun-2015.
Recent releases of DACSshould work
with OpenSSL 1.0.2c and 1.0.1o,
but formal testing will not be completed until the next
version of DACS is released.

Further to the note in
dacs.install(7)
(also here)
regarding issues with libtool when building mod_auth_dacs,
we found it necessary to pass "--tag=CC" to libtool
invocations to avoid the error:

libtool: compile: unable to infer tagged configuration

We used:

my $libtool = "/usr/local/bin/libtool --tag=CC";

Bug: dacs_version(8) should accept
the FORMAT=XMLSCHEMA argument but does not.

DACS Version 1.4.32

Release Notes

This release includes some minor improvements, documentation updates,
and platform and third-party software upgrades.

Change Summary

Platform upgrades: FreeBSD 10.1, Mac OS X 10.10, CentOS 6.6

Third-party software upgrades:
OpenSSL 1.0.1j, OpenLDAP 2.4.40

Improvements and bug fixes for
dacstoken(1);
improved provisioning by exporting account information as URIs
(Google's KeyUriFormat) that can be converted into QR barcodes and
imported by several OTP client applications

Fixes and improvements to
cgiparse(8),
especially regarding multiple parameters with the same name

Minor improvements to
dacshttp(1)
and internal HTTP requests wrt
Authorization headers;
a userinfo field (username:password) is now
processed in URLs in conjunction with HTTP Basic authentication
(RFC 2617)

Corrections to
dacsauth(1) examples;
lines in -Of configuration files may now be continued

Fix to
dacs_acs(8)
to ignore Rname rules with a "status" of "disabled";
fixes to
dacsrlink(1)
for URI query parameters and empty Allow clause
(unspecified user); all rules must have a "status" attribute

Post-Release Notes

Going back at least to DACS1.4.30,
when Apache resolves a URL with a trailing pathname component
(PATH_INFO) by processing a sub-request,
mod_auth_dacs can drop DACS HTTP cookies.
When this happens, DACS access control rule processing may determine that
there are no credentials accompanying a request,
and access will typically be (unexpectedly) denied.
This bug was first demonstrated by invoking a PHP script,
through a ScriptAlias directive, with a trailing pathname component
on the request URI.
This will be fixed in the next release of DACS.

Soon after release of DACS1.4.32
an OpenSSL
Security Advisory
was dispatched.
Initial tests indicate that DACS will
work with OpenSSL 1.0.1k and 1.0.2.

Post-Release Notes

During routine testing after an upgrade,
a particular Apache+DACS configuration that worked correctly
with Apache 2.2.22 did not work properly with Apache 2.2.27.
It did not seem that anything important had changed in either
the Apache or DACS configurations.
After much debugging, it turned out that certain URLs were
not being actually being DACS-wrapped on the new system.
No Apache change log entries suggest anything relevant to this.

A beta release of mod_auth_dacs for use with Apache 2.2.27
will be made available shortly.
As always, please ensure that your Apache+DACS system
is granting and denying access as you intend,
especially after making changes.

When installing mod_auth_dacs on some platforms
(notably FreeBSD 10.0), messages similar to the following may be seen:

Warning! dlname not found in /usr/local/apache2.2/modules/mod_auth_dacs.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache2.2/modules/mod_auth_dacs.so
chmod: /usr/local/apache2.2/modules/mod_auth_dacs.so: No such file or directory
apxs:Error: Command failed with rc=65536

You should notice that a shared library (a .so file) has not been
created in the Apache modules directory.
This problem is apparently caused by a buggy version of libtool
that ships with Apache
(e.g., /usr/local/apache2.2/apr-httpd/build-1/libtool)
and is invoked by apxs from "make install".
To work around this, change the apxs command
(e.g., /usr/local/apache2.2/bin/apxs) that is run from the
Makefile in the DACS apache directory to execute the system's
libtool instead of Apache's.
For example:

After upgrading to Apache 2.2.27 on FreeBSD 10.0,
it was discovered that requests sent from most clients
(firefox, curl, wget, safari,
and telnet, but not lynx or dacshttp),
running on any system, were not being handled correctly
by httpd.
For most URLs,
the client would sometimes connect to Apache and sometimes not.
Apache would not service the request and it would eventually time out.
This was eventually traced to changes in FreeBSD 10.0 firewall rule processing
(ipfw) from the previous release of FreeBSD and
is not DACS related.

The HTTP_AUTH directive appears to have been broken by
changes to recent releases of Apache.

Post-Release Notes

While no incidents have been reported, DACS
releases use
OpenSSL,
which may be affected by the
TLS heartbeat read ove
rrun bug.
DACS installations should recompile
OpenSSL with -DOPENSSL_NO_HEARTBEATS,
as instructed in the advisory,
or upgrade to OpenSSL 1.0.1g.

Despite the addition of support for add-on modules,
there is no change to the open source license for DACS and
the DACS distribution does not include any code that is not
open source licensed.

The README was not updated to version 1.4.29.

dacs.install(7) incorrectly states
that this release expects
libxml 2.9.0 and xmlsec 1.2.18;
libxml 2.9.1 and xmlsec 1.2.19 should be used.

Post-Release Notes

In the instructions for building Apache 2.2 in
dacs.install(7) there
is a typo.
The command line flag:

--with-expat=/usr/local/expat-2.0.1

should read:

--with-expat=/usr/local/expat-2.1.0

Pasting the command line that appears in the manual page might result
in compilation errors.

There is a subtle difference between the -D flag as
recognized by dacsauth(1) and the general
dacsoption flag-D.
The former case sets a configuration directive while the latter sets
the value of a variable.
A different name should have been selected for the
dacsauth(1) flag, to avoid confusion.
A future release may address this issue.

Support for JSON is buggy, with names not quoted correctly.

DACS Version 1.4.28a

Release Notes

This release improves support for Apache 2.4,
corrects many problems with dacs.quick(7),
and fixes a variety of minor bugs.
There are no third-party support package upgrades, so upgrading from
DACS 1.4.28 should be easy.
For details, consult the
README and
HISTORY files,
dacs.readme(7), and
dacs.install(7).

Post-Release Notes

Apache 2.2 is the recommended version to use with this
release of DACS.
Some features of DACS may not work properly with Apache 2.4.

The instructions in dacs.install(7)
do not completely describe the procedure for building
Apache 2.4.3. It is covered in Apache's INSTALL file, however.
For the testing platforms, we get the APR and APR-UTIL libraries
from apr.apache.org and unpack
them in the Apache distribution's srclib directory, then rename them
apr and apr-util, respectively, as it says in
INSTALL.
For DACS 1.4.28a we used apr-1.4.6 and apr-util-1.5.1.
When building httpd, run configure with the
--with-included-apr flag.

On CentOS 5.9, the Apache build initially failed with a complaint
about not finding pcre-config. To solve this, we did

% yum install pcre-devel.x86_64

When configuring for the DACS build it was not necessary
to use the --with-apache-apr flag.

Remember that starting with Apache 2.4,
you need to write "Require dacs-authz" instead of
"Require valid-user".
If you use the old directive with Apache 2.4.x, httpd will
emit a message like
"AuthType DACS configured without corresponding module".

In some configurations the dreaded
"undefined ssl_hook_Fixup symbol" error or the
"Cannot load modules/mod_ssl.so into server" error
is produced by httpd when it starts up.
This was also seen in earlier releases of Apache.
These errors can be due to an apparent bug in the Apache build procedure that
results in the mod_ssl.so module not knowing where
libssl.so and libcrypto.so are,
even though the correct path was specified at Apache build time through
the --with-ssl flag to configure.

One solution is to make mod_ssl a built-in module instead of a
dynamically loaded module.
Build Apache using something similar to this (using the
--enable-ssl=static flag is the important change):

You may also be able to resolve the problem using the ldconfig
command, but we don't know if that could possibly break other programs that
expect a different version of the OpenSSL library.
You will need to always set LD_LIBRARY_PATH
before running httpd, maybe using an alias or script.
If you use apachectl to manage Apache,
you could simply have it set LD_LIBRARY_PATH
(also see bin/envvars, which is sourced by bin/apachectl).

Post-Release Notes

The Active Directory (LDAP) and NTLM authentication methods
have been successfully (though not exhaustively) tested against
Windows Server 2012 platform services.
It is likely that that platform will officially replace the
(ancient) Windows Server 2000 platform that has been used for testing
since the earliest releases of DACS.

Some invalid absolute links appear in
dacs.exprs.5.xml
(and to a lesser extent in a couple of other manual pages)
and documentation generated from it.
They are easily fixed by deleting the "http://bsd6.dss.ca/..."
prefix to change them to the obvious relative URLs.

Some references and links to http(1) were not updated to refer to
dacshttp(1).

The --srcdir flag to configure may not be handled
correctly.

For Apache 2.4, the mod_auth_dacs module identification string
may not be included in the SERVER_SIGNATURE string (and other places).
A quick fix is to modify mod_auth_dacs.c:dacs_register_hooks()
to ensure that ap_hook_post_config() is called.

mod_auth_dacs may not work correctly with Apache 2.4.3.
Consult the Apache log for messages that look like
"AuthType DACS configured without corresponding module".
Until this is fixed, please check if Apache 2.4.1 works for you,
or use Apache 2.2.23 (or something close to it).

added OpenLDAP Public License (Version 2.8) to NOTICES to
facilitate inclusion of OpenLDAP code for Debian GNU/Linux support

added OpenLDAP ldif.h and ldif.c to simplify build and
allow installed OpenLDAP headers and libraries to be used;
if LDAP authentication is enabled and the location of OpenLDAP is
not specified, configure will search for OpenLDAP libraries

mod_auth_dacs now recognizes the
"wsgi-script" executable
type

Post-Release Notes

Nothing yet.

DACS Version 1.4.27

Release Notes

Change Summary

fixes and extensions to
HTTP_AUTH,
dacsauth(1),
and the dacsauth() function
and their documentation; the syntax of the HTTP_AUTH directive has been
modified (the -url flag was removed) and is not backward compatible in
some instances, so configuration changes may be necessary

Post-Release Notes

Yet more problems remain with the HTTP_AUTH directive;
fixes are currently being tested and patches will be posted after a
suitable evaluation period.
Contact us if you would like to try the patches now.

Some debugging code crept in to the dacskey(1) utility,
which prevents it from functioning.
To fix the problem, edit src/mkkey.c and remove or comment out
the entire block of code that starts at line 645
(if (streq(argv[1], "enc")) {)
and ends at line 669
(return(0);).

Building DACS on FreeBSD 9 may be problematic.
The primary development environment for DACS will be changed to FreeBSD 9.0
for the next release, however, and these problems will be addressed.

additional crypto support and self-tests, including initial OAuth support

support for the Solaris/OpenSolaris platform has been withdrawn,
although commercial support is still available

Post-Release Notes

In the description of the HTTP_AUTH directive in
dacs.conf(5),
the comment regarding the -r flag not being implemented
is incorrect and should be ignored.
Refer to dacsauth(1) for
information about the -r role-module-spec flag.

DACS should work with Apache 2.0.64, although this has not yet
been confirmed
("The Apache HTTP Project developers strongly encourages all users to
migrate to Apache 2.2, as only limited and less frequent maintenance
is performed on this legacy flavor.")

Recent work has shown that
XML Encryption may be insecure.
While this does not mean that DACS itself is insecure,
it may point to weaknesses in XML-based authentication methods that DACS
can use, such as Information Cards.

A recent change: you must now sign on to the Oracle site before it allows
you to
download Berkeley DB.
You may be able to avoid this by using a URL such as
http://download.oracle.com/berkeley-db/db-5.3.15.tar.gz,
or you may be able to obtain BDB elsewhere
(such as
linux.softpedia.com,
pkgs.fedoraproject.org,
or
http://fossies.org").
Consider validating the downloaded file using a checksum published
on a different site, however.

There may be issues with build-time enabling of Readline library
functionality on Mac OS X (to be addressed in the next release).

Some HTTP_AUTH directives may not be parsed correctly
and/or the documentation may be incorrect in some cases.
This may also affect dacsauth(1).
Please pay special attention to testing these features until the problems
are resolved in the next release.

DACS Version 1.4.25

Release Notes

Although it mainly fixes bugs and adds some minor features,
this release includes improved support for one-time passwords
(such as time-based tokens, token provisioning,
and additional OTP token vendors),
introduces a new, simplified user-selectable authentication control,
fixes and improves PAM-based authentication,
and adds support for SQLite.

As with earlier releases of DACS,
a variety of problems were encountered building third-party software.
In particular, OpenSSL - which has seen a larger than usual number of
releases recently - seems to be troublesome.
These problems are addressed in
dacs.install(7).

third-party software upgrades: BerkeleyDB 5.0.21, Apache 2.2.15,
Readline 6.1, Samba 3.5.3, openssl-1.0.0a, openldap-2.4.21, xmlsec1-1.2.16,
libxml2-2.7.7note: DACS will no longer build against earlier releases of Sambanote: it was necessary to rebuild xmlsec1 against OpenSSL 1.0.0note: changes made in OpenSSL 0.9.8[mno] are incompatible with DACS;
do not use them with DACS

many fixes and improvements to OTP token support in dacstoken;
new dacs_token web service; new support for time-based OTP tokens (TOTP);
incompatible changes to token account format and command line flags
(see dacstoken(1),
dacs_token(8), and
dacs_authenticate(8))

Post-Release Notes

Important (3-Nov-2010):
The local_passwd_authenticate authentication module for 1.4.25
may report a successful authentication outcome even if an incorrect
password is given.
If you are using this authentication module or plan to,
please apply
this patch immediately,
then "make install" DACS.
Sites running earlier releases of DACS should upgrade (and apply the patch),
or at least verify that their release's local_passwd_authenticate
is working properly.

Not mentioned in the release notes and HISTORY were
some improvements to the output of dacs_error,
a generic error handling Perl script.

Solaris/OpenSolaris is easily the most troublesome platform when it
comes to building packages.
Here are examples of fairly basic configurations that have been used
to successfully build DACS with NTLM and LDAP authentication
on OpenSolaris 5.11.

To correct the problem, edit defs.mk and change every occurrence
of "-Wl,-rpath," to "-R".
So, for example:

-Wl,-rpath,/local/expat-2.0.1/lib

will become

-R/usr/local/expat-2.0.1/lib

Make this change everywhere in defs.mk.
If you run configure again,
defs.mk will be replaced with a new copy,
so you will need to repeat these changes unless you know how to mess with
defs.mk.in and configure.ac.

On Solaris (and perhaps other platforms),
the documentation may fail to install properly because
man/mkindex uses the -E flag with grep;
this flag is not understood by some versions of grep.
The solution is to
1) adjust your PATH so that an appropriate version
of grep is found;
2) edit man/mkindex at around line 160 and provide the
full pathname of an appropriate version of grep; or
3) edit man/mkindex at around line 160 and replace

grep -E "${which_el}" < "$el_f" | blah blah ...

with

sed -e "/${which_el}/p" -e d < "$el_f" | blah blah ...

DACS Version 1.4.24

Release Notes

This is primarily a bug fix release,
but it also introduces support for the Mac OS X 10.6/x86 platform.

As with earlier releases of DACS,
a variety of problems were encountered building third-party
software on OpenSolaris/x86.
These problems - and, sometimes, solutions - are addressed in
dacs.install(7).

Change Summary

fixed several low-level bugs, some of which might have caused
DACS web services or utilities to crash

A workaround is to insert a slash ("/") immediately before the
question mark.

A virtual filestore bug can sometimes cause the "rename" operation,
when used with the dacs-kwv-fs scheme, to report success but result
in no data being modified.

Several problems have been found in
dacs_transform(8)/dacstransform(1)
and their documentation;
until these are addressed in the next release,
please test carefully.

Automatic conversion of a function argument to the string
data type may trigger an evaluation error in some cases.
A workaround is to use an explicit cast:

> hash((string) 123, 0)

The XML document returned by
dacs_select_credentials
can be invalid because of a missing <ok> element.
If you require an immediate fix, edit src/select_credentials.c
and emit the element immediately after the
<dacs_select_credentials> element
(at or near line 439).

Problems were apparently introduced by changes to CFB mode encryption
in OpenSSL 0.9.8m
[1,
2]
and DACS does not appear to work correctly with OpenSSL 0.9.8m,
0.9.8n, or 1.0.0.
Decryption/encryption performed by DACS using these releases of OpenSSL may not
be compatible with DACS releases that use earlier or later releases of OpenSSL.
These changes have apparently since been reversed in the OpenSSL code base.
Do not upgrade beyond the version(s) recommended for this release
of DACS
(see dacs.install(7)).
Note: after building DACS, always do a "make test".

A bug has been found in
regmatch()
when subexpressions are used.
Matches may not be copied into a namespace if the namespace has already
been used.

Though not yet confirmed, it appears that if any HTTP cookie
contains a double quote character, that HTTP cookie and subsequent ones
in the Cookie header may be ignored.
This can make it appear as if an authenticated user is unauthenticated,
for example, because the cookie bearing DACS credentials is not processed.

Several long-standing problems with PAM-based authentication have been
identified.
Expect fixes and improved documentation in the next release.

DACS Version 1.4.23a

Release Notes

This release adds some refinements to the Information Card support,
introduces some new features, fixes some bugs,
and upgrades to recent releases of third-party supporting software.
Everyone is encouraged to upgrade to this release of DACS.

One significant new feature is an optional inactivity time out
(see the new directives,
ACS_TRACK_ACTIVITY and
ACS_INACTIVITY_LIMIT_SECS).
Another important feature is that
dacs_current_credentials can return information about a user's last
login and other logins that might be "active" - this can be useful for
detecting security breaches.

[Following the demise of CardSpace, support for Information Cards is
deprecated and web site material has been removed.]

If you are upgrading from an earlier release of DACS,
after installation check that you are using the site.conf
that comes with the new release.

Change Summary

enhancements to
dacs_current_credentials(8),
including ability to report last sign on and active sign ons.
There is one potential incompatibility with previous releases, as the DTD
for the document returned by dacs_current_credentials has changed.
The different format is produced only if user tracking is enabled --
see
dacs(1).
The modifications to the XML are quite minor.

an additional Apache directive is now expected by the default config:Alias /infocards "/usr/local/dacs/www/infocards/"
New installation directory /usr/local/dacs/www/infocards contains
some default public files and possibly some private (ACL-controlled)
subdirectories

the variable previously called JURISDICTION_URI is now called
JURISDICTION_URI_PREFIX
and a new variable called JURISDICTION_URI
has similar semantics but includes the request's scheme and any port
number

data type names used in
casts are now case sensitive
(they had been case insensitive, although that was not documented)

third-party software upgrades:
openssl-0.9.8k, Apache 2.2.13,
OpenLDAP 2.4.17, Samba 3.2.14
Note: when upgrading to openssl-0.9.8j
there were some problems with "make install" and Makefiles under
the fips subdirectory did not have
INCLUDES set correctly and
some manual intervention was required to complete the build.
Additional details are here.

Post-Release Notes

You must use the built-in local_infocard_authentication module
rather than the web service; the latter mode of use is not fully implemented
(it will require changes to auth_reply.dtd).
Please see
dacs_authenticate(8).

A bug has been discovered that can cause DACS applications to crash,
particularly during configuration processing.
A fix will appear in the next release.

Building openssl-0.9.8j on FreeBSD

A "make install"
of the standard openssl-0.9.8j distribution fails on FreeBSD 7.0,
even if specifying only
--prefix and --openssldir to configure.
It may fail on other platforms, too
(I'm lookin' at you, OpenSolaris and Cygwin):

cp: fipscanister.o.sha1: No such file or directory
cp: fipscanister.o: No such file or directory
*** Error code 1
Stop in /usr/k/generic/src/sysutils/openssl-0.9.8j/fips.

Here is what was needed to fix the problem(s) on FreeBSD 7.0
(your mileage may vary).

After unpacking the source distribution, run configure

As usual, run:

% make
% make test

These should work properly; if they do, proceed.

Do: make install
If it fails, continue with the following steps.

Change to the fips subdirectory

Edit each of {aes,des,dh,dsa,hmac,rand,rsa,sha}/Makefile and
(if necessary) change the value of INCLUDES
(defined near the beginning of the file) to:

INCLUDES=-I../.. -I..

Run "make lib" in each of those directories:

% (cd aes; make lib)
% (cd des; make lib)
and so on
% (cd sha; make lib)

Do: make fipscanister.o
It will probably report an error, but that's ok provided it actually creates
fipscanister.o.

Do: make fips_standalone_sha1

Do: ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1

Change to the distribution's root directory and try again to install:

% cd ..
% make install

If it still doesn't work, as on OpenSolaris and Cygwin,
try openssl-0.9.8i, which doesn't seem to
have these problems.

DACS Version 1.4.22

Release Notes

This release mainly fixes an assortment of bugs and upgrades to recent
releases of third-party supporting software.

As in the past, Samba (3.2.7, this time)
would neither configure nor build on the Solaris 5.10 x86 platform
(see also DACS 1.4.15).

Your mileage may vary, but when building OpenLDAP on the
Solaris 5.10 x86 platform, before running 'configure'
it was necessary to do
'setenv CC /usr/sfw/bin/gcc'
so that the correct compiler was found.

On any platform, if you are including LDAP support and encounter
DACS build errors related to '-lsasl2' or 'sasl' symbols,
add the '--without-cyrus-sasl' flag when you run the
OpenLDAP 'configure', rebuild OpenLDAP, and then rebuild DACS.
Contrary to the documentation in inet(3),
the Solaris 5.10 x86 platform puts inet_aton() in libresolv;
if local_ldap_auth fails to build because inet_aton() is
not found, edit DACS's defs.mk (and defs.mk.in, if you like)
and add '-lresolv' to the end of the OPENLDAP_LIBS
definition, then run 'gmake' again.

For the next release of DACS, we intend to upgrade to
OpenSolaris 2008.11 for testing.

problems associated
with release 1.4.21 have been fixed;
truncated multipart/form-data arguments still sometimes occur,
but they should not cause dacs_acs to crash anymore
(see dacs_acs(8) and
the Apache configuration directive
SetDACSAuthPostBuffer
for details).
In any case, you should set SetDACSAuthPostBuffer to zero if
you do not require DACS to process the HTTP entity body.
If you are able to use the GET method instead, that will also avoid the problem.
[It seems that this problem with truncation is due to some recent subtle
changes in the way Apache processes brigades.]
Note that disabling this feature of DACS does not mean that you
cannot DACS-wrap programs that are run via POST, only that
DACS will not make variables contained within the POST data stream
available to its access control rules - the program will run normally
if DACS grants access.

Post-Release Notes

The following errata and comments are associated with this release:

If you see the message "Mime parse of SERVICE_ARGS failed" in the
DACS log it suggests that the truncation problem mentioned above is occurring.

Some browsers (Firefox3 is one of them) may formulate an HTTP request
using the POST method that includes a Content-Type header
that is valid but that DACS does not understand, causing DACS to ignore any
arguments in the entity body (meaning that the POST parameters are
not available to DACS).
In this context, a Content-Type header like
"application/x-www-form-urlencoded; charset=UTF-8" will trigger
the bug.

The regmatch() function
may not return the correct value when there is at least one subexpression
in the regex and no namespace argument.
For example, "regmatch("foo", "(bar)|(baz)|(foo)")
returns 3 when it should return the string foo.

The dacsacl(1) command unnecessarily
reformats its input ACL files. This is usually harmless, but can add a lot
of whitespace.
If a rule's url_pattern or url_expr attribute values contain
quotes, the corresponding INDEX file entries will sometimes not be read
correctly, resulting in an error and dacs_acs denying access.
If this happens, the INDEX file (and possibly also ACL files) will
need to be repaired manually.

DACS may sometimes lose cookies following internal Apache redirects,
despite the access control rule in effect setting
pass_http_cookie to yes.
A symptom of this bug is that although a valid credentials cookie is sent
(possibly with other DACS or non-DACS cookies),
DACS appears to "forget" who is sending a request because the user's
DACS credentials are lost.
Other cookies may also mysteriously disappear, or disappear instead.
These internal redirections occur when Apache receives a request
that involves a DirectoryIndex directive, for instance.
This bug likely exists in earlier DACS releases.

For example, it is possible for Apache configuration to cause a user's
request for https://example.com to be internally redirected
to https://example.com/, then https://example.com/index.html,
and finally to https://example.com/index.php.
When this bug is triggered, the DACS rule for
https://example.com/index.php may not see the credentials that were
sent with the request.

If you require an immediate fix and are not concerned about DACS
cookies being revealed through environment variables
(such as when only trusted users have login access to your Apache box),
you can try a quick and dirty solution:

change to the apache directory of the DACS distribution

edit mod_auth_dacs.c (save the original, just in case)

Locate the function dacs_cookie_zap() and make it
return immediately without doing anything
(just insert a return statement at its start)

Do: make tag install

Restart Apache

DACS Version 1.4.21

Release Notes

Although this release mainly addresses a wide assortment of bugs,
and upgrades to recent releases of third-party supporting software,
it also features some significant performance and administrative improvements.
Changes of note include:

a new indexing mechanism for access control rules to accelerate
searches for the applicable rule - due to this change, however, the
dacsacl command must always be run after the ruleset
has been modified
(see dacsacl(1));

re-introduction of the authorization caching feature,
a cookie-based mechanism to optionally bypass authorization checking of
requests after they have been approved once,
which can be of particular benefit for frequently accessed files such
as images and CSS files, or when a rule is relatively expensive to evaluate
(see dacs_acs(8));

a complete rewrite of the dacs_admin web service to provide a
fully REST-ful, unified, and comprehensive administrative web-based console
[note that in this release, dacs_admin will only produce HTML output
and only supports read-only operations]
(see dacs_admin(8));

extensions to the DACS programming language with new, composite data types
(lists, associative lists, and arrays)
[note that their implementation is mostly but not totally complete;
in particular, list references may not yet be embedded within strings]; and

a new utility (dacsinit) for interactively configuring a
very basic federation and jurisdiction, which can help you to get started
with DACS quickly.

Upgrade to OpenSSL 0.9.8g
Note: when building it on FreeBSD, it was necessary to specify the
-fPIC flag to its config program

Upgrades to Samba 3.0.28 and Apache 2.2.8/2.0.63

Incompatible changes to access control rule processing:

to both significantly improve performance and simplify the rule
processing engine, changes have been made to the way rules are named
and processed

these changes will only affect users of earlier releases who are using
customized access control rules

the new format preprocesses rules to create an index called
INDEX.
The index is an XML file
(with syntax acl_index.dtd)
located at the root
of each ACL directory structure
(e.g., /usr/local/dacs/acls/INDEX)

you cannot have a rule file named "INDEX" (unless you change the
definition of ACL_INDEX_FILENAME and rebuild DACS)

an index file is processed during rule processing to determine the rule
that best matches a request, so it must always reflect the set of
available rules and be up-to-date WRT their contents

at most one rule file will be read during access control processing,
namely the best match

the DTD
acl.dtd
has been revised with a new "status" attribute
(currently IMPLIED but eventually REQUIRED)
that is used to flag a
rule as enabled or disabled for access control checking purposes

Release 1.4.21 ships with the standard DACS rules in the new format

if an existing DACS installation has added custom ACLs, its old format
rules must be converted to the new format - the old format should no
longer be used

because the changes affect the rule processing engine,
rules used by dacscheck(1)
must also be converted and indexed.
A command like the following might be used to do this
(your path will vary): % dacsacl -un -build -vfs '[acls]file:///usr/local/myapp/rules'

the
dacsacl(1)
command should be used to convert from the old format to
the new format:% dacsacl -convert
this will create a new INDEX file or replace an existing one,
and edit existing rules to use the new "status" attribute
this should only need to be done one time (running it more than once
should not cause any problems, however, so if any errors are reported
you may re-run the conversion after fixing the problems)

during conversion, rule files that were disabled in the old format will
also be disabled in the new format; if an old format file happens to
have a "status" attribute it will override the status implied
by its filename

during conversion, the priority associated with any subdirectory is
lost, only the numeric suffix of files containing a rule is used
to determine the rule priority propagated to the INDEX file.
Manual attention may be required to preserve the intended order of
rule processing if subdirectory priority was significant in the old
format.

rule files and subdirectories are not renamed during conversion

apart from conversion to the new format, dacsacl does not support
the old format

only the "acls" item type is converted,
not the "dacs_acls" (since
1.4.21 and later ship with the standard ACLs already converted)

Important: after conversion check that the converted rules are enabled
or disabled properly. If you find an error, edit the rule and change its
status. When you are done, run dacsacl again.

whenever a rule is added, deleted, or modified, dacsacl(1) must always
be run to rebuild the INDEX files:% dacsacl -build
this will create new INDEX files or replace any existing ones and
assumes that rules are in the new format
(i.e., they have a "status" attribute)

in the new format, all subdirectories are examined, regardless of any
"acl-" prefix, need not have a numeric suffix,
cannot be disabled,
and any numeric suffix does not influence rule priority

in the new format, rule files must still begin with the
prefix "acl-"
(any other non-directory file names are ignored), but the
convention "acl-disabled" to signify a disabled
rule file is not followed - so although initially disabled after
conversion, in the new format a rule file or subdirectory
with this prefix does necessarily imply that the rule file or subdirectory
is disabled - only the INDEX determines that.

in the new format, the "acl-" prefix is still required for files
containing rules but it is no longer required or significant for
subdirectories

in the new format, priorities are non-negative integers, with zero
being the highest possible priority. Rules with equal priorities
are ordered based on the ASCII collating order strcmp(3) of their
full pathnames

notwithstanding the conversion operation, in the new format a rule that
does not have a "status" attribute defaults to being disabled, and
the old style ACL prefix "acl-disabled" has no special meaning
(e.g., if such a rule is fed to dacsacl as a file argument
for syntax checking)

in previous releases, if an error occurred while searching through rules
(e.g., a syntax error was found)
the search would terminate and access would be denied.
In the new format, if dacsacl finds an error in a rule it does not
update the INDEX file and because only the responsible rule is read,
errors in other rules should not trigger problems during rule processing.

Re-introduction of the authorization caching feature
This allows positive access control decisions to be cached so that future
requests by the same client for resources controlled by the same rule
can be granted more quickly - see
dacs_acs(8)

Addition of dacsinit, a script to create and initialize
a minimal, single jurisdiction federation.
There is currently no manual page for the program, but there are
brief descriptions
here and
here.
Run it with the -n flag the first time you use it.
If there is any positive feedback, the program is likely to be extended to
do more configuration and initializations.

Post-Release Notes

The following errata are associated with this release:

The release accidentally shipped with a rule that allows all
access to dacs_admin.
This could potentially reveal information that should not be made
public, so it is important to either (1) disable the default rule for
dacs_admin,
(2) change the default to restrict access to dacs_admin, or
(3) add a custom rule for the jurisdiction, which will override the default,
and restrict access appropriately.
If you do (1) or (2), you should make the change to the installed
rule and to the rule that comes with the distribution
(acls/acl-admin.0) because 'make install' will replace
the installed rule with the rule that comes with the distribution.
Make sure that dacsacl is run after you make the changes,
and then verify that access has been disabled or restricted as you intend.

A bug (or feature) in Makefile.in makes it necessary to build
DACS with the --enable-developer flag for dacs_admin to be
built and installed.
This will be changed in the next release.

Examples of rules in the manual pages were not updated to
include the new "status" attribute.
(Note: the Tips have been revised to include
this attribute)

It is not made clear in the manual page for
dacskey(1) that the
keyfile argument is accessed via the virtual filestore.
Therefore, a relative pathname is not acceptable.

On some platforms, the pre-generated documentation in the distribution's
man directory may not unpack properly, causing make to think
that the documentation needs to be rebuilt even though it does not;
a bug in the Makefile can lead to the pre-generated documentation
files being truncated.
If this happens, restore the contents of the man directory from
the distribution tarball and do 'make touch install' from the
man directory.

Optionally, DACS can be configured to use OpenLDAP
to supply core functionality for LDAP-based authentication
(local_ldap_auth).
On some platforms, OpenLDAP may fail to build, producing error messages
about undefined symbols beginning with "sasl_".
DACS does not require SASL support, so OpenLDAP can be configured with
the --with-cyrus-sasl=no flag.

The local_apache_auth module runs very slowly when given a
large (e.g., thousands of entries) flat-file
(htpasswd) formatted password file.
Converting the file to Berkeley DB format (htdbm)
is currently the only solution (also see dbmmanage).

The description of the
from() function should mention that
in the case where the argument is a full or partially matching domain name
and REMOTE_HOST is not available but
REMOTE_ADDR is,
a reverse DNS lookup will be performed on the argument and all IP addresses
that result will be tested against REMOTE_ADDR;
if this lookup fails, then the function raises an error condition and rule
processing will terminate.
You should therefore avoid using a domain name argument that may not be
resolvable on the host where DACS is run.

Immediately after pasting the text to create a new access control rule in
Step 6.5 of the Quick Start tutorial, you must run
dacsacl(1) to rebuild the rule index:

A truncated multipart/form-data argument
(e.g., as a result of file uploading)
may cause dacs_acs(8) to crash.
Smaller uploads (up to approx. 7 KB) usually work, however.
Additionally, truncation may occur erroneously, depending on the size of
the argument, particular browser type being used, version of Apache,
and perhaps other environmental factors
(this problem has reared its ugly head before and appears to be intimately
related to Apache internals).
It may be possible to work around the problem(s) by adjusting
SetDACSAuthPostBuffer
and
ACS_POST_BUFFER_LIMIT.
Because the possibility of truncated arguments can never be eliminated,
there should probably be better ways to tell DACS what to do when they occur.

This and previous releases of DACS produce
HTTP cookies that have colons (and possibly other punctuation) in their names.
Although this is not known to cause problems with any web browsers,
it is
unacceptable to some versions of Tomcat.
It seems that
RFC 2109
(Sections 4.2.2 and 4.1)
and
RFC 2965
(Sections 3.2.2 and 3.1),
with
RFC 2616
(Section 2.2),
do not allow these "separators" to appear in a cookie name.
DACS does not currently have a workaround for
this problem, but then it does not claim to be RFC 2109/2965 compliant.
A future release of DACS will likely change
the syntax of its cookies to something benign.
Changes to the cookie name syntax may cause problems for interoperation
between different versions of DACS.
Note that middleware should not be relying upon (esp. parsing) the names of
DACS cookies, other than to identify the
different types of cookies, so a change should only be a minor inconvenience
for middleware.

It seems that issues may arise when
mod_rewrite
and
mod_proxy
come into play with DACS-wrapped resources.
A single proxied request may cause Apache to perform many authorization
checks.
Also, Apache mangles some variables associated with a proxied request
during processing (e.g., the REQUEST_URI)
and these may not be handled properly by DACS.
Avoid these kinds of requests, or at least test them carefully.

DACS Version 1.4.20

Release Notes

This is primarily a bug fix release.
DACS is security software - we urge all users to upgrade to the latest release.

Change Summary

Bug fixes:

important bug fix to local_passwd_authenticate prevents invalid
passwords from being accepted

Post-Release Notes

While DACS is not officially supported on Solaris/SPARC,
a bug has been found on that platform that breaks the http(1) command
and internal HTTP requests.
One consequence of this bug is that authentication may fail;
this particular case can be avoided by using built-in authentication modules.
This bug will be fixed in the next release, but you can contact us for a patch.

The
SetDACSAuthConf
and
SetDACSAuthSiteConf
directives may not work properly.
Because these directives cause the environment variables
DACS_CONF and
DACS_SITE_CONF, respectively, to be passed to
dacs_acs(8),
a possible work-around is to explicitly set them in your Apache
configuration
(using
SetEnv,
for instance).

DACS should not be affected by the
problems
recently discovered in
OpenSSL 0.9.8e.
The next release of DACS will upgrade to the then-current release of OpenSSL.

DACS Version 1.4.19

Release Notes

This is primarily a bug fix and minor enhancements release.
DACS is security software - we urge all users to upgrade to the latest release.

change to DACS base-64 encoding character set to make encoded
strings safe in paths (this does not affect MIME base-64 encodings);
NOTE: the change is (temporarily) "mostly" backward compatible in that
the old encoding is still recognized, however some things could break.
DACS admins should take this opportunity to regenerate federation and
jurisdiction keys (see dacskey(1));
user passwords via local_passwd_authenticate
should also be updated

consolidated encoding/decoding functions into
encode() and
decode(),
and added dacs64 encoding type
NOTE: anyone using the old function names must make the obvious edits to
convert the old names into the new ones; the following functions are
deprecated and will be removed from a future release:
cescape(), hex_decode(), mime_encode(), mime_decode(), url_encode(),
url_decode()

additional internal PKI support

changed site.conf defaults for LOG_LEVEL and LOG_FORMAT

changes to default log message formats

added several new flags to
dacspasswd(1)
and various improvements.
Notes: These changes are backward compatible with existing DACS password
files. Not all of the new features can be accessed through
dacs_passwd(8),
dacs_admin(8), etc.

Post-Release Notes

Important:
A bug in the local_passwd_authenticate authentication module
has been discovered that can cause an invalid DACS password to be accepted
when it should not be.
This does not affect any other forms of authentication or the
DACS password file.
Unless you are sure that you will not use this authentication module,
you must apply the following fix.
We apologize for the error.

This bug has been fixed and a new version of
src/local_passwd_auth.c is
available.
Replace the local_passwd_auth.c file (revid 1941)
that ships with dacs-1.4.19 with the new one (revid 1983).
Do a 'make clean' from the distribution's src directory,
then build and install DACS again.

Before deploying this or any other DACS authentication method in a production
system, please ensure that authentication succeeds only if all
authentication material is correct.

Correction: in the examples in
dacsauth(1),
the -vfs flag must appear with the module flags
(before the -u flag, for instance).

Regarding the notice acknowledgment feature
(dacs_notices(8),
dacs.nat(5)),
if a document requiring acknowledgement is accessed using the
https scheme, all links to the document must provide the port number
(even if it is 443) in its URL.
For instance, use
https://dss.fedroot.com:443/notices/ack-me.html
instead of
https://dss.fedroot.com/notices/ack-me.html.
Failure to do this causes users to see the same prompt twice.
The default port number will be handled correctly in the next release.

DACS Version 1.4.18

Release Notes

This is primarily a bug fix and minor enhancements release.
DACS is security software - we urge all users to upgrade to the latest release.

Notable improvements include:

a new "authentication-at-authorization-time" feature that allows a
user identity to be established, either interactively or non-interactively,
via HTTP Basic Auth (RFC 2617) or using any available context
(the request URI, arguments, etc.);
see dacs_acs(8)
and ACS_PRE_AUTH

a new "Rlinks" feature that can associate a URL with
authorizing rules and an identity, promoting collaboration and sharing;
see dacs_acs(8)
and dacsrlink(1)

changes to
HTTP_AUTH and
HTTP_AUTH_ENABLE
directives in support of the new pre-authorization testing HTTP authentication
feature;
the changes to these two directives are backward compatible,
but anyone using either directives should review the updated descriptions

added -invisible/-visible flags to
DACS_ACS
argument, with the former being the new default behaviour

Post-Release Notes

There is a bug in
dacsvfs(1) that prevents a
field separator character other than the default (a colon) from being used.
A bug in http(1) causes improper output
buffering with the -ih flag.

Arguments passed through the multipart/form-data content type may
not be handled correctly.

Requests that are the result of an internal redirect by Apache may cause
DACS to become confused about the request URI that it should use.

The dacsrlink(1) command and its manual page have several bugs.
The -expires flag is buggy.
The manual page has a typo: the flag for the rlink operation
should be called -lmode instead of -mode.
The manual page lacks examples.

On Cygwin, a build using expat-2.0.0 was clean but the DACS binaries did not
work properly.
Building with expat-1.95.8 instead solved the problem.

DACS Version 1.4.17

Release Notes

This is primarily a bug fix and minor enhancements release.
DACS is security software - we urge all users to upgrade to the latest release.

Notable improvements include:

a new 'simple' style of authentication via
local_simple_authenticate for inherently password-less
accounts (note that local_passwd_authenticate requires
a user provided password that cannot be the empty
string)

improved handling of binary data

upgrades to samba-3.0.23d, openldap-2.3.31, docbook-xsl-1.71.1

new local_ldap_roles module can assign LDAP/ADS roles
to any user; it was previously necessary to
authenticate the user through local_ldap_authenticate
to obtain these roles

NOTE: six utilities have been renamed for consistency
aclcheck(1) to dacsacl(1),
conf(1) to dacsconf(1),
cookie(1) to dacscookie(1),
mkkey(1) to dacskey(1),
auth_grid(1) to dacsgrid(1),
auth_token(1) to dacstoken(1)
also renamed prenv(8) to dacs_prenv(8)
See
dacs(1)
for an explanation of the the naming convention. The original
names, which may have been confusing or conflicted with non-DACS software,
are temporarily still available via the dacs(1) command. Their manual
pages will be temporarily retained as reminders of the changes.

Post-Release Notes

A bug was found that may cause the Args namespace to be
unavailable during configuration processing by dacs_acs.
This will be fixed in the next release.

There may be problems compiling DACS on GNU/Linux if Apache was built
with large file support enabled (it was if apr.h defines
APR_HAS_LARGE_FILES to be 1).
Try configuring Apache's APR support library (srclib/apr) with
--disable-lfs, and then rebuilding Apache and DACS.
This will be addressed in the next release.

Apparently some GNU/Linux distributions sometimes install Apache's
apxs utility as apxs2.
In this case, DACS will not find apxs during its build.
A quick fix is to edit the DACS src/defs.mk.in file
and replace

apxs = $(apache_home)/bin/apxs

with wherever your apxs2 is, for example:

apxs = /usr/sbin/apxs2

DACS Version 1.4.16

Release Notes

This is primarily a bug fix and minor enhancements release. DACS is security
software - we urge all users to upgrade to the latest release.

Note: In the final stages of testing we discovered that this
release of DACSdoes not
build on Cygwin, despite what is indicated elsewhere in the
DACS documentation.
This is because Cygwin lacks several library functions (even POSIX ones)
that are provided by all of the fully-supported platforms.
We will decide before the next release whether we will continue to
partially support the Cygwin platform or abandon it entirely.
Please let us know if you would like to see support for Cygwin continued.

Note: Minor but incompatible changes have been made to the
setvar function.
If you currently use this function, you will need to
review the documentation
and make appropriate changes before upgrading.

Change Summary

bug fix: http_auth_jurisdiction variable didn't
set DACS_JURISDICTION

bug fixes for building with Samba on GNU/Linux

bug fixes for building with Samba on Solaris 8 (-lresolv)

new authentication module, local_http_authenticate
(used to authenticate against a Google account, for instance)

bug fix for
dacs_conf(8)
and conf(1)
where closing Roles tag may be omitted in XML and HTML output; CSS fix

bug fixes: CREDENTIALS_LIFETIME_SECS directive was ignored by
some auth modules

Post-Release Notes

In releases 1.4.16 and earlier, it is possible to create a DACS account that
has no password (the password is the empty string) but these accounts cannot
be used because
local_passwd_authenticate rejects these passwords
as a sanity check.
Password-less accounts will be addressed more consistently in release 1.4.17.

DACS Version 1.4.15

Release Notes

This is primarily a bug fix and minor enhancements release. DACS is security
software - we urge all users to upgrade to the latest release.

With this release, DACS now supports strong authentication based on the
Authenex A-Key hardware token
(and other OATH-HOTP/RFC 4226 compliant products).
This provides a very low cost and convenient path to two-factor
authentication, not only for web-based single sign-on and CGI programs, but for
virtually any software. No additional software is required to use the
Authenex token with DACS. We hope to support other vendors' products in
future releases. Besides auth_token(1),
please see a description of the
Authenex
A-Key and background on
two-factor
authentication.

This release no longer supports some PASSWORD_* directives,
as earlier advised.
If you configured them for a previous release, you will need to
delete some configuration directives.
Please see the
Change Summary.

This release includes incompatible changes to
dacs_auth_transfer(8).
If you configured it for a previous release, you will need to
change some configuration directives.
We apologize for the inconvenience, but we think you will agree that
the new way to configure cross-federation trusts is much simpler and
easier to understand.
Please see the
Change Summary.

We were unable to successfully build, or even configure, Samba 3.0.23c on
the Solaris 10 x86 platform but had no problems with it on FreeBSD and
GNU/Linux.
If you require NTLM support on the Solaris 2.8 platform and experience
difficulties building local_ntlm_auth, you may need to edit
src/defs.mk and add "-lresolv" to the
SAMBA_LIBS argument list
(this must be repeated if you re-run configure).
Please make sure you build Samba exactly as described in
dacs.install(7).
If this release of Samba does not build on your platform, or will not
work properly with DACS, try an earlier release that has been tested
with DACS: samba-3.0.23, samba-3.0.22, or samba-3.0.21a.

Although this release was tested with OpenSSL 0.9.8c, initial
testing with 0.9.8d has not revealed any problems and it should be ok to use.

the
PASSWORD_MINIMUM_LENGTH,
PASSWORD_NEEDS_MIXED_CASE,
PASSWORD_NEEDS_PUNCTUATION,
and
PASSWORD_NEEDS_DIGITS
directives have been removed - use
PASSWORD_CONSTRAINTS;
PASSWORD_AUDIT
is now an Auth clause directive instead of a general directive

Some progress has been made with local_pam_authenticate and we hope to
have it functional in the next release.

Post-Release Notes

Both the HTML and XML output of conf(1) and dacs_conf(8) can be incorrect -
a closing Roles tag may be omitted.
This is insignificant for most users, but a
patch is available for
src/conf.c.
The CSS file for the HTML output (man/css/conf.css)
was not updated to include the new Transfer clause.
Though not important, a
patch is available.

DACS Version 1.4.14

Release Notes

This is primarily a bug fix and minor enhancements release.
It includes new applications that apply the
DACS rule processing engine
to problems other than web access control.
A
demonstration
of one of these applications,
dacs_transform(8),
is available.
The new dacstransform(1) command
was used to generate much of this site's documentation.

Improvements of note include:

new configuration directives to enhance security and detect poor passwords
(see the Change Summary for a list of the new directives)

Note:
A new feature, which is enabled by default, has been added to improve security.
Earlier releases will discard credentials generated by this release
unless the feature has been disabled at jurisdictions running this release,
however.
Please refer to the
VERIFY_UA directive for details.

new authentication module, local_cas_authenticate, for authenticating
through the Central Authentication Service (CAS)

Post-Release Notes

Shortly after release, a bug was found that may cause configuration
processing to fail.
When this bug is triggered, the DACS log file will contain the message:
Invalid boolean result value.

To fix this problem, either:

obtain DACS 1.4.13a or

replace two files with the ones found in
patch-1.4.13a.tgz.
From the distribution's root directory, do:

% gunzip < patch-1.4.13a.tgz | tar -xvf -
% cd src
% gmake install

We apologize for the inconvenience.

Older versions of gdb (4.18, for example) do not work properly
with DACS binaries, at least on FreeBSD.
This appears to be related to the upgrade to OpenSSL 0.9.8b.
Upgrading to a newer release of gdb (6.4, for example) avoids the problem.
A similar problem was found on Solaris 10/x86, even with newer releases
of gdb, but this DACS release works around it on that
platform (by passing -gstabs+ to GCC).

DACS Version 1.4.12

Release Notes

This is primarily a bug fix and minor enhancements release.

Important new features include:

the ability to authenticate against Apache htpasswd and htdbm files
using any DACS password-oriented authentication module

bug fix for rule matching where Jurisdiction uri attribute ends in a slash

new check for precondition element error

fixes for Solaris 10 x86 platform

bug fix re: <user name="any"/>

minor improvements to http, including following redirects

minor improvements to mkkey and its documentation

properly ignore disabled rules

upgrade to Samba 3.0.22

upgrade to OpenLDAP 2.3.21

configuration processing fixes and documentation clarifications

Note: if the following directive appears in any site.conf or dacs.conf,
it should be deleted:

VFS "[default]dacs-fs:"

Built-in authentication modules
In the Auth clause, you can use (so far):
URL="local_passwd_authenticate" (or URL="passwd")
URL="local_ntlm_authenticate" (or URL="ntlm")
URL="local_apache_authenticate" (or URL="apache")
URL="local_unix_authenticate" (or URL="unix")
For the last one, dacs_authenticate must be setuid root since it must
be able to read the shadow password file.

Incompatible change to dacs_auth_agent local mode name mapping for
improved usability: Configure, e.g.,

VFS "[auth_agent_local_test]dacs-fs:/usr/local/dacs/testmap"

(previous behaviour of "auth_agent_local" is retained)
Where /usr/local/dacs/testmap is a file consisting of expressions,
one per line (a continued line ends with a backslash). Each expression
is evaluated until one is True; its value becomes the mapped username.
The value of the USERNAME argument is available to each expression
as ${Expr::_} (a new convention, reminiscent of Perl's $_ variable).
Say the file contains:

does RFC 2617 Basic auth in conjunction with an htpasswd or htdbm file,
or with any DACS username/password based module
(e.g, local_unix_authenticate, local_ntlm_authenticate,
local_passwd_authenticate)

does RFC 2617 Digest auth in conjunction with an htdigest file

this feature should be considered semi-reliable pending additional testing

documented in dacs_acs(8) and dacs_authenticate(8)

Post-Release Notes

In previous versions, a reference to an undefined variable in a
configuration file did not result in an error; the empty string was
interpolated.
This behaviour has been changed in this release as a precaution against
buggy configuration files.
If you are upgrading from an earlier release and your configuration
file stops working, it may be because your dacs.conf or site.conf
tries to dereference an undefined variable.
Perhaps the easiest fix is to use the "e" or "?" modifier flag when
referencing a variable that might not be defined.

The return/exit function sometimes yields an incorrect value.

A syntax error can occur when a statement that
ends with a block is followed by another statement.
This sequence of statements should have the value 3:

if (1) { 2; } 3;

A temporary workaround is to explicitly separate the statements:

if (1) { 2; }; 3;

DACS Version 1.4.11

Release Notes

This is primarily a bug fix and minor enhancements release.

A new cross-federation identity transfer mechanism has been added.
It not only provides support for single sign-on among DACS federations,
but also between a DACS federation and other identity management systems.
See dacs_auth_transfer(8) for details.

The initial release of a web-based DACS administration interface called
FedAdmin will be made available shortly at Sourceforge's
contributed resource
project for DACS.
The DACS Java Library (DJL), which is being developed to
support the use of DACS in Java client applications, will also be updated.

Change Summary

many minor bug fixes and documentation improvements

new cross-federation identity transfer capability: dacs_auth_transfer

improvements and important extensions to user() predicate to handle
multiple credentials correctly; compatible except that the optional MODE
argument is now part of the string argument instead of being a separate
argument. The ACL user_list's user element inherits these improvements.

Cookie naming format change to align with DACS names.
The change is that a second colon follows the <federation_name>
This also affects NAT cookie names, which are not DACS cookies per se

Mostly backward-compatible changes to the Jurisdiction section matching
algorithm in dacs.conf, improved documentation.
The uri attribute can now include a simple hostname pattern (e.g.,
uri=*.fedroot.com) and a port number (fedroot.com:8080 and fedroot.com:8081
can now be different jurisdictions). Hostname matching is case-insensitive
but URI path matching is still case-sensitive and is done path
segment-by-segment rather than as a simple string compare.
NB: this could potentially break some configuration files.
Note that if you use ports in the uri=, you may need to change
the -u flag (e.g., in httpd.conf or ssl.conf) to add the port.
See "The Jurisdiction Section" in dacs.conf(5).

added 'touch' target to man/Makefile in case make thinks it needs
to regenerate documentation when it really doesn't

Post-Release Notes

This release uses va_copy(), which is not present in older
versions of stdarg(3) that come with GCC.

The changes wrt cookie naming broke the pseudo-backward compatibility
enabled by the COMPAT_MODE directive.
This will be fixed in the next release.
The cookie name format change will, of course, also require all
jurisdictions within a federation to upgrade to this release if any
one of them upgrades, otherwise credentials may not be recognized.
While we apologize for any inconvenience, our mantra is "security first"
and we urge you to upgrade to the newest release as soon as you are able.

The installation instructions in dacs.install(7) are missing
material on how to configure Apache for DACS.
You can obtain a
revised version
(right-click the link and "Save Link Target As..." or "Save Target As..."),
replace the one in your distribution's man directory with it,
and do a 'make install' from the man directory.

A bug may prevent arguments passed as application/x-www-form-urlencoded
content type in the message body from being accessible in the
Args namespace.

A bug prevents all "sensitive" messages from being logged, even
if LOG_SENSITIVE is set to "yes".

A bug in the LOG_FILTER directive prevented non-audit events from being
properly ignored.

A bug in configuration processing sometimes causes variables
in the Conf namespace to be interpolated as the empty string.

Additional changes (not listed above):

new directives: COOKIE_NO_DOMAIN and CSS_PATH

bug fix for sslclient

bug fix for installion of shared libraries

DACS Version 1.4.10

Release Notes

Change Summary

This release contains some minor new features, fixes bugs, and
improves the documentation.

A
contributed resource
project for DACS is now available.
The DACS Java Library (DJL) is being developed to support the use of DACS
in Java client applications. It implements Java wrapper classes for selected
DACS services, and provides an HTTP client through which DACS services may be
accessed and DACS credentials obtained and managed.

"make install" may fail if shared libraries have been configured.
To fix this, edit Makefile
(and/or Makefile.in), look for the targets
install-libs and install-shared-lib, and remove the string
"/$(SHARED_LIB)".
Or simply disable shared libraries (--disable-shared)
when you build this release.

DACS Version 1.4.9

Release Notes

Change Summary

This release contains some minor new features, fixes bugs, and
improves the documentation.

Other changes:

many bug fixes and documentation revisions and improvements

fixes and improvements to the dacscheck(1) command and its man page

fixes to autologin(8) and exec() function

fixes to local_roles, local_unix_roles, and dacs_authenticate(8)

added the Env namespace

fixes to dacs_notices(8) and its man page

fixes to the virtual filestore and its documentation

added --with-apache=omit (see INSTALL)

added ability to select case sensitive/insensitive comparison of
federation/jurisdiction/usernames. See docs for the new NAME_COMPARE
directive and the revised user() predicate.
A consequence of this change is that accounts created by dacspasswd
are now lowercase names; otherwise case-insensitive comparisons will
consider "Bob" and "bob" equivalent. Some such existing accounts will
become inaccessible if the admin changes to case-insensitive names.

added DACS-Status-Line with -check_only and -check_fail flags; see
dacs_acs(1)

changes to dacs_acs.dtd

Post-Release Notes

None.

DACS Version 1.4.8

Release Notes

Change Summary

The major change is the new
dacscheck(1)
command, which we believe will
open up DACS to many developers and many new
applications. It provides
simplified, platform-independent, general-purpose access to the
DACS access
control rule evaluation engine. This feature can be used by any virtually
any application,
script (Perl, PHP, shell, etc.), server software, or CGI
program to make data-driven access control decisions rather than
program-driven ones. dacscheck can be used by itself and does not depend
on any other DACS programs,
web services, or even an web server. Simply
install it and start to use it. Please refer to the manual page for details
and examples.

Other changes:

many bug fixes and documentation revisions and improvements

upgrade to OpenSSL 0.9.8a

new configuration directives for password constraints

fixes for Cygwin

backward compatible changes to the AUTH_SUCCESS_HANDLER
and SIGNOUT_HANDLER directives

changes to dacs_passwd, its DTD and default ACL

changes to DACS name parsing and user() predicate

changes to behaviour of permit_chaining attribute

Post-Release Notes

A bug in dacscheck(1) causes identities given in the "concise syntax"
to be parsed incorrectly.
A partial workaround is to omit the squirrelly braces;
for example, use
-i u=bobo or
-i u="bobo" or
-i 'u="bobo"'
instead of
-i '{u="bobo"}'

A bug in dacscheck(1) may cause SEGVs on system configurations
where hostname(1) does not return the host's FQDN.
You can use the -fn flag to explicitly provide a federation name.

A bug in autologin(8) prevents it from operating correctly.
The fix is to get
REMOTE_USER from the environment and pass its value as
the USERNAME argument to dacs_authenticate.

A bug in expression evaluation causes a non-zero return status of
a command executed by exec() to abort evaluation.

A bug in http(1) causes the -user-agent flag to be ignored.

DACS Version 1.4.7

Release Notes

Please note the following important changes/incompatibilities:

changed from comma-separated URI lists to space-separated lists in all
notice acknowledgement XML

changed ack() predicate to take individual URI arguments rather than
a single URI argument; NB: this may require changes to existing ACLs that
use the ack() predicate

a "secure" cookie is emitted if a request comes over https, regardless of
SECURE_MODE

Renamed acl-auth.0 to the more accurate acl-local-auth.0
Note: after acl-local-auth.0 has been installed, delete a previously
installed copy of acl-auth.0

A new feature called ACL delegation allows a DACS
administrator to delegate access control decisions for a portion of the
URL space to another person (or DACS identity) or to rules obtained from
another source. See dacs.acls(5).

The store command is now called vfs (delete any
previously installed copies of store).

Post-Release Notes

Apache's AddDACSAuth directive's command-line-arg-string argument,
which is supposed to be optional, must actually be provided.
This will be fixed in the next release; in the meantime, you can use "-v".

A bug in dacs_auth_agent's local mode of operation requires
the item type auth_agent_local to be configured (it's supposed to be optional).
This will be fixed in the next release.

Where the INSTALL file describes sslclient, replace
www.fedroot.com
with fedroot.com.

Change Summary

This release includes:

many bug fixes and documentation revisions

some log entries now include a "session tracking identifier"

sensible https/SSL defaults for the http command

new dacs_auth_agent web service

replacement of Store clause with VFS configuration
directiveNote: this may require revisions to dacs.conf and site.conf

added version header/footer lines to HTML man pages

important bug fixes for local_ntlm_authenticate and local_ldap_authenticate

reworking of the former "url" virtual filestore type (now called "vfs")

http/https URI schemes are supported by the new VFS directive

DACS Version 1.4.6

Release Notes

Authentication bugs
Bugs in the NTLM and LDAP authentication modules have been found that
may cause authentication to fail.
Fixes for these bugs will appear in the next release.

Checksums
After obtaining a DACS release, please verify all checksums
for the file you downloaded.
Do not use a download if any checksum for it does not match.
Checksums will be posted here from now on.

A note about upgrading
Because DACS is security software, we strongly recommend that you upgrade to
the newest release as soon as you are able. This is neither a difficult nor
a time consuming procedure most times. Sometimes an incompatible change in
DACS will require you to change a DACS configuration file, but this should
not be difficult to do and we will try to advise you of such changes.

For a quick and dirty upgrade (assumes you aren't changing any third-party
packages or options):

Obtain and unpack the new distribution and cd to it;

Review the README and INSTALL instructions;

Copy the src/config.nice from your installed version to the
new src directory and configure DACS:"cd src; sh ./config.nice";

Because the format for ACL file names has been changed, you may
need to rename your ACLs.
To be used by DACS, rule files must begin with "acl-".
All other file and directory names are ignored.
A rule named acl.0 will not be used by DACS, for example;
if it is renamed to acl-local.0 it will be processed.
Please consult the documentation for details.

Documentation for the dacs_signout web service is missing from the
distribution.
Its manual page is available
here.

Change Summary

DACS Version 1.4.2

Release Notes

Index: INSTALL

Please pay careful attention to the descriptions of the third-party
packages.

For a few third-party packages, it is important that you use the
exact version that is mentioned.
Do not use anything newer or older.

For other packages, a particular release is recommended.
It is less critical that you use the recommended release, but older
releases may have important bugs, including security problems.
Newer releases will not have been tested with DACS.

You may save yourself time and headaches if you just use the
recommended releases.

Index: HISTORY

added suport for LDAP and Microsoft ADS based authentication

improved man pages

minor bug fixes

minor changes:

new and renamed DACS expression functions, including
ldap name parsing

if -v and --version are given, also print module version
stamps

an initial version of WWW-Authenticate/Authorization
header handling (ACS can respond with or accept
RFC 2617 headers)