commit 1b0f1870efa0ad039d113262f48a7df04bf4c51f from: Aleksey Ryndin date: Sun Sep 22 11:20:30 2024 UTC Fix: /vostok/reports/0.2.1.gmi commit - a46f2c1c8756ac69a39853a9b137ebf1134959f6 commit + 1b0f1870efa0ad039d113262f48a7df04bf4c51f blob - 5d0e14500f51eee32a246c9979bba09f40d3aa9d blob + 225cad3b511302930c4c034a443c90b3a09791aa --- capsule/atom.xml +++ capsule/atom.xml @@ -8,7 +8,13 @@ continue continue@to.any-key.press - 2024-09-19T15:56:18.478961+00:00 + 2024-09-22T11:15:05.408058+00:00 + + gemini://any-key.press/vostok/reports/0.2.1.gmi + + vostok 🚀 0.2.1: VGI_CERT_HASH, bugfix + 2024-09-22T11:15:05.408058+00:00 + gemini://any-key.press/python/python3.11-tools.gmi blob - ddccde4f25c2e318edf41b9cf11e4a5ec1663227 blob + fc2e35cf4e32cee3eb448bcbb243bba4346443e0 --- capsule/vostok/reports/0.2.1.gmi +++ capsule/vostok/reports/0.2.1.gmi @@ -1,14 +1,22 @@ # vostok: сервер Gemini, версия 0.2.1 -TBD +Активное тестирование VGI с одной стороны увеличило аппетит: захотелось иметь возможность авторизации. А с другой стороны вскрылась небольшая проблема для крайнего случая обработки ошибочных ситуаций. Всё это решено в gemini сервере vostok версии 0.2.1. => 0.2.0.gmi Предыдущая запись блога разработки Что нового в версии 0.2.1: -* VGI_CERT_HASH -* BugFix +* при вызове VGI скрипта добавлена переменная окружения VGI_CERT_HASH, содержащая хэш сертификата клиента; +* поправлено ожидание процесса VGI в случае ошибки передачи данных в gemini клиент. -## VGI_CERT_HASH +## Переменная окружения VGI_CERT_HASH -## BugFix +Для моих новых (пока ещё не анонсированных) проектов мне потребовалась авторизация. Тут грех не воспользоваться тем, что gemini работает по TLS и клиентские сертификаты заложены в спецификацию именно для авторизации. +Весь сертификат (как и его отдельные поля) мне (пока?) не нужен, поэтому при вызове VGI устанавливается переменная окружения VGI_CERT_HASH, которая содержит SHA256 хэш сертификата пользователя. Детали можно найти в описании функции tls_peer_cert_hash: +=> https://man.openbsd.org/tls_peer_cert_hash + +## Исправление вызова ожидания дочернего процесса + +Подойдя более основательно к тестированию VGI я нашёл небольшой баг: если сервер vostok не смог отдать клиенту очередную порцию данных (например функция tls_write вернула ошибку из-за того, что клиент уже закрыл соединение со своей стороны), то не вызывалось ожидание дочернего процесса VGI. В результате дочерний процесс оставался висеть в дерево процессов. + +Исправление достаточно тривиальное, но нужное на длительной дистанции эксплуатирования сервера.