Здравствуйте, itslave, Вы писали:
I>Здравствуйте, A13x, Вы писали:
A>>Здравствуйте, itslave, Вы писали:
I>>>...
A>>На работе в свое время перешли на git и еще ни разу не пожалели. Правда часть сидит на linux, часть на mac. A>>Интеграция с JIRA отличная, все работает на ура, с бинариками вроде проблем не было особых.
A>>Что там не так с гитом? I>Если пользователь делает push в репозитарий, который требует аутентификации, можно ли быть уверенным что в качестве автора изменений будет логин, под которым пользователь аутентифицировался?
Да, можно. push сводится к набору операций осуществляемых через ssh. Если вы не знаете логина и пароля / ключа (в зависимости от способа аутентификации), то не сможете закоммитить изменения якобы из под другого пользователя.
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, itslave, Вы писали:
I>>Здравствуйте, rm822, Вы писали:
I>>(поскипано) I>>Я рад что в перфорсе все хорошо SD>в перфорсе все так хорошо что будете по свну рыдать кровавыми слезами. Я вот 4 месяца уже так.
Ну я просто за человека порадовался, нельзя чтоли?
SD>а насчет авторства чейнджей там проблему вы не поняли. Речь идет о том что у разработчика есть локальный репо в нем он сам себе царь и может править историю как хочет. И то что он заливает на сервер как правило содержит кучу чужих чейнджсетов полученных от других разработчиков мимо кассы. Иначе вам нет смысла держать офис так как каждый может сидеть дома и не общаясь ни с кем делать свои таски. И соответственно ставить авторство на чужие чейнджи есть дикость и никто в опенсорсе так делать не будет. Если вы осуществите свою мечту то у вас в центральном репо будет один автор — тот кто мержил весь этот бардак. Я регулярно был таким "мержером по вызову" так что знаю что большинство разработчиков пасуют при виде многопутевых мержей с попутанной историей и 2-3 раза наложенными чужими патчами так как они пришли разными путями.
Тут уже обсудили и пришли к выводу(по крайней мере я) что в чейнджсете необходимо еще одно поле, что-то типа "commiter" в которое пишется аутентификационная инфа того человека, который залил данный чейнджсет в данный репозитарий. Ессна в разных репозитариях эта инфа должна меняться.
А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>Стандартный увы то что надо не делает. Похожих примеров(конкретно вытаскивание аутентификационной инфы) я не нашел, может плохо искал.
A>Я ошибся, хук нужен не incoming, а pretxnchangegroup
A>[hooks] A>pretxnchangegroup = /path/to/script
A>вот такой вот баш скрипт хука A>
A>echo ${HG_URL:14} #отрезал первые 14 символов
A>hg log -r $HG_NODE --template "{author}" $PWD
A>
A>выдаёт мне имя аутентифицированного пользователя и имя из лога. Дальше их надо сравнить и вернуть не 0 если надо прервать операцию. пример развивать не стал, так как вы CMD или Powershell будете использовать.
Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
Здравствуйте, itslave, Вы писали:
I>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили.
Здравствуйте, A13x, Вы писали:
A>>>Что там не так с гитом? I>>Если пользователь делает push в репозитарий, который требует аутентификации, можно ли быть уверенным что в качестве автора изменений будет логин, под которым пользователь аутентифицировался? A>Да, можно. push сводится к набору операций осуществляемых через ssh. Если вы не знаете логина и пароля / ключа (в зависимости от способа аутентификации), то не сможете закоммитить изменения якобы из под другого пользователя.
А это где нить запоминается и можно легко и непринужденно увидеть, кто же запушил в репозиторий конкретно взятый ченджсет?
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, SleepyDrago, Вы писали:
SD>>Здравствуйте, itslave, Вы писали:
I>>>(поскипано)
SD>>а насчет авторства чейнджей там проблему вы не поняли. Речь идет о том что у разработчика есть локальный репо в нем он сам себе царь и может править историю как хочет. И то что он заливает на сервер как правило содержит кучу чужих чейнджсетов полученных от других разработчиков мимо кассы. Иначе вам нет смысла держать офис так как каждый может сидеть дома и не общаясь ни с кем делать свои таски. И соответственно ставить авторство на чужие чейнджи есть дикость и никто в опенсорсе так делать не будет. Если вы осуществите свою мечту то у вас в центральном репо будет один автор — тот кто мержил весь этот бардак. Я регулярно был таким "мержером по вызову" так что знаю что большинство разработчиков пасуют при виде многопутевых мержей с попутанной историей и 2-3 раза наложенными чужими патчами так как они пришли разными путями. I>Тут уже обсудили и пришли к выводу(по крайней мере я) что в чейнджсете необходимо еще одно поле, что-то типа "commiter" в которое пишется аутентификационная инфа того человека, который залил данный чейнджсет в данный репозитарий. Ессна в разных репозитариях эта инфа должна меняться. I>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
я ненавязчиво намекаю что в этом поле продакшна как правило будет одно и то же имя (ну или 2-3 в зависимости от отпусков и личного состава). Те кто проводил интеграцию. У нас сейчас в перфорсе нет никакой аутентификации — имя человека пишется исключительно для display и никак не проверяется. Если вы не готовы доверять тому что коллектив мотивирован в успехе проекта у вас нет ни одного шанса быть более умным чем коллектив разработчиков. Это справедливо для любой штучной разработки /имхо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, itslave, Вы писали:
I>>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю. C>Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили.
А можно поподробней(или линку на годную статтю), интересно стало.
В первую очередь интересует в контексте как это поможет узнать кого раком ставить.
Здравствуйте, SleepyDrago, Вы писали:
SD>я ненавязчиво намекаю что в этом поле продакшна как правило будет одно и то же имя (ну или 2-3 в зависимости от отпусков и личного состава). Те кто проводил интеграцию.
А интегрировать они будут из воздуха, или же у них каким то образом появятся чейнджсеты, которые собственно говоря и надо синтегрировать в релизную ветку? Следующий шаг — формализовать обмен чейнджсетов между девами и интеграторами. А ет либо какой нить промежуточный репозитарий либо емейл — все решается
SD>У нас сейчас в перфорсе нет никакой аутентификации — имя человека пишется исключительно для display и никак не проверяется. Если вы не готовы доверять тому что коллектив мотивирован в успехе проекта у вас нет ни одного шанса быть более умным чем коллектив разработчиков. Это справедливо для любой штучной разработки /имхо.
На одном прянике далеко не уедешь.
Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты.
Проблема решается цифровыми подписями, причем тегов, а не коммитов. Подпись, удостоверяющая, что этот коммит внесен таким-то пользователем, ничего не значит. Может, это эксперимент, который не должен был попадать в общий репозиторий, а недоброжелатель его всё равно туда запустил. Подписанная метка, обещающая, что коммит достигает какой-то цели, — совсем другое дело.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты.
Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
RO>Проблема решается цифровыми подписями, причем тегов, а не коммитов. Подпись, удостоверяющая, что этот коммит внесен таким-то пользователем, ничего не значит. Может, это эксперимент, который не должен был попадать в общий репозиторий, а недоброжелатель его всё равно туда запустил. Подписанная метка, обещающая, что коммит достигает какой-то цели, — совсем другое дело.
Здравствуйте, itslave, Вы писали:
I>Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
Понятно. Вот для этого в git есть committer и author.
I>И ето есть в меркурале? Или просто мечты в слух? http://mercurial.selenic.com/wiki/CommitsigsExtension
А в git искаропки. hg — must die.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, itslave, Вы писали:
I>>>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю. C>>Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили. I>А можно поподробней(или линку на годную статтю), интересно стало. I>В первую очередь интересует в контексте как это поможет узнать кого раком ставить.
Стоит понимать, что в git/hg вполне допустима ситуация, когда я возьму коммиты Пети и закоммичу их от своего имени. При это в логе будет так и записано "автор — Петя, закоммичено Васей". Это абсолютно штатная ситуация, хотя её можно запретить административно, повесив хуки на центральный репозиторий, которые проверяют авторство.
Но гораздо лучше эту ситуацию обратить в свою пользу. Для этого вводится криптографическое подписывание коммитов, и в логе будет записано нечто типа "автор — Петя <цифровая подпись коммита>, закоммичено Васей <цифровая подпись merge-коммита>". Так что по подписям можно всегда восстановить историю, даже если merge осуществлялся через несколько посредников.
Это гораздо более сильная гарантия, так как подпись без получения доступа к приватным ключам всех в цепочке подделать невозможно. Тогда как зловредный администратор может зайти на центральный хостинг и туда чего-нибудь левое добавить.
В git озаботились подписыванием после недавней компрометации сайта kernel.org.
Здравствуйте, itslave, Вы писали:
I>Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
A>Выложи скрипт на публику, не жмоться
Та там того скрипта 5 строк, большы времени заняли эксперименты и раздумываняи как луччи связать ченджсет с инфой об аутентификации(и соотвественно чтение доки, размышлизмы).
Решил именна тагом потому как их видно прям в вебморде и ничего дописывать не надо(в принципе мона просто в логи(БД) фигачить и прикрутить веб страничку для поиска по этим логам).
В hgrc репозитария пишем
С какого то перепугу Powershell запускаться не захотел(можы прав системному иис-овскому аккаунту не хватает можы еще чего), а я уже замахалси и забил. Поентому ограничилси бат-скриптом(и опять жы время на чтение доки, 100 лет уже бат скриптов не писал и эксперименты)
set str=%HG_URL%
set str=%str%_%date%
set str=%str%_%time%
set str=%str::=_%
set str=%str:5C=_%
set str=%str:/=_%
set str=%str:.=_%
set str=%str: =_%
cd c:\Repositories\%1
call "c:\Program Files\Mercurial\hg.exe" tag -l -r %HG_NODE% %str%
(дата-время необходима для уникальности тагов, т.е. чтобы они не "перескакивали" на свежий чейнджсет того же пользователя).
Оно конечно кривенько но вся необходимая инфа есть и работает. Будет настроение — причешу.
Ышо таг делаем с ключем -l чтобы эти таги не расползались по "локальным" репозиториям, они там ни к чему имха.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
A>У меня вашей оранизационной проблемы нет, но я постараюсь в ближайшем будущем написать аналогичный bash скрипт и выложить здесь (ну и у себя внедрю)
Рассказали мне в этой теме про подписи чейнджсетов. Таки действительно, сила. Но, опять жы, хочется интеграцию в АД, централизированный менеджмент юзеров — ет реально очень удобно.
Вот я прям щас думаю, что идеально было бы:
1. При создании АД-пользователя автоматически создается сертификат, который прикрепляется к свойствам этого пользователя.
2. При коммите специальный хук определяет что за пользователь залогинен и подписывает чейнджсет его сертификатом, автоматически и прозрачно.
3. В настройках "центрального" репозитория прописывается чейнджсеты какой группы пользователей етот самый репозиторий может принимать
4. При пуше в "центральный" репозиторий проверяются цифровые подписи каждого чейнджсета
4.1 если ее нету — в сад
4.2 если сертификат, которым подписывали, не принадлежит ни одному пользователю из указанной в п.3 группы — тожы в сад.
Но я фактически уверен, что ничего подобного под hg не написано и не планируется в ближайшем будущем, поентому думаю ограничиться ручной генерацией ключей и выдачей их сотрудникам(хотя опять жы, неизвестно, можно ли аннулировать ключ если сотрудник увольняется).
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
A>Это вам свой CA по идее нужен, иначе сертификаты отзывать не получится.
Т.е. решение, основанное исключительно на сертификатах мягко говоря не канает. Нужно сертификаты ассоциировать с локальными ресурсами, которыми можно управлять.
I>поставить-настроить под винду I>желательно IIS в качестве веб сервиса I>аутентификация-авторизация через Active Directory(изначально я вычитал что авторизация с расстановкой прав доступа — не получится) I> http://hglabhq.com/
HgLab: Mercurial Server and Repository Management for Windows
hg — must die.
