[jitsi-dev] Re: [jitsi~svn:10306] Fixes android and debian source package compatibility.


#1

+ // Uses String UTF-8 to keep compatible with android version and
+ // older versions of the http client libs, as the one used
+ // in debian (4.1.x)
+ String s = URLEncodedUtils.format(parameters, "UTF-8");
+ StringEntity entity = new StringEntity(s, "UTF-8");

It's some time since I've dealt with Android, do they actually include HttpClient as part of the OS? If so, how do we deal with the OSGi-Exports in our httputil-bundle that declare providing org.apache.*?
Btw: the Charset overload was introduced in 4.2

And you mention Debian also using an older version? The reason for the update was an SSL security fix in the library, so using anything older than 4.2.3 is a really bad idea. In any distro.

Index: trunk/resources/install/build.xml

--- trunk/resources/install/build.xml (revision 10305)
+++ trunk/resources/install/build.xml (revision 10306)
@@ -2874,10 +2874,10 @@
         <!-- libhttpcore-java libhttpmime-java libhttpclient-java -->
         <symlink resource="/usr/share/java/httpclient.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpclient-
4.1.2.jar"/>
+ link="${debian.src.dir}/lib/installer-exclude/httpclient-osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpcore.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpcore-
4.1.2.jar"/>
+ link="${debian.src.dir}/lib/installer-exclude/httpcore-osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpmime.jar"
              overwrite="true"
              link="${debian.src.dir}/lib/installer-exclude/httpmime-
4.1.2.jar"/>

Sorry, missed that. But shouldn't the httpmime symlink also be dropped here?
And in <target name="deb-bundle-httputil">?
What does that do anyway?

Ingo


#2

Hi,

+ // Uses String UTF-8 to keep compatible with android version and
+ // older versions of the http client libs, as the one used
+ // in debian (4.1.x)
+ String s = URLEncodedUtils.format(parameters, "UTF-8");
+ StringEntity entity = new StringEntity(s, "UTF-8");

It's some time since I've dealt with Android, do they actually include HttpClient as part of the OS? If so, how do we deal with the OSGi-Exports in our httputil-bundle that declare providing org.apache.*?
Btw: the Charset overload was introduced in 4.2

in android it is still org.apache:
http://developer.android.com/reference/org/apache/http/package-summary.html

And you mention Debian also using an older version? The reason for the update was an SSL security fix in the library, so using anything older than 4.2.3 is a really bad idea. In any distro.

Ok, we may make a package update request in debian. But currently
(maybe this week) we wait for first submission in debian repository
and we should keep our source package fixed so future
maintainers/uploaders can do their job :slight_smile:

Index: trunk/resources/install/build.xml

--- trunk/resources/install/build.xml (revision 10305)
+++ trunk/resources/install/build.xml (revision 10306)
@@ -2874,10 +2874,10 @@
         <!-- libhttpcore-java libhttpmime-java libhttpclient-java -->
         <symlink resource="/usr/share/java/httpclient.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpclient-
4.1.2.jar"/>
+ link="${debian.src.dir}/lib/installer-exclude/httpclient-osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpcore.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpcore-
4.1.2.jar"/>
+ link="${debian.src.dir}/lib/installer-exclude/httpcore-osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpmime.jar"
              overwrite="true"
              link="${debian.src.dir}/lib/installer-exclude/httpmime-
4.1.2.jar"/>

Sorry, missed that. But shouldn't the httpmime symlink also be dropped here?
And in <target name="deb-bundle-httputil">?
What does that do anyway?

If it is dropped the sources cannot be build against the old version
of the library.
Currently:
/usr/share/java/httpcore.jar
/usr/share/java/httpclient.jar
/usr/share/java/httpmime.jar

are versions: 4.1.4, 4.1.1 and 4.1.1.

Hope this explains the situation.

Regards
damencho

···

On Tue, Jan 22, 2013 at 12:29 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:


#3

And you mention Debian also using an older version? The reason for the
update was an SSL security fix in the library, so using anything older

than

4.2.3 is a really bad idea. In any distro.

Ok, we may make a package update request in debian. But currently
(maybe this week) we wait for first submission in debian repository
and we should keep our source package fixed so future
maintainers/uploaders can do their job :slight_smile:

Hmm, okay. I have some doubt that they'll update it: hc.apache.org still
lists 4.1.x as "stable and production ready" despite the stopped development
on that branch. Therefore we'd probably need to convince the Apache
maintainers to consider 4.2.x as stable. Oh my... :frowning:

