On Mon, 2017-05-29 at 06:37 +0200, Nikos Mavrogiannopoulos wrote: > On Sun, 2017-05-28 at 18:02 +0200, Andreas Metzler wrote: > > On 2017-05-27 Nikos Mavrogiannopoulos <[email protected]> wrote: > > [...] > > > * Noteworthy changes in release 4.11 (released 2017-05-27) > > > [stable] > > > - Introduced the ASN1_TIME_ENCODING_ERROR error code to indicate > > > an invalid encoding in the DER time fields. > > > - Introduced flag ASN1_DECODE_FLAG_ALLOW_INCORRECT_TIME. This > > > flag > > > allows decoding errors in time fields even when in strict DER > > > mode. > > > That is introduced in order to allow toleration of invalid > > > times > > > in > > > X.509 certificates (which are common) even though strict DER > > > adherence > > > is enforced in other fields. > > > - Added safety check in asn1_find_node(). That prevents a crash > > > when a very long variable name is provided by the developer. > > > Note that this to be exploited requires controlling the ASN.1 > > > definitions used by the developer, i.e., the 'name' parameter > > > of > > > asn1_write_value() or asn1_read_value(). The library is > > > not designed to protect against malicious manipulation of the > > > developer assigned variable names. Reported by Jakub Jirasek. > > > > [...] > > > > Hello, > > > > this release features a soname bump (libtasn1.so.6 -> > > libtasn1.so.7). > > As > > the changelog does not mention an ABI break I assume this was not > > done > > intentionally. Perhaps a typo, bumping LT_CURRENT instead of > > LT_REVISION? > > You are right. I'll make a new release fixing that issue and > introduce > an ABI check to avoid such issues in the future.
Thanks, I've released 4.12 addressing only that issue. It seems that there is already an abi check with abi-compliance-checker as part of the release process but unfortunately it doesn't include the so-name version matching as part of its tests. I'm open to suggestions for that. regards, Nikos
