On 17-Jul-2001 Kris Kennaway wrote: | On Mon, Jul 16, 2001 at 09:24:54PM -0400, Mike Heffner wrote: |> Hi, |> |> I would like to import Luke Mewburn's ftpd from NetBSD as the ftpd for |> FreeBSD. |> David had originally brought up the idea of importing it back in December, |> but |> it appears that he hasn't had the time, or other issues have come up. |> However, |> I would like to bring up the discussion again as I think it's a needed |> improvement--NetBSD's ftpd is better maintained and has better standards |> compliance. | | This has been discussed extensively over on -audit in the past.

It was? All I remember was that David brought it up and the discussion quickly switched to whether patches to disable some commands before login were reviewed and/or should be committed, but the whole discussion died rather quick. I'll have to check the archives, maybe there was a different thread I missed.

| Basically, I have concerns as security officer about replacing an ftpd | which has a good security track record with one which contains large | amounts of unaudited code, and has had several security problems. The | FreeBSD ftpd is used on far too many installed systems out there to | risk introducing new root vulnerabilities, no matter how good the | lukemftpd code is or how small that risk.

Yes, I agree that suddenly pulling out the current ftpd from under people's feet would be a bad idea. However, lukemftpd also has alot better support for more fine grained security settings and logging mechanisms, so there's two sides to it. Also, many users looking for more functionality than our current ftpd provides will switch to using alternatives like wu-ftpd, proftpd, or others that also haven't had the best of track records.

| | There are also problems with missing features as you note. The last | time this came up I offered the compromise solution of importing it | into FreeBSD to work on feature parity and to give auditors a known | base to work from, but it is not to become the default ftpd until I've

I'm willing to accept this as a solution, it won't be as much of a jump and will provide the opportunity for it to get into the tree and worked upon until its ready for primetime. The only disadvantage of course would be the lack of testing exposure.

| signed off on it. We now have funding to perform in-depth auditing | work on FreeBSD, so I think this would be achieved in a reasonable | timeframe (probably by 5.0-RELEASE).

My original intentions were to probably not merge this into 4.x anyways.

Mike