Subject: [alpine-devel] Fw: Improving cross-distribution security

From: Natanael Copa <[email-masked]>
Date: Fri, 1 Mar 2019 21:48:06 +0100

Hi,

I got this email from Morten who I met at the reproducible builds
summit lat December. I think this is a very nice initiative and I think
Alpine should try participate.

Begin forwarded message:

Date: Thu, 21 Feb 2019 23:42:02 +0100
From: Morten Linderud <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Improving cross-distribution security

Hi, I'm Morten from the Arch Linux security team.

There are a lot of community linux distributions with adhoc security teams that
work on an best effort basis. A lot of time is spent on the same tasks. For
example tracking down if a patch has been backported to a linux-stable release,
and which commit fixes which specific CVE and so on. The main goal of this
effort is to alleviate the workload of vulnerability tracking by means of
information sharing as there's plenty of overlap on each of the distros'
efforts.

We strongly believe better collaboration between distributions can help all
users' security. While all distributions hold different priorities for their
development, timely vulnerability tracking and remediation of upstream projects
is one that is a clear win for all of them. Alpine, Red Hat, NixOS and SUSE have
replied positively on this idea and we now reaching out to other distributions
that may wish to participate.

#### Goals:
- Improve overall distribution security and collaboration
- Share knowledge in regards to issues, mitigations and patches
- Help younger distributions establish security teams

#### Non-goals:
- The project has no intention of replacing the open-wall distros/oss-security list.
- The project has no intention of replacing distro security teams, but rather enrich them

We have created the IRC channel ##distro-security on freenode that will function
as a cross-distribution channel to discuss security issues. The goal of this
channel is not to replace team channels, but work as a high signal-to-noise
place where people can ask for information, patches and advisories. The channel
will also work for further discussions how to improve collaboration between
distribution teams.

#### Projects contacted on BCC:
- SUSE
- Alpine Linux
- Guix
- NixOS
- Manjaro
- Gentoo
- Void Linux
- Debian
- Ubuntu
- QubesOS
- Red Hat
- Clear Linux
- Slackware
- Mageia

This is meant to be an open project. If there are any distributions missing from
the above list, please don't hesitate forwarding this email or replying with
contact information.

We are excited to hear back from distributions about thoughts, concerns or
suggestions on this project.

Cheers,
Arch Linux Security Team

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Daniel Isaksen <[email-masked]>
Date: Sat, 02 Mar 2019 00:45:53 +0000

This is a great initiative, and we really need to get Working Groups (WGs) /
Special Interest Groups (SIGs) formally set up. A while ago, I created a draft
document[1] describing how to create and operate them. If you strongly
disapprove of Google, email me, and I can return you a PDF copy.

So, I'll be short: what do you, the Alpine developers, think of this proposal?
Could any of you help me with said document? I am on the (somewhat loosely
defined) 'infrastructure team', so I will be able to help out with the technical
aspect.

My personal opinion is that we need a team of (at least semi-)dedicated people
on a Security SIG to first and foremost:
- Maintain a security advisory program as a service for Alpine users.
- Make sure we are properly tracking and patching new vulnerabilities, both
  through open-source intelligence and information sharing with other
  distributions.

[1]: https://docs.google.com/document/d/1TIGk24yLdoAC-JAH7IQzCAkxzX_YocUiHVbeSt-WZsk/edit?usp=sharing
-----
Sincerely / Med vennlig hilsen,
Daniel Isaksen <[email-masked]> (https://duniel.no)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

> From: Morten Linderud [email-masked]

> ----------------------------------------------------------------------------------------------------------

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 1 Mar 2019 21:19:01 -0500

> [1]: https://docs.google.com/document/d/1TIGk24yLdoAC-JAH7IQzCAkxzX_YocUiHVbeSt-WZsk/edit?usp=sharing

I disagree with your outlined approach, for various reasons.
After a discussion over on IRC, we agreed on a more general team-based 
management approach.
Please find the resulting draft proposal here[1].

We also both agreed that something along these lines must be done, for 
many reasons.
Kaniini has also expressed preemptive support in #alpine-devel.

Hopefully, a deeper and more detailed discussion will take place (likely 
over IRC) within the next few days.

[1]: https://p.toastin.space/F7MDfw?asciidoc

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 14 Mar 2019 17:11:31 +0100

On Fri, 1 Mar 2019 21:19:01 -0500

> [1]: https://p.toastin.space/F7MDfw?asciidoc

This has been suggested before. Wilcox had some good points and
suggestions[1].

And we need this badly. We are not lacking volunteers, but problem is
that I have become in a position that everything blocks on me. I want
fix that.

What would be the simplest way to get this started? We already have a
semi-team for infra, with Carlo as team lead.

We could probably also get a docs team running immediately, with Chloe
as team lead.

That would be a good start I think.

[1]: http://lists.alpinelinux.org/alpine-devel/5811.html
[2]: http://lists.alpinelinux.org/alpine-devel/6215.html

-nc

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Thu, 14 Mar 2019 20:16:00 -0400

> This has been suggested before. Wilcox had some good points and

I agree with the following points:
- People can often identify with their specific project even moreso than 
with the distribution.
- Having dedicated teams for languages - this isn't necessary, but is 
very useful when there is sufficient interest.

However, I have several issues with the idea being presented there.
Specifically:
- Some level of formality is needed - this helps avoid a bottlenecking 
situation, and enforces separation of tasks (minimizing 
context-switching and thus increasing total throughput).
- A license-oriented team likely isn't needed per-se. We have since 
started using the SPDX license list, so the remaining bits can be 
handled by the core and aports teams (depending on the specifics).

The reality is that that suggestion was made in the middle of 2017, and 
the situation has changed, but it's certainly something to look at.

> that I have become in a position that everything blocks on me. I want

It also means that you (and other core/infra developers) tend to be 
extremely busy.
One of the goals would be to lessen your load (and allow you to, at the 
same time, be more efficient at the things that you *do* still do :) ).

> That would be a good start I think.

Currently, the plan (as discussed in #alpine-docs, because that's where 
the conversation happened to have happened) is to have a meeting on 
Sunday, 14:00 GMT.
I'm currently composing a proposed agenda for it.

During it, things such as the initial teams should be decided, after 
which (likely Monday) a final version would be submitted for approval by 
the core team.

Once approval happens, I'll initialize a developer-handbook repository 
(even if it'll likely be a bit until more things get added to it) and 
populate it with everything that'll have been decided during the meeting 
(and potentially revised during the, hopefully short, approval process).

As a side note, I agree with your initial set of teams, though I think 
the core and aport teams should also be made at the start, along with a 
full member listing.

---