Review request for 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException

[Andrew John Hughes]

2009/9/4 Alan Bateman <Alan.Bateman at sun.com>:
> Andrew John Hughes wrote:
>>
>> :
>> Isn't there some way to test for snprintf and use it on platforms that
>> aren't broken?  It seems a bad idea to leave a potential security hole
>> open for the sake of one legacy platform.  snprintf is part of C99
>> according to its manpage, so it should be available on all compilers
>> that implement this standard.
>>
>> This is one reason why it would be better if OpenJDK used autoconf; it
>> has a test for this exact issue, but sadly that needs to be run prior
>> to the build.
>>
>
> Windows is indeed a pain. If this were library code then we could use
> jio_snprintf but this is a debugger transport library that shouldn't need to
> be linked to the VM. As I said, we could put in platform dependent code for
> this - it's not hard, just didn't seem to be worth it for this one case. You
> are right, that if someone were to increase the message without resizing the
> buffer then we'd have the buffer overflow issue back again. So if folks feel
> strongly about this, then I can do this so that we are using
> snprintf/equivalent. Alternatively, we simply change this to return a
> generic message (like "handshake failed - the peer is not a debugger") and
> skip printing the bytes received from the unrecognized peer.
>

Don't worry about going to a lot of effort if it's just me quibbling.
It's annoying that we have to work to the lowest common denominator
but I'm sure it's not the first time, nor will it be the last.  Your
FIXME should at least catch the eye of anyone changing this.

> Moving to an autoconf build is a significant project - that something for
> build-dev.
>

Yeah, I may look at it when I get some time.  It shouldn't actually be
too hard to have a configure run that feeds variables to the current
make-based build by autodetecting some stuff and allowing users a
nicer way to work with the options.  We already have IcedTea as a
prototype of this and it would be optional; seasoned hackers could
still set the variables themselves should they so wish.

If the Windows build is Cygwin based, it should even be usable there
-- albeit very slowly if my memories of Cygwin-based configure are
anything to go by.

> -Alan.
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8