А так, не представляю себе чела, которому на выбор предложили идти в гугол или яндекс и он такой выбирает яндекс.
Я бы вот при именно таком выборе выбрал яндекс. По политическим соображениям. И вам того же желаю.
Если бы политических соображений не было — пришлось бы долго разбираться что же у них там внутри, не судить же по тем пиар-статьям что они публикуют.
Хотя это всё конечно гипотетические ситуации.
Почему негативное то?
По-моему то что тут на линуксе тестировалось показало в целом лучшие результаты наоборот.
ибо сама технология Java изначально разрабатывается Oracle
Ну это враньё уже, Java изначально разрабатывалась Sun, и в какой-то момент была форкнута на две более менее равноправные ветки, одна опенсорсная другая клозедсорсная.
Я может быть неправильно вас понял, но у меня сложилось впечатление, что у вас "символы до завершающего нуля" и "вся строка" это разные вещи. Нет, это одно и то же. И там нет никакого "первого вхождения нуля" и вообще никаких вхождений нуля. Ноль это спецзначение, обозначающее конец строки, и никаких других концов, до которых можно пробежать, у строки быть не может.
Соответственно, strlen пробегает все символы строки + не-символ-строки '\0' который идёт ПОСЛЕ всех символов строки, а затем останавливается. Байты после нуля уже к строке никакого отношения не имеют, даже если под них выделена память в массиве char, в котором эта строка хранится.
Раньше вкладки копились неограниченно, а после крашей (кстати, крайне редких, то ли новый фф то ли новые сайты виноваты но крашится заметно чаще) или после ребутов (с предварительной имитацией краша через kill -9 чтобы сессия сохранилась в удобном виде) оставались в about:sessionrestore (или как там оно называется) и так могло делаться например 10 раз и все они сохранялись корректно. В каждой итерации могло быть по 10 окон в примерно 5-30 вкладок в каждом.
Но со временем (а может быть, после того как пару раз закрыл случайно закрыл браузер штатно и все эти сотни вкладок терялись) я понял, что всё это собирательство ни к чему полезному не приводит и стал закрывать их сам время от времени (ну если совсем жалко — сохранять перед этим в закладки где они хоть память не жрут), ну наверно когда порядка 50 накапливается но это не точно.
Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).
Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
И комментарии под ней, на полном серьёзе что-то обсуждающие.
Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.
Я и не собирался. Но теоретическая возможность имеется. Повторюсь, безопасность, построенная на "они не смогут разобраться в устройстве" называется security through obsurity и это общепризнанно плохой подход.
Какой ещё сертификат? Речь идёт о приватном ключе шифрования. Обновление прошивки, скачиваемое с сайта, тут не поможет — из него точно так же (даже ещё намного проще) вытащат этот приватный ключ (если надо — сэмулируют проц, качающий себе обновление, хотя по-моему до этого ещё не дошли и скачивается оно средствами ОС).
Или они всем покупателям предложат бесплатно заменить чипы на новые? А всем поставщикам зашифрованного софта придётся его перешифровывать и изымать с жёстких дисков клиентов старые версии?
Я вообще не пойму кому пришла в голову идиотская идея что можно доверять железу, полностью находящемуся в руках предполагаемого злоумышленника. Точнее, для производителя то резон понятен: "впарим ка ещё и это, заодно цену повысим". А вот те, кто этому верит — странные.
Достаточно один раз отреверсить проц чтобы вытащить из него этот самый ключ и дальше использовать везде. Да, это совсем не дёшево, но суть не меняется — security through obsurity. Ключ просто спрятан в чипе с надеждой что его там никто не сможет подсмотреть.
Причем какой-то реверсинг уже делали, если верить этой статье, значит были близко к правильной нейтрализации этой фигни.
Что за глупости.
Ядро ОС (и те кому оно дало доступы к настройке железа) может прочитать память? Всё в порядке.
Не в порядке сама идея прятать пользовательский процесс в памяти от ядра, затея заведомо провальная, даже без этих "уязвимостей". Потому как всю эту чушь можно просто виртуализировать (вплоть до эмуляции нужных узлов проца, отвечающих за эту "защиту") и запустить исследуемое приложение в такой песочнице. Очередное security through obscurity.
Он "лучше" только тем что действует не настолько топорно и таким образом меньше палится.
Вот можно например почитать https://habr.com/ru/post/391575/
Понимаю что это несколько другая история, но у неё общее: и там и там фирма хочет заставить других делиться с ней доходами за то что к ней не относится. У майкрософта получилось, причём в куда большем финансовом масштабе чем тут.
По-моему случившееся — целиком частная разборка, инициированная плохой компанией (у которой скорее всего капитализация меньше чем та сумма от которой они переполошились).
А у органов просто не хватило компетенции сразу понять что претензия полностью сфальсифицирована и отказаться её принимать. Ну ничего, разберутся, хотя неприятно вышло. Хотелось бы чтоб рамблеру что-то сделали за это, но это уже под вопросом.
Не отрицаю что проблема на гос. уровне имеется, но тут она не политическая а в компетенции тех гос. чиновников кто принял/руководит этим делом (ну естественно не только их конкретно а общей ситуации при которой такие имеются).
Вы то ли подменяете понятия то ли не понимаете сути. Я не знаю что и как в Rust, но ваши заявления касательно C/C++ странные.
Во-первых, "как C только контролируя безопасность" это и есть оверхед. В glibc например если поставить переменную окружения _MALLOC_CHECK=2 он тоже будет что-то контролировать, но это не продакшн функция а отладочная. Это если про само выделение/освобождение. Если же речь про невыход за границы выделенной памяти то это ещё больше оверхеда (при каждом обращении к массиву сверять индекс с чем-то в памяти, а уж как в таком режиме работать с type-casted указателями я вообще не знаю).
Во-вторых, когда я выше писал про c++ это было не про smart pointers а про RAII. Сам RAII добавляет немного (немного — повторюсь — на современных компиляторах и с качественной реализацией класса) оверхеда, а smart pointers с refcount — это абстракция над RAII которая добавляет ещё оверхеда. Если речь про без refcount то это тоже самое что статический объект. Случай с малым оверхедом это когда функционал smart pointer'а встроен в используемые классы, но не отдельной абстракцией а монолитно.
Иметь несколько указателей на объект это штатная фича указателей. А ещё бывают указатели на не-объект, например на позицию "+2 байта от начала переменной long long x;" (тип long long обычно 64-битный). То есть указатель это совсем-совсем не обязательно результат работы аллокатора для какого-то класса.
можно все это сделать через unsafe и сырые указатели.
То есть если хотим максимальной эффективности — возвращаемся в тому что было.
Код на Си транслируется в ассемблер практически без оверхеда. Более того, современные компиляторы часто могут сделать такие оптимизации, которые вручную было бы делать крайне муторно. А если ещё эти оптимизации зависят от платформы то всё ещё лучше в пользу Си. Те же места, где компилятору не повезло (их мало но они встречаются) можно сделать ассемблерными вставками, если там критична скорость.
А вот с управлением памятью ситуация совершенно другая. Автоматическое управление памятью всегда создаёт оверхед, и работает хуже чем это может сделать программист вручную. И вряд ли ситуация сильно изменится если только этим не займётся AI. Ну, насчёт оверхеда есть одно почти исключение — c++ управление временем жизни объектов (не указателей) при должном уровне компиляторных оптимизаций и при качественной реализации конструкторов копирования/перемещения, операторов присваивания (всё это с полноценным учётом const/nonconst аргументов) и деструкторов этих самых объектов, на современных компиляторах может быть с довольно маленьким оверхедом. Однако обычно это даже не считают автоматическим управлением памятью.
Патч-корды подписывать.
На выходах из организаторов оставлять хвосты такие чтобы в пределах патч-панели или свитча можно было легко переткнуть. Да, будут чуть-чуть свисать но это не страшно, стойка на для красоты установлена а для работы.
Эти две меры покроют большинство случаев когда из-за "наведения порядка" получаются проблемы.
"Красота" в серверной делается тоже не ради самоценной красоты а ради удобства и безопасности. Не надо подменять цели и делать красоту в ущерб тому ради чего она нужна.
Какой странный майрософт, все же знают что у настоящего программиста не бывает ошибок с памятью, особенно в программах написанных в последние годы. Вы покажите пару примеров кода, всем станет очевидно, что ни один программист в здравом уме такого не напишет.
〈/sarcasm〉
Это вобщем-то и без сарказма почти верно.
Просто "настоящие программисты" (в хорошем смысле) бизнесменам не нужны. Поэтому даже те, кто мог бы быть ими, обычно вынуждены играть роль плохих.
Не систему а планы сделать систему.
Скорее всего до хоть сколько-то осмысленной реализации дело не дойдёт.
Это в переводе на русский означает "пока что занимаемся графоманией и может быть написали бут лоадер".
Я бы вот при именно таком выборе выбрал яндекс. По политическим соображениям. И вам того же желаю.
Если бы политических соображений не было — пришлось бы долго разбираться что же у них там внутри, не судить же по тем пиар-статьям что они публикуют.
Хотя это всё конечно гипотетические ситуации.
Почему негативное то?
По-моему то что тут на линуксе тестировалось показало в целом лучшие результаты наоборот.
Ну это враньё уже, Java изначально разрабатывалась Sun, и в какой-то момент была форкнута на две более менее равноправные ветки, одна опенсорсная другая клозедсорсная.
Я может быть неправильно вас понял, но у меня сложилось впечатление, что у вас "символы до завершающего нуля" и "вся строка" это разные вещи. Нет, это одно и то же. И там нет никакого "первого вхождения нуля" и вообще никаких вхождений нуля. Ноль это спецзначение, обозначающее конец строки, и никаких других концов, до которых можно пробежать, у строки быть не может.
Соответственно, strlen пробегает все символы строки + не-символ-строки '\0' который идёт ПОСЛЕ всех символов строки, а затем останавливается. Байты после нуля уже к строке никакого отношения не имеют, даже если под них выделена память в массиве char, в котором эта строка хранится.
Увы, обычно это ошибкой не считают. А так, всегда всё компилю с -Wshadow -Werror и такие места сразу отсеиваются.
Шрифт как шрифт.
А вот аргументация про "прямоугольники помогут скользить взглядом" — какая-то чушь.
Раньше вкладки копились неограниченно, а после крашей (кстати, крайне редких, то ли новый фф то ли новые сайты виноваты но крашится заметно чаще) или после ребутов (с предварительной имитацией краша через kill -9 чтобы сессия сохранилась в удобном виде) оставались в about:sessionrestore (или как там оно называется) и так могло делаться например 10 раз и все они сохранялись корректно. В каждой итерации могло быть по 10 окон в примерно 5-30 вкладок в каждом.
Но со временем (а может быть, после того как пару раз закрыл случайно закрыл браузер штатно и все эти сотни вкладок терялись) я понял, что всё это собирательство ни к чему полезному не приводит и стал закрывать их сам время от времени (ну если совсем жалко — сохранять перед этим в закладки где они хоть память не жрут), ну наверно когда порядка 50 накапливается но это не точно.
А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).
Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
И комментарии под ней, на полном серьёзе что-то обсуждающие.
Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.
Так вам и надо. Нечего было считать его годным и пользоваться.
С одной стороны, вроде бы интересная статья. С другой, автор кажется пользуется мэйлру, а это уже странно.
Я и не собирался. Но теоретическая возможность имеется. Повторюсь, безопасность, построенная на "они не смогут разобраться в устройстве" называется security through obsurity и это общепризнанно плохой подход.
Какой ещё сертификат? Речь идёт о приватном ключе шифрования. Обновление прошивки, скачиваемое с сайта, тут не поможет — из него точно так же (даже ещё намного проще) вытащат этот приватный ключ (если надо — сэмулируют проц, качающий себе обновление, хотя по-моему до этого ещё не дошли и скачивается оно средствами ОС).
Или они всем покупателям предложат бесплатно заменить чипы на новые? А всем поставщикам зашифрованного софта придётся его перешифровывать и изымать с жёстких дисков клиентов старые версии?
Я вообще не пойму кому пришла в голову идиотская идея что можно доверять железу, полностью находящемуся в руках предполагаемого злоумышленника. Точнее, для производителя то резон понятен: "впарим ка ещё и это, заодно цену повысим". А вот те, кто этому верит — странные.
Достаточно один раз отреверсить проц чтобы вытащить из него этот самый ключ и дальше использовать везде. Да, это совсем не дёшево, но суть не меняется — security through obsurity. Ключ просто спрятан в чипе с надеждой что его там никто не сможет подсмотреть.
Причем какой-то реверсинг уже делали, если верить этой статье, значит были близко к правильной нейтрализации этой фигни.
Что за глупости.
Ядро ОС (и те кому оно дало доступы к настройке железа) может прочитать память? Всё в порядке.
Не в порядке сама идея прятать пользовательский процесс в памяти от ядра, затея заведомо провальная, даже без этих "уязвимостей". Потому как всю эту чушь можно просто виртуализировать (вплоть до эмуляции нужных узлов проца, отвечающих за эту "защиту") и запустить исследуемое приложение в такой песочнице. Очередное security through obscurity.
Он "лучше" только тем что действует не настолько топорно и таким образом меньше палится.
Вот можно например почитать https://habr.com/ru/post/391575/
Понимаю что это несколько другая история, но у неё общее: и там и там фирма хочет заставить других делиться с ней доходами за то что к ней не относится. У майкрософта получилось, причём в куда большем финансовом масштабе чем тут.
По-моему случившееся — целиком частная разборка, инициированная плохой компанией (у которой скорее всего капитализация меньше чем та сумма от которой они переполошились).
А у органов просто не хватило компетенции сразу понять что претензия полностью сфальсифицирована и отказаться её принимать. Ну ничего, разберутся, хотя неприятно вышло. Хотелось бы чтоб рамблеру что-то сделали за это, но это уже под вопросом.
Не отрицаю что проблема на гос. уровне имеется, но тут она не политическая а в компетенции тех гос. чиновников кто принял/руководит этим делом (ну естественно не только их конкретно а общей ситуации при которой такие имеются).
Вы то ли подменяете понятия то ли не понимаете сути. Я не знаю что и как в Rust, но ваши заявления касательно C/C++ странные.
Во-первых, "как C только контролируя безопасность" это и есть оверхед. В glibc например если поставить переменную окружения _MALLOC_CHECK=2 он тоже будет что-то контролировать, но это не продакшн функция а отладочная. Это если про само выделение/освобождение. Если же речь про невыход за границы выделенной памяти то это ещё больше оверхеда (при каждом обращении к массиву сверять индекс с чем-то в памяти, а уж как в таком режиме работать с type-casted указателями я вообще не знаю).
Во-вторых, когда я выше писал про c++ это было не про smart pointers а про RAII. Сам RAII добавляет немного (немного — повторюсь — на современных компиляторах и с качественной реализацией класса) оверхеда, а smart pointers с refcount — это абстракция над RAII которая добавляет ещё оверхеда. Если речь про без refcount то это тоже самое что статический объект. Случай с малым оверхедом это когда функционал smart pointer'а встроен в используемые классы, но не отдельной абстракцией а монолитно.
Иметь несколько указателей на объект это штатная фича указателей. А ещё бывают указатели на не-объект, например на позицию "+2 байта от начала переменной long long x;" (тип long long обычно 64-битный). То есть указатель это совсем-совсем не обязательно результат работы аллокатора для какого-то класса.
То есть если хотим максимальной эффективности — возвращаемся в тому что было.
Код на Си транслируется в ассемблер практически без оверхеда. Более того, современные компиляторы часто могут сделать такие оптимизации, которые вручную было бы делать крайне муторно. А если ещё эти оптимизации зависят от платформы то всё ещё лучше в пользу Си. Те же места, где компилятору не повезло (их мало но они встречаются) можно сделать ассемблерными вставками, если там критична скорость.
А вот с управлением памятью ситуация совершенно другая. Автоматическое управление памятью всегда создаёт оверхед, и работает хуже чем это может сделать программист вручную. И вряд ли ситуация сильно изменится если только этим не займётся AI. Ну, насчёт оверхеда есть одно почти исключение — c++ управление временем жизни объектов (не указателей) при должном уровне компиляторных оптимизаций и при качественной реализации конструкторов копирования/перемещения, операторов присваивания (всё это с полноценным учётом const/nonconst аргументов) и деструкторов этих самых объектов, на современных компиляторах может быть с довольно маленьким оверхедом. Однако обычно это даже не считают автоматическим управлением памятью.
Патч-корды подписывать.
На выходах из организаторов оставлять хвосты такие чтобы в пределах патч-панели или свитча можно было легко переткнуть. Да, будут чуть-чуть свисать но это не страшно, стойка на для красоты установлена а для работы.
Эти две меры покроют большинство случаев когда из-за "наведения порядка" получаются проблемы.
"Красота" в серверной делается тоже не ради самоценной красоты а ради удобства и безопасности. Не надо подменять цели и делать красоту в ущерб тому ради чего она нужна.
Это вобщем-то и без сарказма почти верно.
Просто "настоящие программисты" (в хорошем смысле) бизнесменам не нужны. Поэтому даже те, кто мог бы быть ими, обычно вынуждены играть роль плохих.