AT&T-синтаксис достаточно похож на различных архитектурах — одни и те же символы обозначают регистр, непосредственное (immediate) значение, одинаковые псевдооперации; в итоге проще написать программу (компилятор), генерирующую текст на языке ассемблера под несколько различных архитектур, пригодный для подачи на вход в GNU assembler.
Если злоумышленник сможет подменять DNS-ответы, то он сможет делегировать домен себе (подменить NS-записи), а затем поставить
свои A-записи и выписать сертификат у любого CA (пройдёт domain validation).
Проблема этой аналогии в том, что добавить поддержку HTTPS на своём веб-сервере даже проще, чем реализовать MitM. Настройка выполняется один раз; это объективно проще, чем купить бронежилет и каждый раз надевать его перед прогулкой по лесу.
Тут скорее уместна аналогия с дверьми — не смотря на то, что общество борется со злоумышленниками, вход в своё жилище вы всё равно защищаете. Пока не придумали системного способа борьбы со злом, который бы устранил проблему навсегда (и вряд ли придумают), будет иметь смысл защищаться.
Даже в условиях, когда злоумышенников нет, HTTPS может помочь. Если кто-то неправильно (без всякого злого умысла) настроит прокси-сервер, сетевую маршрутизацию или DNS, что приведёт к обработке трафика не на том узле, использование HTTPS в большинстве случаев поможет сразу же обнаружить проблему — браузер покажет ошибку, и пользователи пожалуются.
Не подскажите, как называются такие сокеты, и где вы их взяли?
Поиск по картинке находит только habr, а по запросу «soic-8 socket» находятся ICSP-прищепки.
Причина действительно историческая. Раньше использовали метод, называемый «in-circuit emulation» (ICE) — «релизную» микросхему заменяли специальным устройством, которое эмулировало её и вставлялось в разъём. Сейчас большинство процессоров содержат блок JTAG, что позволяет отказаться от дорогих ICE.
Если предположить, что все преступники технически продвинуты, а раскрытие ключей шифрования нужно для того, чтобы их было проще ловить, то использование любой надёжной схемы шифрования в качестве государственной (с требованием раскрывать ключ) и запрет на использование других схем не помогут правительству.
Вероятно, maybe sudo pacman -Syu не сработала потому, что sudo — suid-ный бинарник, а их трассировать с помощью ptrace обычный пользователь не может.
Стоит попробовать sudo maybe pacman -Syu.
Совсем несложно добавить в тот же bitcoind требование блока быть подписанным ключём, публичная часть которого захардкожена в клиент — это даст контроль той организации, которая обладает приватным ключём.
Принципиальная разница в лучшей изолации блокчейна по сравнению с mysql. Даже в рамках одной организации часто выгодно с точки зрения безопасности не иметь требования полного доверия между своими системами — ведь их обслуживают потенциально подкупаемые сотрудники, узлы системы могут находиться в какой-то сложной топологии с удалёнными датацентрами и т.п.
Другое различие в mysql заключается в ином консенсусе; для bitcoin, например, не требуется наличие постоянной связности с кворумом. Если интернет внезапно расколется надвое, просуществует в таком виде некоторое время, а потом восстановится, то во время поломки bitcoin-транзакции всё равно будут проходить в рамках своей «половины» мира. А после восстановления связи одна из цепочек «победит» другую, но это не приведёт систему в неконсистентное состояние. Большинство «транидицонных» СУБД, напротив, сломаются от такого разделения до восстановления связи с кворумом мастеров.
Даже в рамках своей собственной организации я бы предпочёл иметь систему, узлам которой не требуется полное доверие — это увеличит сложность её компрометации.
В блокчейне не все узлы занимаются поиском блоков (эмиссией). Например, если я установлю себе bitcoind, то с настройками по-умолчанию мой компьютер не будет участвовать в процессе эмиссии, но при этом я буду получать реплику всех изменений состояния блокчейна.
Если посмотреть на «обычную базу данных», скажем mysql с репликацией между нодами, то разница будет в необходимости выстраивать цепочки доверия между мастерами и слейвами. Ведь злоумышленник может взломать любой промежуточный узел и подправить баланс своего счёта; и эта правка останется незамеченной, пока не разъедутся балансы.
С bitcoind такой трюк не пройдёт. Если злоумышленник получит контроль над обычным узлом и подправит балансы, то его транзакции никто не примет — они не пройдут валидацию. Если злоумышленник захватит один узел, участвующий в эмиссии, то это тоже ничего ему не даст — для консенсиса proof of work потребуется получить контроль над половиной мощностей.
Действительно, ЦБ может «переписать историю», но во-первых эта операция всё равно остаётся недоступной злоумышленнику (требуется захват половины сети), что делает схему с криптовалютой более привлекательной с точки зрения безопасности; во-вторых такое переписывание не останется незамеченным (ведь странно же, что среди группировки майнеров, подконтрольных одной огранизации, получился форк) и, вероятно, будет вынесено в свет СМИ.
Можно. Смысл в том, что сеть будет работать лучше, если все вокруг будут использовать только каналы из списка «1, 6, 11» и никакие другие. Таким образом, если, например, у меня используется первый канал и у соседа сверху тоже первый канал, то наши устройства будут знать о существовании друг-друга и игнорировать «чужие» фреймы. А если кто-то рядом выставит себе второй канал, то мои устройства воспримут излучения его точки доступа, как радиочастотную помеху (ситуация симметрична и для соседа), что приведёт к увеличению задержек, потерь и повторным передачам.
Картинка с channel plan 1,6,11
Можно попытаться построить такую аналогию: в большой группе уважающих друг друга людей принято не перебивать других при разговоре. Если мы будем воспринимать чужой разговор (другой подгруппы), как фоновый шум и говорить внутри своей подгруппы всё громче, это приведёт к тому, что все подгруппы начнут повышать голос. Тогда никто не сможет разобрать речь своих собеседников.
Похожая проблема возникает, если все соседи начинают последовательно покупать всё более мощные точки доступа, чтобы их сигнал был мощнее сигнала соседа. Хотя в большинстве случаев было бы достаточно всем вместе снизить мощность передатчика, а в местах плохого покрытия поставить вторую маломощную точку.
Для 2.4GHz имеет смысл придерживаться channel plan, чтобы избежать коллизий для перекрывающихся каналов (простым языком можно написать «лучше всего работают вот такие-то каналы»). Вот только на эту тему разные источники дают разные рекомендации — чаще вижу «1, 6, 11», реже «1, 5, 9, 13». А приносить пользу эта рекомендация будет только тогда, когда большинство будет ей придерживаться.
Или можно хотя бы не использовать «Channel: auto» в настройках.
свои A-записи и выписать сертификат у любого CA (пройдёт domain validation).
Тут скорее уместна аналогия с дверьми — не смотря на то, что общество борется со злоумышленниками, вход в своё жилище вы всё равно защищаете. Пока не придумали системного способа борьбы со злом, который бы устранил проблему навсегда (и вряд ли придумают), будет иметь смысл защищаться.
Даже в условиях, когда злоумышенников нет, HTTPS может помочь. Если кто-то неправильно (без всякого злого умысла) настроит прокси-сервер, сетевую маршрутизацию или DNS, что приведёт к обработке трафика не на том узле, использование HTTPS в большинстве случаев поможет сразу же обнаружить проблему — браузер покажет ошибку, и пользователи пожалуются.
Поиск по картинке находит только habr, а по запросу «soic-8 socket» находятся ICSP-прищепки.
maybe sudo pacman -Syuне сработала потому, что sudo — suid-ный бинарник, а их трассировать с помощью ptrace обычный пользователь не может.Стоит попробовать
sudo maybe pacman -Syu.Принципиальная разница в лучшей изолации блокчейна по сравнению с mysql. Даже в рамках одной организации часто выгодно с точки зрения безопасности не иметь требования полного доверия между своими системами — ведь их обслуживают потенциально подкупаемые сотрудники, узлы системы могут находиться в какой-то сложной топологии с удалёнными датацентрами и т.п.
Другое различие в mysql заключается в ином консенсусе; для bitcoin, например, не требуется наличие постоянной связности с кворумом. Если интернет внезапно расколется надвое, просуществует в таком виде некоторое время, а потом восстановится, то во время поломки bitcoin-транзакции всё равно будут проходить в рамках своей «половины» мира. А после восстановления связи одна из цепочек «победит» другую, но это не приведёт систему в неконсистентное состояние. Большинство «транидицонных» СУБД, напротив, сломаются от такого разделения до восстановления связи с кворумом мастеров.
Если посмотреть на «обычную базу данных», скажем mysql с репликацией между нодами, то разница будет в необходимости выстраивать цепочки доверия между мастерами и слейвами. Ведь злоумышленник может взломать любой промежуточный узел и подправить баланс своего счёта; и эта правка останется незамеченной, пока не разъедутся балансы.
С bitcoind такой трюк не пройдёт. Если злоумышленник получит контроль над обычным узлом и подправит балансы, то его транзакции никто не примет — они не пройдут валидацию. Если злоумышленник захватит один узел, участвующий в эмиссии, то это тоже ничего ему не даст — для консенсиса proof of work потребуется получить контроль над половиной мощностей.
Действительно, ЦБ может «переписать историю», но во-первых эта операция всё равно остаётся недоступной злоумышленнику (требуется захват половины сети), что делает схему с криптовалютой более привлекательной с точки зрения безопасности; во-вторых такое переписывание не останется незамеченным (ведь странно же, что среди группировки майнеров, подконтрольных одной огранизации, получился форк) и, вероятно, будет вынесено в свет СМИ.
Можно попытаться построить такую аналогию: в большой группе уважающих друг друга людей принято не перебивать других при разговоре. Если мы будем воспринимать чужой разговор (другой подгруппы), как фоновый шум и говорить внутри своей подгруппы всё громче, это приведёт к тому, что все подгруппы начнут повышать голос. Тогда никто не сможет разобрать речь своих собеседников.
Похожая проблема возникает, если все соседи начинают последовательно покупать всё более мощные точки доступа, чтобы их сигнал был мощнее сигнала соседа. Хотя в большинстве случаев было бы достаточно всем вместе снизить мощность передатчика, а в местах плохого покрытия поставить вторую маломощную точку.
Или можно хотя бы не использовать «Channel: auto» в настройках.