LINUX.ORG.RU

Messaging Layer Security принят в качестве стандарта RFC

 , , ,


2

3

После многих лет разработки, протокол MLS наконец-то опубликован как стандарт RFC за номером 9420.

MLS позволяет организовать оконечное шифрование (End-to-End Encryption, E2EE) между неограниченным количеством участников. Главным отличием от существующих протоколов, таких как Proteus, Signal и т.д., является отсутствие привязки к конкретному сервису, что допускает его использование как поверх существующих протоколов, так и в рамках новых сервисов обмена сообщениями. Также стоит заметить, что в MLS реализован новый алгоритм обмена ключами, из-за чего отправка сообщений группе участников имеет логарифмическую сложность, а не линейную, что позволит использовать MLS в группах с тысячами и более участников, как например списки рассылок.

Среди сервисов, планирующих использовать MLS, можно отметить Matrix, Wire, Google и Facebook. Работники последних трёх так же принимали участие в разработке этого протокола.

Для желающих использовать протокол в своих разработках представлена реализация OpenMLS на языке Rust. OpenMLS опубликована под лицензией MIT.

>>> Краткий обзор протокола

>>> Официальный сайт

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 4)
Ответ на: комментарий от Croco

Слушай, ну а вот как мне ещё объяснить твою религиозную убеждённость в том, что СУБД – это быстро и производительно? Откуда они должны брать эту свою быстроту и производительность?

Конечный продукт складывается их скорости разработки, стоимости разработки, скорости и стоимости внесения изменений и поддержки, надёжности и так далее. Скорость и производительность – ничтожный аспект для большинства проектов. Просто потому доработка будет дороже, чем аренда сервера.

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

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

Простыми словами, задачу ставит дело (бизнес, если угодно). И исходить имеет смысл именно из этого. Потому что приложение – средство, а не цель.

thegoldone ★★
()
Ответ на: комментарий от thegoldone

На самом деле, он в каком-то смысле прав. Если бы у него страница с комментами условно генерилась бы один раз и чанковалась тупо по смещению, это реально было бы быстрее.

Проблема гения программирования в том, что его поделка перечитывает всю иерархию директорий КАЖДЫЙ МАТЬ ЕГО РАЗ НА КАЖДОМ МАТЬ ЕГО GET РЕКВЕСТЕ. Поэтому вместо пары сотен наносекунд, которые потребовались бы той же sqlite чтобы отдать все дерево комментов, загрузка html странички размером 4k занимает 300ms.

То есть, ещё раз: на каждый запрос GET создается отдельная программа, которая каждый раз парсит файлы, каждый раз строит дерево комментов, каждый раз его рендерит.

А самое смешное в том, что есть undeadly.org. Он тоже написан упоротыми опенбсдшниками на C и вроде даже без базы данных, только работает гораздо быстрее. Потому что упоротые опенбсдшники, внезапно, умеют писать на C.

Вот, зацени:

$ /usr/bin/time -p curl -o /tmp/stolyarov -sLX GET 'http://stolyarov.info/node/402' 2>&1
real 0.27
user 0.00
sys 0.00
$ /usr/bin/time -p curl -o /tmp/undeadly -sLX GET 'http://undeadly.org/cgi?action=article;sid=20230704094238'
real 0.18
user 0.00
sys 0.00
$ du -b /tmp/stolyarov /tmp/undeadly
4498	/tmp/stolyarov
18599	/tmp/undeadly
cumvillain
()
Ответ на: комментарий от cumvillain

Читать директории на каждом реквесте (если это правда) – это конечно эпично.

А миллисекунды не показательны, хотя в отсутствие других тестов хоть что-то. Вот тут несколько сотен результатов https://www.techempower.com/benchmarks/#section=data-r21 – правда насчет методики тестирования ничего не скажу.

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 3)
Ответ на: комментарий от www_linux_org_ru

Это cgi, там по-другому никак. На самом деле я конечно кекаю и рофлю, потому что по большому счету для сайта с десятком тысяч человек в целом абсолютно наплевать чем ты будешь генерировать ответы, если у тебя настроено кеширование.

cumvillain
()
Ответ на: комментарий от TheAnonymous

оценивать софт, измеряя пинги до серверов - моё почтение

RTT до его глагне меньше примерно в два раза. Что-то мне подсказывает, что дело тут не в пингах :D

cumvillain
()
Ответ на: комментарий от cumvillain

RTT до его глагне меньше примерно в два раза

А от меня наоборот, до undeadly.org быстрее, больше, чем в 2 раза
Ну и вообще это всё фигня, очевидно, пока неизвестны другие параметры серверов, нагрузка в данный момент. Вот если бы ты локально поднял на одной и той же машине одну CMS и другую, тогда можно было бы говорить про какое-то сравнение

TheAnonymous ★★★★★
()
Последнее исправление: TheAnonymous (всего исправлений: 1)
11 сентября 2023 г.
Ответ на: комментарий от thegoldone

задачу ставит дело

Именно. В данном случае дело лично моё: мне в силу определённых причин нужно (а) поддерживать несколько cлабонагруженных сайтов, (б) с минимальными трудо- и деньгозатратами и (в) чтоб там не было никаких следов «современных веб-технологий». Ничего сколько-нибудь подходящего я ещё семь лет назад (см. Подскажите CMSку моей мечты) не нашёл, даже прибегнув к «помощи зала».

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

Потому что приложение – средство, а не цель.

Кто б спорил. Таласса - средство, а цель, например, в том, чтобы (1) развёртывание инфраструктуры на новом сервере (а с VPSки на VPSку приходится мигрировать, никуда не денешься) занимало меньше минуты (залить архив - пять секунд, раскрыть архив - ещё столько же, включая наколачивание команды, и чтобы оно собралось - ну, команда make и семь-восемь секунд подождать, ну потом туда ещё склонировать git-реп с исходниками сайтов и прогнать саму талассу для каждого из сайтов; наибольшее количество времени уходит на редактирование конфигов апача и правку DNS-зон, но от этого в любом случае не денешься никуда); (2) чтобы в ходе обычной работы сайтов о них можно было вообще не вспоминать (субд регулярно падают, но вот чтобы апач упал сам собой - я такого не припоминаю за всю свою практику); (3) и чтобы инфраструктура не стоила примерно ничего (я за ту VPSку плачу что-то около 16 баксов в год, ибо low-end).

Мораль: с точки зрения дела thalassa идеальна.

Croco ★★★
()
Ответ на: комментарий от cumvillain

его поделка перечитывает всю иерархию директорий КАЖДЫЙ МАТЬ ЕГО РАЗ НА КАЖДОМ МАТЬ ЕГО GET РЕКВЕСТЕ

Мне даже интересно, с какого дуба нужно спикировать вниз башкой и какое должно быть покрытие горизонтальной поверхности под этим дубом, чтобы что-то подобное заподозрить.

На всякий случай: всё, что есть на том же stolyarov.info и не имеет ``thalcgi.cgi'' в локальном пути, отдаётся в виде статических HTML-файлов. Ну, в смысле апач их видит в таком виде и понятия не имеет, откуда они взялись. Сама thalassa их только генерит, причём либо будучи запущенной вручную (например, для (пере)генерации новых или изменённых страниц, которые в нынешней версии нельзя добавить или изменить через web-интерфейс, только путём добавления файлов в дерево исходников сайта), либо будучи запущенной тем самым thalcgi.cgi для перегенерации страницы, на которой только что был добавлен, изменён или удалён коммент (перегенерируется только эта страница, и только после указанных событий, к GET-запросам это не имеет отношения от слова совсем).

http://stolyarov.info/node/402

Не поверишь:

w_croco@milda:~/public_html/stinfo$ ls -l node/402/

total 48

-rw-r–r– 1 w_croco webadm 48268 Sep 5 19:57 index.html

w_croco@milda:~/public_html/stinfo$

Уже не помню, за каким фигом я 5 сентября сайт перегенерил, вроде после апдейта конфигов, отвечающих за оформление страничек. Короче, иди теперь расскажи авторам апача, как они программировать не умеют.

Croco ★★★
()
Последнее исправление: Croco (всего исправлений: 3)
Ответ на: комментарий от cumvillain

Это cgi, там по-другому никак.

Ага, конечно. Это в мозгах у тебя по-другому никак, судя по всему.

Croco ★★★
()
Ответ на: комментарий от www_linux_org_ru

Читать директории на каждом реквесте (если это правда) – это конечно эпично.

А миллисекунды не показательны

Вот уж точно миллисекунды не показательны, ибо если бы всё было так, как пригрезилось кумвилану, то там бы счёт шёл отнюдь не на миллисекунды. Полная перегенерация того же stolyarov.info занимает около пяти секунд. Только она нафиг не нужна, я её иногда проделываю, просто чтобы в командной строке не указывать нужные странички — пока я их номера буду вспоминать, там те пять секунд уже пройдут.

Croco ★★★
()
Ответ на: комментарий от Croco

На всякий случай: всё, что есть на том же stolyarov.info и не имеет ``thalcgi.cgi'' в локальном пути, отдаётся в виде статических HTML-файлов. Ну, в смысле апач их видит в таком виде и понятия не имеет, откуда они взялись.

То есть ты изобрел http кеш. ПОХВАЛЬНО.

cumvillain
()
Ответ на: комментарий от cumvillain

То есть ты изобрел http кеш.

Только в твоих протухших мозгах, начисто разъеденных уЁбдезигном, сие могло вызвать какие-то ассоциации с http caching. В действительности я здесь вообще ничего не изобрёл, статический контент существовал за десятки лет до того, как поганые обезьяны принялись превращать веб в ту кучу дерьма, каковой он сейчас является.

Я тебе больше скажу, генераторов статического контента тоже существуют десятки, если не сотни, даже здесь ничего нового. Thalassa от них отличается всего двумя вещами: во-первых, в ней кроме собственно генератора предусмотрен ещё CGIник, отвечающий за комментарии, а сама она поддерживает генерацию страниц с комментариями, каждый из которых живёт в отдельном файле, облегчая работу CGIнику; тогда как сайты, поддерживаемые другими генераторами, либо вовсе не предусматривают комментариев, либо предлагают аутсорсить их на всякое дерьмо вроде дискусса. А во-вторых, Thalassa ни от чего внешнего не зависит ни в компайле, ни в рантайме, в крайнем случае её можно залить на сервер в виде двух статически слинкованных бинарников, тогда как другие генераторы слеплены на всякой дряни вроде питона, руби, перла и прочего интерпретируемого говна, создатели (высиратели) коего, кроме всего прочего, никогда не слышали про обратную совместимость, так что ЭТИ внешние зависимости превращают поддержку софта в непрерывную русскую рулетку.

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

Croco ★★★
()
Ответ на: комментарий от Croco

Только в твоих протухших мозгах, начисто разъеденных уЁбдезигном, сие могло вызвать какие-то ассоциации с http caching. В действительности я здесь вообще ничего не изобрёл, статический контент существовал за десятки лет до того, как поганые обезьяны принялись превращать веб в ту кучу дерьма, каковой он сейчас является.

Кучей дерьма он является только в твоих протухших мозгах. Додуматься статически генерировать страницы с комментариями мог только очень дремучий сишный пердоля. Прикинь, один твой пользователь в одной таймзоне, а другой – в другой! Ты им будешь два сайта генерировать? :))

Я тебе больше скажу, генераторов статического контента тоже существуют десятки, если не сотни, даже здесь ничего нового.

Ага. Более того, многие даже вполне неплохо прикручивают к ним комментарии. Только вот никто не генерирует эти комменатрии статически D:

cumvillain
()
Ответ на: комментарий от cumvillain

Прикинь, один твой пользователь в одной таймзоне, а другой – в другой! Ты им будешь два сайта генерировать?

Нет, я время покажу в UTC. Собственно, там так и сделано. Либо, если уж очень хочется, покажу некое «время сайта» (сейчас, кстати, не поддерживается, потому что чтобы это поддержать адекватно, нужна собственная версия функций работы со временем – можно выдрать из какого-нибудь musl и адаптировать, но мне пока лень).

А вот придумать генерить каждую страницу на каждый GET-запрос, даже если информация на странице меняется раз в год, могли только дебилы, каковыми все «современные» вебщики, собственно, и являются.

Я, впрочем, тоже хорош – послать-то этого кумвилана послал, а в игнор добавить забыл. Старость не радость. Ну, исправляюсь, чо.

Croco ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.