hi all, I am working on the next sec release and would like get some feedback from end users, since I've implemented some changes in the beta code of the next release.
Previous versions of sec have ignored the PIPE signal in specific parts of the code (such as functions which write to tcp and udp sockets). Unfortunately, this still leaves the danger of getting this signal when it is not expected. For example, if sec is not running as a daemon and its standard error is connected to pipe, an unexpected perl warning will produce SIGPIPE if the reader has disappeared on pipe. In the new release, PIPE signal is ignored globally in all parts of the code. Would that change be ok with the users? (SIGPIPE handler is set back to default when child processes are forked.) Another change involves the creation of child processes for the 'pipe' action. Previous versions of sec used the Perl pipe open for forking a process: open(PIPE, "| cmd"). Also, the exit code of the child process was collected with blocking close(PIPE). Unfortunately, when the child process receives the TERM signal which interrupts blocking close() and calls exit(), recent Perl versions produce a warning "refcnt: fd -1 < 0", since exit() calls close() for the second time for pipe descriptor. In order to avoid this warning, the 'pipe' action is now implemented through lower level calls to pipe(), fork(), exec() and waitpid(). Are there any special considerations while someone might still prefer a higher level pipe open? I am also considering raising the default value for the --blocksize option (it is currently 1024 which means that sec attempts to read from input files by 1KB blocks). Are there any objections if the default is raised to 8KB or 16KB? Finally, while most users are letting sec to load its rule files as US ASCII data, there might still be cases when unicode IO is activated for sec (e.g., with env PERL_UNICODE=SAD /usr/bin/sec --conf=test.rules ...).Previous versions of sec have used the \d regular expression construct for verifying the numeric rule fields, but this passes other characters than just 0-9, since with unicode exotic digit symbols also match \d. However, usually they don't receive proper interpretation and perl converts them to just 0. To prevent the accidental use of such exotic digits, \d has been exchanged for [0-9] which only matches meaningful numerals. Can anyone think of possible caveats here? (Characters 0..9 are adjacent in both ascii and ebcdic and thus the list [0-9] covers all ten digits for them, but can anyone recall some exotic character sets where this is not the case?) kind regards, risto ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
