3.3.3 beta build issues

[Miller, Timothy J.]

1) There's "" around CFLAGS; this breaks the testlib targets objects (on
Linux, at least) because the ""s are passed off to the shell where CC is
invoked, causing gcc to interpret the entire string as a single flag.
Removing the ""s doesn't seem to have a negative impact on my Linux machine,
but YMMV.

2) tools/buildall.sh still has PLV="2".

3) Here's a fun one:  my local FW (not run by me :) doesn't just block SSH
connections, it resets them.  Thus:

"""
Testing SSHv2 session...
  Remote host: www.openssh.com.
Attempt to activate SSH client session failed with error code -41, line
1068.
  Error message =
  'Error reading server's SSH identifier string: No data was read because
the remote system closed the connection (recv() == 0)'.
"""

Which prevents the rest of the tests from running.  In these modern days of
more and more network restrictions, should testlib's methodology be changed
to either treate network-dependent tests specially, or to not rely on
Internet resources during the test run?  E.g., testlib could equally well
create a SSH or SSL service on a local highport and connect to it for the
test.

-- Tim




_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

"Miller, Timothy J." <tmiller@...> writes:

>1) There's "" around CFLAGS; this breaks the testlib targets objects (on
>Linux, at least) because the ""s are passed off to the shell where CC is
>invoked, causing gcc to interpret the entire string as a single flag.
>Removing the ""s doesn't seem to have a negative impact on my Linux machine,
>but YMMV.

Can you provide a bit more information on what the issue is, i.e. what problem
is being caused?  I test-built it on several Linux machines before the
release, and it seemed to work fine.

>2) tools/buildall.sh still has PLV="2".

Oops, thanks.

>3) Here's a fun one:  my local FW (not run by me :) doesn't just block SSH
>connections, it resets them.  Thus:
>
>"""
>Testing SSHv2 session...
>  Remote host: www.openssh.com.
>Attempt to activate SSH client session failed with error code -41, line
>1068.
>  Error message =
>  'Error reading server's SSH identifier string: No data was read because
>the remote system closed the connection (recv() == 0)'.
>"""
>
>Which prevents the rest of the tests from running.  In these modern days of
>more and more network restrictions, should testlib's methodology be changed
>to either treate network-dependent tests specially, or to not rely on
>Internet resources during the test run?

There's no easy way to distinguish between "failed self-test due to cryptlib
problem" and "failed due to networking issue" (for example the above was
something that could happen due to bugs in the Win2K TCP stack under exactly
the right conditions of nonblocking reads and a variety of other things that I
can't remember at the moment, whereupon recv() would return 0 with the TCP
connection still open).  The self-test already checks for lack of Internet
connectivity, but I can't really check for too-unusual conditions because
they're indistiguishable from a potential code bug.  Particularly for rare
issues like the above, I think it requires human intervention to handle true
problems vs. false positives.

> E.g., testlib could equally well create a SSH or SSL service on a local
>highport and connect to it for the test.

The code already does this when it thinks it's safe to do so, however there
were problems with this under Linux (at least when it was originally
implemented) due to threading issues, you can try removing the '#undef
TEST_SESSION_LOOPBACK' in test/test.h, but I haven't tested that code under
Linux for awhile so I don't know what state it's currently in.

In any case though the loopback tests aren't really as useful as the
external-server tests because if there's a problem inside cryptlib then
testing a cryptlib client against a cryptlib server, both of which use the
same code, may not indicate anything.

Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Miller, Timothy J.]

>Can you provide a bit more information on what the issue is, i.e. what
>problem is being caused?  I test-built it on several Linux machines before
the
>release, and it seemed to work fine.

I was on a base install of Ubuntu 9.04.  Last night the system patched
itself, and now I can't reproduce the error.  So I'll just shrug and
withdraw it.

>In any case though the loopback tests aren't really as useful as the
>external-server tests because if there's a problem inside cryptlib then
>testing a cryptlib client against a cryptlib server, both of which use
>the same code, may not indicate anything.

Good point, I didn't think of that.

It might be worthwhile to make testlib use the http_proxy environment
variable if present and open the session with proxy support (for SSL,
anyway), and/or prompt the user for a service to test against.  If I get
time I'll take a hack at it.

-- Tim



_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

"Miller, Timothy J." <tmiller@...> writes:

>It might be worthwhile to make testlib use the http_proxy environment
>variable if present and open the session with proxy support (for SSL,
>anyway), and/or prompt the user for a service to test against.  If I get
>time I'll take a hack at it.

If there's a simple way of doing this it could be useful, I'm just a bit
reluctant to add too much duct-tape functionality to the self-test because you
inevitably end up with exceptions and then exceptions to the exceptions, which
are often worse than just providing a nice clean (and obvious to the user)
failure.  I'll see how it goes...

Peter.

_______________________________________________
Cryptlib mailing list
Cryptlib@... via Mail: cryptlib-request@...
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.