Index: trunk/resources/install/build.xml

--- trunk/resources/install/build.xml (revision 10305)
+++ trunk/resources/install/build.xml (revision 10306)
@@ -2874,10 +2874,10 @@
         <!-- libhttpcore-java libhttpmime-java libhttpclient-java -->
         <symlink resource="/usr/share/java/httpclient.jar"
              overwrite="true"
-
link="${debian.src.dir}/lib/installer-exclude/httpclient- 4.1.2.jar"/>
+
link="${debian.src.dir}/lib/installer-exclude/httpclient- osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpcore.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpcore-
4.1.2.jar"/>
+

link="${debian.src.dir}/lib/installer-exclude/httpcore-osgi-

4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpmime.jar"
              overwrite="true"
              link="${debian.src.dir}/lib/installer-exclude/httpmime-
4.1.2.jar"/>

Sorry, missed that. But shouldn't the httpmime symlink also be dropped
here? And in <target name="deb-bundle-httputil">? What does that do
anyway?

If it is dropped the sources cannot be build against the old version
of the library.
Currently:
/usr/share/java/httpcore.jar
/usr/share/java/httpclient.jar
/usr/share/java/httpmime.jar

are versions: 4.1.4, 4.1.1 and 4.1.1.

Where's the 4.1.2 httpmime package coming from? That was the version in our
installer-exclude but now that I've put the -osgi version there, I imagine
the symlink points into the void?

Hope this explains the situation.

More or less. But I took a look at the Ubuntu source package. I don't get
what they're doing: they patch the maven build to remove the OSGi target,
then do a second patch to manually inject the OSGi-exports into the
manifest. WTF!?

···

Regards
damencho


#4

Hi again,

And you mention Debian also using an older version? The reason for the
update was an SSL security fix in the library, so using anything older

than

4.2.3 is a really bad idea. In any distro.

Ok, we may make a package update request in debian. But currently
(maybe this week) we wait for first submission in debian repository
and we should keep our source package fixed so future
maintainers/uploaders can do their job :slight_smile:

Hmm, okay. I have some doubt that they'll update it: hc.apache.org still
lists 4.1.x as "stable and production ready" despite the stopped development
on that branch. Therefore we'd probably need to convince the Apache
maintainers to consider 4.2.x as stable. Oh my... :frowning:

Index: trunk/resources/install/build.xml

--- trunk/resources/install/build.xml (revision 10305)
+++ trunk/resources/install/build.xml (revision 10306)
@@ -2874,10 +2874,10 @@
         <!-- libhttpcore-java libhttpmime-java libhttpclient-java -->
         <symlink resource="/usr/share/java/httpclient.jar"
              overwrite="true"
-
link="${debian.src.dir}/lib/installer-exclude/httpclient- 4.1.2.jar"/>
+
link="${debian.src.dir}/lib/installer-exclude/httpclient- osgi-
4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpcore.jar"
              overwrite="true"
- link="${debian.src.dir}/lib/installer-exclude/httpcore-
4.1.2.jar"/>
+

link="${debian.src.dir}/lib/installer-exclude/httpcore-osgi-

4.2.3.jar"/>
         <symlink resource="/usr/share/java/httpmime.jar"
              overwrite="true"
              link="${debian.src.dir}/lib/installer-exclude/httpmime-
4.1.2.jar"/>

Sorry, missed that. But shouldn't the httpmime symlink also be dropped
here? And in <target name="deb-bundle-httputil">? What does that do
anyway?

If it is dropped the sources cannot be build against the old version
of the library.
Currently:
/usr/share/java/httpcore.jar
/usr/share/java/httpclient.jar
/usr/share/java/httpmime.jar

are versions: 4.1.4, 4.1.1 and 4.1.1.

Where's the 4.1.2 httpmime package coming from? That was the version in our
installer-exclude but now that I've put the -osgi version there, I imagine
the symlink points into the void?

The link is to /usr/share/java/httpmime.jar which is the version
currently available and installed in debian
http://packages.debian.org/sid/libhttpmime-java
It is put in the installer-exclude so it can compile against the old
one, and later when preparing the httputils bundle is used again as
symlink along with the core and client libs, and the new libraries are
not used at all.
So later what is distributed in the deb file, it is a symlink. But
this goes only for the version that will be in debian. For currently
build deb packages it is still not used. Maybe we can switch to that
after the release, but the problem there is that not all packages are
available in ubuntu like jdic, but are available in debian.

Hope this explains the situation.

