[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#841638: transition: libcrypto++



Hi Emilio,

On Sat, Oct 22, 2016 at 1:06 PM, Emilio Pozuelo Monfort
<pochu@debian.org> wrote:
> On 21/10/16 18:20, Laszlo Boszormenyi (GCS) wrote:
>> I'd like to update libcrypto++ from 5.6.4 to 5.6.5; which is a
>> semi-transition. Packages I've tried works with both version,
>> however without binNMUs those will print this:
>> Symbol `_ZTVN8CryptoPP23FilterWithBufferedInputE' has different size in shared object, consider re-linking
>> Symbol `_ZTVN8CryptoPP10HexEncoderE' has different size in shared object, consider re-linking
>> Symbol `_ZTVN8CryptoPP11ProxyFilterE' has different size in shared object, consider re-linking
>>
>> This matches upstream recommendation[1]:
>> "maintenance release, recompile of programs recommended"
>
> Does this bump the SONAME, or is it an ABI break without a SONAME bump?
 No, the SONAME is the same. ABI should be the same, but I've found
one (more may exist) case where one (probably internal) symbol can't
be found anymore:
Generating secure encryption key. This might take some time..done
cryfs: symbol lookup error: cryfs: undefined symbol:
_ZN8CryptoPP10RandomPool34GenerateIntoBufferedTransformationERNS_22BufferedTransformationERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEy

If I recompile it with the new libcrypto++ release, it is solved.
As this effects cryptography related programs, I want to be extra
safe. The package list for binNMUs:
amule
armory
clementine
codecrypt
cryfs
entropybroker
gdal
murasaki
newlisp
pycryptopp
synergy
tegrarcm

Regards,
Laszlo/GCS


Reply to: