cargo2spec

[Володимир Лісівка]

Створив простенький скрипт на bash, який створює файл SPEC для будування RPM-пакетів замість виконання cargo install, щоб ставити бінарники в системний каталог та користуватися всім зручностями RPM та dnf.

Проєкт: https://github.com/vlisivka/cargo2spec

[ps]

Я cargo install не використовую, замість того збираюсь з cargo build + sudo install target/release/appname /usr/local/bin
це обмежує права на зміни бінарного файлу шкідливим ПЗ, яке заходить з npm/pip до ~ і має доступ до стандартно розташованих там низькорівневих програм rust.

[Володимир Лісівка]

Ну і коли потім приходить системний пакет з таким самим бінарником, знов починається бардак, тому що новіший бінарник, який оновлюється системою, не використовується, а використовується старий бінарник з $HOME чи /usr/local/bin.

[BeSiDa]

Ну і коли потім приходить системний пакет з таким самим бінарником, знов починається бардак, тому що новіший бінарник, який оновлюється системою, не використовується, а використовується старий бінарник з $HOME чи /usr/local/bin.

Якщо ви самі створили бінарник, то ви самі взяли на себе відповідальність вирішувати який з них "кращий" (це не обов'язково "новіший", може бути той, що вам більше потрібний (з іншими опціями компілювання)). Система може лише прислати вам листа, що виник конфлікт назв чи з'явився вибір. Але вибір ваш.

[BeSiDa]

це обмежує права на зміни бінарного файлу шкідливим ПЗ, яке заходить з npm/pip до ~ і має доступ до стандартно розташованих там низькорівневих програм rust.

Ви так кажете, ніби не читали Ріадмі Лінукс кернела, бо там зазначено де саме проходить межа захисту. І ця межа проходить між різними юід (ід логіну системи). Дивно що будь хто може очікувати захисту склавши бінарники у свій хоум від свого юід. А сервери взагалі кожен має свій юід (веб сервер, поштовий, ...). Якщо ви рут, створіть собі скільки завгодно нових юід під кожен проект та й компілюйте програми в межах тих юід (су інший-юзер).

[ps]

Якщо ви самі створили бінарник, то ви самі взяли на себе відповідальність вирішувати

+

Ви так кажете, ніби не читали Ріадмі Лінукс кернела, бо там зазначено де саме проходить межа захисту

Ще рідмі кернела я не читав 

Моя мета - лише зменшення кількості потенційних вразливостей, щонайменше тих, які я розумію. Чого я досі не розумію і перевірити ніколи не зможу - це бінарні напівфабрикати з яких складається кожен дістр. Були думки зібратись з сорсу, але для цього потрібно зібрати тулчейни. Тому зона контролю для однієї людини в колективних проєктах буде завжди фізично обмеженою.

[BeSiDa]

Тому зона контролю для однієї людини в колективних проєктах буде завжди фізично обмеженою.

Не тому.
Це метод синхронізації імперії (місце в ієрархії) обмежив ваше мислення, тому ви не розділяєте "зону контролювання" та "свій вільний вибір яку з зон контролювати в будь який момент" (імперія не дає обирати місце та вільно змінювати потім (навіть коли ви обрали)).
У вас детальний центр ока "фізично обмежений", але "вертіти головою та очима" ви здатні необмежено.
Немає сенсу себе автоматично вважати частиною "колективного проекту" навіть коли зі сторони здається що ви є. Це ваш вибір ким себе вважати та що саме контролювати та коли саме.

Моя мета - лише зменшення кількості потенційних вразливостей, щонайменше тих, які я розумію.

Але чомусь з цієї фрази ви зробили висновок, що хочете "розуміти менше"   Замість того щоб подякувати за нову (для вас?) інформацію про розділення програм по різним юід як ще один інструмент контролю взаємодій софту (ви ж рут! а поводите себе ніби звичайний один юзер який інколи рут, а не 100 різних юід-юзерів в ОС).

[Володимир Лісівка]

Якщо ви самі створили бінарник, то ви самі взяли на себе відповідальність вирішувати який з них "кращий" (це не обов'язково "новіший", може бути той, що вам більше потрібний (з іншими опціями компілювання)). Система може лише прислати вам листа, що виник конфлікт назв чи з'явився вибір. Але вибір ваш.

Якраз в тому і проблема, що менджер пакетів мені не каже про це, бо він нічого не знає про мої власноруч встановлені програми. Коли я роблю пакет, то я лише додаю мета-інформацію до бінарника, яка дозволяє менеджеру пакетів стежити за деякими речами, такими як конфлікти імен. Плюс, дуже зручно коли треба на новій машині розгорнутися чи контейнер зібрати — просто скопіював власні пакети і встановив їх, а не шукаєш їх по всій файловій системі та згадуєш потім як і звідки їх встановлював та які в них залежності.

  Замість того щоб подякувати за нову (для вас?) інформацію про розділення програм по різним юід як ще один інструмент контролю взаємодій софту (ви ж рут! а поводите себе ніби звичайний один юзер який інколи рут, а не 100 різних юід-юзерів в ОС).

Це не нова інформація. Окремі користувачі використовуються для розділення сервісів понад 30 років. Але коли працюєш як користувач, то це не зручно (я пробував колись), тому і придумали спочатку chroot а потім контейнери.

[BeSiDa]

Це не нова інформація. Окремі користувачі використовуються для розділення сервісів понад 30 років. Але коли працюєш як користувач, то це не зручно (я пробував колись), тому і придумали спочатку chroot а потім контейнери.

Інформація нова не через те, що до того такого не робили, а через те, що так робити не тільки зручно, але й це єдиний вірний спосіб (відповідно до меж розділення прав доступу кернела).
От, наприклад, в Андроїд це зроблено на стільки просто, що користувачі навіть не знають по те що кожна програма у своєму юід.
Ви написали свою програму, яка робить пакети для вас простіше, то чому ви аргументуєте проти способу замість зробити собі програму, яка робить те простіше собі?
Чи подивитися що вже є... ман сабюідс, ман лхц-юзернсекзек (для контейнера від іншого юід та запуску шелу в тому юід відповідно до списку дозволених юзеру в файлі сабюідс) та інші.

[BeSiDa]

Якраз в тому і проблема, що менджер пакетів мені не каже про це, бо він нічого не знає про мої власноруч встановлені програми.

А чому ви очікуєте що менеджер пакетів вам про це скаже? Це ж не ваш менеджер пакетів, а той менеджер, яким керують розробники дістру ОС. Їх метою є усунення конфліктів лише в тих пакетах, які тестували саме вони. Ви не тестуєте свій пакет на конфлікти з усіма пакетами, що є в дистрі ОС взагалі, але чомусь це очікуєте. Цієї інформації не існує. Ці конфлікти ваша відповідальність, а не менеджера.

Коли я роблю пакет, то я лише додаю мета-інформацію до бінарника, яка дозволяє менеджеру пакетів стежити за деякими речами, такими як конфлікти імен. Плюс, дуже зручно коли треба на новій машині розгорнутися чи контейнер зібрати — просто скопіював власні пакети і встановив їх, а не шукаєш їх по всій файловій системі та згадуєш потім як і звідки їх встановлював та які в них залежності.

А чому тоді ви не використали свій інший менеджер? (чи копію того самого, але з іншою базою та пошуком конфліктів з вже встановленими файлами у файловій системі, щоб не ламати менеджер пакетів ОС)

[BeSiDa]

У разі використання апт  у ман соурсиз.ліст рекомендують додавати свій репозиторій пакетів (навіть коли це лише окремий каталог локальної фс чи мережевої) задля вибору пріорітетів пакетів та їх версій відповідно до пріоритету репозиторію, а у ман апт_преференсис можна встановити пріоритети окремо щодо кожного пакету (і своїх) вказавши (відповідно за діапазонами пріоритетів) коли новіші версії з інших джерел мають вищій пріоритет чи не мають. Також там про те як обирати окремі пакети з джерела "тестування" (а не того, з якого всі інші пакети того дистру). Але вже без гарантій, що вони сумісні з дистром.

[BeSiDa]

А ви помітили яка епічна халепа розгортається зі значною частиною фанатів Раст?
Спочатку вони обрали Раст, бо той безпечний.
А з цього автоматично випливає, що тепер та людина... ні в чому не винна!
Але раптом виявилося, що помилки є і не все всюди добре, але... вони ж ніяким чином не можуть бути винні! А хто тоді?
І тут сталася халепа, бо Раст не є людиною! А отже сам Раст жодним чином не може бути у всьому винним!
Миттєво вони розгорнули супер важливе повідомлення! до всіх інших (які тепер стопудово винні у всьому і навіть у смерті людей (є вже такий пост в інеті)) допоки ті всі інші не перетворять себе на фанатів Раст!
Але ті всі (тупі!) інші люди, замість того щоб добровільно визнати себе винними в усьому! не захотіли те робити, а натомість почали знаходити тисячі прикладів чому винні фанати Раст та обрана ними мова! ))
А отже тепер це без кінця і без зупинок! І фанати Раст нічого подібного не хотіли! Це не вони а всі інші! І тим нічого не лишилося крім продовження до вирішення альфа сорців. (або ізоляції всього Раст, але на це інші неспромоглися...) А от визнати себе... і не пручатися... все б зупинило (іншим).
Самих себе так і назвати... небезпечна мова програмування  Будь яка інша.

[BeSiDa]

Раст це фашизм не сам по собі, і не через те, що в нього свій пакетний менеджер та своя білд систем, а через те, що масовано не застосовують той пакетний менеджер та білд систем для поширення всіх інших мов програмування (як те з окремими пакетними менеджерами, не прив'язаними до мови) та створення з них всіх бінарників та запакованих релізів.

Ви перепакували карго в спек та радієте що "побороли фашизм" (бо використали лише Раст як корисний для вас інструмент), але ні. Ви стали інфраструктурою фашизму як на вас (поки тимчасово) спирається (ви стали +1 до лічильника популярності, яка дозволить "перевести все на Раст" і знищити всі інші мови... (ну так вони сподіваються...)).


Але поки йде стадія "становлення до все-популярності" можете насолоджуватися його перевагами як мови створення програм. Лише не полишайте (розвиток до сучасного стану та навички в собі) асемблер, С, С++ та всі інші мови (які захочете, але всіх рівнів відстані від обладнання).

[Володимир Лісівка]

Якраз в тому і проблема, що менджер пакетів мені не каже про це, бо він нічого не знає про мої власноруч встановлені програми.

А чому ви очікуєте що менеджер пакетів вам про це скаже? Це ж не ваш менеджер пакетів, а той менеджер, яким керують розробники дістру ОС. Їх метою є усунення конфліктів лише в тих пакетах, які тестували саме вони. Ви не тестуєте свій пакет на конфлікти з усіма пакетами, що є в дистрі ОС взагалі, але чомусь це очікуєте. Цієї інформації не існує. Ці конфлікти ваша відповідальність, а не менеджера.

Для прикладу, пакет ast-grep з crate.io встановлює бінарник sg, який перекриває бінарник з такою самою назвою з пакету shadow-util: https://github.com/ast-grep/ast-grep/issues/706

Створений мною пакет RPM не поставився, бо rpm не дав переписати системний бінарник, а інакше я би і не помітив цього, поки не натрапив би на якусь помилку.