Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

Rick a very good message (and well thought out).

On 3/13/17 4:33 PM, Rich Freeman wrote:
> On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann  wrote:
> 
> The two areas that I see as possibly pushing security towards being a
> special project are:
> 1.  Masking or otherwise directly touching packages without waiting
> for the maintainer if the timeline passes.

Security team does not like doing this since we do not know the internal
workings of packages. But sometimes it is very much needed, remember
"heartblead?". The notification came to our points of contact (Alex
(a3li) and Tobias (keytoaster)), a private security bug was filed with
normal rating since the release was within our time-lines. Then in a few
hours the security team decided to release it. Well I remember all hell
breaking loose, and at that point direct involvement was involved.

For that reason for something like this I think we need a GLEP for. Not
to use every day, but lets call it "Emergency Power" that shall NOT be
abused.

> 2.  Being able to represent Gentoo on special security mailing lists
> that have tight distribution.  (If somebody betrays this trust Gentoo
> could find itself cut off from all such lists, so Gentoo should use
> care here.)

This is very important. Pre-Notification is on a case by case basis.
While we can define point of contacts, it is also important as a
reputation for Gentoo.

Lets say we want to become a CNA, just like  other distributions
(Debian, Red Hat, SUSE, Ubuntu) we need a person that would be
responsible for coordinating the information and the appropriate
paperwork and coordinate with Council or Foundation as needed. This can
not be a free for all.


> I'll finally note that there is also a possible compromise.  We might
> make security somewhat special, but decide that its powers aren't that
> important and so let it self-govern without forced Council
> interaction.  Even so we should probably create some avenue for appeal
> so that the next time an argument comes up over whether long-term
> masks vs overlays are the right solution people feel like they had
> input into the decision.

I think that it is not a power thing but more of a responsibility and
accountability that is being defined. There is nothing about Governance
by the council when I read the GLEP. The only thing is the confirmation
by the Council since they are Privy to a lot more information then all
the isolated Teams are, and can prevent problems ahead of time.

The GLEP is a draft also and I have already proposed some changes to
Kristian about some wording.

The idea here is that it is not someone taking away power, but just
continuing what we have been doing in Security for years and just
formulating some of the processes by the GLEP. We have always had leads
that received notifications, communicated on behalf of the team, settled
problems, etc.

We have always discussed and provided opinions on changes and no one was
dictated something before discussion (Unless Security Policy specific).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

On 3/13/17 3:28 PM, Thomas Deutschmann wrote:

> A lead is only needed if the team can't get a decision.
> 
> Saying that the team could call for re-election if they don't like
> lead's decision is ridiculous from my view: Like said it isn't the lead
> who controls the direction. It is the lead who should step down if
> he/she doesn't feel comfortable with the team decision and no longer
> wants to represent the project anymore because he/she disagree so much
> with the team decision.

The security team has always worked in a process where the direction of
the team (with the leads) has always been decided as a team. Based on
reading the GLEP it is the goal of it to assign responsibility and not
to take control away from the other team members.

We have always discussed and voted on things in full disclosure. I see
nothing changing from the way we do things, and nothing is changing from
the way it is, projects have leads. People vote on project leads, the
security team has had and voted on project leads for a long time before.
There were two before, Alex and Tobias. Making it one or two is a
decision that can easily be discussed. Making it 15 leads just does not
work.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

On 3/13/17 3:10 PM, Thomas Deutschmann wrote:

> I completely disagree with that.
> 
> The whole powerful lead/deputy thing is going in the wrong direction.
> 
> We don't need that. Security project is nothing special and doesn't need
> a strong lead with such a power to rule the entire Gentoo project.
> 
> In general, every full member in the project should be equal. So I would
> list them all as confidential contact for example. This would lower the
> chance to compromise a member because an attacker wouldn't know who will
> get contacted. If we would only have one contact (like the lead) this
> would be a high-value target.

That is not possible (every full member as a confidential contact). This
is not something that is allowed by the upstream early notification
teams. We have tried using a mailing list and only very few would accept
that.

Also this is important for point of contacts as well. Once the
confidential contacts receive the email they put in to bugzilla and make
it security bug at that point everyone sees it.

> Because the security project has some inactive/dev away members the team
> maybe want to select some main contacts instead. But this is up to the
> team/project and doesn't belong in any GLEP.

