Кратко

  • RFC 742 сделал строку из одного CRLF стандартным запросом списка всех вошедших пользователей, как минимум с полными именами и по возможности с местом терминала.
  • RFC 1288 сохранил однострочный обмен TCP, но потребовал отвечать либо явно отказывать в общем списке и пересылке, а также рекомендовал настраивать выдачу каждого элемента.
  • Порт 79 согласовал место вопроса. Он не удостоверял человека или ответ, не создавал права на данные и не делал предназначенный для чтения текст безопасным для терминала.

Пустая строка задавала самый широкий вопрос

RFC 742 от 30 декабря 1977 года описывал несколько действий: соединение с сокетом 117 в восьмеричной записи, то есть 79 в десятичной, одна строка с CRLF, произвольный человекочитаемый отчёт и закрытие сервером после вывода.

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

Имя пользователя сужало запрос до одного человека. Ответ мог сообщить текущий вход, последний выход и короткую заметку в специальном файле — plan. В ней оставляли график, поездку, способ связи или сведения о работе.

Исходное сообщество было небольшим. RFC перечислял SAIL, SRI и системы ITS, связывал FINGER Леса Эрнеста с появлением NAME на ITS и называл Эрла Киллиана и Брайана Харви разработчиками протокола. Для знакомых исследовательских групп видимость присутствия помогала координации.

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

Свободный текст не имел общего предела

Finger не устанавливал формат ответа. Системы хранили разные сведения, а результат предназначался человеку. Гибкость позволяла соединить login, имя, терминал, комнату, телефон, shell, каталог, почту и личную заметку.

/W просил больше подробностей. В раннем тексте его называли Whois switch. RFC 1288 поместил токен в начало запроса; последний RUIP мог увеличить подробность или проигнорировать. Дополнительной проверки права на детали не было.

Поиск мог принимать фамилию и полное имя помимо login. Неоднозначное слово давало несколько кандидатов. Помощь человеку, не знающему точную учётную запись, одновременно позволяла перечислять пользователей по частям после отключения общего списка.

Читаемость не означала одинакового измерения. Idle мог считаться от клавиатуры или от активности задания. Отсутствие строки могло означать отсутствие сессии, незнание или сокрытие. Ответ выражал локальный взгляд хоста.

Явный отказ отделил политику от нуля

RFC 1196, опубликованный в декабре 1990 года, опирался на распространённое поведение BSD. Он старался не ломать множество реализаций и прямо называл возврат сведений о пользователях чувствительной задачей.

Через год RFC 1288 исправил место /W, пробелы и порядок закрытия. Остались TCP 79, ASCII, одна строка CRLF, ответ и конец. Изменилась видимость решений.

На пустой {C} сервис обязан был ответить или активно отказать. При ответе он выдавал хотя бы полные имена; администратор должен был выбирать добавление терминала, офиса, телефона, задания и простоя. При отключённом списке хост мог сообщить отказ, а не изображать отсутствие людей.

Пустой список выглядит как факт: пользователей ноль. Отказ описывает правило: сайт не публикует население. Различие не позволяет маскировать приватность под операционное наблюдение.

RFC рекомендовал атомарную выдачу. Один администратор мог открыть домашний телефон и время входа, другой — только офис, третий — минимальное имя. Общая грамматика перестала навязывать общий набор личных данных.

Пересылка давала вопросу чужую достижимость

Q2 допускал цепочку @hostname. Первый RUIP открывал следующее Finger-соединение, передавал остаток запроса и возвращал результат. Произвольного предела числа хостов в грамматике не было.

RFC 1288 требовал либо предоставлять пересылку, либо явно отказывать, и рекомендовал отказ по умолчанию, особенно на шлюзе. Доступный снаружи шлюз мог опросить внутреннюю машину от имени внешнего посетителя.

Посредник не удостоверял автора и не превращал внутренние данные в публичные. Он лишь одалживал достижимость. Все переходы могли быть синтаксически верны и всё же пересечь границу без полномочия.

Поэтому проверяют не только открытые порты, но Q2, конечного ответчика, форму отказа и связь журналов разных участков.

Автор plan не выбирал всю аудиторию

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

RFC 1288 предупреждал, что возврат изменяемого пользователем файла может свободно раздать любые сведения о системе. Добросовестная заметка могла раскрыть внутреннее, злонамеренная — обмануть, а код чтения — опереться на опасные предположения.

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

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

Текст для человека оставался недоверенным вводом

RFC 1288 рекомендовал фильтровать непечатаемые символы по умолчанию и оставлять видимый 7-bit ASCII, tab и CRLF. Escape-последовательности могли изменить имя X Window или вызвать другие терминальные эффекты.

На отправке RFC 742 уже видел обратную проблему: обычный Telnet-клиент мог добавить переговоры IAC и испортить строку Finger. Передача текста не делает скрытые управляющие команды совместимыми.

«Для человека» говорит о читателе, а не о безопасности. Отправитель строит точную строку, получатель отделяет внешние данные от команд интерфейсу.

Безопасный процесс всё ещё мог рассказать лишнее

RFC 1288 ссылался на червя Morris, помещая Finger рядом с Telnet, FTP и SMTP на периметре хоста. Маленькому daemon всё равно нужны защита от искажённого ввода и penetration testing.

Корректный сервер мог быть чрезмерно откровенным. Документ описывал реализацию с последним login, последним чтением почты, непрочитанными письмами и отправителем последнего. Без эксплуатации кода наблюдатель видел разговоры и внимание.

Мало полей также не доказывало надёжность программы. Parser, forwarding, программы и управляющие символы требовали отдельных тестов. Минимизация данных и прочность процесса не заменяли друг друга.

Журнал запросов показывал повторяемые имена, /W и Q2. Одновременно он хранил карту интереса к людям, поэтому нуждался в цели, ограничении доступа и сроке удаления.

IANA сохранила адрес, а не право на сведения

Реестр IANA имён сервисов и транспортных портов содержит finger на порту 79 для TCP и UDP. RFC 1288 определяет TCP. Запись сохраняет общий адрес встречи.

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

Finger возвращал моментальный взгляд хоста на сессии и иногда самоописание. Это не подписанная личность и не административная запись с историей изменений.

Вопрос выжил, потеряв власть по умолчанию

История сложнее перехода от наивности к безопасности. Текст 1977 года уже видел разные форматы и помехи Telnet. Поздние документы сохранили человеческую пользу, но проявили решения вокруг неё.

Общий список остался, но стал отвергаемым. Профиль остался, но настраиваемым. Пересылка осталась, но с отрицательным default. Plan остался, не делая авторство безграничной публикацией. Свободный текст остался, но с фильтром клиента.

Finger не создал приватность автоматически. Он показал, где ею управляют. Порт 79 отвечал, где спрашивать; оператор — что раскрывать; клиент — как показывать. Общая строка не передала никому власть остальных.

Источники и границы

Источники подтверждают историю, грамматику, рекомендации безопасности и регистрацию. Они не измеряют нынешнее развёртывание, частоту атак или политику сайта. Запись IANA не используется как перепись, а поля примеров не приписываются каждой исторической реализации.