The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен Passim, кэширующий сервер для распространения файлов в локальной сети

29.07.2023 09:07

Ричард Хьюз (Richard Hughes), создатель фреймворка PackageKit, системы управления цветом colord, сервиса UPower, системы доставки прошивок LVFS и таких приложений, как GNOME Software, GNOME Power Manager и GNOME Color Manager, представил свой новый проект - Passim. Passim представляет собой кэширующий сервер для распространения файлов, использующий для адресации хэши от содержимого по аналогии с IPFS (InterPlanetary File System). Для определения другими системами наличия файлов в хранилище применяется протокол mDNS (Avahi). Код проекта написан на языке Си и распространяется под лицензией LGPLv2.1.

Passim может быть использован для повышения эффективности работы приложений, которые периодически загружают метаданные и файлы, необходимые для обработки других запросов. Основная идея в использовании Passim в качестве кэширующей локальной системы доставки контента, применяемой для распространения часто запрашиваемых файлов среди систем в локальной сети, без прямого обращения к основным серверам и без привлечения глобальных CDN. Например, Passim может применяться для оптимизации распространения среди пользовательских систем обновлений прошивок, метаданных систем блокирования рекламы и обновлений для пакетных менеджеров. На практике Passim планируют использовать для организации доставки прошивок в инструментарии fwupd и проекте LVFS.

В проекте применяется модель адресации файлов на основе хэша SHA-256 от их содержимого. Имя файла в Passim носит информационный характер, а обязательным атрибутом при адресации является хэш от хранящегося в файле содержимого, что не позволяет внести изменение в файл без изменения его адреса для загрузки. Использование хэшей также позволяет выявлять файлы с одинаковым содержимым, независимо от присвоенного им символьного имени. Для предотвращения подмены файлов на клиентской стороне предписано обязательно сверять заявленный хэш с хэшем, вычисленным на основе содержимого загруженных данных.

