summaryrefslogtreecommitdiff
path: root/.github
diff options
context:
space:
mode:
authorDavid Sherret <dsherret@users.noreply.github.com>2022-12-05 17:30:58 -0500
committerGitHub <noreply@github.com>2022-12-05 17:30:58 -0500
commit5e1113ec772876faee13221ad1ce8b5ef4efbdba (patch)
tree45e94a2ad99ae5ec8274250bd2b2934c87db1344 /.github
parent2fab4583ef3db0a3d8438ffa07f9e64db8190433 (diff)
chore: move/remove some repo top level files (#16951)
Diffstat (limited to '.github')
-rw-r--r--.github/CODE_OF_CONDUCT.md4
-rw-r--r--.github/SECURITY.md60
2 files changed, 64 insertions, 0 deletions
diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md
new file mode 100644
index 000000000..740967958
--- /dev/null
+++ b/.github/CODE_OF_CONDUCT.md
@@ -0,0 +1,4 @@
+Deno uses
+[Rust's Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct). In
+the forums, every community member must follow the rules and values expressed
+there. Please email ry@tinyclouds.org to report any instance of misconduct.
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
new file mode 100644
index 000000000..c5680b2b0
--- /dev/null
+++ b/.github/SECURITY.md
@@ -0,0 +1,60 @@
+# Security Policy
+
+Thank you for taking the time to investigate the security of Deno. The security
+of Deno is our topmost priority. We appreciate investigative work into system
+security by well-intentioned, ethical security researchers. If you discover a
+vulnerability, however small, we would like to know about it to address it with
+appropriate measures as quickly as possible. This document outlines the method
+we use to work with the security research community to address runtime security.
+
+## Reporting a vulnerability
+
+Please email findings to security@deno.com. We strive to resolve all problems as
+quickly as possible, and are more than happy to play an active role in
+publication of writeups after the problem is resolved.
+
+Try to include as much information as possible in the initial email, so we can
+quickly address the issue.
+
+**Please do not open security issues in the public issue tracker.**
+
+### Please do the following
+
+- Do not take advantage of the vulnerability or problem you have discovered.
+- Do not publish or reveal the problem until it has been resolved.
+- Do not use attacks on physical security or applications of third parties.
+- Do provide sufficient information to reproduce the problem, so we will be able
+ to resolve it as quickly as possible. Usually, a list of steps to follow, and
+ the vulnerable Deno version is enough. More complex vulnerabilities may
+ require further explanation.
+
+### Our commitment to you
+
+- If you act in accordance with this policy, we will not take legal action
+ against you in regard to your report.
+- We will handle your report with strict confidentiality, and not pass on your
+ personal details to third parties without your permission.
+
+## Security Model
+
+The following paragraphs outline the rough security model for Deno. The model
+may change slightly over time, but in general the model is as follows:
+
+- All JavaScript run in Deno is considered untrusted, so permissions are thus
+ never enforced in JavaScript.
+- All JavaScript run in a single Deno process is considered to be part of the
+ same program and is not isolated from itself. This means that Deno does not
+ guarantee that values set by one JS module will be inaccessible to another, or
+ that a value set in one web worker can not be accessed by another.
+- All runtime I/O is considered to be privileged and must always be guarded by a
+ runtime permission. This includes filesystem access, network access, etc.
+- Users should not be able to self-escalate their permissions without explicit
+ consent.
+- I/O required to build an initial static module graph should always follow the
+ permissions of its parent. If there is no parent, all permissions are granted.
+ As an example, this means that the initial static module graph that is
+ constructed when doing `deno run`, does not have any permission restrictions.
+ However, the module graph constructed as the result of loading a web worker or
+ dynamic import will be restricted to the permissions of the caller (the main
+ worker most likely).
+- We consider the V8 VM to be a secure sandbox.