Mercurial, workflow и безопасность (отрезано от Имена файлов ключей для доступа по ssh)

Любые разговоры которые хоть как-то связаны с тематикой форума

Модератор: Модераторы разделов

Ответить
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Mercurial, workflow и безопасность

Сообщение Kopilov »

SLEDopit писал(а):
12.07.2013 22:00
Омг. В .ssh/config прекрасно прописываются все алиасы и ssh m1 будет работать вполне нормально. Причём не только с ssh, но и с scp, rsync и прочими вещами, в отличие от вашего костыля.

Что ж, буду знать. Просто когда "каждый раз всё руками писать" вдруг надоело -- написать костыль было быстрее, чем искать стандартный способ реализации.
А файлы я копирую на сервер, в 95% случаев, через систему контроля версий -- и там каждый проект "знает" свой сервер, порт и учётку (тоже РЕШЕТО?), в 5% -- через MC, ведущий журнал подключений.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Kopilov писал(а):
13.07.2013 00:29
А файлы я копирую на сервер, в 95% случаев, через систему контроля версий -- и там каждый проект "знает" свой сервер, порт и учётку (тоже РЕШЕТО?),

конечно! Проект должен знать только имя хоста, в вашем случае например m1. И ВСЁ. Ну ладно, ещё каталог проекта внутри удалённого $HOME. А всякие параметры доступа (ip, port, ключ, сжатие, проч.) должны лежать в ~/.ssh/config.
Kopilov писал(а):
13.07.2013 00:29
в 5% -- через MC, ведущий журнал подключений.

тоже не нужно.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Re: Mercurial, workflow и безопасность

Сообщение Kopilov »

drBatty, обоснуйте, пожалуйста, почему хранение параметров доступа в проекте или костыле (устойчивость костыля не обсуждаем) дырявее, чем их хранение в конфиге. Я бы сказал, что скорее наоборот: конфиг лежит в определённом месте и имеет определённый формат, его может прочитать и распарсить любой желающий (имеющий права, разумеется). Проект и костыль -- точно такие же мои файлы, как и конфиги. Если бы я костыль в /usr/local/bin держал или в проекте вписал параметры доступа к серверу в файл, участвующий в контроле версий, а не в параметр хранилища -- это было бы решето.

А по сопровождению полностью согласен. Когда наш сервер с проектами переедет -- достаточно будет отредактировать конфиг SSH, а не настройки множества проектов и костыль впридачу. Просто мне не приходило в голову, что в конфигах SSH предусмотрены псевдонимы.
Любые знания приобретаются с опытом :)
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Kopilov писал(а):
15.07.2013 12:27
обоснуйте, пожалуйста, почему хранение параметров доступа в проекте или костыле (устойчивость костыля не обсуждаем) дырявее, чем их хранение в конфиге.

а почему оружие хранят в оружейной комнате с табличкой "оружейная комната", а не под подушкой?

а почему важные документы и ценности хранят в сейфе, который виден всем присутствующим, а не в трусах одной из сотрудниц?
Kopilov писал(а):
15.07.2013 12:27
Я бы сказал, что скорее наоборот: конфиг лежит в определённом месте и имеет определённый формат, его может прочитать и распарсить любой желающий (имеющий права, разумеется).

вот. Потому задача админа обеспечить права доступа тем кому можно, и запретить тем, кому нельзя. Если есть один конфиг одного формата, то это сделать проще, чем обеспечивать сохранность доступа к примеру каких-то строк в каких-то таблицах каких-то СУБД. Безопаснее в этих строках хранить безликий ID (хеш), который злоумышленнику ничего не даст. А вот развернуть этот ID может только тот, у кого есть доступ, причём именно доступ к машинам, а не доступ к этим СУБД.

При необходимости, администратор может также и зашифровать ~/.ssh/config, что-бы даже локальный администратор не смог им воспользоваться. Если пароли разбросаны по разным СУБД, то сделать это практически невозможно.
Kopilov писал(а):
15.07.2013 12:27
Проект и костыль -- точно такие же мои файлы

Kopilov писал(а):
15.07.2013 12:27
Проект и костыль -- точно такие же мои файлы

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

Да, если вы хотите усилить безопасность, то есть более разумный вариант: хранить ключ И в ./ssh/ И где-то ещё. Например это "где-то ещё" может расшифровывать своим ключом ключ в ssh (правда не очень понятно, зачем оно на локальной машине. А вот на удалённых вполне можно, если скажем доступ к хранилищу закрыт одним ключом. Тогда можно сделать автоматическую рассылку ключей, со списком реципиентов для расшифровки. Если кого-то вычеркнуть из этого списка, он не сможет расшифровать новый ключ к хранилищу. При ключи можно передавать по открытым каналам всем реципиентам, ведь воспользоваться им может только те реципиенты, которых админ хранилища ещё не вычеркнул)

Kopilov писал(а):
15.07.2013 12:27
Просто мне не приходило в голову, что в конфигах SSH предусмотрены псевдонимы.

просто перед тем, как делать велосипед, есть смысл почитать мануал :p
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Re: Mercurial, workflow и безопасность

Сообщение Kopilov »

drBatty писал(а):
15.07.2013 13:45
нет. К проекту и к костылю другой круг доступа. Проект например доступен всем участникам этого проекта.

Прошу прощения, но Вы, наверно, давно с VCS (например, Mercurial) не работали. Всем участникам проекта доступны файлы, находящиеся под контролем версий. При этом, каждое хранилище имеет собственные настройки, в том числе информацию о родителе (сервере). Когда я делаю клонов клона -- информации о сервере в нём уже нет. Каждый разработчик, приступая к проекту, получает в своё распоряжение сервер и данные о подключении, а отредактирует конфиг или напишет данные при выполнении команды hg clone -- решать ему.
(Возможно, такая политика является неправильной сама по себе, но в своё оправдвние могу сказать, что до моего прихода в компанию в ней не применяли VCS вообще, а коллектив разработчиков был и остаётся крайне небольшим.)

drBatty писал(а):
15.07.2013 13:45
вот. Потому задача админа обеспечить права доступа тем кому можно, и запретить тем, кому нельзя.

Согласен. Только я не админ, а разработчик, хотя два года был вынужден исполнять так же роль админа (и даже настроить ряд серверов), пока недавно не наняли настоящего).
Спасибо сказали:
Pchol
Сообщения: 88

Re: Mercurial, workflow и безопасность

Сообщение Pchol »

Поясните пожалуйста что значит "клона клонов" ?
Если вы делаете clone репозитория из источника то информация о сервере источнике все же сохраняется, потому что она необходима для обратного пуша. Или вы о чем то другом ?
"получает в свое распоряжение сервер итд"... Не понятно снова, вы что все конфиги сервера в hg храните ?
... Весь ужас заключается в том что предают только свои ...
Спасибо сказали:
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Re: Mercurial, workflow и безопасность

Сообщение Kopilov »

drBatty сказал, что
drBatty писал(а):
15.07.2013 13:45
К проекту и к костылю другой круг доступа. Проект например доступен всем участникам этого проекта.
Костыль оставим (он может быть защищён не хуже конфига, но это сделают с меньшей вероятностью), а про проект я ответил, что всем участникам доступны только хранящиеся в VCS файлы проекта, в то время как информация о сервере является служебной и, по крайней мере, не "осядет" в хранилище, в отличие от пароля к БД, если его держать в проекте и не исключить содержащий его файл из-под контроля.
Когда в проекте появляется новый разработчик, менеджер проекта говорит: "Мы используем VCS Mercurial, доступ на наш центральный сервер 8.x.x.8 осуществляется по порту 202. Тебе выдан логин vasya. Проект лежит в /var/hg/example." После этого кто-то склонирует проект командой hg clone ssh://vasya@8.x.x.8:202//var/hg/example ~/myclone, кто-то воспользуется конфигами SSH. Информация для обратного пуша, безусловно, сохранится, но она не будет частью проекта, "доступной всем участникам этого проекта". Она будет только у тех, кто изначально имел доступ к серверу и собственноручно склонировал проект. И если, например, сделать hg clone ~/myclone ~/myclone2 -- в ~/myclone2 данных о сервере уже не будет. В частности, стажёры могут использовать компьютер руководителя в качестве сервера, ничего не зная о центральном.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Kopilov
на самом деле, hg не может и не должна ника заботится о безопасности, это не её работа. Hg отдаёт ВСЁ, до чего может дотянуться этот юзер. В частности, файлы, для коротых вы пока не выполнили hg add. Это не баг, а фича.

И да, вы неправильно используете DVCS, hint: узнайте, что значит D, и чем лучше ртуть всяких маздайных звёздочек. Довольно странно использовать DVCS как древнюю VSS из M$VS начала века.

