Skip to content

Add security policy (fixes #6)#13

Merged
matteodelabre merged 1 commit intomainfrom
add-security-policy
Feb 6, 2021
Merged

Add security policy (fixes #6)#13
matteodelabre merged 1 commit intomainfrom
add-security-policy

Conversation

@matteodelabre
Copy link
Copy Markdown
Member

No description provided.

@matteodelabre matteodelabre added the documents Policy documents label Jan 15, 2021
Copy link
Copy Markdown
Member

@Eeems Eeems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@Eeems Eeems requested review from LinusCDE, dixonary and raisjn January 15, 2021 19:02
Copy link
Copy Markdown
Collaborator

@raisjn raisjn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

who has access to the email? is there an SLA on responding + fixing or do we just use industry standard?

@matteodelabre
Copy link
Copy Markdown
Member Author

who has access to the email?

I’m going to give access to the email to the maintainers, as with #12.

is there an SLA on responding + fixing or do we just use industry standard?

The current wording only says “as soon as possible”. What’s your opinion on this? I think we don’t really have the resources available to provide a SLA.

@Eeems
Copy link
Copy Markdown
Member

Eeems commented Jan 15, 2021

No support or security guarantee of any kind is provided for the testing branch.

Since we also say this, I don't think we really care to provide an SLA.

@raisjn
Copy link
Copy Markdown
Collaborator

raisjn commented Jan 15, 2021

https://en.wikipedia.org/wiki/Responsible_disclosure - the industry standard is 90 day before disclosing a vulnerability in software, but for package repositories, probably makes sense to look at debian or arch.

https://www.debian.org/security/disclosure-policy
https://wiki.archlinux.org/index.php/Arch_Security_Team

debian is few days for initial response, then attempt to get fix in within 2 weeks (depending on severity). not sure what arch is, doesn't look specified.

i think leaving it unspecified is fine.

@Eeems
Copy link
Copy Markdown
Member

Eeems commented Jan 15, 2021

We can have an internal target of 2 weeks depending on severity, with a few days to respond.

matteodelabre added a commit to toltec-dev/toltec that referenced this pull request Jan 15, 2021
@dixonary
Copy link
Copy Markdown
Contributor

I agree with having an internal target rather than something explicit. LGTM.

Who is authorised to merge?

@LinusCDE
Copy link
Copy Markdown
Member

Not sure if we'd even need the email access. I think making the mail forward it to all of us would be fine. Some clubs are probably doing it similarly since responses usually come from their personal (but usually club specific) emails. But the current approach is probably better to keep up authenticity when responding from a random email and preventing duplicate answers.

(Not sure what the state on the mail is, but I have a mailcow mail server that could double for this domain as well and give out domain-admin accounts.)

@LinusCDE
Copy link
Copy Markdown
Member

I agree with having an internal target rather than something explicit. LGTM.

Who is authorised to merge?

Usually the person who started a PR also merges it. If you're okay with it, it would be cool if you can review it.

@Eeems
Copy link
Copy Markdown
Member

Eeems commented Jan 17, 2021

I agree with having an internal target rather than something explicit. LGTM.

Who is authorised to merge?

@dixonary I think we are just waiting on you to approve the PR and we can merge.

@Eeems Eeems linked an issue Jan 17, 2021 that may be closed by this pull request
@matteodelabre
Copy link
Copy Markdown
Member Author

We just need your review before we can merge this @dixonary. Thanks!

Copy link
Copy Markdown
Contributor

@dixonary dixonary left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very sorry, I thought I had done this already!

@matteodelabre matteodelabre merged commit 8f81970 into main Feb 6, 2021
@matteodelabre matteodelabre deleted the add-security-policy branch February 6, 2021 14:33
@matteodelabre
Copy link
Copy Markdown
Member Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documents Policy documents

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define security policy

5 participants