cronie bug in centos 6

Recently tried to redirect all output from crontabs to syslog, instead of mail with ‘-s’ param on CentOS 6.3, but was observing some trash in syslog. Looked into cronie code and found stupid bug, that was there for several years:

while (EOF != (ch = getc(in))) {
bytes++;
if (mail)
putc(ch, mail);
}
#if defined(SYSLOG)
# WE ARE NOT IN WHILE LOOP HERE!
if (SyslogOutput) {
logbuf[bufidx++] = ch;
if ((ch == '\n') || (bufidx == sizeof(logbuf)-1)) {
if (ch == '\n')
logbuf[bufidx-1] = '';
else
logbuf[bufidx] = '';
syslog(LOG_INFO, "%s", logbuf);
bufidx = 0;
}
}
#endif


Centos, (or even Redhat, I suppose the code in RHEL is the same) do you have some basic tests? Argh… This was fixed in cronie-1.4.8 more than a year ago, but still not in RHEL.

Advertisements

Science article generator

English version below

Генератор научных статей. Вводим автора(ов) нажимаем generate и у нас статья с картинками, формулами, графиками. Я ввел
Edward Lee и получил “802.11B Considered Harmful”, что вполне забавно.


Science article generator. Type author(s) click generate and you will get article with pictures, formulas, charts. I have typed Edward Lee and got “802.11B Considered Harmful”, that seems pretty funny.

DJBX33A collisions

(English version below)

Прочитал новость о коллизиях в реализациях хэш функций в php/python/ …
Как пишут в статье “PHP realistically: 500k of POST → 1 minute” и не поверил, что в действительности так. Нашел коллизии для DJBX33A, создал файл на 1.0MB с 27k записей, проверил на сервере. POST запрос выполняется на одном ядре современного серверного процессора 50(!) секунд. Не оптимальный POST, есть как уменьшить, но я на этом остановился. Проверил несколько своих сайтов с бекендом на PHP, дружно ложаться… Ограничил POST на 100Кб, но это не решение. Ждем когда сделают рандомизацию хэш функции.


Read the news about collisions in hash functions of php/python/… As it was said in the article “PHP realistically: 500k of POST → 1 minute” and didn’t believe it, that it is really so. Found collisions for DJBX33A, created 1Mb file with 27k records, tested on the server. POST request is executed on one core of modern server CPU for 50(!) seconds. It’s not the optimal POST, can be smaller, but I stoped with that. Tested some of my sites with PHP backend, all are going down… Limited POST for 100Kb, but that’s not the solution. Will wait for hash function randomisation.