Re: [SOGo] Packaging Debian in SOGo
Christian Roessner said: So, if projects can not be linked against OpenSSL, wouldn't be NSS the better choice than gnutls (also for other packages)? This video contains information about the flaws in many SSL/TLS toolkits: http://www.youtube.com/watch?v=y3cfEP05LDA -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Packaging Debian in SOGo
At Thu, 7 Apr 2011 00:34:01 +, Clint Adams wrote: Christian Roessner said: So, if projects can not be linked against OpenSSL, wouldn't be NSS the better choice than gnutls (also for other packages)? This video contains information about the flaws in many SSL/TLS toolkits: http://www.youtube.com/watch?v=y3cfEP05LDA Slides are here: http://www.slideshare.net/bagder/libcurl-seven-ssl-libraries-and-one-ssh-library And the last slide links to http://curl.haxx.se/docs/ssl-compared.html which might also be interesting. I actually choosed GnuTLS in the end, because NSS requires to use NSPR (Netscape Portable Runtime) sockets instead of just normal sockets. This would mean also changing the NSActiveSocket class and maybe more instead of just a few lines NSActiveSSLSocket. I've almost finished my patch, it compiles but I still have to test whether it really works. -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Packaging Debian in SOGo
Sorry, I don't know about NSS (only name service switch ;-) ) NSS was orginally created by Netscape and now maintained by Mozilla. It is used by all Mozilla products, but also for example by OpenOffice.org and Chrome. See http://www.mozilla.org/projects/security/pki/nss/ for more information. Thanks for this link. This looks interesting to me :-) Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com signature.asc Description: OpenPGP digital signature
Re: [SOGo] Packaging Debian in SOGo
Am 02.04.2011 12:37, schrieb Jeroen Dekkers: At Sat, 02 Apr 2011 08:38:46 +0200, Christian Roessner wrote: I know, I will get flamed right now, but please do not use gnutls. Google for i.e. OpenLDAP and gnutls and follow the comments from Howard Chu, then you understand me. Or at least dear SOGo devs: please do not drop packges for Ubuntu/Debian on inverse, so people can use the openssl variant. There is no need to flame people who raise valid concerns. I was actually thinking about using NSS instead of GnuTLS, but I don't have a very strong opinion about it. I did have some problems with GnuTLS a few years ago, but those problems might have been solved and I don't have experience with NSS to compare with. Do you (of anyone else on this list) know of any potential problem with using NSS? Sorry, I don't know about NSS (only name service switch ;-) ) NSS was orginally created by Netscape and now maintained by Mozilla. It is used by all Mozilla products, but also for example by OpenOffice.org and Chrome. See http://www.mozilla.org/projects/security/pki/nss/ for more information. What I just saw there on the FAQ: How does NSS compare to OpenSSL? OpenSSL is an open source project that implements server-side SSL, TLS, and a general-purpose cryptography library. It does not support PKCS #11. It is based on the SSLeay library developed by Eric A. Young and Tim J. Hudson. OpenSSL is widely used in Apache servers and is licensed under an Apache-style licence. NSS supports both server and client applications as well as PKCS #11 and S/MIME. To permit its use in as many contexts as possible, NSS is triple-licensed under the Mozilla Public License, the GNU General Public License, and the GNU Lesser General Public License. You may choose to use the code either under the terms of the MPL or the GPL or the LGPL. So, if projects can not be linked against OpenSSL, wouldn't be NSS the better choice than gnutls (also for other packages)? Thanks in advance Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com signature.asc Description: OpenPGP digital signature
Re: [SOGo] Packaging Debian in SOGo
I know, I will get flamed right now, but please do not use gnutls. Google for i.e. OpenLDAP and gnutls and follow the comments from Howard Chu, then you understand me. Or at least dear SOGo devs: please do not drop packges for Ubuntu/Debian on inverse, so people can use the openssl variant. There is no need to flame people who raise valid concerns. I was actually thinking about using NSS instead of GnuTLS, but I don't have a very strong opinion about it. I did have some problems with GnuTLS a few years ago, but those problems might have been solved and I don't have experience with NSS to compare with. Do you (of anyone else on this list) know of any potential problem with using NSS? Sorry, I don't know about NSS (only name service switch ;-) ) Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com signature.asc Description: OpenPGP digital signature
Re: [SOGo] Packaging Debian in SOGo
At Sat, 02 Apr 2011 08:38:46 +0200, Christian Roessner wrote: I know, I will get flamed right now, but please do not use gnutls. Google for i.e. OpenLDAP and gnutls and follow the comments from Howard Chu, then you understand me. Or at least dear SOGo devs: please do not drop packges for Ubuntu/Debian on inverse, so people can use the openssl variant. There is no need to flame people who raise valid concerns. I was actually thinking about using NSS instead of GnuTLS, but I don't have a very strong opinion about it. I did have some problems with GnuTLS a few years ago, but those problems might have been solved and I don't have experience with NSS to compare with. Do you (of anyone else on this list) know of any potential problem with using NSS? Sorry, I don't know about NSS (only name service switch ;-) ) NSS was orginally created by Netscape and now maintained by Mozilla. It is used by all Mozilla products, but also for example by OpenOffice.org and Chrome. See http://www.mozilla.org/projects/security/pki/nss/ for more information. -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Packaging Debian in SOGo
SOPE and SOGo use OpenSSL which is incompatible with the GPL due to the advertising clause. There are only 3 places where OpenSSL is used and it shouldn't be that hard to replace OpenSSL with GnuTLS or NSS. Would a patch doing that be accepted? I know, I will get flamed right now, but please do not use gnutls. Google for i.e. OpenLDAP and gnutls and follow the comments from Howard Chu, then you understand me. Or at least dear SOGo devs: please do not drop packges for Ubuntu/Debian on inverse, so people can use the openssl variant. My personal opinion: If I as a user have to choose between license and a working ssl implementation, I choose the latter one. SOGo configuration file is currently in /home/sogo. For the FHS this should be under /etc. A quick way to do this is to give the sogo user a homedirectory of /etc/sogo, but I think that's bit dirty. Would it be possible to use something like /etc/sogo/sogo.conf instead of the GNUdefaults in the sogo homedirectory? Or maybe something like /etc/GNUstep/Defaults? I don't really know enough about GNUstep to figure out the best way to do this. I just think a about packages like amavis. The home is /var/lib/amavis. If you set up razor or pyzor, you do have the configuration in /var/lib/amavis, too. So in my opinion there do exist projects and packages, where it is normal that the configuration might be elsewhere. Compared to sogo, you even would not directly edit the plist, would you? If so, maybe you could place a symlink into /etc/sogo/sogo.plist? Just an idea. Sorry for my comments above. Just my opinion and experiences. Best wishes Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com signature.asc Description: OpenPGP digital signature
Re: [SOGo] Packaging Debian in SOGo
At Fri, 01 Apr 2011 11:34:34 +0200, Christian Roessner wrote: SOPE and SOGo use OpenSSL which is incompatible with the GPL due to the advertising clause. There are only 3 places where OpenSSL is used and it shouldn't be that hard to replace OpenSSL with GnuTLS or NSS. Would a patch doing that be accepted? I know, I will get flamed right now, but please do not use gnutls. Google for i.e. OpenLDAP and gnutls and follow the comments from Howard Chu, then you understand me. Or at least dear SOGo devs: please do not drop packges for Ubuntu/Debian on inverse, so people can use the openssl variant. There is no need to flame people who raise valid concerns. I was actually thinking about using NSS instead of GnuTLS, but I don't have a very strong opinion about it. I did have some problems with GnuTLS a few years ago, but those problems might have been solved and I don't have experience with NSS to compare with. Do you (of anyone else on this list) know of any potential problem with using NSS? My personal opinion: If I as a user have to choose between license and a working ssl implementation, I choose the latter one. If you actually read the whole thread you also see that people aren't fond of using GnuTLS, but don't have the choice of using OpenSSL. As user you can do with GPL software whatever you want as long as you don't distributie it, but as a developer or distribution you can't just violate the license of other people's code. And Inverse could add an exception for linking with OpenSSL, but that wouldn't fix the problem with OpenChange or other GPL code used by SOGo now or in the future. So in my opinion the best solution would be to just use a GPL-compatible SSL library. SOGo configuration file is currently in /home/sogo. For the FHS this should be under /etc. A quick way to do this is to give the sogo user a homedirectory of /etc/sogo, but I think that's bit dirty. Would it be possible to use something like /etc/sogo/sogo.conf instead of the GNUdefaults in the sogo homedirectory? Or maybe something like /etc/GNUstep/Defaults? I don't really know enough about GNUstep to figure out the best way to do this. I just think a about packages like amavis. The home is /var/lib/amavis. If you set up razor or pyzor, you do have the configuration in /var/lib/amavis, too. So in my opinion there do exist projects and packages, where it is normal that the configuration might be elsewhere. Compared to sogo, you even would not directly edit the plist, would you? If so, maybe you could place a symlink into /etc/sogo/sogo.plist? Just an idea. What I currently do on my own server is to edit an old-style configuration file and copy that in place everytime I change it, so I don't have to edit the XML file. I think that's a bit suboptimal. Some time ago someone also posted a script that parses a SOGo.conf and generated the poperty list. So there are more people who don't like that GNUstep changes the configuration automatically to XML (or worse, overwrite it when it can't parse it). So maybe it's better to make changes in the way SOGo is configured, but I would like to know the opinion of the SOGo developers about this. Sorry for my comments above. Just my opinion and experiences. Again, no need to apologize. Discussions like this only make SOGo a better product. Jeroen Dekkers -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Packaging Debian in SOGo
Hi Jeroen, If you are serious about maintaining that package then that's very good news! Regarding your concerns: - for libssl, we use the encryption code but we also make use of utility functions such as md5_something. I don't know if similar functions are offered by other libraries. The alternative would be to clarify our licence to include an exception clause. That's more difficult for SOPE though, as we don't own the copyright for it. How was this handle with the old SOPE packages, that used to be present in Debian a few years ago? - regarding the configuration file in /etc/, this would not be difficult to achieve. Another concern I would have though would be to see whether SOGo can run in a homeless environment, which actually depends more on GNUstep for that matter... There are other areas of improvements that would make SOGo fit even better in Debian: - a debconf interface to setup a basic and working configuration - the ability to update the database schema whenever it changes from one version to another. We provide scripts for that but they might not be suitable for execution from setup scripts. In any case, I am willing to help you with that task, being a dormant Debian developer myself. Cheers! -- Wolfgang Sourdeau :: +1 (514) 447-4918 ext. 125 :: wsourd...@inverse.ca Inverse inc. Leaders behind SOGo (sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] Packaging Debian in SOGo
Hi, I'm currently working on the Debian packaging of SOGo with the goal of getting it into Debian. There has been a request for package here: http://bugs.debian.org/584073. Some issues are raised there and I found a few myself. The things I haven't solved yet are: SOPE and SOGo use OpenSSL which is incompatible with the GPL due to the advertising clause. There are only 3 places where OpenSSL is used and it shouldn't be that hard to replace OpenSSL with GnuTLS or NSS. Would a patch doing that be accepted? SOGo includes embedded copies of ckeditor, scriptaculous and prototype. According to Debian policy those embedded copies should not be packaged and the system copies should be used instead. One way to do this is to create symlinks from the original location to the system copies. I tried that but scriptaculous has been patched in SOGo because the location in SOGo wasn't what scriptaculous normally wants and I couldn't get it to load. Another solution would be to always use /javascript as location for the javascript libraries (and also avoid patching scriptaculous). Then the Debian package can rely on javascript-common to setup the /javascript dirs in Apache. SOGo can then just ship a default apache configuration with a single Alias/RewriteRule that point to the javascript libs provided by SOGo. What do you think about this? SOGo configuration file is currently in /home/sogo. For the FHS this should be under /etc. A quick way to do this is to give the sogo user a homedirectory of /etc/sogo, but I think that's bit dirty. Would it be possible to use something like /etc/sogo/sogo.conf instead of the GNUdefaults in the sogo homedirectory? Or maybe something like /etc/GNUstep/Defaults? I don't really know enough about GNUstep to figure out the best way to do this. I'm trying to avoid having to patch a lot in the Debian package and I'm willing to solve the issues cleanly in SOGo upstream, but I need some directions for that. Kind regards, Jeroen Dekkers -- users@sogo.nu https://inverse.ca/sogo/lists
