El jue., 16 may. 2019 a las 9:09, David Lang (<[email protected]>) escribió: > > On Thu, 16 May 2019, Rainer Gerhards wrote: > > > El jue., 16 may. 2019 a las 7:46, David Lang via rsyslog > > (<[email protected]>) escribió: > >> > >> I saw a issue that said that the version of gnutls shipped in RHEL6 has > >> serious problems. I'm not finding detals easily, can someone give a brief > >> explination of the problem? > > > > I couldn't find the issue tracker, there exists at least one. The > > issue is that the version that comes with CentOS 6 segfaults from time > > to time. It abort with an internal error which starts with something > > like "Ohhh jeeeh" (or so ;-)) Newer versions don't have this issue. We > > tried hard to isolate this in rsyslog code, but it really looks like > > it is a GnuTLS issue. > > > > My approach is to suggest use of openSSL instead of GnuTLS. With > > openssl we can also generate much more meaningful error messages plus > > it's certificate handling is far superior. > > Ok, I may be able to contribute information here. At my new job (3 days in) > one > of the other admins tracked things down a bit more. > > forwarding info from an internal ticket: > > If a tls handshake is interrupted, there is a function that retries the > operation. it essentially takes a memory address of a typed defined structure > "pNsd". A member of this structure (retryCall) is evaluated for the result of > a > TLS session (as conducted via gnutls_handshake()) and sets memory with the > result. If the result is non-zero an exception is entered. In this case the > exception returned can be tied back to an overflow (specifically, > GNUTLS_E_UNEXPECTED_PACKET_LENGTH as defned in gnutls.h). Since this cannot be > handled, the code invokes a macro (ABORT_FINALIZE) which sets a global vrable > in > memory and then calls a goto statement called finalize_it - This does some > things, but ultimately sets a member ofpNsd (bAbortConn). This ultimately > causes > rsyslog to abort and die.
The interesting there here is why it aborts. Any information on that? Is there a suggested way to handle this signal? If we cannot handle it, the right thing to do is to abort the connection,, which is done by setting bAbortConn. Rainer > > this was with 8.37 (and possibly 8.24) on RHEL6 (unknown generation) > > reading this, it seems to me that gnutls seems to be doing the right thing, > but > I am guessing that it's possible that the error that gets propodated back to > rsyslog isn't being handled. > > But I have notlooked at the code. I've passed on the info that there were > problems with gnuTLS on RHEL 6 and suggested that there are lots of TLS fixes > in > more recent versions, but I figured I'd do a bit more digging on the rsyslog > side to pass details of the problems back, It sounds as if the > detailed analysis may help track down the bug on the rsyslog side as well. > > David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
