| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
It's really not appropriate for the "examples" subsection of
"Adding, modifying and deleting principals".
While here, update the enctype recommendation for cross-realm principals
to something that does not include weak crypto.
|
|
|
|
|
| |
Start with a capital letter and end with a full stop, making
the description a sentence (or at least close to one).
|
|
|
|
|
|
| |
The target principal and restrictions arguments are not orthogonal;
a target principal argument must be given in order for a restriction
list to be supplied.
|
|
|
|
|
|
|
|
|
| |
It is an eggregious security violation to give all admin principals
admin rights and then give all null instances permission to change
the password of the associated admin instance.
While here, don't assume that admin and root are the only non-null
instances, and correct the formatting of an entry with restrictions.
|
|
|
|
| |
Make it a special note in the documentation to help it stand out.
|
|
|
|
| |
Grammar fixup and avoid jargon.
|
|
|
|
|
| |
Tweak the wording a bit to be more clear and avoid using multiple
words deriving from the stem "use" in close succession.
|
|
|
|
|
|
|
|
|
| |
Even though they are subject to vulnerabilities via DNS spoofing
and we accordingly don't recommend their use, we do have the code
to use them. Just as we document dns_lookup_realm in krb5.conf(5),
document them here.
ticket: 7407
|
|
|
|
|
|
|
|
| |
Now that the install guide make rules are removed, nothing references
build.texinfo or install.texinfo any more (other than the tgz target,
which is updated accordingly).
ticket: 7408
|
|
|
|
|
|
| |
Towards removing the texinfo docs entirely.
ticket: 7408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its content has been migrated to or superseded by the RST documentation,
split amongst krb_build and various sections of krb_admins.
A few portions of the texinfo document are simply no longer relevant
and do not need to be migrated. In particular:
It's 2012; we don't need to specify that we require a C89 compiler.
It's 2012; it will be easy to get enough disk to build krb5.
The KADM5 tests are part of 'make check' and don't need separate
documentation.
Shared library support is not limited to "a few operating systems".
We do not need to document incompatibilities with ancient/dead OSes.
kadmind4 and v5passwdd are no longer relevant.
ticket: 7408
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are, unfortunately, still some single-DES deployments out
there. Try to help them along by documenting a procedure for
migrating to stronger crypto.
The texinfo install guide had a section on "upgrading", but it was
not really suitable for direct import into a RST document. For one,
it gave a high profile to the on-disk incompatibilities in upgrades
to 1.1 and 1.2. It also was driven at upgrading *to* triple-des (or RC4),
which are something of a dead-end. This new text attempts to be more
general and applicable to today's environment.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a slightly less-contrived use case of the utility than the
other example, which reads more like a usage statement.
Give a motivating sentence before each example, and note that this
new example is not needed in the general upgrade case.
The need to dump/load for upgrades prior to 1.2 was documented in
the texinfo install guide, but not in any RST sources until now.
ticket: 7407
|
|
|
|
|
|
|
|
|
| |
The Texinfo install guide had a separate subsection about the DejaGnu
tests which did not get converted to the RST source.
In the testing section, also link to the wiki page on manual testing.
ticket: 7407
|
|
|
|
|
|
| |
It is unused; send-pr.texinfo supercedes it at the moment anyway.
ticket: 7408
|
|
|
|
| |
ticket: 7375
|
|
|
|
| |
ticket: 7376
|
|
|
|
| |
ticket: 7379
|
|
|
|
|
|
|
|
|
|
|
|
| |
New options:
-p path-to-kdb5_util
-K path-to-kprop
-F dump-file
These are needed for testing without first having to install.
ticket: 7372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make kpropd in iprop mode fork a child to listen for kprops from the
master. The child writes progress and outcome reports to the parent
for each kprop. This fixes a race between asking for a full resync
and setting up a listener socket for it.
- Add runonce (-t) for kpropd do_standalone() too.
- Add a new iprop parameter: iprop_resync_timeout. kpropd will keep
asking for incremental updates while waiting for a full resync to
finish, and will re-request a full resync if kadmind continues to
indicate that one is needed after this timeout passes since the
previous full resync was requested.
- Allow polling intervals less than 10 seconds.
[ghudson@mit.edu: split out debug output changes; note polling interval
change in commit message]
ticket: 7373
|
| |
|
|
|
|
|
|
|
|
| |
Add gss_export_cred and gss_import_cred mechglue functions to
serialize and unserialize GSSAPI credential handles. Mechanism
implementations and tests will follow.
ticket: 7354 (new)
|
|
|
|
|
| |
Remove KRB5_PADATA_OTP_CONFIRM pre-authentication data (padata) type
as it is marked as OBSOLETE in RFC 6560.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We at present only have long-form options for configure, the scope
of the change is somewhat limited. Our SmartyPants config for Sphinx
causes these options to appear as prefixed with an en dash, instead
of the two hyphens that demarcate the (GNU-style) long-form options.
Using a different type of markup for command options could work around
this, but that would be a much larger patch.
Instead, apply a workaround in the markup for display purposes, which
makes the source a bit more ugly but the output correct.
Man page output is unaffected.
This patch was automatically generated with:
git grep -- -- doc/rst_source | grep -v -- --- | cut -d ':' -f 1
| uniq | xargs sed -i '' -e 's/\*\*--\([a-zA-Z]\)/**-**\\ **-\1/g'
and manually reviewed for correctness.
ticket: 7187
|
|
|
|
|
|
|
|
| |
This page gets rendered for the web with Sphinx but is also turned
into the krb5_conf.5 manual page. We need to use three-hyphen
em dashes for the Sphynx config, but those are a bit long for
monospace terminal output. Since the dash here can easily be
changed to a comma, do so, and avoid the conflict of formatting.
|
|
|
|
|
|
|
|
|
| |
Our sphinx configuration uses SmartyPants, which produces smart
quotes and dashes in HTML output, using '--' for en dash and
'---' for em dash. (This is also the LaTeX convention.)
These points in the text are meant to be em dashes, so format them
as such. Also standardize on no spaces around the dash per
Chicago Manual of Style (and others).
|
|
|
|
|
| |
Also, move [logging] section documentation after [dbmodules]
documentation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Change the default client keytab name, if not overridden at build
time, to FILE:$localstatedir/krb5/user/%{euid}/client.keytab.
Introduce a second file from the autoconf archives in order to
recursively expand $localstatedir within configure.in.
|
|
|
|
|
|
|
|
|
| |
Tie up some loose ends in substitution of the default ccache/keytab
names after 688a2702d2045abf5f99acfb59f3f372391e5be4:
* Fix the substhtml target in src/doc/Makefile.in
* Don't add FILE: when substituting the default keytab and client
keytab names, as the defaults already have it.
|
| |
|
|
|
|
|
| |
Do not leave anyone thinking that they might have to specify it
in the config file to get the standard behavior.
|
|
|
|
|
|
|
|
| |
For Unix-like platforms, add %{username} to the path expansion
facility, expanding to the result of getpwuid on the euid.
Also, for manual testing convenience, make t_expand_path print the
result if no second argument is given.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simply adds KADM5_API_VERSION_4 and various fields to the
policy structures:
- attributes (policy-ish principal attributes)
- max_life (max ticket life)
- max_renewable_life (max ticket renewable life)
- allowed_keysalts (allowed key/salt types)
- TL data (future policy extensions)
Of these only allowed_keysalts is currently implemented.
Some refactoring of TL data handling is also done.
ticket: 7223 (new)
|