Never mind,
This patch is not stable yet.
Joe Maimon wrote:
Return value checks for
cli_malloc/cli_calloc/cli_realloc/malloc/calloc/realloc
Some of the reactions may not be wholly apropriate but are certainly
no worse than a segfault?
Joe
Nigel Horne wrote:
Please don't cross post.
My apologies.
I was under the impression that [EMAIL PROTECTED] is not the mailinglist,
but where patches sgould be sent for consideration by developers with
CVS write.
I will send future posts to wherever is preferred.
Joe
---
Return value checks for
cli_malloc/cli_calloc/cli_realloc/malloc/calloc/realloc
Some of the reactions may not be wholly apropriate but are certainly no
worse than a segfault?
Joe
Only in clamav-devel.jm-pl4: autom4te.cache
Only in clamav-devel.jm-pl4: backup-051220042311-pre-clamav-devel.jm-
James Courtier-Dutton wrote:
Jakub Jankowski wrote:
I searched for "virus naming" and found what I wanted, on both
clamav-users and clamav-devel lists
s.
I am an open source developer, and I think that clamav is not very
user friendly with the naming of viruses.
I have read a majority of the
This fixes some logging wording.
--- clamav-devel-jm0/clamd/scanner.cTue May 11 06:10:52 2004
+++ clamav-devel-jm1/clamd/scanner.cTue May 11 06:54:13 2004
@@ -344,11 +344,11 @@
switch(retval) {
case 0: /* timeout */
- mdprintf(odesc, "Accept timeout ERROR\n");
-
Hello All,
I have been seeing some work go into CVS on streammaxlength.
However there are still some things I dont understand about the current
approach.
I have enclosed a newly created against clamav-milter 0.70-x patch which
I have been using in various form since 0.70 was released with good
Tomasz Kojm wrote:
On Thu, 29 Apr 2004 07:37:25 -0400
Joe Maimon <[EMAIL PROTECTED]> wrote:
Could we maybe consider doing it this way?
This patch fixes clamd to stop after reading EXACTLY up to
streammaxlength. After reaching streammaxlength, whatever has been
received up to that po
Frederic Olivie wrote:
On Friday 30 April 2004 2:52 pm, Frederic Olivie wrote:
Hi,
I'm new to clamav. I have one simple suggestion (though maybe not that
simple to implement :-)).
Would it be complex to add another field to the virus DB that could hold
the known name of a virus ?
O
Frederic Olivie wrote:
Hi,
I'm new to clamav. I have one simple suggestion (though maybe not that
simple to implement :-)).
Would it be complex to add another field to the virus DB that could
hold the known name of a virus ?
If there was a known name of the virus than an additional field
Joe Maimon wrote:
Hello,
Hope I am not beating a dead horse. I seem to recall being told that
this would be considered after 0.70
Now that 0.70 is out, and counting bytes we send to clamd is the in
thing todo.
Could we maybe consider doing it this way?
This patch fixes clamd to stop after
Hello,
Hope I am not beating a dead horse. I seem to recall being told that
this would be considered after 0.70
Now that 0.70 is out, and counting bytes we send to clamd is the in
thing todo.
Could we maybe consider doing it this way?
This patch fixes clamd to stop after reading EXACTLY up to
in clamfi_envfrom()
--
n_children++;
cli_dbgmsg(">n_children = %d\n", n_children);
pthread_mutex_unlock(&n_children_mutex);
if(rc == ETIMEDOUT) {
#ifdef CL_DEBUG
if(use_syslog)
A couple days ago, I had clamav-milters that were timing out.
My sendmail logs looked like this:
Apr 27 04:25:50 nameserver2 clamav-milter[4431]: ClamAv: private data
not NULL
Apr 27 04:25:50 nameserver2 clamav-milter[4417]: ClamAv: private data
not NULL
Apr 27 04:25:52 nameserver2 clamav-milte
in clamav-milter.c updateSigfile()
cli_realloc(signature, statb.st_size);
read(fd, signature, statb.st_size);
close(fd);
return from cli_realloc is discarded, and realloc may change the address
of memory block.
---
This SF.N
Trog wrote:
On Wed, 2004-04-28 at 12:46, Joe Maimon wrote:
I suppose by having thrmgr_destroy(thr_pool); wait for all worker
threads to finish?
Yes.
If a thread refused to finish at that time would thrmgr_destroy not
return and clamd stop doing any more work even after accepting
clamfi_cleanup would get called)
Joe Maimon wrote:
So this morning clamd hung up. But then to add insult to injury
max-children of clamav-milter piled up behind it like a car wreck. This
patch adds the argument --max-child-wait=, which works like this.
* -1 wait 60 seconds for max_children an
Trog wrote:
On Wed, 2004-04-28 at 12:14, Joe Maimon wrote:
It would make sense to suppose that steps were taken to ensure there was
only one thread executing reload_db with do_check == FALSE ?
It would make sense, which is why it is currently implemented that way.
-trog
I
Trog wrote:
On Wed, 2004-04-28 at 11:01, Joe Maimon wrote:
Because the 'reload_mutex' mutex protects the variable 'reload'. Thats
all.
Ok. Thank you.
I was looking at this because clamd hung up on me right after logging
"No stats for Database check - forci
was hoping you would explain with a drop more detail what I seem to be
missing here.
Joe
Trog wrote:
On Tue, 2004-04-27 at 16:34, Joe Maimon wrote:
Hello All,
In clamd/server-th.c why do we not wait to call pthread_mutex_unlock
until after reload_db?
Because the 'reload_mutex'
Trog wrote:
On Tue, 2004-04-27 at 16:34, Joe Maimon wrote:
Hello All,
In clamd/server-th.c why do we not wait to call pthread_mutex_unlock
until after reload_db?
Because the 'reload_mutex' mutex protects the variable 'reload'. Thats
all.
You mean it doesnt prote
Hello All,
In clamd/server-th.c why do we not wait to call pthread_mutex_unlock
until after reload_db?
ALSO: Isnt this a call to pthread_mutex_unlock after its already unlocked?
pthread_mutex_lock(&reload_mutex);
if(reload) {
reload = 0;
pthread_mutex_unlock(&
<>I wrote this patch because I kept getting virus emails quarantined by
amavisd (after passing through clamav-milter) which were not recognized
as RFC822 mail files.
They are not recognized because their headers are mxed up a bit. For
instance the messages can start with Date: or To: or any othe
I have setup a small page for all my (updated) clamav patches for
purposes of convenience.
http://www.jmaimon.com/clamav
(still running ok)
I will stop harassing you all now about this.
Joe Maimon wrote:
>These patches
---
This SF.Net em
Joe Maimon wrote:
These patches
* clamd scans up to streammaxlength
* clamav-milter does not send more than streammaxlength (by way of
making clamfi_send track bytes sent) only if not using quarantine option
* paranoid checking is performed for all memory allocations by way of
using a macro
These patches
* clamd scans up to streammaxlength
* clamav-milter does not send more than streammaxlength (by way of
making clamfi_send track bytes sent) only if not using quarantine option
* paranoid checking is performed for all memory allocations by way of
using a macro which when called in a
Is this a problem and should it concern me in anyway?
(null-milter is the sample milter with everything except return
SFSI_CONTINUE stripped out)
Sorry for wrapping
Sendmails:
root 5002 0.2 0.6 7120 3584 ?S08:34 0:00
sendmail: i3KCYak
root 743 0.0 0.6 6836 3496 ?
In cvs head...
I see in clamav-milter.c
snprintf(reject, sizeof(reject) - 1,
According to man 3 printf
snprintf and vsnprintf do not write more than size bytes (including the
trailing '\0'),
Also
In libclamav/others.c:
void *cli_malloc(size_t size)
{
void *alloc;
alloc = malloc(si
Joe Maimon wrote:
I see in CVS we are now tracking number of bytes written to clamd
socket. It would probaly be a whole lot easier (and more accurate) if
clamfi_send actualy returned number of bytes written or -1 on error.
Additionaly clamfi_send can potentialy write less than the user
I see in CVS we are now tracking number of bytes written to clamd
socket. It would probaly be a whole lot easier (and more accurate) if
clamfi_send actualy returned number of bytes written or -1 on error.
Additionaly clamfi_send can potentialy write less than the user expects
with truncation ha
Antony Stone wrote:
On Wednesday 31 March 2004 10:33 pm, Sergey wrote:
Hello.
I think produce to discussion some patch.
All your suggestions assume that ClamAV is running in combination with
sendmail (and, perhaps, combined in a very particular way).
which is generaly a valid assu
I saw the below patch in cvs. I just want to point out that I dont think
will work.
A) len will typically be a "chunk" of size MILTER_CHUNK_SIZE (65535)
B) sendmail libmilter calls the xxfi_body callback once for each chunk
of body
C) clamfi_send should only be called if len > 0 and from then on
31 matches
Mail list logo
