Pavel Gulchouck писал(а) Ivan Agarkov в 10:03 18 янв 14
PG> Да, обычный tcp в таком случае делается утилитой netcat. PG> Hо раз уж оно уже реализовано, отламывать смысла не вижу.
В принципе с т.з. софта - что exec() что call(main(...)) - все едино, поэтому можно просто подключать так, как будто это shared library. Заодно механизм плагинов будет например :-) Hу это касается binkd конечно, у меня вообще свой огород.
IA>> Проблема в том что ssh мы не контролируем. Ключи мы тоже не IA>> контролируем те, которые ssh генерит. И подписать их никак не IA>> можем например централизованно. А так - да, ssh это хорошо :-)
PG> Если хочется централизованно подписывать, тогда вместо ssh нужно PG> что-то другое. Сходу не скажу - надо подумать/поискать. Распространять PG> - если нодлист не подходит, то есть ещё DNS.
Давно придумали: pgp key server называется. А подписывать на key-sign встречах, как и в pgp мире.
PG> То есть, не просто "обновил мейлер - получил ssl", а несколько PG> сложнее. Впрочем, генерировать/подписывать/распространять ключи ведь PG> всё равно нужно будет вручную.
В общем что в итоге-то? Запилить rsa не так сложно, основное - разработать стандарт и вписать его внутрь binkp как extension.
Кстати еще один минус - binkp over <ssh/icmp/etc> работает через пайп и соответственно не имеет возможности фоллбека на обычный tcp в случае факапа. Своя реализация SSL втыкается как extension, аля startssl. Удаленный узел не понял - ну и хер с ним - ок, откатываемся на обычное соединение. В случае пайпа такое не получится - соединение просто не установится в случае, если на второй стороне пайп как-то по-другому сделан.