please sync libcrypto++ 5.5.2-1 from Debian testing

Bug #189243 reported by Zooko Wilcox-O'Hearn
8
Affects Status Importance Assigned to Milestone
libcrypto++ (Ubuntu)
Fix Released
Wishlist
Emilio Pozuelo Monfort

Bug Description

Dear Ubuntu Folks:

Thank you very much for Ubuntu! I'm excited about Hardy, and I think other people are, too.

Please sync the latest Crypto++ library from Debian testing, thereby upgrading Ubuntu from Crypto++ v5.5 to Crypto++ v5.5.2.

Here is the Debian changelog; it includes a compatibility fix -- the addition of symlinks from "libcryptopp*" to "libcrypto++*".

http://packages.debian.org/changelogs/pool/main/libc/libcrypto++/libcrypto++_5.5.2-1/changelog

Here is the upstream changelog; it includes fixes for two crashes, a possible security fix, and a portability fix for 32-bit big-endian machines.

http://cryptopp.com/#news

Thank you!

Regards,

Zooko

Tags: sync
Revision history for this message
Daniel Holbach (dholbach) wrote :

This is part of the debian changelog: "Increased SONAME from 6 to 7 because of API changes."

At least amule is going to need to go through a transition. Who will take care of that?

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Are you asking me? I don't know who will take care of that. There are no source code changes required to upgrade from Crypto++ 5.5 to Crypto++ 5.5.2, so I guess this is just a matter of rebuilding amule. Aren't builds automated?

Also doesn't increasing the SONAME mean that amule can continue using the older version of libcryptopp?

Revision history for this message
Daniel Holbach (dholbach) wrote :

No doesn't look like amule can continue to use the old package:

daniel@bert:~$ debdiff libcrypto++6_5.5-5_amd64.deb libcrypto++7_5.5.2-1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/libcrypto++.so.7.0.0
-rw-r--r-- root/root /usr/share/doc/libcrypto++7/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libcrypto++7/copyright
lrwxrwxrwx root/root /usr/lib/libcrypto++.so.7 -> libcrypto++.so.7.0.0
lrwxrwxrwx root/root /usr/lib/libcryptopp.so.7 -> libcrypto++.so.7

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/libcrypto++.so.6.0.0
-rw-r--r-- root/root /usr/share/doc/libcrypto++6/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libcrypto++6/copyright
lrwxrwxrwx root/root /usr/lib/libcrypto++.so.6 -> libcrypto++.so.6.0.0

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libc6 (>= [-2.6.1-1),-] {+2.7-1),+} libgcc1 (>= 1:4.2.1), libstdc++6 (>= 4.2.1)
Installed-Size: [-4980-] {+5112+}
Maintainer: [-Ubuntu MOTU Developers <email address hidden>-]
[-Original-Maintainer:-] Jens Peter Secher <email address hidden>
Package: [-libcrypto++6-] {+libcrypto++7+}
Version: [-5.5-5-] {+5.5.2-1+}
daniel@bert:~$

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

I'm sorry, but I don't understand a lot of things about the Ubuntu package building infrastructure. My first question is: doesn't the amule package get automatically rebuilt, such as by a BuildBot, when its dependencies change? That would seem to be sufficient to solve this problem.

Here are a couple of other observations:

The amule in Debian testing is linked against the libcryptopp in Debian testing:

http://packages.debian.org/testing/amule

Apparently amule doesn't even require Crypto++ -- amule is self-contained nowadays, but it still offers the option of linking against Crypto++ instead of using its own crypto:

http://www.amule.org/wiki/index.php/Libcrypto

Regards,

Zooko

Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

It doesn't seem that amule has problems with the changes since i don't find a link to the library hardcoded. I'm testing the build, instalation and use of amule with this library to see if it works and/or fix it

