Advisories and Patches

Reliability and security of our software products is a top priority. Since 2002 the gSOAP software is subjected to rigorous testing as part of quality assurance practices. Our source code is continuously analyzed by the most aggressive top-rated static analysis tools, including Fortify, Coverity and Valgrind (the gSOAP engine also includes a built-in leak checker enabled in DEBUG mode). And first and foremost, the gSOAP source code is downloaded a million times by satisfied developers working at small to large companies world-wide. We listen to you to improve our software, so let us know if you need assistance by [contacting us.](contact.html) In the interest of full transparency with our customers and with the open source community of gSOAP users, we collect and post all issues ranging from minor issues to critical bugs on this page since 2004. Visit our [download](downloads.html) page to upgrade your version of gSOAP. Feel free to [subscribe](https://eepurl.com/cW6GT1) to receive notifications of important updates from Genivia. In addition to offering sane advice to developers in tutorials, examples and documentation, Genivia also offers technical support and expert consulting services. Thank you for giving us the opportunity to serve you! How to request technical support when you have a problem or found a bug --- If you find an issue that is not already reported on this page or is not already resolved by [SourceForge's bug tracker](https://sourceforge.net/p/gsoap2/bugs), then here is what you should do. ### Commercial edition users You are entitled to our timely expert professional support. Please [submit a ticket](inquire/support.php) or [contact us](contact.html) for more details about technical support services offered by Genivia. ### Open source users Report bugs or ask for support by visiting the [SourceForge gSOAP bug tracker](http://sourceforge.net/p/gsoap2/bugs/) and [SourceForge gSOAP support tracker.](http://sourceforge.net/p/gsoap2/support-requests/) We monitor these trackers and you will receive status updates as the issues are addressed over time. WSA and WSSE plugin bugs in some gSOAP versions up to 2.8.110 (Nov 20, 2020, Jan 22 2021) --- All [commercial release downloads](downloads.html) are patched and updated. All open source releases are up to date since version 2.8.111. Two potential null pointer dereferences may occur in the WSA (WS-Addressing versions 2.7.16-2.8.110) plugin and WSSE (WS-Security versions 2.8.34-2.8.110) plugin and random 4GB heap memory corruption may potentially occur in the WSA (WS-Addressing versions 2.8.31-2.8.110) plugin. None of these issues can occur with normal usage and messaging with the plugins, but may happen in very specific scenarios involving XML messages that are invalid and non-compliant. Upgrading to gSOAP 2.8.111 or greater is strongly recommended if one of these plugins is used. The potential denial of service issues were published as multiple CVEs by a third party (CVE-2020-13574 to 8 and duplicate CVE-2021-21783) to maximize getting credit for each combination, even though the pointer problems in the two plugins are related. Also by contrary to one of the claims, remote code execution is impossible (4GB uncontrolled data written to the heap at a random location) and no proof of concept or exploit exists. False claim of a security risk when gSOAP is used --- It was brought to our attention that false claims of security risks are publicly posted online, claiming that trajectory traversals are allowed with HTTP GET (or other HTTP methods) with gSOAP. The gSOAP software **does not offer web servers or library functions that use the path part of the HTTP request URL to access and load files**. The GET plugin can be used to load a file, **but only with manual code written by the developer**. In fact, since 2003 the gSOAP software includes the source code of one example web server to assist developers, in which directory traversals are explicitly forbidden and it states very clearly why: int http_GET_handler(struct soap *soap) { ... // note: a small piece of code is located here that deals with compressed HTML requests /* Use soap->path (from request URL) to determine request: */ if (options[OPTION_v].selected) fprintf(stderr, "HTTP GET Request '%s' to host '%s' path '%s'\n", soap->endpoint, soap->host, soap->path); /* we don't like requests to snoop around in dirs, so we must reject request that have paths with a '/' or a '\'. You must at least check for .. to avoid request from snooping around in higher dirs!!! */ if (strchr(soap->path + 1, '/') || strchr(soap->path + 1, '\\')) return 403; /* HTTP forbidden */ Also our [tutorials](tutorials.html) state for many years the following paragraph in "How to make stand-alone services serve HTTP GET requests": "*This example returns the content of file `service.wsdl` located in the current directory, upon receiving a URL with a `?wsdl` query string. It may be tempting to return files referenced in the `soap->path` string, but **do not use the path to simply return files referenced in the url** without making sure that the directories and files opened do not pose security risks. Strip all `/` from the file names to open, or at least strip `..` to prevent snooping around with `../../` from the directory root.*" Likewise, the [HTTP GET plugin documentation](doc/guide/html/group__group__io.html#ga0ecdc43a53e494edc4f84e8c135659ba) warns of the same. It is clear that we made all possible efforts for many years to force developers to understand the security implications of using `soap->path` unconstrained. If a developer does not follow our documentation or the examples that we make publicly available, then the developer is deliberately implementing a well-known problem with custom code that deviates from ours. Bug in gSOAP versions to 2.8.98 for applications built with the WITH_COOKIES flag enabled (Mar 12, 2020) --- All [commercial release downloads](downloads.html) are patched and updated. This cookie memory deallocation bug is unlikely to occur under normal usage, but could cause a runtime error and a potential abort. Server applications built with the optional `-DWITH_COOKIES` flag or with the optional C/C++ `libgsoapck`/`libgsoapck++` cookie-enabled libraries are affected. This flag is typically not required or recommended to deploy services and we expect very few applications to be affected in practice. Other configurations are not affected. It is recommended to upgrade to 2.8.99 or greater. If upgrading is not possible, then patch `gsoap/stdsoap2.c` and `gsoap/stdsoap2.cpp` function `soap_getcookies` with the following two additions (approx line 936): if (domain) { p->domain = domain; domain = NULL; // added } else { p->domain = NULL; } if (path) { p->path = path; path = NULL; // added } Not an actual gSOAP bug or vulnerability (Jan 2019) --- The makers of a certain type of product implemented an iterative web server vulnerable to denial of service (CVE-2019-6973) because of a long TCP bind queue and long socket timeouts. Our documentation specifically states that multi-threaded servers should be implemented, not iterative which are known to block requests! In fact, since 2003 we offer public recommendations on how to safely implement web servers in the gSOAP [user guide](doc/guide/html/index.html) and in our [tutorials](tutorials.html#How_to_implement_and_deploy_gSOAP_Web_services). For over a decade, the documentation specifically addresses the critical importance of proper socket timeouts and how to safely deploy services as multi-threaded services or with Apache or IIS, as demonstrated by our example web server demo included with the gSOAP software (since 2003). This part of the gSOAP library API and the documentation has not changed since 2003 and is field-tested safe when used properly. Developers should follow our documentation, tutorials, and the examples that we make publicly available. When in doubt, contact us for technical support. Bug in gSOAP versions 2.7.0 to 2.8.74 for applications built with the WITH_COOKIES flag enabled (Jan 14, 2019) --- All [commercial release downloads](downloads.html) are patched and updated. This critical bug (CVE-2019-7659) affects server applications built with the `-DWITH_COOKIES` flag enabled, possibly causing an application abort. The bug affects the C/C++ `libgsoapck`/`libgsoapck++` and `libgsoapssl`/`libgsoapssl++` libraries as these are built with `-DWITH_COOKIES` enabled. This flag is typically not required or recommended to deploy services and we expect very few applications to be affected in practice. It is recommended to upgrade to 2.8.75 or greater. If upgrading is not possible, then patch `gsoap/stdsoap2.c` and `gsoap/stdsoap2.cpp` function `soap_encode_url` with the following four changes (approx line 8305): SOAP_FMAC1 int // changed SOAP_FMAC2 soap_encode_url(const char *s, char *t, int len) // changed { int c; int n = len; // changed if (n <= 0) return 0; // added Update `gsoap/stdsoap2.h` approx line 3622: SOAP_FMAC1 int SOAP_FMAC2 soap_encode_url(const char*, char*, int); This function used to be named `soap_encode_cookie` in older gSOAP versions 2.7.0 to 2.8.14 and should be patched as indicated. Patch for SSL_get_error bug affecting gSOAP versions 2.8.71 and 2.8.72 (Nov 30, 2018) --- A bug in `SSL_get_error()` may cause this function to crash (`EXC_BAD_ACCESS`) when called a second time in function `soap_ssl_accept()` when used in HTTPS servers. HTTPS client applications are not affected. Recommended is to upgrade to 2.8.73 or greater. To patch this issue in gSOAP version 2.8.71/72, in function `soap_ssl_accept()` in `stdsoap2.c[pp]` replace `soap_ssl_error(soap, r)` (which calls `SSL_get_error()` with the non-positive return error value of `SSL_accept()`) by `"SSL/TLS error"` as follows: SOAP_FMAC1 int SOAP_FMAC2 soap_ssl_accept(struct soap *soap) { ... while ((r = SSL_accept(soap->ssl)) <= 0) { int err; if (retries-- <= 0) break; err = SSL_get_error(soap->ssl, r); ... } if (r <= 0) { soap_closesock(soap); soap_set_receiver_error(soap, "SSL/TLS error", "SSL_accept() failed in soap_ssl_accept()", SOAP_SSL_ERROR); return SOAP_SSL_ERROR; } Alternatively, make sure that `soap_closesock(soap)` is called after `soap_ssl_error(soap, r)` as in versions prior to 2.8.71 that are not affected by this issue: if (r <= 0) { soap_set_receiver_error(soap, soap_ssl_error(soap, r), "SSL_accept() failed in soap_ssl_accept()", SOAP_SSL_ERROR); soap_closesock(soap); return SOAP_SSL_ERROR; } Patch for gSOAP 2.8.39 to 2.8.70 xlocale.h compilation error after configure (Nov 5, 2018) --- This patch for the `configure` script addresses a failure to compile gSOAP 2.8 after running `./configure` and `make` on specific platforms that lack xlocale.h. ![Download](images/download.png) [Download patched configure script](files/configure.zip) Patch for gSOAP 2.1.6 to 2.8.52 infinite loop on malformed DIME protocol messages (Aug 28, 2017) --- All [commercial release downloads](downloads.html) are patched and updated. This patch addresses a critical issue with the DIME protocol receiver that may cause the receiver to become unresponsive when a specific malformed DIME protocol message is received. Because DIME is obsolete and this feature is not enabled by default in gSOAP, we expect very few applications to be affected in practice. [Download](downloads.html) gSOAP 2.8.53 or greater. Or alternatively, patch stdsoap2.c and stdsoap2.cpp function `soap_getdimehdr` by removing the following line that returns `SOAP_OK`: int soap_getdimehdr(struct soap *soap) { ... if (soap->dime.buflen || soap->dime.chunksize) { ... return SOAP_OK; // REMOVE THIS LINE } Security advisory: CVE-2017-9765 bug in certain versions of gSOAP 2.7 up to 2.8.47 (June 21, 2017) --- All [commercial release downloads](downloads.html) are patched and updated. The vulnerability affects stand-alone gSOAP HTTP servers deployed in uncontrolled network environments that permit messages of over 2GB in size to be uploaded to a stand-alone gSOAP server. Uploads of over 2GB of data are typically rejected by servers, making them invulnerable to this bug. Upgrading is generally recommended for server and client deployments. [Download](downloads.html) gSOAP 2.8.48 (released June 21) or greater to fix a vulnerability to a large and specifically-targeted XML message with an XML PI fragment over 2GB in size (greater than 2147483711 bytes to trigger the software bug). When triggered, a buffer overflow can cause an open unsecured server to crash or malfunction after 2GB is received. If you have a commercial support and maintenance contract then please check the list of [updated releases](downloads.html#releases) to download a patched and secured release. If the version you require is not listed then [submit a ticket](inquire/support.php) to receive patch instructions. The patch does not affect the functioning or performance of the gSOAP software. Also the [GPLv2 open source gSOAP versions on SourceForge](https://sourceforge.net/projects/gsoap2) have been updated. If upgrading is not possible, we recommend our [high protect](devilsivy.html) plugin to control your service and client application's messaging by limiting message sizes to 2GB or less. This plugin works with any old gSOAP version. The upgraded version 2.8.48 and greater do not require this plugin. Services developed with gSOAP 2.8.50 or greater, or services that use the [high protect](devilsivy.html) plugin, are protected against integer and buffer overflows. Also services developed with the [Apache module for gSOAP](https://www.genivia.com/doc/apache/html/index.html) with the LimitRequestBody set in .htaccess or httpd.conf to any non-zero value (a common configuration that avoids DDoS attacks), by default should prevent this type of HTTP vulnerabilities in the first place: the size of the HTTP message body uploaded is always limited to well below 2GB in Apache (also when running the gSOAP module). When the issue became first known to Genivia, the problem was analyzed within 24 hours to update the software, and Genivia staff immediately informed its current customers June 22 by reaching out with download and patch instructions. Patch for exception trigger in gSOAP 2.8.23 to 2.8.43 on windows platforms (Feb 2017) {#iphr} --- All [commercial release downloads](downloads.html) are patched and updated. A parameter passing issue with the secure string functions (`_s` functions) may cause a soft exception to occur in applications developed on Windows. Upgrade to 2.8.44 or greater. If upgrading is not possible, check gsoap-2.8/gsoap/stdsoap2.h around line 1446 for the two macros `soap_strncpy` and `soap_strncat` that use `strncpy_s` and `strncat_s`. Remove the `#if _MSC_VER >= 1400` branch that defines the `_s`-based macros and keep the macro in the `#else` branch only. This prevents [Invalid Parameter Handler Routine](https://msdn.microsoft.com/en-us/library/ksazx244.aspx) invocation. The invocation is **very unlikely to occur**, but in one case there is no absolute guarantee. Patch for gSOAP 2.8.23 to 2.8.30 memory leak in C++ directly nested dynamic arrays (Apr 2016) --- All [commercial release downloads](downloads.html) are patched and updated. A memory deallocation issue may result in leaks in C++ with directly-nested dynamically-allocated arrays in classes and structs. C++ containers are fine and are generated by default by wsdl2h for C++, meaning applications created by manually modifying header file specifications are affected (nested arrays are rarely used in C++ and requires manual coding instead of the wsdl2h generator). These are classes or structs with a `__ptr` and a `__size` member such that the members also contain arrays. The patch for stdsoap2.h:3394 in `template<class T> struct soap_block` is: static void save(struct soap *soap, struct soap_blist *b, T *p) { if (!b) b = soap->blist; for (T *q = (T*)soap_first_block(soap, b); q; q = (T*)soap_next_block(soap, b)) { soap_update_pointers(soap, (const char*)p, (const char*)q, sizeof(T)); *p++ = *q; q->T::~T(); } soap_end_block(soap, b); // ADD THIS LINE } Patch for gSOAP 2.8.28 "SNI failed" HTTPS connection error with OpenSSL 0.9.8 (Feb 2016) --- When this HTTPS connection failure occurs, in stdsoap2.c/.cpp:4636 change the second line of: #elif (OPENSSL_VERSION_NUMBER >= 0x0090800fL) && defined(SSL_CTRL_SET_TLSEXT_HOSTNAME) if (SSL_ctrl(soap->ssl, SSL_CTRL_SET_TLSEXT_HOSTNAME, TLSEXT_NAMETYPE_host_name, (void*)host)) to: #elif (OPENSSL_VERSION_NUMBER >= 0x0090800fL) && defined(SSL_CTRL_SET_TLSEXT_HOSTNAME) if (!SSL_ctrl(soap->ssl, SSL_CTRL_SET_TLSEXT_HOSTNAME, TLSEXT_NAMETYPE_host_name, (void*)host)) OpenSSL security advisory: OpenSSL updates required for gSOAP 2.7.0 to 2.8.28 (Feb 2016) --- Due to the recent publishing of information regarding a TLS/SSL protocol vulnerability [(ISC diary entry)](http://isc.sans.org/diary.html?storyid=7534) OpenSSL has released a new version OpenSSL 0.9.8l. Please use the latest OpenSSL release with gSOAP. OpenSSL 1.0.1 users should upgrade to 1.0.1j to work around the SSLv3 POODLE vulnerability (CVE-2014-3566). The gSOAP version releases 2.8.20 and greater support only TLS by default, with SSLv3 disabled (can be selectively enabled). For older versions of gSOAP 2.8.19 and lesser, we recommend disabling SSLv3 support. Thus enabling TLSv1 (TLS 1.0, 1.1, and 1.2) only. This provides a safe workaround this issue in general (for any OpenSSL version). To do so, on the client side set the SSL context as follows: soap_ssl_client_context(soap, SOAP_SSL_REQUIRE_SERVER_AUTHENTICATION | SOAP_TLSv1, ...) On the server side set the context as follows: soap_ssl_server_context(soap, SOAP_TLSv1, ...) or set the context as follows when the client is required to authenticate: soap_ssl_server_context(soap, SOAP_SSL_REQUIRE_CLIENT_AUTHENTICATION | SOAP_TLSv1, ...) Changes in the OpenSSL API can lead to a client-side crash in the gSOAP engine for all gSOAP versions up to and including 2.8.11. This is fixed in 2.8.12 and greater. The fix is to replace `tcp_connect()` in `stdsoap2.c` and `stdsoap2.cpp` with [this new tcp_connect.c](files/new_tcp_connect.zip) code that replaces the host name check code that is no longer supported in newer OpenSSL versions 0.9.8 and greater. Patch for gSOAP 2.8.25 and 2.8.26 error when using WITH_NOIDREF (Nov 2015) --- All [commercial release downloads](downloads.html) are patched and updated. Forcing the `WITH_NOIDREF` flag to compile the source code may cause an immediate application termination in versions 2.8.25 and 2.8.26. In stdsoap2.c/.cpp in `soap_versioning(soap_init)` close to line 2577 remove `#ifndef WITH_NOIDREF` to enable `soap_init_iht`: #ifndef WITH_NOIDREF // REMOVE THIS LINE soap_init_iht(soap); #endif // REMOVE THIS LINE Patch to correct date time format 2.8.19 and 2.8.20 (Nov 2014) --- For versions 2.8.19 and 2.8.20: Visual Studio does not support `%F` and `%T` in `strftime`. In `stdsoap2.c` and `stdsoap2.cpp`, replace all occurrences of `%F` with `%Y-%m-%d` and `%T` with `%H:%M:%S`. Patch for HTTP digest plugin module memory deallocation error in 2.8.0 to 2.8.15 (Aug 2013) --- The plugin source code may cause double deallocation errors in OpenSSL's EVP API, possibly leading to a crash. In `gsoap/plugin/md5evp.c` change line 81 from EVP_DigestFinal(ctx, (unsigned char*)hash, &size); to EVP_DigestFinal_ex(ctx, (unsigned char*)hash, &size); Please note: the HTTP digest authentication plugin has been upgraded since version 2.8.29 to support SHA-256 as per RFC7616. MD5 is still an option. However, MD5 is a vulnerable hash algorithm and should be avoided. If MD5 digest authentication is required, note that MD5-based digest authentication may be protected with TLS/SSL connections. Patch for minor issue in 2.8.13 and 2.8.14 with DIME/MTOM attachment processing (Feb 2013) --- DIME/MTOM attachment processing may cause a rejection of the attachment. This patch also replaces `mode` with `omode` in these two functions (as shown): soap_reference(struct soap *soap, const void *p, int t) { struct soap_plist *pp; if (!p || (!soap->encodingStyle && !(soap->omode & (SOAP_ENC_DIME|SOAP_ENC_MIME|SOAP_ENC_MTOM|SOAP_XML_GRAPH))) || (soap->omode & SOAP_XML_TREE)) return 1; and soap_array_reference(struct soap *soap, const void *p, const struct soap_array *a, int n, int t) { struct soap_plist *pp; if (!p || !a->__ptr || (!soap->encodingStyle && !(soap->omode & (SOAP_ENC_DIME|SOAP_ENC_MIME|SOAP_ENC_MTOM|SOAP_XML_GRAPH))) || (soap->omode & SOAP_XML_TREE)) return 1; Patch for XML parser rejecting qualified tags when contexts are copied in 2.8.2 and 2.8.3 (Jun 2011) --- To patch a soft error in `stdsoap2.c` and `stdsoap2.cpp` function `soap_copy_context()` line 8264 (2.8.3 release), change to: soap_set_namespaces(copy, soap->namespaces); // REMOVE local_ Patches for issues in gSOAP 2.7 (predates 2010) --- The gSOAP versions 2.7 are old and date back to the period between 2004 and 2010. Updating to 2.8 is strongly recommended. A problem with `soapcpp2` option `-b` has been reported, where the deserialized fixed-size array is not populated in the soapcpp2-generated code. Rebuild soapcpp2 with the patch for src/symbol2.c:9890: if (is_fixedstring(typ)) { fprintf(fhead,"\nSOAP_FMAC3 char* SOAP_FMAC4 soap_in_%s(struct soap*, const char*, char[], const char*);", c_ident(typ)); fprintf(fout,"\n\nSOAP_FMAC3 char* SOAP_FMAC4 soap_in_%s(struct soap *soap, const char *tag, char a[], const char *type)\n{\tchar *p;\n\tif (soap_instring(soap, tag, &p, type, %s, 1, 0, %d))\n\t\treturn strcpy(a, p);\n\treturn NULL;\n}", c_ident(typ), soap_type(typ), typ->width / ((Tnode*)typ->ref)->width - 1); return; WSRM plugin leak fix wsrmapi.c:3231, insert two lines: for (q = p->list; q; q = r) { r = q->next; if (q->buf) free((void*)q->buf); free((void*)q); } Problem with `#import "custom/duration.h"` that is using an incorrect file name Patch by changing `typemap.dat` line 94: xsd__duration = #import "custom/duration.h" | xsd__duration to: xsd__duration = #import "custom/duration.h" | xsd__duration ### Patch for using QT with gSOAP A problem with floating point data has been reported when using QT with gSOAP: QApplication app(argc, argv); or QCoreApplication app(argc, argv); before the gSOAP call, produced a truncated float that keeps only the integer part. It seems that this could be a locale problem (using decimal `.` versus `,`). For correct locale usage in gSOAP, compile the sources with `-DWITH_C_LOCALE`. ### Patch for gSOAP 2.7.14 A win32 bug with `select()` was found when send/recv timeouts are used. This may lead to premature connection termination. Patch in `stdsoap2.c` and `stdsoap2.cpp` line 4349: static int tcp_select(struct soap *soap, SOAP_SOCKET s, int flags, int timeout) { register int r; struct timeval tv; fd_set fd[3], *rfd, *sfd, *efd; soap->errnum = 0; #ifndef WIN32 // ADD /* if fd max set size exceeded, use poll() when available */ #if defined(__QNX__) || defined(QNX) /* select() is not MT safe on some QNX */ if (1) ... #else { soap->error = SOAP_FD_EXCEEDED; return -1; } #endif #endif // ADD rfd = sfd = efd = NULL; ### Patch for 2.7.x SSL The following is a fix to improve SSL shutdown speed. Change `stdsoap2.c` and `stdsoap2.cpp` line 4630 by replacing `SOAP_TCP_SELECT_SND` by `SOAP_TCP_SELECT_RCV`: { /* wait up to 10 seconds for close_notify to be sent by peer (if peer not present, this avoids calling SSL_shutdown() which has a lengthy return timeout) */ r = tcp_select(soap, soap->socket, SOAP_TCP_SELECT_RCV | SOAP_TCP_SELECT_ERR, 10); ### Patch for gSOAP 2.7.12 Patch for a `xsd:dateTime` numeric timezone normalization issue when converting to a dateTime with numeric timezone `(+hh:mm)` to `time_t` (e.g. `2000-03-04T02:00:00+03:00`). Patch `stdsoap2.c` and `stdsoap2.cpp` line 10886: /* put hour and min in range */ T.tm_hour += T.tm_min / 60; T.tm_min %= 60; if (T.tm_min < 0) { T.tm_min += 60; T.tm_hour--; } T.tm_mday += T.tm_hour / 24; T.tm_hour %= 24; if (T.tm_hour < 0) { T.tm_hour += 24; T.tm_mday--; } /* note: day of the month may be out of range, timegm() handles it */ ### Patch for gSOAP 2.7.11 In `wsseapi.c` line 2721 initialization of `count = 0` is missing: static size_t soap_wsse_verify_nested(struct soap *soap, struct soap_dom_element *dom, const char *URI, const char *tag) { size_t count = 0; ### Patch for 2.7 issues with strtof Fix for known problems with `strtof()` on some platforms (e.g. SUSE 11). Replace `stdsoap2.c` and `stdsoap2.cpp` line 9724: #if defined(HAVE_STRTOF_L) char *r; *p = strtof_l((char*)s, &r, soap->c_locale); if (*r) #elif defined(HAVE_STRTOD_L) char *r; *p = (float)strtod_l(s, &r, soap->c_locale); if (*r) #elif defined(HAVE_STRTOF) char *r; *p = strtof((char*)s, &r); if (*r) #elif defined(HAVE_STRTOD) char *r; *p = (float)strtod(s, &r); if (*r) #endif with: #if defined(HAVE_STRTOD_L) char *r; *p = (float)strtod_l(s, &r, soap->c_locale); if (*r) #elif defined(HAVE_STRTOD) char *r; *p = (float)strtod(s, &r); if (*r) #endif ### Patch for gSOAP 2.7.10 ![Download](images/download.png) [Download stdsoap2.h/.c/.cpp)](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.10-upd.zip) to fix a floating point conversion with GLIBC using C locale, fixed `xsd:dateTime` timezone offset handling (+/-HH.MM), and fixed SOAPAction output. ### Patch for gSOAP 2.7.9l/k ![Download](images/download.png) [Download dom.h](http://www.cs.fsu.edu/~engelen/dom.h.zip) with missing `xsd__anyAttribute` definitions ![Download](images/download.png) [Download stdsoap2.h/.c/.cpp](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.9l-upd.zip) with improved HTTP chunking and improved socket timeout support. ![Download](images/download.png) [Download soapcpp2 sources](http://www.cs.fsu.edu/~engelen/soapcpp2-src-2.7.9l-upd.zip) with fix for option `-i` one-way send/recv operations. ### Patch for gSOAP 2.7.9j and earier ![Download](images/download.png) [Download corrections for wsaapi.c](http://www.cs.fsu.edu/~engelen/wsaapi.c.zip) plugin. ### Patch for gSOAP 2.7.9h To run the `soapcpp2.exe` and `wsdl2h.exe` binaries, you need to install the DLLs that ship with MS VS 2005 (or install MS VS 2005). ### Patch for gSOAP 2.7.9g Minor correction needed for `samples/components/cpp/main.cpp`: rename `calc::Service` to `calc::ServiceService`. ### Patch for gSOAP 2.7.9a To prevent HTTP chunked transfer responses from server to show `202 ACCEPTED`, change `stdsoap2.c` and `stdosap2.cpp` line 13381 into (`mode` should be `omode`): if (count || ((soap->omode & SOAP_IO) == SOAP_IO_CHUNK)) ### Patch for gSOAP 2.7.9 Issue with an `elementFormDefault="unqualified"` bug for C++ class members that represent complexTypes. The `wsdl2h` translator may ignore option `-o`. Download gSOAP 2.7.9a with a fix. ### Updated gSOAP 2.7.8c OpenSSL extension support ![Download](images/download.png) [Download stdsoap2.h](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.8c.h) 2.7.8c updated source code ![Download](images/download.png) [Download stdsoap2.c](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.8c.c) 2.7.8c updated source code ![Download](images/download.png) [Download stdsoap2.cpp](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.8c.cpp) 2.7.8c updated source code Fix for wsse plugin API HMAC SHA1 signature verification: ![Download](images/download.png) [Download wsseapi.h](http://www.cs.fsu.edu/~engelen/wsseapi.h) plugin ![Download](images/download.png) [Download wsseapi.c](http://www.cs.fsu.edu/~engelen/wsseapi.c) plugin ### Patch for gSOAP 2.7.x OpenSSL portability In `stdsoap2.c` and `stdsoap2.cpp` OpenSSL code `meth->d2i()` produces an error on certain platforms. Suggested fix for GCC 4.x and MSVC: 3758c3758 < val = meth->i2v(meth, meth->d2i(NULL, &ext->value->data, ext->value->length), NULL); --- > val = meth->i2v(meth, meth->d2i(NULL, (unsigned const char**)&ext->value->data, ext->value->length), NULL); ### Patch for gSOAP 2.7.8b and earlier Fix for HTTPS proxy CONNECT. The `stdsoap2.c` and `stdsoap2.cpp` function `tcp_connect()` contains the following code: #ifdef WITH_OPENSSL ... userid = soap->userid; /* preserve */ passwd = soap->passwd; /* preserve */ if (soap_begin_recv(soap)) { soap->fclosesocket(soap, (SOAP_SOCKET)fd); return SOAP_INVALID_SOCKET; } soap->userid = userid; /* restore */ soap->passwd = passwd; /* restore */ ... To resolve the problem, change this into: userid = soap->userid; /* preserve */ passwd = soap->passwd; /* preserve */ if ((soap->error = soap->fparse(soap))) { soap->fclosesocket(soap, (SOAP_SOCKET)fd); return SOAP_INVALID_SOCKET; } soap->userid = userid; /* restore */ soap->passwd = passwd; /* restore */ Patch for gSOAP 2.7.8(a/b) GCC 4.1 with OpenSSL In `stdsoap2.c` and `stdsoap2.cpp` line 3737: const char *ext_str = OBJ_nid2sn(OBJ_obj2nid(X509_EXTENSION_get_object(ext))); if (!strcmp(ext_str, "subjectAltName")) { int j; - unsigned char *data; + unsigned const char *data; STACK_OF(CONF_VALUE) *val; ### Patch for gSOAP 2.7.8a On some systems the use of `soap_isnan()` may fail with a FP exception. The culprit is in `stdsoap2.h` line 847: #define soap_isnan(n) ((double)(n) == DBL_NAN) Either enable isnan checking with `-DHAVE_ISNAN` or change `stdsoap2.h` line 847 by: #define soap_isnan(n) (0) ### Patch for XML-RPC array handling in gSOAP 2.7.6c and earlier ![Download](images/download.png) [Download xml-rpc.zip](http://www.cs.fsu.edu/~engelen/xml-rpc.zip) and install in samples directory to replace xml-rpc. ### Issue with gSOAP 2.7.4/.5 The `soapcpp2` WSDL output may include additional `</message>` tags that must be removed. For some RPC encoded Response messages in the WSDL the name attribute is missing in the `<message>` element. ### Patches for gSOAP 2.7.3 Fix for hexBinary- and base64Binary-typed XML attribute parsing: ![Download](images/download.png) [Download stdsoap2.c.](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.3a.c) ![Download](images/download.png) [Download stdsoap2.cpp.](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.3a.cpp) ### Patches for gSOAP 2.7.0f Server-side fix for transmitting fault message responses to clients, which might get lost over socket that is still open but has an error state: ![Download](images/download.png) [Download stdsoap2-2.7.0f.c.](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.0f.c) ![Download](images/download.png) [Download stdsoap2-2.7.0f.cpp.](http://www.cs.fsu.edu/~engelen/stdsoap2-2.7.0f.cpp) ### Patches for gSOAP 2.7.0d The gSOAP 2.7 releases provide explicit support for schema `elementFormDefault` and `attributeFormDefault`. This enables the mixing of schemas with default qualified element/attribute tags together with schemas with unqualified element/attribute tags in the same WSDL document. As a result of these changes, when you define a document/literal service, you should add the following directive to your header file to set the element and attribute form defaults to `"qualified"`: //gsoap ns schema form: qualified or: //gsoap ns schema elementForm: qualified //gsoap ns schema attributeForm: unqualified to declare form defaults for elements and attributes (i.e. schema `elementFormDefault="qualified"` and `attributeFormDefault="unqualified"`). Repeat this for all your schemas, e.g. ns1, ns2, and so on. The difference is profound. Validating parsers require full element/attribute qualification when the schema form default is "qualified". With the directives above, the gSOAP messages conform to this requirement by producing qualified elements and attributes. The directive is automatically generated by the wsdl2h importer, so you don't need to do this again by hand. However, if you are using an older version of the wsdl2h importer (prior to 1.1.4) you should either try the new importer OR add these directives to the .h file by hand. Patches and updates for gSOAP 2.6.x and earlier (predates 2004) --- The gSOAP versions 2.6 and earlier are very old and date back to the period between 2001 and 2004 and are no longer maintained by Genivia. The issues listed below are for archival purposes only. ### gSOAP 2.6.2 A bug in `stdsoap2.c` and `stdsoap2.cpp` prevents the deserialization of `xsd:short`: soap_s2short(struct soap *soap, const char *s, short *p) { if (s) { long n; char *r; n = soap_strtol(s, &r, 10); if (*r || n < -32768 || n > 32767) return soap->error = SOAP_TYPE; *p = (char)n; ^^^^^^^^^^^ Should be *p = (short)n [![To top](images/go-up.png) To top](advisory.html)