sflphone is marked for autoremoval from testing

[Emmanuel Lepage]

Hello Jonas,

> If, since you are onvolving in the upstream development, you could find
> time to port to GnuTLS (ot some other compatible librry - there are
> several), then that would indeed be a good optin - obviously better than
> disabling the feature which would otherwise be the likely workaround for
> Debian (and for any other non-final-user-compiling-on-their-own-system)
> due to the licensing constraints.

Unfortunately, this is unlikely. First of all, I am currently in vacation,
so I wont meet the deadline. Then, I don't want to rush security related
code and risk inserting regressions. While porting from TLS API to TLS
API is usually strait-forward looking, there is a lot of gotcha. Many of
those are even invisible to "quick wireshark". The packets look encrypted,
but aren't (like TLS wrapper clear text or mis-sorted cipher list).

But the main reason here is that we dropped that dependency. The time
involved into "backporting" a fix to a 18 month old release is better
spent elsewhere (from an "upstream" point of view). As much as I would
hate to see this feature disabled, investing 50+ hours in a library
that we dropped, used for a single feature used by ~5% of our users on
a barely maintained 18 month old release make very little sense.

That being said, please note that we did just that for pjproject itself:
https://projects.savoirfairelinux.com/projects/ring-daemon/repository/revisions/master/entry/contrib/src/pjproject/gnutls.patch

This patch make pjproject use GnuTLS instead of OpenSSL for pjproject.

Best regards,
Emmanuel Lepage

----- Original Message -----
From: "Jonas Smedegaard" <dr at jones.dk>
To: "Emmanuel Lepage" <emmanuel.lepage at savoirfairelinux.com>
Cc: sflphone at packages.debian.org
Sent: Sunday, November 8, 2015 4:59:34 AM
Subject: Re: sflphone is marked for autoremoval from testing

Hi Emmanuel,

Quoting Emmanuel Lepage (2015-11-07 22:42:43)
> Removing it would harm a small but existing fraction of sflphone 
> userbase. I would prefer to see an alternate solution for this, but 
> relicensing is hard. Maybe porting to glutls would be an option?

If, since you are onvolving in the upstream development, you could find 
time to port to GnuTLS (ot some other compatible librry - there are 
several), then that would indeed be a good optin - obviously better than 
disabling the feature which would otherwise be the likely workaround for 
Debian (and for any other non-final-user-compiling-on-their-own-system) 
due to the licensing constraints.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private