Hint2: никакого "центрального сервера" быть не должно, он не нужен, и только снижает надёжность и безопасность работы.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Pchol
Сообщения: 88

Re: Mercurial, workflow и безопасность

Сообщение Pchol »

Окей, Kopilov
То есть junior может взять в качестве источника репу senior'a наворотить там дел и заставить сеньора разгребать ? :) Крутой workflow. Если он не может запушить обратно тогда нахрена бы такой репо? Можно во время разворачивания виртуалки заливать ему код, да и все.
Еще не понял причем здесь пример "можно SCM, а можно по SSH". У вас что, кто то кроме администраторов этой самой SCM может зайти на сервер и забрать при помощи scp или еще чего то репо ? Как вы разруливаете доступ к определенным веткам разным группам пользователей ?
Это реальные примеры или вы это все из пальцев высасываете ?
На счет оседания пароля от БД в репо тоже долго можно спорить. Во время инсталяции кода на сервера этот пароль так или иначе попадет в конфиги, и если вас будут ломать "снаружи", с большой долей вероятности тот интерфейс через который поломают, будет иметь доступ на чтение к файлу конфигурации. Выходит что вы защищаете себя лишь от своих же сотрудников, которые для эксплуатации потенциальной уязвимости должны иметь доступ до продакшен среде, что само по себе не очень правильно.
... Весь ужас заключается в том что предают только свои ...
Спасибо сказали:
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Re: Mercurial, workflow и безопасность

Сообщение Kopilov »

Pchol писал(а):
16.07.2013 01:34
То есть junior может взять в качестве источника репу senior'a наворотить там дел и заставить сеньора разгребать ?
Ну, если он хам -- то сможет, да. Но, наверно, сениор предоставит доступ к промежуточному клону, а не к тому, в котором сам пишет. Я говорил о том, что junior не сможет пройти дальше машины senior'a.

Pchol писал(а):
16.07.2013 01:34
Если он не может запушить обратно тогда нахрена бы такой репо?
Кто сказал, что не сможет?

Pchol писал(а):
16.07.2013 01:34
У вас что, кто то кроме администраторов этой самой SCM может зайти на сервер и забрать при помощи scp или еще чего то репо ? Как вы разруливаете доступ к определенным веткам разным группам пользователей ?
Это реальные примеры или вы это все из пальцев высасываете ?


Реальный пример один: как я уже сказал, я не админ, а так же не менеджер проекта. Я лишь разработчик в маленькой компании, впервые предложивший использовать VCS и научивший нескольких человек ею пользоваться.
Если что, сейчас коллектив компании составляет 7 человек, из них 5 разработчиков (чисто или по совместительству), 3 из которых используют Mercurial (двое других -- дельфист и ораклист -- упрямо обходятся). И да, все они имеют прямой доступ к серверам (и SCM, и боевым web), но понимают, что надо пушить, а не редактировать на сервере без особой необходимости. Ну а трогать проекты друг друга -- просто свинство.
Доступ пока никак не разруливаем. Сервером SCM служит, фактически, мой десктоп. Двое товарищей подключаются по SSH, один из Linux, один из Windows.

Если интересует, как было до меня.
Разрабатывая апстрим все редактировали проект одновременно (по сетевой шаре), часто мешая друг другу. Благо, больше двоих за раз, как правило, не сидело. Я с трудом убедил директора, что удобнее будет работать независимо, проблем при слиянии будет меньше, чем при параллельной работе. А при поддержке (доработке или исправлении ошибки в действующем проекте) руководитель руками делал примерно то, что делает rsync (десктопов с линуксом тогда тоже не было).
Спасибо сказали:
Pchol
Сообщения: 88

Re: Mercurial, workflow и безопасность

Сообщение Pchol »

Ну, если он хам -- то сможет, да. Но, наверно, сениор предоставит доступ к промежуточному клону, а не к тому, в котором сам пишет. Я говорил о том, что junior не сможет пройти дальше машины senior'a.

