Christian Perrier <[EMAIL PROTECTED]> writes:

> Package: krb5
> Version: N/A
> Severity: normal
> Tags: patch

> Dear Debian maintainer,

> On Tuesday, May 22, 2007, I notified you of the beginning of a review
> process concerning debconf templates for krb5.

> The debian-l10n-english contributors have now reviewed these templates,
> and the proposed changes are attached to this bug report.

Thank you very much for your work on this!

> Please review the suggested changes are suggested, and if you have any
> objections, let me know in the next 3 days.

Feel free to forward this message as appropriate.

Why were all the double quotes changed to apostrophes?  That feels like an
American vs. British English change, and I think double quotes are more
widely used.  (This won't matter for translations, of course.)

One other general English issue:  I'm not sure if we should use Kerberos4
and Kerberos5 to refer to the versions of the protocol instead of Kerberos
v4 and Kerberos v5, or Kerberos V4 and Kerberos V5.  The primary MIT
Kerberos documentation uses Kerberos V4 and Kerberos V5.  Google returns
58,000 hits for "Kerberos V4" and 42,000 hits for "Kerberos4", and many of
the latter are filenames.  (89,000 hits for "Kerberos 4" with the space.)
This *will* matter for translations.

>  Template: krb5-kdc/krb4-mode
>  Type: select
> -_Choices: disable, full, nopreauth, none
> +__Choices: disable, full, nopreauth, none
>  Default: none
>  _Description: Kerberos4 compatibility mode to use:
> - By default, Kerberos4 requests are allowed from principals that do not
> - require preauthentication.  This allows Kerberos4 services to exist while
> - requiring most users to use Kerberos5 clients to get their initial
> - tickets.  These tickets can then be converted to Kerberos4 tickets. 
> - Alternatively, the mode can be set to full, allowing Kerberos4 to get
> - initial tickets even when preauthentication would normally be required, or
> - to disable, which will disable all Kerberos4 support.
> + By default, Kerberos4 requests are allowed from principals that do
> + not require preauthentication ('nopreauth'). This allows Kerberos4
> + services to exist while requiring most users to use Kerberos5 clients
> + to get their initial tickets. These tickets can then be converted to
> + Kerberos4 tickets.
> + .
> + Alternatively, the mode can be set to 'full', allowing Kerberos4 to
> + get initial tickets even when preauthentication would normally be
> + required, or to 'disable', which will disable all Kerberos4 support.

We should also document what "none" means, as this template has four
choices and the description only talks about three of them.

"none" will cause the KDC to not respond to K4 ticket requests at all.
"disable" will cause the KDC to respond with a protocol version error.

Maybe rephrase the last paragraph as:

    Alternatively, the mode can be set to "full", allowing Kerberos4
    clients to get initial tickets even when preauthentication would
    normally be required; to "disable", returning protocol version errors
    to all Kerberos4 clients; or to "none", which tells the KDC to not
    respond to Kerberos4 requests at all.

>  Template: krb5-kdc/run-krb524
>  Type: boolean
> -_Description: Run a krb524d?
> +_Description: Run a Kerberos5 to Kerberos4 ticket conversion daemon?
>   Krb524d is a daemon that converts Kerberos5 tickets into Kerberos4 tickets
> - for the krb524init program.  If you have Kerberos4 enabled at all, then
> - you probably want to run this program.  Especially when Kerberos4
> - compatibility is set to nopreauth, krb524d is important if you have any
> - Kerberos4 services.
> + for the krb524init program.
> + .
> + It is recommended to use that daemon if Kerberos4 is enabled,
> + especially when Kerberos4 compatibility is set to 'nopreauth'.

Change "use" to "enable" here, I think.  "Use" has a slightly different
meaning that doesn't seem as appropriate.

>  Template: krb5-kdc/purge_data_too
>  Type: boolean
> @@ -36,6 +51,7 @@
>  _Description: Should the data be purged as well as the package files?
>   By default, purging this package will not delete the KDC database in
>   /var/lib/krb5kdc/principal since this database cannot be recovered once
> - it is deleted.  If you wish to delete your KDC database when this package
> - is purged, knowing that purging this package will then mean deleting all
> - of the user accounts and passwords in the KDC, enable this option.
> + it is deleted.
> + .
> + Choose this option if you wish to delete the KDC database when this package
> + is purged, deleting all of the user accounts and passwords in the KDC.

As mentioned earlier, the wording will change as soon as I get around to
having the postrm script use debconf to prompt rather than relying on an
answer given during installation.

> @@ -133,15 +133,15 @@
>  Conflicts: kerberos4kth-kdc
>  Description: MIT Kerberos key server (KDC)
>   Kerberos is a system for authenticating users and services on a network.
> - Kerberos is a trusted third-party service.  That means that there is a
> - third party (the kerberos server) that is trusted by all the entities on
> + Kerberos is a trusted third-party service. That means that there is a
> + third party (the Kerberos server) that is trusted by all the entities on
>   the network (users and services, usually called "principals").
>   .
>   This is the MIT reference implementation of Kerberos5.
>   .
> - This package contains the Kerberos key server (KDC).  The KDC manages all
> + This package contains the Kerberos key server (KDC). The KDC manages all
>   authentication credentials for a Kerberos realm, holds the master keys
> - for the realm, and responds to authentication requests.  This package
> + for the realm, and responds to authentication requests. This package
>   should be installed on both master and slave KDCs.

I'll probably restore the two spaces after periods.  I find it much more
readable, and this is a question of style.

As a matter of procedure, I would recommend against changing things like
that as part of this sort of review, since it makes the diff considerably
longer and, as a question of personal preference with no right answer, I
don't think it's really a good sort of change to be making.

-- 
Russ Allbery ([EMAIL PROTECTED])               <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to