Some other things to consider.
Raphael
----- Forwarded message from Carl Erhorn <[EMAIL PROTECTED]> -----
Date: Mon, 29 Sep 2003 10:32:14 -0400
From: "Carl Erhorn" <[EMAIL PROTECTED]>
Subject: hacking question...
To: <[EMAIL PROTECTED]>
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Hi, Raphael.
Please direct this question to the best person to answer it.
I have just built gtk-gnutella, v0.92.1 on Solaris X86, using
the Sun compilers, and after about 12 hours of work getting all
the required support packages built on this platform, I was able
to get gtk-gnutella to work.
However, I found that I was apparently being crashed by an outside
user on the net, and their IP shows up in the hostiles.txt file.
If the mechanism for locking out malicious users is working
correctly, shouldn't this be prevented by the IP appearing in
the hostiles.txt file?
Somehow, the data from this user was accepted, and we got as far
as doing queue lookups on the data before it finally crashed with
a seg-fault, caused by an unexpected null string that was passed
to strlen().
I have attached the stderr log at the time of the most recent
crash, and the dbx traceback from the core file. I did notice
that this time I did not see the hostile IP address in an error
message, but that was what was in the log the first time this
happened. Perhaps you can determine what was happening from the
log and traceback - I hope so.
To me, it appears that someone has found a way to hack into the
protocol, and pass data that is missing required parts, in such
a way as to cause segfaults. That's a fairly serious problem,
since the hostiles.txt mechanism appears to be unable to prevent
it. I will continue to test, and try to catch the same situation
happening again, with the log showing the IP and error.
Even though I probably do not have enough detail to be helpful
right now, I wanted to give you a heads-up on the problem. I
find it pretty frustrating, as I have spent a fair about of time,
and a serious amount of effort porting the code to Solaris 8 on
X86 hardware, using the Sun compiler. I found many instances in
the code that are dependant on the GNU compilers, and had to make
a lot of changes in order to get the code to compile, so it
certainly wasn't just a trivial recompile.
It's a real shame that people are using GNU-specific extentions
in the code, since it breaks the code for anyone without the GNU
compilers, or who are unwilling or unable to install the gcc/g++.
In my case, I have to maintain a clean SUN development environment,
so I am not allowed to install GNU tools.
But even so, I was able to get gtk-gnutella working, and have
downloaded a number of files without problems. I have not seen
anyone upload from me yet, so I've been unable to test that
functionallity.
I suppose it's too late in the project to ask that you refrain
from using GNU-specific code extensions, and GNU-only tools. It
kills the portability of the code, but since your primary user
group is likely to be Linux-based, it probably isn't high on
your wish list.
For instance, Solaris provides a native xgettext, and the configure
program accepts that, but then uses GNU-specific arguments to the
command line, which causes the make to fail. I was able to dummy up
the *.po file, and touch the stamp-po file, so that the make finished,
and I was able to install. But of course, I now have no
internationalization features, because it's just hacked.
I also found someone using:
switch(var)
case 'A...Z':
case 'a...z':
This is totally illegal in every version of C except for GNU. So
again, you are locked to the GNU tools, unless you know what to do
to fix this. Of course, I had to insert the 62 missing case
statements to fix this. Luckily, the end result in the compiler
output is probably identical. So it's really lazy coders causing
these problems, not the compiler itself. You might want to change
your coding guidelines in the future, to try to inforce better
portability to other platforms.
For instance, the current code would never compile on Sun Sparc,
IBM's AIX, or HP's HPUX systems, using the commercial C compilers.
Any site doing commercial development is likely to use the native
commercial compilers, because they can get good paid support for
the tools. This is often critical in the commercial development
cycle. But your code will not work on any of those platforms,
without the user making the effort that I just did, in order to
port the code to the native tools.
I was also amazed at the third-party support libs required. I
found that I needed to download, port, and build the following
to get your product code to work:
atk-1.2.4
glib-2.2.3
gtk+-2.2.3
jpeg6b
libpng-1.2.5
libxml2-2.5.11
pango-1.2.5
pkgconfig-0.15.0
tiff-v3.5.7
zlib-1.1.4
This is a huge amount of libs to be dependant on, and a huge
amount of code to port, as some of it (thankfully little) also
is using gcc/g++-specific code or tools. While I applaud the
work of GNU and the FSF, the non-adherance to standards is
causing so many people grief. And the people doing development
are usually kids on a linux box, who could care less about
portability.
Anyway, I wonder if it might be possible to downsize the
number of libs you depend on, at some future time? While you
may need some of these libs, I am sure you could eliminate
two of the three image libs, and certainly pkgconfig, and
perhaps zlib.
If I ever get the code running cleanly, and eliminate the
problem of the current crashes, perhaps I can rebuild everything
with optimization turned on, and the libs stripped down to as
small as possible.
If there is more that I can do for you, or more information
that I can provide, please let me know, and I will do my best
to provide it.
Regards,
Carl Erhorn <[EMAIL PROTECTED]>
----- End forwarded message -----
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
