Попытка пересесть на Linux, первые грабли
В связи с пониманием, что в Виндоуз трудно достичь сколько-нибудь вменяемой безопасности, из-за закрытости кода и возможных закладок, осуществлена попытка пересесть на линукс. Первые грабли не заставили себя ждать. Выяснилось, что я попал в чудный новый мир. Оказывается нельзя просто так взять с сайта и поставить какую-нибудь программу. Необходимо подождать, пока её добавят в репозитарий моего дистрибутива, и после этого установить командой apt-get install. Возник вопрос, можно ли как-то скачивать программу нужной версии вместе с необходимыми ей библиотеками необходимых версий, ставить в нужную мне папку, и запускать оттуда? Такое меня вполне устраивает. А не заморачиваться, есть ли новая версия в репозитарии, нет ли конфликта с какими-то устаревшими библиотеками, и так далее.
Далее, для обновлений рекомендуется прописать сервер ftp.debian.org в /etc/apt/sources.list. Соединение устанавливается назащищенное, соответственно сведения об устанавливаемых приложениях передаются в открытую. Не является ли это "дырой" и ущербом для анонимности? И как это можно обойти?
Можно, если готовы вручную всё компилить, включая все зависимости. Stand-alone-программы в Linux непопулярны, TBB — редкое исключение. Даже если кто-то сделал готовый deb-пакет нужной вам версии, вас это не спасёт, т.к. он, скорей всего, слинкован не с теми версиями библиотек, какие установлены в системе по умолчанию, поэтому все недостающие библиотеки нужных версий тоже придётся откуда-то брать. Короче, забейте на это. Даже автокомпиляция из портов (там версии фиксированы, но могут отличаться от системных, быть свежее) — дело не для слабонервных [1], а самостоятельно компилировать всё из исходников будет ещё сложнее.
Насчёт «ставить в нужную папку» — это если только для каждого приложения делать своё дерево портов, т.е. полный анреал. Это полностью противоречит всей сути и духу UNIX'а. В Gentoo Linux вроде можно работать паралельно с деревьями разных версий и выбирать, какую хотите поставить (в широких рамках), но и там всё ставится в /usr, а не в персонально выбранную директорию.
Будете заморачиваться, да, как и все остальные. Обход этого правила — очень тяжёлая процедура, фактически сводящаяся к портированию новой версии программы на ваш дистр. Этим занимаются либо профессиональные программисты-мейнтейнеры, либо гуру. Другие люди до этого опускаются, только если уж очень сильно надо.
Является.
Установить системный Tor [2], закрыть трафик в обход Tor'а файерволлом [3] и торифицировать apt-get [4]. Ну, т.е., на вашем уровне знаний пока проще забить. ☺
комментариев: 9796 документов: 488 редакций: 5664
Сами пакеты заверены электронной подписью и автоматически проверяются, так что ущерб есть для анонимности, но не безопасности. Если вы совсем новичок в системе, то первые несколько лет у вас и безопасность системы будет так себе, не говоря уже про анонимность.
После такого названия темы пропадает желание что-либо обсуждать, скажите спасибо, что кто-то не поленился ответить по существу.
Название темы неинформативно, нытьё — неконструктивно.
Главное, не устраивать и не поддерживать нытик-треды :).
Скачивать можно. Для этого надо всего-то зайти на сайт производителя и скачать. Разумеется, если производитель такую сборку сделал ;)
Можно предложить простое временное решение:
1. Запустите TBB
2. В консоли:
# sudo torsocks apt-get update
А потом установить tor в систему и настроить как предложено
Не заработает. Порт torsocks умолчанию — 9050, а порт TBB — 9150, так что придётся или править /etc/tor/torsocks.conf или менять порт в TBB.
И эту тему мне хотелось бы развить.
Тут ответ выше, но спрятать недоумение у меня видимо не получилось.
Скажите, вот есть Винда. Я ставлю какую-то программу, она ставится вместе со своими библиотеками, после этого работает. Если я поставлю какую-то еще программу, зависимую от этих библиотек, то насколько я понимаю у меня не возникнет конфликта зависимостей. А что в таком случае происходит в Линуксе? Есть какое-то чисто техническое отличие в реализации, или это просто идеологическая парадигма, одна библотека, в определенной папке, и все новые программы с другими требованиями к библиотекам автоматически не работают. В чем отличие, почему это as is работает в Винде и не работает в Линуксе?
Вот это я и не понимаю, почему в Винде я не портирую программу чтобы её запустить, а в Линуксе и должен хз что сделать, чтобы запустить программу с большим количеством зависимостей. Тому есть какие-то технические причины и отличия в реализации операционной системы, или просто некая идеология построения библиотек и их зависимостей, в которой мне ничего не положено. Просто по-моему, это очень просто и рационально, скачать и запустить программу, и какие причины могли побудить отказаться от подобного подхода.
То есть сам разработчик конкретной программы может без проблем слинковать её с нужными библиотеками и распространять в таком "пакете", и тогда она просто будет работать, без возни с зависимостями, но не делает этого по историческим и идеологическим причинам относительно распространения Linux программ?
Я понимаю, что вопросы эти могут быть чайниковыми, для людей хорошо понимающих что, как, и почему, делается в Unix-like системах.
А насчет apt-get, хотелось бы простого шифрования сеанса обновления с сервером. В конце концов все приложения и обновления скачиваются из одного источника (а качать откуда угодно я не могу, ибо пакеты, зависимости :) ) И пусть сервер может посмотреть что обновил и установил, но простой наблюдатель не сможет.
И большего не нужно. А вот если идти дальше, быть анонимным и для сервера, в таком случае уже apt-get через Tor. Как мне кажется (и если я правильно понимаю) в случае с Тором атака человека по середине более вероятна, соответственно при работе со сторонними репозитариями надо будет как-то в ручном режиме проверять аутентичность пакетов.
На эту тему можно написать обстоятельную статью, но я не так много знаю и не настолько квалифицирован. Можно поставить вопрос, откуда так пошло, почему так сложилось исторически и т.д. — всё это по-своему интересные вопросы, но всё-таки приземлимся до уровня status quo на текущий момент.
Представьте, что у вас есть много всякого разного софта. Вы хотите им оптимально управлять. К примеру, множество софтин зависят от библиотеки libjpeg. Вы можете включить эту библиотеку в каждую софтину, где она нужна, получив, таким образом, сотни её вариантов и версий на ПК, являющихся частью того или иного софта. Однако, можно поступить иначе: поставить одну бибилиотеку одной конкретной версии, а потом весь софт заставить её юзать. Первый способ — Windows, второй — Linux/UNIX.
Чтобы софт был завязан на конкретную версию библиотеки, он должен быть с ней слинкован при компиляции. Т.е. все сборщики всего софта должны определиться, какую версию библиотеки взять, чтобы всё заработало, а потом, исходя из этих требований, сделать нужный бинарник.
Теперь о плюсах и минусах. Представьте, что в libjpeg нашлась уязвимость. Что нужно сделать на винде? Правильно, переустановить весь софт, выкачав повторно (в общем случае) гигабайты данных. А что нужно сделать в Linux? Обновить один-единственный маленький пакет libjpeg, на который завязано в системе всё и вся. Если вы хотите сделать кастомную, компактную или ещё какую-то специфическую ОС, подход Linux'а также даёт вам свободу в плане достижения оптимума «в системе нет ничего лишнего». Минусы тоже очевидны, вы на них сами указали, трудность инсталляции. На самом деле, это предельные случаи, а в реальности в Linux-методе есть элементы винды, а в винде — элементы Linux'а, так что, например, зависимости в винде у некоторых софтин тоже имеются (как и конфликты с зависимостями), но они обычно немногочисленны.
Вы можете подойти к этому вопросу и иначе. Если кто-то ради вас собрал stand-alone бинарь со всеми вкомпиленными зависимостями (как в TBB), вы его прекрасно запустите в любом Linux, проблем нет. Просто это мало кому нужно, потому что все свой софт пропихивают через пакеты/порты в официальных репозиториях. Представьте на секунду ту же ситуацию под винду: есть исходники нужной версии вашей софтины, а бинаря нет. Ну, вот не сделал его автор для винды, и всё, а сделал только, допустим, для мака. И как вы тогда этот софт на винду поставите? Вам придётся его вручную компилить, попутно устанавливая все необходимые инструменты и библиотеки, которые, в свою очередь, будут тянуть другие инструменты и библиотеки, которые, в свою очередь... ну, вы поняли. Вместо одного проекта вам придётся в итоге установить из исходников их несколько десятков. И, я вам скажу, что эта процедура сборки под виндой будет ещё сложнее, чем аналогичная на Linux.
На самом деле, там всё ещё сложней (как в плане идеологии, так и в плане её реализации), но я вам очертил общие контуры того, откуда берётся различие. Скажем так, в Mac OS X, насколько я знаю, всё точно так же, как в Linux-дистрах: почти все установки идут с официальных репов, а там те версии, какие положили.
Потому, что в винде за вас это сделал разработчик программы, а для Linux он это не сделал. Соответственно, в винде всё работает наура, а в Linux эта тяжесть ложится на плечи пользователей.
Есть и обратные примеры, со временем их становится всё больше: какой-то софт создаётся и разрабатывается под Linux. С существенным геморроем его ещё можно как-то водрузить на Mac OS X, пользуясь тем, что последнее — хоть какой-то, но тоже Linux, а вот на винду его установка если возможна, то лишь только теоретически. Инструкции по сборке, компиляции и пр. тоже идут под Linux. Попробуйте по ним сделать аналогично на винде, я на вас посмотрел бы.
Кстати, был проект Lindows или какой-то другой, где пытались то ли сделать отдельные пути для хранения всех файлов каждой софтины в одной директории, то ли отказаться от завязывания всего на одну версию библиотек (сделать всё stand alone)... уже не помню.
Есть «просто для юзера», а есть «просто для разработчика». UNIX никогда не был системой «для людей» — это ОС, «написанная программстами для программистов» ©, поэтому программисты себя в ней чувствуют комфортно и естественно. Вообще, есть UNIX way и его критика, а также принцип «worse is better» и его критика. Делая в UNIX софт и инструменты простыми, вся сложность выдавливается на уровень пользователя, их использующего, а можно было бы делать наоборот, как винде: софт очень умным, чтобы наружу торчало только самое простое. Плюсы и минусы есть у обоих подходов. Например, минус второго подхода (винда) в том, что программа пытается быть умнее пользователя не там, где нужно, из-за чего ему приходится воевать с этой умной автоматикой, которая как нарочно пытается сделать всё по-своему и наоборот. А плюс первого подхода (линукс) в том, что если нужно что-то исправить под свой случай, сделать это проще, т.е. внутренняя логика простая, а поведение компонентов системы легко предсказуемо.
Может, но для него это не будет простым. Есть такое понятие, как среда, в которой разрабатывается софт. Допустим, он пишет под Linux и сам пользуется Linux'ом, тогда он, чтобы протестировать свой же софт, напрягётся и соберёт его под Linux в stand alone (если вдруг ему такой подход близок). Но тут к нему приходит пользователь и просит аналогичный продукт, к примеру, под FreeBSD. А оно разработчику надо — теперь разбираться с этой системой и делать всю аналогичную работу под ней? Возьмите распространённые массовые продукты: TBB под Linux и винду есть, а под BSD нет; stand alone-версии Skype под Linux нет (поэтому хрен запустишь порой), она только под винду; браузер Opera был как под винду с Linux'ом, так и под FreeBSD (разработчики почему-то не поленились это сделать). Бывает, что крупный разработчик заявляет, что та или иная платформа в процентном отношении небольшая (хотя большая в абсолютном), поэтому её поддержку он прекращает, и новые версии под неё выкладываться не будут. По-моему, Adobe что-то такое в отношении Linux недавно сделала.
Самое простое — запускайте его только после запуска VPN.
Я, кстати, не знаю, что apt-get передаёт серверу при обновлении, есть ли там локальный IP-адрес, и как велико количество уникальной информации, позволяющей серверу различать клиентов.
Аутентичность пакетов перед их установкой проверяет сама система по имеющимся PGP-подписям, так что на этот счёт переживать не стоит. Пакеты могут скачиваться откуда угодно, хоть у вашего противника.
комментариев: 9796 документов: 488 редакций: 5664
Хороший пример.
Это кстати, одно из основных преимуществ: браузеры, офисные и графические редакторы, смотрелки файлов, масса всего. В коммерческих системах никто из пользователей выяснять, где эта библиотека используется — не будет. Да там это и достаточно сложно сделать. Также и кто-то из производителей софта может просто на это забить. И дырка останется открытой.
К тому же, отсутствие пакетного менеджера, зоопарк библиотек и повторяющихся фрагментов кода не способствует эффективному использованию кода с открытыми исходниками. Это в коммерческих программах могут свой велосипед вместо какой-то библиотеки написать или выкупить у кого-то права на использование. Завышенная цена на программные продукты оправдает коммерческую прибыль от такого неэффективного создания и использования кода.
Если вы ставите в Linux-систему то, чего в ней нет, то вся ответственность и затраты времени/сил на поддержку этого ложится на вас. В обычном случае — обновился пакет и мэнтейнеры дистра поправили всё от него зависящее. А ваш самосборный пакет может прекратить работать, пока вы не выясните, в чём там дело, сами не исправите или не скачаете новую версию.
Ещё нюанс. Разработки программ в виде исходников часто идут под свежие версии библиотек, а мэнтейнеры дистров бэкпортят это в более старое окружение. Если вы поставите вручную, не сделав корректный бэкпорт, то вам придётся понаставить в систему кучу новых либ, утилит с шансом поломать не только безопасность, но и в ряде случаев элементарную работоспособность.
# ./configure
# make
# checkinstall
комментариев: 9796 документов: 488 редакций: 5664
Пример, кстати, хрестоматийный (как и с libpng) по двум причинам. Первая — в нём действительно нередко находили критические уязвимости, из-за чего его приходилось обновлять. Вторая — на него слишком много завязано. Если кто-то пользуется или пользовался портами, может вспомнить про эпопею «я решил-таки обновить libjpeg с 7-ой до 8-ой версии», из-за чего ему приходится перекомпилить почти весь прикладной софт — занятие на очень много часов, многие пакеты не компилятся, падают с ошибками, требуется ручное вмешательство и т.д.
На этой стадии вылезет туева хуча ошибок о ненайденных зависимостях, о несовместимых версиях, не той версии компилятора и хрен знает чем ещё. Часть из этого бардака будет решаться установкой нужных версий библиотек и инструментов, другая часть — отключением опций configure, так что готовьтесь внимательно его читать. На самом деле, если знать и понимать, как оно там внутри всё устроено, будет понятно, что нет у этой проблемы простого решения. Опрос очень нагляден, кстати.
А тут компиляция вылетит с ошибками, потому что чего-то там в каком-то режиме разрабы не протестировали, и конкретно с опциями нужными вам оно почему-то не собирается. Выглядит этот трах примерно так же, как в этом примере.
И в итоге собранный пакет не работает, а вы даже не знаете, почему.
Нормальные autotools должны включать в себя ИИ как составную часть: