2015-02-09 22:52 GMT+03:00 Rainer Jung <rainer.j...@kippdata.de>:
> Am 09.02.2015 um 20:31 schrieb Rainer Jung:
>
>
>>>> src/sslinfo.c: In function
>>>> 'Java_org_apache_tomcat_jni_SSLSocket_getInfoB':
>>>> src/sslinfo.c:221:51: error: dereferencing pointer to incomplete type
>>>>                   array = tcn_new_arrayb(e, &session->session_id[0],
>>>>                                                     ^
>>>> src/sslinfo.c:222:47: error: dereferencing pointer to incomplete type
>>>>                                          session->session_id_length);
>>>>                                                 ^
>>>> src/sslinfo.c: In function
>>>> 'Java_org_apache_tomcat_jni_SSLSocket_getInfoS':
>>>> src/sslinfo.c:301:51: error: dereferencing pointer to incomplete type
>>>>                   char *hs = convert_to_hex(&session->session_id[0],
>>>>                                                     ^
>>>> src/sslinfo.c:302:50: error: dereferencing pointer to incomplete type
>>>>                                             session->session_id_length);
>>>>                                                    ^
>>>
>>>
>>> Hmm, that's weird. That code's been like that for ... ever.
>>>
>>> Does anybody know what the build environment looks like for this?
>>>
>>> SSL_SESSION.session_id is an unsigned char[]
>>>
>>> It would be odd to do "&session->session_id[0]" instead of simply
>>> "session->session_id" unless one wanted to obfuscate the loss of type
>>> information.
>>>
>>> SSL_SESSION.session_id_length is an unsigned int and .. it should be
>>> fine.
>>>
>>> I think the OpenSSL being used here might be borked.
>>
>>
>> I followed a couple of links from the above ones and landed at a gump
>> page looking like it would use the master branch of OpenSSL at github.
>>
>> If that is true, it can well be, that direct access to internal OpenSSL
>> structures is no longer possible. The general tendency is making
>> structures opaque and allowing access only via accessor functions.
>>
>> I haven't checked, whether this is the case here.
>
>
> OK, this should probably be (from ssl/ssl.h):
>
> const unsigned char *SSL_SESSION_get_id(const SSL_SESSION *s,
>                     unsigned int *len);
>
> The function exists at least since 0.9.8 (checked with 0.9.8za).
>
> I tried to fix it in r1658557.

I merged that into 1.1.x branch in r1658603.

The fix is good:
sslinfo.c was compiled successfully.

It now fails on similar issue on the next file,

[[[
src/sslnetwork.c: In function 'ssl_socket_recv':
src/sslnetwork.c:413:36: error: dereferencing pointer to incomplete type
             if (s == 0 && (con->ssl->shutdown & SSL_RECEIVED_SHUTDOWN)) {
                                    ^
src/sslnetwork.c: In function
'Java_org_apache_tomcat_jni_SSLSocket_renegotiate':
src/sslnetwork.c:650:13: error: dereferencing pointer to incomplete type
     con->ssl->state = SSL_ST_ACCEPT;
             ^
make[1]: *** [src/sslnetwork.lo] Error 1
make[1]: Leaving directory `/srv/gump/public/workspace/tomcat-native/native'
make: *** [all-recursive] Error 1
]]]

http://vmgump.apache.org/gump/public/tomcat-native/tomcat-native-make/gump_work/build_tomcat-native_tomcat-native-make.html

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to