Menu
▾
▴
|
From: Lionel B. <lio...@bo...> - 2004-12-10 18:27:38
|
Hi, 1.4.0 is released on sourceforge. There was a window left for SQL injection that was reported this morning, it is fixed in this version. People still running 1.2.x versions are strongly advised to upgrade to 1.4.0. The documentation should be up to date for the new whitelisting mechanisms, see the HOWTO file for details on how to handle the occasional odd MTA configuration that doesn't play well with greylisting. Happy greylisting, Lionel. |
|
From: HaJo S. <ha...@ha...> - 2004-12-13 11:47:16
|
On Sat, 2004-12-11 at 02:27, Lionel Bouton wrote: > Hi, > > 1.4.0 is released on sourceforge. There was a window left for SQL > injection that was reported this morning, it is fixed in this version. Appears good. A few thoughts though: - Shouldn't sqlgrey be placed in /usr/sbin rather than /usr/bin? - Ever thought of a "live update" of the whitelists rather than supplying them with the source/rpm. Ie sqlgrey in say weekly intervals loading them from sqlgrey.sf.net? - Is /var/sqlgrey really necessary? Wouldn't it be enough to start sqlgrey in /tmp? Tnx, HaJo -- HaJo Schatz <ha...@ha...> http://www.HaJo.Net PGP-Key: http://www.hajo.net/hajonet/keys/pgpkey_hajo.txt |
|
From: Lionel B. <lio...@bo...> - 2004-12-13 12:59:10
|
HaJo Schatz wrote the following on 12/13/04 12:47 : >On Sat, 2004-12-11 at 02:27, Lionel Bouton wrote: > > >>Hi, >> >>1.4.0 is released on sourceforge. There was a window left for SQL >>injection that was reported this morning, it is fixed in this version. >> >> > >Appears good. A few thoughts though: > >- Shouldn't sqlgrey be placed in /usr/sbin rather than /usr/bin? > > Makes sense to me. >- Ever thought of a "live update" of the whitelists rather than >supplying them with the source/rpm. Ie sqlgrey in say weekly intervals >loading them from sqlgrey.sf.net? > > Nice idea. I don't want to bloat SQLgrey with the download code (I'm already worried by its size and what it will be like with SPF support), but I sure can add a hook to make it reload the main whitelists on a SIGHUP for example. Then it's only a matter of a simple script that will fetch the download URLs from the conf file, download the whitelists, make some simple checks, replace the whitelist files and send SIGHUP to sqlgrey. I don't think distributing them from sourceforge is acceptable by sourceforge policy, but I can setup an alternate distribution server (in fact Gentoo users can install SQLgrey from the sources on my server already). >- Is /var/sqlgrey really necessary? Wouldn't it be enough to start >sqlgrey in /tmp? > > For MySQL and PostgreSQL users, /var/sqlgrey isn't needed at all. But SQLite users need a working directory for the database. The RPM can't guess which database will be used. As the answer really isn't obvious, I'll add this to the FAQ. Best regards, Lionel. |
|
From: HaJo S. <ha...@ha...> - 2004-12-13 13:17:46
|
Lionel Bouton wrote: >> - Ever thought of a "live update" of the whitelists rather than >> supplying them with the source/rpm. Ie sqlgrey in say weekly intervals >> loading them from sqlgrey.sf.net? > > Nice idea. I don't want to bloat SQLgrey with the download code (I'm > already worried by its size and what it will be like with SPF support), How about just calling an external wget? > but I sure can add a hook to make it reload the main whitelists on a > SIGHUP for example. Then it's only a matter of a simple script that will > fetch the download URLs from the conf file, download the whitelists, > make some simple checks, replace the whitelist files and send SIGHUP to > sqlgrey. That could maybe be done nicely in the init.d script. Say a restart automagically loads the latest whitelists. -- HaJo Schatz <ha...@ha...> http://www.HaJo.Net PGP-Key: http://www.hajo.net/hajonet/keys/pgpkey_hajo.txt |
|
From: Lionel B. <lio...@bo...> - 2004-12-13 13:39:25
|
HaJo Schatz wrote the following on 12/13/04 14:17 : > Lionel Bouton wrote: > >>> - Ever thought of a "live update" of the whitelists rather than >>> supplying them with the source/rpm. Ie sqlgrey in say weekly intervals >>> loading them from sqlgrey.sf.net? >> >> >> Nice idea. I don't want to bloat SQLgrey with the download code (I'm >> already worried by its size and what it will be like with SPF support), > > How about just calling an external wget? SQLgrey will block until the wget returns (Multiplexing has its drawbacks...) : you will put connections on hold and if the wget takes long enough, break them. > >> but I sure can add a hook to make it reload the main whitelists on a >> SIGHUP for example. Then it's only a matter of a simple script that >> will fetch the download URLs from the conf file, download the >> whitelists, make some simple checks, replace the whitelist files and >> send SIGHUP to sqlgrey. > > > That could maybe be done nicely in the init.d script. Say a restart > automagically loads the latest whitelists. > Calling the init.d script seems good, but on non SysV Unices it won't work... Sending a SIGHUP to the pid in /var/run/sqlgrey.pid is probably more portable. I'll probably add a reload to the init scripts for convenience though. Best regards, Lionel. |
|
From: David R. <dr...@gr...> - 2004-12-13 20:08:34
|
Lionel Bouton wrote: >>- Ever thought of a "live update" of the whitelists rather than >>supplying them with the source/rpm. Ie sqlgrey in say weekly intervals >>loading them from sqlgrey.sf.net? > > Nice idea. I don't want to bloat SQLgrey with the download code (I'm > already worried by its size and what it will be like with SPF support), > but I sure can add a hook to make it reload the main whitelists on a > SIGHUP for example. Then it's only a matter of a simple script that wil= l > fetch the download URLs from the conf file, download the whitelists, > make some simple checks, replace the whitelist files and send SIGHUP to > sqlgrey. I like the idea of a script to update the whitelists. This would be something that could be added to a cron entry. I don't like the idea of putting that code into sqlgrey itself, if you should be able to turn it off. -Dave PS - Version 1.4.0 has been working very well for me so far! |
