OpenBSD 7.7

нет регулярного регрессионного и fuzzy тестирования

Тесты есть, кому надо, может прогонять сам. Не Тео же за электричество платить.

Багрекера тоже нет, описание комитов в огромном количестве случаев выглядит как «я сделаль»

И как это мешает процессу? Ответ, никак. Всем причастным это не нужно. Ты еще скажи что у них там жиры нет.

Тесты есть, кому надо, может прогонять сам. Не Тео же за электричество платить.

Ты только что про правильные практики что-то говорить пытался. «Кто-нибудь однажды запустит тесты» это не процесс. Да и качество тестов неизвестно. Я подозреваю что code coverage тоже нет, поэтому неизвестно, что вообще покрыто.

И как это мешает процессу? Ответ, никак. Всем причастным это не нужно. Ты еще скажи что у них там жиры нет.

Это мешает отслеживать проблемы и верифицировать их решение. Что уже не один раз в рассылке было: баг принесли, его как-то починили, починили не до конца / породили что-то в процессе починки, на круг. Хуже, если репортер не ответил и воспроизвели через пять лет.

По остальным пунктам тебе уже ответили, добавлю только, что линуксом пользуется больше людей и корпораций, так что и тестирование в боевых применениях у него гораздо более всеобъемлющее. Не говоря уже о современных методологиях тестирования самими разрабами.

Культура кода это хорошо, но на ней одной далеко не уедешь.

Культура кода это хорошо, но на ней одной далеко не уедешь.

Проблема в том что «у OpenBSD хорошая культура кода» это, по ходу, ещё один миф. У них полно копипасты, код с использованием imsg() абсолютно хаотично написан (а это основной IPC в их новых privsep демонах), проверка граничных условий принятых сообщений написана где повезет, понять стейт-машину удается исключительно в силу врожденного аутизма. Где в этом «культура кода» я не понимаю.

Кстати, если уж говорить о культуре кода, то современные линуксовые проекты написаны на очень высоком уровне. Например, тот же systemd, код которого хейтеры никогда не открывали. Я недавно лазил туда за обработкой хоткеев и без труда нашел нужную функцию, причем написано всё очень аккуратно и без кулхакерства. Libinput тоже - я не до конца разделяю их подход к отсутствию настраиваемости, но там тоже всё достаточно неплохо написано.

причем написано всё очень аккуратно и без кулхакерства

Странное слово, я думаю многие не согласятся, если увидят этот кусок из systemd:

#define  CASE_F_1(X)	  case X:
#define  CASE_F_2(X, ...) case X:  CASE_F_1( __VA_ARGS__)
#define  CASE_F_3(X, ...) case X:  CASE_F_2( __VA_ARGS__)
#define  CASE_F_4(X, ...) case X:  CASE_F_3( __VA_ARGS__)
#define  CASE_F_5(X, ...) case X:  CASE_F_4( __VA_ARGS__)
#define  CASE_F_6(X, ...) case X:  CASE_F_5( __VA_ARGS__)
#define  CASE_F_7(X, ...) case X:  CASE_F_6( __VA_ARGS__)
#define  CASE_F_8(X, ...) case X:  CASE_F_7( __VA_ARGS__)
#define  CASE_F_9(X, ...) case X:  CASE_F_8( __VA_ARGS__)
#define CASE_F_10(X, ...) case X:  CASE_F_9( __VA_ARGS__)
#define CASE_F_11(X, ...) case X: CASE_F_10( __VA_ARGS__)
#define CASE_F_12(X, ...) case X: CASE_F_11( __VA_ARGS__)
#define CASE_F_13(X, ...) case X: CASE_F_12( __VA_ARGS__)
#define CASE_F_14(X, ...) case X: CASE_F_13( __VA_ARGS__)
#define CASE_F_15(X, ...) case X: CASE_F_14( __VA_ARGS__)
#define CASE_F_16(X, ...) case X: CASE_F_15( __VA_ARGS__)
#define CASE_F_17(X, ...) case X: CASE_F_16( __VA_ARGS__)
#define CASE_F_18(X, ...) case X: CASE_F_17( __VA_ARGS__)
#define CASE_F_19(X, ...) case X: CASE_F_18( __VA_ARGS__)
#define CASE_F_20(X, ...) case X: CASE_F_19( __VA_ARGS__)

