id: Гость   вход   регистрация
текущее время 11:56 28/03/2024
Автор темы: Гость, тема открыта 30/09/2011 05:44 Печать
Категории: софт, tor
https://www.pgpru.com/Форум/АнонимностьВИнтернет/СкачиваниеВидеоИзПодTorBrowser
создать
просмотр
ссылки

Скачивание видео из под Tor Browser


Прошу помочь тех, кто разбирается. Скачал и установил последнюю версию Тор Браузер. Работает хорошо, стабильно. Но не могу ни просмотреть, ни скачать видео практически ниоткуда. Требует установить флэш плэйер, а установить я его не могу. Он почему-то устанавливается на другой файрфокс, который установлен в системе. Тор Браузер я запускаю со сменного носителя. Как обойти проблему к сожалению не знаю.
Заранее спасибо.


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (29/01/2015 16:15)   <#>
gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --list-sigs 0x5C808C2B65558117
Подписан:
Christian Bayle
Arnaud Quette


Не будет ли это означать, что теперь любой пакет, подписанный ключом этого автора, система будет считать валидным? Как разруливается, кто что имеет право подписывать? apt-get всё хорошо сделает?
— unknown (29/01/2015 16:26, исправлен 29/01/2015 16:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Нет, я только хотел об этом предупредить.



Никак.



С этой т.з. — плохо.


Теперь этот автор (или кто-то утащивший его ключ), который не является владельцем официального подписывающего ключа Debian, может протроянивать вашу систему не только своими собранными пакетами, но и подписывать левые пакеты якобы от Debian. Его можно поймать если сверять все подписи пакетов до установки, но по умолчанию apt этого не делает.


С другой стороны, любой пакет — это потенциальный троян. Пофиг, что вы ставите: можете ставить утилиту, а вам протроянят GRUB. Поэтому, разделять подписи особого смысла нет.

— Гость (29/01/2015 16:31)   <#>
ffmpeg через ffmpeg -i video -i audio out.avi сливает как попало — видео теряет в качестве, звук тоже штормит. Но зато с debian multimedia теперь ставится mencoder, где всё ОК.


В рот мне ноги. А можно, чтоб apt хотя бы предупреждал, что ставит пакеты из сомнительного источника? Наверно, меньшим злом сейчас будет удалить от греха подальше этот ключ. По крайней мере, до тех пор, пока снова не понадобится что-то доустановить из их репа, можно будет спать спокойно.
— Гость (29/01/2015 16:42)   <#>

Сделал apt-key del. Ключ не сразу удалился, что странно. То ли влияет наличие/отсутствие префикса 0x, то ли просто глюки. В sources.list тоже закомментил реп, что он более не ругался.


Они могли бы организовать apt иначе, назначив роли ключам, чтоб каждый мог подписывать только то, на что у него есть компетенция. Конечно, мог бы быть и мастер-ключ, но не у каждого разработчика или владельца репа.
— unknown (29/01/2015 17:57, исправлен 29/01/2015 17:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Он один у выпускающего дистра. И один на каждый доп. репозиторий. Все пакеты и так ставятся в систему с правами рута. Какая разница, будет вам протроянено ядро левым mplayer'ом или левым kernel'ом, подписанным ключом mplayer?

— Гость (29/01/2015 18:04)   <#>

Много их там: stable-ключи, automatic-ключи... у меня apt-key list сейчас показывает наличие 10-ти ключей.


Ну и что? Рут мог бы разруливать, в какие пути какой реп что может ставить. Как вы думаете, почему в BSD есть /usr, а есть /usr/local, причём ни один пакет ничего не может поставить вне /usr/local? Тут можно было бы сделать аналогично: под каждый реп — свой /usr/local. А юзеры критичные пакеты всегда будут брать из /usr/bin, потому что PATH. По-хорошему, конечно, тут уже нужен SELinux.
— unknown (29/01/2015 21:00, исправлен 29/01/2015 21:10)   профиль/связь   <#>
комментариев: 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, то не ставьте этих пакетов вообще. А то поставил, отвернулся и зажмурился.



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

— Гость (30/01/2015 03:49)   <#>

Минимум в плане записи файлов можно сделать традиционными средствами UNIX: запускать установщик пакетов от имени непривелегированного юзера с дропом прав после запуска, причём права должны быть такие, что в /usr/local он писать может, а в другие пути /usr — нет.


Охотно верю, поэтому считаю, что в моей модели угрозы виртуалки будут самым правильным выбором.


А мне кажется, что это вопросы, с которых всё должно начинаться, а не заканчиваться ими. «Чему мы доверяем-то?». Хотя, в принципе, да, даже зная имена пакетов, это не гарантия ни чему. Вдруг в библиотеке libnsa сидит файл /usr/bin/gpg, который будет apt'ом записан вместо настоящего gpg?


Юзабилити тоже важно. По-хорошему, под мультимедиа нужно отвести отдельный дом, вырубить его из сети, ставить туда всё, что заблагорассудится, и никуда не отворачиваться. Без виртуалок это не делается.
— Гость (30/01/2015 10:29)   <#>


Либо libnsa будет конфликтовать с gpg (мейнтейнеры пропишут), и APT её не поставит, либо dpkg при попытке установить пакет страшно разругается на конфликт содержимого пакетов, и всё равно его не поставит.
— Гость (30/01/2015 23:09)   <#>
Вместо уже существующего gpg можно установить другой критический пакет, да ещё дать ему какие-то приоритеты над другими через настройки (поменять PATH или ешё как).
— unknown (30/01/2015 23:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Можно при установке выполнить скрипт, который выгрузит некий файл и запишет его как руткит в GRUB, в initrd, куда угодно, а после загрузки и активации он всё за собой на системе подчистит.
— Гость (03/02/2015 12:42)   <#>

Кстати, прокрутка в новой версии mplayer для так слитых файлов (звук + видео → avi-контейнер) нормально работает искоробки, поэтому извращения с vlc более не нужны. Ну, хоть какие-то баги исправились, а то в основном лишь к старым добавляются новые.
— SATtva (03/02/2015 13:17)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Многие называют это прогрессом. :)
— Гость (09/02/2015 08:47)   <#>

Зато есть старые файлы, которые когда-то были слиты через старый mencoder и игрались старым mplayer или старым vlc с известными проблемами. Если теперь их проирывать новым mplayer'ом, то играются нормально, но без прокрутки. Если их проигрывать новым vlc, то на видео через каждые сколько-то секунд будут видны такие артефакты, как будто два разных видео искуственно слили в одно. Т.е. удачный баг-пофикс касается только новых файлов, обработанных новыми версиями mencoder'а и проигрываемых новым mplayer'ом, а вот со старыми уже готовыми файлами теперь всё стало только хуже. Даже если ручная перекодировка видеопотока через mencoder спасёт дело, это всё равно ад: даже на Intel i7 перекодировка занимает по времени столько же, сколько сама длительность видео, а на i5 уже в два раза больше.
— unknown (09/02/2015 09:38, исправлен 09/02/2015 09:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У mplayer (надеюсь вы используете его без GUI) можно открыть man и ужаснуться количеству опций. Есть шанс, что вы подберёте такие опции, при которых он не будет падать или зависать на прокрутке файлов. Смутно припоминаю, что это опции, касающиеся синхронизации кадров.

На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3