More or less. But I took a look at the Ubuntu source package. I don't get
what they're doing: they patch the maven build to remove the OSGi target,
then do a second patch to manually inject the OSGi-exports into the
manifest. WTF!?

Regards
damencho

Cheers
damencho

···

On Tue, Jan 22, 2013 at 1:50 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:


#5

+ // Uses String UTF-8 to keep compatible with android version

and

+ // older versions of the http client libs, as the one used
+ // in debian (4.1.x)
+ String s = URLEncodedUtils.format(parameters, "UTF-8");
+ StringEntity entity = new StringEntity(s, "UTF-8");

It's some time since I've dealt with Android, do they actually include

HttpClient as part of the OS? If so, how do we deal with the OSGi-Exports

in

our httputil-bundle that declare providing org.apache.*?

Btw: the Charset overload was introduced in 4.2

in android it is still org.apache:
http://developer.android.com/reference/org/apache/http/package-summary.ht
ml

Btw: Android uses some obscure 4.0.beta snapshot of httpcomponents [1] and
now discourages the use of it [2], [3]. We should ship our own version,
perhaps using [4] for the conversion.

Ingo

[1]
http://httpcomponents.10934.n7.nabble.com/HttpClient-in-Android-td9384.html
[2] http://android-developers.blogspot.in/2011/09/androids-http-clients.html
[3]
http://developer.android.com/reference/org/apache/http/impl/client/DefaultHt
tpClient.html
[4] http://code.google.com/p/httpclientandroidlib/

···

On Tue, Jan 22, 2013 at 12:29 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:


#6

The funny thing is that we (and all Debian contributors in general) are
discouraged from shipping our own lib versions and encouraged to use
those available in the repositories. The reasons that I've been given
for this is how this _improves_security_ because the Debian packages are
under the scrutiny of the Debian community who constantly patch them.
Packages that we commit ourselves, we are told, would hence go
unprotected and potentially leave security holes open.

Well ... in this case, that very policy seems to be forcing us to use a
lib with known problems rather than shipping a fixed one ourselves.

Sweet! :slight_smile:

···

On 22.01.13, 13:18, Damian Minkov wrote:

Where's the 4.1.2 httpmime package coming from? That was the version in our
installer-exclude but now that I've put the -osgi version there, I imagine
the symlink points into the void?

The link is to /usr/share/java/httpmime.jar which is the version
currently available and installed in debian
http://packages.debian.org/sid/libhttpmime-java
It is put in the installer-exclude so it can compile against the old
one, and later when preparing the httputils bundle is used again as
symlink along with the core and client libs, and the new libraries are
not used at all.
So later what is distributed in the deb file, it is a symlink. But
this goes only for the version that will be in debian. For currently
build deb packages it is still not used. Maybe we can switch to that
after the release, but the problem there is that not all packages are
available in ubuntu like jdic, but are available in debian.

--
https://jitsi.org


#7

Where's the 4.1.2 httpmime package coming from? That was the version
in our installer-exclude but now that I've put the -osgi version
there, I imagine the symlink points into the void?

The link is to /usr/share/java/httpmime.jar which is the version
currently available and installed in debian
http://packages.debian.org/sid/libhttpmime-java
It is put in the installer-exclude so it can compile against the old
one, and later when preparing the httputils bundle is used again as
symlink along with the core and client libs, and the new libraries are
not used at all.
So later what is distributed in the deb file, it is a symlink. But
this goes only for the version that will be in debian. For currently
build deb packages it is still not used. Maybe we can switch to that
after the release, but the problem there is that not all packages are
available in ubuntu like jdic, but are available in debian.

The funny thing is that we (and all Debian contributors in general) are
discouraged from shipping our own lib versions and encouraged to use
those available in the repositories. The reasons that I've been given
for this is how this _improves_security_ because the Debian packages are
under the scrutiny of the Debian community who constantly patch them.
Packages that we commit ourselves, we are told, would hence go
unprotected and potentially leave security holes open.

Well ... in this case, that very policy seems to be forcing us to use a
lib with known problems rather than shipping a fixed one ourselves.

Well, actually I can follow their argument: Assume Jitsi would be stable and
development almost stopped. Assume further we use the today a lib considered
secure (in our package). Everyone is happy. Now a bug is discovered in said
lib, but we don't care about Jitsi anymore. Ups.

Now that chain of events obviously isn't an excuse to keep old packages in
the repository.

Sweet! :slight_smile:

As maple sirup :slight_smile:

Ingo

···

On 22.01.13, 13:18, Damian Minkov wrote: