Вот темы, которые было бы интересно послушать мне: 1) Пакетирование перловых

приложений/библиотек.

Минилла? Или что-то лучше изобрели?
Подвопрос - как добавлять в пакет ресурсные файлы (картинки например)?

2) Публикация перловых пакетов в закрытом контуре.

В гитлабе нет встроенного перлового реестра. Куда же класть? Держать в виде исходников в том же Гитлабе? Поднимать локальный спан?

3) Генерация удобной красивой html-документации из POD-а.

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

4) Распил огромной кучи бессистемно перемешанных модулей/функций на отдельные независимые модули.

И чтобы ни единого разрыва ни одной циклической зависимости. Автоматизируется?

Мы легко можем тему #2 про метасрань заменить на что-то из твоего списка, 1-2, например, можно вообще в один доклад уложить. Но тоже хз, найдется ли спикер

На тему 1-2 один ответ - deb или rpm ) Но на самом деле да, очень интересно послушать бы

а что делать в Windows ?

Страдать. ;)

паковать в zip

> В гитлабе нет встроенного перлового реестра. Куда же класть? Держать в виде исходников в том же Гитлабе? Поднимать локальный спан? Проще всего держать в виде исходников в том же Гитлабе (в подписанном коммите с подписанным тегом)

Исходники (репы) нельзя установить по спанфайлу рекурсивно. Ни один перловый установщик не умеет так делать, даже cpm.

там же есть переменная окружения. Она сначала из локальной репы тянет то, что есть, потом из глобальной

Неа. Рекурсивно не тянет.

ну вот на**я тебе рекурсия?

Ну здрасьте. А зависит от Б, тот от В. И всё, привет, перл не сможет поставить А.

У вас наверняка есть какой-то сборщик, который превращает исходники в артефакты для прода (rpm/deb/docker image). Вот он должен выкачивать репу с зависимостями (tgz скачанными безопасно с CPAN) с проверкой её целостности, и после этого запускать перловый пакетный менеджер. У голого cpm для этого недостаточно фич, я выше кидал ссылку на мой PR к мэйловому форку cpm.

а, б, и в ставишь всё в локальную репу. И всё он из неё тащит стандартными средставми

Что значит "ставишь в репу"? Как в репу можно что-то поставить?

в локальный cpan (забыл как софт, вроде orepan есть и другие). ставишь ВСЕ свои зависимости, оно оттуда тащит всё (как переменную окружения задашь).

Так в этом и задача – как-то выкачать репы с зависимостями и cpm это не умеет рекурсивно. Собрать-то потом что угодно можно.

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

Вот мэйловый форк позволяет сделать максимально адекватно %)

там это ПОЧТИ тоже самое. Более... по-девопски, чтоли

Как вариант: зависимости ставить в конкретный каталог и его под гит и занести. Потом так же обновлять только в этом каталоге. При установке то и подзависимости качаются если перечислены в пакете. А для прода брать код из этой гит репы по тегу который будете проставлять после аудита кода. Тут гемор может быть с XS, который хоть и решаем, но это уже не "из коробки" как хотелось бы.

Вообще, проблема, о которой пишет Михаил, действительно существует. Она связана с тем, что во всех популярных реализациях перловых менеджеров пакетов: cpanm, carton, cpm (а все они под капотом используют примерно одно и тоже) - зависимости качаются недетерминированно. Что приводит к тому, что в два разных запуска по одному и тому же cpanfile у вас могут скачаться разные наборы зависимостей за счёт того, что скачаются разные транзитивные зависимости. Простого решения этой проблемы нет (надо писать новый перловый пакетный менеджер). Но вы можете один раз скачать зависимости, закоммитить их в репу и (например каким-то CI механизмом) проверить, что без внешнего интернета этих зависимостей достаточно для сборки вашего приложения.

Некоторая сложность с этим в том, как именно организовать процесс безопасного скачивания зависимостей (что бы не допустить различных Supply Chain Attacks).

Ага, весь local закоммитить 😳😳😳

Вот тут речь о нем

Именно. Но проблема в том: как (например) сотруднику ИБ убедиться в том, что Алиса, которая скачивала tar.gz из CPAN-а не стала жертвой злоумышленника до коммита.

А, я понял

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

Стикер

Нет, не подписывалось. Думаю, считалось, что внутри контура атака с подменой не пройдёт(но на шоколадку не поспорю).

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

Я был пользователем той системы, т.е. программистом, который качал модули из хранилища. Каковы были методы защиты как системы в целом, так и непосредственно хранилища, могу только предполагать. https для локального зеркала использовался с сертификатом, который подписан внутренним CA. Больше никакой защиты или проверки целостности не было.

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

Знаем, проходили с "проверкой независимых разработчиков". xz, HeartBleed и т.д. Но проблема то даже не в проверке. Разумеется, после коммита зависимостей надо запускать SAST и дополнительно смотреть глазами, что там в этом коммите. Проблема, что если будут таргетированно ломать вас (злоумышленник организует коммит заведомо компрометированной зависимости), вы ничего таким способом на практике в 99.99% случаев не найдёте. Так что проще дополнительно понадеяться на open source, но защитившить от SCA

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

Ну, вот обсуждаем как раз сложность создания упомянутой процедуры.