[jitsi-dev] putting bouncycastle 1.49 into backports?


#1

When you say creating separate binary packages, do you mean creating
packages that have the version in the name such as

libbcprov1.49-java.deb (1.49)

libbcprov-java.deb (existing 1.44 in wheezy)

or did you mean just taking the 1.44 version of bcpkix.jar and making a
package of it for wheezy backports users?

I'm not sure if the backports managers will accept the 1.44 version
being uploaded if it hasn't gone through testing - and as you have 1.49
in testing, it is not possible for me to put something else through
there. I'm happy to ask them though if that is what you had in mind.

Jitsi doesn't have a versioned dependency on this so it would hopefully
be happy with the 1.44 version though and I think that would look better
than having libbcprov1.49-java packages floating about.

···

On 20/01/14 13:14, Emmanuel Bourg wrote:

Hi Daniel,

Backporting bouncycastle to wheezy is going to cause a lot of troubles
because the version 1.49 breaks a lot of reverse dependencies. See
#687694 for a glimpse of the work that was involved in the transition to
this new version.

A safe solution would be to create separate binary packages that doesn't
conflict with the stable packages.


#2

Jitsi doesn't have a versioned dependency on this so it would hopefully
be happy with the 1.44 version though and I think that would look better
than having libbcprov1.49-java packages floating about.

Then this should get versioned, we definitely fail to compile with older
versions. The only change I remember though was a relatively simple one in
the CertificateValidationService.

But DTLS-SRTP needs 1.49. This goes way deeper and is connected to bcpkix.

Ingo


#3

Le 21/01/2014 11:09, Daniel Pocock a �crit :

When you say creating separate binary packages, do you mean creating
packages that have the version in the name such as

libbcprov1.49-java.deb (1.49)

libbcprov-java.deb (existing 1.44 in wheezy)

Yes exactly. And the package would have to be slightly modified to not
conflict with libbcprov-java (by renaming the jars in /usr/share/java
and changing the version of the Maven artifacts in /usr/share/maven-repo).

Jitsi doesn't have a versioned dependency on this so it would hopefully
be happy with the 1.44 version though and I think that would look better
than having libbcprov1.49-java packages floating about.

I looked quickly into the latest jitsi downloads and it seems they use
bouncycastle 1.49. You may try to compile with bouncycastle 1.44 but
it's very unlikely to work out of the box.

Patching jitsi to work with bouncycastle 1.44 is another solution. There
is porting guide on the bouncycastle site detailing the API changes:

http://www.bouncycastle.org/wiki/display/JA1/Porting+from+earlier+BC+releases+to+1.47+and+later

Emmanuel Bourg


#4

Based on Ingo's reply, I think this is what we would have to do because
they definitely need that version in wheezy-backports if Jitsi is to be
backported

···

On 21/01/14 11:27, Emmanuel Bourg wrote:

Le 21/01/2014 11:09, Daniel Pocock a �crit :

When you say creating separate binary packages, do you mean creating
packages that have the version in the name such as

libbcprov1.49-java.deb (1.49)

libbcprov-java.deb (existing 1.44 in wheezy)

Yes exactly. And the package would have to be slightly modified to not
conflict with libbcprov-java (by renaming the jars in /usr/share/java
and changing the version of the Maven artifacts in /usr/share/maven-repo).