Данные в хранилище могут добавляться в автоматическом или ручном режиме, и сводятся к копированию файла в каталог /var/lib/passim/data и установке через расширенные атрибуты (xattr) максимального времени жизни и ограничений на число загрузок. После истечения времени жизни или превышения лимита на число загрузок файл автоматически удаляется. Присутствующие в хранилище файлы отражены в общем индексе, который могут получить все пользователи, используя mDNS или загрузку индекса по HTTP (http://host:27500/).

Для отдачи файлов применяется простой однопоточный HTTP-сервер. Файлы и индекс отдаются без аутентификации и без шифрования (HTTPS не поддерживается), так как система рассчитана на публичное распространения данных в локальной сети. Загрузка осуществляется через отправку HTTP-запроса в форме "http://192.168.10.1:27500/filename.xml.gz?sha256=хэш", в котором ключевым идентификатором является хэш (без хэша файлы не отдаются). Начальный проверочный хэш и GPG-подпись загружаются через обращение к внешнему CDN.

Изначально для организации доступа к обновлениям прошивок в LVFS рассматривалась возможность использования хранилища на базе децентрализованной файловой системы IPFS, но в конечном счёте было принято решение создать свою более простую альтернативу, рассчитанную на доставку данных только с серверов в локальной сети. Основной причиной отказа от IPFS стали возможные юридические проблемы, вызванные попаданием IPFS под действия экспортных ограничений ITAR (International Traffic in Arms Regulations) и EAR (Export Administration Regulations) из-за использования продвинутого шифрования.

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

  1. Главная ссылка к новости (https://blogs.gnome.org/hughsi...)
  2. OpenNews: Выпуск глобальной децентрализованной файловой системы IPFS 0.9
  3. OpenNews: Выпуск Venus 1.0, реализации платформы хранения FileCoin
  4. OpenNews: Инициатива по созданию единой коллекции обновлений прошивок для Linux
  5. OpenNews: Началась разработка пакетного менеджера DNF 5 и замены PackageKit
  6. OpenNews: Доступен fwupd 1.8.0, инструментарий для загрузки прошивок
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59515-passim
Ключевые слова: passim, ipfs, cache
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:34, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    > без шифрования (без HTTPS)

    А в чем проблема использовать self signed certificates?

     
     
  • 2.7, Карлос Сношайтилис (ok), 09:58, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лень писать шифрование на сишке.
    Ну как "писать". Подключать либы и морочиться с их постоянным обновлениями.

    Да и зачем там https, если аутентификации нет и файл проверяется после загрузки?

     
     
  • 3.48, Аноним (-), 07:54, 30/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Лень писать шифрование на сишке.

    Скорее, вопрос в том что...
    1) Будет греть проц. Это должно быть ради чего-то полезного, а не галочки в маткетинговом булшите.
    2) Больше кода = больше багов. Вы точно хотите иметь дело с софтом где CVE каждый месяц находят. Чекать апдейты в openssl? Это может стать и вашей проблемой - достаточно его использовать.
    3) Управление сертификатами и вопросы доверия - опять же не очень тривиальный вопрос. Да, можно не париться. Потом половина софта хавает без вопросом MITMовские серты, содержит километровый список ауторити которым вы "доверяете" (хоть даже и не слышали про половину) и так далее. Много административной хрени во имя... чего?

     
  • 3.58, sena (ok), 01:26, 02/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Да и зачем там https, если аутентификации нет и файл проверяется после загрузки?

    Файл проверяется на соответствие хешу. То есть для скачивания файла шифрование не нужно, согласен. Но где-то же надо взять сам хеш!

     
  • 2.11, Аноним (11), 10:11, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Написано же

    >возможные юридические проблемы, вызванные попаданием IPFS под действия экспортных ограничений ITAR (International Traffic in Arms Regulations) и EAR (Export Administration Regulations) из-за использования продвинутого шифрования.

    Если надо будет сделать без хэш-функций с целью обеспечения возможности доставки вредоносного ПО компетентными органами - автор и без хэш-функций сделает и получит дополнительные +15 баллов к "социальному кредитному рейтингу".

     
     
  • 3.31, Тоже_аноним_естественно (ok), 12:45, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Два чая этому господину!
     
  • 2.14, Аноним2 (?), 10:17, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    От сертификатов надо отказываться. Крайне хрупкая, неудобная и узкоспециализированная система, единственное достоинство которой что пользователю ничего не нужно делать.
     
     
  • 3.45, Аноним. (?), 23:40, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда уже и от шифрования тоже.
     
  • 3.51, daemontux (?), 05:55, 31/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы конечно же можете предложить решение лучше?
     
     
  • 4.59, Аноним (59), 17:43, 03/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    DANE/TLSA
     
  • 2.17, Аноним (17), 10:26, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –11 +/
    > А в чем проблема использовать self signed certificates?

    HTTPS с self-signed по уровню безопасности эквивалентен HTTP.
    А если не видно разницы, зачем запариваться?

     
     
  • 3.19, пох. (?), 10:36, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    экспертиза опеннета, как обычно...
     
  • 3.20, Elc (?), 10:42, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чаво!?
    Это в каком месте наличие шифрования равносильно его отсутствию?
    Можно подробно плз? Я видимо что-то сильно важное пропустил...
     
     
  • 4.27, User999 (?), 11:22, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Он просто не вкурсе про сниферы... Бывает
     
  • 4.52, Stax (ok), 09:57, 31/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Все правильно, равносильно.

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

    Другое дело, что тут есть логическая ошибка - возможность расшифровать появляется не из-за self-signed, а когда нажимают в браузере "пустите меня" в ответ на предупреждение о self-signed. И в таком режиме это шифрование - фальшивка, пустая иллюзия шифрования. А вот если администратор нормально поставил свой CA в систему и браузер пускает без предупреждения - то это уже рабочее настоящее шифрование (которое может стать ненастоящим, если админ позволит ключу своего self signed CA утечь).

     
  • 3.21, Аноним (21), 10:45, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Только если юзер добавляет исключение и не смотрит хэш и все остальное. Если правильный сертификат добавляется в доверенные, это вполне ок.
    Голый хттп как транспорт годится, но нужны криптографические средства подтверждения аутентичности данных, по аналогии с тем, как доставляются пакеты в дебиане.
     
  • 3.22, Аноним (22), 10:48, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вот и выростили поколение людей, которые не верят своему шифрованию, а верят только одобренному майором.
     
     
  • 4.26, Аноним (26), 11:04, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вот майоры и вырастили поколение, которое им верит. Майоры молодцы.
     
     
  • 5.32, Тоже_аноним_естественно (ok), 12:47, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Сейчас на подходе уже поколение которое верит майору, но не верит в его существование.
     
  • 3.34, Аноним (34), 13:03, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Объяснять анекдоты непонявшим - это конечно испанский стыд, но поясню. Доверие в системе ты можешь настроить ТОЛЬКО ДЛЯ СВОИХ self signed сертификатов, приватные ключи которых хранятся только у тебя и бортовать всё остальное (селф и неселф сайнд). Удачи тогда всяким MITM-чувакам впарить тебе любой другой сертификат или прочесть/подправить твой трафик. Ну разве что если ты им каким-то образом подаришь свои приватные ключи или применишь какие-нибудь самые дохлые криптоалгоритмы, а у них уже будут квантовые компьютеры из ближайшего будущего.
     
  • 3.46, Аноним. (?), 23:45, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Отпишите, что Вам не видно.
     

  • 1.2, Аноним (2), 09:37, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >что не позволяет внести изменение в файл без изменения его адреса для загрузки.

    Что даже пропатченный сервер это не сможет?

     
     
  • 2.3, Аноним (3), 09:39, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Для предотвращения подмены файлов на клиентской стороне предписано обязательно сверять заявленный хэш с хэшем, вычисленным на основе содержимого загруженных данных.

    на которой так никто делать не будет. А кто будет - тот мог бы скачать по любому адресу, хоть хэшу, хоть uuidу.

     
     
  • 3.12, Аноним2 (?), 10:14, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю без хэша не скачать. Что-то вроде обязательной проверки.
     
     
  • 4.13, Аноним (13), 10:15, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да. Только нет никакого смысла в таком ограничании.
     
  • 2.29, Атон (?), 11:44, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    нет смысла. клиент сверит хэш перед применением.
     

  • 1.4, Аноним (4), 09:41, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Со всем перечисленным, для доставки обновлений в локальной сети, хорошо справится кеширующий прокси сервер, например squid.

    А цифровую подпись скачаной фирмвари или пакета перед установкой проверять все равно надо.

     
     
  • 2.23, Аноним (22), 10:52, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот мне тоже кажется что дядя решил написать свой сквид с кучей новомодных свистоперделок. Если раньше надо было только сквид, то тут надо авахи, мднс, хттп-серер, и собственно аналог ипфс. Кроме того все это видимо не сможет работать без системды. Вот так просто и легко переписываем сквид на микросервисы :)))
     

  • 1.5, Аноним (5), 09:43, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Основной причиной отказа от IPFS стали возможные юридические проблемы, вызванные попаданием IPFS под действия экспортных ограничений ITAR (International Traffic in Arms Regulations) и EAR (Export Administration Regulations) из-за использования продвинутого шифрования.

    Так можно дойти и до того, чтт вообще никакую криптографию нельзя использовать. И вообще компьютеры, как один оратор ( https://zavtra.ru/blogs/ochevidnoe_nezamechaemoe ) предложил.

     
     
  • 2.16, Аноним (17), 10:25, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Только если вы находитесь в американской юрисдикции.

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

     
     
  • 3.18, Аноним (18), 10:30, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Налоги от копирастов и поборы с населения перекроют вса убытки.
     
  • 3.30, пох. (?), 12:26, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    тооочна! И они все как побегут в Бурунди и Буркину-Фасо! Так мы их и победим!

     
  • 3.33, Аноним (33), 12:59, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Указанный оратор - член законодательного органа далеко не американской юрисдикции.
     

  • 1.6, qwerrty (?), 09:44, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если можно патчить прогу, то независимо от неё, что она делает, можно туда зашить вредонос.
    А так, получается, две стороны патчить надо (передающую и принимающую).
     
     
  • 2.10, Аноним2 (?), 10:08, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Можно сказать про абсолютно любую программу.
     
  • 2.25, Аноним (26), 11:02, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так с сабжем ты сможешь понять этот твой вредонос или кто-то по дороге дошил твоему вредоносу свой вредонос.
     

  • 1.9, Аноним2 (?), 10:08, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Торрент^W IPFS переизобрели, только для локалки. Корпорации от тысячи серверов оценят, остальным похоже даром не нужно.
     
     
  • 2.15, Саня (??), 10:19, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    тоже подумал "чем их торрент не удовлетворил?"
     
     
  • 3.24, Аноним (24), 10:59, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    зная SHA256, как ты скачаешь в сети битторрент подлинный образ Windows, например?
     
     
  • 4.36, Tron is Whistling (?), 14:26, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Включившись в DHT и зная DHT раздачи, ты вполне себе скачаешь что угодно.
     
     
  • 5.37, Tron is Whistling (?), 14:26, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    // хэш раздачи
     
  • 3.57, Аноним (57), 20:56, 01/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Заблокировать тррренты по DPI
     
  • 2.38, Аноним (38), 15:01, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    DC++
     
     
  • 3.40, хрю (?), 17:37, 29/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Именно директ коннект чувак "изобрёл", а ни какой не торрент, только без чатика.
     

  • 1.28, Аноним (28), 11:38, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё как обычно. Десятки раз переписывать одно и тоже. Взять нормальное и немного дополнить - неее, не надо. Делаем кривульку сами. Скоро десятилетие будет как закопали похожую вещь https://www.snia.org/sites/default/orig/SDC2012/presentations/Revisions/Christ
    Но она хотя бы адекватная была.
     
  • 1.35, Аноним (35), 13:08, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сложилось такое впечатление, что это на гпани ненужного.
     
  • 1.39, Аноним (39), 16:29, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ничего не понимаю.

    Почему бы просто не использовать обычный кэширующий сервер?

    Зачем туда прикручивать IPFS и LVFS.

     
  • 1.41, Аноним (41), 19:53, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вы как всегда про велосипеды... Мульён программистов и каждый со своим особо ценным мнением. Потом будете говорить - вот  Passim же есть,зачем к нему не прикрутил чего-нибудь.
     
     
  • 2.54, Пряник (?), 10:19, 31/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это часть естественного отбора. Нужно много почти бесмысленных и одинаковых итераций для выведения идеала.
     

  • 1.42, r0g3r (ok), 21:28, 29/07/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]
  • +/
     

  • 1.44, Аноним (44), 23:03, 29/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хэш файла имеет смысл только вкупе с размером файла. Я думаю, ума надо много, но в разумной мере, чтобы дописать в конец файлы кусок до получения нужного хеша. Это не коллизии искать.
     
     
  • 2.47, Аноним (47), 00:56, 30/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > дописать в конец файлы кусок до получения нужного хеша
    > Это не коллизии искать.

    Эталонная опеннетная экспердиза. Пойди что ли почитай, что же это за коллизии такие. А то так и помрёшь не разобравшись.

     
     
  • 3.50, Аноним (50), 04:22, 31/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пошёл, почитал, спасибо. Коллизией хеша называют совпадение хеша для любых двух наборов данных, а не одинаковых по размеру блоков данных (как я думал). Неожиданно широкая трактовка.
     
  • 2.60, Аноним. (?), 03:22, 05/08/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не сработает.
     

  • 1.49, beck (??), 15:01, 30/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чего люди не делают,  лишь бы wsus не использовать. )))
     
  • 1.53, Пряник (?), 10:14, 31/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Классная идея. Можно уже писать плагин для APT/YUM. Вот только

    > Для отдачи файлов применяется простой однопоточный HTTP-сервер

     
  • 1.56, pavlinux (ok), 21:58, 31/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    В общем очередная муть, которую уже давно реализовали в squid.  
    Самбу можно настроить как кэширующий сервак своей локалки.
    NFS3/NFS4 тоже самое ...
    P2P/Torrent вариантов море, чтоб блоки файлов раздавались от ближайших хостов, а не из одного сервера.  
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру