[devel] I: git.alt package build acl: ideas

[devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Hi,

Интерфейс управления разграничением доступа к сборке пакетов из git.alt
будет отличаться от действующего интерфейса list.src.classic&notes для
управления разграничением доступа к сборке пакетов через incoming.

Цель изменения acl -- упростить совместную разработку.
Основная идея: наследование истории изменений сделать обязательным,
по умолчанию разрешить сборку всем.

Предполагается реализовать git.alt acl следующим образом.
+ acl по прежнему состоит из 2 частей: список пакетов (packages) и
  список групп мантейнеров (groups).
+ Первоначально оба списка пусты.
+ Пакет, не упомянутый в packages, считается новым.
+ Сборку нового пакета может предпринять любой потенциальный мантейнер.
+ Новый пакет, будучи успешно собранным, закрепляется за его мантейнером
  путём внесения соответствующей записи в packages (и, возможно, groups).
+ Новая сборка пакета, не являющегося новым, должна основываться на
  последней успешной сборке этого пакета.
+ Новую сборку пакета может предпринять любой, если только
  мантейнер этого пакета не установил ограничений.
+ Мантейнер при помощи своего etc/packages.git может:
  - ограничить список тех, кому можно отправлять на сборку
    закреплённые за ним пакеты;
  - передать закреплённый за ним пакет другому мантейнеру,
    тем самым закрепив этот пакет за новым мантейнером;
  - отказаться от закреплённого за ним пакета, тем самым давая
    возможность сборке этого пакета в качестве нового.
+ Актуальное состояние списков, образующих git.alt acl, будет доступно
  на http://git.altlinux.org/

Для особо недоверчивых мантейнеров можно реализовать закрепление
их пакетов до введения в строй сборки из git.alt.

Комментарии приветствуются.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]

On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> Интерфейс управления разграничением доступа к сборке пакетов из git.alt
> будет отличаться от действующего интерфейса list.src.classic&notes для
> управления разграничением доступа к сборке пакетов через incoming.
> 
> Цель изменения acl -- упростить совместную разработку.
> Основная идея: наследование истории изменений сделать обязательным,
> по умолчанию разрешить сборку всем.
> 
> Предполагается реализовать git.alt acl следующим образом.
> + acl по прежнему состоит из 2 частей: список пакетов (packages) и
>   список групп мантейнеров (groups).
> + Первоначально оба списка пусты.
> + Пакет, не упомянутый в packages, считается новым.
> + Сборку нового пакета может предпринять любой потенциальный мантейнер.
> + Новый пакет, будучи успешно собранным, закрепляется за его мантейнером
>   путём внесения соответствующей записи в packages (и, возможно, groups).
> + Новая сборка пакета, не являющегося новым, должна основываться на
>   последней успешной сборке этого пакета.
> + Новую сборку пакета может предпринять любой, если только
>   мантейнер этого пакета не установил ограничений.
> + Мантейнер при помощи своего etc/packages.git может:
>   - ограничить список тех, кому можно отправлять на сборку
>     закреплённые за ним пакеты;
>   - передать закреплённый за ним пакет другому мантейнеру,
>     тем самым закрепив этот пакет за новым мантейнером;
>   - отказаться от закреплённого за ним пакета, тем самым давая
>     возможность сборке этого пакета в качестве нового.
> + Актуальное состояние списков, образующих git.alt acl, будет доступно
>   на http://git.altlinux.org/

А как будут создаватся/удалятся/изменятся группы?

> 
> до введения в строй сборки из git.alt.

Когда?!

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

[..]
> Для особо недоверчивых мантейнеров можно реализовать закрепление
> их пакетов до введения в строй сборки из git.alt.

предлагаю начать с "особо недоверчивых"

>
> Комментарии приветствуются.



-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Fri, Jun 13, 2008 at 04:58:14PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
[...]
> А как будут создаватся/удалятся/изменятся группы?

Я предполагаю следующий вариант:
+ Новый успешно собранный пакет, %{packager}'ом которого указана
группа@packages.a.o, будет закрепляться за этой группой.
+ В случае, если этой группы ещё нет (в файле groups), то она будет
создана и закреплена за мантейнером, собравшим пакет.
+ Дальнейшее изменение состава группы будет осуществляться руководителем
этой группы при помощи своего etc/packages.git, по аналогии с packages.

> > до введения в строй сборки из git.alt.
> 
> Когда?!

Я только начал этим заниматься, посмотрим, насколько сильно будут
отвлекать на другие дела.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Fri, Jun 13, 2008 at 06:03:45PM +0400, Valery V. Inozemtsev wrote:
> [..]
> > Для особо недоверчивых мантейнеров можно реализовать закрепление
> > их пакетов до введения в строй сборки из git.alt.
> 
> предлагаю начать с "особо недоверчивых"

С ними просто -- они заполнят свои acl-packages обычным образом, после чего
эти acl-packages можно будет включить в общий list.packages вручную.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Fri, Jun 13, 2008 at 06:08:53PM +0400, Dmitry V. Levin wrote:
> On Fri, Jun 13, 2008 at 04:58:14PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> [...]
> > А как будут создаватся/удалятся/изменятся группы?
> 
> Я предполагаю следующий вариант:
> + Новый успешно собранный пакет, %{packager}'ом которого указана
> группа@packages.a.o, будет закрепляться за этой группой.
> + В случае, если этой группы ещё нет (в файле groups), то она будет
> создана и закреплена за мантейнером, собравшим пакет.

Лучше всё-же явное создание группы. Так можно простой опечаткой создать
лишнюю группу. 


-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Fri, Jun 13, 2008 at 05:14:01PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jun 13, 2008 at 06:08:53PM +0400, Dmitry V. Levin wrote:
> > On Fri, Jun 13, 2008 at 04:58:14PM +0300, Kirill A. Shutemov wrote:
> > > On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> > [...]
> > > А как будут создаватся/удалятся/изменятся группы?
> > 
> > Я предполагаю следующий вариант:
> > + Новый успешно собранный пакет, %{packager}'ом которого указана
> > группа@packages.a.o, будет закрепляться за этой группой.
> > + В случае, если этой группы ещё нет (в файле groups), то она будет
> > создана и закреплена за мантейнером, собравшим пакет.
> 
> Лучше всё-же явное создание группы. Так можно простой опечаткой создать
> лишнюю группу. 

А где проще сделать опечатку?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Fri, Jun 13, 2008 at 06:32:24PM +0400, Dmitry V. Levin wrote:
> On Fri, Jun 13, 2008 at 05:14:01PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jun 13, 2008 at 06:08:53PM +0400, Dmitry V. Levin wrote:
> > > On Fri, Jun 13, 2008 at 04:58:14PM +0300, Kirill A. Shutemov wrote:
> > > > On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> > > [...]
> > > > А как будут создаватся/удалятся/изменятся группы?
> > > 
> > > Я предполагаю следующий вариант:
> > > + Новый успешно собранный пакет, %{packager}'ом которого указана
> > > группа@packages.a.o, будет закрепляться за этой группой.
> > > + В случае, если этой группы ещё нет (в файле groups), то она будет
> > > создана и закреплена за мантейнером, собравшим пакет.
> > 
> > Лучше всё-же явное создание группы. Так можно простой опечаткой создать
> > лишнюю группу. 
> 
> А где проще сделать опечатку?

К одной группе может оносится много пакетов. В оном из этих пакетов можно
допустить опечатку. Группа создаётся один раз.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Fri, Jun 13, 2008 at 05:36:12PM +0300, Kirill A. Shutemov wrote:
[...]
> К одной группе может оносится много пакетов. В оном из этих пакетов можно
> допустить опечатку. Группа создаётся один раз.

Т.е. предлагается создавать группу посредством etc/packages.git, и не
допускать пакетов с незарегистрированными группами?

Пожалуй, это не сильно усложнит жизнь мантейнерам, поскольку
групп существенно меньше чем пакетов.

Было ещё одно предложение: тэг %{packager} пакета должен совпадать с
именем того мантейнера/группы, за которым закреплён этот пакет.

Это ограничение исключит опечатки в %{packager} и сделает значение этого
тэга более актуальным.  Что скажете?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

* Dmitry V. Levin <ldv@> [080613 17:54]:
> Для особо недоверчивых мантейнеров можно реализовать закрепление
> их пакетов до введения в строй сборки из git.alt.
Либо я не до конца это понял, либо оно ещё не работает.  Как
можно мне "реализовать закрепление", пожалуйста?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Sat, Jun 14, 2008 at 02:32:25PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [080613 17:54]:
> > Для особо недоверчивых мантейнеров можно реализовать закрепление
> > их пакетов до введения в строй сборки из git.alt.
> Либо я не до конца это понял, либо оно ещё не работает.

Идеи не могут не работать. :)
Прежде чем ОНО заработает, оно должно быть написано.
Формат acl-файлов уже существует, но не является окончательным,
и по мере реализации может быть изменён.

> Как можно мне "реализовать закрепление", пожалуйста?

Зачем это тебе сейчас?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> Интерфейс управления разграничением доступа к сборке пакетов из git.alt
> будет отличаться от действующего интерфейса list.src.classic&notes для
> управления разграничением доступа к сборке пакетов через incoming.
> 
> Цель изменения acl -- упростить совместную разработку.
> Основная идея: наследование истории изменений сделать обязательным,
> по умолчанию разрешить сборку всем.
> 
> Предполагается реализовать git.alt acl следующим образом.
> + acl по прежнему состоит из 2 частей: список пакетов (packages) и
>   список групп мантейнеров (groups).
> + Первоначально оба списка пусты.
> + Пакет, не упомянутый в packages, считается новым.
> + Сборку нового пакета может предпринять любой потенциальный мантейнер.
> + Новый пакет, будучи успешно собранным, закрепляется за его мантейнером
>   путём внесения соответствующей записи в packages (и, возможно, groups).
> + Новая сборка пакета, не являющегося новым, должна основываться на
>   последней успешной сборке этого пакета.
> + Новую сборку пакета может предпринять любой, если только
>   мантейнер этого пакета не установил ограничений.
> + Мантейнер при помощи своего etc/packages.git может:
>   - ограничить список тех, кому можно отправлять на сборку
>     закреплённые за ним пакеты;
>   - передать закреплённый за ним пакет другому мантейнеру,
>     тем самым закрепив этот пакет за новым мантейнером;
>   - отказаться от закреплённого за ним пакета, тем самым давая
>     возможность сборке этого пакета в качестве нового.
> + Актуальное состояние списков, образующих git.alt acl, будет доступно
>   на http://git.altlinux.org/

Мне кажется это недостаточно гибким.  На все важные пакеты всё равно
будет установлен жесткий ACL (чтобы кто-нибудь не залил openssl 0.9.8g).
Останутся "второсортные" пакеты, которые компрометируют институт
мейнетнерства (более или менее персональной ответственности за
работоспособность пакета).

Вообще идея раннего ACL в связи с предложенным означает слишком
диаметральное рсслоение -- либо априорное доверие, либо априорное
недоверие.  На практике же доверие -- штука тонкая, "доверяй но
проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
"неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
неавторизированную сборку можно было "быстро подтвердить" или же,
наоборот, "быстро отшить".  Mainatiner не всегда может быстро
среагировать, поэтому нужен арбитр.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Mon, Jun 16, 2008 at 01:09:57AM +0400, Alexey Tourbin wrote:
> On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> > Цель изменения acl -- упростить совместную разработку.
> > Основная идея: наследование истории изменений сделать обязательным,
> > по умолчанию разрешить сборку всем.
[...]
> Мне кажется это недостаточно гибким.  На все важные пакеты всё равно
> будет установлен жесткий ACL (чтобы кто-нибудь не залил openssl 0.9.8g).

Я не против, чтобы кто-нибудь со знанием дела залил openssl 0.9.8g
На практике это означает, что этому "кто-нибудь" нужно подготовить
несколько сборок openssl такого качества, чтобы у меня не возникало
необходимости вносить в них изменения.

> Останутся "второсортные" пакеты, которые компрометируют институт
> мейнетнерства (более или менее персональной ответственности за
> работоспособность пакета).

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

> Вообще идея раннего ACL в связи с предложенным означает слишком
> диаметральное рсслоение -- либо априорное доверие, либо априорное
> недоверие.  На практике же доверие -- штука тонкая, "доверяй но
> проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
> "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
> неавторизированную сборку можно было "быстро подтвердить" или же,
> наоборот, "быстро отшить".

Насколько быстрым?  Как ты это видишь?

> Mainatiner не всегда может быстро среагировать, поэтому нужен арбитр.

Кто же за мантейнера сможет определить, пропускать сборку или нет?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Mon, Jun 16, 2008 at 02:03:40AM +0400, Dmitry V. Levin wrote:
> > Вообще идея раннего ACL в связи с предложенным означает слишком
> > диаметральное рсслоение -- либо априорное доверие, либо априорное
> > недоверие.  На практике же доверие -- штука тонкая, "доверяй но
> > проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
> > "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
> > неавторизированную сборку можно было "быстро подтвердить" или же,
> > наоборот, "быстро отшить".
> 
> Насколько быстрым?  Как ты это видишь?

Я это вижу так: ACL должен проверяться не на входе, а на выходе.
Если пакет собрался, тогда есть о чём говорить.  Формируется список
"нарушений" пакета.  Одно из нарушений -- не проходит проверка по ACL;
другое нарушение -- появление новых анметов.

Нарушение ACL соответствует ситуации NMU.  Мы можем дать разовое NMU
без изменения ACL, но для этого нужно точно знать изменения в пакете
(то есть пакет должен собраться).  Тогда либо maintainer пакета,
либо арбитр (если maintainer недоступен) может сказать "SKIP ACL OK".

> > Mainatiner не всегда может быстро среагировать, поэтому нужен арбитр.
> Кто же за мантейнера сможет определить, пропускать сборку или нет?

Необходимость в NMU может быть неизбежной, и во многих случаях NMU
легко проверить, если там небольшие изменения.  Например, при пересборке
пакетов с новым soname'ом.  Кто собрал новый soname, тот может
попытаться делать NMU на зависящие пакеты.  Сейчас так и происходит
(напр. libdb4.7), просто арбитр действует закулисно и в обход системы.
А можно сделать саму систему достаточно гибкой и прозрачной.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Mon, Jun 16, 2008 at 10:49:54AM +0400, Alexey Tourbin wrote:
> On Mon, Jun 16, 2008 at 02:03:40AM +0400, Dmitry V. Levin wrote:
> > > Вообще идея раннего ACL в связи с предложенным означает слишком
> > > диаметральное рсслоение -- либо априорное доверие, либо априорное
> > > недоверие.  На практике же доверие -- штука тонкая, "доверяй но
> > > проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
> > > "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
> > > неавторизированную сборку можно было "быстро подтвердить" или же,
> > > наоборот, "быстро отшить".
> > 
> > Насколько быстрым?  Как ты это видишь?
> 
> Я это вижу так: ACL должен проверяться не на входе, а на выходе.
> Если пакет собрался, тогда есть о чём говорить.  Формируется список
> "нарушений" пакета.  Одно из нарушений -- не проходит проверка по ACL;
> другое нарушение -- появление новых анметов.
> 
> Нарушение ACL соответствует ситуации NMU.  Мы можем дать разовое NMU
> без изменения ACL, но для этого нужно точно знать изменения в пакете
> (то есть пакет должен собраться).  Тогда либо maintainer пакета,
> либо арбитр (если maintainer недоступен) может сказать "SKIP ACL OK".

Мне нравится эта идея.  Каким должен быть механизм подтверждений, чтобы
быть удобным и мантейнеру, и арбитру?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Мне нравится эта идея.  Каким должен быть механизм подтверждений, чтобы
> быть удобным и мантейнеру, и арбитру?

Я за почтовый.

-- 
Rgrds, legion

Re: [devel] I: git.alt package build acl: ideas

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Tue, Jun 17, 2008 at 02:01:52AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> >Мне нравится эта идея.  Каким должен быть механизм подтверждений, чтобы
> >быть удобным и мантейнеру, и арбитру?
> 
> Я за почтовый.

Можешь рассказать немного подробнее, как ты это видишь?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On Tue, Jun 17, 2008 at 01:53:10AM +0400, Dmitry V. Levin wrote:
> > Нарушение ACL соответствует ситуации NMU.  Мы можем дать разовое NMU
> > без изменения ACL, но для этого нужно точно знать изменения в пакете
> > (то есть пакет должен собраться).  Тогда либо maintainer пакета,
> > либо арбитр (если maintainer недоступен) может сказать "SKIP ACL OK".
> 
> Мне нравится эта идея.  Каким должен быть механизм подтверждений, чтобы
> быть удобным и мантейнеру, и арбитру?

Это зависит от модели данных в сборочнице.  Она может быть такой:

struct task {
	int id; // ever-increasing номера заданий
	struct packages[]; // пакеты, собираемые в задании
}

struct package {
	struct task *task; // имеется в виду, что пакеты привязаны к
			   // заданиями и рассматриваются в пределах
			   // задания
	char *name;	// имя пакета, на которое можно ссылаться в
			// пределах задания
	
	char *git_repo; // информация про gear-репозитарий
	char *tag;
	sha1 *comitish;

	enum {
		V_UNMETS;
		V_ACL;
	} violations[];	// нарушения пакета
}

Когда мы делаем 'push-build', мы отправляем один или несколько пакетов
на сборку, и создаётся task.  Если все пакеты собрались, и в каждом
пакете пустой список violations, то пакеты автоматически проходят в
Сизиф.  Если хотя бы один пакет не собрался (по грубой причине), то
task автоматически отменяется.  В противном случае пакеты собрались,
но в некоторых из них имеются violations.  Тогда об этом отправляется
письмо по почте (тем, кто может воздействовать на violations).

Механизм подтверждения или отвержения нарушений можно сделать через
git.alt.

ssh git.alt violation <task-id> <package-name> <violation> "permit"|"deny"

Если все нарушения удалось снять, то пакеты из task проходят в сизиф.
В противном случае через некоторое время task автоматически отменятся.

В task надо уметь добавлять новые пакеты (если он не проходит
автоматически).  Это соответствует ситуации, когда пакет что-то ломает
(напр. V_UNMETS).  Тогда в этот task добавляются исправленные пакеты,
и часть violations автоматически снимается (но могут также добавляться
новые violations, напр. V_ACL).

Такая модель позволят наладить транзакционную смену soname'ов (а также
частично её нарушать).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Anton Farygin]

Dmitry V. Levin пишет:
> On Mon, Jun 16, 2008 at 10:49:54AM +0400, Alexey Tourbin wrote:
>> On Mon, Jun 16, 2008 at 02:03:40AM +0400, Dmitry V. Levin wrote:
>>>> Вообще идея раннего ACL в связи с предложенным означает слишком
>>>> диаметральное рсслоение -- либо априорное доверие, либо априорное
>>>> недоверие.  На практике же доверие -- штука тонкая, "доверяй но
>>>> проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
>>>> "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
>>>> неавторизированную сборку можно было "быстро подтвердить" или же,
>>>> наоборот, "быстро отшить".
>>> Насколько быстрым?  Как ты это видишь?
>> Я это вижу так: ACL должен проверяться не на входе, а на выходе

Re: [devel] I: git.alt package build acl: ideas

[Anton Farygin]

И всё-таки, это глючит gmane.


На мой взгляд - почтовый интерфейс в этом случае будет самым удобным.

Т.е. - в случае нарушения ACL по почте приходит письмо, в котором 
указывается git changelog, URL на gitweb, может быть - diff (если он 
маленький), rpmdiff.

После этого достаточно ответить на это письмо, написав в теле ACL OK или 
ACL REJECT для выполнения той или иной процедуры прохождения пакета.

Письмо должно уйти по reply all роботу и мантейнеру-инициатору сборки 
пакета.


Anton Farygin пишет:
> 
> 
> Dmitry V. Levin пишет:
>> On Mon, Jun 16, 2008 at 10:49:54AM +0400, Alexey Tourbin wrote:
>>> On Mon, Jun 16, 2008 at 02:03:40AM +0400, Dmitry V. Levin wrote:
>>>>> Вообще идея раннего ACL в связи с предложенным означает слишком
>>>>> диаметральное рсслоение -- либо априорное доверие, либо априорное
>>>>> недоверие.  На практике же доверие -- штука тонкая, "доверяй но
>>>>> проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
>>>>> "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
>>>>> неавторизированную сборку можно было "быстро подтвердить" или же,
>>>>> наоборот, "быстро отшить".
>>>> Насколько быстрым?  Как ты это видишь?
>>> Я это вижу так: ACL должен проверяться не на входе, а на выходе
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: git.alt package build acl: ideas

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

Здравствуйте Anton Farygin
  В сообщении от 17 июня 2008 Anton Farygin написал(a):
> Т.е. - в случае нарушения ACL по почте приходит письмо, в
> котором указывается git changelog, URL на gitweb, может быть -
> diff (если он маленький), rpmdiff.
>
> После этого достаточно ответить на это письмо, написав в теле
> ACL OK или ACL REJECT для выполнения той или иной процедуры
> прохождения пакета.
>
> Письмо должно уйти по reply all роботу и мантейнеру-инициатору
> сборки пакета.
+1 
Мне очень понравилось, ну ещё письмо должно быть подписано 
доверенной подписью ?

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Anton Farygin]

