Re: for_DDTP_devscript_ledgersmb_libxfce4util7
Сб 06 окт 2018 @ 20:03 Galina Anikina : > Перевела - но не полностью эти три описания. Кто-нибудь прочитайте, > подправьте пожалуйста. > $ apt show devscripts Галина, используйте веб-интерфейс DDTSS [ddtss]. Я уже скидывал ссылку на небольшое руководство о том, как пользоваться веб-интерфейсом [howto], недавно я исправил в нём все ссылки. И не надо брать описания с помощью apt show, надо пользоваться веб-интерфейсом. [ddtss] http://ddtp2.debian.net/ddtss/index.cgi/ru [howto] https://debianforum.ru/index.php?topic=8440.0
Re: html-вычитка_devel_website_using_git__на сайте Debian.org
Чт 04 окт 2018 @ 19:26 Galina Anikina : > Git не даст отправить ваши изменения в случае, если удалённый > репозиторий содержит более новые коммиты (изменения), чем ваша > локальная копия той же ветки. > может > Git не позволит вам разместить свои коммиты напрямую если удалённый > репозиторий уже содержит более новые коммиты (изменения), чем ваша > локальная копия той же ветки. Заменил "не даст" на "не позволит", остальное не менял. > В таком случае имеет место конфликт, сначала загрузите и обновите вашу > локальную копию и при необходимости выполните rebase ваших изменений > так, чтобы они были размещены после последнего коммита. > > может > В таком случае, когда возник конфликт, сначала загрузите и обновите > вашу локальную копию и при необходимости выполните rebase ваших > изменений так, чтобы они были размещены после последнего коммита. ОК. > В своём сообщении напишите что-нибудь полезное, например, то, над каким > языком или над какой частью веб-сайта вы собираетесь работать, а также > кто может за вас поручиться. > > может > В своём сообщении напишите что-нибудь полезное в предисловии, например, > над каким языком или над какой частью веб-сайта вы собираетесь > работать, и кто может за вас поручиться. "Предисловие" тут не нужно. > Клонирование локальной копии репозитория > > А почему нельзя написать > Создание локальной копии репозитория (clone). ? > > Clone a local copy of the repository > > В литературе по git по-моему так пишут. В русском переводе официальной книжки используют "клонировать" [https://git-scm.com/book/ru/v2] > Во-первых, для работы с репозиторием вам требуется установить git. > может > Во-первых, для работы с репозиторием вам необходимо установить git. ОК. > Каждый несколько дней (и до того как что-то отредактировать!) вам > следует выполнять > > поправить > КаждыЕ несколько дней (и до того как что-то отредактировать!) вам > следует выполнять ОК. > Теперь требуется немного больше работы, чем раньше (нужно два коммита), > но это неизбежно по причине того, как работают хэши коммитов git. > > может > Теперь требуется немного больше работы, чем раньше (нужно два коммита), > но это неизбежно из-за того, что так работают хэши коммитов git. ОК. > . это можно сделать следующим образом (это нужно сделать только один > раз): > поправить > . Это можно сделать следующим образом (это нужно сделать только один > раз): ОК. > (Вы можете аутентифицироваться через SSO или зарегистрироваться, указав > адрес электронной почты и пароль, если вы ещё не используете > tracker.debian.org для каких-то других целей). > > может > (Вы можете авторизироваться через SSO или зарегистрироваться, указав > адрес электронной почты и пароль, если вы ещё не используете > tracker.debian.org для каких-то других целей). Тут именно аутентифицироваться. Аутентификация и авторизация -- разные вещи.
Re: for_DDTP_devscript_ledgersmb_libxfce4util7
Почему не через web-интерфейс?
Re: Доступ к медиатеке
06.10.2018 20:39, Victor Wagner пишет: > On Sat, 6 Oct 2018 15:49:18 +0300 > artiom wrote: > > >> >> Т.е., всё-таки на первое место выходит доступность, а >> конфиденциальность данных на втором, и они не сильно чувствительны к >> этой угрозе? > > > Проблема тут не в том, сильно ли чувствительны данные к угрозам > конфиденциальности, а в том что разные данные к ним чувствительны очень > по разному. > > Нарушая фидошную традицию и вспоминая, что написано в subj, а там > написано "Доступ к медиатеке", мы можем рассмотреть угрозы > конфиденциальности для данных медиатеки. > > В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, > и которые потенциальному атакующему доступны и из другого места. > Да не, с медиатекой всё понятно. > Но, в мире есть такая штука как копирайт, поэтому если мы вообще не > будем защищать медиатеку от несанкционированного доступа, мы можем > налететь на обвинение в незаконном распространении охраняемых > копирайтом произведений. > > Насколько я понимаю, закрытие любой самой примитивной аутентификацией > во-первых отсекает 100% ботов, которые рыщут по интернету в поисках > нелегальных копий копирайченной продукции, во-вторых, является > достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы > данные не распространяем, мы их для собственных нужд на этом сервере > держим. И даже доступом к нему не торгуем. А так все это добросовестно > приобретенные фильмы. > > Ну и вообще надо вспомнить третий тип угроз - кроме доступности и > конфиденциальности атакующий может попытаться нарушить целостность > данных. То есть стереть и/или подменить то, что он стирать или > подменять не имел права. > > Поскольку в соседнем письме речь шла о нескольких пользователях, > которым предлагается дать права на удаление/изменение данных, тут дать > единого рецепта на все случаи жизни, пожалуй не получится - сначала > роспись того, какие у нас бывают пользователи и над какими данными они > имеют власть, а потом модель угроз. > Это часть модели. Но в явном виде у меня её нет. В общем-то задача состоит в том, чтобы давать разный доступ разным группам так, чтобы это было удобно. >>> Потому что первым в списке угроз "будет плохо, если они прочитают >>> ваши данные" стоит гугль, который использует данные для >>> таржетированной рекламы. И при этом существует достаточно много >>> данных, которые их владельцы старательно скармливают гуглю, чтобы >>> они попали в результаты поиска. >>> >> >> Он использует эти данные не только для рекламы. >> > Интересно, какие по вашему мнению способы использования данных гуглем > хуже таржетированной рекламы? > Не секрет, как они используют данные и какие: https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in Одна из проблем, которую уже освещали, не таргетированная реклама, а таргетированный контент. Вплоть до того, что некто может не узнать важных новостей по своему запросу. Потом, ещё это: "Иногда мы получаем запросы на доступ к данным пользователя от правоохранительных органов. Наши юристы рассматривают каждый запрос и отвечают отказом, если он составлен в слишком общих терминах или с нарушением юридических норм." Рассматривают и предоставляют. Как известно, законы везде разные. Плюс, ваши данные потенциально могут утечь: https://tproger.ru/news/facebook-87-million-leak/ Если возможно на Facebook, то почему не в гугле? К тому же, google.docs были недавно яндексом проиндексированы. И есть немало компаний и "аффилированных лиц", которым гугл передаёт данные.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 15:49:18 +0300 artiom wrote: > > Т.е., всё-таки на первое место выходит доступность, а > конфиденциальность данных на втором, и они не сильно чувствительны к > этой угрозе? Проблема тут не в том, сильно ли чувствительны данные к угрозам конфиденциальности, а в том что разные данные к ним чувствительны очень по разному. Нарушая фидошную традицию и вспоминая, что написано в subj, а там написано "Доступ к медиатеке", мы можем рассмотреть угрозы конфиденциальности для данных медиатеки. В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, и которые потенциальному атакующему доступны и из другого места. Но, в мире есть такая штука как копирайт, поэтому если мы вообще не будем защищать медиатеку от несанкционированного доступа, мы можем налететь на обвинение в незаконном распространении охраняемых копирайтом произведений. Насколько я понимаю, закрытие любой самой примитивной аутентификацией во-первых отсекает 100% ботов, которые рыщут по интернету в поисках нелегальных копий копирайченной продукции, во-вторых, является достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы данные не распространяем, мы их для собственных нужд на этом сервере держим. И даже доступом к нему не торгуем. А так все это добросовестно приобретенные фильмы. Ну и вообще надо вспомнить третий тип угроз - кроме доступности и конфиденциальности атакующий может попытаться нарушить целостность данных. То есть стереть и/или подменить то, что он стирать или подменять не имел права. Поскольку в соседнем письме речь шла о нескольких пользователях, которым предлагается дать права на удаление/изменение данных, тут дать единого рецепта на все случаи жизни, пожалуй не получится - сначала роспись того, какие у нас бывают пользователи и над какими данными они имеют власть, а потом модель угроз. > > Потому что первым в списке угроз "будет плохо, если они прочитают > > ваши данные" стоит гугль, который использует данные для > > таржетированной рекламы. И при этом существует достаточно много > > данных, которые их владельцы старательно скармливают гуглю, чтобы > > они попали в результаты поиска. > > > > Он использует эти данные не только для рекламы. > Интересно, какие по вашему мнению способы использования данных гуглем хуже таржетированной рекламы?
for_DDTP_devscript_ledgersmb_libxfce4util7
Перевела - но не полностью эти три описания. Кто-нибудь прочитайте, подправьте пожалуйста. 1) $ apt show devscripts Package: devscripts Version: 2.18.4 Priority: optional Section: devel Maintainer: Devscripts Maintainers Installed-Size: 2 252 kB Depends: dpkg- dev (>= 1.18.19), libfile-homedir-perl, sensible-utils, perl, python3:any, libc6 (>= 2.3.4) Recommends: apt, at, dctrl-tools, dput | dupload, fakeroot, file, gnupg | gnupg2, libdistro-info-perl, libdpkg- perl, libencode-locale-perl, libgit-wrapper-perl, liblist-compare-perl, libstring-shellquote-perl, libtry-tiny-perl, liburi-perl, libwww-perl, licensecheck, lintian, man-db, patch, patchutils, python3-apt, python3- debian (>= 0.1.15), python3-magic, python3-requests, python3-unidiff, python3-xdg, strace, unzip, wdiff, wget | curl, xz-utils, debian- keyring, equivs, liblwp-protocol-https-perl, libsoap-lite-perl Suggests: adequate, autopkgtest, bls-standalone, bsd-mailx | mailx, build- essential, check-all-the-things, cvs-buildpackage, devscripts-el, diffoscope, disorderfs, dose-extra (>= 4.0), duck, faketime, gnuplot, gpgv | gpgv2, how-can-i-help, libauthen-sasl-perl, libfile- desktopentry-perl, libnet-smtps-perl, libterm-size-perl, libtimedate- perl, libyaml-syck-perl, libdbd-pg-perl, mozilla-devscripts, mutt, piuparts, postgresql-client, quilt, ratt, reprotest, ssh-client, svn- buildpackage, w3m Breaks: hardening-includes, ubuntu-dev-tools (<< 0.147~) Replaces: hardening-includes, ubuntu-dev-tools (<< 0.124~) Tag: devel::debian, devel::packaging, implemented-in::perl, interface::commandline, role::program, scope::utility, suite::debian, use::checking, works-with::bugs, works-with::software:package, works- with::software:source Download-Size: 986 kB APT-Manual-Installed: no APT- Sources: http://deb.debian.org/debian sid/main amd64 Packages Descriptio n: scripts to make the life of a Debian Package maintainer easier сценар ии облегчают жизнь сопровождающих пакетов Debian Contains the following scripts, dependencies/recommendations shown in brackets afterwards: Вклю чают следующие сценарии, зависимости/рекомендации, показанные в скобках впоследствии-потом-позже . - annotate-output: run a command and prepend time and stream (O for stdout, E for stderr) for every line of output - annotate-output: запустить команду и prepend время и поток (O для stdout, E для stderr) для каждой строки вывода - archpath: print tla/Bazaar package names [tla | bazaar] - archpath: печатать tla/Bazaar названия пакетов [tla | bazaar] - bts: a command-line tool for manipulating the BTS [www-browser, libauthen-sasl-perl, libnet- smtps-perl, libsoap-lite-perl, liburi-perl, libwww-perl, bsd-mailx | mailx] - bts: инструмент командной строки для взаимодействия с BTS [www-browser, libauthen-sasl-perl, libnet-smtps-perl, libsoap-lite- perl, liburi-perl, libwww-perl, bsd-mailx | mailx] - build-rdeps: search for all packages that build-depend on a given package [dctrl- tools, dose-extra, libdpkg-perl] - build-rdeps: поиск всех пакетов, зависящих от данного пакета [dctrl-tools, dose-extra, libdpkg-perl] - chdist: tool to easily play with several distributions [dctrl-tools] - chdist: инструменты для быстрой игры с различными дистибутивами [dctrl-tools] - checkbashisms: check whether a /bin/sh script contains any common bash-specific constructs - checkbashisms: проверить содержит ли сценарий /bin/sh любые, общие с bash-определёнными, конструкции - cowpoke: upload a Debian source package to a cowbuilder host and build it, optionally also signing and uploading the result to an incoming queue [ssh-client] - cowpoke: обновить исходные пакеты Debian для cowbuilder host и собрать их (в бинарные пакеты), опционально отметить также и обновить результат во внутренней очереди [ssh-client] - cvs-debi, cvs-debc: wrappers around debi and debc respectively (see below) which allow them to be called from the CVS working directory [cvs-buildpackage] - cvs-debi, cvs-debc: обёртки вокруг debi и debc соответственно (смотрите ниже), которые позволяют вызывать их из рабочего каталога CVS [cvs-buildpackage] - cvs- debrelease: wrapper around debrelease which allows it to be called from the CVS working directory [cvs-buildpackage, dupload | dput, ssh-client] - cvs-debrelease: обёртка вокруг debrelease, которая позволяет вызвать их из рабочих каталогов CVS [cvs-buildpackage, dupload | dput, ssh-client] - cvs-debuild: wrapper for cvs- buildpackage to use debuild as its package building program [cvs- buildpackage, fakeroot, lintian, gnupg | gnupg2] - cvs-debuild: обёртка для cvs-buildpackage использует debuild как программу, собирающую пакет [cvs-buildpackage, fakeroot, lintian, gnupg | gnupg2] - dcmd: run a given command replacing the name of a .changes or .dsc file with each of the files referenced
Re: nginx и проксирование
On Sat, 6 Oct 2018 17:56:30 +0300 artiom wrote: d > > Из того, что каждый сервис будет иметь свой собственный внешний > > (видимый клиентам) хостнейм, никак не следует что пользователей > > будут по этому хостнейму пускать на сервис напрямую, минуя общий > > для всех сервисов фронтенд-прокси. > > > > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, Не домена, а хоста. И все их A-записи указывают на один и тот же IP-адрес - тот, на котором nginx. В конфиге у nginx пишем, что если к нему пришли, указав в http запросе такой-то хостнейм, проксируем на такой-то сервис. Обратная прокси будет одна. И слушать будет на одном IP-адресе и одном порту. Просто в этот IP-адрес будет резолвится несколько имен, и на основании того имени, к которому обратился клиент (и честно указал это в HTTP запросе, как это позволяет HTTP/1.0 и безусловно требует HTTP/1.1) nginx будет решать куда именно проксировать прошедший авторизацию запрос. Просто вы тут разработали систему, когда признаком того, к какому сервису относится запрос, является префикс пути, а я предлагаю использовать для этого другую часть URL - имя хоста. > меня перекидывает на ещё один обратный прокси, который делает проброс > только если пользователь авторизован? >
Re: nginx и проксирование
06.10.2018 13:46, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:56:42 +0300 > artiom wrote: > >> 05.10.2018 22:54, Victor Wagner пишет: >>> В Fri, 5 Oct 2018 22:32:47 +0300 >>> artiom пишет: >>> Да, nginx ни в чём, ни в чём не виноват. Это на странице прописано включение css от корня и браузер, соответственно, делает GET запрос. Вопрос, как сделать, не заводя корень, и возможно ли это? >>> >>> А подумать? Вот у нас есть поток данных, идущих от сервера к >>> браузеру через proxy. >>> >> Вот через подумать и выходит, что технически это возможно. >> >>> Вот где-то внутри этого потока данных js-код, формирующий URL >>> запроса. По-моему, очевидно, что прошерстить весь этот код и >>> выловить URL, чтобы их переписать - задача в общем виде не >>> разрешимая. >>> Так и не требуется. Достаточно подменить PUT/POST/GET/etc., >>> обращающиеся > > Где подменить? На клиенте? На proxy-то не получится. > Вот именно тут и есть проблема. На прокси получится. Только для этого ему нужно понимать, на какой из сервисов перекидывать запрос. > Вот у вас есть два сервиса, каждый из > которых считает что он в корне сайта, и формирует URL на свои кнопки > как /images/something.gif. > > Вот приходит к вам на прокси запрос GET /images/something.gif. > > Как вы определите, его надо переписывать > на /service1/images/something.gif > или на /service2/images/something.gif? > Да, про это я в курсе. Вообще, сделать это может и возможно. Я даже смутно представляю, как с костылями в виде общего cookies для всех сервисов, но это извращение. >> к /bla/bla/... на BASE_URL/bla/bla/... >> >>> Если же у нас код дошел до браузера неизменным, то браузер отправит >>> на прокси ту URL, которую ему отдал сервер. И определить от какого >>> из проксированных сервисов эта URL тоже будет ох как непросто. >>> >>> Раз задача в общем виде неразрешимая, то решать ее придется в >>> частных случаях, для каждого из сервисов по отдельности, >>> конфигурируя каждый сервис (если он это позволяет) на работу под >>> уникальным префиксом, причем совпадающим с тем, что был указан нв >>> фронтэнде. >> Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к >> сервисам, в которых её нет. >> >>> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три >>> >>> Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. >>> Расходуются только строчки в файле зоны локального DNS. >>> >> Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP >> через nginx это не вариант. Мне же их надо внутри держать, а запрос >> проксировать лишь тогда, когда авторизация прошла. > > Почему не вариант? Вариант. Вы заводите В nginx name-based > virtualhost, и его проксируете весь. Так что запрос > https://externalname/static/image.gif проксируется в > http://internalcontainerip:port/static/image.gif. Т.е. меняется при > проксировании адрес nginx на адрес контейнера (или на localhost, если > сервис крутится на той же машине, что и nginx. А та часть URl,которая > следует за именем хоста - не меняется. > В смысле, он виден только изнутри и недоступен из внешней сети? > Можно еще извернуться так, чтобы контейнер с сервисом считал что то > имя, под которым вся сеть видит виртуальный хост на nginx - это его имя > Примерно так у меня и есть, в целом: https://habr.com/post/359344/ > Из того, что каждый сервис будет иметь свой собственный внешний > (видимый клиентам) хостнейм, никак не следует что пользователей будут по > этому хостнейму пускать на сервис напрямую, минуя общий для всех > сервисов фронтенд-прокси. > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, меня перекидывает на ещё один обратный прокси, который делает проброс только если пользователь авторизован?
Re: Доступ к медиатеке
А причём здесь вообще телеграм? 06.10.2018 16:01, Евгений Кабанов пишет: >> Впрочем, несколько ушли от темы доступа к медиатеке. >> Музыка и фильмы - это явно не те данные, которые я хочу защитить ото >> всех. Мне нужно предоставить доступ на запись/изменение с аудитом для >> некоторых авторизованных людей. >> И на чтение для большинства авторизованных. >> Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на >> практике. >> Может имеются ещё варианты? > > Есть простые, но возможно не правильные решения: > 1. грузите контент в приватный канал телеги; > 2. назначаете админов с нужными правами (на изменение); > 3. просто подписываете всех остальных, кого решите; > 4. поддерживаете состав подписчиков и админов в соответствии с > собственной политикой. >
Re: Доступ к медиатеке
D. H. -> debian-russian@lists.debian.org @ Sat, 6 Oct 2018 06:18:14 -0500: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > Вот это я пошел гуглить. Что-то пропустил похоже. Угу. Пару месяцев назад, подыскивая для машинки на DigitalOcean адрес, не заблокированный Роскомнадзором, я перебрал пять их датацентров. С трудом нашел.
Re: Доступ к медиатеке
> Впрочем, несколько ушли от темы доступа к медиатеке. > Музыка и фильмы - это явно не те данные, которые я хочу защитить ото > всех. Мне нужно предоставить доступ на запись/изменение с аудитом для > некоторых авторизованных людей. > И на чтение для большинства авторизованных. > Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на > практике. > Может имеются ещё варианты? Есть простые, но возможно не правильные решения: 1. грузите контент в приватный канал телеги; 2. назначаете админов с нужными правами (на изменение); 3. просто подписываете всех остальных, кого решите; 4. поддерживаете состав подписчиков и админов в соответствии с собственной политикой. -- Евгений Кабанов
Re: Доступ к медиатеке
Впрочем, несколько ушли от темы доступа к медиатеке. Музыка и фильмы - это явно не те данные, которые я хочу защитить ото всех. Мне нужно предоставить доступ на запись/изменение с аудитом для некоторых авторизованных людей. И на чтение для большинства авторизованных. Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на практике. Может имеются ещё варианты? 04.10.2018 20:44, artiom пишет: > Требуется организовать доступ к медиатеке, позволяющий нескольким > пользователям переименовывать, удалять и, главное, добавлять файлы. > > Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о > полноценном управлении, как файловой структурой, и говорить нечего. > > При этом, условие такого, что пользователи авторизуются через LDAP. > > Один из вариантов был - использовать файловые менеджеры в > докер-контейнере, типа sprut.io, но с LDAP там всё плохо. > Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и > системный pam-ldap модуль. Но встали вопросы: как не дать пользователю > выполнять команды и ограничить просмотр дерева не выше того каталога, в > котором хранится медиатека? > > Есть какие-то варианты того, как эту задачу решают белые люди? > Что посоветуете? > И по pam-ldap вопросы тоже актуальны. >
Re: Доступ к медиатеке
06.10.2018 13:53, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:59:41 +0300 > artiom wrote: > >> 05.10.2018 23:06, D. H. пишет: >>> On 05/10/18 02:45 PM, artiom wrote: А от кого вы защищаться собрались? >>> >>> Как правильно было сказано уже не помню где. Но суть примерно такая: >>> >>> - Вам есть что скрывать? >>> - Нет, но мои данные не ваше дело. >>> >> Не в тему. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Защищаться надо > > 1. От пьяного тракториста, который переедет интернет кабель > 2. От обкурившегося сетевого админа, который сломает роутинг. > 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако > может случайно попасть под раздачу, оказавшись в одном /16 блоке с > телеграмовской прокси. > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > > От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. > Т.е., всё-таки на первое место выходит доступность, а конфиденциальность данных на втором, и они не сильно чувствительны к этой угрозе? > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > Какая "прелесть". > Определить от каких угроз несанкционированного доступа следует защищать > данные, практически невозможно, если не знать характера данных. > Конечно. Я о том и говорю. Когда вы будете думать, надо ли защищаться и от кого, вопрос о характере данных встанет. > Потому что первым в списке угроз "будет плохо, если они прочитают > ваши данные" стоит гугль, который использует данные для таржетированной > рекламы. И при этом существует достаточно много данных, которые их > владельцы старательно скармливают гуглю, чтобы они попали в результаты > поиска. > Он использует эти данные не только для рекламы.
Re: Доступ к медиатеке
> On 06/10/18 04:59 AM, artiom wrote: >> Не в тему. > > Почему же? У вас душ к примеру на улице находиться? полностью прозрачный? > Потому что вопрос был не о душе на улице и не о философских проблемах необходимости защиты информации. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > > В том то и дело. Вопрос не верен. Не от кого. А почему (ну или зачем). А > ответ уже есть :) > Вопрос совершенно верен. Думаю, что эту тему я знаю несколько лучше вас. Если хотите формально: какова модель нарушителя? >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Очень просто. Задача обеспечить конфиденциальность целостность и > доступность. > От кого? Кому? Для чего? На каком уровне? Вы говорите общими словами, а они дают мало.
Re: Доступ к медиатеке
06.10.2018 14:18, D. H. пишет: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > > Вот это я пошел гуглить. Что-то пропустил похоже. > Совсем немного: блокировки миллионов адресов, судебные иски и срач в сторону РКН.
Re: Доступ к медиатеке
> On 06/10/18 04:58 AM, artiom wrote: >> От задач. Если вы хотите, например, имея облако, отдать файл по ссылке >> кому-то постороннему. > > Боже упаси и сохрани от хранения важной инфы в облаках. (икону наверное > надо ещё приложить) > В своём облаке. Что такое "важная инфа"? Вы как-то измеряете степень важности? >> Как вы это сделаете, если NAS доступен только через VPN? > > А я сказал только? > Ну ok, доступен через VPN для манипуляции файлами. А манипулировать ими хочу не только я. Кроме того, надо поднимать VPN на NAS, что само по себе задач не решит, лишь откроет другие пути, которые без VPN не работают. >> Вы будете всех переводить на VPN? > > Это даже телефоны умеют. В чем проблема? > В том, что это надо сделать тому, кто это делать не хочет. Это переусложнение. Вам надо поделиться с человеком данными, а вы ему не только ссылку, но "поставь VPN". > Итого: > > Это не проблема VPN, это проблема внезапно возникшего человека. У > которого нет в данный конкретный момент VPN. И с ним вопрос будет решен > индивидуально, как ему и мне удобнее. > Опять же: каковы условия? Есть пять человек, которым этот VPN нафиг не сдался. Онис гитом, например, работают. Всё по SSH, интерфейс по HTTPS. Зачем тут VPN? > Как правило таки файлы умещаются в обычный email. > > Всё остальное. Ну вопрос только к самой информации. Смотря что вы хотите > раздавать. > И это тоже: что и кому.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 12:59:41 +0300 artiom wrote: > 05.10.2018 23:06, D. H. пишет: > > On 05/10/18 02:45 PM, artiom wrote: > >> А от кого вы защищаться собрались? > > > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > > > - Вам есть что скрывать? > > - Нет, но мои данные не ваше дело. > > > Не в тему. > Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > Если вы этого не понимаете, то как вы определите перечень мер защиты? Защищаться надо 1. От пьяного тракториста, который переедет интернет кабель 2. От обкурившегося сетевого админа, который сломает роутинг. 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако может случайно попасть под раздачу, оказавшись в одном /16 блоке с телеграмовской прокси. 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. Определить от каких угроз несанкционированного доступа следует защищать данные, практически невозможно, если не знать характера данных. Потому что первым в списке угроз "будет плохо, если они прочитают ваши данные" стоит гугль, который использует данные для таржетированной рекламы. И при этом существует достаточно много данных, которые их владельцы старательно скармливают гуглю, чтобы они попали в результаты поиска.
Re: nginx и проксирование
On Sat, 6 Oct 2018 12:56:42 +0300 artiom wrote: > 05.10.2018 22:54, Victor Wagner пишет: > > В Fri, 5 Oct 2018 22:32:47 +0300 > > artiom пишет: > > > >> Да, nginx ни в чём, ни в чём не виноват. > >> Это на странице прописано включение css от корня и браузер, > >> соответственно, делает GET запрос. > >> Вопрос, как сделать, не заводя корень, и возможно ли это? > > > > А подумать? Вот у нас есть поток данных, идущих от сервера к > > браузеру через proxy. > > > Вот через подумать и выходит, что технически это возможно. > > > Вот где-то внутри этого потока данных js-код, формирующий URL > > запроса. По-моему, очевидно, что прошерстить весь этот код и > > выловить URL, чтобы их переписать - задача в общем виде не > > разрешимая. > >Так и не требуется. Достаточно подменить PUT/POST/GET/etc., > >обращающиеся Где подменить? На клиенте? На proxy-то не получится. Вот у вас есть два сервиса, каждый из которых считает что он в корне сайта, и формирует URL на свои кнопки как /images/something.gif. Вот приходит к вам на прокси запрос GET /images/something.gif. Как вы определите, его надо переписывать на /service1/images/something.gif или на /service2/images/something.gif? > к /bla/bla/... на BASE_URL/bla/bla/... > > > Если же у нас код дошел до браузера неизменным, то браузер отправит > > на прокси ту URL, которую ему отдал сервер. И определить от какого > > из проксированных сервисов эта URL тоже будет ох как непросто. > > > > Раз задача в общем виде неразрешимая, то решать ее придется в > > частных случаях, для каждого из сервисов по отдельности, > > конфигурируя каждый сервис (если он это позволяет) на работу под > > уникальным префиксом, причем совпадающим с тем, что был указан нв > > фронтэнде. > Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к > сервисам, в которых её нет. > > > > >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу > >> три > > > > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. > > Расходуются только строчки в файле зоны локального DNS. > > > Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP > через nginx это не вариант. Мне же их надо внутри держать, а запрос > проксировать лишь тогда, когда авторизация прошла. Почему не вариант? Вариант. Вы заводите В nginx name-based virtualhost, и его проксируете весь. Так что запрос https://externalname/static/image.gif проксируется в http://internalcontainerip:port/static/image.gif. Т.е. меняется при проксировании адрес nginx на адрес контейнера (или на localhost, если сервис крутится на той же машине, что и nginx. А та часть URl,которая следует за именем хоста - не меняется. Можно еще извернуться так, чтобы контейнер с сервисом считал что то имя, под которым вся сеть видит виртуальный хост на nginx - это его имя Из того, что каждый сервис будет иметь свой собственный внешний (видимый клиентам) хостнейм, никак не следует что пользователей будут по этому хостнейму пускать на сервис напрямую, минуя общий для всех сервисов фронтенд-прокси. --
Re: Доступ к медиатеке
05.10.2018 23:06, D. H. пишет: > On 05/10/18 02:45 PM, artiom wrote: >> А от кого вы защищаться собрались? > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > - Вам есть что скрывать? > - Нет, но мои данные не ваше дело. > Не в тему. Вопрос совершенно конкретный: "От кого вы собрались защищаться?" Если вы этого не понимаете, то как вы определите перечень мер защиты?
Re: Доступ к медиатеке
06.10.2018 00:13, D. H. пишет: > On 05/10/18 02:33 PM, artiom wrote: >> VPN привносит другие проблемы, которые мне не требуются. > > Ну со мной поделитесь, я пока не столкнулся но возможно удаться избежать > этого в будущем так как буду иметь в виду и думать над потенциальным > решением. > От задач. Если вы хотите, например, имея облако, отдать файл по ссылке кому-то постороннему. Как вы это сделаете, если NAS доступен только через VPN? Вы будете всех переводить на VPN? >> Не будем спорить. > > И не собирался. >
Re: nginx и проксирование
05.10.2018 22:54, Victor Wagner пишет: > В Fri, 5 Oct 2018 22:32:47 +0300 > artiom пишет: > >> Да, nginx ни в чём, ни в чём не виноват. >> Это на странице прописано включение css от корня и браузер, >> соответственно, делает GET запрос. >> Вопрос, как сделать, не заводя корень, и возможно ли это? > > А подумать? Вот у нас есть поток данных, идущих от сервера к браузеру > через proxy. > Вот через подумать и выходит, что технически это возможно. > Вот где-то внутри этого потока данных js-код, формирующий URL запроса. > По-моему, очевидно, что прошерстить весь этот код и выловить URL, > чтобы их переписать - задача в общем виде не разрешимая. >Так и не требуется. Достаточно подменить PUT/POST/GET/etc., обращающиеся к /bla/bla/... на BASE_URL/bla/bla/... > Если же у нас код дошел до браузера неизменным, то браузер отправит на > прокси ту URL, которую ему отдал сервер. И определить от какого из > проксированных сервисов эта URL тоже будет ох как непросто. > > Раз задача в общем виде неразрешимая, то решать ее придется в частных > случаях, для каждого из сервисов по отдельности, конфигурируя каждый > сервис (если он это позволяет) на работу под уникальным префиксом, > причем совпадающим с тем, что был указан нв фронтэнде. > Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к сервисам, в которых её нет. > >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три > > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. > Расходуются только строчки в файле зоны локального DNS. > Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP через nginx это не вариант. Мне же их надо внутри держать, а запрос проксировать лишь тогда, когда авторизация прошла. >> сервиса висит за LDAP авторизацией через nginx > > Вот как раз transmission прекрасно работает с указанием префикса. > > Там единственное, что нужно сделать кроме проксирования > /transmission/ это перманентный редирект /transmisson > на /transmission/web. Ok, посмотрю, как с ним разобраться. jDownloader работает тоже. Остаётся GUI к youtube-dl.
[DONE] wml://security/2018/dsa-4309.wml
--- ../../english/security/2018/dsa-4309.wml2018-10-02 15:13:30.332337224 +0500 +++ 2018/dsa-4309.wml 2018-10-02 15:24:14.033632645 +0500 @@ -1,28 +1,28 @@ -security update +#use wml::debian::translation-check translation="ba0ee6a16998af689e05daf7f66bf2c36ac0b5d3" mindelta="1" maintainer="Lev Lamberov" +обновление безопасности -Google's OSS-Fuzz revealed an exploitable bug in the gmp plugin caused by the -patch that fixes https://security-tracker.debian.org/tracker/CVE-2018-16151;>\ -CVE-2018-16151 and https://security-tracker.debian.org/tracker/CVE-2018-16151;>\ +Сотрудники Google из проекта OSS-Fuzz обнаружили уязвимость в дополнении gmp, которая появилась из-за +заплаты, исправляющей https://security-tracker.debian.org/tracker/CVE-2018-16151;>\ +CVE-2018-16151 и https://security-tracker.debian.org/tracker/CVE-2018-16151;>\ CVE-2018-16151 (DSA-4305-1). -An attacker could trigger it using crafted certificates with RSA keys with -very small moduli. Verifying signatures with such keys would cause an integer -underflow and subsequent heap buffer overflow resulting in a crash of the -daemon. While arbitrary code execution is not completely ruled out because of -the heap buffer overflow, due to the form of the data written to the buffer -it seems difficult to actually exploit it in such a way. +Злоумышленник может вызвать эту ошибку, используя специально сформированные сертификаты с ключами RSA, +имеющими очень маленькие показатели. Проверка подписей с такими ключами вызывает отрицательное переполнение +целых чисел и последующее переполнение буфера, приводящее к аварийной остановке +службы. Хотя выполнение произвольного кода из-за переполнения буфера не может быть +полностью исключено, уязвимость, как кажется, весьма сложно для этого использовать +из-за формы записываемых в буфер данных. -For the stable distribution (stretch), this problem has been fixed in -version 5.5.1-4+deb9u4. +В стабильном выпуске (stretch) эта проблема была исправлена в +версии 5.5.1-4+deb9u4. -We recommend that you upgrade your strongswan packages. +Рекомендуется обновить пакеты strongswan. -For the detailed security status of strongswan please refer to -its security tracker page at: +С подробным статусом поддержки безопасности strongswan можно ознакомиться на +соответствующей странице отслеживания безопасности по адресу https://security-tracker.debian.org/tracker/strongswan;>\ https://security-tracker.debian.org/tracker/strongswan # do not modify the following line #include "$(ENGLISHDIR)/security/2018/dsa-4309.data" -# $Id: $
[DONE] wml://security/2018/dsa-4311.wml
--- ../../english/security/2018/dsa-4311.wml2018-10-06 11:19:57.599218439 +0500 +++ 2018/dsa-4311.wml 2018-10-06 11:24:25.933156743 +0500 @@ -1,20 +1,21 @@ -security update +#use wml::debian::translation-check translation="109968bd2506826f7f4be00312b1c6161931ac20" mindelta="1" maintainer="Lev Lamberov" +обновление безопасности -joernchen of Phenoelit discovered that git, a fast, scalable, -distributed revision control system, is prone to an arbitrary code -execution vulnerability via a specially crafted .gitmodules file in a -project cloned with --recurse-submodules. +joernchen из Phenoelit обнаружил, что git, быстрая масштабируемая распределённая +система управления изменениями, уязвима к выполнению произвольного +кода при использовании специально сформированного файла .gitmodules в +проекте, при его клонировании с использованием опции --recurse-submodules. -For the stable distribution (stretch), this problem has been fixed in -version 1:2.11.0-3+deb9u4. +В стабильном выпуске (stretch) эта проблема была исправлена в +версии 1:2.11.0-3+deb9u4. -We recommend that you upgrade your git packages. +Рекомендуется обновить пакеты git. -For the detailed security status of git please refer to its security -tracker page at: -https://security-tracker.debian.org/tracker/git;>https://security-tracker.debian.org/tracker/git +С подробным статусом поддержки безопасности git можно ознакомиться на +соответствующей странице отслеживания безопасности по адресу +https://security-tracker.debian.org/tracker/git;>\ +https://security-tracker.debian.org/tracker/git # do not modify the following line #include "$(ENGLISHDIR)/security/2018/dsa-4311.data" -# $Id: $
[DONE] wml://security/2018/dsa-4310.wml
--- ../../english/security/2018/dsa-4310.wml2018-10-04 01:03:04.079168295 +0500 +++ 2018/dsa-4310.wml 2018-10-04 08:02:11.850097487 +0500 @@ -1,19 +1,20 @@ -security update +#use wml::debian::translation-check translation="ede79f1afd13feaf7d39f8d7668240a75fae445c" mindelta="1" maintainer="Lev Lamberov" +обновление безопасности -Two security issues have been found in the Mozilla Firefox web browser, -which could potentially result in the execution of arbitrary code inside -the sandboxed content process. +В веб-браузере Mozilla Firefox были обнаружены две проблемы безопасности, +которые потенциально могут приводить к выполнению произвольного кода в +процессе обработки содержимого, размещённом в песочнице. -For the stable distribution (stretch), these problems have been fixed in -version 60.2.2esr-1~deb9u1. +В стабильном выпуске (stretch) эти проблемы были исправлены в +версии 60.2.2esr-1~deb9u1. -We recommend that you upgrade your firefox-esr packages. +Рекомендуется обновить пакеты firefox-esr. -For the detailed security status of firefox-esr please refer to its -security tracker page at: -https://security-tracker.debian.org/tracker/firefox-esr;>https://security-tracker.debian.org/tracker/firefox-esr +С подробным статусом поддержки безопасности firefox-esr можно ознакомиться на its +соответствующей странице отслеживания безопасности по адресу +https://security-tracker.debian.org/tracker/firefox-esr;>\ +https://security-tracker.debian.org/tracker/firefox-esr # do not modify the following line #include "$(ENGLISHDIR)/security/2018/dsa-4310.data" -# $Id: $
