Скачивание видео из под Tor Browser
Прошу помочь тех, кто разбирается. Скачал и установил последнюю версию Тор Браузер. Работает хорошо, стабильно. Но не могу ни просмотреть, ни скачать видео практически ниоткуда. Требует установить флэш плэйер, а установить я его не могу. Он почему-то устанавливается на другой файрфокс, который установлен в системе. Тор Браузер я запускаю со сменного носителя. Как обойти проблему к сожалению не знаю.
Заранее спасибо.
Arnaud Quette
Не будет ли это означать, что теперь любой пакет, подписанный ключом этого автора, система будет считать валидным? Как разруливается, кто что имеет право подписывать? apt-get всё хорошо сделает?
комментариев: 9796 документов: 488 редакций: 5664
Нет, я только хотел об этом предупредить.
Никак.
С этой т.з. — плохо.
Теперь этот автор (или кто-то утащивший его ключ), который не является владельцем официального подписывающего ключа Debian, может протроянивать вашу систему не только своими собранными пакетами, но и подписывать левые пакеты якобы от Debian. Его можно поймать если сверять все подписи пакетов до установки, но по умолчанию apt этого не делает.
С другой стороны, любой пакет — это потенциальный троян. Пофиг, что вы ставите: можете ставить утилиту, а вам протроянят GRUB. Поэтому, разделять подписи особого смысла нет.
В рот мне ноги. А можно, чтоб apt хотя бы предупреждал, что ставит пакеты из сомнительного источника? Наверно, меньшим злом сейчас будет удалить от греха подальше этот ключ. По крайней мере, до тех пор, пока снова не понадобится что-то доустановить из их репа, можно будет спать спокойно.
Сделал apt-key del. Ключ не сразу удалился, что странно. То ли влияет наличие/отсутствие префикса 0x, то ли просто глюки. В sources.list тоже закомментил реп, что он более не ругался.
Они могли бы организовать apt иначе, назначив роли ключам, чтоб каждый мог подписывать только то, на что у него есть компетенция. Конечно, мог бы быть и мастер-ключ, но не у каждого разработчика или владельца репа.
комментариев: 9796 документов: 488 редакций: 5664
Он один у выпускающего дистра. И один на каждый доп. репозиторий. Все пакеты и так ставятся в систему с правами рута. Какая разница, будет вам протроянено ядро левым mplayer'ом или левым kernel'ом, подписанным ключом mplayer?
Много их там: stable-ключи, automatic-ключи... у меня apt-key list сейчас показывает наличие 10-ти ключей.
Ну и что? Рут мог бы разруливать, в какие пути какой реп что может ставить. Как вы думаете, почему в BSD есть /usr, а есть /usr/local, причём ни один пакет ничего не может поставить вне /usr/local? Тут можно было бы сделать аналогично: под каждый реп — свой /usr/local. А юзеры критичные пакеты всегда будут брать из /usr/bin, потому что PATH. По-хорошему, конечно, тут уже нужен SELinux.
комментариев: 9796 документов: 488 редакций: 5664
SELinux имеет копию apt-get в виде se_apt-get и массу других команд с приставкой "se_". Но se_apt-get вроде всего лишь не позволяет руту ставить пакеты без подтверждения пароля и смены контекста на SELinux'овый, соответственно он гарантирует лишь, что на поставленные файлы раздадутся правильные SELinux'овые права. Но если правил для раздачи прав содержимому конкретного пакета не предусмотрено, то раздадутся права высшего уровня (unconfined). Ну т.е. да, штатный модуль SELinux для mplayer не даст ему лезть в систему и делать больше положенного, в т.ч. и на этапе установки через se_apt-get. Но чего-то более тонкого мне неизвестно, особо глубокие извращения с SELinux я не осиливал, из-за него и так масса всего в системе глючит и не работает. Если для вас конфигурирование Debian — ужас, то SELinux — это ужас за гранью разумного понимания. А SELinux в исполнении Debian из-за взаимной плохой поддержки — особо ужасен.
Каждый ключ подписывает не пакет, а общий список пакетов репа с хэш-суммами каждого пакета в этом списке. От этого списка проверяется подпись, а по этому списку сверяется сумма скачанных пакетов.
Я, возможно, неосторожно высказался в плане перестраховок, а вы сразу мне поверили в плане негатива. Я не знаю точно, как оно там работает и нет желания это разбирать. Может ли злоумышленник в список своего репа включить пакет из другого? Заметит ли apt конфликт пакетов между репами и как его разрешит? Может ли злоумышленник подменить весь список чужого репа, подписав его своим ключом и подменив там часть пакетов? А если да, то пройдёт ли это незаметно? Или на смену ключа в списке будет реакция как на смену дистра и apt предложит dist-upgrade, а простой upgrade не прокатит? Можно ли сделать хитрую подмену и хитрый MiTM, чтобы обмануть все проверки apt?
Я не знаю ответов на эти вопросы. Они мне неинтересны. Я исхожу из того, что неважно через что будет подсажен в систему троян, в тот же mplayer можно упаковать любой руткит, а на этапе инсталляции из пакета можно выполнить любой скрипт и любую команду (если нет правила SELinux). Если вы не доверяете ключу deb-multimedia, то не ставьте этих пакетов вообще. А то поставил, отвернулся и зажмурился.
Ну да, ключи старых дистров, ключи будущего стабильного, чтобы можно было обновить систему. Нужно знать досконально всю эту матчасть прежде чем обвинять разрабов в недалёкости.
Минимум в плане записи файлов можно сделать традиционными средствами UNIX: запускать установщик пакетов от имени непривелегированного юзера с дропом прав после запуска, причём права должны быть такие, что в /usr/local он писать может, а в другие пути /usr — нет.
Охотно верю, поэтому считаю, что в моей модели угрозы виртуалки будут самым правильным выбором.
А мне кажется, что это вопросы, с которых всё должно начинаться, а не заканчиваться ими. «Чему мы доверяем-то?». Хотя, в принципе, да, даже зная имена пакетов, это не гарантия ни чему. Вдруг в библиотеке libnsa сидит файл /usr/bin/gpg, который будет apt'ом записан вместо настоящего gpg?
Юзабилити тоже важно. По-хорошему, под мультимедиа нужно отвести отдельный дом, вырубить его из сети, ставить туда всё, что заблагорассудится, и никуда не отворачиваться. Без виртуалок это не делается.
Либо libnsa будет конфликтовать с gpg (мейнтейнеры пропишут), и APT её не поставит, либо dpkg при попытке установить пакет страшно разругается на конфликт содержимого пакетов, и всё равно его не поставит.
комментариев: 9796 документов: 488 редакций: 5664
Можно при установке выполнить скрипт, который выгрузит некий файл и запишет его как руткит в GRUB, в initrd, куда угодно, а после загрузки и активации он всё за собой на системе подчистит.
Кстати, прокрутка в новой версии mplayer для так слитых файлов (звук + видео → avi-контейнер) нормально работает искоробки, поэтому извращения с vlc более не нужны. Ну, хоть какие-то баги исправились, а то в основном лишь к старым добавляются новые.
комментариев: 11558 документов: 1036 редакций: 4118
Многие называют это прогрессом. :)
Зато есть старые файлы, которые когда-то были слиты через старый mencoder и игрались старым mplayer или старым vlc с известными проблемами. Если теперь их проирывать новым mplayer'ом, то играются нормально, но без прокрутки. Если их проигрывать новым vlc, то на видео через каждые сколько-то секунд будут видны такие артефакты, как будто два разных видео искуственно слили в одно. Т.е. удачный баг-пофикс касается только новых файлов, обработанных новыми версиями mencoder'а и проигрываемых новым mplayer'ом, а вот со старыми уже готовыми файлами теперь всё стало только хуже. Даже если ручная перекодировка видеопотока через mencoder спасёт дело, это всё равно ад: даже на Intel i7 перекодировка занимает по времени столько же, сколько сама длительность видео, а на i5 уже в два раза больше.
комментариев: 9796 документов: 488 редакций: 5664
У mplayer (надеюсь вы используете его без GUI) можно открыть man и ужаснуться количеству опций. Есть шанс, что вы подберёте такие опции, при которых он не будет падать или зависать на прокрутке файлов. Смутно припоминаю, что это опции, касающиеся синхронизации кадров.