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

Re: Third party code inside Ugene



Hi Andreas,

Here are the flags we use for SQLite:

DEFINES+=SQLITE_ENABLE_COLUMN_METADATA
DEFINES+=SQLITE_ENABLE_RTREE
unix:DEFINES+=SQLITE_OMIT_LOAD_EXTENSION

We use no extra flags for zlib.

These 2 libraries (+Qt) is everything needed to build UGENE. When we distribute source code for different platforms (MacOS, Windows, Linux) we do not ask users to install something extra. If a user has Qt5 he will able to build UGENE with no extra packages at all. This is very convenient for us.

We release updates for UGENE every 2-3 months. I know that Debian & Ubuntu LTS  do not accept updates from the projects like UGENE after feature freeze. It makes more beneficial for us to use PPA or ask users to download the latest version from the website directly.

+ You are absolutely right that we need to update our own local SQLite library. We have never experienced any problems with the old version, but it will be correct to upgrade. We will do it with the next release.

Thank you.

Yuliya.



On 01/29/2019 02:45 PM, Andreas Tille wrote:
Hi Yuliya,

On Tue, Jan 29, 2019 at 07:43:14AM +0700, Yuliya Algaer wrote:
Thank you for your letter.
Thank you for your quick answer.
We use custom flags to build sqlite. It is very important for us to keep
these flags.
We are really keen on running each component as best as possible.  So it
would be very interesting, which actual flags you are using and why these
are important for UGENE.  It could be possible that this enhancement has
some positive effect also on other programs.  The code copy of sqlite3
you are shipping says:


#define SQLITE_VERSION        "3.7.11"
#define SQLITE_VERSION_NUMBER 3007011
#define SQLITE_SOURCE_ID      "2012-03-20 11:35:50 00bb9c9ce4f465e6ac321ced2a9d0062dc364669"

while Debian has

#define SQLITE_VERSION        "3.16.2"
#define SQLITE_VERSION_NUMBER 3016002
#define SQLITE_SOURCE_ID      "2017-01-06 16:32:41 a65a62893ca8319e89e48b8a38cf8a59c69a8209"


Chances are good that in five years development some progress has
happended with this library.  Moreover when inspecting the Debian
changelog I can see several security fixes with CVEs.  So if it is
just about custom flags of building the library we might be able
to discuss this with the maintainer of sqlite3.


I'm also wondering about zlib.  Are you also using custom flags for this
widely used library?  Ugene contains version 1.2.3, July 18th, 2005
which is not acceptable for our security team (the current zlib is
1.2.11 and contains fixes for several security relevant bugs with CVEs).

If it is against of Debian rules I think it is OK to remove UGENE from the
official Debian distribution.
UGENE is not part of the *official* Debian distribution anyway it is
only in an area called "non-free" - not because the code itself is
non-free but because of code copies (also of other software specifically
code liky phylip where you are shipping the code version with a non-free
license).  I'd volunteer to work on this but only if I see a chance to
use code that does not contain well known security issues.
Thank you!

Kind regards,
Thanks to you and thanks for your cooperation

       Andreas.
Yuliya Algaer

The UGENE Team

On 01/28/2019 07:01 PM, Andreas Tille wrote:
Hi,

I'd like to update the packaging for Ugene[1].  (BTW Ivan, you are
listed as Uploader for this package but you probably do not have access
to the new development platform salsa.debian.org - if you intend to
commit something please register there and apply for the Debian Med team
or send me an e-mail with your user name.)

Ugene comes with several third party software which we did not yet
replaced by the Debian packaged equivalents as the Debian policy
requests.  However in previous version we at least replaced sqlite3
and zlib by the Debian packaged versions.  In the latest upstream
version which I commited to Git[1] there are lots of occurences of
these libraries which are renamed from the standard name sqlite
to ugenedb and z to zlib, resp.  Before I now start mass-patching
the according makefiles I'd like to know the motivation to

    a) ship these very basic well established libs at all
    b) renaming the local copies to something else.

I do not want to do useless work just to find out the result will
not work as expected.

Kind regards

         Andreas.


[1] https://salsa.debian.org/med-team/ugene




Reply to: