Проблема в том, что она "интересная техническая" когда у вас в условиях написано "точечно идентифицировать вот это, не трогая всё остальное". У РКН вводные проще: "можно заодно сломать почти что угодно". Что резко понижает градус инженерного вызова.
Сценарий ещё проще: для инфраструктуры ТСПУ выпускают промежуточный сертификат с правом выписывать сертификаты для любого FQDN. ТСПУ начинает радостно на лету генерировать сертификаты и делать MitM всему проходящему трафику.
Если не включалось по питанию, то электрохимической коррозии под чипами не было (а это в случае электроники - самое страшное; большинство открытых внешним воздействиям контактов и компонентов вот так просто само по себе очень слабо и медленно разваливается чисто в силу своего химического состава). После грубой механической чистки снимаем с платы всё, что потенциально боится долгого бултыхания в ультразвуке (например кварцы) и/или боится изопропанола. Несколько итераций промывки в деионизированной воде в ультразвуковой ванне (на небольшой мощности, а то можно антиоксидное покрытие с контактов смыть ненароком) для удаления отложений солей и прочих водорастворимых присадок. Потом в очень обильном количестве абсолютированного изопропанола, который всю воду даже под чипами радостно свяжет и утащит за собой т.к. обожает её удерживать и не отдавать назад до тех пор, пока его концентрация не упадёт до, ЕМНИП, 97%. Тщательно сушим. В конце сажаем назад на плату всё снятое. Главное - не жалеть количества и чистоты промывочных жидкостей на каждом этапе.
После такой процедуры можно, в принципе, считать, что железка утопленником не была. Честно говоря, у меня даже по результатам описанных в статье процедур возникло сильное подозрение, что скорее что-то нежное уз-ванной угробили в процессе отмывки.
Ну и как-то быстро они сдались. Или не уж то расчитывали, что за эти пару месяцев все бросят свои проекты и начнут заново на новом движке.
Судя по тексту статьи, они даже до релиза не добрались и сдались ещё на стадии открытой беты. То есть до того, как у них в принципе могли появиться крупные коммерческие клиенты. Прям классика грамотного менеджмента: начать делать продукт без изучения рынка и понимания потенциального спроса; не спланировать/заложить бюджет проекта наперед так, чтобы его хватило на время разработки и выхода на самоокупаемость; в итоге сдаться и отправить проект в забвение. Ну или причина та же, что и обычно: были бесплатные деньги, их осваивали пока давали.
Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
И, вдобавок, были реальные случаи совпадения MAC-адресов.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
Вы могли заметить, что в заголовке фигурирует более 20 ГБ свободного места, а на графиках — лишь половина. Всё просто: индексы удаляются и на репликах! Освободив 10 ГБ на основной базе, вы освобождаете примерно столько же на каждой реплике.
Ну всё, позабыта ZFS. Ставлю винду!
Проблема в том, что она "интересная техническая" когда у вас в условиях написано "точечно идентифицировать вот это, не трогая всё остальное". У РКН вводные проще: "можно заодно сломать почти что угодно". Что резко понижает градус инженерного вызова.
Некоторые не парятся и ничего не меняют даже между 30 и 35 годами!
А вы таки наивно думаете, что на государственном уровне такое для блокировок мечтают внедрить?)
Wildcard сертификаты работают только на один уровень доменных имён именно для того, чтобы нельзя было делать так)
Сценарий ещё проще: для инфраструктуры ТСПУ выпускают промежуточный сертификат с правом выписывать сертификаты для любого FQDN. ТСПУ начинает радостно на лету генерировать сертификаты и делать MitM всему проходящему трафику.
Не просвечивается. Им давно с небесной тверди инторнеты раздают наверняка.
Планируют к 2028 году разработать? Ну ведь у них хотя бы начата была работа на момент этого заявления? Ведь начата же, да?
Оооо! FreeRadius! THE posh garbage! Блеск нищеты!
(Серьёзно, мало что из софта вызывает у меня столь полярные эмоции разом)
Должен заметить, что справа герой статьи выглядит куда счастливее. Прям настолько, что хочется тоже бросить это всё и уйти гусей разводить...
Если не включалось по питанию, то электрохимической коррозии под чипами не было (а это в случае электроники - самое страшное; большинство открытых внешним воздействиям контактов и компонентов вот так просто само по себе очень слабо и медленно разваливается чисто в силу своего химического состава). После грубой механической чистки снимаем с платы всё, что потенциально боится долгого бултыхания в ультразвуке (например кварцы) и/или боится изопропанола. Несколько итераций промывки в деионизированной воде в ультразвуковой ванне (на небольшой мощности, а то можно антиоксидное покрытие с контактов смыть ненароком) для удаления отложений солей и прочих водорастворимых присадок. Потом в очень обильном количестве абсолютированного изопропанола, который всю воду даже под чипами радостно свяжет и утащит за собой т.к. обожает её удерживать и не отдавать назад до тех пор, пока его концентрация не упадёт до, ЕМНИП, 97%. Тщательно сушим. В конце сажаем назад на плату всё снятое. Главное - не жалеть количества и чистоты промывочных жидкостей на каждом этапе.
После такой процедуры можно, в принципе, считать, что железка утопленником не была. Честно говоря, у меня даже по результатам описанных в статье процедур возникло сильное подозрение, что скорее что-то нежное уз-ванной угробили в процессе отмывки.
Судя по тексту статьи, они даже до релиза не добрались и сдались ещё на стадии открытой беты. То есть до того, как у них в принципе могли появиться крупные коммерческие клиенты. Прям классика грамотного менеджмента: начать делать продукт без изучения рынка и понимания потенциального спроса; не спланировать/заложить бюджет проекта наперед так, чтобы его хватило на время разработки и выхода на самоокупаемость; в итоге сдаться и отправить проект в забвение.
Ну или причина та же, что и обычно: были бесплатные деньги, их осваивали пока давали.ВК за всё берется смело
Всё превращается в говно
А если за говно берётся
То просто тратит меньше сил
Три: пароль от сети заносится в keepass и проблема решена.
Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Приоритеты власть имущих они такие, да)
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
Из-за десяти:
Но есть запрет на их полеты!)