#define GET_CASE_F(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,_11,_12,_13,_14,_15,_16,_17,_18,_19,_20,NAME,...) NAME
#define FOR_EACH_MAKE_CASE(...) \
        GET_CASE_F(__VA_ARGS__,CASE_F_20,CASE_F_19,CASE_F_18,CASE_F_17,CASE_F_16,CASE_F_15,CASE_F_14,CASE_F_13,CASE_F_12,CASE_F_11, \
                               CASE_F_10,CASE_F_9,CASE_F_8,CASE_F_7,CASE_F_6,CASE_F_5,CASE_F_4,CASE_F_3,CASE_F_2,CASE_F_1) \
                   (__VA_ARGS__)

Тю, с макросами всегда жопа, в сях от этого никуда не деться.

Как то я решил насладится прекрасным OpenBSD кодом о котором я так много слышал, через специальный скрипт который открывает рандомный файл, я впервые увидел вот этот кусок из случайного приложения, которому понадобилось разобрать url. По другому взглянул на npm помойки!

/*
 * Retrieve URL, via the proxy in $proxyvar if necessary.
 * Returns -1 on failure, 0 on success
 */
static int
url_get(const char *origline, const char *proxyenv, const char *outfile, int lastfile)
{
	char pbuf[NI_MAXSERV], hbuf[NI_MAXHOST], *cp, *portnum, *path, ststr[4];
	char *hosttail, *cause = "unknown", *newline, *host, *port, *buf = NULL;
	char *epath, *redirurl, *loctail, *h, *p, gerror[200];
	int error, isftpurl = 0, isredirect = 0, rval = -1;
	int isunavail = 0, retryafter = -1;
	struct addrinfo hints, *res0, *res;
	const char *savefile;
	char *pathbuf = NULL;
	char *proxyurl = NULL;
	char *credentials = NULL, *proxy_credentials = NULL;
	int fd = -1, out = -1;
	volatile sig_t oldintr, oldinti;
	FILE *fin = NULL;
	off_t hashbytes;
	const char *errstr;
	ssize_t len, wlen;
	size_t bufsize;
	char *proxyhost = NULL;
#ifndef NOSSL
	char *sslpath = NULL, *sslhost = NULL;
	int ishttpsurl = 0;
#endif /* !NOSSL */
#ifndef SMALL
	char *full_host = NULL;
	const char *scheme;
	char *locbase;
	struct addrinfo *ares = NULL;
	char tmbuf[32];
	time_t mtime = 0;
	struct stat stbuf;
	struct tm lmt = { 0 };
	struct timespec ts[2];
#endif /* !SMALL */
	struct tls *tls = NULL;
	int status;
	int save_errno;
	const size_t buflen = 128 * 1024;
	int chunked = 0;

	direction = "received";

	newline = strdup(origline);
	if (newline == NULL)
		errx(1, "Can't allocate memory to parse URL");
	if (strncasecmp(newline, HTTP_URL, sizeof(HTTP_URL) - 1) == 0) {
		host = newline + sizeof(HTTP_URL) - 1;
#ifndef SMALL
		scheme = HTTP_URL;
#endif /* !SMALL */
	} else if (strncasecmp(newline, FTP_URL, sizeof(FTP_URL) - 1) == 0) {

Как много говорят о том что BSD это цельная операционная система, не то что Linux. Но библиотеку для url они сделать не догадались.

Да, там довольно много такого. С одной стороны у них много хороших идей (типа vmctl send / vmctl recv по SSH), с другой вот такая срань там просто на каждом шагу.

P.S. Правда с OpenSSH есть проблема, он тормозит как сучка, поэтому VM через него передавать тоже небыстро :(

Ладно, тут всё в одну гигафункцию упихано, хотя это уже само по себе трешак. Зачем они при таком подходе все переменные в начале функции объявляют? У некоторых структур при этом инициализация есть, у других - нет. Безопаснее объявить по месту использования, а еще лучше - запихнуть в скоуп {}, чтобы не перепутать ее с чем-то другим.

Лучше, конечно, попилить этот хлам на подфункции, но, видимо, это недостаточно безопасно.

Ты только что про правильные практики что-то говорить пытался.

Ты перепутал «общепринятые» практики с «правильными». И вот по правилу «толпу всегда на*вают», «общепринятые» как минимум не стоит за эталон принимать.

Ты перепутал «общепринятые» практики с «правильными». И вот по правилу «толпу всегда на*вают», «общепринятые» как минимум не стоит за эталон принимать.

Нет, извините, это так не работает. Нельзя сказать «в OpenBSD очень классные практики разработки», если их там нет. Ну или приведи нам список процессов, который помогает OpenBSD быть лучше других. Пока что мы нашли список отсутствующих процессов, который объективно мешает им проводить нормальный QA.

если их там нет.

Мнение одного «эксперта» поскипано. Следующий

Мнение одного «эксперта» поскипано. Следующий

То есть их нет, ты их выдумал?

Ладно, тут всё в одну гигафункцию упихано, хотя это уже само по себе трешак.

Нет, разрабу так удобней. Ты найди там ошибки, вот тогда поговорим.

Зачем они при таком подходе все переменные в начале функции объявляют?

читаем стандарт C89.

То есть их нет, ты их выдумал

То есть их там есть, но тебе не познать, расслабся уже.

То есть их там есть, но тебе не познать, расслабся уже.

Если ты не можешь привести список из пяти пунктов, значит их там нет. А ты пока не смог.

Если ты не можешь привести список из пяти пунктов

А мне больше делать нечего?

читаем стандарт C89.

Зачем? Актуальный C23.

Актуальный C23

Выдыхай

Выдыхай

C23, formally ISO/IEC 9899:2024, is the current open standard for the C programming language

А мне больше делать нечего?

Ну как бы да, ты же в тему пишешь. Пишешь некоторое утверждение, вместо обоснования начинаешь жопой вращать, не переставая писать в тему. Раз пишешь, значит время есть. А вот пруфов – нет.

Зачем они при таком подходе все переменные в начале функции объявляют?

Мне, кстати, тоже больше нравится переменные в начало класть. Как раз по этой причине. Если их становится слишком много – значит пора функцию разбивать.

Долгих лет жизни проекту. ЗЫ: Ха ха, сколько же jоп порвалось!

читаем стандарт C89

Это что за смузихлебство? Типы прямо в аргументах указываешь небось?

Нет, разрабу так удобней. Ты найди там ошибки, вот тогда поговорим.

Да, это трешак. Любая модификация такой лапши превращается в занятие с повышенным риском ошибки. Функция должна иметь минимальный размер и делать что-то одно, осмысленное, а не вот это вот всё. Бывают исключения, Но это не тот случай.

читаем стандарт C89

Во-первых, согласно оному стандарту можно обсудить переменные в начале блока, а не функции. Во-вторых, ты не понял сути вопроса.

Упрощу: в чем сакральный смысл следования древнему стандарту? Почему не C99, например? Чтобы что?

Я кладу переменные по месту использования, потому что их можно обмазать const-ами из параноидальных соображений. А с правилом и так управлюсь :)

Может там код из 90-х. Или кодеры живут в вечных 90-х. Хотя я видел и такое, что молодежь не знает про C89, а все равно выносят объявления в начало функции. И не только в C кстати. Может их так учат преподы паскале-утята, не знаю.

описание комитов в огромном количестве случаев выглядит как «я сделаль»

Тут я понял что так и коммичу в основном 😂

Тут я понял что так и коммичу в основном 😂

Коммитируй лучше!

• Поставь на другой комп FreeBSD, настрой там ZFS и прокинь NFS через IPsec! Только так! Иначе ты лалка анскильная!

ZFS на OpenBSD можно легко получить даже в гостевой виртуалке:

1. Раздаём локальные блочные устройства на хосте OpenBSD по iSCSI

2. Получаем блоки для ZFS в гостевой через iSCSI

3. В гостевой виртуалке можно запускать любую ось с поддержкой ZFS, хоть линь, хоть фряху и раздавать ZFS обратно на хост через NFS или опять iSCSI.

В результате получим на OpenBSD хосте новые виртуальные блочные устройства или NFS каталоги с очень хорошей сохранностью данных, намного лучше, чем в родной FS OpenBSD. В таких подмонтированных FS можно хранить, например, свои уникальные скрипты и проектные данные, вероятность их потери из-за сбоя FS околонулевая.

А если что-то потеряется в остальной системной части родной файловой системы OpenBSD (,что маловероятно потому что в основном читается большую часть времени), то это легко переставить заново.

У них нет публичного code review,

The OpenBSD project doesn't use many of the web-based code review tools common in other projects, preferring their established email-based workflows.

регрессионного и fuzzy тестировани

https://man.openbsd.org/bsd.regress.mk.5

?

Багрекера тоже нет, поэтому никто не знает не пропустили ли они какой-то критичный багрепорт.

https://marc.info/?l=openbsd-bugs

The OpenBSD project doesn’t use many of the web-based code review tools common in other projects, preferring their established email-based workflows.

Это не связанные вещи. В Linux Kernel тоже email-based workflow, но там логи обсуждения публичные. Здесь же большая часть обсуждений происходит где-то в непубличных местах и наружу не попадает.

https://man.openbsd.org/bsd.regress.mk.5

И? То что у них есть директория с тестами не означает, что у них есть тестирование. Насколько покрыты кодовые пути? Адекватны ли тестовые кейсы? Как проходит тестирование железа? Этого ничего нет. Ровно та же срань, что в линуксе.

https://marc.info/?l=openbsd-bugs

И? Это не баг-трекер, это рассылка. Ты даже не знаешь закрыт тикет или нет, надо перечитать весь тред и пытаться понять по комментариям решена там проблема или нет.

Ровно та же срань, что в линуксе.

А какую безопасную ось ты предлагаешь в качестве более удачной замены OpenBSD, например, хотя бы на роутерах периметра и ssh endpoints (терминалы, бастионы и т.п.)?

Лялекс. Если хватило гуглу, хватит и тебе.

Сколько надо потратить сил и времени, чтобы сделать Лялекс таким же безопасным как OpenBSD в базовой поставке ?

У Google есть достаточно времени, да.

Но есть ли оно у среднестатистического *nix админа?

Сколько надо потратить сил и времени, чтобы сделать Лялекс таким же безопасным как OpenBSD в базовой поставке ?

По каким критериям ты сравниваешь и оцениваешь безопасность?

ZFS на OpenBSD можно легко получить даже в гостевой виртуалке:

<описание пердолева>

А зачем всё это пердолево, если, как выше указали, можно поставить Linux и не пердолиться? Чтобы что?

Я вот сравнительно недавно спрашивал как сделать в OpenBSD аналог MANGLE из люнексового Netfilter, так оказалось, что специально разрабатываемая для сетевых роутеров ОС даже этого не умеет. Нахрен так вообще жить-то?

Хотя бы чтобы самостоятельно не собирать статическое Linux ядро без подгружаемых руткитов?

## OpenBSD Security Features in Debian

### Available in Debian:

1. **W^X (Write XOR Execute)**
   - Available in Debian via NX bit/DEP protection
   - Not as strictly enforced as in OpenBSD by default
   - Can be strengthened with additional hardening

2. **ASLR (Address Space Layout Randomization)**
   - Available but less aggressive by default
   - Can be enhanced via sysctl settings (`kernel.randomize_va_space`)
   - Default setting is not as comprehensive as OpenBSD's implementation

3. **Stack Smashing Protection**
   - Available via GCC's `-fstack-protector` options
   - Modern Debian builds use `-fstack-protector-strong` by default
   - Not as universally applied to all packages as in OpenBSD

4. **Privilege Separation**
   - Implemented in many daemons but not as comprehensively
   - Depends on individual package maintainers' implementations
   - Can be strengthened with proper configuration

### Not Available in Debian:

1. **Pledge and Unveil**
   - These are OpenBSD-specific features not available in Linux/Debian
   - Linux has seccomp-bpf and namespaces which serve similar purposes but require more complex implementation
   - No direct equivalents with the same ease of use

2. **OpenBSD's Secure Memory Allocator**
   - Debian uses standard malloc implementations
   - Can use alternatives like Hardened_malloc but requires manual installation and is not the default

3. **LibreSSL**
   - Debian uses OpenSSL by default
   - LibreSSL is available in repositories but not the default

Debian can be hardened significantly through manual configuration and additional packages, 
but the integration and default enablement of security features in OpenBSD remains more comprehensive
 without requiring additional configuration.

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

Интересующимся предлагаю почитать: https://www.reddit.com/r/openbsd

Очень много интересных обсуждений.

Хотя бы чтобы самостоятельно не собирать статическое Linux ядро без подгружаемых руткитов?

Каких подгружаемых руткитов? Ты про ядерные модули? То, что OpenBSD их не умеет, это не преимущество.

То, что OpenBSD их не умеет, это не преимущество.

С точки зрения безопасности?

отсутствие контейнеров,

https://www.reddit.com/r/openbsd/comments/1jwqs1r/why_has_openbsd_not_embraced_freebsd_jails/

Представь, в OpenBSD нет даже Kubernetes, какая печаль !

Но всё же OpenBSD идеально подходит в качестве текстового терминала для управления Talos Linux-ом и Кубером.

То есть, не то что бы очень много отличий. И технически тебе ничего не мешает сделать из линукса то же самое.

А если начать сравнивать в другую сторону? Как на счет cgroups, не говоря уже об selinux?

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

В линуксе тоже так можно, просто мало кому нужно. Чтобы руткит подгрузить, сначала надо получить рута. А если ты получишь рута на openbsd - то шороху и так в системе наведешь.

OpenBSD is really about Security by Correctness (the software you run is trusted)

А если correctness провалилась, то упс.

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

не говоря уже об selinux?

pledge/unveil?

В линуксе тоже так можно, просто мало кому нужно.

Но в OpenBSD это «из коробки», да ещё и с рандомной перелинковкой при каждом ребуте.

Чтобы руткит подгрузить, сначала надо получить рута. А если ты получишь рута на openbsd - то шороху и так в системе наведешь.

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

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

А в OpenBSD нет разграничения прав?

В OpenBSD есть довольно мощная система разграничения прав, которая является одной из ключевых особенностей этой операционной системы, ориентированной на безопасность. OpenBSD предлагает несколько механизмов разграничения прав:

1. Традиционная UNIX-модель прав доступа с правами на чтение/запись/исполнение для владельца, группы и остальных

2. Расширенные атрибуты файлов (флаги) через команду `chflags`, которые позволяют устанавливать дополнительные ограничения на файлы

3. Системный механизм `pledge`, который ограничивает системные вызовы, доступные процессу

4. Механизм `unveil`, который ограничивает доступ процесса к файловой системе

5. Chroot-окружения для изоляции программ

6. Механизм сетевой фильтрации PF (Packet Filter)

7. Контроль ресурсов через механизм `login.conf`

OpenBSD уделяет особое внимание безопасности, и система разграничения прав в ней считается одной из самых строгих и хорошо продуманных среди Unix-подобных операционных систем.

Во-первых, согласно оному стандарту можно обсудить переменные в начале блока, а не функции.

А там и дальше переменные по блокам объявлены еще %) Видимо скроллить кому то надоело.

pledge/unveil?

До selinux не дотягивает.

Но в OpenBSD это «из коробки», да ещё и с рандомной перелинковкой при каждом ребуте.

Проблема исключительно в коробке, я так понимаю? Если ты специалист по ИБ, то все равно будешь собирать ОС под свои нужды. А учитывая, что у линукса больше пользовательская база (в том числе среди корпораций), то он лучше оттестирован. Так что, потратив на линукс чуть больше времени, ты получишь более безопасную ОС.

А в OpenBSD нет разграничения прав?

Это всё концепции столетней давности, дубовые и топорные, по сравнению с тем, что уже давно есть в линуксе.

Кстати, элементы твоего текста вообще не гуглятся. Ты это из нейронки достал?

Сколько надо потратить сил и времени, чтобы сделать Лялекс таким же безопасным как OpenBSD в базовой поставке ?

Я тебе уже говорил; у нас нет данных, насколько в реальности безопасна openbsd, потому что нет достаточного количества ищущих баги. Есть ценник на эксплоиты и он не отличается от фрибсд.

landlock. Но если мы говорим про роуер, то если кто-то получил шелл, то ты уже проиграл.

Если ты специалист по ИБ, то все равно будешь собирать ОС под свои нужды.

Преимущество OpenBSD как раз для неспециалистов в ИБ?