From: "Steven M. Schweda" <sms@antinode-info>
> On a different point, a closer look at the 64-bit-pointer test
> results shows a problem on Alpha (but not on IA64) somewhere in the "CMS
> => PKCS#7 compatibility test" sequence. Perhaps some file I/O thing?
> The perl script doesn't seem to handle an explosion here very well. A
> search for "fail" in the test results transcript won't detect the
> absence of an "ALL TESTS SUCCESSFUL" message, making it easy for a
> casual inspection to miss this kind of failure.
The cause of this test failure seems to be yet another unexpected
quirk -- not really file I/O. So far as I can see, all the popular
"app/*.c" main programs (cms.c, genpkey.c, nseq.c, ocsp.c, pkcs12.c,
pkcs8.c, pkey.c, pkeyparam.c, and smime.c) scan their argument list
using this scheme:
[...]
int MAIN(int argc, char **argv)
[...]
char **args;
[...]
args = argv + 1;
[...]
while (*args) [or similar]
[...]
args++;
[...]
That is, they look for a NULL terminator at (past) the end of "argv".
My apparent problem is that on VMS V8.3 Alpha (at least), with 64-bit
pointers, the "argv" array is not reliably NULL-terminated, and when
it's not, these programs ("cms" in the case at hand) will grab at least
one noise pointer after the end of the actual argument list. For
example, some diagnostic output looked like this:
cms. argc = 10.
[Here, it's looking at the non-option (file-name) arguments...]
cms(0). argc_x = 3, *args: >smime-certs/smrsa1.pem<.
cms(1). argc_x = 3, *args: >smime-certs/smrsa1.pem<.
file_ctrl(). ptr: %x00000000004e077a >smime-certs/smrsa1.pem<.
cms(1). argc_x = 2, *args: >smime-certs/smrsa2.pem<.
file_ctrl(). ptr: %x00000000004e0791 >smime-certs/smrsa2.pem<.
cms(1). argc_x = 1, *args: >smime-certs/smrsa3.pem<.
file_ctrl(). ptr: %x00000000004e07a8 >smime-certs/smrsa3.pem<.
cms(1). argc_x = 0, *args: >ÀØÜz<.
file_ctrl(). ptr: %x000000007adcd870 >ÀØÜz<.
Error opening recipient certificate file ÀØÜz
910895052:error:02001002:system library:fopen:no such file or directory:ALP$DKA0
:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d_64.crypto.bio]bss_file.c;3:403:fopen('ÀØ
Üz','r')
910895052:error:20074002:BIO routines:FILE_CTRL:system lib:ALP$DKA0:[UTILITY.SOU
RCE.OPENSSL.openssl-1_0_0d_64.crypto.bio]bss_file.c;3:405:
unable to load certificate
("argc_x" is my own decrementing "argc"-related variable, and when it
hit zero, it was time to stop.)
Perhaps "argv" _should_ be NULL-terminated, but that seems not to be
the case here. (Eventually, the programs are likely to run into enough
zero bytes to stop the scan, but who knows when?) I have no idea how
much space is actually allocated in this case, so I'd be reluctant to
jam a NULL into argv[ argc], just so that this code will work reliably.
One possible solution (work-around?) would be not to look for a
NULL terminator in "argv", but instead count the arguments, and quit
when the last argument has been processed. For example, instead of
bumping that "args" pointer through the "argv" array (looking for that
NULL), one could use an integer argument counter, say, "arrghc", look at
"argv[ arrghc]" instead of "*args", and stop when "arrghc" gets up to
"argc". Making the changes to all these files would be tedious, but
(not having tried it) I don't see any obvious problems.
Using the known count ("argc") makes more sense to me than looking
for a terminating (NULL) value, but what do I know?
Again, even if there's some Standard which demands a NULL after the
(known) end of "argv", I ain't got one, so it wouldn't help.
Thoughts?
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