Хихин Руслан пишет:
> Здравствуйте Anton Farygin
>   В сообщении от 17 июня 2008 Anton Farygin написал(a):
>> Т.е. - в случае нарушения ACL по почте приходит письмо, в
>> котором указывается git changelog, URL на gitweb, может быть -
>> diff (если он маленький), rpmdiff.
>>
>> После этого достаточно ответить на это письмо, написав в теле
>> ACL OK или ACL REJECT для выполнения той или иной процедуры
>> прохождения пакета.
>>
>> Письмо должно уйти по reply all роботу и мантейнеру-инициатору
>> сборки пакета.
> +1 
> Мне очень понравилось, ну ещё письмо должно быть подписано 
> доверенной подписью ?

С подписью я бы не настаивал. Если можно сделать отключабельным 
необходимость подписывать эти письма - было бы здорово.

Re: [devel] I: git.alt package build acl: ideas

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

* Anton Farygin <rider@> [080617 10:55]:
> > Мне очень понравилось, ну ещё письмо должно быть подписано 
> > доверенной подписью ?
> С подписью я бы не настаивал. Если можно сделать отключабельным 
> необходимость подписывать эти письма - было бы здорово.
При помощи письма специального вида злоумышленник может
подтвердить чужой пакет.  ssh git.alt надёжнее и не требует
широкого канала.

А в отпуске надо отдыхать ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Anton Farygin]

Alexey I. Froloff пишет:
> * Anton Farygin <rider@> [080617 10:55]:
>>> Мне очень понравилось, ну ещё письмо должно быть подписано 
>>> доверенной подписью ?
>> С подписью я бы не настаивал. Если можно сделать отключабельным 
>> необходимость подписывать эти письма - было бы здорово.
> При помощи письма специального вида злоумышленник может
> подтвердить чужой пакет.  ssh git.alt надёжнее и не требует
> широкого канала.
> 
> А в отпуске надо отдыхать ;-)

Злоумышленник из числа Team ?

Не думаю, что кто-то из Team этим будет заниматься. Но я вообще хорошо 
думаю о людях.

Re: [devel] I: git.alt package build acl: ideas

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Tue, Jun 17, 2008 at 11:21:23AM +0400, Alexey I. Froloff wrote:
> * Anton Farygin <rider@> [080617 10:55]:
> > > Мне очень понравилось, ну ещё письмо должно быть подписано 
> > > доверенной подписью ?
> > С подписью я бы не настаивал. Если можно сделать отключабельным 
> > необходимость подписывать эти письма - было бы здорово.
> При помощи письма специального вида злоумышленник может
> подтвердить чужой пакет.  ssh git.alt надёжнее и не требует
> широкого канала.

+1

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

* Anton Farygin <rider@> [080617 11:46]:
> >> С подписью я бы не настаивал. Если можно сделать отключабельным 
> >> необходимость подписывать эти письма - было бы здорово.
> > При помощи письма специального вида злоумышленник может
> > подтвердить чужой пакет.  ssh git.alt надёжнее и не требует
> > широкого канала.
> Злоумышленник из числа Team ?
> Не думаю, что кто-то из Team этим будет заниматься. Но я вообще хорошо 
> думаю о людях.
В таком случае акли и подтверждения просто не нужны ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

Twas brillig at 12:06:46 17.06.2008 UTC+04 when Alexey I. Froloff did gyre and gimble:

 AIF> В таком случае акли и подтверждения просто не нужны ;-)

Нужны - для предотвращения непреднамеренной ошибки.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] I: git.alt package build acl: ideas

[Anton Farygin]

Alexey I. Froloff пишет:
> * Anton Farygin <rider@> [080617 11:46]:
>>>> С подписью я бы не настаивал. Если можно сделать отключабельным 
>>>> необходимость подписывать эти письма - было бы здорово.
>>> При помощи письма специального вида злоумышленник может
>>> подтвердить чужой пакет.  ssh git.alt надёжнее и не требует
>>> широкого канала.
>> Злоумышленник из числа Team ?
>> Не думаю, что кто-то из Team этим будет заниматься. Но я вообще хорошо 
>> думаю о людях.
> В таком случае акли и подтверждения просто не нужны ;-)

Нужно - для получения согласия мантейнера на внесение изменений.