junior он на то и junior что может ошибаться, и дело не в хамстве.
"Промеужточный клон", ну и смысл ? Проще просто положить ему код да и пусть он с ним играется. Перекладывать по десятку копий репозиториев код, довольно странное, на мой взгляд, решение.
К сожалению с hg не работал и не знаю какие существуют workflow при работе с ним, но мне кажеться там наверняка реализуем стандартный подход с несколькими ветками stable / beta / dev / feautureXXX, и когда правила мерджа между ветками, а также "бранчевание" новых веток для допиливания фич или для тестов также как то жестко регламентированны. Иначе, на мой взгляд, это не сильно отличается от вашего старого подхода. Ну равзе что вы можете посмотреть историю коммитов и ткнуть в кого то пальцем когда упадет production.
Но я наивано полагал что цель SCM и всех "обвязок" (code review, тесты и т д) как раз облегчить совместную разработку и помочь свести ошибки к минимуму.
Иными словами это средство помогающее обеспечить качество кода и продукта, а не кнут в руках начальства.
Вцелом, помоему это уже флейм.
... Весь ужас заключается в том что предают только свои ...
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Kopilov писал(а):
16.07.2013 10:27
просто свинство.

ну а при чём тут "безопасность" и "надёжность"? Они мимо вас проходили. Безопасность и надёжность -- это когда свиньи гадят в специально отведённых местах.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Pchol писал(а):
16.07.2013 11:35
К сожалению с hg не работал и не знаю какие существуют workflow при работе с ним, но мне кажеться там наверняка реализуем стандартный подход с несколькими ветками stable / beta / dev / feautureXXX, и когда правила мерджа между ветками, а также "бранчевание" новых веток для допиливания фич или для тестов также как то жестко регламентированны.

ИМХО проще всего сделать несколько репозиториев. Здесь у нас уже был спор на эту тему. ЕМНИП.

И да, юниор может у себя делать всё что угодно, а вот пушить имеет право только сеньор (в тривиальном случае). Возможно также создание юниорского репа. Вариантов много. И регулировать доступ к бранчам совсем НЕ обязательно.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Pchol
Сообщения: 88

Re: Mercurial, workflow и безопасность

Сообщение Pchol »

Есть bracnhing workflow практика которую применяют многие и нормально с ней живут.
Только "техническими" ограничениями построить нормальный процесс нельзя, всегда есть регламент который говорит: как делают, а как делать нельзя.
У кого то этот регламент существует только в устном общении у кого то формализован.
А что конкретно проще ? Пилить под кажду фичу свой репозиторий или под каждую ветку (dev/ stable / beta) свой репозиторий ? Помоему мердж из одной ветки в другую сделать куда проще чем перекладывать код в другой репозиторий, дублируя свою работу.
И зачем создавать отдельное репо для джуниоров ? Есть механизм с 2мя репозиториями, во второй данные попадают после ревью в первом, есть механизмы pre/post хуков, ими решается множество потенциальных косяков.
... Весь ужас заключается в том что предают только свои ...
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Pchol
та я в общем-то диванный теоретик. Просто я думаю, что защищать ветки одного репозитория сложнее, чем два репозитория.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Pchol
Сообщения: 88

Re: Mercurial, workflow и безопасность

Сообщение Pchol »

Согласен, вобще огранизация работы с SCM в компании это задача не на 3 часа работы (если конечно основная деятельность компании это разработка). Это целый новый процесс который придется вести долго.
Тема "богатая и интересная", жаль куда то пропал Kopilov
... Весь ужас заключается в том что предают только свои ...
Спасибо сказали:
Kopilov
Сообщения: 947
ОС: [K]Ubuntu, Debian

Re: Mercurial, workflow и безопасность

Сообщение Kopilov »

А что мне ещё добавить, если мои навыки администратора и менеджера (которыми я особо и не хвастался) разбиты в пух и прах. Могу, конечно, рассказать подробнее, как примерно оргинизована работа у нас.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current
Контактная информация:

Re: Mercurial, workflow и безопасность

Сообщение drBatty »

Kopilov писал(а):
17.07.2013 16:18
А что мне ещё добавить, если мои навыки администратора и менеджера (которыми я особо и не хвастался) разбиты в пух и прах.

ничего не разбито. Обычно ещё хуже. Просто выявлены некоторые недостатки. ИМХО, можно на любой машине делать любое количество пользователей, и у каждого пользователя сделать свой круг доступа. Тогда пользователь А в принципе не сможет полезть в проект Б, он его даже не увидит. А если надо, то можно сделать что-бы увидел, но только read-only, тогда он может сделать себе клон, что-то исправить в чужом проекте(локально), и отправить патч майнтейнеру этого проекта(ведь это не его проект, и он над ним не работает, потому это будет очень редко).
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Ответить