MtW>>> Мне хочется передавать фидопочту с одной системы Фидонета на MtW>>> другую систему Фидонета поверх HTTP, сочинив для этой цели MtW>>> специальный веб-сервер и не менее специальный клиент с открытым MtW>>> исходным кодом. AV>> Эта архитектура прямо противоречит основной фиждошной идее о том, AV>> что все участники обмена используют унифицированный набор софта. MW> Разве эта основная фиждошная идея не оказалась поколеблена появлением MW> таких узлов, на которые нельзя позвонить в ZMH, потому что они MW> подключены к Инету?
С чего бы изба-то покосилась? Вот у меня узел отвечает по binkp/tcp - это не мешает мне при необходимости соединиться директом с узлом, который отвечает модемом (хотя и потребует определенных усилий с моей стороны). Точно так же никто не мешает всем желающим соединиться с моим узлом даже через несколько шлюзов с NAT.
MW> Вообще ты это о чём сказал: о том, что наличие HTTP-интерфейса не MW> должно быть предлогом для отказа от протокола binkp на том же узле, MW> или же о том, что binkd должен быть последним в Фидонете протоколом MW> связи узлов, более же него несть человеческому уму разумевати?
О том, что и устанавливать соединение, и принимать оное должна одна и та же программа, в фидошной терминологии традиционно именуемая мейлером.
MtW>>> Может быть, и не только фидопочту передавать, но и дать MtW>>> возможность дистанционного управления системою со стороны её MtW>>> сисопа (чтобы человек мог сочинить новое сообщение эхопочты, MtW>>> не находясь непосредственно за компом фидошной системы, а MtW>>> воспользовавшись своим смартфоном или браузером чужого компа). AV>> Все это уже не первый десяток лет работает через SSH. MW> Однако работает, кажется, на уровне операционной системы, а не MW> фидошной.
Да - это более общее решение, у которого есть неоспоримые преимущества: 1. Его не нужно разрабатывать, ибо оно уже существует. 2. За прошедшие годы там заткнуты практически все дыры. 3. При этом свежеобнаруженные оперативно исправляются.
MtW>>> Как известно, binkd использует код CRC (в тех случаях, когда MtW>>> он не использует SSH), AV>> Для контроля целостности. MW> А заявлено, что для криптования: ^^^^^^^^^^^ Одно только это слово демонстрирует, что использующий оное ни шиша не смыслит ни в шифровании, ни в других криптопреобразованиях.
MW> Криптование включается, если обе стороны предъявили опцию CRYPT MW> [...] MW> реализацию проще посмотреть в исходниках infozip или binkd
Дык это zip crypt - его современные процессоры в реальном времени ломают.
MtW>>> а AMFOW (кажется, чуть ли не единственный ранее существующий MtW>>> мейлер, передающий фидопочту поверх HTTP) использует побайтовый MtW>>> XOR (причём в качестве операнда XOR употребляет MD5-хэш от итога MtW>>> конкатенации секретного пароля сеанса и известного unixtime). AV>> Я одного не понимаю: что мешало сделать классическое гаммирование AV>> с обратной связью по шифротексту? И не на хеш-функции (хотя это AV>> возможно), а на блочном симметричном алгоритме шифрования. MW> Это вопрос не ко мне, это вопрос к Кочарину.
MtW>>> Первым на ум приходит HTTPS (то есть работа HTTP поверх TLS). AV>> Со всеми его болячками, ага... MW> Ты это говоришь так, как если бы они были общеизвестны. А они не MW> общеизвестны. Просвещай, оглашай.
Тут на короткий-то ответ раз в день время находится...
MtW>>> Ещё идеи есть? AV>> | gpg -es AV>> После этого можно передавать бандлы, не заморачиваясь ни AV>> секретностью, ни целостностью, ни достоверностью источника. MW> /system/bin/sh: gpg: command not found MW> (это под Android, например)
