Задача: минимизировать вероятность генерации (в неопределённом будущем) поддельного контента, подходящего под некий хэш.

Как все наверно знают, сейчас существует довольно много разных хэш-функций, к которым всё ещё не найдено ни одной коллизии. И как все наверно знают, строгого доказательства сложности нхождения этих коллизий ни для одной из хэш-функций нет и не будет.

В связи с этим возник вопрос, я даже не уверен что он действительно относится к security а не к толксам (если нао перенесите). Допустим, на хэш нам выделено 512 бит, и мы решили выбрать sha512. Можно предположить, что когда-нить к нему подберут алгоритм подбора подходящих исходных данных, придумав способ непротиворечиво разврачивать данные из хеша назад по цепочке (разумеется, подходящих разных данных очень много, но допустим даже нашли способ развернуть один единственный вариант - этого достаточно). И другой вариант: допустим, 256 бит мы займём sha256, а оставшиеся - ещё каким-нить 256-битным хэшом, построенным на немного других математических принципах. Кажется (именно кажется, а как на самом деле я не претендую знать), что этот вариант выглядит немного надёжнее: даже найдя алгоритм разворота sha256, придётся потом ещё искать такой же алгоритм для второго хэша (а учитывая что он математически другой - искать придётся с нуля заново), а так же как-то обеспечить чтобы оба агоритма сгенерили одинаковые данные.

Ну и собственно вопрос: учитывая, что деталей всей этой истории из будущего мы не знаем, а ещё скорее всего не знаем даже современной криптографии, можно ли как-то оценить что из этих двух вариантов имеет больше шансов продержаться подольше?

-------- Уточнения:

1) Я понимаю, что конструкцию из второго варианта тоже можно назвать одним хэшом, и вероятно даже такие хэши свществуют и используются, но речь именно про один математически единый хэш против двух разных алгоритмов меньшей битности.

2) Советы исключительно утилитарного характера «используй то, оно хорошее» не нужны, интересует именно сравнение.

3) Очевидно, что если кто-то научится делать тупой брутфорс 256 и выше битных хэшей, то все рассуждения выше будут полностью бесполезны и хэш взломают независимо от его алгоритма, так что давайте именно про алгоритмический взлом а не про брутфорс.

Обычно h264 упакован в контейнер, например mp4, и в этом контейнере (в блоке moov или moof) указывается pts (presentation time) каждого кадра, то есть порядок их показа. Допустим, moov куда-то потерялся, но остался блок mdat, в нём сырой h264. В нём есть информация о порядке кадров или никак нет?

Когда я сконвертировал mp4 в annexb (тоже можно считать без контейнера) - mpv получившийся файл успешно показывал, и вроде даже нормально выглядело. Хотя, допускаю, что кадры там показывались в порядке кодирования, а я просто не заметил разницы от мелких перестановок.

В ходе неспешной разработки vcs пришла в голову такая идея, но я не уверен что она полезная, вот хочу узнать чьё-нить мнение.

Введение (это не вопрос ещё):

В репе есть разные модели хранения, одна из них - «публикация официальных ревизий» (то есть линейный пронумерованный список релизных/одобренных версий продукта). Очевидно, в целях надёжности эти релизы (включая факт публикации под указанным номером ревизии и, на всякий случай, ссылку на подпись предыдущей) должны быть подписаны владельцем репы или ещё каким ответственным лицом. Эта подпись, кроме защиты от подмены репы путём взлома сервера, её раздающего, так же позволяет зеркалировать репу куда угодно в ненадёжные места, при этом ничем, кроме как запозданием доставки нового релиза, это не будет грозить.

Теперь собственно вопрос. А что, если:

1) право публикации привязать не к одному ключу владельца, а к набору ключей ответственного за публикацию коллектива, и для валидной публикации требовать наличие подписей всех участников, либо какого-то порогового процента их количества

2) список ответственных подписей версионировать, то есть в ревизии номер 137 будет информация о том, как именно должна быть подписана ревизия номер 138

3) для смены информации о правах публикации (список участников и правила подсчёта достаточных голосов) всё та же процедура с подписями, но, возможно, более высокое их пороговое количество, или обязательное наличие среди списка подписей подписи «председателя» (которую, вероятно, тоже можно сменить); при этом так же возможна процедура одностороннего отзыва своего членства - такую ревизию достаточно подписать только одной подписью - того человека, который самоустраняется (хотя тут проблема - это может спровоцировать недопустимое ветвление, возможно нельзя одной и должны одобрить остальные)

На мой взгляд, выглядит красиво, криптографически обеспеченная преемственность, но есть ли тут полезные применения?

С одной стороны, видится полностью отвязанная от физического хранилища сущность, добавление информации в которую делается не на основании доступа к конкретному серверу, а на основании криптографического разрешения. С другой, на практике скорее всего всё равно получится некий сервер с урлом, который люди будут воспринимать как первоисточник, и на котором никто не помешает написать что-то типа «ой, у нас проблемы, старые ключи отменяются, новые такие». Ну или другим способом сделать «хард форк». Даже более того, в этом может возникнуть нужда: какие-нить диверсанты могут в результате многолетней секретной операции по внедрению получить достаточный для принятия любых решений комплект подписей, и испортить проект - не хоронить же его после этого? Ну или просто тупо украсть или отнять ключи у настоящих участников, что может теоретически случиться даже весьма быстро. Или текущие участники могут забить или пропасть без вести.

Что думаете?

Перемещено dataman из security

При запуске гуи-проги (вроде бы - только использующей видеоускорение), на весь экран (размер рабочей зоны окна 1920х1080), xorg начинал жрать 100% проц и подавать признаки жизни раз в 15-20 секунд (выглядело как зависший комп). Если окно открыто не на полный экран, а хотя бы чуть поменьше, или если его видимая зона перекрыта другим окном (я проверял таскбаром, у него ширина около 300 пикселей, другое было бы делать долго и я не стал) - проблема не проявлялась.

После перезапуска xorg-а всё стало норм как и раньше.

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

Касательно того что именно за прога: заметил на xscreensaver, но некоторые лагали, некоторые нет, лагали те что с opengl. Потом пробовал запустить фулскрин mpv - он тоже лагает. xev не лагал, xfce4-terminal не лагал, хотя у последнего ещё меню сверху, возможно оно не «считалось» за размер окна.

Видео nvidia с проприетарным драйвером 490.

В логах dmesg и Xorg.log на момент лагов пусто.

Кто-нить сталкивался?

Диски Seagate ST8000AS0002 (несколько штук, были куплены вместе, работали тоже вместе). По логам обнаружил, что power on hours у них обнулился после примерно 78190 часов, то есть без 4 недель 9 лет. Что это за странное число такое? В побайтовом дампе смарта оно у этих дисков хранится в младших 32 битах поля «raw» в виде часов, то есть это не из-за того что там были минуты или секунды или ещё что-то.

Кто-нить сталкивался?

После запуска иксов он делают мне 3840x1080, рисуя две его 1920х1080 половины на разных видеовыходах. Одноразово исправляется командой

$ xrandr --output HDMI-0 --pos 0x0

$ xrandr --output VGA-0 --pos 0x0

Как это полностью отключить? Подозреваю, что можно в xorg.conf прописать эти pos вручную (кстати, не знаю как). Но лучше не это, а именно вообще отключить этот виртуальный экран, чтобы вне зависимости от конфигурации видеовыходов он никогда не пытался такое делать. Есть такое?

В иксах с помощью xrandr переключается на лету между VGA и HDMI, как сделать то же самое для ядерной консоли? Знаю про прописывание аргументов в grub, но там нужно ребутаться, другие варианты есть? И ещё, желателен режим чтобы на всех видеовыходах была одинаковая картинка (то есть чтобы сделать 1 раз и больше ничего не переключать) - такое можно настроить хоть как-нить?

%Cpu(s): 10,7 us,  4,3 sy,  0,0 ni,  0,0 id, 82,6 wa,  0,0 hi,  2,3 si,  0,0 st

Вопрос вот про «wa». И кстати почему оно считается состоянием проца вообще? Ведь пока процесс ждёт ответ от диска, ядро проца вполне может заниматься чем-то другим. В фрибсд например iowait не считается занятым ядром и в детализации занятости проца его нет.

Происходит сейчас когда разом сотню вкладок в фф закрываю - по минуте и больше может в этом wa всё висеть. Ну то есть тут то понятно кто виноват, но всё равно хотелось бы детализацию по конкретным процессам (у фф их несколько десятков).

Перемещено hobbit из general

Когда подключаю новому диску сата-питание - система теряет (и спустя какое-то время снова находит) диск, подключённый уже раньше к тому же проводу. Ну и слышно как он останавливает шпиндель. Диски, подключённые к другим проводам, не теряются. В некоторых комбинациях дисков (уже включённый и новоподключённый) этого не происходит, но в целом чаще кажется происходит чем нет. Это норм?

Лет 10 назад на старых дисках (blue и подобных на 250гб и меньше) такого ни разу не замечал.

Купил новый хороший БП с большим запасом мощности, засунул в соседний молекс на 5В и 12В линии по low-esr конденсатору 2200мкФ - не помогает ничего.

У меня стандартная процедура доступа к этому счётчику на WD40EFPX (Red Plus 4TB) не работает, диск собственно отклоняет команду его чтения. Я её шлю не через idle3-tools а через фрибсдшный camcontrol в виде блоба байт, но это не важно. На старых дисках (например WD20EFRX Red 2TB, 2015 года) всё работает. А ещё я в инете нашёл жалобы на аналогичную ошибку и из idle3ctl и из hdparm -J, но нигде не нашёл внятные ответы на эти репорты. Может кто на ЛОРе знает точный ответ?

Хотя радует что конкретно у этого диска таймер явно не 8 секунд, но Load Cycle уже стало 2 вместо 1, так что какой-то он есть, сейчас ставлю опыты. Возможно исправлять его и не требуется, но хотелось бы знать остался ли к нему доступ.

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +41.5°C  (high = +70.0°C)
                       (crit = +72.0°C, hyst = +70.0°C)

it8718-isa-0228
Adapter: ISA adapter
in0:           1.46 V  (min =  +0.00 V, max =  +4.08 V)
in1:           1.60 V  (min =  +0.00 V, max =  +4.08 V)
in2:           3.26 V  (min =  +0.00 V, max =  +4.08 V)
+5V:           2.98 V  (min =  +0.00 V, max =  +4.08 V)
in4:           3.02 V  (min =  +0.00 V, max =  +4.08 V)
in5:           3.14 V  (min =  +0.00 V, max =  +4.08 V)
in6:           4.08 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
in7:           2.74 V  (min =  +0.00 V, max =  +4.08 V)
Vbat:          3.31 V  
fan1:        1163 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +51.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermal diode
temp3:        +48.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:    +1.050 V
intrusion0:  ALARM

Вот эти in0 in1 итд это что такое? На in6 ещё ALARM какой-то.

Почему пишет +5V 2.98V? Померил вручную на molex разъёме - на 5В нормальные 5В.

Обнаружил странности с ценами (смотрю WD): все диски меньше 2ТБ стоят как 2ТБ (даже 320ГБ) - примерно 5к, а если это Red/Black - то все что меньше 4ТБ стоят как 4ТБ (от 10-12к).

Это всмысле что теперь объём от 2ТБ (или 4ТБ для ответственных мест), а всё что меньше позиционируется как «ну хочешь меньше - дадим меньше за ту же цену»? Или я где-то не там смотрю (всякие алиэкпрессы и прочие помойки в расчёт не берём)?

Диск отвалился по таймауту, спустя 10 часов я это заметил и выключил-включил электричество системному блоку - диск ожил. Хотел посмотреть в смарте что-нить а там всё по нулям, power on hours = 1, power cycle count = 1. Как так, было у кого-нить похожее? Диск WD5000AZRX firmware 01.01A01.

Подозреваю что диск стоит сменить, но всё равно интересно как такое случилось.

Наконец-то дошло дело установить купленный зимой новый монитор (MSI Pro MP271A E2), во всех инет описаниях и у него на коробке написано что он поддерживает 120Гц через HDMI. Видеокарта GeForce GT 610.

xrandr предлагает такое:

HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   1920x1080     60.00 +  99.65*   84.90    59.94    50.00  
   1680x1050     59.95  
   1440x900      59.89  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    56.25    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  

В логе Xorg есть такое:

[2322751.769] (--) NVIDIA(GPU-0): CRT-0: disconnected
[2322751.769] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[2322751.770] (--) NVIDIA(GPU-0):
[2322751.781] (--) NVIDIA(GPU-0): CRT-1: connected
[2322751.781] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[2322751.781] (--) NVIDIA(GPU-0):
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: disconnected
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
[2322751.785] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
[2322751.785] (--) NVIDIA(GPU-0):
[2322751.799] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): connected
[2322751.800] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): Internal TMDS
[2322751.800] (--) NVIDIA(GPU-0): Microstep MSI MP271A E2 (DFP-1): 230.0 MHz maximum pixel clock

230MHz для 1920x1080 и правда никак не позволит сделать 120Гц: 230000000/1920/1080=110, а там ещё межстрочные/межкадровые интервалы какие-то должны быть, так что видимо как раз 100Гц и выходит.

Не то что бы мне очень хотелось 120Гц, но раз они заявлены то неприятно что почему-то не дают их выставить.

Вот это 230МГц pixel clock это чьё ограничение? И там рядом 400 и 330 МГц - они чьи?

------------

Сделал xrandr --prop, edid оттуда отправил программе edid-decode, результат (конец)

  Detailed Timing Descriptors:
    DTD 2:  1920x1080   84.905 Hz  16:9    95.433 kHz 198.500 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  36 Vpol N
    DTD 3:  1920x1080   99.650 Hz  16:9   109.615 kHz 228.000 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  12 Vpol N
    DTD 4:  1920x1080  119.982 Hz  16:9   137.260 kHz 285.500 MHz (598 mm x 336 mm)
                 Hfront   48 Hsync  32 Hback  80 Hpol P
                 Vfront    3 Vsync   5 Vback  56 Vpol N

[Вс апр  6 20:34:58 2025] usb 1-4: new high-speed USB device number 5 using ehci-pci
[Вс апр  6 20:34:58 2025] usb 1-4: New USB device found, idVendor=03f0, idProduct=3d17, bcdDevice= 1.00
[Вс апр  6 20:34:58 2025] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Вс апр  6 20:34:58 2025] usb 1-4: Product: HP LaserJet P1005
[Вс апр  6 20:34:58 2025] usb 1-4: Manufacturer: Hewlett-Packard
[Вс апр  6 20:34:58 2025] usb 1-4: SerialNumber: LC00FTQ
[Вс апр  6 20:34:58 2025] usblp 1-4:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x03F0 pid 0x3D17
[Вс апр  6 20:35:02 2025] usblp0: removed
[Вс апр  6 20:39:49 2025] usb 1-4: USB disconnect, device number 5

Включаю принтер в usb, через какое-то время появляется /dev/usb/lp0, проходит ещё 5 сек и оно исчезает (предпоследняя строчка лога). Последняя строчка это я вытащил кабель. В lsusb он виден всё время пока кабель вставлен.

Раньше всё работало (не помню когда точно, но вроде уже этот релиз стоял - Devuan 4, это аналог Debian 11), на ноутбуке рядом (там Debian 11) тоже удаляется. Если пока он есть успеть отправить туда firmware - принтер реагирует на неё как раньше (крутит валиком). Но потом всё равно удаляется.

Почему это может быть?

Линуксовый multipathd как-то автоматически распознаёт что например sdc и sdf - два пути к одному и тому же «диску» (речь про первое его подключение, когда никаких данных там ещё не записано). Мне лень изучать его исходники, как он это делает?

Фрибсд так не умеет, там надо вручную задавать устройства, хочу тоже автоматизировать. Из доступной информации вижу: номер шины, номер таргета на шине, номер луна, wwpn (идентификатор порта лун-провайдера). Из всего этого совпадают только номера лунов, но номер луна может совпасть и у разных дисков.

Системг обнаружил, что физическое устройство, на которое был по его мнению смонтирован путь, исчезло, и размонтирует его. Я монтирую - он сразу опять размонтирует (пишет в лог). Как это прекратить? Путь разумеется монтируется на уже новое устройство которое есть. В fstab ничего не менялось т.к. UUID у него тот же - он скопирован через dd.

Нужно чтобы демон думал что к нему подключаются из инета, хотя на самом деле к нему подключается другая локальная прога. В этой проге я включаю на сокет опцию O_BINDANY, делаю bind() на внешний поддельный айпи-адрес и затем connect() к адресу демона.

Из tcpdump-ов выяснилось, что TCP SYN идёт правильно через локалхост от моей проги к демону, а вот SYN+ACK ответ отправляется в настоящий интернет через сетевуху, до моей проги не доходит. Как ему объяснить что он тоже должен через локалхост идти? Напрашивается ipfw fwd, но ему же надо айпи+порт куда заворачивать указывать, а он там поддельный и к тому же каждый раз разный.

Вообще я думал что при наличии локального сокета с нужным ip+port+ip+port пакеты должны попадать сразу в него вне зависимости от того, какому интерфейсу это всё принадлежит, но оказывается нет.

Я не удивлюсь, если там в библиотеке фундаментальный дефект на этот счёт, но возможно это просто непонятные маны.

Исходные данные:

1) есть функция int SSL_shutdown(SSL *ssl);

Краткое содержание мана: функция отправляет «close notify alert» и иногда ещё и принимает ответ на него (тоже «close notify alert») от той стороны. Возвращает: -1 если произошла ошибка либо нужно ждать читаемости/записываемости сокета, 0 если «close notify alert» отправлен успешно, но ответный ещё не получен, и 1, если и отправлен и получен.

Касательно возврата 0 там есть три пояснения:

а) если мы планируем закрывать сокет то можно этим и ограничиться и ответ не ждать

б) есть рекомендация вызвать SSL_shutdown() повторно чтобы принять ответ

в) есть рекомендация вызвать SSL_read() повторно чтобы принять ответ - да, в том же мане 4 абзацами ниже предыдущего утверждения, которому оно немного противоречит (подозреваю речь идет про SSL_ERROR_ZERO_RETURN, см. ниже, но это догадка)

2) есть ошибка SSL_ERROR_ZERO_RETURN, в мане к SSL_get_error описанная так: та сторона закрыла соединение для записи, отправив «close notify alert», читать данные больше нельзя (и уточнение что речь не идёт о сокете, а только об ssl-сессии).

Описание очень похоже на описание нуля, возвращённого из recv() для обычных BSD-сокетов, однако в инете я нашёл ряд репортов про получение этой ошибки от SSL_write(), так что кажется её может делать и он. Тут непонятно: ман говорит что нельзя больше читать, а оказывается что и запись тоже блокируется? В SSL/TLS вообще есть такое явление как наполовину закрытый поток, когда одна сторона завершила отправку и уведомила об этом, а потом только принимает ответ?

В мане какие-то мутные намёки на то, как будто оно есть, но не уточнено как с ним обращаться. Например, как известно, TLS иногда шлёт какие-то служебные данные, которые в итоге прозрачно обрабатываются во время вызова SSL_read/SSL_write. Пока соединение полностью открыто, с ними всё просто: узнаём что на уровне сокетов что-то пришло, вызывает SSL_read(), тот уже либо выяснит что это полезные данные и выдаст нам их, либо примет и обработает служебные и скажет что пользовательских пока нет. Если же та сторона сделала shutdown и нам SSL_read возвращает только SSL_ERROR_ZERO_RETURN, то кем читать пришедшие байты? SSL_write не годится, если мы пока что не хотим ничего записывать, а оставлять их в сокете тоже нельзя - они будут постоянно триггерить select() или его аналоги. Убирать сокет из select-а тоже нельзя - тогда мы не узнаем если он вдруг закроется уже на уровне tcp.

Или, может быть, всё проще, и SSL_ERROR_ZERO_RETURN следует считать как «соединение умерло, закрываем всё что осталось», а в мане просто враньё? Смущает фраза из мана SSL_shutdown: «the peer is still allowed to send data after receiving the close_notify event», и рядом ещё ода рекомендация использовать именно SSL_read вместо повторного SSL_shutdown.

Судя по веб-архиву, 22-24 июля 2024 они его сделали. Зашёл посмотреть, первое что подумал - что они просрочили домен и его захватили киберсквоттеры, как с bzip2 случилось. Но походу это не так и сайт настоящий. Точнее, теперь у них 9 (может не все нашёл) сайтов - по отдельному домену 2 уровня на каждый «раздел». Напомнило сайты известного наверно автора rus-os.narod.ru, но у того оно всё 3-го уровня на бесплатном хостинге было в тут вот так.

Или может всё-таки у них что-то случилось, например проект приобрели какие-то эффективные бизнесмены?