IMAP/POP3+SSL/TLS are disabled

[Ilmari Vacklin]

The SSL/TLS options for IMAP and POP3 are greyed out in preferences. Only the “standard” method is available.

According to Debian (http://ftp-master.debian.org/REJECT-FAQ.html), the license of mail-notification is incompatible with the license of OpenSSL and hence Debian ships mail-notification packages with SSL support disabled.

Packages for Ubuntu with mail-notification compiled with SSL support are available from this PPA:
https://launchpad.net/~mail-notification-ssl/+archive/ppa

[wouter bolsterlee (wbolster)]

severity 286672 important
thanks

Not having SSL support renders the packages useless for a lot of people
(including me). The mail-notification homepage provides a .deb with SSL
support (I'm using that one in the mean time). It's really easy to fix (one
compile flag), so please fix it.

  bye, Wouter

--
:wq mail <email address hidden>

now she's gone love burns inside me -- black rebel motorcycle club

[Pascal Giard (pascalgiard-debian)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tags 286672 wontfix help

thx!

| SSL was disabled in this application. Why? Is it just a
| configuration problem or the program's bug? Without SSL,
| mail-notification became useless to me.

it's not a bug nor a configuration problem.
i had to disable it for mail-notification to be accepted in Debian.

here's what i previously got from an ftp-master:

This software is licensed under the GPL but appears to link with
OpenSSL. This doesn't work due to license conflicts (see
debian-legal, debian-devel-announce archives for more details).
Please convince upstream to add an exception to the GPL which allows
linking with OpenSSL or point out if I am missing something.

- -- end of extract

Jean-Yves disagrees with the interpretation done by the debian legal team:

As long as dynamic linking is involved, I do not agree with that
interpretation.

Mail Notification does not contain OpenSSL code, and therefore the
clauses #3 and #6 of the OpenSSL license do not apply to it.

As of GPL clause #6, the "Program" is Mail Notification, not Mail
Notification + the libraries it may dynamically link against.

If this is a problem for the Debian project, I suggest you ship a
package compiled using ./configure --disable-ssl. I'm not changing my
license.

Regards,
Jean-Yves Lefort

- -- end of extract

See the following link for more information about the OpenSSL+GPL
license issue:
http://www.gnome.org/~markmc/openssl-and-the-gpl.html
<http://www.gnome.org/%7Emarkmc/openssl-and-the-gpl.html>

I'm tagging this bug wontfix and help as i can't do anything about it.

- -Pascal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBynT51Lfd97FsypURAsJaAJ40WODYrSlECygatK/kyRh0Efz3VwCgpU0K
CLMWodlTW2aVAWaTJMjq0Fc=
=j7HY
-----END PGP SIGNATURE-----

[Chun-Chung Chen (cjj)]

Since the author explicitly expressed that the program can be
distributed with dynamically linked OpenSSL. Why not just use the email
from the author as a permission statement and include it in the
documentation?

--
Chun-Chung Chen

[Ilmari Vacklin (wolverian)]

The SSL/TLS options for IMAP are greyed out in preferences. Only the "standard" method is available. ldd says that mail-notification does use gnutls (is it just for SASL then?). Upstream site mentions openssl instead of gnutls.

[Ilmari Vacklin (wolverian)]

Sorry, forgot to mention that this is on current Dapper.

[David Planella (dpm)]

AFAIK, mail-notification uses OpenSSL, which cannot and will not be used in Debian due to licensing issues. That's why the SSL/TLS options are not available in the universe package (the --disable-ssl option is also explicitly specified in the debian/rules file).

In short, I don't think this bug will be fixed unless OpenSSL changes its license or mail-notification starts using gnutls instead. Shame though, since I'd also like to be able to use SSL.

[Ilmari Vacklin (wolverian)]

Thanks, I'll take this upstream (mail-notification) then.

[Charles Griffin (cngriffin)]

If there is any way to provide SSL support for this package, I would be very
grateful. I understand there may be some licensing issues but I think
upstream should reconsider. Not having SSL support renders this application
useless for me.

Thank you.

[Sam Morris (yrro)]

Charles, you have to take it up with upstream. Debian simply does not
have permission to distribute binaries of mail-notification compiled
with OpenSSL support.

Another alternative would be to port mail-notification to use the Gnu
TLS library... :)

--
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078

[Pascal Giard (pascalgiard-debian)]

As a follow up on this, i'm currently looking into patching
mail-notification to use GnuTLS instead of OpenSSL.
Now, please don't read this as a promise that SSL/TLS support will be
back in mail-notification soon.

If you're willing to help on this front, you're very much welcome.
You can help by:
- writing a patch;
- giving tips on doing the port;
- providing anything else relevant to this task;
- trying to convince the upstream author that it would be a good idea[?].

It might also be of interest to mention that Ubuntu users would also
like to see SSL/TLS support. See bug report:
https://launchpad.net/distros/ubuntu/+source/mail-notification/+bug/44335

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)

[Nicolas da Luz Duque (hot-boy)]

I don't know if I'm right to post this here. If it's wrong, I apologise in advance.

For those who don't care so much about what debian thinks, I have made a "non-free" version of the mail-notification package with ssl enabled (for dapper). I have renamed it to mail-notification-ssl and it conflicts of course with mail-notification.

I have tested it on my computer and it works well. I really haven't changed much in the original package so I doubt it could cause any kind of trouble.

I must nevertheless warn you that this is the first time I compile a package ever. I have followed the ubuntu guide to creating a package.

I don't really want to host a deb repository for just one package (for now) so I'll just leave the package on my server, accessible via http: http://daluzduque.be/stuff/dapper_packages/mail-notification-ssl_2.0.dfsg.1-2ubuntu2_i386.deb

I did this package because there was no clean way to enable ssl in mail-notification. You had to compile it yourself. Now you can do it "the clean way" (well ok you can't have apt-get retrieve it for you, but it's a lot easier for beginners now with this package and gdebi)

[Gustaf (opera)]

mail-notifications is completely useless to any reasonable person since it doesn't handle ssl. It has been like this for _many years_ in debian, and my question (unanswered) has always been: Why the heck compile against openssl and not gnutls? gnutls has an openssl wrapper, so it should be a rather simple thing to do. Why even have this package in ubuntu when it is completely useless? Please don't tell me you Want people to not use ssl?
This is unfortunately pathetic. Years of unusable.
Thanks for the package Nicolas, but I'm on edgy, and I don't like packages which synaptic/apt wants to remove for every update I do.

It's just unbelievable. Completely unbelievable. I don't even understand why OpenSSL is in debian/ubuntu in the first place. Build the programs against GnuTLS, so we can get rid of all these non-issues which is only due to maintainer lazyness.
You have to excuse me, all of you are doing a good job, but this IS lazyness. And it has been like this for YEARS. Is nobody using mail anymore?

Maybe when everyone started to blog, cause they thought people cared what they think, they forgot about mail, I dunno.

[Ilmari Vacklin (wolverian)]

This seems to be fixed on Feisty. Please revert if I am hallucinating.

[Mikael Nilsson (mini)]

The options are in the GUI, but don't seem to work. I still see

DEB_CONFIGURE_EXTRA_FLAGS += --disable-ssl --with-gconf-schema-file-dir=/usr/share/gconf/schemas

in debian/rules. Thus, reverting.

[Peter Clifton (pcjc2)]

Ubuntu != debian,

I think Ubuntu ought to re-ship the mail-notification package with --enable-ssl

In the mean time, fetching the sources yourself and re-compiling with ssl enabled is pretty easy. There is, however, an upstream bug which means the default trusted certificates aren't picked up on the system, so you have to verify the certificate fingerprint manually, and accept / decline it.

[Nicolas da Luz Duque (hot-boy)]

I totally agree with Peter.

[Peter Clifton (pcjc2)]

As an extra note, you can fix the bug of not having any trusted SSL CAs, with the following line:

  SSL_CTX_set_default_verify_paths( ctx );

added before:
  G_UNLOCK(init);

in the function:

SSL_CTX *
mn_ssl_init (GError **err)

in the file src/mn-ssl.c

This modification adds the default system trusted CAs to the list of verification sources OpenSSL will use to check certificates in this app.

[Ilmari Vacklin (wolverian)]

On Wed, Apr 11, 2007 at 06:19:19PM -0000, Peter Clifton wrote:
> I think Ubuntu ought to re-ship the mail-notification package with
> --enable-ssl

Why? The OpenSSL license and the mail-notification license (GPL) are
incompatible.

--
Ilmari Vacklin
<email address hidden>

[Peter Clifton (pcjc2)]

> Why? The OpenSSL license and the mail-notification license (GPL) are
> incompatible.

This may be Debian's take on the issue, but the author of mail-notification doesn't believe it to be the case. If he wanted, he could add an exception clause to his GPL license, but he doesn't believe there to be a problem in the first place.
Surely this common sense being to ship with --enable-ssl?

If debian believe it is the GPL program which must be graced by its copyright holder with an exception, surely the author's opinion counts here? (Or are we more thinking of the purity of the GPL, and the freedoms it gives software users?)

http://www.openssl.org/support/faq.html#LEGAL2 :

"On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution)."

It seems that debian's stance is fairly hard-line. My real question, is should Ubuntu automatically follow the same stance?

[Ilmari Vacklin (wolverian)]

On Thu, Apr 12, 2007 at 01:34:20PM -0000, Peter Clifton wrote:
> "On many systems including the major Linux and BSD distributions, yes
> (the GPL does not place restrictions on using libraries that are part of
> the normal operating system distribution)."

The difference between Debian and Ubuntu here is that Ubuntu does not
ship mail-notification in main (i.e. along with the OpenSSL libraries).
This might indeed allow Ubuntu to compile mail-notification with OpenSSL
enabled. I am not sure this is the right interpretation, however. Seems
like we need a legal opinion on this.

--
Ilmari Vacklin
<email address hidden>

[Mikael Nilsson (mini)]

tor 2007-04-12 klockan 13:34 +0000 skrev Peter Clifton:

>
> It seems that debian's stance is fairly hard-line. My real question, is
> should Ubuntu automatically follow the same stance?

Well, AFAIK the stance is more of the form "we can't afford any legal
trouble, so we'd better take the safe route". It's not really
fundamentalist, more like pragmatic from an organization without legal
resources.

One option that was discussed in the debian bug was to simply recompile
it with the GNU TLS openssl compatibility library:

http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-with-the-OpenSSL-library

Is this a solution?

/Mikael

[Mikael Nilsson (mini)]

tor 2007-04-12 klockan 14:26 +0000 skrev Mikael Nilsson:
> One option that was discussed in the debian bug was to simply recompile
> it with the GNU TLS openssl compatibility library:
>
> http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-
> with-the-OpenSSL-library
>
> Is this a solution?

Tried it, and it does not work, due to missing definitions of

SSL_get_version
SSL_get_verify_result
X509_V_OK
X509_digest
EVP_md5
X509_verify_cert_error_string

in gnutls/openssl.h

Too bad.

Pascal: have you had more luck with a full GNU TLS port?

[Wit Wilinski (wit-wilinski)]

Still an issue in Gutsy (testing) - mail-notification is linked against libgnutls, settings are available in GUI, but don't work... (at least not for GMail...)

[Christopher Denter (dennda)]

Yes. This is rather annoying.
Nobody really uses unencrypted connections to his mailserver (me neither).
This programm could be really cool, but the lack of support for encrypted connections makes it absolutely useless (to me).

regards

[Pascal Giard (pascalgiard-debian)]

On 4/12/07, Mikael Nilsson <email address hidden> wrote:
> tor 2007-04-12 klockan 14:26 +0000 skrev Mikael Nilsson:
> > One option that was discussed in the debian bug was to simply recompile
> > it with the GNU TLS openssl compatibility library:
> >
> > http://www.gnu.org/software/gnutls/manual/gnutls.html#Compatibility-
> > with-the-OpenSSL-library
> >
> > Is this a solution?
>
> Tried it, and it does not work, due to missing definitions of
>
> SSL_get_version
> SSL_get_verify_result
> X509_V_OK
> X509_digest
> EVP_md5
> X509_verify_cert_error_string
>
> in gnutls/openssl.h
>
> Too bad.
>
> Pascal: have you had more luck with a full GNU TLS port?

Mikael nicely summed up the problems and respective positions.

Unfortunatly, i don't have the time to add GNU TLS support to
mail-notification but this seem like the best way to go.

For those who, _like me_, absolutly want SSL support... well, you can
rebuild the mail-notification package after removing --disable-ssl in
debian/rules (changing the version number in changelog is also a good
practice so you don't get confused with official packages).

In the Debian Bug Tracker, i've tagged that bug "help" and this still applies.
I welcome with open hands anyone who could provide a patch
implementing SSL support using GNU TLS.

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[Christian Roessner (christian-roessner-net)]

Hi,

a simple workaround for the missing SSL/TLS support is using stunnel4 in client mode.

http://www.roessner-net.com/mail-notification-workaround.txt

[PatRiehecky (jcpunk)]

Here is a good set of instructions for making your own package to work around this: http://www.howtoforge.com/repackage_deb_packages_debian_ubuntu

[LEVIS Cyril (atlas95)]

Someone has compil it for i386?
Thanks

[Tero Karvinen (karvinen+launchpad)]

Solution: Put mail-notifications-ssl to multiverse. Use packages linked in this bug.

Reasoning:
- Gustaf: "mail-notifications is completely useless to any reasonable person since it doesn't handle ssl."
- README.Debian: "It doesn't look like the [SSL] issue is going to be solved soon."
- PatRiehecky's link: "Remove the '--disable-ssl' option from the [debian/rules] line with definition of the variable DEB_CONFIGURE_EXTRA_FLAGS"
- Nicolas da Luz Duque: "I have made a 'non-free' version of the mail-notification package with ssl enabled"
http://daluzduque.be/stuff/dapper_packages/mail-notification-ssl_2.0.dfsg.1-2ubuntu2_i386.deb

So why not put mail-notifications-ssl to multiverse?

[Pascal Giard (pascalgiard-debian)]

I'd gladly do so but at this point i'm overflowed with real life.
I'd very much like help, could you help?

Eventually a co-maintainer for m-n would be very nice...

-Pascal

On Mon, Apr 28, 2008 at 8:41 AM, Tero Karvinen
<email address hidden> wrote:
> Solution: Put mail-notifications-ssl to multiverse. Use packages linked
> in this bug.
>
> Reasoning:
> - Gustaf: "mail-notifications is completely useless to any reasonable person since it doesn't handle ssl."
> - README.Debian: "It doesn't look like the [SSL] issue is going to be solved soon."
> - PatRiehecky's link: "Remove the '--disable-ssl' option from the [debian/rules] line with definition of the variable DEB_CONFIGURE_EXTRA_FLAGS"
> - Nicolas da Luz Duque: "I have made a 'non-free' version of the mail-notification package with ssl enabled"
> http://daluzduque.be/stuff/dapper_packages/mail-notification-ssl_2.0.dfsg.1-2ubuntu2_i386.deb
>
> So why not put mail-notifications-ssl to multiverse?
>
> --
> IMAP/POP3+SSL/TLS are disabled
> https://bugs.launchpad.net/bugs/44335
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[cecil_t (greg-hasslers)]

The deb package referenced is almost 2 years old, is there a newer deb package with SSL support? Something for Hardy?

[Andrew (andrew-rw-robinson)]

Just follow the suggested instructions to build your own modified deb with SSL enabled at:
http://www.howtoforge.com/repackage_deb_packages_debian_ubuntu

Hopefully a mail-notification-ssl will make it into ubuntu someday

[AZ (m-dev)]

I took http://savannah.nongnu.org/download/mailnotify/mail-notification-5.4.tar.bz2 (most recent) and add gnutls (2.0.4 as installed in hardy) support.
It works for me but I'm pretty sure that there are still some bugs around I somehow missed, so better somebody else looks over it before applying it.

I basically added a new option "gnutls" parallel to "ssl" (=> openssl), where gnutls suppresses ssl in auto configuration.
Next, I replaced all #if WITH_SSL (and similar) definitions with #if WITH_SSL || WITH_GNUTLS. (These changes also applied to the code generated from gob, as I don't have gob2 2.1.16) .
Further, jbsrc/lib/src/extra/jb-gnutls.{c,h} and src/mn-gnutls.{c,h} got added, the latter contains some useful functions for cert verification and the default cert path.
In src/mn-client-session.{c,h} I seperated WITH_SSL and WITH_GNUTLS and rewrote the code for gnutls.

There are three major points about it:
 * gnutls 2.0.4 does not have all functions given in online api of gnutls nor do the examples work
   (gnutls-doc-2.0.4 is somehow incomplete regarding api listing).
 * cert chain verification needs to be cared for by mail-notification, e.g. reading ca certs from /etc/ssl/certs etc.
    I decided not to use gnutls_certificate_verify_peers2 due to
     http://blog.josefsson.org/2008/02/27/real-world-performance-tuning-with-callgrind/ ,
    which was really slow on my machine. Perhaps this could be changed some day.
 * check_hostname is not used as I didn't figure out how to extract the common_name and altName(s)
    correctly but use gnutls_x509_crt_check_hostname. I don't know if gnutls_x509_crt_check_hostname supports wildcards.

[AZ (m-dev)]

changes to build/src , which should automatically generate if gob2 2.1.16 were installed.

[Tero Karvinen (karvinen+launchpad)]

Thanks AZ, this GnuTLS compilation is a big step towards the real solution to this SSL/TLS problem.

[Ilmari Vacklin (wolverian)]

AZ kirjoitti:
> I took
> http://savannah.nongnu.org/download/mailnotify/mail-notification-5.4.tar.bz2
> (most recent) and add gnutls (2.0.4 as installed in hardy) support.
> It works for me but I'm pretty sure that there are still some bugs
> around I somehow missed, so better somebody else looks over it before
> applying it.

This is great, thanks! Have you submitted the patch upstream yet?

--
Ilmari Vacklin

[Jean-Yves Lefort (jylefort)]

Distributors: please do not ship a MN package with this patch applied. Its quality is rather questionable, and I do not want my reputation to be damaged by it.

[Peter Clifton (pcjc2)]

On Sun, 2008-05-25 at 00:30 +0000, Jean-Yves Lefort wrote:
> Distributors: please do not ship a MN package with this patch applied.
> Its quality is rather questionable, and I do not want my reputation to
> be damaged by it.

Is there going to be upstream support for GnuTLS?

If not, perhaps a fork would be appropriate to avoid this conflict.

Peter Clifton

[AZ (m-dev)]

I justed looked over the patch and found I forgot to remove some debugging stuff.

[AZ (m-dev)]

Is there a way to remove a patch from a bug report or to replace it silently?
Here comes rev3 patch containing a minor fix.

[AZ (m-dev)]

@Tero: thanks :)

@Ilmari: Sry, but I don't know yet how to handle gconf registering and so on in deb / ubuntu packages so I can hardly build a deb package in this case.

@Jean-Yves Lefort: Thanks for pointing out that this patch is not yet perfect ;). But apart from the mistakes I corrected,
                              most of the gnutls related code is rather almost copy&paste from gnutls documentation
                              so I don't expect too much errors . Perhaps you could point out qualitity shartfalls because I'm not afraid of
                              improving my own coding style ;)

[Jean-Yves Lefort (jylefort)]

On Sun, 25 May 2008 02:44:03 -0000
Peter Clifton <email address hidden> wrote:

> On Sun, 2008-05-25 at 00:30 +0000, Jean-Yves Lefort wrote:
> > Distributors: please do not ship a MN package with this patch applied.
> > Its quality is rather questionable, and I do not want my reputation to
> > be damaged by it.
>
> Is there going to be upstream support for GnuTLS?

There is no point. The Debian interpretation [1] is simply wrong, as
clearly hinted by the fact that no other vendor seems to adhere to it,
and as I am going to demonstrate below.

Debian believes that these two OpenSSL licensing clauses conflict with
the GPL:

 * 3. All advertising materials mentioning features or use of this
 * software must display the following acknowledgment:
 * "This product includes software developed by the OpenSSL Project
 * for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

 * 6. Redistributions of any form whatsoever must retain the following
 * acknowledgment:
 * "This product includes software developed by the OpenSSL Project
 * for use in the OpenSSL Toolkit (http://www.openssl.org/)"

According to Debian, "these clauses impose restrictions on people
wishing to distribute your program". If this was the case, MN (or any
other GPL program linking against OpenSSL) would be infringing the
OpenSSL license, since it does not display the mandatory
acknowledgement:

  "This product includes software developed by the OpenSSL Project
   for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

This acknowledgement makes it particularly clear that the two OpenSSL
clauses apply to work which includes OpenSSL source code, NOT to work
which merely links against the OpenSSL library. Does MN include
"software developed by the OpenSSL project"? No. Why should it display
an acknowledgement stating that it "includes software developed by the
OpenSSL project" when in fact it does not?

In other words, if the Debian interpretation was correct, Debian would
currently be deliberately violating the OpenSSL licensing terms by
shipping hundreds of packages which are linked against OpenSSL but do
not include the mandatory acknowledgement.

[1] http://www.gnome.org/~markmc/openssl-and-the-gpl.html

--
Jean-Yves Lefort <email address hidden>

[Jean-Yves Lefort (jylefort)]

On Sun, 25 May 2008 13:11:29 -0000
AZ <email address hidden> wrote:

> @Jean-Yves Lefort: Thanks for pointing out that this patch is not yet perfect ;). But apart from the mistakes I corrected,
> most of the gnutls related code is rather almost copy&paste from gnutls documentation
> so I don't expect too much errors . Perhaps you could point out qualitity shartfalls because I'm not afraid of
> improving my own coding style ;)

It would be rather pointless. Since I don't agree with the idea of
adding GnuTLS support, I don't want to encourage you in that way.

--
Jean-Yves Lefort <email address hidden>

[Phoenix (phoenix-dominion)]

The trouble is, that the current package deliberately transmits passwords in clear text - so I wouldn't worry too much about reputation. In it's current state this piece of software is a potential security risk, as users are encouraged to transmit passwords in cleartext - in these days, support for cleartext should be disabled and not vis versa.

I never understood debian's political issues about certain stuff - like this one, hunderts of debian packages have no trouble linking against a next-to core library, but one maintainer thinks the world turns around him and has to interpret some licensing other way round.... last but not least it might be a french and IIRC does the french gov disapprove of encryption anyway.
"France is the only Western European country which does not allow a free use of encryption on its territory." - but it's just a wild guess.

IMHO it's rather simple, as ubuntu != debian, and the licensing issues are no issues, so let's compile the software with ssl support.

GnuTLS Support would be in this case not needed, but it does not hurt to have it, does it? My abilities a rather limited to "./configure; make; make install" - so if some brave soul could give AZ a hand, he would be grateful - last but not least, ubuntu might even give it to upstream, which might be even appreciated and once debian would fetch the gnuTLS-patched version, they might even considering....

just my 2c
Philipp

[Edwin Shin (eddie)]

As a first step to getting this in multiverse, can someone produce a 5.x-series source deb? I don't have much experience at producing debs and the new build system in 5.x doesn't jibe w/ the instructions for building debs I've seen online.

[Pascal Giard (pascalgiard-debian)]

On Wed, May 28, 2008 at 10:34 AM, Edwin Shin <email address hidden> wrote:
> As a first step to getting this in multiverse, can someone produce a
> 5.x-series source deb? I don't have much experience at producing debs
> and the new build system in 5.x doesn't jibe w/ the instructions for
> building debs I've seen online.

I intend to update mail-notification to 5.x for debian as soon as
possible (as time permits).
There are many changes from 4.x to 5.x which require special attention.
Among those changes are the switch from autotools to Jean-Yves' own
build system.

That said, any help is appreciated. I'd gladly welcome a co-maintainer.

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[EarloftheWest (earlofthewest)]

Running Hardy Heron

I downloaded the most recent source of mail-notification from:
http://www.nongnu.org/mailnotify/
And followed the Readme to install and it works fine with ssl/tls notification. I'm very happy.

Being relatively new to compiling, I cheated a bit before I installed by running
sudo apt-get build-dep mail-notification
from the terminal. This installed the dependencies and the compliers (true?) so I could build and install mail-notification. Had I not run apt-get build-dep mail-notification, how would I have known what compilers and dependencies were needed to build and install?

Thanks.

[Pascal Giard (pascalgiard-debian)]

Good morning!

On Tue, Jun 10, 2008 at 2:35 AM, EarloftheWest <email address hidden> wrote:
> Being relatively new to compiling, I cheated a bit before I installed by running
> sudo apt-get build-dep mail-notification
> from the terminal. This installed the dependencies and the compliers (true?) so I could build and install mail-notification. Had I not run apt-get build-dep mail-notification, how would I have known what compilers and dependencies were needed to build and install?

Well... by having a look at the README in the official package from Jean-Yves.
"apt-get build-dep mail-notification" most likely installed abit too
much stuff as things have changed abit between 4.x and 5.x, but you
might have already installed autotools as it's a _very_ common
dependency for other packages.

cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[l33ting disorder (omni-networksense)]

Hi,

Running Ubu 8.04

I just tried downloading the most recent source to compile with TLS support and when I tried to run './jb configure' I received an error about GLib not being installed. I fired up synaptic and libglib 2.0 is in fact installed.

Tried the 'apt-get build-dep mail-notification' to install the dependencies. After that, tried './jb configure' again and it installed perfectly.

So it seems that a good idea is in fact to install the dependencies. Sure, it might also install some unneeded cruft, but I'd rather have a bit of cruft and a functional (and secure) mail scanner than to have no cruft and no scanner.

[l33ting disorder (omni-networksense)]

Ok looks like I spoke too soon...

after typing 'sudo ./jb install' it ran through the installation and it reported that it had installed itself.

When I run 'mail-notification' the app comes up, but I still have no TLS/SSL support. (The options are still disabled).

I've tried going through the process outlined in the README file a second time, this time with './jb configure ssl=yes' just to ensure ssl is being included... same results. Program works, TLS is still disabled.

I followed all the steps in the README and I received no errors. What's going wrong here?

[Pascal Giard (pascalgiard-debian)]

On Thu, Jul 24, 2008 at 3:29 PM, omni <email address hidden> wrote:
> Ok looks like I spoke too soon...
>
> after typing 'sudo ./jb install' it ran through the installation and it
> reported that it had installed itself.
>
> When I run 'mail-notification' the app comes up, but I still have no
> TLS/SSL support. (The options are still disabled).
>
> I've tried going through the process outlined in the README file a
> second time, this time with './jb configure ssl=yes' just to ensure ssl
> is being included... same results. Program works, TLS is still disabled.
>
> I followed all the steps in the README and I received no errors. What's
> going wrong here?

Do you have libssl-dev installed?

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[l33ting disorder (omni-networksense)]

Didn't have libssl-dev installed.

I tried reverting to 4.1 and manually rebuilding with dpkg and libssl-dev and now 4.1 works perfectly with TLS.

Now that I have libssl-dev I could try with 5.4 but 4.1 seems to have everything I need. Have there been any significant security updates between 4.1 and 5.4 or are all the changes mostly cosmetic?

[Pascal Giard (pascalgiard-debian)]

On Thu, Jul 24, 2008 at 4:14 PM, omni <email address hidden> wrote:
> Didn't have libssl-dev installed.
>
> I tried reverting to 4.1 and manually rebuilding with dpkg and libssl-
> dev and now 4.1 works perfectly with TLS.
>
> Now that I have libssl-dev I could try with 5.4 but 4.1 seems to have
> everything I need. Have there been any significant security updates
> between 4.1 and 5.4 or are all the changes mostly cosmetic?

Security-wise, the most significant feature must be the usage of GNOME
Keyring to store passwords.
(They used to be stored in plaintext in
~/.gnome2/mail-notification/mailboxes.xml).

Of course that particular feature is mentionned in the NEWS file, the
paragraph itself is an entertaining read.
Allow me to quote Jean-Yves:
"Passwords are now encrypted, using GNOME Keyring. Note that I do not
endorse the flawed GNOME Keyring approach of granting passwords an
encryption-worth status while ignoring other sensitive data.
Furthermore, at the time of this writing, GNOME Keyring does not seem
to prevent the memory it uses for storing the passwords from being
swapped out to disk. However, despite these flaws, it has been
observed that GNOME Keyring has beneficial psychological effects on
some users. For increased psychological well-being, MN even moves the
plain text passwords it finds in mailboxes.xml to the keyring."

Food for thoughts. ;-)

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[l33ting disorder (omni-networksense)]

Ok I tried clicking on the tray icon to bring up my mail reader and it tried to load Evolution, even though my Preferred Applications is set to use Thunderbird.

I installed 5.4 again now that I have libssl-dev, in hopes that there would be an option to select which mail reader to use. Double-disappointment: not only is v5.4 still lacking in that feature, but the SSL/TLS became disabled again.

I've reverted to 4.1 (again using the dpkg build routine after ensuring --disable-ssl had been removed from debian/rules) [side-note: i notice there's no debian/rules file in 5.4...] and now that I'm back to 4.1 the TLS/SSL support is back.

There's still the problem that mail-notification launches the wrong e-mail client.

My first thought is to simply uninstall evolution, but synaptic has all the evo files highlighted in bright red which I'm guessing means they shouldn't be installed due to dependencies.

How can I set mail-notification to launch the correct mail reader?

[l33ting disorder (omni-networksense)]

Heheh I like the quote, Pascal... So very true.

Although ultimately if you've been rooted so someone has access to the plaintext password file, YOU'VE BEEN ROOTED and thus have bigger concerns than just your e-mail password file! heheh

My concern is with sending plaintext passwords over a network.

[Nicolas da Luz Duque (hot-boy)]

Omni, the fact that synaptics highlights things in red doesn't mean it's dangerous to delete them. It just means they are set for deletion. I don't think re-installing evo is the right thing to do nor will solve anything for you, but don't be alarmed by those bright colours ;-). It's the normal behaviour for apps set for deletion.

[Pascal Giard (pascalgiard-debian)]

On Thu, Jul 24, 2008 at 4:53 PM, omni <email address hidden> wrote:
> Ok I tried clicking on the tray icon to bring up my mail reader and it
> tried to load Evolution, even though my Preferred Applications is set to
> use Thunderbird.

What's in the gconf key /desktop/gnome/url-handlers/mailto/command ?
Get it with something like "gconftool-2 --get
/apps/mail-notification/commands/mail-read/command" or by using
gconf-editor.
(You might want to try to install gconf-editor to easily get/set its value).

> I installed 5.4 again now that I have libssl-dev, in hopes that there
> would be an option to select which mail reader to use. Double-
> disappointment: not only is v5.4 still lacking in that feature, but the
> SSL/TLS became disabled again.

SSL/TLS is disabled even tho libssl-dev is installed?! What's in the
configure/build logs?

> I've reverted to 4.1 (again using the dpkg build routine after ensuring
> --disable-ssl had been removed from debian/rules) [side-note: i notice
> there's no debian/rules file in 5.4...] and now that I'm back to 4.1 the
> TLS/SSL support is back.

No debian packaging files for 5.4 as haven't ported them yet.
You might have noticed that there's been significant changes upstream
since 4.x .
Changes include license changes and a switch to a not-autotools
configure/build tool.

[...]
> How can I set mail-notification to launch the correct mail reader?

Try editing the relevant gconf key as mentionned above.

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[l33ting disorder (omni-networksense)]

> What's in the gconf key /desktop/gnome/url-handlers/mailto/command ?

Aha, thanks - that was still set to evolution.

> SSL/TLS is disabled even tho libssl-dev is installed?! What's in the
configure/build logs?

Where do I find the configure/build log?

> You might have noticed that there's been significant changes upstream
since 4.x

Indeed - and I'd prefer to use 5.4 if it would only allow TLS! :)

So anyway, I now have more trouble. 4.1 is working to an extent - it allows TLS so I can actually _USE_ it, but when I hover the mouse over the tray icon the app crashes and the icon goes away. When I click on it to launch the e-mail app, the icon goes away and the app crashes without loading my e-mail app.

Obviously something's buggered.

The ideal situation would be for me to get TLS working with 5.4 but after following all the instructions given (and making sure I have libssl-dev installed in synaptic) it's still disabled.

Sssso... I guess the stopping point now is just waiting to find out where to look for the logs.

thanks! :)

[Pascal Giard (pascalgiard-debian)]

On Fri, Jul 25, 2008 at 10:41 PM, omni <email address hidden> wrote:
>> What's in the gconf key /desktop/gnome/url-handlers/mailto/command ?
>
> Aha, thanks - that was still set to evolution.

How come this is not set when going thru the Preferred Application GUI
is actually beyond me...

>> SSL/TLS is disabled even tho libssl-dev is installed?! What's in the
> configure/build logs?
>
> Where do I find the configure/build log?

In the build/ folder. e.g. /tmp/mail-notification-5.4.dfsg.1/build/build.log .
For me, executing `./jb configure` does show ssl as enabled.

>> You might have noticed that there's been significant changes upstream
> since 4.x
>
> Indeed - and I'd prefer to use 5.4 if it would only allow TLS! :)
>
> So anyway, I now have more trouble. 4.1 is working to an extent - it
> allows TLS so I can actually _USE_ it, but when I hover the mouse over
> the tray icon the app crashes and the icon goes away. When I click on it
> to launch the e-mail app, the icon goes away and the app crashes without
> loading my e-mail app.
>
> Obviously something's buggered.

I suspect this is connected to schemas and bonobo.
Try restarting bonobo or more drastically rebooting.

Hope this helps,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[l33ting disorder (omni-networksense)]

Woot! Merci merci merci monsieur!

I had deleted all my build directories so in order to get the log I had to build again.

Looking at the output from ./jb configure I noticed that ssl was enabled. Initially this frustrated me: if ssl is enabled, why is it disabled in the built gui???

I figured I'd carry on and build so I could post the build log in case it offered any insight.

After building and installing I decided I'd do a quick test just to see if it had magically worked this time and booya - 5.4 is working with SSL just fine now. (And it doesn't crash when I hover the mouse over the tray icon, heh)

Again - merci beaucoup mon ami!

[Pascal Giard (pascalgiard-debian)]

On Mon, Jul 28, 2008 at 6:31 PM, omni <email address hidden> wrote:
> Woot! Merci merci merci monsieur!
>
> I had deleted all my build directories so in order to get the log I had
> to build again.
>
> Looking at the output from ./jb configure I noticed that ssl was
> enabled. Initially this frustrated me: if ssl is enabled, why is it
> disabled in the built gui???
>
> I figured I'd carry on and build so I could post the build log in case
> it offered any insight.
>
> After building and installing I decided I'd do a quick test just to see
> if it had magically worked this time and booya - 5.4 is working with SSL
> just fine now. (And it doesn't crash when I hover the mouse over the
> tray icon, heh)
>
> Again - merci beaucoup mon ami!

Bienvenue! i'm glad it worked :-)

FWIW, i've started packaging mn-5.4 but haven't had the time to finalize it yet.

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
LACIME: École de technologie supérieure (http://lacime.etsmtl.ca)

[Pascal Giard (pascalgiard-debian)]

Back to main subject, i'm left wondering if i should apply AZ's patch or not...

I'm well aware of Jean-Yves' opinion on this but I'd like your thoughts on the issue.

[unggnu (unggnu)]

If someone with expertise in this sector could check the code it would be fine I guess. It wouldn't be more insecure than now but I am not sure about the license/name thing.
I think that there is no fork needed. It doesn't seem to be so much code to review and support for both libs could be shipped so no one loses his face imho.

[Rachel Greenham (rachel-strangenoises)]

excuse me if this is a silly question, but why is it ok for openssh-client/openssh-server and apache2.2-common to depend on libssl and not mail-notification?

[ccc1 (cllccl-deactivatedaccount)]

any chance to include mn with ssl support enabled in intrepid?
or is there an alternative to mn that supports ssl?

[Havard Bjastad (havard-bjastad)]

Pascal, I think you SHOULD include AZ's patch. It doesn't seem to hurt to add that option, and those not comfortable with it can just leave it unused...

[Jean-Yves Lefort (jylefort)]

Havard, I've already pointed out above that I disagree with the idea.

[Matthias Benkard (mulk)]

Rachel,

mail-notification is GPL'd, while OpenSSH and Apache are released under more liberal licenses. The problem isn't with OpenSSL per se; it's with the combination of OpenSSL with a GPL-covered programme.

That said, GPL'd software may be combined with OpenSSL _if_ the software's author adds an exception to the license allowing linking with OpenSSL. mail-notification's author refuses to do that.

At least, this is the way I understand the situation. IANAL and all that.

[Christian Engwer (christi)]

Package: mail-notification
Version: 5.4.dfsg.1-1
Followup-For: Bug #286672

It seems that different maintainers interpret this issue differently.
The FAQ of the openssl package follows the official interpretation of
upstream openssl. Several other packages link against libssl although
they are licensed under gpl (e.g. kcontrol, inkscape, balsa, ...).
I would like to have this issue clearified and to have a consistent
interpretation for all debian packages.

I think many packages are rather useless without ssl support (like
mail-notification). If there exists consens in debian, that gpl
programs can not be distributed with libssl linked, I think it must be
a high priority for debian to make openssl-compat a full drop-in
replacement for libssl.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'testing-proposed-updates'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mail-notification depends on:
ii gconf2 2.22.0-1 GNOME configuration database syste
ii gnome-icon-theme 2.22.0-1 GNOME Desktop icon theme
ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libbonobo2-0 2.22.0-1 Bonobo CORBA interfaces library
ii libbonoboui2-0 2.22.0-1 The Bonobo UI library
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra
ii libdbus-1-3 1.2.1-3 simple interprocess messaging syst
ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst
ii libgconf2-4 2.22.0-1 GNOME configuration database syste
ii libglade2-0 1:2.6.2-1 library to load .glade files at ru
ii libglib2.0-0 2.16.5-1 The GLib library of C routines
ii libgmime-2.0-2a 2.2.21-1 MIME library
ii libgnome-keyring0 2.22.3-1 GNOME keyring services library
ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display
ii libgnomeui-0 2.20.1.1-1 The GNOME 2 libraries (User Interf
ii libgnomevfs2-0 1:2.22.0-5 GNOME Virtual File System (runtime
ii libgnomevfs2-extra 1:2.22.0-5 GNOME Virtual File System (extra m
ii libgtk2.0-0 2.12.11-3 The GTK+ graphical user interface
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii libnotify1 [libnotify1 0.4.4-3 sends desktop notifications to a n
ii liborbit2 1:2.14.13-0.1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.20.5-2 Layout and rendering of internatio
ii libpopt0 1.14-4 lib for parsing cmdline parameters
ii libsasl2-2...

[Matthias Benkard (mulk)]

Jean-Yves,

I, for one, really really like mail-notification and I deeply respect the work that you have put into it. Yet I'm here, unable to use this free piece of software, while the author is explicitely refusing to do anything constructive to change the users' situation, including making a tiny license change that would make everyone happy and wouldn't hurt anyone, at least as far as my viewpoint is concerned.

Personally, I think you, as the author, have every right to refuse to help. But you're not only refusing to help, you're at the same time discouraging others from helping themselves. If this is the case, why did you choose the GPL in the first place? The GPL is all about the users' ability to help themselves if need be. This is such a situation.

Do you want Ubuntu to distribute a version of mail-notification that you have reviewed for bugs and can proudly put your name on? You could effect this easily by either blessing or, better yet, merging the port to GNUTLS or by changing the license. If you don't want to do either, that's fine, but in this case, why do you complain about someone actually making use of the freedom that your chosen license grants for the exact purpose that is being considered here?

[Havard Bjastad (havard-bjastad)]

Matthias, thank you! My sentiments, exactly...
MN is so close to being *really* useful, so why not get the last piece of the puzzle in place?

[Jean-Yves Lefort (jylefort)]

Matthias,

The MN license certainly grants someone the freedom to modify the MN source code and redistribute the modified version. However, I own the "Mail Notification" trademark. Shipping a modified MN version that I have explicitly been disagreeing with is called trademark infringement. If someone wants to legally distribute such a MN version, he has to change the name of the application.

Please keep in mind that it is my reputation which can potentially be damaged by this patch. For instance, if this patch contains a security vulnerability, the various security announcements that will be issued will contain my name.

[Andrew (andrew-rw-robinson)]

On Sun, Oct 5, 2008 at 6:29 AM, Jean-Yves Lefort <email address hidden> wrote:
> Matthias,
>
> The MN license certainly grants someone the freedom to modify the MN
> source code and redistribute the modified version. However, I own the
> "Mail Notification" trademark. Shipping a modified MN version that I
> have explicitly been disagreeing with is called trademark infringement.
> If someone wants to legally distribute such a MN version, he has to
> change the name of the application.
>
> Please keep in mind that it is my reputation which can potentially be
> damaged by this patch. For instance, if this patch contains a security
> vulnerability, the various security announcements that will be issued
> will contain my name.

Not to sound too bad, but the current ubuntu version has the biggest
security hole possible, it sends passwords clear text over the
internet. Any SSL support is much better than the current versions
shipped with Debian and Ubuntu. I am surprised that Debian and Ubuntu
allow the the application in the distro without SSL. For example, the
gmail account doesn't even warn you that the connection is not secure.
I like the product a lot and I package it myself with SSL enabled as I
would much rather not use the library than use it without any
security.

>
> --
> IMAP/POP3+SSL/TLS are disabled
> https://bugs.launchpad.net/bugs/44335
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[AZ (m-dev)]

Jean-Yves Lefort wrote: "However, I own the "Mail Notification" trademark."

Is it a registered trademark? In which country? I'm not sure whether this trademark is relevant for ubuntu.

[OlivierP (unineurone)]

FYI: http://www.getdeb.net/release/2903 V. 5.4 , SSL _enabled_ despite package description stating otherwise. libssl appears as a dependency. It provides the evolution plugin also.

I do hope it will be provided quickly after the Intrepid release also ...

[OlivierP (unineurone)]

Jean-Yves,
If you REALLY intend to prohibit others from applying AZ's patch and redistributing it under the name "Mail Notification" in releases _after_ 5.4, you need to change certain things.

Using the sources downloaded here: http://savannah.nongnu.org/download/mailnotify/mail-notification-5.4.tar.bz2

MN 5.4 is released as found in it's online help, section 9.3, Licensing: "This program is distributed under the terms of the GNU General Public license as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. A copy of this license can be found at this link, or in the file COPYING included with the
 source code of this program." This is also what I have seen in the sources that I checked (I did not go through all of the files)

I've done this in the downloaded source tree:

olive@nostromo:~/mail-notification-5.4$ grep -nRi "trademark" *
COPYING:379: e) Declining to grant rights under trademark law for use of some
COPYING:380: trade names, trademarks, or service marks; or
help/C/documentation-license.xml:21: products and services are claimed as trademarks. Where those
help/C/documentation-license.xml:24: trademarks, then the names are in capital letters or initial
jbsrc/lib/COPYING:379: e) Declining to grant rights under trademark law for use of some
jbsrc/lib/COPYING:380: trade names, trademarks, or service marks; or
olive@nostromo:~/mail-notification-5.4$

I only find the lines of section 7 of GPLv3, but have not found, as per the same section: "If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms."

I have not found, but I may well have missed it, the additional terms related to your potential trademark.

Is MN v 5.4 GPLv3 "as published by the FSF" or is it governed by (belgian ?) trademark law ? If the later, please remove references to GPLv3 from the sources, documentation, and your website for your future releases. A link to the trademark registration(s) would also be appreciated.

[Jean-Yves Lefort (jylefort)]

The GPLv3 obviously does not forbid to use a trademark as the name of a covered work. You're confusing trademark and licensing issues.

[Mikael Nilsson (mini)]

OlivierP

Jean-Yves is completely correct regarding trademarks. Noone stops you
from using the sources under GPL3, but only Jean-Yves can let you use
the name "Mail Notification" (assuming it's a valid trademark of
course).

Though there is of course, a potential iceweasel situation here - i.e.
Ubuntu could choose to distribute the patched sources under a new name
because of such issues.

Jean-Yves - am I right in assuming that your resistance applies mostly
to this patch, and not to all patches in general?

Or better - what IS the exact trademark license, really? Can ubuntu ship
MN with security fixes or not, for example? Where is the limit?

/Mikael

tis 2008-10-14 klockan 23:55 +0000 skrev Jean-Yves Lefort:
> The GPLv3 obviously does not forbid to use a trademark as the name of a
> covered work. You're confusing trademark and licensing issues.
>

[Jean-Yves Lefort (jylefort)]

On Wed, 15 Oct 2008 11:16:18 -0000
Mikael Nilsson <email address hidden> wrote:

> Jean-Yves - am I right in assuming that your resistance applies mostly
> to this patch, and not to all patches in general?

You are.

> Or better - what IS the exact trademark license, really? Can ubuntu ship
> MN with security fixes or not, for example? Where is the limit?

It certainly can. The limit is crossed when I explicitly disagree with
a modification and the vendor decides to ignore my opinion.

--
Jean-Yves Lefort <email address hidden>

[unggnu (unggnu)]

Why not enable ssl and move it to multiverse? I personally use the package of getdeb.net which has SSL enabled.

[OlivierP (unineurone)]

Mikael, Jean-Yves,

   GPLv3, section 7 "Additonal terms", paragraph 3
*"e) Declining to grant rights under trademark law for use of some trade
names, trademarks, or service marks; or"
*
No problem. Jean-Yves may well have a valid trademark, I can live with it.

But paragraph 5, penultimate paragraph of setion 7):
*"If you add terms to a covered work in accord with this section, you
must place,
in the relevant source files, a statement of the additional terms that apply
to those files, or a notice indicating where to find the applicable terms."
*
As mentioned, I have *not* found such statements or notices in the sources I
have downloaded. I cannot find it either when using the help file, or in the
MN "About" dialog (firefox's 3.0.3 about box does, as previous versions
probably also have). The only place I have found it, is at the bottom of a
web page that may not be readily available to all recipients of the source
code.

How can then anyone know that there could be a potential trademark problem,
and that MN can no longer be freely to modified and redistributed under
GPLv3 ?

All I am asking for is that future releases contain the required information
as the license states they should.

[Phoenix (phoenix-dominion)]

The as yet current release does AFAICS not satisfy that the patch can not be applied, thank you GPL - Anyhow, to remove further IMHO childish discussions with the author of this software, I simply recommend to rename the the package, apply a Patch that renames the whole software. Finito. I would vote for "FreeMailNotification" - Free like in Freedom of course.
my 2c
Philipp

darn, all I wanted is to not submit my passwords in cleartext... can't belive it.

[AZ (m-dev)]

Looks like the easiest solution to me too.

[puntarenas (puntarenas)]

Okay, I guess another Ubuntu release without a usable mail-notification package in the repositories, right? Any chance to see "Free Mail Notification" in Backports for Intrepid soon? I think Debian and Ubuntu would both benefit from a renamed and patched package, so please don't hesitate any longer, your work is highly appreciated.

[PatRiehecky (jcpunk)]

Getting back to the root of the issue, ssl linkage.

To double check my assumptions before going forward:
1) Debian holds that GPL software must make some exception for it to be correctly linked with openssl
2) JYL does not note an exception nor believe it to make any sense to do such
3) Without such an exception Debian will not link this
4) Ubuntu follows Debian in such policies
5) Without the linkage no ssl is done

A part of me wants to attack 4 for being a bit like a blind man following another, but as a loyal Debian and Ubuntu user, I will keep my mouth shut on such matters.

Part of me wants to attack 2, while I know that in JYL is standing on principles that are personally important, refusing to write a sentence on this matter.... I do not intend to criticize someone for abiding by their principles in the face of adversity.

Instead I will aim at making 5 imply 2. The argument that follows is based entirely on premise 1.

A) MN has code in it which links to the openssl library
B) MN is a GPL program

Does A + B imply 1? Surly if JYL didn't want this code to be linked up to openssl no such code would be present. An analysis of the code demonstrates it is of high quality and does this linkage intentionally. The site documentation provides further support for a deliberate and intentional linkage to openssl. The build dependencies even list openssl as THE ONLY way to satisfy the SSL/TLS option. I would say that it is clear linking this to openssl is permitted by JYL.

Given that it appears JYL has granted permission to link this to openssl by the inclusion of code which performs that function, why exactly do we need an official statement saying that linkage to openssl and distribution to others is permitted?

The only bit that I feel would be needed to close up the leap would be an entry in the README indicating that JYL recommends linking the software to an SSL/TLS provider at all times. By saying that SSL linkage is recommended at all times along with the distribution of the source, it seems that anyone who is unable to determine if JYL will allow MN to be distributed along side of openssl is not paying attention. The key to sliding through the hole is the "at all times."

See http://www.gnome.org/~markmc/openssl-and-the-gpl.html with particular attention paid to the Debian template at the bottom. My reading of it boils down to, "Yes you can link this with openssl, with the caveats expected" (Thanks for the link JYL)

Question 1:
Did I whiff on the logic? This argument is a form of Original Intent legal argument, but free from some of the problems as we are just dealing with code where the intent is a bit more obvious than ethics. http://en.wikipedia.org/wiki/Original_intent

Question 2:
JYL are you willing to add this clause to the README? I expect you believe that SSL linkage should be done and as such this shouldn't violate your principles to encourage it.

[Jean-Yves Lefort (jylefort)]

On Thu, 23 Oct 2008 17:02:03 -0000
PatRiehecky <email address hidden> wrote:

> To double check my assumptions before going forward:
> 1) Debian holds that GPL software must make some exception for it to be correctly linked with openssl

Correct.

> 2) JYL does not note an exception nor believe it to make any sense to do such

Correct.

> 3) Without such an exception Debian will not link this

Correct.

> 4) Ubuntu follows Debian in such policies

It looks like it, but I've never seen an official statement.

> 5) Without the linkage no ssl is done

Correct.

> A part of me wants to attack 4 for being a bit like a blind man
> following another, but as a loyal Debian and Ubuntu user, I will keep my
> mouth shut on such matters.
>
> Part of me wants to attack 2, while I know that in JYL is standing on
> principles that are personally important, refusing to write a sentence
> on this matter.... I do not intend to criticize someone for abiding by
> their principles in the face of adversity.

Nice. :)

> Instead I will aim at making 5 imply 2. The argument that follows is
> based entirely on premise 1.
>
> A) MN has code in it which links to the openssl library
> B) MN is a GPL program
>
> Does A + B imply 1? Surly if JYL didn't want this code to be linked up
> to openssl no such code would be present. An analysis of the code
> demonstrates it is of high quality and does this linkage intentionally.
> The site documentation provides further support for a deliberate and
> intentional linkage to openssl. The build dependencies even list
> openssl as THE ONLY way to satisfy the SSL/TLS option. I would say that
> it is clear linking this to openssl is permitted by JYL.
>
> Given that it appears JYL has granted permission to link this to openssl
> by the inclusion of code which performs that function, why exactly do we
> need an official statement saying that linkage to openssl and
> distribution to others is permitted?
>
> The only bit that I feel would be needed to close up the leap would be
> an entry in the README indicating that JYL recommends linking the
> software to an SSL/TLS provider at all times. By saying that SSL
> linkage is recommended at all times along with the distribution of the
> source, it seems that anyone who is unable to determine if JYL will
> allow MN to be distributed along side of openssl is not paying
> attention. The key to sliding through the hole is the "at all times."
>
> See http://www.gnome.org/~markmc/openssl-and-the-gpl.html with
> particular attention paid to the Debian template at the bottom. My
> reading of it boils down to, "Yes you can link this with openssl, with
> the caveats expected" (Thanks for the link JYL)
>
> Question 1:
> Did I whiff on the logic? This argument is a form of Original Intent legal argument, but free from some of the problems as we are just dealing with code where the intent is a bit more obvious than ethics. http://en.wikipedia.org/wiki/Original_intent

Your analysis looks reasonable and senseful.

> Question 2:
> JYL are you willing to add this clause to the README? I expect you believe that SSL linkage should be done and as such this shouldn't violate your principles to enc...

[Edwin Shin (eddie)]

A big thank-you to Pat for such a well-reasoned and well-put argument. I look forward to Jean-Yves' addition to the README and hope that we will see MN *with* SSL/TLS in the official repos soon. As Pat notes, after JYL makes the README addition, arguments that the author does not allow for the distribution of MN with openssl demonstrate a lack of attention. If we see this resolved for Jaunty, we won't all have to come back here to mark the three year anniversary of this bug report ;)

[huiii (a00ps)]

oooooh, does not woooorkkk, nooo ssl...

[Henrik Heino (henu)]

Hello. I would just like to inform you, that there is one more person who thinks that current mail-notification in repository is completely useless as long as it does not have an SSL-support.

[Dook (danduq)]

Just adding another voice to the list! Useless without SSL.

[_dan_ (dan-void)]

useless without ssl, change it or remove it from repos.

[Sika (sikamikaniboots)]

I'd like to understand: 6 months ago you found a solution to fix this but nothing has changed since then.
Is there still anything keeping this bug from being solved?

[Mike Basinger (mike.basinger)]

Could a SSL enabled package be built and uploaded to multiverse?

[Johannes Hessellund (osos)]

+1

Useless without SSL. I'm not going to send my password unencrypted over the internet!

Using gnubiff until fixed!

[Andrew (andrew-rw-robinson)]

I'm trying to get this setup in a PPA. I got it to build with a different version number, but if I try to rename the binary package as "mail-notification-ssl" (did not rename the source package), the build is failing due to the output directories I think.

Anyone know all the steps necessary to get this to build under a different binary name?

That way when a new mail-notification is released, it would not automatically upgrade the mail-notification-ssl package that you would have installed.

[Andrew (andrew-rw-robinson)]

I have decided that if debian has decided that GPL and libssl are incompatible, I am not going to subject myself to problems by making a PPA of this either.

I am just going to keep re-packaging it.

Perhaps the author may consider switching off of GPL, or having a dual license, or if not switching libraries, but until then, we are stuck with re-packaging as that doesn't affect the redistribution clause.

[Andrew (andrew-rw-robinson)]

For those interested, I wrote a deb program that does the necessary steps to rebuild the 5.4 package in jaunty with SSL enabled. No steps to follow, just install my package from my PPA:

https://launchpad.net/~andrew-rw-robinson/+archive/ppa

Hope it helps.

[Patrick Seiji Winslow (pswinslow)]

This is how I build my package. I think this should work with Ubuntu, but I use Debian. Hopefully an Ubuntu user will report whether this works or not. You need to have deb-src lines in your /etc/apt/sources.list to download package sources. You'll have a bunch of files, so I suggest you make a directory to contain them.

apt-get source mail-notification
sudo apt-get build-dep mail-notification
sudo apt-get install libssl-dev
 (this was removed from the build dependencies)
cd mail-notification-5.4.dfsg.1
 (the name of this directory may be different on your system)

Edit debian/rules. Search for "ssl=no" and change it to "ssl=yes". You can change the version number in debian/changelog if you want to. I append ".0.ssl" to it so updates are not blocked.

dpkg-buildpackage -b -us -uc -tc
cd ..
sudo dpkg -i mail-notification*.deb

[John Lewis (jlewis-johnlewis-deactivatedaccount)]

Hi Andrew and Patrick,

I can report that both of you methods work in that you get a package to install at the end, however I still have the SSL options greyed out after installation, any ideas?

[John Lewis (jlewis-johnlewis-deactivatedaccount)]

Scratch that, I just had to end and restart the existing mail-notification binary i.e. "sudo killall mail-notification" and then restart from the preferences menu and the options appeared. Thanks for the solution guys.

[sefs (sefsinc)]

Andrew I would like to use your ppa to have your solution dump the results as a deb into a directory that i can copy from machine to machine after building in one place.

Is that possible?

[sefs (sefsinc)]

By the way where in the source do I change that ugly icon when there is no new mail.

Thanks.

[Nikil Mehta (nikil.mehta)]

I can't believe this is being argued over the course of three years. There is a two second fix for this which could be accomplished either by the ridiculously stubborn developer or the ridiculously stubborn distro maintainers. Put your egos aside and fix the problem! So dumb.

[Nikil Mehta (nikil.mehta)]

This is still pissing me off so another note on this...

There are potentially MILLIONS of users out there using this program and submitting their gmail password in cleartext. Jean-Yves Lefort, somebody wrote the gnutls code FOR you! I don't think you care about the security of the patch (aka your "reputation")- if you cared about security you would try to make sure that the majority of users out there are using your program in a secure manner. The fact is you don't care about security, you care about winning an argument with the Ubuntu/Debian maintainers. Which chances are you are not going to win.

And to those maintainers... this package is insecure enough that it shouldn't even be packaged and supported if you're not going to allow for OpenSSL compilation. Just remove it or allow for SSL. Seriously.

[Aidan Fitzpatrick (afit)]

I agree re removing this package or replacing it with another until this is fixed. It is insecure and I cannot see why many would use it without SSL. With SSL it's great, but if we have to repackage ourselves each time we install it may as well not be in the repository...

[John Lewis (jlewis-johnlewis-deactivatedaccount)]

I second that.

On Wed, 2009-07-29 at 21:38 +0000, Aidan Fitzpatrick wrote:
> I agree re removing this package or replacing it with another until this
> is fixed. It is insecure and I cannot see why many would use it without
> SSL. With SSL it's great, but if we have to repackage ourselves each
> time we install it may as well not be in the repository...
>

[Phoenix (phoenix-dominion)]

As bug reporter of bug #132947, who notified Ubuntu Security about the issue, I can barely express myself, as English is not my mother tongue, how poorly this issue is handled - YEARS passed by. Everyone is laughting at Microsoft when it takes them 10 months to fix severe security issues, but seeing this bug, I can well imagine why it takes so long.

If I were so, and I was, about building packages everytime myself, I would use Gentoo, Slackware or any BSD - but Ubuntu is a binary distribution, therefore I like to have a binary delivered. I want something that just works.

It needs someone to get it done on a political basis - either by fixing the issue or removing the piece of insecure code.

my 2c
Philipp

[Karol Pucyński (kpucynski)]

3 years and still arguing... come on! Is it really such ideological issue to enable SSL? :/

[Patrick Seiji Winslow (pswinslow)]

This is what we in the U.S. call a Mexican standoff. This is a human problem, not a technical problem. Free software has been burdened by it for decades. This is why Emacs forked and XFree86 stagnated for years under bad management until Keith Packard staged a coup. Most free software developers and maintainers are volunteers, so they can't be forced to do anything. They are free to behave like children if they wish.

I'm concerned when people say things like, "I admire your devotion to your principles, but . . . " in situations like this, because they're confusing integrity with inflexibility. If I refuse to do something which I consider immoral, I am demonstrating integrity. If I'm asked to do something legal, moral, and easy, but I refuse because I believe my interpretation of the rules should prevail, and any who have the temerity to disagree with me must submit to my superior opinion, even if that process is prolonged and inflicts collateral damage upon people who aren't even privy to the dispute, then I'm being inflexible.

This situation is analogous to one I repeatedly encounter in my interactions with children who have Asperger's syndrome/high-functioning autism (I have it, too, like many programmers). Two autistic children who are playing a board game will disagree about the correct interpretation of the rules and they deadlock, neither making a move, each absolutely focused on winning the argument and making the other relent, so they miss the opportunity to enjoy the game, which was the original point.

This behavior isn't admirable, it's petty. The children aren't defending moral principles. They just want everything their way. While there's nothing illogical about what they're doing, it's inconsiderate. They take do-or-die stands on trivial issues because they don't consider what other people might regard as important. Many people think this is simple selfishness, but this is actually a manifestation of a problem we have appreciating, in general, the perspectives of other people, and, specifically, considering the harmful effects our actions will have on other people, particularly bystanders.

I actually agree with Jean-Yves Lefort's interpretation of the Debian policy document, but I'm more sympathetic to Debian's position because I think it's an overly cautious response to a legitimate fear of being destroyed by lawsuits. Even if the lawsuits have no merit, the cost in money and time (especially time) can be severely damaging. Their position may be technically incorrect, but I believe it's understandable in light of the threats to free software (e.g. SCO vs. Linux, a perfect example of a lawsuit without merit consuming time and resources).

I want to emphasize, however, that either side could resolve this standoff. That is the nature of any Mexican standoff. Debian could and should fix the policy document so that people like Jean-Yves and me don't interpret it the way we do, since that isn't their intention. They should do this without regard to what Jean-Yves chooses to do or not do. It will only benefit them in the long run. Whether they will or not, however, is something only they control.

In closing, I'd like to assure bot...

[Jeremy Nickurak (nickurak)]

Jean-Yves Lefort:
You mentioned willingness to add this clause to your README file, which would apparently solve this. Any chance you could provide such a clause quickly, with no other source/feature-changes to mail-notification? We as users of this program (which so far fills a gap nobody else seems interested in working on...) would, I think, all greatly appreciate it

[unggnu (unggnu)]

I hope that this gets fixed until the release of Karmic. I mean a setting like this is insane with a Laptop or Netbook.
Even worse it is not so easy possible to compile an own version of mail-notification in Karmic because of https://bugs.launchpad.net/ubuntu/+source/mail-notification/+bug/435789 .

At least after this there is no need to read a Jane Austen novel, we got all the stuff here ;D

[Patrick Seiji Winslow (pswinslow)]

If you can't recompile, you can use Stunnel. It binds to a port on your computer and forwards traffic with encryption (like ssh, but you don't need a shell account on the remote host). This is how Conky does secure email checks. Read the Conky FAQ at http://conky.sourceforge.net/faq.html (Q #10) to get it working. The Stunnel configuration will work just as well for mail-notification as it will for Conky.

You may even end up replacing mail-notification with Conky, like I did.

[AZ (m-dev)]

Hi,

more than a year ago I provided a patch for mail notification to work with gnutls hoping
that this would speedup either distribution with openssl or gnutls enabled.
At that time, creating a gnutls enabled mail notification package failed due to a lack of time
of the involved persons. As it looks to me that distributing mail notification with openssl
support enabled will still take some more time before it happens, I've now updated
the mail notification 5.4 ubuntu jaunty source package to come with gnutls enabled.

Though, the upstream author mentioned in comment 64 that he would dislike
such a package being named mail notification. That's why I renamed the package
to secure mail notification. As soon as debian and ubuntu decide to distribute
mail notification with openssl support enabled, secure mail notification will become
obsolete.

For those who cannot await secure mail notification being in the universe repository,
I'm uploading a signed binary (jaunty x86) and the source package.

[AZ (m-dev)]

comment #106 : main application binary
comment #107: evolution plugin binary
comment #108: changelog for binaries
comment #109: source description
comment #110: source to extract
comment #111: changelog for source

[AZ (m-dev)]

Cleaning up the patch files by removing all changes from files that can be regenerated on jaunty.
This leads to the server dbus interface working again.
Futher, ubuntu jaunty binaries and source packages for secure mail notification and vanilla patches against mail notification 5.4 have been grouped into an archive and supplemented by a short readme explaining the patch files.

[AZ (m-dev)]

Dear package maintainer,

please find patches to make mail notification work with gnutls
attached to the ubuntu bug report. They apply to the vanilla
mail notification 5.4 and introduce only gnutls as a new build
and runtime dependeny (no diff for control file included).

Sincerely
 AZ

[unggnu (unggnu)]

The only workaround for Karmic I have found so far is to compile mail-notification (with SSL) in Jaunty and use this package for Karmic.

[AZ (m-dev)]

The important step for karmic is to remove libeel2-dev from the list of dependencies as well as to apply bug #443406.

[MP (marcopugge)]

Shipping this package without builtin ssl support is wrong whatever the reason, so please:
- try and find a way to accomodate ubuntu rules with the author's opinions and ship a package with ssl support
- build a package with ssl support and ship it in multiverse
- remove the package entirely from ubuntu repositories and let the users go to the author homepage to get it

Having this bug still opened after 3 years of arguing is a shame for both the distributor and the author.

Is not Ubuntu the distribution where things just works?

[MP (marcopugge)]

In my previous comment I obviously suggest to follow one of three options listed. Sorry but english is not my first language..

I also want to make clear that if we are so pissed off is because mn is a really great piece of software (thanks Jean-Yves!) that deserves to be fully appreciated by the users.. having it broken is not a good advertisement for anyone.

[David Jurenka (jurenka)]

This bug may well remain open for another couple of years. In the meantime, I've created a PPA with mail-notification as conceived by its upstream author, i.e. with SSL enabled.

https://launchpad.net/~mail-notification-ssl/+archive/ppa

Packages for all current releases (Hardy through Lucid) are available.

[John Paulett (johnpaulett)]

David, thanks for creating this ppa! It has worked well so far.

[Rod J (rod-jamieson)]

Thanks David ... I didn't feel up to compiling the source just yet so your work is appreciated :-)

[cnom (cnom)]

Comment #72 by Jean-Yves Lefort on 2008-10-05:
> I own the "Mail Notification" trademark. Shipping a modified
> MN version that I have explicitly been disagreeing with is
> called trademark infringement. If someone wants to legally
> distribute such a MN version, he has to change the name of
> the application.

Aside from everything else, please disregard this particular nonsense. It might be preferable to not take the same name to preclude misunderstandings or out of respect, but there is no such thing as trademark protection of generic names. If you want to protect your trademark, choose a distinctive name.

Anyone interested, look up "trademark distinctiveness", "descriptive marks, and "generic marks".

[Mark Shuttleworth (sabdfl)]

Hold on, Mail Notification might well be a registered trademark in a
particular jurisdiction, the rules vary widely as to what is allowed as
a TM and what is not. If the original author does have a point on this,
we should respect it.

Mark

[John Lewis (jlewis-johnlewis-deactivatedaccount)]

Ok so, change the name and lets get this sorted once and for all.

[Carsten Agger (agger)]

I would like to add that as much as I'd like to use mail-notification, I also regard it as completely useless unitl SSL/TLS support has been added.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mail-notification - 5.4.dfsg.1-2.4ubuntu3

---------------
mail-notification (5.4.dfsg.1-2.4ubuntu3) oneiric; urgency=low

  * SSL enabled (LP: #44335). New Debian license interpretation:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286672#68
  * debian/patches/looser-gconf-check.patch:
    Drop default checks when default values don't apply (LP: #845990).
 -- Gunnar Hjalmarsson <email address hidden> Mon, 26 Sep 2011 08:11:28 +0200