[log in to unmask] quoted and then wrote: >+> I don't know how many of you follow the security bulletins >> in the Unix-world, but there has recently been a lot of >> trouble with the more widely used FTP daemons (one of them >> is WU-FTPD). > >I'm not familiar with this particular problem, but many >security problems in internet clients and servers are the >result of buffer overflow bugs. An example is the recent >flap over Outlook and executable code in MIME headers. > >Please do not be so confident as to assume this doesn't >happen if you were to implement the code in Ada. You >certainly can prevent it in pure Ada code, but if you are >interfacing to the operating system, you are still subject >to potential problems. I am familiar with a relatively large development organization that makes little use of Ada but has only recently started to use C in volume. They seem to do much better than average at avoiding buffer overflows because of a longstanding discipline of carefully checking sizes and lengths. So for the project proposed, I think the fact that the implementation language would be Ada might color the degree of discipline of those doing the programming. >I recently ported some Ada code which contained an interface >to the TM time structure (time.h) from Solaris to Linux. I >did not carefully examine the Linux include file, just compiled >the code. Turns out that the Linux (Slackware) had an extra >long and char* in the structure that weren't in the Solaris >definition. Took me quite awhile to find the bug. The code >worked when I had a Text_IO debug statement, but not when I >removed it. That's the only clue I had! But the lesson I take from that is that the proposed FTP project would end up not being so "portable" as desired even if it were restricted to the set of Unix-like operating systems (a much more narrow scope than I would like to see in a premier Ada demonstration). My own security experience says that even if you avoid buffer overflows, there are _many_ additional defects just waiting to happen in this problem domain, especially if one attempts a high-performance implementation.