Bug Description

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.

Related branches

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.

| 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.

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?

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.

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.

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.

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[?].

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 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)

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.

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.

> 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?)

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.

>
> 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:

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).

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.

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

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 tohttp://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.

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.

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.

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.

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.

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.

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.

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.

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...

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...
>

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.

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.

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

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.

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.

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.

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).

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.

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.

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.

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.