That is the whole point of elections, if the lead is away then the
deputy takes over the role. If the deputy can  not do the job for some
reason then they can be changed to another deputy.  There is no problems
with that, the deputy role being a non-elected role.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Tue, Mar 14, 2017 at 7:55 PM, Yury German  wrote:
>
>
> The maintainer also knows the package, dependencies, other bugs filed, etc. 
> Removing things for your
> packages might be simple, but it is not the same across all packages and that 
> is the reason we ask the
> Maintainers to take an active step in cleaning up.

I agree.

The security team should be empowered to do the cleanup, but I think
their first priority should be to administering the overall process.
Anything maintainers can do to move it along is probably going to make
the process more efficient.

The reality is that most of the "work" in terms of commits/etc in
security work is really done by maintainers and arch teams.  The main
role of the security team is to ensure that it is all happening, so
they're going to spend a lot of time herding along everybody else.
They can always chip in with other things but if they don't do the
administrative overhead nobody else will.

-- 
Rich

Re: [gentoo-dev] Unused profiles

[Jack Morgan]

On 01/19/17 09:08, Michał Górny wrote:

(CC-ing a lot of potentially interested teams)

Hi, everyone.

I've did a quick sweep of profiles/ directory for unused profiles.
Unused means: not used as parent of any other profile, and not listed
in profiles.desc.

Note that the list does not include parents of the listed profiles
since they are still used by them ;-).

Please let me know which of the profiles are worth keeping, and which
can be killed entirely. If you prefer to keep them, please consider
adding them to profiles.desc so that our users can officially use them.

List follows



Just to follow up, for all Sparc profiles

I use two profiles..
default/linux/sparc/13.0 *
default/linux/sparc/13.0/desktop

I'm happy to remove these profiles...
default/linux/sparc/13.0/desktop/gnome
default/linux/sparc/13.0/desktop/gnome/systemd
default/linux/sparc/13.0/developer

anyone else?

--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan 
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

Re: [gentoo-dev] Unused profiles

[Jack Morgan]

On 01/19/17 09:08, Michał Górny wrote:

default/linux/sparc/experimental/multilib/desktop
default/linux/sparc/experimental/multilib/developer


These can go to.

--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan 
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

Re: [gentoo-dev] Unused profiles

[Jack Morgan]

On 01/22/17 10:49, Anthony G. Basile wrote:

default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd
default/linux/powerpc/ppc64/13.0/desktop/kde/systemd
default/linux/powerpc/ppc64/13.0/developer


I think these can go.


The systemd folks added the */systemd.  I don't care to keep them but
they might.  */developer can definitely go.


Personally, I think all of these can go. Just keep the base profile and 
desktop which I use on my PPC systems.



--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan 
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Yury German]

> On Mar 12, 2017, at 4:14 AM, Alexis Ballier  wrote:
> 
> 
> Also, it'd be nice to have something more formal for sec. cleanup:
> "After 30 days a sec. issue has been fixed, sec. team is free to
> cleanup old vulnerable versions.". I've seen too much pings by sec.
> team members on old bugs for this and they could have spent the same
> amount of time simply doing it instead.


Alexis, here is a problem that I have noticed over the years. Everyone is short 
on time, but if the developers do not step in (and only some) and clean up the 
packages then we might as well make this another job for Security team as 
everyone will just leave it to security.

Security looks at every security bug, and needs to do a lot of things behind 
the scenes. GLSA writing, look for CVE’s if not there, assign them to bugs in 
the CVE system used for GLSA’s. If no CVE’s exist communicate with upstream to 
see if it was requested, if not requested request it on their behalf and work 
with MITRE in getting it assigned. When you multiply that time over the 100+ 
security bugs at any time. Cleanup is not a 5 second thing as for me typing 
three characters to have that bug be submitted with that comment. 

The maintainer also knows the package, dependencies, other bugs filed, etc. 
Removing things for your packages might be simple, but it is not the same 
across all packages and that is the reason we ask the Maintainers to take an 
active step in cleaning up.

Re: [gentoo-dev] [PATCH] mysql-v2.eclass: Drop dead g3nt8.org mirror

[Thomas Deutschmann]

This is now committed.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature