Умные образованные «плохие парни» могут сами поднять IRC/Jabber сервер и общаться себе свободно (и законно). Но тогда они не пойдут в публичные IRC/Jabber сети. И в Ватсап с Вайбером не пойдут, скорее всего.
А вот прочим мешает резкое падение популярности IRC и Jabber через смерть серверов, отсутствие нормальных клиентов для мобильных устройств и, в конце концов, чтобы забить гвоздь, нужно знать, что гвозди вообще существуют.
И пока во всяких «ватсапах» в РФ сидят десятки миллионов, а в IRC — меньше тысячи, то, да, вероятность обнаружить объект интереса в IRC заметно, заметно меньше. И будет ещё меньше, исчезающе меньше в ближайшие годы (судя по тенденции).
А так, да, конечно, могут собраться и пообсуждать.
Вполне себе показатель, ибо мы говорим о РФ и соблюдении законов РФ на территории РФ. С технической точки зрения — это локализация сервисов — выполнения правил могут требовать только для соединений с адресов из РФ.
Более того, если возвращаться к цифрам: год назад в RusNet было три тысячи пользователей, десять лет назад — тридцать. Тенденция, как говорится, на лицо. Подозреваю, что на freenode подобное же состояние (у кого есть статистика?).
Простые люди ушли из IRC сначала в более удобные для них соц. сети, а потом в мобильные мессенджеры. В IRC остаются только некоторые категории технически подкованных людей.
P.S. Комнаты в Jabber (если память не изменяет), а в IRC — каналы.
С IRC уже ничего не нужно делать, например, RusNet:
17:05 -!- There are 786 users and 0 services on 16 servers
Из них треть — боты, часто забытые, ещё треть — полумёртвые BNC. IRC перешёл в разряд неуловимого Джо. С Jabber ситуация не лучше: у меня никого из старых контактов там не осталось уже (но Jabber как рабочий мессенджер живее всех живых).
Полагаю, что у вас неправильное понимание, кто такие «совы» и «жаворонки». Это не те, кто ложатся/просыпаются поздно и рано, соответственно — это группы с разными биологическими сутками: длинными и короткими, соответственно.
«Совам» мало 24 часов в сутки, «жаворонкам» — много. Вот именно поэтому первые запросто могут засидеться подольше, откладывая сон, а вторые лечь пораньше, потому что нет сил. При этом и те, и те могут вставать в одно и то же время вынужденно (как делает большинство в нашей европейской цивилизации).
И, конечно, длина биологических суток величина непостоянная: меняется от состояния здоровья, перемены нагрузок, климата и возраста.
P.S. Предупреждая тех, кто скажет, что нужно просто больше работать (точнее, уставать): это так не работает. При повышении нагрузки биологические сутки уменьшатся, но ненадолго — со временем произойдёт привыкание и всё вернётся к прежним значениям.
То, что язык позволяет выстрелить себе в ногу, не значит, что в неё нужно стрелять. Да, тип в Си нужно читать тип справа налево, что несколько непривычно и неудобно. Но главное: не нужно так делать: нужно разделять абстракции. Именно поэтому есть typedef: и всё резко начинает быть простым и понятным.
P.S. Да, можно возразить, что описание типа в алголоподобном (паскале-/модула-/оберон- — и т.п.) виде слева направо удобнее читается и без разделения на абстракции. Но, скорее всего, вы очень быстро устанете от такого чтения и точно так же начнёте путаться. Почему оно так в Си получилось: по историческим причинам из-за совместимости с B и ранними диалектами K&R C.
По-моему, одним из лучших в мире курсов, является старый курс от MIT: «Structure and Interpretation of Computer Programs» — при чём именно в изначальном его виде, с примерами и заданиями на Scheme.
Только не надо смотреть на Lisp/Scheme и убегать — это не учебник по программированию на каком-либо языке, это учебник по дисциплине «программирование». (К тому же, у вас явно не хватает в копилке функционального подхода.)
P.S. Лет восемь — десять назад MIT поддалась тренду и перевела сей курс на Python. Не ищите его, читайте оригинальный.
P.P.S. Нет, я совсем не любитель lisp-подобных языков: даже, скорее, где-то противник. Но здесь это именно то, что нужно.
Почему нельзя было придумать что-нибудь более внятное наподобие ESI/EDI и квадратных скобок?
Так оно и есть же! *(2 + p) и p[2] — одно и то же. Более того, 2[p] — ровно то же самое. Только операции производятся в единицах размера объекта: нет полутора землекопов. И да, для многих архитектур на ассемблере тоже можно указать размер объекта при индексации.
Кстати, С является подмножеством С++, поэтому можно убить двух зайцев одним выстрелом.
Глубокое заблуждение — это два несовместимых языка со своими особенностями, хоть и общей историей и взаимными заимствованиями.
P.S. Да, можно написать код, который будет компилироваться и работать и как C, и как C++, но это будет плохой код: как минимум, он будет использовать неканонические конструкции.
P.P.S. Для изучения Си — только Керниган и Ритчи в последней редакции, плюс изучение нововведений С99 и С11.
Возможно, точно так же, как в случае, когда функциональность ещё не реализована? Ну, может быть, добавится ещё один пункт: изучение текущей реализации. Просто теперь будут другие оценки времени на выполнение требований.
Если SRS ещё нет — её нужно разработать, если есть — адаптировать. Затем на основе SRS разработать/адаптировать HLD. (По сути, написать/адаптировать документацию и ПМИ. Нужен ли далее DLD или в качестве него будет выступать непосредственно патч изменений — это уже зависит от размера компонента.)
У языков семейства Lisp фактически нет синтаксиса — пользователь сразу пишет AST. (Ну а для записи AST достаточно простой рекурсивно-регулярной грамматики.)
Хорошо это или плохо — Holy War: лично я принадлежу к тем, кому нравятся языки с более богатым синтаксисом, другие же предпочитают «AST прямо в мозг».
Они ничем не отличаются от раздельных, кроме того, что в один DIN 6 разъём вывели два PS/2 порта. Более того, судя по всему, такой порт позволяет подключать клавиатуру и без Y-сплиттера:
Видимо, такой порт появился исключительно ради экономии при практически полном исчезновении PS/2 мышек в современном мире.
P.S. Теоретически, драйвер может отличить клавиатуру от мыши по протоколу и, если при подключении в обычный PS/2 порт «чужого» устройства оно определяется корректно, то и мышь будет работать в таком разъёме без сплиттера. (Тут нужна поддержка и от BIOS, и от ОС.)
(Тут, судя по коду, ISO_Last_Group — вторая группа.) Не забыть потом добавить setxkbmap в автозагрузку при старте (тут много путей, в зависимости от используемого WM/DM).
Ну а Ctrl-C, Ctrl-V и иже с ними должны работать независимо от раскладки, если приложение не кривое, т.к. должны смотреть на клавиши до преобразования… Для кривых приложений, в принципе, можно сделать отображение: принцип тот же, примеры искать там же )
P.S. Ну а для своего любимого DM лучше запостить feature request (или даже merge request, если есть знания и силы реализовать).
Не надо ничего менять, оставьте клавиатуру в покое. И так головная боль от того, что каждый производитель пытает что-то придумать своё, по-своему расположить клавиши…
К тому же она прекрасно настраивается под альтернативные раскладки, если нужно: мне, например, удобнее AltGr для переключения раскладок, а CapsLock у меня — Compose для ввода тире, кавычек-«ёлочек», греческих букв и некоторых математических знаков. («α» ∂ξ — красота! только стрелочка вперёд-назад почему-то не отображается после преобразования MarkDown в HTML 8/)
Если в вашей любимой проприетарной ОС это трудно сделать стандартным способом, дак напишите в поддержку: если вас будут тысячи — вас заметят. В X.Org есть xkcb и XCompose (я использую его с uim-xim). KDE/Gnome позволяют (пере)назначать действия на клавиши по вашему усмотрению.
P.S. И нет, я не против альтернативных клавиатур, но именно как альтернативных — либо покупаемых отдельно в случае отдельных устройств, либо как опция там, где они встроены.
Поддержка ГОСТ-ов в CERT_ExtractPublicKey естественно есть с полным разбором ключей. Иначе бы ничего не работало!
Тогда зачем мы вычисляем хаком тип хеш-функции вместо получения его непосредственно из параметра ключа, где он есть (явно или не явно)?
Я про switch(pubk->keyType) для вычисления hashType (и прочих параметров) — вот последний и нужно извлекать непосредственно из pubk, а не гадать.
То что гостовую подпись можно получить от любого хэша — понятно. С этого и началась статья.
Эм, нет, там всё хуже:
Digest Algorithm (1): SHA-256
Signature Algorithm: GOST R 34.10-2012 signature with GOST R 34.11-2012-512
— Это не ECGOST + SHA2, а диназавробегемот — в одном месте SHA2, в другом необрезанный Стрибог.
UPD: Если извлекать алгоритм хеша из pubk, то у нас и ECDSA+SHA3 заработает в LibreOffice, и ECKDSA с ECGDSA, если (или когда) они будут реализованы в NSS.
Суть замечания была не в этом, а в том, что с точки зрения разработки сил то не много нужно было.
А вот теперь, посмотрев на ссылку под статьёй и в комментарии я по-другому перечитал комментируемый комментарий («сил и средств»).
У нас не было задачи сертифицировать СКЗИ, у нас МЭ и работы, основанные на нём, где было прописано только «использование российской криптографии». Понадобилась поддержка новых алгоритмов — реализовали быстро.
P.S. Посмотрел историю: ТК26 OIDы для 34.11-2012 у нас добавлены через неделю после собственно 34.11-2012 в один день с добавлением 34.10-2012, а вот 34.10-2012-512 парамсеты от ТК26 на пару месяцев позже.
UPD: А вот и проект рекомендации ТК26 по данному вопросу — первая редакция от апреля 2014-го… Вот такие документы, по-моему, должны выпускаться одновременно с принятием нового стандарта, пакетом.
Да, тут для разных схем выделили по идентификатору. Только вот конкретно в нашем случае у нас схема одна и та же (мы говорим про 34.10).
Более того, описываемое решение некорректно: тот же алгоритм хеширования задан в параметрах алгоритма подписи в SubjectPublicKeyInfo и должен быть прочитан и содержаться внутри SECKEYPublicKey к моменту возврата из CERT_ExtractPublicKey.
Кроме него есть и параметры эллиптической кривой (минимум пять больших чисел), в случае 34.11-94 ещё и S-Box, а для любого хеша, вообще говоря, можно ещё и альтернативный IV задавать.
И мы никак это не запихаем в идентификаторы перечисления.
Вот для ECDSA, ECKDSA, ECGOST и ECGDSA можно и имеет смысл выделить по отдельному идентификатору (имя KeyType тут прямо об этом и просит).
Так что, думаю, нужно сначала научить CERT_ExtractPublicKey проверять параметры ключа, как минимум, определять функцию хеширования. Заменить жёстко прописанное использование SHA2 так, как это делается здесь. А потом добавить уже поддержку ГОСТовых алгоритмов в CERT_ExtractPublicKey.
P.S. А ещё PKIX не мешает нам использовать 34.11 с ECDSA и SHA-* с ECGOST. Да, ни одна из таких схем не пройдёт сертификацию ни FIPS, ни ФСБ на СКЗИ, но подавляющему большинству такая сертификация и не нужна.
Лично мы сделали аж две независимые реализации Стрибога в январе 2013-го, обнаружив после новогодних каникул факт принятия стандартов. Вот с 34.10 хуже — пришлось ждать OIDы от Крипто-Про и ТК26 (и параметры кривой для 512).
Даже более, скорее всего, ни одна из этих новых констант не нужна: если ecKey это то, что используется для ECDSA, то там всё уже есть — параметры кривых можно задавать в том же формате, поле для параметризации по алгоритму хеширования тоже должно быть.
Но, в то же время, ECDSA, ECKDSA и ECGOST (и ещё какой-то европейский стандартный алгоритм) хоть и используют одинаковую математику на эллиптических кривых, но процедуры вычисления и проверки подписи у них разные.
UPD: «Какой-то европейский», скорее всего, ECGDSA от Siemens.
А ключи ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012-256 байт используют один и тот же алгоритм, но у них разные параметры (curve).
Они могут использовать одинаковые параметры эллиптики и, de facto, используют одинаковые параметры эллиптики: достаточно посмотреть в текст соответствующих стандартов — там даже примеры абсолютно совпадают. И используемые на практике параметры от Крипто-Про также идентичны, см. RFC 7836, п. 5.1:
In case of elliptic curves with 256-bit prime moduli, the parameters defined in [RFC4357] are proposed for use.
Умные образованные «плохие парни» могут сами поднять IRC/Jabber сервер и общаться себе свободно (и законно). Но тогда они не пойдут в публичные IRC/Jabber сети. И в Ватсап с Вайбером не пойдут, скорее всего.
А вот прочим мешает резкое падение популярности IRC и Jabber через смерть серверов, отсутствие нормальных клиентов для мобильных устройств и, в конце концов, чтобы забить гвоздь, нужно знать, что гвозди вообще существуют.
И пока во всяких «ватсапах» в РФ сидят десятки миллионов, а в IRC — меньше тысячи, то, да, вероятность обнаружить объект интереса в IRC заметно, заметно меньше. И будет ещё меньше, исчезающе меньше в ближайшие годы (судя по тенденции).
А так, да, конечно, могут собраться и пообсуждать.
Вполне себе показатель, ибо мы говорим о РФ и соблюдении законов РФ на территории РФ. С технической точки зрения — это локализация сервисов — выполнения правил могут требовать только для соединений с адресов из РФ.
Более того, если возвращаться к цифрам: год назад в RusNet было три тысячи пользователей, десять лет назад — тридцать. Тенденция, как говорится, на лицо. Подозреваю, что на freenode подобное же состояние (у кого есть статистика?).
Простые люди ушли из IRC сначала в более удобные для них соц. сети, а потом в мобильные мессенджеры. В IRC остаются только некоторые категории технически подкованных людей.
P.S. Комнаты в Jabber (если память не изменяет), а в IRC — каналы.
С IRC уже ничего не нужно делать, например, RusNet:
Из них треть — боты, часто забытые, ещё треть — полумёртвые BNC. IRC перешёл в разряд неуловимого Джо. С Jabber ситуация не лучше: у меня никого из старых контактов там не осталось уже (но Jabber как рабочий мессенджер живее всех живых).
Полагаю, что у вас неправильное понимание, кто такие «совы» и «жаворонки». Это не те, кто ложатся/просыпаются поздно и рано, соответственно — это группы с разными биологическими сутками: длинными и короткими, соответственно.
«Совам» мало 24 часов в сутки, «жаворонкам» — много. Вот именно поэтому первые запросто могут засидеться подольше, откладывая сон, а вторые лечь пораньше, потому что нет сил. При этом и те, и те могут вставать в одно и то же время вынужденно (как делает большинство в нашей европейской цивилизации).
И, конечно, длина биологических суток величина непостоянная: меняется от состояния здоровья, перемены нагрузок, климата и возраста.
P.S. Предупреждая тех, кто скажет, что нужно просто больше работать (точнее, уставать): это так не работает. При повышении нагрузки биологические сутки уменьшатся, но ненадолго — со временем произойдёт привыкание и всё вернётся к прежним значениям.
То, что язык позволяет выстрелить себе в ногу, не значит, что в неё нужно стрелять. Да, тип в Си нужно читать тип справа налево, что несколько непривычно и неудобно. Но главное: не нужно так делать: нужно разделять абстракции. Именно поэтому есть typedef: и всё резко начинает быть простым и понятным.
P.S. Да, можно возразить, что описание типа в алголоподобном (паскале-/модула-/оберон- — и т.п.) виде слева направо удобнее читается и без разделения на абстракции. Но, скорее всего, вы очень быстро устанете от такого чтения и точно так же начнёте путаться. Почему оно так в Си получилось: по историческим причинам из-за совместимости с B и ранними диалектами K&R C.
По-моему, одним из лучших в мире курсов, является старый курс от MIT: «Structure and Interpretation of Computer Programs» — при чём именно в изначальном его виде, с примерами и заданиями на Scheme.
Только не надо смотреть на Lisp/Scheme и убегать — это не учебник по программированию на каком-либо языке, это учебник по дисциплине «программирование». (К тому же, у вас явно не хватает в копилке функционального подхода.)
P.S. Лет восемь — десять назад MIT поддалась тренду и перевела сей курс на Python. Не ищите его, читайте оригинальный.
P.P.S. Нет, я совсем не любитель lisp-подобных языков: даже, скорее, где-то противник. Но здесь это именно то, что нужно.
Так оно и есть же!
*(2 + p)иp[2]— одно и то же. Более того,2[p]— ровно то же самое. Только операции производятся в единицах размера объекта: нет полутора землекопов. И да, для многих архитектур на ассемблере тоже можно указать размер объекта при индексации.Глубокое заблуждение — это два несовместимых языка со своими особенностями, хоть и общей историей и взаимными заимствованиями.
P.S. Да, можно написать код, который будет компилироваться и работать и как C, и как C++, но это будет плохой код: как минимум, он будет использовать неканонические конструкции.
P.P.S. Для изучения Си — только Керниган и Ритчи в последней редакции, плюс изучение нововведений С99 и С11.
Долго думал, что же такое «type output», и понял только переведя на русский и прочитав снова: всё таки, «type inference».
P.S. Полное понимание данного комментария требует знания русского, не зависимо от, того, на каком языке он написан, а основной посыл поймут все.
Возможно, точно так же, как в случае, когда функциональность ещё не реализована? Ну, может быть, добавится ещё один пункт: изучение текущей реализации. Просто теперь будут другие оценки времени на выполнение требований.
Если SRS ещё нет — её нужно разработать, если есть — адаптировать. Затем на основе SRS разработать/адаптировать HLD. (По сути, написать/адаптировать документацию и ПМИ. Нужен ли далее DLD или в качестве него будет выступать непосредственно патч изменений — это уже зависит от размера компонента.)
У языков семейства Lisp фактически нет синтаксиса — пользователь сразу пишет AST. (Ну а для записи AST достаточно простой рекурсивно-регулярной грамматики.)
Хорошо это или плохо — Holy War: лично я принадлежу к тем, кому нравятся языки с более богатым синтаксисом, другие же предпочитают «AST прямо в мозг».
Они ничем не отличаются от раздельных, кроме того, что в один DIN 6 разъём вывели два PS/2 порта. Более того, судя по всему, такой порт позволяет подключать клавиатуру и без Y-сплиттера:
Видимо, такой порт появился исключительно ради экономии при практически полном исчезновении PS/2 мышек в современном мире.
P.S. Теоретически, драйвер может отличить клавиатуру от мыши по протоколу и, если при подключении в обычный PS/2 порт «чужого» устройства оно определяется корректно, то и мышь будет работать в таком разъёме без сплиттера. (Тут нужна поддержка и от BIOS, и от ОС.)
Смотреть в setxkbmap(1) (setxkbmap -print для начала) и в xkeyboard-config(7). Потом смотрим в и около:
Как пример используем lctrl_lwin_rctrl_menu, находим в /usr/share/X11/xkb/symbols/group:
Пишем по образу и подобию для себя, перед этим определив ISO_Second_Group, ISO_Third_Group и т.д., смотрим в /usr/share/X11/xkb/compat/iso9995:
(Тут, судя по коду, ISO_Last_Group — вторая группа.) Не забыть потом добавить setxkbmap в автозагрузку при старте (тут много путей, в зависимости от используемого WM/DM).
Ну а Ctrl-C, Ctrl-V и иже с ними должны работать независимо от раскладки, если приложение не кривое, т.к. должны смотреть на клавиши до преобразования… Для кривых приложений, в принципе, можно сделать отображение: принцип тот же, примеры искать там же )
P.S. Ну а для своего любимого DM лучше запостить feature request (или даже merge request, если есть знания и силы реализовать).
К тому же она прекрасно настраивается под альтернативные раскладки, если нужно: мне, например, удобнее AltGr для переключения раскладок, а CapsLock у меня — Compose для ввода тире, кавычек-«ёлочек», греческих букв и некоторых математических знаков. («α» ∂ξ — красота! только стрелочка вперёд-назад почему-то не отображается после преобразования MarkDown в HTML 8/)
Если в вашей любимой проприетарной ОС это трудно сделать стандартным способом, дак напишите в поддержку: если вас будут тысячи — вас заметят. В X.Org есть xkcb и XCompose (я использую его с uim-xim). KDE/Gnome позволяют (пере)назначать действия на клавиши по вашему усмотрению.
P.S. И нет, я не против альтернативных клавиатур, но именно как альтернативных — либо покупаемых отдельно в случае отдельных устройств, либо как опция там, где они встроены.
Тогда зачем мы вычисляем хаком тип хеш-функции вместо получения его непосредственно из параметра ключа, где он есть (явно или не явно)?
Я про
switch(pubk->keyType)для вычисления hashType (и прочих параметров) — вот последний и нужно извлекать непосредственно из pubk, а не гадать.Эм, нет, там всё хуже:
— Это не ECGOST + SHA2, а диназавробегемот — в одном месте SHA2, в другом необрезанный Стрибог.
UPD: Если извлекать алгоритм хеша из pubk, то у нас и ECDSA+SHA3 заработает в LibreOffice, и ECKDSA с ECGDSA, если (или когда) они будут реализованы в NSS.
Суть замечания была не в этом, а в том, что с точки зрения разработки сил то не много нужно было.
А вот теперь, посмотрев на ссылку под статьёй и в комментарии я по-другому перечитал комментируемый комментарий («сил и средств»).
У нас не было задачи сертифицировать СКЗИ, у нас МЭ и работы, основанные на нём, где было прописано только «использование российской криптографии». Понадобилась поддержка новых алгоритмов — реализовали быстро.
P.S. Посмотрел историю: ТК26 OIDы для 34.11-2012 у нас добавлены через неделю после собственно 34.11-2012 в один день с добавлением 34.10-2012, а вот 34.10-2012-512 парамсеты от ТК26 на пару месяцев позже.
UPD: А вот и проект рекомендации ТК26 по данному вопросу — первая редакция от апреля 2014-го… Вот такие документы, по-моему, должны выпускаться одновременно с принятием нового стандарта, пакетом.
Да, тут для разных схем выделили по идентификатору. Только вот конкретно в нашем случае у нас схема одна и та же (мы говорим про 34.10).
Более того, описываемое решение некорректно: тот же алгоритм хеширования задан в параметрах алгоритма подписи в SubjectPublicKeyInfo и должен быть прочитан и содержаться внутри SECKEYPublicKey к моменту возврата из CERT_ExtractPublicKey.
Кроме него есть и параметры эллиптической кривой (минимум пять больших чисел), в случае 34.11-94 ещё и S-Box, а для любого хеша, вообще говоря, можно ещё и альтернативный IV задавать.
И мы никак это не запихаем в идентификаторы перечисления.
Вот для ECDSA, ECKDSA, ECGOST и ECGDSA можно и имеет смысл выделить по отдельному идентификатору (имя KeyType тут прямо об этом и просит).
Так что, думаю, нужно сначала научить CERT_ExtractPublicKey проверять параметры ключа, как минимум, определять функцию хеширования. Заменить жёстко прописанное использование SHA2 так, как это делается здесь. А потом добавить уже поддержку ГОСТовых алгоритмов в CERT_ExtractPublicKey.
P.S. А ещё PKIX не мешает нам использовать 34.11 с ECDSA и SHA-* с ECGOST. Да, ни одна из таких схем не пройдёт сертификацию ни FIPS, ни ФСБ на СКЗИ, но подавляющему большинству такая сертификация и не нужна.
Даже более, скорее всего, ни одна из этих новых констант не нужна: если ecKey это то, что используется для ECDSA, то там всё уже есть — параметры кривых можно задавать в том же формате, поле для параметризации по алгоритму хеширования тоже должно быть.
Но, в то же время, ECDSA, ECKDSA и ECGOST (и ещё какой-то европейский стандартный алгоритм) хоть и используют одинаковую математику на эллиптических кривых, но процедуры вычисления и проверки подписи у них разные.
UPD: «Какой-то европейский», скорее всего, ECGDSA от Siemens.
Они могут использовать одинаковые параметры эллиптики и, de facto, используют одинаковые параметры эллиптики: достаточно посмотреть в текст соответствующих стандартов — там даже примеры абсолютно совпадают. И используемые на практике параметры от Крипто-Про также идентичны, см. RFC 7836, п. 5.1:
Что у них разное, дак это алгоритм хеша.