nxvl@petunia:~/src/amule/amule-2.1.3$ grep -R "libcrypto++" *
configure: # Debian uses libcrypto++5.1 - it's not my fault, please soda patch the package
configure.in: # Debian uses libcrypto++5.1 - it's not my fault, please soda patch the package
debian/changelog: * Do not use an internal copy of libcrypto++, dynamically link against it
debian/changelog: + debian/control: add libcrypto++-dev to Build-Dependencies.
debian/changelog: new libcrypto++ (closes: #268460)
debian/control:Build-Depends: autotools-dev, debhelper, quilt, libglib2.0-dev, zlib1g-dev, libgd2-xpm-dev, libpng12-dev, libreadline5-dev, libcrypto++-dev, libwxgtk2.8-dev, wx2.8-i18n

Changed in libcrypto++:
assignee: nobody → nvalcarcel
status: New → In Progress
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :
Download full text (3.3 KiB)

Ok, it builds fine, but it crashes on use, here is the output of the error.

nxvl@petunia:~/src/amule$ amule
Initialising aMule
Checking if there is an instance already running...
No other instances are running.
Loading temp files from /home/nxvl/.aMule/Temp.

All PartFiles Loaded.
ListenSocket: Ok.

External connections disabled in config file
*** Server UDP socket (TCP+3) at 0.0.0.0:4665
*** TCP socket (TCP) listening on 0.0.0.0:4662
*** Client UDP socket (extended eMule) at 0.0.0.0:4672
Empty dir /home/nxvl/.aMule/Incoming/ shared
HTTP download thread started

--------------------------------------------------------------------------------
A fatal error has occurred and aMule has crashed.
Please assist us in fixing this problem by posting the backtrace below in our
'aMule Crashes' forum and include as much information as possible regarding the
circumstances of this crash. The forum is located here:
    http://forum.amule.org/board.php?boardid=67
If possible, please try to generate a real backtrace of this crash:
    http://www.amule.org/wiki/index.php/Backtraces

----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule 2.1.3 using wxGTK2 v2.8.6 (Unicoded)
Running on: Linux 2.6.24-5-generic i686

[2] wxThreadHelperThread::~wxThreadHelperThread() in amule [0x808311b]
[3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0xb75d3446]
[4] ?? in [0xb7f36420]
[5] wxGIFDecoder::GetFrameSize(unsigned int) const in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7894df2]
[6] wxGIFDecoder::ConvertToImage(unsigned int, wxImage*) const in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7894e5c]
[7] wxTextCtrl::wxTextCtrl() in amule [0x82339cd]
[8] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const in /usr/lib/libwx_baseu-2.8.so.0[0xb7527341]
[9] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) in /usr/lib/libwx_baseu-2.8.so.0[0xb75cedf8]
[10] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) in /usr/lib/libwx_baseu-2.8.so.0[0xb75cef58]
[11] wxEvtHandler::ProcessEvent(wxEvent&) in /usr/lib/libwx_baseu-2.8.so.0[0xb75cf0bf]
[12] wxTimerBase::Notify() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb78e03e1]
[13] ?? in /usr/lib/libwx_gtk2u_core-2.8.so.0 [0xb77bc535]
[14] ?? in /usr/lib/libglib-2.0.so.0 [0xb6f544e6]
[15] g_main_context_dispatch in /usr/lib/libglib-2.0.so.0[0xb6f53d76]
[16] ?? in /usr/lib/libglib-2.0.so.0 [0xb6f57133]
[17] g_main_loop_run in /usr/lib/libglib-2.0.so.0[0xb6f57517]
[18] gtk_main in /usr/lib/libgtk-x11-2.0.so.0[0xb6ce2d94]
[19] wxEventLoop::Run() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb77b2fec]
[20] wxAppBase::MainLoop() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7854cee]
[21] wxAppBase::OnRun() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7854341]
[22] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-2.8.so.0[0xb75632ea]
[23] wxEntry(int&, char**) in /usr/lib/libwx_baseu-2.8.so.0[0xb7563397]
[24] CryptoPP::IteratedHash<unsigned int, CryptoPP::EnumToType<CryptoPP::ByteOrder, 0>, 64u, CryptoPP::HashTransformation>::~IteratedHash() in amule [0x812b3d0]
[25] __libc_start_main in /lib/tls/i686/cmov/libc.so.6[0xb727e450]
[26] w...

