[ITP] tftp-hpa 5.0

[Gernot Hillier]

Dear Chuck!

First of all, thanks for your detailed review, response and your 
suggestions!

Am 01.10.2010 17:47, schrieb Charles Wilson:
>>> We'll need to coordinate the release of tftp-hpa
>
> Hmmm...now that I think about it, it would be really great if the
> package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N
> Users aren't going to CARE that the implementation/source came from
> the 'tftp-hpa' distribution.
[...]
> setup.exe doesn't have any provision for specifying conflicts.  So,
> we can only have one (current) package that provides any specific
> file (such as /bin/tftp.exe or /usr/sbin/tftpd.exe).

Ic. I'm not that of a Cygwin expert so I just trust your opinion here.
Changing the package accordingly is fine for me. (Keeping inetutils'
tftp implementation was just a quick idea w/o thinking about the
conflict resolving stuff).

> While I don't really have any issues with remap, I wonder why you
> dropped tcpwrappers? It adds no complexity to the build, and helps --
> to a certain degree -- with some of the security issues endemic to
> the tftp protocol.  (Especially as tftpd-hpa operates in such a way
> that you *can't* call it via the 'tcpd' utility in inetd.conf).
>
> Also, the whole *point* of obsoleting inetutil's version is because
> it is not capable of support IPv6 -- but tftp-hpa is.
>
> So, I really think you should enable IPv6.  Now, that means a lot of
> new porting work, because there are ALWAYS issues with porting IPv6
> networking to cygwin/win32...see the rsh package's patches (also,
> xinetd).

Ic.

Well, what I've proposed here was the result of an internal project
where we just needed bare-bone IPv4 tftpd functionality in an isolated
environment w/o security concerns. As I ended up in quite some compiling
errors (and found some posts suggesting that those aren't that easy to 
fix), I simply tried disabling features until tftpd finally worked.
"Worked for me", you know. :-)

And as I wasn't sure if the package would be accepted or taken care of
at all, I also didn't want to invest that much upfront effort, but chose
to document limitations instead...

We can for sure try to re-enable and fix all these issues, but as for
you, my time for these tasks is also quite limited and I can't promise
quick results here...

> Now, as far as dropping privileges...that's a tricky one.  First,
> your assumption that most people will run tftpd as a standalone
> service under cygrunsrv is probably false. I imagine most people will
> use a superserver (inetd or xinetd) instead.
[...]

Thanks for all the insights on this complicated topic!

> Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as
> ANY privileged user at all: cygserver, Administrator, SYSTEM, ...
[...]
> tftp is SO incredibly insecure it boggles the mind.  Letting random
> *unauthenticated* users upload to your machine (or download), using
> the credentials of Administrator?  Using client-specified paths?  Not
> just no, but hell no. (Recall that cygwin doesn't *really* jail
> chrooted processes; they can always use win32 functions to "break
> out").

Hmmm, anyone running tftpd should know that (s)he should protect it from
any productive network as it's insecure by design. In my eyes, putting
tftpd behind an effective firewall is just the right answer here. Any
effort spent to improve tftpd's security concept *if you don't trust his
peers* will only raise the security bar from 10 to 12% IMHO.

That's the reason why I didn't spend any effort on this yet and why I 
personally don't see this as a top-prio.

That's, btw, also the reason why I decided not to provide a 
(postinstall) script which activates a Windows service. People who want
to use this piece should really know what they're doing...

> We should probably take additional discussions offline, just to keep
> from annoying the list with ongoing development.

Sure. I'll come back to you via private mail as soon as I had a detailed 
look on all your points...

-- 
Gernot