openssl breakage: apache2, kdelibs3, mutt-devel

[Thomas Klausner]

Hi!

On current/amd64, apache, mutt-devel and kdelibs3 fail with similar
errors:

apache2:
--- ssl_engine_init.lo ---
ssl_engine_init.c: In function 'ssl_init_ctx_protocol':
ssl_engine_init.c:391: warning: assignment discards qualifiers from pointer target type
ssl_engine_init.c:397: warning: assignment discards qualifiers from pointer target type
ssl_engine_init.c: In function 'ssl_init_ctx_verify':
--- ssl_engine_kernel.lo ---
ssl_engine_kernel.c: In function 'ssl_hook_Access':
ssl_engine_kernel.c:249: warning: assignment discards qualifiers from pointer target type
--- ssl_engine_init.lo ---
ssl_engine_init.c:534: error: 'STACK' undeclared (first use in this function)
ssl_engine_init.c:534: error: (Each undeclared identifier is reported only once
ssl_engine_init.c:534: error: for each function it appears in.)
ssl_engine_init.c:534: error: expected expression before ')' token
ssl_engine_init.c: In function 'ssl_init_FindCAList':
ssl_engine_init.c:1109: warning: pointer type mismatch in conditional expression
*** [ssl_engine_init.lo] Error code 1
--- ssl_engine_kernel.lo ---
ssl_engine_kernel.c:553: warning: assignment from incompatible pointer type
ssl_engine_kernel.c:683: warning: assignment discards qualifiers from pointer target type
--- ssl_engine_vars.lo ---
ssl_engine_vars.c: In function 'ssl_var_lookup_ssl_cipher':
ssl_engine_vars.c:540: warning: initialization discards qualifiers from pointer target type
ssl_engine_vars.c: In function 'ssl_var_lookup_ssl_cipher_bits':
ssl_engine_vars.c:566: warning: assignment discards qualifiers from pointer target type

kdelibs3:
./kopenssl.h:528: error: expected ';' before '(' token
./kopenssl.h:534: error: 'STACK' has not been declared
./kopenssl.h:540: error: 'STACK' has not been declared
./kopenssl.h:546: error: expected ';' before '(' token
./kopenssl.h:552: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:552: error: expected ';' before '*' token
./kopenssl.h:558: error: 'STACK' has not been declared
./kopenssl.h:564: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:564: error: expected ';' before '*' token
./kopenssl.h:830: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:830: error: expected ';' before '*' token
./kopenssl.h:831: error: 'STACK' has not been declared
./kopenssl.h:528: error: expected ';' before '(' token
./kopenssl.h:534: error: 'STACK' has not been declared
./kopenssl.h:540: error: 'STACK' has not been declared
./kopenssl.h:546: error: expected ';' before '(' token
./kopenssl.h:552: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:552: error: expected ';' before '*' token
./kopenssl.h:558: error: 'STACK' has not been declared
./kopenssl.h:564: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:564: error: expected ';' before '*' token
./kopenssl.h:830: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:830: error: expected ';' before '*' token
./kopenssl.h:831: error: 'STACK' has not been declared
./kopenssl.h:528: error: expected ';' before '(' tokenkssl.cc: In member function 'void KSSL::setPeerInfo()':

mutt-devel:
--- mutt_ssl.o ---
mutt_ssl.c: In function 'check_host':
mutt_ssl.c:655: error: 'STACK' undeclared (first use in this function)
mutt_ssl.c:655: error: (Each undeclared identifier is reported only once
mutt_ssl.c:655: error: for each function it appears in.)
mutt_ssl.c:655: error: 'subj_alt_names' undeclared (first use in this function)
mutt_ssl.c:656: warning: ISO C90 forbids mixed declarations and code
mutt_ssl.c: In function 'ssl_cache_trusted_cert':
mutt_ssl.c:738: warning: assignment from incompatible pointer type


Is there a migration guide somewhere, or can someone tell me what the proper fix is?

Thanks,
Thomas

[Thor Lancelot Simon]