Read more...

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote : Re: [Bug 189243] Re: please sync libcrypto++ 5.5.2-1 from Debian testing

On Feb 5, 2008, at 1:28 PM, Nicolas Valcárcel (nxvl) wrote:

> Ok, it builds fine, but it crashes on use, here is the output of the
> error.

Thanks for working on this.

Did you figure out that aMule was not linking to libcryptopp at all,
and it is aMule using its own internal copy of CryptoPP that crashes,
or is it linking to the new v5.5.2 of libcryptopp that crashes? Or
is it linking to the old v5.5 of libcryptopp that crashes?

more comments below:

> ----------------------------=| BACKTRACE FOLLOWS: |
> =----------------------------
> Current version is: aMule 2.1.3 using wxGTK2 v2.8.6 (Unicoded)
> Running on: Linux 2.6.24-5-generic i686
>
> [2] wxThreadHelperThread::~wxThreadHelperThread() in amule [0x808311b]
> [3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0xb75d3446]
> [4] ?? in [0xb7f36420]
> [5] wxGIFDecoder::GetFrameSize(unsigned int) const in /usr/lib/
> libwx_gtk2u_core-2.8.so.0[0xb7894df2]
> [6] wxGIFDecoder::ConvertToImage(unsigned int, wxImage*) const in /
> usr/lib/libwx_gtk2u_core-2.8.so.0[0xb7894e5c]
> [7] wxTextCtrl::wxTextCtrl() in amule [0x82339cd]
> [8] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)
> (wxEvent&), wxEvent&) const in /usr/lib/libwx_baseu-2.8.so.0
> [0xb7527341]
> [9] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) in /usr/lib/libwx_baseu-2.8.so.0
> [0xb75cedf8]
> [10] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) in /usr/
> lib/libwx_baseu-2.8.so.0[0xb75cef58]
> [11] wxEvtHandler::ProcessEvent(wxEvent&) in /usr/lib/
> libwx_baseu-2.8.so.0[0xb75cf0bf]
> [12] wxTimerBase::Notify() in /usr/lib/libwx_gtk2u_core-2.8.so.0
> [0xb78e03e1]
> [13] ?? in /usr/lib/libwx_gtk2u_core-2.8.so.0 [0xb77bc535]
> [14] ?? in /usr/lib/libglib-2.0.so.0 [0xb6f544e6]
> [15] g_main_context_dispatch in /usr/lib/libglib-2.0.so.0[0xb6f53d76]
> [16] ?? in /usr/lib/libglib-2.0.so.0 [0xb6f57133]
> [17] g_main_loop_run in /usr/lib/libglib-2.0.so.0[0xb6f57517]
> [18] gtk_main in /usr/lib/libgtk-x11-2.0.so.0[0xb6ce2d94]
> [19] wxEventLoop::Run() in /usr/lib/libwx_gtk2u_core-2.8.so.0
> [0xb77b2fec]
> [20] wxAppBase::MainLoop() in /usr/lib/libwx_gtk2u_core-2.8.so.0
> [0xb7854cee]
> [21] wxAppBase::OnRun() in /usr/lib/libwx_gtk2u_core-2.8.so.0
> [0xb7854341]
> [22] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-2.8.so.0
> [0xb75632ea]
> [23] wxEntry(int&, char**) in /usr/lib/libwx_baseu-2.8.so.0
> [0xb7563397]
> [24] CryptoPP::IteratedHash<unsigned int,
> CryptoPP::EnumToType<CryptoPP::ByteOrder, 0>, 64u,
> CryptoPP::HashTransformation>::~IteratedHash() in amule [0x812b3d0]
> [25] __libc_start_main in /lib/tls/i686/cmov/libc.so.6[0xb727e450]
> [26] wxNotebook::SetPadding(wxSize const&) in amule[0x807f451]

This is a pretty weird stack trace -- the destructor of a CryptoPP
IteratedHash object calls __libc_start_main(), which then calls
wxNotebook::SetPadding()?

Anyway, a crash in a destructor like this makes me suspect a memory
management bug in aMule. Could you please run it with valgrind?

Regards,

Zooko

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :
Changed in libcrypto++:
assignee: nvalcarcel → nobody
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

So I rather doubt that upgrading the version of libcryptopp is actually what causes nxvl's crash. nxlv: could you try the same thing linking against the current libcryptopp in Hardy pre-release?

Could you try it several times in a row and see if it keeps happening?

Thank you,

Regards,

Zooko

Revision history for this message
Daniel Holbach (dholbach) wrote :

Unsubscribing Ubuntu Sponsors for universe from this bug for now.

Revision history for this message
Daniel Holbach (dholbach) wrote :

My misunderstanding the amule crash happens without the upgrade, amule will build fine against the new version, so let's sync it.

ACKed.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

On Feb 7, 2008, at 7:31 AM, Daniel Holbach wrote:

> My misunderstanding the amule crash happens without the upgrade, amule
> will build fine against the new version, so let's sync it.

Daniel:

I'm sorry, I miscommunicated. I *guess* that the amule crash happens
without the upgrade based on the stack trace and the fact that there
are other known amule crashes with similar stack traces, but I
haven't confirmed that yet, and neither has nxvl.

I'll attempt to confirm this now.

--Z

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Okay, I did "apt-get source amule", and then I cd'ed into the amule-2.1.3 directory and ran "./configure", and it printed out, among other things:

checking whether to use embedded Crypto... yes

This means that amule is not even using the system-wide installation of Crypto++, so upgrading that version of Crypto++ can hardly be blamed for amule crashing.

Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

Zooko O'Whielacronx wrote:
> Okay, I did "apt-get source amule", and then I cd'ed into the
> amule-2.1.3 directory and ran "./configure", and it printed out, among
> other things:
>
> checking whether to use embedded Crypto... yes
>
> This means that amule is not even using the system-wide installation of
> Crypto++, so upgrading that version of Crypto++ can hardly be blamed for
> amule crashing.

That's wrong. It's not using the system crypto library in your build, but not in
the Ubuntu package, which is passing --disable-embedded-crypto to ./configure.
See debian/rules and a build log:
http://launchpadlibrarian.net/11435188/buildlog_ubuntu-hardy-i386.amule_2.1.3-4ubuntu2_FULLYBUILT.txt.gz
>

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

On Feb 7, 2008, at 8:38 AM, Emilio Pozuelo Monfort wrote:

> That's wrong. It's not using the system crypto library in your
> build, but not in
> the Ubuntu package, which is passing --disable-embedded-crypto to ./
> configure.

Okay, thanks.

By the way, how about if we stop passing --disable-embedded-crypto
and instead let amule build in the default way chosen by the amule
developers?

Anyway, I will go try that now.

Regards,

Zooko

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

But I should emphasize that there are other known crashes with amule on, e.g. Gutsy, which have the same last few stack frames:

https://bugs.launchpad.net/ubuntu/+source/amule/+bug/172323

So I really think that amule tends to crash like this sometimes, regardless of which version of Crypto++ it is using...

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Okay, I built amule with --disable-embedded-crypto, against libcryptopp v5.5.2, and it did not crash on startup for me.

Revision history for this message
Martin Pitt (pitti) wrote :

So, just to be clear: who will take care of fixing amule and other reverse dependencies once this is synced?

Changed in libcrypto++:
status: In Progress → Incomplete
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Is "taking care of fixing amule" something that I can do? I mean, someone like me who doesn't have write privileges to ubuntu repositories?

Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

I will take care of this. I'm likely to upload aMule 2.2.0 svn and it's affected by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448766 which is fixed in this new package, so I'll do both at the same time.

Changed in libcrypto++:
assignee: nobody → pochu
importance: Undecided → Wishlist
status: Incomplete → In Progress
Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

ACK. Hope I'm not too late for the freeze :)

Changed in libcrypto++:
status: In Progress → Confirmed
Revision history for this message
Emilio Pozuelo Monfort (pochu) wrote :

The only rdependency is aMule. I'll take care of it.

Revision history for this message
Martin Pitt (pitti) wrote : Synced

Package(s) synced.

Changed in libcrypto++:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.