All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Joshua Brindle <method@gentoo.org>
Cc: Colin Walters <walters@verbum.org>,
	selinux@tycho.nsa.gov, Chris PeBenito <pebenito@gentoo.org>
Subject: Re: [RFC] Upstream policy handling
Date: Mon, 20 Sep 2004 13:22:21 +0100	[thread overview]
Message-ID: <20040920122221.GL23901@lkcl.net> (raw)
In-Reply-To: <414E153B.7070805@gentoo.org>

On Sun, Sep 19, 2004 at 07:24:43PM -0400, Joshua Brindle wrote:

> The divergence is not the problem, if divergence wasn't good then most 
> applications wouldn't exist today. There is no compelling need for every 
> vendor to shoehorn their policy into the sample, adding bloat and 
> causing it's analyzability to go down. 

... which is, in combination with the earlier responses about not
having divergent repositories, why i mentioned the thing about
multi-tagged CVS.

criteria to satisfy:

	1) the sample "strict" policy must be managed
	   exclusively by stephen et al.

	2) the sample "strict" policy should not include
	   absolutely everything [auditability and maintenance]

	3) ideally, REDHAT, Gentoo, Debian policies should be
	   based on the "strict" policy [too much work otherwise]

	4) ideally, all policies in 3) _should_ also be managed
	   through stephen et al {_someone's_ gotta be responsible]

	5) ideally, there should _be_ no number 3) above but
	   realistically this is in conflict with 2)

	6) there should be no distro "tunables" in the sample
	   "strict" policy.

therefore, a means to satisfy these criteria is to have a CVS repository
per distribution which contains only the files that are different from
the "strict" one.

the reasons for recommending this double-tagged approach over the
"put-the-entire-lot-of-the-nsa-strict-policy-files-into-another-cvs-tag"
approach are two-fold:

	1) maintaining totally separate cvs tags is a maintenance headache:
	   it's merge, merge, merge and it's boring.

	2) having separate tags FORCES maintainers of BOTH tags to be alert.

	   any commits in say the NSA tagged location will IMMEDIATELY be
	   pulled in by anyone doing a cvs update, NOT just when they next
	   do a merge-merge-merge.

	3) having a separate tag for REDHAT files that are additional or
	   different from the NSA tag minimises people's desire to _create_
	   such differences in the first place!


enough said: i won't mention this issue any more, it's up to you to
decide if a future maintenance headache warrants the above solution.

l.

p.s. if you like i can create a tiny test cvs repository plus example
cvs commands which demonstrates the principle of multi-tagging.


-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2004-09-20 13:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-19 15:07 [RFC] Upstream policy handling Joshua Brindle
2004-09-19 19:21 ` Luke Kenneth Casson Leighton
2004-09-19 21:10   ` Luke Kenneth Casson Leighton
2004-09-19 20:46 ` Russell Coker
2004-09-19 21:11   ` Joshua Brindle
2004-09-19 21:29     ` Russell Coker
2004-09-19 23:48       ` Joshua Brindle
2004-09-20  3:33         ` Colin Walters
2004-09-20 12:26           ` Daniel J Walsh
2004-09-20 12:56           ` Christopher J. PeBenito
2004-09-20 15:53             ` Colin Walters
2004-09-20 20:44               ` File types that are not sysadmfiles Daniel J Walsh
2004-09-21  5:08                 ` Russell Coker
2004-09-21 14:42                   ` Colin Walters
2004-09-21 15:25                     ` Russell Coker
2004-09-21 15:45                       ` Colin Walters
2004-09-21 14:42                   ` Colin Walters
2004-09-22 20:22                   ` James Carter
2004-09-23 16:43               ` [RFC] Upstream policy handling Daniel J Walsh
2004-09-23 19:10                 ` Russell Coker
2004-09-20 12:25       ` Luke Kenneth Casson Leighton
2004-09-20 14:54         ` Russell Coker
2004-09-19 22:08 ` Colin Walters
2004-09-19 23:24   ` Joshua Brindle
2004-09-20  0:07     ` Colin Walters
2004-09-20 12:22     ` Luke Kenneth Casson Leighton [this message]
2004-09-20 15:17   ` Thomas Bleher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040920122221.GL23901@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=method@gentoo.org \
    --cc=pebenito@gentoo.org \
    --cc=selinux@tycho.nsa.gov \
    --cc=walters@verbum.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.