public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kristian Fiskerstrand <k_f@gentoo.org>
To: gentoo-project@lists.gentoo.org, "Michał Górny" <mgorny@gentoo.org>
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - Council meeting 2018-12-09
Date: Tue, 4 Dec 2018 10:54:58 +0100	[thread overview]
Message-ID: <1c00c4da-8369-6539-2156-cf5b4375976e@gentoo.org> (raw)
In-Reply-To: <1543894892.810.5.camel@gentoo.org>

On 12/4/18 4:41 AM, Michał Górny wrote:
> Are you asking the Council to make a policy for security team,
> or to override the existing policy of security team?  Because this
> sounds like you're implying that security team can't make up their mind.

This is indeed part of the ongoing discussion surrounding the GLEP for
the security team; Before anything should go to council on this we need
to put the the current draft up for a public discussion on the -project
mailing list.

> 
> Also, if the Council votes 'yes', what happens next?  Does security
> accept all stable arches?  Do stable arches get demoted implicitly based
> on security project considerations?

The assumption would be that security needs to have a say for whenever
an arch is added or if requesting to remove an arch. To balance this a a
GLEP48-style/QA-style lead approval process is added and criteria to be
used for such determination is included.

Personally I don't see a problem with the status quo where security
supported arches is listed as part of security project's documentation,
and removals announced etc. The actual security implication for a lot of
these arches will anyways be impacted by members of the team having
limited knowledge of particulars, in particular when it come to auditing
due to difference in assembly etc, so the major arches will anyways have
a better foundation for being handled by the team, so security is
relative to what we claim to know and do.

In any case, too early for the council to do anything here.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


  reply	other threads:[~2018-12-04  9:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 12:31 [gentoo-project] Call for agenda items - Council meeting 2018-12-09 Mart Raudsepp
2018-11-30 16:17 ` William Hubbs
2018-11-30 16:24   ` Alec Warner
2018-12-06 17:32     ` William Hubbs
2018-12-01  7:47 ` [gentoo-project] Re: [gentoo-dev-announce] " Mikle Kolyada
2018-12-02  9:30   ` grozin
2018-12-02 15:55     ` Michał Górny
2018-12-02 16:06     ` Michał Górny
2018-12-04  0:16   ` Aaron Bauman
2018-12-04  0:39     ` M. J. Everitt
2018-12-04  1:29       ` Aaron Bauman
2018-12-04  3:41     ` Michał Górny
2018-12-04  9:54       ` Kristian Fiskerstrand [this message]
2018-12-04 10:06         ` Mart Raudsepp
2018-12-04 21:18       ` Aaron Bauman
2018-12-04 22:51     ` Sergei Trofimovich

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=1c00c4da-8369-6539-2156-cf5b4375976e@gentoo.org \
    --to=k_f@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    --cc=mgorny@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox