On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Any reason why we don't just follow "The Apache Way"[1] (my term) and list a few of the "core" security people on our website with gpg keys? Then the user has to fetch like 2-4 keys, but I think that's much, much easier and more robust than what is proposed here. This does not require any new keys/servers/software. To make it easier to use, we could put up a file that contains all the relevant keys so that users can import them into GPG in one step. Then we just put up a link that sends to the 2-4 recipients and we are done. With a schleuder based solution, they'd also have to import the schleuder key and then they'd probably click on the email link on some page. I'd say, essentially, both solutions are equal in terms of usability. Doing it "The Apache Way", we also obviously gain full end2end encryption between the reporter and the security team. It is also much clearer for the user who will be able to read their mail, which I believe is quite important when you deal with security issues. Also keeping the recipient list small is good because it limits potentially unwanted exposure. So far I only see benefits with "The Apache Way", where I see a lot of downside with schleuder (difficult setup, additional software, likely rarely used thus might break without us knowing, no actual advantage in terms of usability/security). Am I missing something? [1] https://www.apache.org/security/ Florian

On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Since this requires a GPG key to be on the server, we want to implement this securely and hook up a nitrokey pro 2 to a separate Hetzner dedicated server. This server serves the sole purpose of hosting the security mail address. Installing by Hetzner costs 18 euro’s (excl. VAT).

Options:

* Cheapest Hetzner server 34 euro / month and 40 euro setup fees. * Hetzner auction server ~ 25 / month and no setup fees. * Different dedicated server hoster which allows custom usb devices.

Benefits:

* Key can’t be recovered by an attacker who has access to the server. * Receivers don’t need a shared private key but only their own. * Separate server so no other software can influence/impact. Downsides:

Downsides:

* Nitrokey is out of our control, but we trust Hetzner already (ie. they could easily hook up a malicious USB/BMC device already and gain root privileges). * Server dies, the Nitrokey has to be moved to the new server.

Questions:

* How to update the key, handle key expiration? * Do we backup the key? Let someone have a separate nitrokey?

Setup: * Levente (anthraxx) volunteered to aquire, setup key (+revocation) and get it to Hetzner.

-- Jelle van der Waa

Seems like I've missed a discussion on IRC. Please don't read my next lines as stab into your back. First of all I don't understand the problem you want to solve with this solution. In the past we had people who monitor the security@archlinux.org address and I had always the feeling that they did their job good and had no problem with doing it. I always thought that there are not so much mails with security@archlinux.org as recipient. So either my observation was wrong or things has changed.. Let's say the workload has increased. Then I am fully with you and I can understand your problem. On the technical aspects I like your idea, but I can understand Florians point of view as well. Maybe the problem could be already solved via creating a security landing page with a few developer mail addresses and their GPG keys. But here is another argument for the server: We could use it as isolated machine for automatically signing ISO images and Arch Linux images. chris / shibumi

https://securitytxt.org/ -- Best, polyzen

On 2/11/19 10:48 PM, Florian Pritz via arch-devops wrote:

On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

...

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Any reason why we don't just follow "The Apache Way"[1] (my term) and list a few of the "core" security people on our website with gpg keys? Then the user has to fetch like 2-4 keys, but I think that's much, much easier and more robust than what is proposed here. This does not require any new keys/servers/software.

Yes, all this sounds nice and convenient if we are talking about single time reporters that search for a contact to report an issue. However, the primary advantage we wanted to have solved on top are managed/subscribed reporting to CERT. Right now its extremely in-transparent, we have "random" people mapped on their side (and it already contains an inactive dev). What we wish to have is a transparent way to manage first-level receivers on our side (f.e. in ansible) that handle and redistribute the information to the right people on our team. I don't quite like that we need to be aware of who may be registered at CERT and alter it when people resign. Also it could be a good beta test for using a GPG smartcard in the data center that may potentially be handy for future stuff :-) cheers, Levente

On 2/18/19 1:08 PM, Daniel M. Capella via arch-devops wrote:

On February 18, 2019 4:57:16 AM EST, Morten Linderud via arch-devops wrote:

...

On Mon, Feb 18, 2019 at 04:48:57AM -0500, Daniel M. Capella via arch-devops wrote:

...

https://securitytxt.org/

It would be a bit benefitial if you made an argument instead of posting a link.

Learned about it after a check for that file was added to twa[]. Shared as it was relevant.

You shared a contextless link without explaining why it is relevant. Actually, you're still asserting that it is relevant without explaining why it is relevant -- this is particularly intriguing given that it seems other people are counter-asserting that it is not relevant.

...

https://news.ycombinator.com/item?id=19152145

As we're requiring encrypted communications (IIUC), it looks like that's been a fairly effective barrier.

Do we require encrypted communications? Or was that simply recommended to other people being brought as comparisons? Either way -- filtering the emails for encrypted communications is still a nonzero task. Why engage in additional efforts to support this security.txt thing, when assertations have been made that it is not beneficial at all, and furthermore, the *location* where the list of security contacts is stored is entirely offtopic in this discussion about unifying the actual contacts to list, as a method of preventing leakage and other confusion when members are added and removed from that list, and/or the potential for people with outdated information to encrypt data to a recipient that is no longer supposed to have access to such information. -- Eli Schwartz Bug Wrangler and Trusted User

On 2/18/19 9:23 PM, Florian Pritz via arch-devops wrote:

On Mon, Feb 18, 2019 at 03:10:00PM +0100, Levente Polyak via arch-devops wrote:

...

However, the primary advantage we wanted to have solved on top are managed/subscribed reporting to CERT.

Sorry, I didn't know that. This is indeed a pretty good reason and I'm much more inclined to agree that deploying this might be a good idea. If someone wants to work on this (i.e. create ansible roles), I won't oppose.

I'm sure we will be able to provide them properly, jelle would work on this as well.

Some question came to mind though: Do we actually need encryption there? Do they send important/zero-day/private issues or do they just send some form of advisory about already public problems? Or do they require a GPG key before they add you to their contact list?

Yes, it is mostly sensitive pre-notification before information is declared public. They also accept sending it in clear-text, so I guess I will make sure now that we only receive notifications to security@archlinux.org now. We can later update the contact to make them use the new GPG key, I would still prefer if they don't need to send it in clear-text :-)

Also, could you give a rough estimate of how many mails per day/month/year we are talking about and how many different senders are involved?

It fluctuates highly, but a rough overall estimate would be something around 6 mails per month with aprox. 4 unique senders (3 of which on regular or semi-regular base). cheers, Levente