Date: Wed, 13 Nov 2002 09:01:32 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Doug Rabson <dfr@nlsystems.com> Cc: Wilko Bulte <wkb@freebie.xs4all.nl>, "David E. O'Brien" <obrien@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf src/libexec Makefile Message-ID: <Pine.NEB.3.96L.1021113085120.66084B-100000@fledge.watson.org> In-Reply-To: <200211130932.08532.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Nov 2002, Doug Rabson wrote:
> > > > [DAIVD O'BRIEN's OPINION]
> > > > Head off what I think is an abuse of the TRB, and disable
> > > > lukemftpd.
> > >
> > > The TRB has nothing to do with the fate of lukemftpd and we have
> > > not been discussing it. Policy decisions (which ftpd to use, which
> >
> > rwatson suggested het wanted to ask the TRB
>
> I missed that.
Probably because I sent e-mail to David saying that I planned to take this
issue to the TRB for resolution, since we apparently had a technical
disagreement: I believe that FTP daemons shipped as part of the base
system are feature-incomplete if they claim to support authentication and
accounts, yet don't support our stand authentication and account
management framework, and he doesn't believe that.
> > > authentication framework to use) are probably not part of the TRB's
> >
> > Why not?
>
> Which ftpd to use isn't a technical decision. Presumably both versions
> work (for some value of the word 'work'). Which authentication framework
> to use is clear: we use PAM for authentication services. What is left?
Sounds reasonable to me. I ended up not sending out the e-mail to trb@
yesterday afternoon because of David's backout; from a purely technical
perspective, this suffices to address the list of concerns I had, although
it's perhaps not the most ideal outcome of the set of possible results I
would have considered acceptable.
> > <sjeez, why is this ftpd thing so hairy??>
>
> Because its so trivial that everyone can have an opinion on it of
> course.
My concern, and reason for potentially dropping this on the TRB, was that
there appeared to be a technical viewpoint that it was not necessary to
implement the "standard" system authentication and account management
services, and that this would be considered sufficient reason not to
implement them. If I had sent the request to the TRB, the result I would
have been looking for would either be
(a) that the interfaces must be implemented if we ship a service,
or
(b) we do not have, and will not have, standard authentication and
account management interfaces (and as such there is no obligation
for committers introducing new services that might uses those
interfaces to implement support for them).
Which seems on-target for a TRB discussion. I did not intend to raise the
issue of which FTP daemon was the One True FTP Daemon, although one
potential result of the discussion might be that we do permit a
non-compliant daemon in the system if appropriately signposted, in which
case we'd have Suppported daemons, and Unsupported daemons. In any case,
this is speculation, since thus far it hasn't been sent to the TRB. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021113085120.66084B-100000>