Re: 3.3.3 beta build issues

"Miller, Timothy J." <[email protected]> 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
[email protected] via Mail: [email protected]
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.