Если речь не про строительство сарая, то формы рисуют художники, а архитекторы как раз придумывают как строить, с учётом всех технических норм. А строители возводят здание по готовому чертежу, сделанному архитектором.
Знание технологий тут — не опция для архитектора, а основа его работы. А в вашем примере задачу архитектора выполняют матерящиеся подрядчики.
Те, для кого linux все еще экзотика, использют mc и соответственно — mceditor
Заменил винду на линукс на основном компе лет 10 назад, пользуюсь mc и mcedit для редактирования всего (в т.ч. кода, вместо IDE), vi использую только когда mcedit недоступен, а emacs когда-то 1 раз попробовал и больше не пытался.
Так что не надо за всех говорить.
Даже более того, этот метод (полагаться на указатель, без самомодификации) широко используется в sh-архивах. Это когда в начале файла скрипт, который сделан так, чтобы шелл читал его до определённого байта (и это работает стабильно и без неожиданностей), а скрипт этот забирает stdin дескриптор себе, читает из него хвост и распаковывает, а затем может выполнить ещё какие-то действия, например для первоначальной настройки только что распакованного софта. Работает не только с файлами но и с пайпами в стиле curl | bash (точнее stdin как раз для второго случая, а в первом альтернативный способ какой-то). Естественно это всё не только для баша а для большинства шеллов.
SFTP — это не новая версия того FTP, а новый протокол с аналогичным функционалом (причём в самой статье выше это было написано).
Оба новых протокола имеют свои плюсы и минусы и выполняют немного разные роли. В тех областях, где необходим именно файловый архив предпочтительнее использовать FTPS, особенно если раньше там уже использовался классический FTP
Нет, плюсы есть только у SFTP, а от FTP и всех его модификаций надо избавляться. Это жуткое легаси, совершенно непригодное в современных реалиях нигде, кроме локальной домашней сети, и костыльная SSL-обёртка не особо что-то меняет. Ну а в домашней сети его лучше тоже не использовать, чтобы не привыкать к плохим вещам.
Я нигде не писал что это портированный линуксовый. Но у него общие с линуксом проблемы в виде неорганизованной и местами некомпетентной разработки, видимо потому что компетентным и организованным разработчикам неинтересно рыться в этой помойке, а писать хорошее с нуля — не хватает ресурсов конкурировать с "массовым" производством.
На пользовательском уровне я могу поставить нормальный WM
Ага, на базе ненормального X11 (да, он появился раньше линукса, но во многом благодаря ему остановился в нормальном развитии и начал обрастать костылями).
Настоящий, "целевой" потребитель Linux-системы сам же является участником ее производства. Это либо разработчик, которому нужен удобный, полностью подконтрольный и полностью им конфигурируемый инструмент, либо компания, которая использует систему в своем производственном процессе чего-то другого для этих производственных нужд.
Это всё сошло бы за аргумент, если бы не было FreeBSD. А там именно система, удовлетворяющая этим критериям, но без вороха всякого разнородного хлама на системном уровне. На пользовательском уровне, увы, то же самое что в линуксе (наверно потому что для десктопа она изначально не предназначалась и он получился побочным образом, просто взяв "готовые" решения).
Надёжность, отсутствие неявного оверхеда, полная предсказуемость в плане двусторонней конвертации C <-> asm (или другими словами, можно рассматривать C как набор синтаксических конструкций для компактного и удобного представления асм-кода, а не для манипуляций компиляторными абстракциями).
Для тех, кто всё это умеет использовать, разумеется, а некоторые могут хоть на пхп пытаться системный софт писать.
DoH-сервер может подменить этот ключ (да, DoH-сервер это третья сторона, а не абстрактная идеальная сущность). Но допустим этого не произошло, и ключ вы получили настоящий.
Если я правильно понял, эта команда проверяет, что SSHFP-запись домена babai.ru подтверждена ключом, полученным на прошлом этапе. Очевидно, тут имеется третья сторона (владелец того самого ключа рут-зоны — ICANN наверно? а может ещё цепочка CA, не особо в курсе их организационной структуры), которая может своим настоящим ключом злонамеренно или по ошибке подписать подложную SSHFP-запись для mitm-атаки.
ssh -v root@babai.ru
found 6 secure fingerprints in DNS
Даже если прошлая команда не подверглась уже описанным атакам и подтвердила настоящую легитимную SSHFP-запись, полученную с помощью сделанного ей DNS-запроса про домен babai.ru, это не гарантия того, что аналогичный DNS-запрос, сделанный ssh-клиентом (хотя стоит отметить, что в зависимости от настроек dns-кеша и прочих обстоятельств этого второго запроса может и не случиться, но это частный случай), вернёт ту же SSHFP-запись. То есть может выйти так, что dig получит и проверит легитимную запись, а второму запросу (от ssh) отдадут уже подложную.
Итог: вы, если хотите, можете доверять используемому вами DoH-серверу и вообще официальной DNS-инфраструктуре, но надо понимать, это это именно осознанное доверие третьей стороне, снижающее безопасность p2p-соединения. Даже если этой третьей стороной является какая-то крупная известная организация, которой вроде бы незачем вас атаковать, данный риск всё равно должен держаться в голове.
Все эти шифрования и pki защищают только транспорт, а от злонамеренного агента на той стороне они никак не защитят. Как минимум одна "та сторона" неизбежна — это сам сервер, к которому подключается ssh, а вот от всего остального можно избавиться.
Кому может и никакой, а кто-то может быть против распространения вообще (хоть коммерческого, хоть бесплатного), и не обязан вам даже сообщать причины такого решения. И не надо у добросовестных авторов отнимать это право.
Когда подобным занимаются копирайтодержатели, не являющиеся авторами — другое дело.
Эм, всё не так.
По поводу веба: естественно никто не станет сверять ключи для посещения очередного развлекательного сайта, так что там придумали систему, которая хоть как-то работает в расчёте на незаинтересованного в безопасности и в среднем малограмотного пользователя.
Если у вас SSH относится к той же категории, то ок, хорошая идея, но не надо её выставлять как топовую безопасность. Особенно вот это:
узнать отпечаток ключа сервера через DNS, и если он совпадает с предложенным сервером, то подключаться без предупреждения.
Для пользователей, которым плевать на безопасность, и которые не хотят на неё вообще что-то тратить ("нажимаем Yes не задумываясь", "ведь никто не станет проверять ключи, а будет просто всегда соглашаться"), это всё действительно несколько её увеличит. А те, кому не плевать, будут сверять ключи с полученными по действительно надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).
Ответил RGB, потом заметил что у пункта ответа HEX почему-то больше голосов, и понял что в вашем списке у меня тоже он.
Не надо всё в кучу валить. RGB, HSL и ключевые слова — это действительно разные способы представления цвета. А то, что вы назвали HEX — это не новый способ представления, а другая система счисления (шестнадцатиричная) при указании компонент RGB.
Пользуюсь везде RGB (обычно в hex-форме потому что так короче), потому что за долгое время он стал интуитивно понятным, и нужный цвет обычно можно закодировать с 1-2 попыток со скоростью нажатия кнопок на клавиатуре и без просмотра всяких таблиц. Ну и потому что это нативное представление для видеокарт и мониторов.
В антинаучную хрень очень даже часто верят. Надо только убедительно её оформить. Но какая разница? "Научность" теории — не самоцель. Теория помогает остановить внедрение 5г, значит она полезна. Конкретное её содержание не важно.
Совсем нет.
Мало кто пытается монополизировать интернет-инфраструктуру. Даже всякие массовые сервисы типа публичных почтовиков или гитхаба хоть и пытаются двигаться в сторону своей монополии (и мне эта ситуация тоже не нравится), но они предоставляют сервисы уровня приложения, а не глобальную инфраструктуру.
Ну а про контроль это было не самостоятельное утверждение, а в контексте вышесказанного.
У него единственная проблема — это сервис который пытается монополизировать часть интернетной инфраструктуры. И надёжно контролировать что они там внутри делают — невозможно.
Всё остальное это болтовня.
Была ли ошибка в nginx? Да, была, потому что утечка содержимого памяти это в любом случае ошибка.
Не уверен что это так. Хотя скорее всего ошибка есть, ведь существует например переменная $binary_remote_addr в которой нули могут быть штатно (хотя сувать её в rewrite вряд ли кому придёт в голову, да и длина её всего 4 байта). Что же касается нулей из запроса, то nginx (без стороннних модулей) проверяет входные данные для обеспечения равенства strlen() и сохранённой длины строк, так что именно там бага нет.
Статья о том, как подарить ключи от своего сервера левым конторам.
Если речь не про строительство сарая, то формы рисуют художники, а архитекторы как раз придумывают как строить, с учётом всех технических норм. А строители возводят здание по готовому чертежу, сделанному архитектором.
Знание технологий тут — не опция для архитектора, а основа его работы. А в вашем примере задачу архитектора выполняют матерящиеся подрядчики.
Заменил винду на линукс на основном компе лет 10 назад, пользуюсь
mcиmceditдля редактирования всего (в т.ч. кода, вместо IDE),viиспользую только когдаmceditнедоступен, аemacsкогда-то 1 раз попробовал и больше не пытался.Так что не надо за всех говорить.
Даже более того, этот метод (полагаться на указатель, без самомодификации) широко используется в sh-архивах. Это когда в начале файла скрипт, который сделан так, чтобы шелл читал его до определённого байта (и это работает стабильно и без неожиданностей), а скрипт этот забирает stdin дескриптор себе, читает из него хвост и распаковывает, а затем может выполнить ещё какие-то действия, например для первоначальной настройки только что распакованного софта. Работает не только с файлами но и с пайпами в стиле curl | bash (точнее stdin как раз для второго случая, а в первом альтернативный способ какой-то). Естественно это всё не только для баша а для большинства шеллов.
Интересный обзор, но выводы неправильные.
SFTP — это не новая версия того FTP, а новый протокол с аналогичным функционалом (причём в самой статье выше это было написано).
Нет, плюсы есть только у SFTP, а от FTP и всех его модификаций надо избавляться. Это жуткое легаси, совершенно непригодное в современных реалиях нигде, кроме локальной домашней сети, и костыльная SSL-обёртка не особо что-то меняет. Ну а в домашней сети его лучше тоже не использовать, чтобы не привыкать к плохим вещам.
Я нигде не писал что это портированный линуксовый. Но у него общие с линуксом проблемы в виде неорганизованной и местами некомпетентной разработки, видимо потому что компетентным и организованным разработчикам неинтересно рыться в этой помойке, а писать хорошее с нуля — не хватает ресурсов конкурировать с "массовым" производством.
Ага, на базе ненормального X11 (да, он появился раньше линукса, но во многом благодаря ему остановился в нормальном развитии и начал обрастать костылями).
Это всё сошло бы за аргумент, если бы не было FreeBSD. А там именно система, удовлетворяющая этим критериям, но без вороха всякого разнородного хлама на системном уровне. На пользовательском уровне, увы, то же самое что в линуксе (наверно потому что для десктопа она изначально не предназначалась и он получился побочным образом, просто взяв "готовые" решения).
Надёжность, отсутствие неявного оверхеда, полная предсказуемость в плане двусторонней конвертации C <-> asm (или другими словами, можно рассматривать C как набор синтаксических конструкций для компактного и удобного представления асм-кода, а не для манипуляций компиляторными абстракциями).
Для тех, кто всё это умеет использовать, разумеется, а некоторые могут хоть на пхп пытаться системный софт писать.
Всё и везде.
DoH-сервер может подменить этот ключ (да, DoH-сервер это третья сторона, а не абстрактная идеальная сущность). Но допустим этого не произошло, и ключ вы получили настоящий.
Если я правильно понял, эта команда проверяет, что SSHFP-запись домена babai.ru подтверждена ключом, полученным на прошлом этапе. Очевидно, тут имеется третья сторона (владелец того самого ключа рут-зоны — ICANN наверно? а может ещё цепочка CA, не особо в курсе их организационной структуры), которая может своим настоящим ключом злонамеренно или по ошибке подписать подложную SSHFP-запись для mitm-атаки.
Даже если прошлая команда не подверглась уже описанным атакам и подтвердила настоящую легитимную SSHFP-запись, полученную с помощью сделанного ей DNS-запроса про домен babai.ru, это не гарантия того, что аналогичный DNS-запрос, сделанный ssh-клиентом (хотя стоит отметить, что в зависимости от настроек dns-кеша и прочих обстоятельств этого второго запроса может и не случиться, но это частный случай), вернёт ту же SSHFP-запись. То есть может выйти так, что dig получит и проверит легитимную запись, а второму запросу (от ssh) отдадут уже подложную.
Итог: вы, если хотите, можете доверять используемому вами DoH-серверу и вообще официальной DNS-инфраструктуре, но надо понимать, это это именно осознанное доверие третьей стороне, снижающее безопасность p2p-соединения. Даже если этой третьей стороной является какая-то крупная известная организация, которой вроде бы незачем вас атаковать, данный риск всё равно должен держаться в голове.
Все эти шифрования и pki защищают только транспорт, а от злонамеренного агента на той стороне они никак не защитят. Как минимум одна "та сторона" неизбежна — это сам сервер, к которому подключается ssh, а вот от всего остального можно избавиться.
Затем же, зачем на нём пишут системный софт.
Как будто это что-то плохое.
Кому может и никакой, а кто-то может быть против распространения вообще (хоть коммерческого, хоть бесплатного), и не обязан вам даже сообщать причины такого решения. И не надо у добросовестных авторов отнимать это право.
Когда подобным занимаются копирайтодержатели, не являющиеся авторами — другое дело.
Эм, всё не так.
По поводу веба: естественно никто не станет сверять ключи для посещения очередного развлекательного сайта, так что там придумали систему, которая хоть как-то работает в расчёте на незаинтересованного в безопасности и в среднем малограмотного пользователя.
Если у вас SSH относится к той же категории, то ок, хорошая идея, но не надо её выставлять как топовую безопасность. Особенно вот это:
Для пользователей, которым плевать на безопасность, и которые не хотят на неё вообще что-то тратить ("нажимаем Yes не задумываясь", "ведь никто не станет проверять ключи, а будет просто всегда соглашаться"), это всё действительно несколько её увеличит. А те, кому не плевать, будут сверять ключи с полученными по действительно надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).
Не надо всё в кучу валить. RGB, HSL и ключевые слова — это действительно разные способы представления цвета. А то, что вы назвали HEX — это не новый способ представления, а другая система счисления (шестнадцатиричная) при указании компонент RGB.
Пользуюсь везде RGB (обычно в hex-форме потому что так короче), потому что за долгое время он стал интуитивно понятным, и нужный цвет обычно можно закодировать с 1-2 попыток со скоростью нажатия кнопок на клавиатуре и без просмотра всяких таблиц. Ну и потому что это нативное представление для видеокарт и мониторов.
Критикуй не критикуй а исполнять всё равно придётся.
В антинаучную хрень очень даже часто верят. Надо только убедительно её оформить. Но какая разница? "Научность" теории — не самоцель. Теория помогает остановить внедрение 5г, значит она полезна. Конкретное её содержание не важно.
Жалко что мало кто в это поверит.
Хотя может надо всего лишь придумать какие-то более научно выглядящие обоснования.
Совсем нет.
Мало кто пытается монополизировать интернет-инфраструктуру. Даже всякие массовые сервисы типа публичных почтовиков или гитхаба хоть и пытаются двигаться в сторону своей монополии (и мне эта ситуация тоже не нравится), но они предоставляют сервисы уровня приложения, а не глобальную инфраструктуру.
Ну а про контроль это было не самостоятельное утверждение, а в контексте вышесказанного.
У него единственная проблема — это сервис который пытается монополизировать часть интернетной инфраструктуры. И надёжно контролировать что они там внутри делают — невозможно.
Всё остальное это болтовня.
Не уверен что это так. Хотя скорее всего ошибка есть, ведь существует например переменная $binary_remote_addr в которой нули могут быть штатно (хотя сувать её в rewrite вряд ли кому придёт в голову, да и длина её всего 4 байта). Что же касается нулей из запроса, то nginx (без стороннних модулей) проверяет входные данные для обеспечения равенства strlen() и сохранённой длины строк, так что именно там бага нет.