Re: Intent to package KerberosV
> Bear Giles wrote:
> >Meanwhile, I've identified the following additional packages which can
> >be Kerberized immediately via compile-time flags:
> >
> > IMAP (get your mail from the site you expected; prevent snooping)
> > LPRNG (network print to the site you expected; prevent interceptions)
> > POSTGRES (grant access to database via Kerberos tickets)
>
> Would a kerberized PostgreSQL have to go in non-us?
My plan, back when I was exploring the idea of a US-only package
and/or derived distribution, was to use shared libraries and create
a special null Kerberos package which would return error codes, something
very close to the Kerberos 'bones' package (which is not export restricted).
The resulting package should be exportable and Kerberos functionality
would be enabled whenever someone installed the Kerberos packages.
There were two flies in the ointment, and one remains. First,
this approach doesn't work with non-US/Canadian maintainers; that's
now a moot point.
The second is that both Kerberos and SSLeay use "libcrypto" Maintainers
could change the library name expected, but it's a pain.
> So far, I haven't considered adding the Kerberos compile options, because
> of doubt about this and also because no-one has ever asked for it.
>
> Is there any demand?
This is one of those things where it may make sense to make a
policy decision to support technology ahead of the demand. Many
sites don't use Kerberos because of the perception that it's hard
to use and that there are few kerberized applications, but there
are few kerberized applications because there is little demand.
(Perhaps shadow passwords and getspwent() are a good analogy...)
Regarding postgres in particular, I think Kerberos should definitely
be an option (perhaps as a separate non-US package) because it's a
classic example of the type of problem Kerberos was designed to solve.
As a practical example, consider a web site with a remote server and
a local development mirror. How do you access the database? You
could use ssh (which is non-free) and TCP/IP tunneling, you could
connect directly and hope nobody is sniffing.. or you could set up
both sites to trust a KDC in your offices and run your programs
as usual. No encryption is necessary since the password never
crosses the wire.
Bear Giles
bgiles@coyotesong.com
Reply to: