QR код в systemd

[metaclass]

Айсед вынудил таки почитать, что за QR код сунул поттеринг в systemd: http://lwn.net/Articles/512895/

На данный момент то что там описано, для меня выглядит как жуткий security theater:
* 15 минут подписи логов по умолчанию. Это овердохера - аттакер в среднем имеет 7.5 минут чтобы стереть из текущего неподписанного лога свое присутствие
* мутный алгоритм брата поттеринга
* возможность проебать старый ключик в памяти-свопе
* возможность просто нахрен вытереть логи - и вся информация, которая у нас останется это "логи кем-то были стерты".

Comments

[permea-kra.livejournal.com]

А зачем бинарный? Какие у него объективные преимущества?

[develop7]

с бинарным логом объективно проще работать — требуется тупо меньше кода. Но вы не ответили на мой вопрос.

[metaclass.livejournal.com]

А не однохренственно? Любая сериализация/десериализация структурированных данных, что в текст, что в бинарники - проклятая тема. Особенно если заморачиваться хоть какой обратной совместимостью и вообще живучестью формата данных.

[develop7]

А не однохренственно?

с т.з. юзера — да. С т.з. стоимости поддержки и разработки — нет, т.к. текст нужно прочитать, распарсить, десериализовать и только потом с данными что-то делать. И это я молчу про оверхед. Было бы однохренственно, всякие СУБД хранили бы данные в файлах вида

+----+-------+------+----------------------+
| ID | title | body | created_at           |
+----+-------+------+----------------------+
| 1  | arr   | 123  | 2013-12-12T12:34:56Z |
+----+-------+------+----------------------+

Нуачо, самое главное же чтобы читалось нормально, да?

Олсо сложность seeking по plaintext — минимум O(n), по journal — O(log(n)*log(n))…O(n) (зависит от поля, по которому фильтруем).
Export format обратно совместим, JSON обратно совместим. Сам .journal — предположительно нет, и внезапно быть таковым не обязан.

[permea-kra.livejournal.com]

Кода для *кроссплатформенно* сериализованного лога требуется сопоставимо. Для текста есть стандартные инструменты - cat, tail, head, wc, grep, awk, etc. Для бинарного их нет, в лучшем случае есть конвертор, которого может не быть на том, на чем приходится смотреть/анализировать логи.

[develop7]

Кода для *кроссплатформенно* сериализованного лога требуется сопоставимо

откуда вы знаете, если вы так и не привели ни одного примера?

Для бинарного их нет, в лучшем случае есть конвертор

Показательно, что вы по-прежнему не даёте себе труда изучить критикуемый инструмент и вследствие чего несёте чушь. journalctl — не «конвертор в текст», а CLI-обёртка над библиотекой libsystemd-journal, которая как раз и выдирает из логов .journal информацию.

которого может не быть на том, на чем приходится смотреть/анализировать логи.

разве что из политических, а не рациональных соображений — исходники-то открыты

[permea-kra.livejournal.com]

>откуда вы знаете,

Я писал сериализацию-десериализацию ручками.

> journalctl — не «конвертор в текст», а CLI-обёртка

Т.е. вместо простого и понятного конвертора (а еще лучше - просто текстовых логов) предлагается изучать еще одну утилиту. Это ж как надо ненавидеть себя и людей.

>разве что из политических, а не рациональных соображений — исходники-то открыты

Тем не менее, проблема существует.