Post by Thomas Klausner
Hi!
On current/amd64, apache, mutt-devel and kdelibs3 fail with similar

The "pointer target type" errors are because the OpenSSL guys finally
applied some const poisoning. Unfortunately, they took so long to do so
that most applications' default GCC settings now make this an effective
API change.

The STACK errors are just annoying. It's one of those pseudo-openssl-
internal parts of the API (like OPENSSL_malloc()/OPENSSL_free()) that
is documented in the manual pages for other parts of the API and can't
be avoided if you want to do certain things that are allegedly supported;
yet since it's not directly documented itself I guess they feel free to
change it and break people's application code.

These problems are making me think that, despite the pain, it might be
best to back OpenSSL down to 1.0.0-beta3 in our tree. That would also
make life easier for people who want to use the FIPS canister in the
future, I think.

Thor

[Thomas Klausner]

Post by Thor Lancelot Simon
The STACK errors are just annoying. It's one of those pseudo-openssl-
internal parts of the API (like OPENSSL_malloc()/OPENSSL_free()) that
is documented in the manual pages for other parts of the API and can't
be avoided if you want to do certain things that are allegedly supported;
yet since it's not directly documented itself I guess they feel free to
change it and break people's application code.

Do you know what STACK should be replaced with?
Thomas

[Thor Lancelot Simon]

Post by Thomas Klausner

Post by Thor Lancelot Simon
The STACK errors are just annoying. It's one of those pseudo-openssl-
internal parts of the API (like OPENSSL_malloc()/OPENSSL_free()) that
is documented in the manual pages for other parts of the API and can't
be avoided if you want to do certain things that are allegedly supported;
yet since it's not directly documented itself I guess they feel free to
change it and break people's application code.

Do you know what STACK should be replaced with?

I haven't figured it out yet, but I need to as well!

[Christos Zoulas]

Post by Thor Lancelot Simon

Post by Thomas Klausner

Post by Thor Lancelot Simon
The STACK errors are just annoying. It's one of those pseudo-openssl-
internal parts of the API (like OPENSSL_malloc()/OPENSSL_free()) that
is documented in the manual pages for other parts of the API and can't
be avoided if you want to do certain things that are allegedly supported;
yet since it's not directly documented itself I guess they feel free to
change it and break people's application code.

Do you know what STACK should be replaced with?

I haven't figured it out yet, but I need to as well!

Well, the real "fix" is to replace STACK with STACK_OF(type) like the rest
of the code has done...

christos

[Christos Zoulas]

Post by Thomas Klausner

Post by Thor Lancelot Simon
The STACK errors are just annoying. It's one of those pseudo-openssl-
internal parts of the API (like OPENSSL_malloc()/OPENSSL_free()) that
is documented in the manual pages for other parts of the API and can't
be avoided if you want to do certain things that are allegedly supported;
yet since it's not directly documented itself I guess they feel free to
change it and break people's application code.

Do you know what STACK should be replaced with?

try typedef void *STACK;

christos

[Matthias Scheler]

Post by Thomas Klausner
On current/amd64, apache, mutt-devel and kdelibs3 fail with similar

The "apache22" package has a fix for this.

Post by Thomas Klausner
Is there a migration guide somewhere, or can someone tell me what the proper fix is?

Please have a look at Adam Ciarcinski's fixes which are used for
the "apache22" package before the bug got fixed upstream:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/apache22/patches/Attic/patch-ba?rev=1.4&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/apache22/patches/Attic/patch-bb?rev=1.3&content-type=text/x-cvsweb-markup

They illustrate how to fix this without breaking backwards compatibility
(at least not with NetBSD 5.0).

Kind regards

[Mark Davies]

Post by Thomas Klausner
On current/amd64, apache, mutt-devel and kdelibs3 fail with similar

wip/kdelibs4 has some patches to deal with the equivalent issue there.
I haven't yet looked to see how well they map onto the kdelibs3 code
as I don't have any -current systems to try on at the moment.

cheers
mark