diff --git a/.gitignore b/.gitignore
index 0ac0ed3..42e44b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,23 @@
# Hugo-generated assets
-public/
-resources/
+.hugo_build.lock
+/public
+/resources
# npm assets
node_modules/
+package-lock.json
+yarn.lock
+
+# Local scratch folder
+tmp/
+
+# macOS
+.DS_Store
+
+# Misc
+scripts/collector.yaml
+assets/jsconfig.json
+/.netlify
+
+# VS Code
+/.vscode
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..b76244d
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "themes/docsy"]
+ path = themes/docsy
+ url = https://github.com/google/docsy.git
diff --git a/assets/icons/logo.svg b/assets/icons/logo.svg
new file mode 100644
index 0000000..5d53394
--- /dev/null
+++ b/assets/icons/logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/icons/tuf-white-logo.svg b/assets/icons/tuf-white-logo.svg
new file mode 100644
index 0000000..6276b3c
--- /dev/null
+++ b/assets/icons/tuf-white-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/js/app.js b/assets/js/app.js
deleted file mode 100644
index c582a49..0000000
--- a/assets/js/app.js
+++ /dev/null
@@ -1,16 +0,0 @@
-const navbarBurger = () => {
- const burger = $(".navbar-burger"),
- menu = $(".navbar-menu");
-
- burger.click(() => {
-
-
- [burger, menu].forEach((el) => el.toggleClass('is-active'));
- });
-}
-
-$(() => {
- console.log("Welcome to the CNCF's Hugo + Netlify starter");
-
- navbarBurger();
-});
diff --git a/assets/sass/helpers.sass b/assets/sass/helpers.sass
deleted file mode 100644
index 79b8cb2..0000000
--- a/assets/sass/helpers.sass
+++ /dev/null
@@ -1,65 +0,0 @@
-// This guarantees that the footer stays stuck to the bottom of the page
-.is-page
- display: flex
- flex-direction: column
- min-height: 100vh
-
- .is-main
- flex: 1
-
-=logo($d, $m)
- +desktop
- width: $d
- +touch
- width: $m
-
-.hero-logo
- +logo(70%, 30%)
- +tablet-only
- width: 80%
-
-.cncf-logo
- +logo(80%, 60%)
-
-.has-extra-padding
- padding: 2rem 0
-
-.is-narrow-desktop
- +desktop
- width: 80%
-
-.has-bottom-padding
- padding-bottom: 7.5rem
-
-.toc
- top: $navbar-height + 2rem
- position: sticky
- border-left: 3px solid $primary
- padding: 1.5rem 0 1.5rem 2rem
-
- &-content
- font-weight: 300
- font-size: 1.2rem
-
-.has-no-y-padding
- padding: 3rem 0
-
-hr.thick
- +desktop
- width: 6rem
- height: 5px
- +touch
- width: 4rem
- height: 4px
-
- background-color: $primary
-
-.content.is-copyright
- p
- font-size: 1.1rem
-
- a
- font-weight: 700
-
- &:hover
- color: $grey
diff --git a/assets/sass/style.sass b/assets/sass/style.sass
deleted file mode 100644
index ef9204b..0000000
--- a/assets/sass/style.sass
+++ /dev/null
@@ -1,128 +0,0 @@
-@charset "utf-8"
-{{ $extraColors := site.Params.colors.extra }}
-{{ $fontAwesomeVersion := site.Params.font_awesome_version }}
-{{ $fonts := site.Params.fonts }}
-{{ if $fonts }}
-{{ $fontSlice := (slice) }}
-{{ range $fonts }}
-{{ $fontSlice = $fontSlice | append (printf "%s:%s" (replace .name " " "+") (delimit .sizes ",")) }}
-{{ end }}
-{{ $fontsUrl := printf "https://fonts.googleapis.com/css?family=%s" (delimit $fontSlice "|") }}
-@import url("{{ $fontsUrl }}")
-{{ end }}
-
-{{ with $fontAwesomeVersion }}
-{{ $fontAwesomeUrl := printf "https://use.fontawesome.com/releases/v%s/css/all.css" . }}
-@import url("{{ $fontAwesomeUrl }}")
-{{ end }}
-
-// Site-specific variables here
-$tuf-blue: #0082ca
-
-// Extra colors specified in config
-{{ with $extraColors }}
-{{ range . }}
-${{ .name }}: '{{ .hex }}'
-{{ end }}
-{{ end }}
-
-// Initial Bulma imports
-@import "bulma/sass/utilities/initial-variables"
-@import "bulma/sass/utilities/functions"
-
-// Bulma-specific overrides
-$primary: $tuf-blue
-$navbar-dropdown-boxed-radius: 0
-
-// Font overrides
-{{ if $fonts }}
-// Sans-serif font
-{{ with (index (where $fonts ".type" "sans_serif") 0).name }}
-$family-sans-serif: "{{ . }}", BlinkMacSystemFont, -apple-system, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", "Helvetica", "Arial", sans-serif
-{{ end }}
-
-// Monospace font
-{{ with (index (where $fonts ".type" "monospace") 0).name }}
-$family-monospace: "{{ . }}", monospace
-{{ end }}
-{{ end }}
-
-// Final Bulma imports
-@import "bulma/sass/utilities/derived-variables"
-
-// Bulma variable overrides that require derived variables like $dark
-$footer-background-color: $light
-$link: $primary
-$section-padding: 4rem 1.5rem
-$hero-padding: 0
-$navbar-height: 4rem
-$content-blockquote-background-color: $white-bis
-$content-blockquote-border-left: 5px solid $primary
-$navbar-height: 5rem
-$navbar-item-img-max-height: $navbar-height * 0.7
-
-{{ with $extraColors }}
-{{ range . }}
-$colors: mergeColorMaps(("{{ .name }}": ({{ .hex }}, $white)), $colors)
-{{ end }}
-{{ end }}
-
-// Show h2 headings a bit below navbar when clicking anchors, without affecting
-// the spacing between a heading and a preceding paragraph.
-h2:before
- height: calc(#{$navbar-height} + 2rem)
- margin-top: calc((#{$navbar-height} + 2rem) * -1)
- content: ""
- display: block
-
-// Bulma core
-@import "bulma/sass/utilities/_all"
-@import "bulma/sass/base/_all"
-@import "bulma/sass/elements/container"
-@import "bulma/sass/grid/columns"
-// @import "bulma/sass/grid/tiles"
-@import "bulma/sass/layout/hero"
-@import "bulma/sass/layout/section"
-@import "bulma/sass/layout/footer"
-
-// Elements
-
-// @import "bulma/sass/elements/box"
-@import "bulma/sass/elements/button"
-@import "bulma/sass/elements/content"
-@import "bulma/sass/elements/icon"
-// @import "bulma/sass/elements/image"
-// @import "bulma/sass/elements/notification"
-// @import "bulma/sass/elements/progress"
-// @import "bulma/sass/elements/table"
-// @import "bulma/sass/elements/tag"
-@import "bulma/sass/elements/title"
-// @import "bulma/sass/elements/other"
-
-// Forms
-// @import "bulma/sass/form/shared"
-// @import "bulma/sass/form/input-textarea"
-// @import "bulma/sass/form/checkbox-radio"
-// @import "bulma/sass/form/select"
-// @import "bulma/sass/form/file"
-// @import "bulma/sass/form/tools"
-
-// Components
-// @import "bulma/sass/components/breadcrumb"
-// @import "bulma/sass/components/card"
-// @import "bulma/sass/components/dropdown"
-// @import "bulma/sass/components/level"
-// @import "bulma/sass/components/list"
-// @import "bulma/sass/components/media"
-// @import "bulma/sass/components/menu"
-// @import "bulma/sass/components/message"
-// @import "bulma/sass/components/modal"
-@import "bulma/sass/components/navbar"
-// @import "bulma/sass/components/pagination"
-// @import "bulma/sass/components/panel"
-// @import "bulma/sass/components/tabs"
-
-// Grid
-
-// Custom Sass imports
-@import "helpers"
diff --git a/assets/scss/_styles_project.scss b/assets/scss/_styles_project.scss
new file mode 100644
index 0000000..40d7b93
--- /dev/null
+++ b/assets/scss/_styles_project.scss
@@ -0,0 +1,52 @@
+@import 'td/code-dark';
+
+.td-navbar {
+ .navbar-brand {
+ svg {
+ height: 38px;
+ }
+ .navbar-brand__name {
+ display: none;
+ }
+ }
+}
+
+.td-home {
+ .cncf {
+ text-align: center;
+
+ p {
+ font-size: 1.2rem;
+ margin-bottom: 0;
+ }
+
+ img {
+ width: 20rem;
+ padding-top: 1rem;
+ max-width: 80%;
+ }
+ }
+}
+
+.adoptions-container {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ align-items: center;
+ margin-bottom: -3rem;
+}
+
+.adoptions-logo {
+ max-height: 4rem;
+ max-width: 100%;
+}
+
+.adoptions-item {
+ margin-left: auto;
+ margin-right: auto;
+ padding-left: 1.5rem;
+ padding-right: 1.5rem;
+ padding-bottom: 3rem;
+}
+
+$tuf-blue: #0082ca;
diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss
new file mode 100644
index 0000000..38724f1
--- /dev/null
+++ b/assets/scss/_variables_project.scss
@@ -0,0 +1 @@
+/* Add styles or override variables from the theme here. */
diff --git a/config.toml b/config.toml
deleted file mode 100644
index 96c2747..0000000
--- a/config.toml
+++ /dev/null
@@ -1,171 +0,0 @@
-title = "The Update Framework"
-disableKinds = ["section", "taxonomy"]
-baseURL = "https://theupdateframework.io"
-
-[markup.goldmark.renderer]
-unsafe = true
-
-[params]
-font_awesome_version = "5.12.0"
-description = "A framework for securing software update systems"
-favicon = "favicon.png"
-copyright = """
-The TUF project is managed by the Linux Foundation under the Cloud Native Computing Foundation. The consensus builder for TUF is [Prof. Justin Cappos](https://ssl.engineering.nyu.edu/personalpages/jcappos/) of the [Secure Systems Lab](https://ssl.engineering.nyu.edu) at [New York University](https://engineering.nyu.edu/). Project maintainers[[1](https://github.com/theupdateframework/specification/blob/master/MAINTAINERS.md)][[2](https://github.com/theupdateframework/python-tuf/blob/develop/docs/MAINTAINERS.txt)] are comprised of collaborators from academia and the industry. Contributors and maintainers are governed by the [CNCF Community Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
-
-This material is based upon work supported by the National Science Foundation under Grant Nos. CNS-1345049 and CNS-0959138. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
-"""
-
-[params.logos]
-navbar = "tuf-horizontal-white.png"
-hero = "tuf-stacked-color.png"
-cncf = "cncf-color.png"
-
-[[params.fonts]]
-name = "Nunito"
-sizes = [300, 400, 600, 700]
-type = "sans_serif"
-
-[[params.fonts]]
-name = "Roboto Mono"
-sizes = [300, 400, 600, 700]
-type = "monospace"
-
-[[menu.main]]
-name = "About"
-identifier = "about"
-weight = 1
-
-[[menu.main]]
-name = "Overview"
-parent = "about"
-url = "/overview"
-weight = 1
-
-[[menu.main]]
-name = "History"
-parent = "about"
-url = "/history"
-weight = 2
-
-[[menu.main]]
-name = "Timeline"
-parent = "about"
-url = "/timeline"
-weight = 3
-
-[[menu.main]]
-name = "Publications"
-parent = "about"
-url = "/publications"
-weight = 5
-
-[[menu.main]]
-name = "Project"
-parent = "about"
-url = "/project"
-weight = 5
-
-[[menu.main]]
-name = "Code of conduct"
-parent = "about"
-url = "https://github.com/cncf/foundation/blob/master/code-of-conduct.md"
-weight = 6
-
-[[menu.main]]
-name = "Getting started"
-identifier = "getting-started"
-weight = 2
-
-[[menu.main]]
-name = "Security"
-parent = "getting-started"
-url = "/security"
-weight = 1
-
-[[menu.main]]
-name = "Roles and metadata"
-parent = "getting-started"
-url = "/metadata"
-weight = 2
-
-[[menu.main]]
-name = "Frequently asked questions"
-parent = "getting-started"
-url = "/faq"
-weight = 3
-
-[[menu.main]]
-name = "Specification (latest)"
-parent = "getting-started"
-url = "/specification"
-weight = 4
-
-[[menu.main]]
-name = "Specification index"
-parent = "getting-started"
-url = "/specification/list"
-weight = 5
-
-
-[[menu.main]]
-name = "Implementations"
-parent = "getting-started"
-url = "/implementations"
-weight = 6
-
-[[menu.main]]
-name = "Videos"
-parent = "getting-started"
-url = "/videos"
-weight = 7
-
-[[menu.main]]
-name = "Community"
-identifier = "community"
-weight = 3
-
-[[menu.main]]
-name = "Adoptions"
-parent = "community"
-url = "/adoptions"
-weight = 1
-
-[[menu.main]]
-name = "Reporting issues"
-parent = "community"
-url = "/reporting"
-weight = 2
-
-[[menu.main]]
-name = "Security audits"
-parent = "community"
-url = "/audits"
-weight = 3
-
-[[menu.main]]
-name = "Enhancement proposals"
-parent = "community"
-url = "/taps"
-weight = 4
-
-[[menu.main]]
-name = "Contribute"
-parent = "community"
-url = "https://github.com/theupdateframework/python-tuf"
-weight = 5
-
-[[menu.main]]
-name = "Chat (CNCF Slack)"
-parent = "community"
-url = "https://cloud-native.slack.com/archives/C8NMD3QJ3"
-weight = 6
-
-[[menu.main]]
-name = "News"
-url = "/news/"
-weight = 4
-
-[[menu.main]]
-name = "Contact"
-url = "/contact/"
-weight = 5
diff --git a/content/_index.md b/content/_index.md
deleted file mode 100644
index ac0f31f..0000000
--- a/content/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
----
-
-The Update Framework (**TUF**) helps developers maintain the security of software update systems, providing protection even against attackers that compromise the repository or signing keys. TUF provides a flexible framework and [specification](https://theupdateframework.github.io/specification/latest/) that developers can adopt into any software update system.
-
-TUF is hosted by the [Linux Foundation](https://www.linuxfoundation.org/) as part of the [Cloud Native Computing Foundation](https://www.cncf.io) (CNCF) and is [used in production](/adoptions) by various tech companies and open source organizations. A variant of TUF called [Uptane](https://uptane.github.io/) is widely used to secure over-the-air updates in automobiles.
diff --git a/content/adoptions.md b/content/adoptions.md
deleted file mode 100644
index 334a42f..0000000
--- a/content/adoptions.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Adoptions
----
-
-By clicking on the images below, you will be linked either to articles that
-cover the TUF adoption, presentations on the adoption, or to repositories
-containing the relevant code.
-
-{{< adoptions "main" >}}
-
-
-## Ongoing
-
-{{< adoptions "ongoing" >}}
-
-## Others
-
-* [Docker registry bindings](https://github.com/davedoesdev/dtuf)
-* [A Rust implementation](https://github.com/heartsucker/rust-tuf)
diff --git a/content/audits.md b/content/audits.md
deleted file mode 100644
index 61124cd..0000000
--- a/content/audits.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Security audits
----
-
-> **Note**: This list only contains publicly available audits.
-
-* [September 9, 2022 by X41](/audits/x41-python-tuf-audit-2022-09-09.pdf)
-
-* [August 7, 2018 by Cure53](https://github.com/theupdateframework/notary/blob/master/docs/resources/cure53_tuf_notary_audit_2018_08_07.pdf) covering TUF and Notary
-
-* [October 18, 2017 by NCC](https://www.nccgroup.trust/globalassets/our-research/us/public-reports/2017/ncc-group-kolide-the-update-framework-security-assessment.pdf) security assessment of TUF / Kolide.
-
-* [July 31, 2015 by NCC](https://github.com/theupdateframework/notary/blob/master/docs/resources/ncc_docker_notary_audit_2015_07_31.pdf) covering TUF and Notary.
diff --git a/content/contact.md b/content/contact.md
deleted file mode 100644
index 75b3be5..0000000
--- a/content/contact.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Contact
----
-
-Please contact us via our [mailing
-list](https://groups.google.com/forum/?fromgroups#!forum/theupdateframework).
-
-Questions, feedback, and suggestions are welcomed on this low volume mailing
-list or the [#tuf](https://cloud-native.slack.com/archives/C8NMD3QJ3) channel
-on [CNCF Slack](https://slack.cncf.io/). We strive to make the specification
-easy to implement, so if you come across any inconsistencies or experience any
-difficulty, do let us know by sending an email, or by reporting an issue in
-the [specification
- repo](https://github.com/theupdateframework/specification/issues).
diff --git a/content/en/_index.md b/content/en/_index.md
new file mode 100644
index 0000000..e880d38
--- /dev/null
+++ b/content/en/_index.md
@@ -0,0 +1,66 @@
+---
+title: TUF
+description: A framework for securing software update systems
+outputs:
+ - HTML
+ - REDIRECTS # Include this `content/en` ONLY
+developer_note:
+ The blocks/cover shortcode (used below) will use as a background image any
+ image file containing "background" in its name.
+---
+
+{{% blocks/cover title="The Update Framework" image_anchor="top" color="primary" height="max" %}}
+
+
+{{% param description %}}
+{.display-6}
+
+Learn More
+Get started
+{.p-initial .my-5}
+
+{{% /blocks/cover%}}
+
+{{% blocks/lead color="tertiary" %}}
+
+The Update Framework (TUF) maintains the security of software update systems,
+providing protection even against attackers that compromise the repository or
+signing keys. TUF provides a flexible framework and
+[specification](https://theupdateframework.github.io/specification/latest/) that
+developers can adopt into any software update system.
+
+{{% /blocks/lead %}}
+
+{{% blocks/section color="dark" type="row" %}}
+
+{{% blocks/feature icon="fa-lightbulb" title="Our work" url="docs/" %}}
+
+Discover how TUF secures update systems
+
+{{% /blocks/feature %}}
+
+{{% blocks/feature icon="fa-solid fa-gear" title="Production Ready" url="/community/adoptions/" %}}
+Used in production by various tech companies and open source organizations.
+
+{{% /blocks/feature %}}
+
+{{% blocks/feature icon="fa-brands fa-github" title="Contribute" url="https://github.com/theupdateframework" %}}
+Start contributing to TUF open source by creating a Pull request on
+[GitHub](https://github.com/theupdateframework)
+
+{{% /blocks/feature %}}
+
+{{% /blocks/section %}}
+
+{{% blocks/section color="primary" type="cncf" %}}
+
+**TUF** is a [CNCF](https://www.cncf.io)
+[graduated](https://www.cncf.io/projects) project.
+
+[![CNCF logo][]][cncf]
+
+[cncf]: https://cncf.io
+[cncf logo]: /img/cncf-white.svg
+[incubating]: https://www.cncf.io/projects/
+
+{{% /blocks/section %}}
diff --git a/content/en/community/_index.md b/content/en/community/_index.md
new file mode 100644
index 0000000..8dbef1a
--- /dev/null
+++ b/content/en/community/_index.md
@@ -0,0 +1,12 @@
+---
+title: Community
+menu: { main: { weight: 40 } }
+cascade:
+ type: docs
+# If your project has a local or external contributing page, then
+# specify the path or URL below.
+contributingUrl: https://github.com/theupdateframework/community
+# Content below, if any, will be added to the community page.
+---
+
+{{% community-lists %}}
diff --git a/content/en/community/adoptions/img/agl.png b/content/en/community/adoptions/img/agl.png
new file mode 100644
index 0000000..ffe5d19
Binary files /dev/null and b/content/en/community/adoptions/img/agl.png differ
diff --git a/content/en/community/adoptions/img/bottlerocket.png b/content/en/community/adoptions/img/bottlerocket.png
new file mode 100644
index 0000000..f6e6aa4
Binary files /dev/null and b/content/en/community/adoptions/img/bottlerocket.png differ
diff --git a/content/en/community/adoptions/img/cnab.png b/content/en/community/adoptions/img/cnab.png
new file mode 100644
index 0000000..45d1f31
Binary files /dev/null and b/content/en/community/adoptions/img/cnab.png differ
diff --git a/content/en/community/adoptions/img/datadog.png b/content/en/community/adoptions/img/datadog.png
new file mode 100644
index 0000000..48c8cfe
Binary files /dev/null and b/content/en/community/adoptions/img/datadog.png differ
diff --git a/content/en/community/adoptions/img/docker.png b/content/en/community/adoptions/img/docker.png
new file mode 100644
index 0000000..a6daedb
Binary files /dev/null and b/content/en/community/adoptions/img/docker.png differ
diff --git a/content/en/community/adoptions/img/fleetdm.png b/content/en/community/adoptions/img/fleetdm.png
new file mode 100644
index 0000000..db469be
Binary files /dev/null and b/content/en/community/adoptions/img/fleetdm.png differ
diff --git a/content/en/community/adoptions/img/foundriesio.png b/content/en/community/adoptions/img/foundriesio.png
new file mode 100644
index 0000000..4ae65be
Binary files /dev/null and b/content/en/community/adoptions/img/foundriesio.png differ
diff --git a/content/en/community/adoptions/img/fuchsia.png b/content/en/community/adoptions/img/fuchsia.png
new file mode 100644
index 0000000..8495503
Binary files /dev/null and b/content/en/community/adoptions/img/fuchsia.png differ
diff --git a/content/en/community/adoptions/img/harbor.png b/content/en/community/adoptions/img/harbor.png
new file mode 100644
index 0000000..bde18b0
Binary files /dev/null and b/content/en/community/adoptions/img/harbor.png differ
diff --git a/content/en/community/adoptions/img/haskell.png b/content/en/community/adoptions/img/haskell.png
new file mode 100644
index 0000000..33299ea
Binary files /dev/null and b/content/en/community/adoptions/img/haskell.png differ
diff --git a/content/en/community/adoptions/img/here.png b/content/en/community/adoptions/img/here.png
new file mode 100644
index 0000000..a8dea94
Binary files /dev/null and b/content/en/community/adoptions/img/here.png differ
diff --git a/content/en/community/adoptions/img/kolide.png b/content/en/community/adoptions/img/kolide.png
new file mode 100644
index 0000000..3b55c20
Binary files /dev/null and b/content/en/community/adoptions/img/kolide.png differ
diff --git a/content/en/community/adoptions/img/mamba.png b/content/en/community/adoptions/img/mamba.png
new file mode 100644
index 0000000..eb22b77
Binary files /dev/null and b/content/en/community/adoptions/img/mamba.png differ
diff --git a/content/en/community/adoptions/img/notary.png b/content/en/community/adoptions/img/notary.png
new file mode 100644
index 0000000..56e4585
Binary files /dev/null and b/content/en/community/adoptions/img/notary.png differ
diff --git a/content/en/community/adoptions/img/opam.png b/content/en/community/adoptions/img/opam.png
new file mode 100644
index 0000000..79ea38f
Binary files /dev/null and b/content/en/community/adoptions/img/opam.png differ
diff --git a/content/en/community/adoptions/img/php.png b/content/en/community/adoptions/img/php.png
new file mode 100644
index 0000000..052968e
Binary files /dev/null and b/content/en/community/adoptions/img/php.png differ
diff --git a/content/en/community/adoptions/img/pypi.png b/content/en/community/adoptions/img/pypi.png
new file mode 100644
index 0000000..04bae17
Binary files /dev/null and b/content/en/community/adoptions/img/pypi.png differ
diff --git a/content/en/community/adoptions/img/sigstore.png b/content/en/community/adoptions/img/sigstore.png
new file mode 100644
index 0000000..0bb7df8
Binary files /dev/null and b/content/en/community/adoptions/img/sigstore.png differ
diff --git a/content/en/community/adoptions/img/trdl.png b/content/en/community/adoptions/img/trdl.png
new file mode 100644
index 0000000..c0f9caf
Binary files /dev/null and b/content/en/community/adoptions/img/trdl.png differ
diff --git a/content/en/community/adoptions/index.md b/content/en/community/adoptions/index.md
new file mode 100644
index 0000000..5eb92bb
--- /dev/null
+++ b/content/en/community/adoptions/index.md
@@ -0,0 +1,19 @@
+---
+title: Adoptions
+weight: 40
+description: Explore practical adoptions of TUF
+---
+
+Each TUF adoption listed below links to an article, presentation, or repository
+containing relevant code.
+
+{{< adoptions "main" >}}
+
+## Ongoing
+
+{{< adoptions "ongoing" >}}
+
+## Others
+
+- [Docker registry bindings](https://github.com/davedoesdev/dtuf)
+- [A Rust implementation](https://github.com/heartsucker/rust-tuf)
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
new file mode 100755
index 0000000..9d2316f
--- /dev/null
+++ b/content/en/docs/_index.md
@@ -0,0 +1,11 @@
+---
+title: Documentation
+linkTitle: Docs
+menu: { main: { weight: 15 } }
+spelling: cSpell:disable # REMOVE this line
+---
+
+Welcome to TUF docs!
+
+We cover everything you need to know about TUF, from learning the specification,
+implementing it, to contributing in various capacities.
diff --git a/content/en/docs/faq.md b/content/en/docs/faq.md
new file mode 100644
index 0000000..4e675a0
--- /dev/null
+++ b/content/en/docs/faq.md
@@ -0,0 +1,155 @@
+---
+title: Frequently Asked Questions
+LinkTitle: FAQ
+weight: 45
+description: Get your questions answered!
+---
+
+**1. How difficult is it to integrate TUF?**
+
+At a high level, all an adopter needs to do is (1) add TUF metadata to its
+software repository, and (2) arrange for clients to use TUF to fetch files from
+the repository before transferring the verified files to the software update
+system.
+
+In practice, (1) will also require the adopter to decide how to make the
+metadata and delegations available to clients, how to manage the keys needed to
+sign TUF metadata (in particular, how to generate, securely store or backup, and
+rotate offline keys), and how to periodically update and re-sign metadata.
+
+For (2), an adopter has to figure out how to ship the initial Root file, and
+implement
+[the TUF download and verification workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow)
+in their language of choice if one of the existing implementations is
+insufficient.
+
+**2. Why should I use delegations?**
+
+Using delegations makes it so that users can perform actions for one another
+without needing to share keys in order to make this happen. As we state in the
+specification: "Delegated roles can further delegate trust to other delegated
+roles. This provides for multiple levels of trust delegation where each role can
+delegate full or partial trust for the target files they are trusted for."
+Delegations add more security. For instance, in a community repository like
+PyPI, delegating trust for target files to a project developer is recommended.
+It increases compromise-resilience because if the developers control their own
+project keys, an attacker cannot access them, and therefore cannot sign and
+serve malicious versions of the project.
+
+**3. What happens if the server and keys are compromised?**
+
+The repo maintainer must revoke and replace compromised keys. If a Timestamp,
+Snapshot, Targets, or Root key is compromised, the Root role must re-sign its
+metadata to replace the compromised key. If a threshold of Root keys is
+compromised, the Root file must be re-issued out of band. If a threshold number
+of offline keys are required, a full compromise of the repo is unlikely. For a
+more in-depth discussion about the steps to follow in the event of a key
+compromise, see
+[PEP 458](https://www.python.org/dev/peps/pep-0458/#in-the-event-of-a-key-compromise),
+which covers one way to deal with compromised keys on a community repo such as
+PyPI.
+
+**4. Can I use the same keys for different roles?**
+
+In general, you shouldn't share keys. In certain cases, even sharing online keys
+(e.g., between the Timestamp and Snapshot roles) is not advised. As we recommend
+for the PyPI community, "different keys for online roles allow for each of the
+keys to be placed on separate servers if need be, and prevents side channel
+attacks that compromise one key from automatically compromising the rest of the
+keys."
+
+**5. Which roles can use online keys?**
+
+The Timestamp and Snapshot roles can use online keys to facilitate continuous
+delivery of updates on the typical repository. All other roles should rely on
+offline keys to prevent attackers from signing for malicious packages in the
+event of a repo compromise.
+
+**6. What is the point of having the Root and Snapshot roles?**
+
+The Root role keeps track of the trusted public keys of the top-level roles, and
+can remove or add keys when needed. Its metadata is rarely updated and its
+signing keys must receive the greatest protection. In contrast, the Snapshot
+role is updated often, signed with an online key, and provides a consistent view
+of the metadata available on a repo. The Snapshot and Root role are responsible
+for different tasks that differ in level of importance. Separation of
+responsibilities is one of TUF's design choices.
+
+**7. Can you combine Timestamp and Snapshot?**
+
+There are a few reasons why the Timestamp and Snapshot files are not combined:
+
+- The Timestamp file is downloaded very frequently and so should be kept as
+ small as possible, especially considering that the Snapshot file will grow
+ proportionally with the number of delegated target roles.
+
+- As the Timestamp role’s key is an online key and thus at high risk, when an
+ offline key storage is appropriate for Snapshot, separate keys should be used
+ so that the Snapshot role’s keys can be kept offline, and thus in a more
+ secure manner.
+
+- When rotating keys, it makes much more sense to rotate Timestamp frequently.
+ When Timestamp is rotated, if an attacker compromises the new key, they can
+ launch a freeze attack for a short while. For Snapshot, an attacker could
+ cause clients to invalidate a lot of their stored targets metadata, which may
+ result in re-retrieval of a substantial amount of information from the
+ repository. So, it is recommended to rotate Timestamp more often.
+
+- Timestamp may be given to mirrors.
+
+**8. How often should metadata expire?**
+
+The Timestamp and Snapshot metadata should normally have a short expiration (1
+day), whereas the Root and Targets metadata should expire less often (1 year). A
+good rule of thumb is the more often the metadata changes, the sooner it should
+expire.
+
+**9. Are there ways to reduce bandwidth costs?**
+
+It is possible to minimize the size and number of delegated metadata that the
+client has to download, and in doing so, reduce the associated costs. The
+[Metadata Scalability section](https://www.python.org/dev/peps/pep-0458/#metadata-scalability)
+of PEP 458 discusses in more detail the ways in which to reduce bandwidth costs.
+For example, if one large metadata file is split into several smaller ones, the
+bandwidth associated with downloading the large file many times can be saved.
+The reference implementation provides an
+[easy way to distribute target files across many targets metadata](https://github.com/theupdateframework/python-tuf/blob/v0.20.0/examples/repo_example/hashed_bin_delegation.py)
+(i.e., delegating to hashed bins), which the specification refers to as
+[path hash prefixes](https://theupdateframework.github.io/specification/latest/#path_hash_prefixes).
+
+**10. Can TUF be used with devices that lack the CPU power or memory to verify
+metadata?**
+
+At a minimum, a client device must be able to verify the hashes and signatures
+on TUF metadata. If a device isn't powerful enough to perform cryptographic
+operations or has limited memory, it can delegate verification of hashes and
+signatures to another device. For instance, a weaker device can rely on another
+device on the network to verify the signatures on top-level metadata. Delegating
+to another device is not built into the framework but
+[Uptane](https://uptane.github.io/), a variant of TUF, is designed to work with
+weaker devices like the Electronic Control Units found in automobiles.
+
+**11. Can I use TUF to download files from more than one repository?**
+
+TUF can download files from multiple mirrors and repos. In fact, we offer
+guidance for conducting a secure search for files across multiple repositories
+in [TAP 4](https://github.com/theupdateframework/taps/blob/master/tap4.md).
+
+**12. Has there been a security audit of TUF?**
+
+The [Security Audits](docs/overview/security) page links to a few of the
+security audits of TUF.
+
+**13. How can I try TUF?**
+
+The `python-tuf` reference implementation provides a
+[well-documented API](https://theupdateframework.readthedocs.io/en/latest/api/api-reference.html)
+to create and manage TUF metadata on a server-side repository, and to perform
+TUF-compliant updates on a client, as well as basic Python
+[code examples](https://github.com/theupdateframework/python-tuf/tree/develop/examples)
+that demonstrate the usage.
+
+**14. Is there a presentation or video about TUF?**
+
+The [Videos]() page contains links to presentations that have been given by both
+TUF developer personnel, as well as adopters.
diff --git a/content/en/docs/get-started/_index.md b/content/en/docs/get-started/_index.md
new file mode 100644
index 0000000..97ebb1a
--- /dev/null
+++ b/content/en/docs/get-started/_index.md
@@ -0,0 +1,21 @@
+---
+title: Get started
+weight: 17
+# aliases: [/docs/getting-started/]
+description: Get started with TUF based on your role.
+---
+
+Want to learn more about TUF? Select a role to get started:
+
+
+
+- [Adopter](adopter/) : You want to use TUF either as a maintainer or client
+- [Contributor](contributor/) : You want to contribute to TUF spec or
+ documentation
+
+
+
+You can also check out our [Videos][] section to see how to implement TUF
+practically.
+
+If none of these roles apply to you, let us know.
diff --git a/content/en/docs/get-started/adopter.md b/content/en/docs/get-started/adopter.md
new file mode 100644
index 0000000..ac61842
--- /dev/null
+++ b/content/en/docs/get-started/adopter.md
@@ -0,0 +1,38 @@
+---
+title: Adopter
+weight: 100
+description: Get started with TUF as an adopter.
+---
+
+TUF provides a framework for integration of the
+[security](docs/overview/security) properties into new and existing content
+delivery systems.
+
+While some [adoptions](/community/adoptions/) integrate TUF by implementing the
+framework from scratch, others start from either a TUF implementation or from a
+TUF system.
+
+This page lists open source implementations of TUF which can be used as building
+blocks for any TUF adoption.
+
+## Implementations
+
+TUF implementations provide libraries implementing the primitives and
+algorithms, such as the detailed client workflow, in the specification.
+
+- [python-tuf](https://github.com/theupdateframework/python-tuf), the reference
+ implementation
+- [go-tuf](https://github.com/theupdateframework/go-tuf/)
+- [tuf-js](https://github.com/theupdateframework/tuf-js)
+
+## Systems
+
+TUF systems build on top of library implementations and provide opinionated
+signing systems designed for particular use-cases.
+
+- [Repository Service for TUF (RSTUF) ](https://repository-service-tuf.readthedocs.io/en/stable/)
+ is a TUF repository designed to integrate into an existing artifact repository
+ with an established storage and delivery system.
+- [tuf-on-ci](https://github.com/theupdateframework/tuf-on-ci/) is a TUF
+ repository and signing tool designed to operate on a CI system and guide
+ signing events through Git forge workflows.
diff --git a/content/en/docs/get-started/contributor.md b/content/en/docs/get-started/contributor.md
new file mode 100644
index 0000000..2bd0d76
--- /dev/null
+++ b/content/en/docs/get-started/contributor.md
@@ -0,0 +1,18 @@
+---
+title: Contributor
+weight: 17
+description: Learn how to contribute to TUF
+---
+
+There are many opportunities to contribute to TUF project.You can contribute to
+the Spec or documentation.
+
+For guidance on how to contribute, the
+[TUF Contributor Guide](https://github.com/theupdateframework/community/blob/main/CONTRIBUTING.md)
+provides details on the Contributor License Agreement and the Code of Conduct.
+
+For more information on how to contribute, reach out to the
+[TUF community site](/community/) or check out areas of contribution on GitHub
+[The Update Framework](https://github.com/theupdateframework).
+
+[Edit this page](https://github.com/theupdateframework/theupdateframework.io)
diff --git a/content/en/docs/history.md b/content/en/docs/history.md
new file mode 100644
index 0000000..7aaf158
--- /dev/null
+++ b/content/en/docs/history.md
@@ -0,0 +1,36 @@
+---
+title: History
+weight: 18
+description: Learn TUF history and core principles
+---
+
+The basic technology behind TUF was developed at the University of Washington in
+2009 by Justin Samuel and Justin Cappos, and presented in a
+[paper](https://theupdateframework.github.io/papers/survivable-key-compromise-ccs2010.pdf?raw=true)
+Samuel and Cappos coauthored with Nick Mathewson and Roger Dingledine,
+researchers from [The Tor Project, Inc](https://www.torproject.org/). Since
+2011, TUF has been based at
+[New York University Tandon School of Engineering](https://engineering.nyu.edu/),
+where Cappos is a tenured associate professor of computer science and
+engineering. There he works with a team of Ph.D. students, including Trishank
+Karthik Kuppusamy, who graduated in 2017, and developers, including Vladimir
+Diaz and Sebastien Awwad, to supervise the development of TUF and its adoption
+and integration by open source non-profits and tech companies.
+
+Though TUF technologies have been customized to meet end-user specifications,
+four core principles continue to be central to its design.
+
+- The first is separation of responsibilities for signing metadata, which means
+ one compromised key does not automatically compromise all repository users.
+
+- The second specifies a fixed number of signatures agreeing to the authenticity
+ of what is presented in the metadata that accompanies an update before the
+ server will download it.
+
+- A third principle works to help a repository to recover quickly from a
+ compromise by providing an automatic way to revoke signing keys. By doing so,
+ hackers can not sign metadata to authenticate malware.
+
+- Lastly, TUF keeps the most vulnerable signing keys offline, which greatly
+ reduces the risk that they can be stolen or compromised. In 2016, the TUF
+ research group set up a process whereby the community could
diff --git a/content/en/docs/overview/_index.md b/content/en/docs/overview/_index.md
new file mode 100644
index 0000000..df06cda
--- /dev/null
+++ b/content/en/docs/overview/_index.md
@@ -0,0 +1,99 @@
+---
+title: Overview
+weight: 10
+description: Find out what TUF is all about!
+---
+
+### Purpose, or Why Get TUF?
+
+There are thousands of different software update systems in common use today.
+
+What these systems have in common is they all identify, locate, and download
+updates for software that can add new functionalities or address old
+vulnerabilities. Software is rarely ever static, and some repositories receive
+updates on software or project metadata
+[every few minutes](https://theupdateframework.io/papers/protect-community-repositories-nsdi2016.pdf).
+
+This growing flow of updates has also created a need for better ways to protect
+the systems that manage them. Though a number of strategies have been introduced
+and used over the last decade or so to enhance the authenticity of update
+files—and by extension, the security of update systems—most have drawbacks that
+have left repositories vulnerable to a number of attacks.
+
+TUF was launched almost a decade ago as a way to build system resilience against
+key compromises and other attacks that can spread malware or compromise a
+repository. The primary goals behind its design are:
+
+- To provide a framework (a set of libraries, file formats, and utilities) that
+ can be used to secure new and existing software update systems.
+
+- To provide the means to minimize the impact of key compromises.
+
+- To be flexible enough to meet the needs of a wide variety of software update
+ systems.
+
+- To be easy to integrate with existing software update systems.
+
+### Software Updates 101
+
+A software update system is an application (or part of an application) running
+on a client system that identifies, obtains, and installs software.
+
+There are three major classes of software update systems:
+
+- **Application updaters** internal updaters that allow an application to update
+ itself. For example, Firefox updates itself through its own application
+ updater.
+
+- **Library package managers** offered by many programming languages for
+ installing additional libraries. Examples include Python's pip/easy_install +
+ PyPI, Perl's CPAN, Ruby's RubyGems, and PHP's Composer.
+
+- **System package managers** used by operating systems to update and install
+ software on a client system. Examples include Debian's APT, Red Hat's YUM and
+ openSUSE's YaST.
+
+While these systems may vary in how they work, most follow a similar update
+procedure. Obtaining and installing an update simply means:
+
+- Knowing when an update exists.
+- Downloading the update.
+- Applying the changes introduced by the update.
+
+TUF is designed to perform the first two steps of this procedure, while guarding
+against the majority of attacks that can occur during or after the update. These
+include threats that other software security strategies may not take into
+account, such as when:
+
+- An attacker keeps giving you the same file, so you never realize there is an
+ update.
+
+- An attacker gives you an older, insecure version of a file that you already
+ have and tricks you into thinking it's newer. You download it and blindly use
+ it.
+
+- An attacker gives you a newer version of a file you have but it's still not
+ the _newest_ one. It's newer to you, but it may be insecure and exploitable by
+ the attacker.
+
+- An attacker compromises the key used to sign these files. Now you download a
+ file that is properly signed, but is still malicious.
+
+The [Security](docs/overview/security) section offers a full list of the attacks
+and updater weaknesses that TUF is designed to defend against.
+
+### How does TUF secure updates?
+
+In a sense, TUF enhances security by adding verifiable records about the state
+of a repository or application. By adding metadata containing information about
+which signing keys are trusted, the cryptographic hashes of files, signatures on
+the metadata, metadata version numbers, and the date after which the metadata
+should be considered expired, it creates a record that can be checked to verify
+the authenticity of update files.
+
+Your software update system never has to deal with this additional metadata or
+understand what's going on underneath. TUF identifies the updates, downloads
+them, and checks them against the metadata that it also downloads from the
+repository. If the downloaded target files are trustworthy, TUF hands them over
+to your software update system. See [metadata](docs/overview/metadata) for more
+information and examples.
diff --git a/content/en/docs/overview/metadata.md b/content/en/docs/overview/metadata.md
new file mode 100644
index 0000000..384814c
--- /dev/null
+++ b/content/en/docs/overview/metadata.md
@@ -0,0 +1,139 @@
+---
+title: Roles and Metadata
+LinkTitle: Metadata
+weight: 15
+description: Understand Roles and Metadata
+---
+
+TUF uses roles to define the set of actions a party can perform. The concept of
+roles allows TUF to only trust information provided by the correctly designated
+party. The root role indicates which roles can sign for which projects.
+
+The roles sign metadata, which TUF uses to create verifiable records about the
+state of a repository or application at a specified time. As such, clients can
+use it to make decisions on which files to update. Different metadata files
+provide different information, and will be signed by different roles.
+
+The signed metadata files always include an expiration date. This ensures that
+outdated metadata will be detected and that clients can refuse to accept
+metadata older than that which they've already seen.
+
+Implementers of TUF may use any data format for metadata files. The examples
+here use a subset of the JSON object format. When calculating the digest of an
+object, we use the [Canonical JSON](http://wiki.laptop.org/go/Canonical_JSON)
+format. Implementation-level detail about the metadata can be found in the
+[spec](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md).
+
+There are four required top-level roles, each with their own metadata file.
+
+Required:
+
+- Root
+- Targets
+- Snapshot
+- Timestamp
+
+Optional:
+
+There may also be any number of delegated target roles.
+
+## Root Metadata (root.json)
+
+Signed by: Root role.
+
+Specifies the other top-level roles. When specifying these roles, the trusted
+keys for each are listed, along with the minimum number of those keys required
+to sign the role's metadata. We call this number the signature threshold.
+
+See
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/root.json)
+of Root metadata.
+
+## Targets Metadata (targets.json)
+
+Signed by: Targets role.
+
+Target files are the actual files that clients want to download, such as the
+software updates they are trying to obtain. The targets.json metadata file lists
+hashes and sizes of target files.
+
+This file can optionally define other roles to which it delegates trust, or
+specify that another role is to be trusted for some or all of the target files
+available from the repository. When delegated roles are specified, it is done so
+in a way similar to how the Root role specifies the top-level roles: by giving
+the trusted keys and signature threshold for each role. Additionally, one or
+more [glob patterns]() will be
+specified to indicate the target file paths for which clients should trust each
+delegated role.
+
+See
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/targets.json)
+of Targets metadata.
+
+## Delegated Targets Metadata (role1.json)
+
+Signed by: A delegated targets role.
+
+A metadata file provided by a Delegated Targets role will follow exactly the
+same format as one provided by the top-level Targets role.
+
+When the Targets role delegates trust to other roles, each delegated role will
+provide one signed metadata file. As is the case with the directory structure of
+top-level metadata, the delegated files are relative to the base URL of metadata
+available from a given repository mirror.
+
+A delegated role file is located at:
+
+/DELEGATED_ROLE.json
+
+where DELEGATED_ROLE is the name of the role specified in targets.json. If this
+role further delegates trust to a role named ANOTHER_ROLE, that role's signed
+metadata file would be found at:
+
+/ANOTHER_ROLE.json
+
+See
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/role1.json)
+of delegated Targets metadata and
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/role2.json)
+of a nested delegation.
+
+## Snapshot Metadata (snapshot.json)
+
+Signed by: Snapshot role.
+
+The snapshot.json metadata file lists version numbers of all metadata files
+other than timestamp.json. This file ensures that clients will see a consistent
+view of all files on the repository. That is, metadata files (and thus Target
+files) that existed on the repository at different times cannot be combined and
+presented to clients by an attacker.
+
+See
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/snapshot.json)
+of Snapshot metadata.
+
+## Timestamp Metadata (timestamp.json)
+
+Signed by: Timestamp role.
+
+The timestamp.json metadata file lists the hashes and size of the snapshot.json
+file. This is the first and potentially only file that needs to be downloaded
+when clients search for updates. It is frequently re-signed, and has a short
+expiration date, thus allowing clients to quickly detect if they are being
+prevented from obtaining the most recent metadata. An online key is generally
+used to automatically re-sign this file at regular intervals.
+
+There are a few reasons why the timestamp.json and snapshot.json files are not
+combined:
+
+- The timestamp.json file is downloaded very frequently and so should be kept as
+ small as possible, especially considering that the snapshot.json file grows
+ proportionally with the number of delegated target roles.
+- As the Timestamp role's key is an online key and thus at high risk, separate
+ keys should be used for signing the snapshot.json file so that the Snapshot
+ role's keys can be kept offline, and thus more secure.
+- Timestamp.json may be given to mirrors.
+
+See
+[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/timestamp.json)
+of Timestamp metadata.
diff --git a/content/en/docs/overview/project/_index.md b/content/en/docs/overview/project/_index.md
new file mode 100644
index 0000000..c5f83e5
--- /dev/null
+++ b/content/en/docs/overview/project/_index.md
@@ -0,0 +1,56 @@
+---
+title: Project
+LinkTitle: Project
+weight: 20
+description: Learn more about the TUF project
+---
+
+The TUF project consists of three components:
+
+- [Specification] – the detailed TUF specification describes how to add TUF
+ metadata to a repository and the process to arrange for clients to use that
+ metadata to download and verify targets.
+- [Standardization process] – major changes to the specification, including new features,
+ are made as TUF Augmentation Proposals (TAPs).
+- [Reference implementation] – python-tuf provides a reference implementation of
+ the TUF specification and is used as a vital part of the TAPs process to prototype
+ changes to the specification.
+
+The project is currently managed by a team of collaborators from academia and
+industry.
+
+Many people have contributed to the project since its inception, including
+academics, professional developers, and contributors from the open-source
+community. We especially acknowledge the individuals from the open-source
+community who have [contributed] to the TUF project over the years.
+
+Please visit the [governance page] to learn how project decisions are made, and for
+a more detailed explanation of the project roles used below.
+
+[contributed]:
+ https://github.com/theupdateframework/python-tuf/blob/develop/docs/AUTHORS.txt
+[governance page]:
+ https://github.com/theupdateframework/specification/blob/master/GOVERNANCE.md
+[Specification]: https://theupdateframework.github.io/specification/latest
+[Standardization process]:
+ https://github.com/theupdateframework/taps/blob/master/tap1.md
+[Reference implementation]: https://theupdateframework.readthedocs.io/en/latest/
+
+## Consensus Builder
+
+### Justin Cappos
+
+Email: jcappos@nyu.edu
+
+GitHub username: [JustinCappos](https://github.com/justincappos)
+
+PGP fingerprint: E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A
+
+## Maintainers
+
+| Maintainer | Email | GitHub username | PGP fingerprint |
+| :------------------------- | :--------------------------- | :-------------------------------------------------------- | :------------------------------------------------ |
+| Trishank Karthik Kuppusamy | trishank.karthik@datadog.com | [trishankatdatadog](https://github.com/trishankatdatadog) | 8C48 08B5 B684 53DE 06A3 08FD 5C09 0ED7 318B 6C1E |
+| Joshua Lock | joshua.lock@uk.verizon.com | [joshuagl](https://github.com/joshuagl) | 08F3 409F CF71 D87E 30FB D3C2 1671 F65C B748 32A4 |
+| Marina Moore | mm9693@nyu.edu | [mnm678](https://github.com/mnm678) | – |
+| Lukas Pühringer | lukas.puehringer@nyu.edu | [lukpueh](https://github.com/lukpueh) | 8BA6 9B87 D43B E294 F23E 8120 89A2 AD3C 07D9 62E8 |
diff --git a/content/en/docs/overview/project/tap.md b/content/en/docs/overview/project/tap.md
new file mode 100644
index 0000000..1a401c5
--- /dev/null
+++ b/content/en/docs/overview/project/tap.md
@@ -0,0 +1,20 @@
+---
+title: Enhancement Proposals
+LinkTitle: Tap
+weight: 16
+description: Learn more about TUF Augmentation Proposals
+---
+
+### What is a TAP?
+
+A TAP (TUF Augmentation Proposal) is a design document providing information to
+the TUF community, or describing a new feature for TUF or its processes or
+environment. We intend TAPs to be the primary mechanisms for proposing major new
+features, for collecting community input on an issue, and for documenting the
+design decisions that have gone into TUF.
+
+Please visit the [TAPs GitHub repo](https://github.com/theupdateframework/taps)
+to review design changes that have been proposed to date, or to submit your own
+new feature. See
+[TAP 1](https://github.com/theupdateframework/taps/blob/master/tap1.md) for
+instructions on how to submit a TAP.
diff --git a/content/en/docs/overview/security.md b/content/en/docs/overview/security.md
new file mode 100644
index 0000000..47dd3f0
--- /dev/null
+++ b/content/en/docs/overview/security.md
@@ -0,0 +1,143 @@
+---
+title: Security
+weight: 35
+description: Security properties of TUF repositories
+---
+
+We can think of a software update system as "secure" if:
+
+- it knows about the latest available updates in a timely manner
+- any files it downloads are the correct files, and,
+- no harm results from checking or downloading files.
+
+Making this happen requires workable preventive strategies against a number of
+potential attacks.
+
+## Attacks and Weaknesses
+
+The following are some of the known attacks on software update systems,
+including the weaknesses that make these attacks possible. To design a secure
+software update framework, these attacks need to be understood and strategies to
+defend against them must be specified. Some of these issues are, or can be,
+related, depending on the design and implementation of the given software update
+system.
+
+- **Arbitrary software installation**. An attacker can provide arbitrary files
+ in response to download requests and install anything on the client system,
+ yet none will be detected as illegitimate.
+
+- **Rollback attacks**. An attacker presents files to a software update system
+ that are older than those the client has already seen. With no way to tell it
+ is an obsolete version that may contain vulnerabilities, the user installs the
+ software. Later on, the vulnerabilities can be exploited by attackers.
+
+- **Fast-forward attacks**. An attacker arbitrarily increases the version
+ numbers of project metadata files in the snapshot metadata well beyond the
+ current value, thus tricking a software update system into thinking that any
+ subsequent updates are trying to rollback the package to a previous,
+ out-of-date version. In some situations, such as those where there is a
+ maximum possible version number, the perpetrator could use a number so high
+ that the system would never be able to match it with the one in the snapshot
+ metadata, and thus new updates could never be downloaded.
+
+- **Indefinite freeze attacks**. An attacker continues to present files to a
+ software update system files that the client has already seen. As a result,
+ the client is kept unaware of new files.
+
+- **Endless data attacks**. An attacker responds to a file download request with
+ an endless stream of data, causing harm to clients (e.g. a disk partition
+ filling up or memory exhaustion).
+
+- **Extraneous dependencies attacks**. An attacker indicates to clients that, in
+ order to install the software they want, they also need to install unrelated
+ software. This extra software may be from a trusted source, but could still
+ have known vulnerabilities that are exploitable by the attacker.
+
+- **Mix-and-match attacks**. An attacker presents clients with a view of a
+ repository that includes files that did not exist there together at the same
+ time. This can result in outdated versions of dependencies being installed,
+ and other complications.
+
+- **Wrong software installation**. An attacker provides a client with a trusted
+ file that is just not the one the client wanted.
+
+- **Malicious mirrors preventing updates**. An attacker controls one repository
+ mirror and is able to use it to prevent clients from obtaining updates from
+ other, non-malicious mirrors.
+
+- **Vulnerability to key compromises**. An attacker who can compromise the one
+ key in a single key system, or less than a given threshold of keys, can
+ compromise clients. These attacks can occur whether the client relies on a
+ single online key (if only being protected by SSL) or a single offline key (if
+ protected by most software update systems that use keysigning).
+
+## Security Design Principles
+
+To ensure systems are secure against all of the above attacks, the design and
+implementation of TUF relies on a few basic concepts. For details of how TUF
+conveys the information discussed below, see the
+[Metadata documentation](docs/overview/metadata).
+
+### Trust
+
+Trusting downloaded files really means assuming the files were provided by party
+without malicious designs. Two frequently overlooked aspects of trust in a
+secure software update system are:
+
+- Trust should not be granted forever. Trust should expire if it is not renewed.
+- Trust should not be granted equally to all parties. This type of
+ compartmentalized trust means a party is only to be trusted for the files that
+ the root role stipulates it is to provide.
+
+### Mitigating Key Risk (Compromise-Resilience)
+
+Cryptographic signatures are a necessary component in securing a software update
+system. The safety of the keys used to create these signatures directly affects
+the security of the clients the system protects. Rather than naively assume that
+private keys are always safe from compromise, a secure software update system
+must anticipate how to keep clients as safe as possible when a compromise of
+those keys occurs. This is the basic principle of compromise resilience.
+
+Keeping clients safe despite a key compromise involves:
+
+- Fast and secure key replacement and revocation.
+- Minimal trust placed in keys that are at high risk. Keys that are kept online
+ or used in an automated fashion should not pose an immediate risk to clients
+ if compromised.
+- Multiple key usage and a threshold/quorum of signatures.
+
+### Integrity
+
+Ensuring integrity in TUF not only refers to single files, but also to
+repository as a whole. It's fairly obvious that clients must verify that
+individual downloaded files are correct. It's not as obvious, but still very
+important for clients to be certain that their entire view of a repository is
+correct. For example, if a trusted party is providing two files, a software
+update system should see the latest versions of both files, not just one, and
+not versions of the two files that were never provided together.
+
+### Freshness
+
+Since software updates often fix security bugs, it is important for software
+update systems to obtain the latest versions available of these files. An
+attacker may want to trick a client into installing outdated versions of
+software or even just convince a client that no updates are available.
+
+Ensuring freshness means:
+
+- Never accepting files older than those that have been seen previously.
+- Recognizing when there may be a problem obtaining updates.
+
+Note that it won't always be possible for a client to successfully update if an
+attacker is responding to their requests. However, a client should be able to
+recognize that updates may exist that they haven't been able to obtain.
+
+## Implementation Safety
+
+In addition to a secure design, TUF also works to be secure against
+implementation vulnerabilities, including those common to software update
+systems. In some cases this is assisted by the inclusion of additional
+information in metadata. For example, knowing the expected size of a target file
+that is to be downloaded allows TUF to limit the amount of data it will download
+when retrieving the file. As a result, TUF is secure against endless data
+attacks (discussed above).
diff --git a/content/en/docs/timeline.md b/content/en/docs/timeline.md
new file mode 100644
index 0000000..84b3fd6
--- /dev/null
+++ b/content/en/docs/timeline.md
@@ -0,0 +1,91 @@
+---
+title: Timeline
+weight: 19
+Description: See the project timeline
+---
+
+**2010**: Improving upon the Thandy software updater for the Tor private
+browser, Justin Samuel and Justin Cappos collaborate to design and publish an
+academic research paper on The Update Framework (TUF).
+
+**2011**: TUF Project moves to New York University Polytechnic School of
+Engineering (later NYU Tandon School of Engineering) when Justin Cappos accepts
+a post as an assistant professor at the Brooklyn, NY, school.
+
+**2013**: Justin Cappos, Trishank Kuppusamy, and Vladimir Diaz begin research
+into adapting and improving TUF for Python, Ruby, and other environments used
+for cloud computing.
+
+**2013**: [PEP 458](https://www.python.org/dev/peps/pep-0458/), the first of two
+Python Enhancement Proposals dealing with TUF is published. "Surviving a
+Compromise of PyPI" details the integration of TUF into the Python package
+manager.
+
+**2014**: Flynn becomes the first tech organization to adopt TUF when it
+independently implements the program in its Go programming language.
+
+**2014**: [PEP 480](https://www.python.org/dev/peps/pep-0480/), a maximum
+security version of PEP 458, is published.
+
+**2015**: Docker launches Notary, an implementation of TUF used to publish and
+manage trusted collections of content. It also launches Docker Content Trust,
+which uses Notary to sign and verify container images.
+
+**2016**: _Diplomat: Using Delegations to Protect Community Repositories_ is
+presented at NSDI 2016. The subject of the paper, Diplomat, is the first of
+several TUF adaptations developed to address a specific identified problem in
+practice. In this case, the problem was the need for faster registration of new
+projects on community repositories without sacrificing security. It also
+introduced the concept of delegation of trust.
+
+**2016**: A consortium including NYU Tandon (Cappos, Kuppusamy, Diaz, Awwad),
+the University of Michigan Transportation Research Institute (UMTRI), and the
+Southwest Research Institute (SWRI), begin developing Uptane, another evolution
+of TUF designed to protect updates for vehicles from being easily compromised by
+rogue nation-state attackers.
+
+**2016**: _Uptane: Securing Software Updates for Automobiles_ is presented at
+escar 16.
+
+**2017**: Uptane is officially introduced at press events in Ann Arbor, MI, and
+Brooklyn, NY.
+
+**2017**: _Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against
+Community Repositories_ is presented at USENIX ATC 2017. Mercury is another TUF
+adaptation, and was developed to protect against rollback attacks on community
+repositories at a reasonable bandwidth cost.
+
+**2017**: Uptane is named one of the year's most important innovations in
+security by _Popular Science_.
+
+**2017**: The Linux Foundation announces at Open Source Summit Europe that it
+was adding TUF as the 14th hosted project for its Cloud Native Computing
+Foundation.
+
+**2018**: Aktualizr, an open source C++ implementation of Uptane developed by
+Advanced Telematic Systems (now HERE technologies), is integrated into
+Automotive Grade Linux (AGL). AGL, a collaborative open source project of the
+Linux Foundation, has been adopted by a number of U.S. and international
+manufacturers.
+
+**2018**: NYU Tandon School of Engineering becomes an associate member of the
+Linux Foundation and a Bronze member of AGL on the strength of the Foundation’s
+adoption of Uptane and TUF projects.
+
+**2018**: The Uptane Alliance, a nonprofit entity organized under the umbrella
+of IEEE’s International Standards and Technology Organization (ISTO), is formed
+to oversee development of standards for the secure implementation/deployment of
+Uptane.
+
+**2019**:
+[IEEE-ISTO 6100.1.0.0 Uptane Standard for Design and Implementation](https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html)
+is released.
+
+**2019**: Uptane becomes a Linux Foundation Joint Development Foundation
+project.
+
+**2019**: TUF is awarded graduate status within the organization, signifying
+completion of a series of steps needed to move the project to the highest level
+of maturity in the CNCF. In achieving this status, TUF becomes both the first
+security project and the first project led by an academic researcher to graduate
+within CNCF
diff --git a/content/en/featured-background.jpg b/content/en/featured-background.jpg
new file mode 100644
index 0000000..b1d3cac
Binary files /dev/null and b/content/en/featured-background.jpg differ
diff --git a/content/en/resources/_index.md b/content/en/resources/_index.md
new file mode 100644
index 0000000..6f63a58
--- /dev/null
+++ b/content/en/resources/_index.md
@@ -0,0 +1,9 @@
+---
+title: Resources
+menu: { main: { weight: 50 } }
+cascade:
+ type: docs
+---
+
+Find curated selections of videos, press coverage, and publications designed to
+inform and inspire you.
diff --git a/content/en/resources/news.md b/content/en/resources/news.md
new file mode 100644
index 0000000..8a3a553
--- /dev/null
+++ b/content/en/resources/news.md
@@ -0,0 +1,261 @@
+---
+title: News
+description: TUF news coverage
+aliases: [/news, /press]
+---
+
+## Highlights
+
+Here are our news highlights. For a complete list, see the [Press](#press)
+section.
+
+**June 16, 2021**
+
+The Sigstore community live-streamed a
+[key generation and signing ceremony ](https://www.cncf.io/blog/2021/06/16/a-new-kind-of-trust-root/)
+for the Sigstore trust root, which is using The Update Framework (TUF)
+primitives to provide a PKI model with no single entity in charge of the trust
+root, and shorter root key lifespan than traditional PKI models.
+
+**March 5, 2021**
+
+The
+[TUF specification](https://theupdateframework.github.io/specification/latest/index.html)
+is now published as a rich HTML document with a table of contents, syntax
+highlighting, cross-linking, and other features.
+
+The new publication machinery also maintains a
+[list of all versions ](https://theupdateframework.github.io/specification/)
+published since the format change.
+
+**October 30, 2020**
+
+The Python Software Foundation live-streams a
+[key generation and signing ceremony](https://www.youtube.com/watch?v=jjAq7S49eow&t=3078s)
+that marks the first practical steps in deploying The Update Framework (TUF) to
+the Python Package Index.
+
+**February 15, 2020**
+
+[PEP 458](https://www.python.org/dev/peps/pep-0458/), Secure PyPI Downloads with
+Package Signing, is accepted and merged into the Python Enhancement Proposals
+(PEP) tree.
+
+**December 19, 2019**
+
+TUF becomes the
+[first project](https://engineering.nyu.edu/news/open-source-system-secure-software-updates-graduates-protect-leading-cloud-services)
+led by an academic and the first specification-based project to graduate from
+the [Cloud Native Computing Foundation](https://www.cncf.io/).
+
+**August 2019**
+
+Uptane becomes joins the
+[Linux Foundation's Joint Development Foundation](https://www.jointdevelopment.org/),
+giving a pathway for ISO standardization of future versions of the
+specification.
+
+**July 31, 2019**
+
+The IEEE/ISTO standardizes
+[version 1.0.0 of the Uptane specification](https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html).
+
+**June 3, 2019**
+
+Trishank Kuppusamy publishes a
+[blog post](https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/)
+announcing the integration of both TUF and a related framework, called
+[in-toto](https://in-toto.io/), into
+[Datadog Agent Integrations](https://docs.datadoghq.com/getting_started/integrations/).
+
+**August 16, 2018**
+
+[NYU Tandon School of Engineering](https://engineering.nyu.edu/) becomes an
+associate member of the [Linux Foundation](https://www.linuxfoundation.org/) and
+a Bronze member of [Automotive Grade Linux](https://www.automotivelinux.org/) on
+the strength of the Foundation’s adoption of Uptane and TUF projects.
+
+**July 31, 2018**
+
+The Uptane Alliance, a nonprofit entity organized under the umbrella of IEEE's
+[International Standards and Technology Organization](https://ieee-isto.org/) is
+formed. The Alliance was tasked with overseeing the setting of standards for the
+implementation/deployment of Uptane, as well as the advancement and improvement
+of the technology itself.
+
+**January 25, 2018**
+
+[Airbiquity](https://www.airbiquity.com) receives a
+[BIG Award for Business](https://www.airbiquity.com/news/press-releases/airbiquity-otamatic-named-2017-new-product-year-business-intelligence-group)
+in the 2017 New Product of the Year Award category for its Uptane-based OTAmatic
+over-the-air software and data management solution.
+
+**December 7, 2017**
+
+Justin Cappos and David Lawrence, senior security engineer at Docker, jointly
+chaired the TUF/Notary Salon at
+[KubeCon + CloudNativeCon North America](https://events17.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america/program/schedule).
+The flagship conference of the Cloud Native Computing Foundation was held in
+Austin, Texas, December 6-8, 2017.
+
+**October 24, 2017**
+
+[The Linux Foundation](https://www.linuxfoundation.org/) announced at Open
+Source Summit Europe that TUF would become the
+[latest hosted project](https://www.linuxfoundation.org/cloud-containers-virtualization/cncf-host-two-security-projects-notary-tuf-specification/)
+of the Cloud Native Computing Foundation. TUF and Notary are the first security
+projects to be adopted by CNCF.
+
+**August 10, 2017**
+
+Lukas Pühringer presented the talk "Rough Times? TUF Shines" at
+[DebConf17](https://debconf17.debconf.org/talks/153/), an "annual conference for
+Debian contributors, and users interested in improving Debian."
+The conference took place in Montreal, Canada, August 6-12, 2017.
+
+**July 3, 2017**
+
+Dr. Trishank Karthik Kuppusamy defended his dissertation on TUF and
+[Uptane](https://uptane.github.io). Congratulations! Work on these projects will
+continue as Sebastien, Vlad, Justin, and others move forward!
+
+**May 10, 2017**
+
+Justin Cappos gave a
+[talk](https://ssl.engineering.nyu.edu/blog/2017-04-24-DockerCon) on TUF,
+[Uptane](https://uptane.github.io), and [in-toto](https://in-toto.io/) at
+DockerCon 2017.
+
+**October 10, 2016**
+
+Lily Guo and Riyaz Faizullabhoy from Docker gave a
+[talk](https://linuxconcontainerconeurope2016.sched.org/event/7oI1/software-update-security-when-the-going-gets-tough-get-tuf-going-riyaz-faizullabhoy-lily-guo-docker?iframe=no&w=i:100;&sidebar=yes&bg=no)
+on TUF and Notary at LinuxCon+ContainerCon Europe 2016. Slides of their talk are
+available
+[here](https://schd.ws/hosted_files/linuxconcontainerconeurope2016/50/When%20the%20going%20gets%20tough%2C%20get%20TUF%20going%21%20Linuxcon%20EU.pdf).
+
+**September 22, 2016**
+
+TUF now welcomes proposals to extend the specification! For more information,
+please see
+[TUF Augmentation Proposals (TAPs)](https://github.com/theupdateframework/taps).
+
+**August 24, 2016**
+
+Riyaz Faizullabhoy from Docker gave a
+[talk](https://lcccna2016.sched.org/event/7JWU/when-the-going-gets-tough-get-tuf-going-riyaz-faizullabhoy-docker)
+on TUF and Notary at LinuxCon North America. Slides of his talk are available
+[here](https://events.linuxfoundation.org/events/linuxcon-north-america/program/slides).
+
+**March 18, 2016**
+
+Trishank Kuppusamy presents "Diplomat: Using Delegations to Protect Community
+Repositories" at [NSDI 2016](https://www.usenix.org/conference/nsdi16).
+Presentation [slides and audio](https://www.usenix.org/node/194973) of the talk
+are also available
+
+**February 22, 2016**
+
+David Lawrence and Ying Li from Docker present at PyCon 2016. The title of their
+talk is:
+[When the going gets tough, get TUF going](https://us.pycon.org/2016/schedule/presentation/2187/)
+
+**February 19, 2016**
+
+The Update Framework acquires a logo to call its own, thanks to Maria Jose
+Barrera (https://twitter.com/joseemari) who created the logo, and Santiago
+Torres who found Barrerra.
+
+**August 12, 2015**
+
+The Docker team announces Docker Content Trust, which integrates TUF via
+[Notary](https://github.com/docker/notary). Docker Content Trust will be
+available starting with Docker 1.8, and supports image signing and verification.
+For more information on the Docker + TUF integration, consult
+[this blog post](https://blog.docker.com/2015/08/content-trust-docker-1-8).
+
+## Press
+
+- [Design2Part Magazine-April 2, 2020: Open Source Framework Helps Automakers Secure OTA Updates](https://www.d2pmagazine.com/2020/04/02/6099/)
+
+- [TechCrunch-March 11, 2020: AWS Launches Bottlerocket, a Linux-based OS for Container Hosting](https://techcrunch.com/2020/03/11/aws-launches-bottlerocket-a-linux-based-os-for-container-hosting/)
+
+- [New Jersey 101.5-March 9, 2020: People are Pretty Reluctant to Embrace Self Driving Cars, Survey Says](https://nj1015.com/people-are-pretty-reluctant-to-embrace-self-driving-cars-survey-says/)
+
+- [Python Foundation Blogspot-March 4, 2020: An Update PyPI Funded Work](https://pyfound.blogspot.com/2020/03/an-update-pypi-funded-work.html)
+
+- [S&P Global-January 9, 2020: Wireless Vehicle Updates Pose Big Cybersecurity Risk for Automakers, Consumers](https://www.spglobal.com/marketintelligence/en/news-insights/trending/Xp9n6TEIEmSe8ho9d0jX_Q2)
+
+- [MP3 Monster's Blog-January 4, 2020: Security Vulnerabilities in Solution Deployment](https://blog.mp3monster.org/2020/01/04/security-vulnerabilities-in-solution-deployment/)
+
+- [AV Network-December 27, 2019: Cloud Native Computing Foundation Announces TUF Graduation](https://www.avnetwork.com/news/cloud-native-computing-foundation-announces-tuf-graduation)
+
+- [HelpNet Security.com-December 23, 2019: The Update Framework Graduates from the Linux Foundation’s Cloud Native Computing Foundation](https://www.helpnetsecurity.com/2019/12/23/update-framework-linux-foundation/)
+
+- [Linux Weekly News-December 19, 2019: Cloud Native Computing Foundation Announces TUF Graduation](https://lwn.net/Articles/807777/)
+
+- [DevClass-December 19, 2019: The Update Framework Becomes the Ninth Project to Graduate CNCF](https://devclass.com/2019/12/19/the-update-framework-becomes-ninth-project-to-graduate-cncf/)
+
+- [DevOps-December 18, 2019: CNCF Graduates TUF Project to Secure Software Updates](https://devops.com/cncf-graduates-tuf-project-to-secure-software-updates/)
+
+- [Linux Weekly News-July 24, 2019: Protecting update systems from nation-state attackers](https://lwn.net/Articles/794391/)
+
+- [The Drive.com-July 23, 2019: Top OTA Expert Shows How State Actors Hack into your Car and What Happens Next](https://www.thedrive.com/tech/29120/top-ota-expert-shows-how-state-actors-hack-into-your-car-and-what-happens-next-people-will-die)
+
+- [Just Auto-May 30, 2019: HERE and Uptane Team on automotive/IoT security](https://www.just-auto.com/news/here-and-uptane-team-on-automotiveiot-security_id188912.aspx)
+
+- [Traffic Technology Today-May 29,2019: HERE Technologies Joins the Uptane Alliance](https://www.traffictechnologytoday.com/news/mapping/here-technologies-joins-the-uptane-alliance-for-highly-secure-software-updates.html)
+
+- [TMCnet.com-May 28, 2019: HERE Technologies Joins the Uptane Alliance](https://www.tmcnet.com/usubmit/2019/05/28/8963021.htm)
+
+- [Airbiquity.com-December 13, 2018: Airbiquity Bolsters OTAmatic™ Security And Data Analytic Features In Latest Over-The-Air (OTA) Software And Data Management Offering For Automotive](https://www.airbiquity.com/news/press-releases/airbiquity-bolsters-otamatictm-security-and-data-analytic-features-latest-over-air-ota-software-and-data-management-offering-aut)
+
+- [Auto Cybersecurity Connected Car News-August 19, 2018: Uptane Prevents Attacks](https://www.autoconnectedcar.com/2018/08/automotive-cybersecurity-open-source-ota-crypto-market/)
+
+- [eweek.com-July 13, 2018: How The Update Framework Improves Software Distribution Security](https://www.eweek.com/security/how-the-update-framework-improves-software-distribution-security)
+
+- [eSecurity Planet.com-June 13, 2018: Container and Kubernetes Security: It's Complicated](https://www.esecurityplanet.com/applications/container-and-kubernetes-security.html)
+
+- [Airbiquity.com-January 2018: Airbiquity OTAmatic Named 2017 New Product Of The Year By Business Intelligence Group](https://www.airbiquity.com/news/press-releases/airbiquity-otamatic-named-2017-new-product-year-business-intelligence-group)
+
+- [TechCrunch-October 2017: The Cloud Native Computing Foundation Adds Two Security Projects to its Open Source Stable](https://beta.techcrunch.com/2017/10/24/the-cloud-native-computing-foundation-adds-two-security-projects-to-its-open-source-stable/)
+
+- [Container Journal-October 2017: CNCF Adds 2 Projects to Better Secure Containers](https://containerjournal.com/2017/10/24/cncf-adds-projects-better-secure-containers/)
+
+- [Enterprise Cloud News-October 2017: Cloud Native Computing Foundation Adopts 2 Security Projects](http://www.enterprisecloudnews.com/author.asp?section_id=571&doc_id=737560)
+
+- [The New Stack-October 2017: CNCF Brings Security to the Cloud Native Stack with Notary, TUF Adoption](https://thenewstack.io/cncf-brings-security-cloud-native-stack-notary-tuf-adoption/)
+
+- [Popular Science-October 2017: The Year's Most Important Innovations in Security](https://www.popsci.com/top-security-innovations-2017)
+
+- [eWeek-April 2017: How The Update Framework Improves Security of Software Updates](https://www.eweek.com/security/how-the-update-framework-improves-security-of-software-updates)
+
+- [Python Podcast.init-March 2017: Securing your Software Updates with Justin Cappos-Episode 99, March 2017](https://www.podcastinit.com/episode-99-the-update-framework-with-justin-cappos/)
+
+- [Forbes-January 2017: Uptane Will Protect your Connected Car from Hackers](https://www.forbes.com/sites/.../uptane-will-protect-your-connected-car-from-hackers)
+
+- [Christian Science Monitor-January 2017: Are Software Uodates Key to Stopping Criminal Car Hacks?](https://www.csmonitor.com/World/Passcode/2017/0118/Are-software-updates-key-to-stopping-criminal-car-hacks)
+
+- [YouTube-October 2016: Justin Cappos presents TUF and ongoing work in securing software updates in automobiles and the software supply chain at Docker's Distributed Systems Summit 2016 ](https://www.youtube.com/watch?v=Aryr0O6H_2U&list=PLkA60AVN3hh8oPas3cq2VA9xB7WazcIgs&index=9)
+
+- [Duo Tech Talk-July 2016: Secure Software Distribution in an Adversarial World](https://www.youtube.com/watch?v=OW8NPkSq-3k)
+
+- [The New Stack-August 2015: Docker: With Content Trust, You Can Run Containers on Untrusted Networks](https://thenewstack.io/docker-content-trust-can-run-containers-untrusted-networks/)
+
+- [Notary demoed at the DockerCon 2015 keynote](https://www.ustream.tv/recorded/64499822#t=1h54m0s)
+
+- [LWN.net-January 2015: Docker image "verification"](https://lwn.net/Articles/628343/)
+
+- [PyCon 2015-Poster Presentation](https://us.pycon.org/2015/schedule/presentation/438/)
+
+- [LWN.net-January 2015: Protecting Python package downloads](https://lwn.net/Articles/629426/)
+
+- [Hacker News-December 2014: Incremental Plans to Improve Python Packaging](https://news.ycombinator.com/item?id=8780369)
+
+- [Titanous.com blog-December 2014: Docker Image Insecurity](https://titanous.com/posts/docker-insecurity)
+
+- [The Linux Magazine-March 2014: TUF Love](https://www.linux-magazine.com/Issues/2014/160/Security-Lessons-TUF)
+
+- [Promotional materials on TUF (The Update Framework) w/ Justin Cappos and Trishank Kuppusamy](https://vimeo.com/88774074)
+
+- [Slashdot: Package Managers As Achilles Heel](https://it.slashdot.org/story/08/07/10/227220/package-managers-as-achilles-heel)
diff --git a/content/en/resources/publications.md b/content/en/resources/publications.md
new file mode 100644
index 0000000..3121272
--- /dev/null
+++ b/content/en/resources/publications.md
@@ -0,0 +1,17 @@
+---
+title: Publications
+---
+
+The following papers provide detailed information on securing software updater
+systems, TUF's design, attacks on package managers, and package management
+security:
+
+- [Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against Community Repositories](/static/papers/prevention-rollback-attacks-atc2017.pdf)
+
+- [Diplomat: Using Delegations to Protect Community Repositories](/static/papers/protect-community-repositories-nsdi2016.pdf)
+
+- [Survivable Key Compromise in Software Update Systems](/static/papers/survivable-key-compromise-ccs2010.pdf)
+
+- [A Look In the Mirror: Attacks on Package Managers](/static/papers/attacks-on-package-managers-ccs2008.pdf)
+
+- [Package Management Security](/papers/package-management-security-tr08-02.pdf)
diff --git a/content/videos.md b/content/en/resources/videos.md
similarity index 83%
rename from content/videos.md
rename to content/en/resources/videos.md
index 06917d2..18c4f72 100644
--- a/content/videos.md
+++ b/content/en/resources/videos.md
@@ -1,10 +1,9 @@
---
title: Videos
+description:
+ Sample videos of presentations given by project members and adopters.
---
-The following are sample videos of presentations that have been given by
-project members and adopters.
-
## TUF-en Up Your Signatures
{{< youtube "8sUqo36IVio" >}}
diff --git a/content/en/search.md b/content/en/search.md
new file mode 100644
index 0000000..394feea
--- /dev/null
+++ b/content/en/search.md
@@ -0,0 +1,4 @@
+---
+title: Search Results
+layout: search
+---
diff --git a/content/en/specifications/specs.md b/content/en/specifications/specs.md
new file mode 100644
index 0000000..c76ade9
--- /dev/null
+++ b/content/en/specifications/specs.md
@@ -0,0 +1,31 @@
+---
+title: Specification
+linkTitle: Spec
+menu: { main: { weight: 35 } }
+cascade:
+ type: docs
+---
+
+The following specification versions are available:
+
+- [latest](https://theupdateframework.github.io/specification/latest/index.html)
+- [draft](https://theupdateframework.github.io/specification/draft/index.html)
+- [v1.0.33](https://theupdateframework.github.io/specification/v1.0.33/index.html)
+- [v1.0.32](https://theupdateframework.github.io/specification/v1.0.32/index.html)
+- [v1.0.31](https://theupdateframework.github.io/specification/v1.0.31/index.html)
+- [v1.0.30](https://theupdateframework.github.io/specification/v1.0.30/index.html)
+- [v1.0.29](https://theupdateframework.github.io/specification/v1.0.29/index.html)
+- [v1.0.28](https://theupdateframework.github.io/specification/v1.0.28/index.html)
+- [v1.0.27](https://theupdateframework.github.io/specification/v1.0.27/index.html)
+- [v1.0.26](https://theupdateframework.github.io/specification/v1.0.26/index.html)
+- [v1.0.25](https://theupdateframework.github.io/specification/v1.0.25/index.html)
+- [v1.0.24](https://theupdateframework.github.io/specification/v1.0.24/index.html)
+- [v1.0.23](https://theupdateframework.github.io/specification/v1.0.23/index.html)
+- [v1.0.22](https://theupdateframework.github.io/specification/v1.0.22/index.html)
+- [v1.0.20](https://theupdateframework.github.io/specification/v1.0.20/index.html)
+- [v1.0.19](https://theupdateframework.github.io/specification/v1.0.19/index.html)
+- [v1.0.18](https://theupdateframework.github.io/specification/v1.0.18/index.html)
+- [v1.0.17](https://theupdateframework.github.io/specification/v1.0.17/index.html)
+
+This list is also available from
+[Spec versions](https://theupdateframework.github.io/specification/).
diff --git a/content/faq.md b/content/faq.md
deleted file mode 100644
index a12eef9..0000000
--- a/content/faq.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-title: Frequently Asked Questions
----
-
-**1. How difficult is it to integrate TUF?**
-
- At a high level, all an adopter needs to do is (1) add TUF metadata to its
- software repository, and (2) arrange for clients to use TUF to fetch files
- from the repository before transferring the verified files to the software
- update system.
-
- In practice, (1) will also require the adopter to decide how to make the
- metadata and delegations available to clients, how to manage the keys needed
- to sign TUF metadata (in particular, how to generate, securely store or backup,
- and rotate offline keys), and how to periodically update and re-sign metadata.
-
- For (2), an adopter has to figure out how to ship the initial Root file, and
- implement [the TUF download and verification
- workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow)
- in their language of choice if one of the existing implementations is
- insufficient.
-
-**2. Why should I use delegations?**
-
- Using delegations makes it so that users can perform actions for one another
- without needing to share keys in order to make this happen.
- As we state in the specification: "Delegated roles can further delegate trust
- to other delegated roles. This provides for multiple levels of trust
- delegation where each role can delegate full or partial trust for the target
- files they are trusted for." Delegations add more security. For instance, in
- a community repository like PyPI, delegating trust for target files to a
- project developer is recommended. It increases compromise-resilience because
- if the developers control their own project keys, an attacker cannot access
- them, and therefore cannot sign and serve malicious versions of the project.
-
-**3. What happens if the server and keys are compromised?**
-
- The repo maintainer must revoke and replace compromised keys. If a Timestamp,
- Snapshot, Targets, or Root key is compromised, the Root role must re-sign its
- metadata to replace the compromised key. If a threshold of Root keys is
- compromised, the Root file must be re-issued out of band. If a threshold
- number of offline keys are required, a full compromise of the repo is
- unlikely. For a more in-depth discussion about the steps to follow in the
- event of a key compromise, see [PEP
- 458](https://www.python.org/dev/peps/pep-0458/#in-the-event-of-a-key-compromise),
- which covers one way to deal with compromised keys on a community repo such
- as PyPI.
-
-**4. Can I use the same keys for different roles?**
-
- In general, you shouldn't share keys. In certain cases, even sharing online
- keys (e.g., between the Timestamp and Snapshot roles) is not advised. As we
- recommend for the PyPI community, "different keys for online roles allow for
- each of the keys to be placed on separate servers if need be, and prevents
- side channel attacks that compromise one key from automatically compromising
- the rest of the keys."
-
-**5. Which roles can use online keys?**
-
- The Timestamp and Snapshot roles can use online keys to facilitate continuous
- delivery of updates on the typical repository. All other roles should rely on
- offline keys to prevent attackers from signing for malicious packages in the
- event of a repo compromise.
-
-**6. What is the point of having the Root and Snapshot roles?**
-
- The Root role keeps track of the trusted public keys of the top-level roles,
- and can remove or add keys when needed. Its metadata is rarely updated and
- its signing keys must receive the greatest protection. In contrast, the
- Snapshot role is updated often, signed with an online key, and provides a
- consistent view of the metadata available on a repo. The Snapshot and Root
- role are responsible for different tasks that differ in level of importance.
- Separation of responsibilities is one of TUF's design choices.
-
-**7. Can you combine Timestamp and Snapshot?**
-
- There are a few reasons why the Timestamp and Snapshot files are not
- combined:
-
- * The Timestamp file is downloaded very frequently and so should be
- kept as small as possible, especially considering that the Snapshot file will
- grow proportionally with the number of delegated target roles.
-
- * As the Timestamp role’s key is an online key and thus at high risk,
- when an offline key storage is appropriate for Snapshot, separate keys should
- be used so that the Snapshot role’s keys can be kept offline, and thus in a
- more secure manner.
-
- * When rotating keys, it makes much more sense to rotate Timestamp
- frequently. When Timestamp is rotated, if an attacker compromises the new
- key, they can launch a freeze attack for a short while. For Snapshot, an
- attacker could cause clients to invalidate a lot of their stored targets
- metadata, which may result in re-retrieval of a substantial amount of
- information from the repository. So, it is recommended to rotate Timestamp
- more often.
-
- * Timestamp may be given to mirrors.
-
-**8. How often should metadata expire?**
-
- The Timestamp and Snapshot metadata should normally have a short expiration
- (1 day), whereas the Root and Targets metadata should expire less often (1
- year). A good rule of thumb is the more often the metadata changes, the
- sooner it should expire.
-
-**9. Are there ways to reduce bandwidth costs?**
-
- It is possible to minimize the size and number of delegated metadata that the
- client has to download, and in doing so, reduce the associated costs. The
- [Metadata Scalability
- section](https://www.python.org/dev/peps/pep-0458/#metadata-scalability) of
- PEP 458 discusses in more detail the ways in which to reduce bandwidth costs.
- For example, if one large metadata file is split into several smaller ones,
- the bandwidth associated with downloading the large file many times can be
- saved. The reference implementation provides an [easy way to distribute
- target files across many targets
- metadata](https://github.com/theupdateframework/python-tuf/blob/v0.20.0/examples/repo_example/hashed_bin_delegation.py)
- (i.e., delegating to hashed bins), which the specification refers to as [path
- hash
- prefixes](https://theupdateframework.github.io/specification/latest/#path_hash_prefixes).
-
-**10. Can TUF be used with devices that lack the CPU power or memory to
- verify metadata?**
-
- At a minimum, a client device must be able to verify the hashes and
- signatures on TUF metadata. If a device isn't powerful enough to perform
- cryptographic operations or has limited memory, it can delegate verification
- of hashes and signatures to another device. For instance, a weaker device can
- rely on another device on the network to verify the signatures on top-level
- metadata. Delegating to another device is not built into the framework but
- [Uptane](https://uptane.github.io/), a variant of TUF, is designed to work
- with weaker devices like the Electronic Control Units found in automobiles.
-
-**11. Can I use TUF to download files from more than one repository?**
-
- TUF can download files from multiple mirrors and repos. In fact, we offer
- guidance for conducting a secure search for files across multiple
- repositories in [TAP
- 4](https://github.com/theupdateframework/taps/blob/master/tap4.md).
-
-**12. Has there been a security audit of TUF?**
-
- The [Security Audits](/audits) page links to a few of the security audits of
- TUF.
-
-**13. How can I try TUF?**
-
- The `python-tuf` reference implementation provides a [well-documented
- API](https://theupdateframework.readthedocs.io/en/latest/api/api-reference.html)
- to create and manage TUF metadata on a server-side repository, and to perform
- TUF-compliant updates on a client, as well as basic Python [code
- examples](https://github.com/theupdateframework/python-tuf/tree/develop/examples)
- that demonstrate the usage.
-
-**14. Is there a presentation or video about TUF?**
-
- The [Videos](/videos) page contains links to presentations that have been
- given by both TUF developer personnel, as well as adopters.
-
diff --git a/content/history.md b/content/history.md
deleted file mode 100644
index f65d156..0000000
--- a/content/history.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: History and core principles
----
-
-The basic technology behind TUF was developed at the University of Washington
-in 2009 by Justin Samuel and Justin Cappos, and presented
-in a [paper](https://theupdateframework.github.io/papers/survivable-key-compromise-ccs2010.pdf?raw=true)
-Samuel and Cappos coauthored with Nick Mathewson and Roger
-Dingledine, researchers from [The Tor Project,
-Inc](https://www.torproject.org/). Since 2011, TUF has been based at [New York
-University Tandon School of Engineering](https://engineering.nyu.edu/), where
-Cappos is a tenured associate professor of computer science and engineering.
-There he works with a team of Ph.D. students, including Trishank Karthik Kuppusamy,
-who graduated in 2017, and developers,
-including Vladimir Diaz and Sebastien Awwad, to supervise the development of
-TUF and its adoption and integration by open source non-profits and tech companies.
-
-Though TUF technologies have been customized to meet end-user specifications,
-four core principles continue to be central to its design.
-
-* The first is separation of responsibilities for signing metadata, which means
-one compromised key does not automatically compromise all repository users.
-
-* The second specifies a fixed number of signatures agreeing to the authenticity
-of what is presented in the metadata that accompanies an update before the
-server will download it.
-
-* A third principle works to help a repository to recover quickly from a
-compromise by providing an automatic way to revoke signing keys. By doing so,
-hackers can not sign metadata to authenticate malware.
-
-* Lastly, TUF keeps the most vulnerable signing keys offline, which greatly
-reduces the risk that they can be stolen or compromised.
-
-In 2016, the TUF research group set up a process whereby the community could
-have input on technical issues. Named the TUF Augmentation Proposal, or TAP,
-this series of documents also provide information to the TUF community, or
-describe new feature for TUF or its processes or environment. Through the use
-of TAPs, as well as input from those who adopted the technology, the evolution
-of TUF technology can continue as security needs change.
diff --git a/content/implementations.md b/content/implementations.md
deleted file mode 100644
index c7c929b..0000000
--- a/content/implementations.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Implementations
----
-
-TUF provides a framework for integration of the [security](/security)
-properties into new and existing content delivery systems.
-
-While some [adoptions](/adoptions) integrate TUF by implementing the framework
-from scratch, others start from either a TUF [implementation](#implementations)
-or from a TUF [system](#systems).
-
-This page lists open source implementations of TUF which can be used as
-building blocks for any TUF adoption.
-
-## Implementations
-
-TUF implementations provide libraries implementing the primitives and algorithms, such as the detailed client workflow, in the specification.
-
-* [python-tuf](https://github.com/theupdateframework/python-tuf), the reference
- implementation
-* [go-tuf](https://github.com/theupdateframework/go-tuf/)
-* [tuf-js](https://github.com/theupdateframework/tuf-js)
-
-## Systems
-
-TUF systems build on top of library implementations and provide opinionated
-signing systems designed for particular use-cases.
-
-* [Repository Service for TUF (RSTUF)
-](https://repository-service-tuf.readthedocs.io/en/stable/) is a TUF
-repository designed to integrate into an existing artifact repository with an
-established storage and delivery system.
-* [tuf-on-ci](https://github.com/theupdateframework/tuf-on-ci/) is a TUF
-repository and signing tool designed to operate on a CI system and guide
-signing events through Git forge workflows.
diff --git a/content/metadata.md b/content/metadata.md
deleted file mode 100644
index fd4705c..0000000
--- a/content/metadata.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: Roles and metadata
----
-
-TUF uses roles to define the set of actions a party can perform. The concept of
-roles allows TUF to only trust information provided by the correctly
-designated party. The root role indicates which roles can sign for which projects.
-
-The roles sign metadata, which TUF uses to create verifiable records about the state
-of a repository or application at a specified time. As such, clients can use
-it to make decisions on which files to update. Different metadata files provide
-different information, and will be signed by different roles.
-
-The signed metadata files always include an expiration date. This ensures
-that outdated metadata will be detected and that
-clients can refuse to accept metadata older than that which they've already seen.
-
-Implementers of TUF may use any data format for metadata files. The examples
-here use a subset of the JSON object format. When calculating the
-digest of an object, we use the [Canonical JSON](http://wiki.laptop.org/go/Canonical_JSON) format. Implementation-level detail about the metadata can be found in the [spec](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md).
-
-There are four required top-level roles, each with their own metadata file.
-
-Required:
-
-* Root
-* Targets
-* Snapshot
-* Timestamp
-
-Optional:
-
-There may also be any number of delegated target roles.
-
-## Root Metadata (root.json)
-
-Signed by: Root role.
-
-Specifies the other top-level roles. When specifying these roles, the trusted
-keys for each are listed, along with the minimum number of those keys required
-to sign the role's metadata. We call this number the signature threshold.
-
-See [example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/root.json) of Root metadata.
-
-## Targets Metadata (targets.json)
-
-Signed by: Targets role.
-
-Target files are the actual files that clients want to download, such as
-the software updates they are trying to obtain. The targets.json metadata
-file lists hashes and sizes of target files.
-
-This file can optionally define other roles to which it delegates trust,
-or specify that another role is to be trusted for some or all of the target files
-available from the repository. When delegated roles are specified, it is done
-so in a way similar to how the Root role specifies the top-level roles: by giving
-the trusted keys and signature threshold for each role. Additionally, one or more
-[glob patterns](https://en.wikipedia.org/wiki/Glob_(programming)) will be specified to indicate the target file paths for which clients should trust each delegated role.
-
-See [example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/targets.json) of Targets metadata.
-
-## Delegated Targets Metadata (role1.json)
-
-Signed by: A delegated targets role.
-
-A metadata file provided by a Delegated Targets role will follow exactly the same
-format as one provided by the top-level Targets role.
-
-When the Targets role delegates trust to other roles, each delegated role will
-provide one signed metadata file. As is the
-case with the directory structure of top-level metadata, the delegated files are
-relative to the base URL of metadata available from a given repository mirror.
-
-A delegated role file is located at:
-
-/DELEGATED_ROLE.json
-
-where DELEGATED_ROLE is the name of the role specified in targets.json. If this
-role further delegates trust to a role named ANOTHER_ROLE, that role's signed
-metadata file would be found at:
-
-/ANOTHER_ROLE.json
-
-See
-[example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/role1.json)
-of delegated Targets metadata and [example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/role2.json) of a nested delegation.
-
-## Snapshot Metadata (snapshot.json)
-
-Signed by: Snapshot role.
-
-The snapshot.json metadata file lists version numbers of all metadata files
-other than timestamp.json. This file ensures that clients will see a consistent
-view of all files on the repository. That is, metadata files (and thus Target
-files) that existed on the repository at different times cannot be combined
-and presented to clients by an attacker.
-
-See [example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/snapshot.json) of Snapshot metadata.
-
-## Timestamp Metadata (timestamp.json)
-
-Signed by: Timestamp role.
-
-The timestamp.json metadata file lists the hashes and size of the snapshot.json file.
-This is the first and potentially only file that needs to be downloaded when
-clients search for updates. It is frequently re-signed, and
-has a short expiration date, thus allowing clients to quickly detect if they are
-being prevented from obtaining the most recent metadata. An online key is
-generally used to automatically re-sign this file at regular intervals.
-
-There are a few reasons why the timestamp.json and snapshot.json files are not
-combined:
-
-* The timestamp.json file is downloaded very frequently and so should be kept as
-small as possible, especially considering that the snapshot.json file grows
-proportionally with the number of delegated target roles.
-* As the Timestamp role's key is an online key and thus at high risk, separate
-keys should be used for signing the snapshot.json file so that the
-Snapshot role's keys can be kept offline, and thus more secure.
-* Timestamp.json may be given to mirrors.
-
-See [example](https://raw.githubusercontent.com/theupdateframework/tuf/develop/tests/repository_data/repository/metadata/timestamp.json) of Timestamp metadata.
diff --git a/content/news.md b/content/news.md
deleted file mode 100644
index e4e0cf9..0000000
--- a/content/news.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-title: News
----
-
-> The [press](/press) page contains a full listing of news coverage.
-
-**June 16, 2021**
-
-The Sigstore community live-streamed a [key generation and signing ceremony
-](https://www.cncf.io/blog/2021/06/16/a-new-kind-of-trust-root/) for the
-Sigstore trust root, which is using The Update Framework (TUF) primitives to
-provide a PKI model with no single entity in charge of the trust root, and
-shorter root key lifespan than traditional PKI models.
-
-**March 5, 2021**
-
-The [TUF specification](https://theupdateframework.github.io/specification/latest/index.html)
-is now published as a rich HTML document with a table of contents, syntax
-highlighting, cross-linking, and other features.
-
-The new publication machinery also maintains a [list of all versions
-](https://theupdateframework.github.io/specification/) published since the
-format change.
-
-**October 30, 2020**
-
-The Python Software Foundation live-streams a [key generation and signing ceremony](https://www.youtube.com/watch?v=jjAq7S49eow&t=3078s) that marks the first practical steps in deploying The Update Framework (TUF) to the [Python Package Index](pypi.org).
-
-**February 15, 2020**
-
-[PEP 458](https://www.python.org/dev/peps/pep-0458/), Secure PyPI Downloads with Package Signing, is accepted and merged into the Python Enhancement Proposals (PEP) tree.
-
-**December 19, 2019**
-
-TUF becomes the [first project](https://engineering.nyu.edu/news/open-source-system-secure-software-updates-graduates-protect-leading-cloud-services) led by an academic and the first specification-based project to graduate from the [Cloud Native Computing Foundation](https://www.cncf.io/).
-
-**August 2019**
-
-Uptane becomes joins the [Linux Foundation's Joint Development Foundation](https://www.jointdevelopment.org/), giving
-a pathway for ISO standardization of future versions of the specification.
-
-**July 31, 2019**
-
-The IEEE/ISTO standardizes [version 1.0.0 of the Uptane specification](https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html).
-
-**June 3, 2019**
-
-Trishank Kuppusamy publishes a [blog post](https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/) announcing the integration of both TUF and a related framework, called [in-toto](https://in-toto.io/), into [Datadog Agent Integrations](https://docs.datadoghq.com/getting_started/integrations/).
-
-**August 16, 2018**
-
-[NYU Tandon School of Engineering](https://engineering.nyu.edu/) becomes an associate member of the
-[Linux Foundation](https://www.linuxfoundation.org/) and a Bronze member of [Automotive Grade Linux](https://www.automotivelinux.org/) on the strength of the Foundation’s adoption of Uptane and TUF projects.
-
-
-**July 31, 2018**
-
-The Uptane Alliance, a nonprofit entity organized under the umbrella of
-IEEE's [International Standards and Technology Organization](https://ieee-isto.org/) is formed.
-The Alliance was tasked with overseeing the setting of standards for the implementation/deployment of Uptane, as well as the advancement and improvement of the technology itself.
-
-**January 25, 2018**
-
-[Airbiquity](https://www.airbiquity.com) receives a [BIG Award for Business](https://www.airbiquity.com/news/press-releases/airbiquity-otamatic-named-2017-new-product-year-business-intelligence-group) in the 2017 New Product of the Year Award category for its
-Uptane-based OTAmatic over-the-air software and data management solution.
-
-**December 7, 2017**
-
-Justin Cappos and David Lawrence, senior security engineer at Docker, jointly
-chaired the TUF/Notary Salon at [KubeCon + CloudNativeCon North America](https://events17.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america/program/schedule). The flagship conference of the Cloud Native Computing Foundation
-was held in Austin, Texas, December 6-8, 2017.
-
-**October 24, 2017**
-
-[The Linux Foundation](https://www.linuxfoundation.org/) announced at Open Source
-Summit Europe that TUF would become the [latest hosted project](https://www.linuxfoundation.org/cloud-containers-virtualization/cncf-host-two-security-projects-notary-tuf-specification/) of the Cloud Native Computing Foundation.
-TUF and Notary are the first security projects to be adopted by CNCF.
-
-
-**August 10, 2017**
-
-Lukas Pühringer presented the talk "Rough Times? TUF Shines" at [DebConf17](https://debconf17.debconf.org/talks/153/), an "annual conference for Debian contributors, and users interested in improving Debian."
-The conference took place in Montreal, Canada, August 6-12, 2017.
-
-
-**July 3, 2017**
-
-Dr. Trishank Karthik Kuppusamy defended his dissertation on TUF and
-[Uptane](https://uptane.github.io). Congratulations! Work on these projects
-will continue as Sebastien, Vlad, Justin, and others move forward!
-
-**May 10, 2017**
-
-Justin Cappos gave a
-[talk](https://ssl.engineering.nyu.edu/blog/2017-04-24-DockerCon) on TUF,
-[Uptane](https://uptane.github.io), and [in-toto](https://in-toto.io/) at
-DockerCon 2017.
-
-**October 10, 2016**
-
-Lily Guo and Riyaz Faizullabhoy from Docker gave a
-[talk](https://linuxconcontainerconeurope2016.sched.org/event/7oI1/software-update-security-when-the-going-gets-tough-get-tuf-going-riyaz-faizullabhoy-lily-guo-docker?iframe=no&w=i:100;&sidebar=yes&bg=no)
-on TUF and Notary at LinuxCon+ContainerCon Europe 2016. Slides of their talk
-are available
-[here](https://schd.ws/hosted_files/linuxconcontainerconeurope2016/50/When%20the%20going%20gets%20tough%2C%20get%20TUF%20going%21%20Linuxcon%20EU.pdf).
-
-**September 22, 2016**
-
-TUF now welcomes proposals to extend the specification! For more information,
-please see [TUF Augmentation Proposals
-(TAPs)](https://github.com/theupdateframework/taps).
-
-**August 24, 2016**
-
-Riyaz Faizullabhoy from Docker gave a
-[talk](https://lcccna2016.sched.org/event/7JWU/when-the-going-gets-tough-get-tuf-going-riyaz-faizullabhoy-docker)
-on TUF and Notary at LinuxCon North America. Slides of his talk are available
-[here](https://events.linuxfoundation.org/events/linuxcon-north-america/program/slides).
-
-**March 18, 2016**
-
-Trishank Kuppusamy presents "Diplomat: Using Delegations to Protect Community
-Repositories" at [NSDI 2016](https://www.usenix.org/conference/nsdi16). Presentation
-[slides and audio](https://www.usenix.org/node/194973) of the talk are also available
-
-
-**February 22, 2016**
-
-David Lawrence and Ying Li from Docker present at PyCon 2016. The title
-of their talk is: [When the going gets tough, get TUF going](https://us.pycon.org/2016/schedule/presentation/2187/)
-
-**February 19, 2016**
-
-The Update Framework acquires a logo to call its own, thanks to Maria
-Jose Barrera (https://twitter.com/joseemari) who created the logo, and
-Santiago Torres who found Barrerra.
-
-
-**August 12, 2015**
-
-The Docker team announces Docker Content Trust, which
-integrates TUF via [Notary](https://github.com/docker/notary). Docker
-Content Trust will be available starting with Docker 1.8, and supports image
-signing and verification. For more information on the Docker + TUF
-integration, consult [this blog post](https://blog.docker.com/2015/08/content-trust-docker-1-8).
diff --git a/content/overview.md b/content/overview.md
deleted file mode 100644
index f0f0662..0000000
--- a/content/overview.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: Overview
----
-
-A quick look at what TUF does and how it works.
-
-### Purpose, or Why Get TUF?
-
-There are literally thousands of different software update systems in common
-use today.
-
-What these very different systems have in common is that they all identify,
-locate, and download updates for software that can add new functionalities or
-address old vulnerabilities. Software is rarely ever static, and some repositories
-receive updates on software or project metadata [every few minutes](/papers/protect-community-repositories-nsdi2016.pdf). This
-growing flow of updates has also created a need for better
-ways to protect the systems that manage them. Though a number of strategies have
-been introduced and used over the last decade or so to enhance the
-authenticity of update files—and by extension, the security of update systems—most have drawbacks
-that have left repositories vulnerable to a number of attacks.
-
-TUF was launched almost a decade ago as a way to build system resilience against
-key compromises and other attacks that can spread malware or compromise a repository.
-The primary goals behind its design are:
-
-* to provide a framework (a set of libraries, file formats, and utilities)
-that can be used to secure new and existing software update systems.
-
-* to provide the means to minimize the impact of key compromises.
-
-* to be flexible enough to meet the needs of a wide variety of software update systems.
-
-* to be easy to integrate with existing software update systems.
-
-### Software Updates 101 ###
-A software update system is an application (or part of an
-application) running on a client system that identifies, obtains, and
-installs software.
-
-There are three major classes of software update systems:
-
-* **Application updaters** internal updaters that allow an application to update
- itself. For example, Firefox updates itself through its own application
- updater.
-
-* **Library package managers** offered by many
- programming languages for installing additional libraries. Examples include
- Python's pip/easy_install + PyPI, Perl's CPAN,
- Ruby's RubyGems, and PHP's Composer.
-
-* **System package managers** used by operating systems to update and
- install software on a client system. Examples include Debian's APT,
- Red Hat's YUM and openSUSE's YaST.
-
-While these systems may vary in how they work, most follow a similar update
-procedure. Obtaining and installing an update simply means:
-
-* Knowing when an update exists.
-* Downloading the update.
-* Applying the changes introduced by the update.
-
-TUF is designed to perform the first two steps of this procedure,
-while guarding against the majority of attacks that can occur during or
-after the update.
-These include threats that other software security strategies may not take into
-account, such as when:
-
-* An attacker keeps giving you the same file, so you never realize
- there is an update.
-
-* An attacker gives you an older, insecure version of a file that you
- already have and tricks you into thinking it's
- newer. You download it and blindly use it.
-
-* An attacker gives you a newer version of a file you have but it's still not
- the *newest* one. It's newer to you, but it may be insecure and
- exploitable by the attacker.
-
-* An attacker compromises the key used to sign these files. Now you
- download a file that is properly signed, but is still malicious.
-
-The [Security](/security.html) section offers a full list of the
-attacks and updater weaknesses that TUF is designed to defend against.
-
-### How does TUF secure updates? ###
-
-In a sense, TUF enhances security by adding verifiable records about the state
-of a repository or application. By adding metadata containing
-information about which signing keys are trusted, the cryptographic hashes of
-files, signatures on the metadata,
-metadata version numbers, and the date after which the metadata should be
-considered expired, it creates a record that can be checked to verify the
-authenticity of update files.
-
-Your software update system never has to deal with
-this additional metadata or understand what's going on underneath. TUF
-identifies the updates, downloads them, and checks them
-against the metadata that it also downloads from the repository. If the
-downloaded target files are trustworthy, TUF hands them over to your software
-update system. See [metadata](/metadata.html) for more information and examples.
diff --git a/content/press.md b/content/press.md
deleted file mode 100644
index 808a933..0000000
--- a/content/press.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Press
----
-
-* [Design2Part Magazine-April 2, 2020: Open Source Framework Helps Automakers Secure OTA Updates](https://www.d2pmagazine.com/2020/04/02/6099/)
-
-* [TechCrunch-March 11, 2020: AWS Launches Bottlerocket, a Linux-based OS for Container Hosting](https://techcrunch.com/2020/03/11/aws-launches-bottlerocket-a-linux-based-os-for-container-hosting/)
-
-* [New Jersey 101.5-March 9, 2020: People are Pretty Reluctant to Embrace Self Driving Cars, Survey Says](https://nj1015.com/people-are-pretty-reluctant-to-embrace-self-driving-cars-survey-says/)
-
-* [Python Foundation Blogspot-March 4, 2020: An Update PyPI Funded Work](https://pyfound.blogspot.com/2020/03/an-update-pypi-funded-work.html)
-
-* [S&P Global-January 9, 2020: Wireless Vehicle Updates Pose Big Cybersecurity Risk for Automakers, Consumers](https://www.spglobal.com/marketintelligence/en/news-insights/trending/Xp9n6TEIEmSe8ho9d0jX_Q2)
-
-* [MP3 Monster's Blog-January 4, 2020: Security Vulnerabilities in Solution Deployment](https://blog.mp3monster.org/2020/01/04/security-vulnerabilities-in-solution-deployment/)
-
-* [AV Network-December 27, 2019: Cloud Native Computing Foundation Announces TUF Graduation](https://www.avnetwork.com/news/cloud-native-computing-foundation-announces-tuf-graduation)
-
-* [HelpNet Security.com-December 23, 2019: The Update Framework Graduates from the Linux Foundation’s Cloud Native Computing Foundation](https://www.helpnetsecurity.com/2019/12/23/update-framework-linux-foundation/)
-
-* [Linux Weekly News-December 19, 2019: Cloud Native Computing Foundation Announces TUF Graduation](https://lwn.net/Articles/807777/)
-
-* [DevClass-December 19, 2019: The Update Framework Becomes the Ninth Project to Graduate CNCF](https://devclass.com/2019/12/19/the-update-framework-becomes-ninth-project-to-graduate-cncf/)
-
-* [DevOps-December 18, 2019: CNCF Graduates TUF Project to Secure Software Updates](https://devops.com/cncf-graduates-tuf-project-to-secure-software-updates/)
-
-* [Linux Weekly News-July 24, 2019: Protecting update systems from nation-state attackers](https://lwn.net/Articles/794391/)
-
-* [The Drive.com-July 23, 2019: Top OTA Expert Shows How State Actors Hack into your Car and What Happens Next](https://www.thedrive.com/tech/29120/top-ota-expert-shows-how-state-actors-hack-into-your-car-and-what-happens-next-people-will-die)
-
-* [Just Auto-May 30, 2019: HERE and Uptane Team on automotive/IoT security](https://www.just-auto.com/news/here-and-uptane-team-on-automotiveiot-security_id188912.aspx)
-
-* [Traffic Technology Today-May 29,2019: HERE Technologies Joins the Uptane Alliance](https://www.traffictechnologytoday.com/news/mapping/here-technologies-joins-the-uptane-alliance-for-highly-secure-software-updates.html)
-
-* [TMCnet.com-May 28, 2019: HERE Technologies Joins the Uptane Alliance](https://www.tmcnet.com/usubmit/2019/05/28/8963021.htm)
-
-* [Airbiquity.com-December 13, 2018: Airbiquity Bolsters OTAmatic™ Security And Data Analytic Features In Latest Over-The-Air (OTA) Software And Data Management Offering For Automotive](https://www.airbiquity.com/news/press-releases/airbiquity-bolsters-otamatictm-security-and-data-analytic-features-latest-over-air-ota-software-and-data-management-offering-aut)
-
-* [Auto Cybersecurity Connected Car News-August 19, 2018: Uptane Prevents Attacks](https://www.autoconnectedcar.com/2018/08/automotive-cybersecurity-open-source-ota-crypto-market/)
-
-* [eweek.com-July 13, 2018: How The Update Framework Improves Software Distribution Security](https://www.eweek.com/security/how-the-update-framework-improves-software-distribution-security)
-
-* [eSecurity Planet.com-June 13, 2018: Container and Kubernetes Security: It's Complicated](https://www.esecurityplanet.com/applications/container-and-kubernetes-security.html)
-
-* [Airbiquity.com-January 2018: Airbiquity OTAmatic Named 2017 New Product Of The Year By Business Intelligence Group](https://www.airbiquity.com/news/press-releases/airbiquity-otamatic-named-2017-new-product-year-business-intelligence-group)
-
-* [TechCrunch-October 2017: The Cloud Native Computing Foundation Adds Two Security Projects to its Open Source Stable](https://beta.techcrunch.com/2017/10/24/the-cloud-native-computing-foundation-adds-two-security-projects-to-its-open-source-stable/)
-
-* [Container Journal-October 2017: CNCF Adds 2 Projects to Better Secure Containers](https://containerjournal.com/2017/10/24/cncf-adds-projects-better-secure-containers/)
-
-* [Enterprise Cloud News-October 2017: Cloud Native Computing Foundation Adopts 2 Security Projects](http://www.enterprisecloudnews.com/author.asp?section_id=571&doc_id=737560)
-
-* [The New Stack-October 2017: CNCF Brings Security to the Cloud Native Stack with Notary, TUF Adoption](https://thenewstack.io/cncf-brings-security-cloud-native-stack-notary-tuf-adoption/)
-
-* [Popular Science-October 2017: The Year's Most Important Innovations in Security](https://www.popsci.com/top-security-innovations-2017)
-
-* [eWeek-April 2017: How The Update Framework Improves Security of Software Updates](https://www.eweek.com/security/how-the-update-framework-improves-security-of-software-updates)
-
-* [Python Podcast.init-March 2017: Securing your Software Updates with Justin Cappos-Episode 99, March 2017](https://www.podcastinit.com/episode-99-the-update-framework-with-justin-cappos/)
-
-* [Forbes-January 2017: Uptane Will Protect your Connected Car from Hackers](https://www.forbes.com/sites/.../uptane-will-protect-your-connected-car-from-hackers)
-
-* [Christian Science Monitor-January 2017: Are Software Uodates Key to Stopping
-Criminal Car Hacks?](https://www.csmonitor.com/World/Passcode/2017/0118/Are-software-updates-key-to-stopping-criminal-car-hacks)
-
-* [YouTube-October 2016: Justin Cappos presents TUF and ongoing work in securing software updates in automobiles and the software supply chain at Docker's Distributed Systems Summit 2016 ](https://www.youtube.com/watch?v=Aryr0O6H_2U&list=PLkA60AVN3hh8oPas3cq2VA9xB7WazcIgs&index=9)
-
-* [Duo Tech Talk-July 2016: Secure Software Distribution in an Adversarial World](https://www.youtube.com/watch?v=OW8NPkSq-3k)
-
-* [The New Stack-August 2015: Docker: With Content Trust, You Can Run Containers on Untrusted Networks](https://thenewstack.io/docker-content-trust-can-run-containers-untrusted-networks/)
-
-* [Notary demoed at the DockerCon 2015 keynote](https://www.ustream.tv/recorded/64499822#t=1h54m0s)
-
-* [LWN.net-January 2015: Docker image "verification"](https://lwn.net/Articles/628343/)
-
-* [PyCon 2015-Poster Presentation](https://us.pycon.org/2015/schedule/presentation/438/)
-
-* [LWN.net-January 2015: Protecting Python package downloads](https://lwn.net/Articles/629426/)
-
-* [Hacker News-December 2014: Incremental Plans to Improve Python Packaging](https://news.ycombinator.com/item?id=8780369)
-
-* [Titanous.com blog-December 2014: Docker Image Insecurity](https://titanous.com/posts/docker-insecurity)
-
-* [The Linux Magazine-March 2014: TUF Love](https://www.linux-magazine.com/Issues/2014/160/Security-Lessons-TUF)
-
-* [Promotional materials on TUF (The Update Framework) w/ Justin Cappos and Trishank Kuppusamy](https://vimeo.com/88774074)
-
-* [Slashdot: Package Managers As Achilles Heel](https://it.slashdot.org/story/08/07/10/227220/package-managers-as-achilles-heel)
diff --git a/content/project.md b/content/project.md
deleted file mode 100644
index 290c807..0000000
--- a/content/project.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Project
----
-
-The TUF project consists of three components:
-
-* [Specification] – the detailed TUF specification describes how to add TUF metadata to a repository and the process to arrange for clients to use that metadata to download and verify targets.
-* [Standardization process] – major changes to the specification, including new features, are made as TUF Augmentation Proposals (TAPs).
-* [Reference implementation] – python-tuf provides a reference implementation of the TUF specification and is used as a vital part of the TAPs process to prototype changes to the specification.
-
-The project is currently managed by a team of collaborators from academia and
-industry.
-
-Many people have contributed to the project since its inception, including
-academics, professional developers, and contributors from the open-source
-community. We especially acknowledge the individuals from the open-source
-community who have [contributed] to the TUF project over the years.
-
-Please visit the [governance page] to learn how project decisions are made, and
-for a more detailed explanation of the project roles used below.
-
-[contributed]: https://github.com/theupdateframework/python-tuf/blob/develop/docs/AUTHORS.txt
-[governance page]: https://github.com/theupdateframework/specification/blob/master/GOVERNANCE.md
-[Specification]: /specification
-[Standardization process]: https://github.com/theupdateframework/taps/blob/master/tap1.md
-[Reference implementation]: https://theupdateframework.readthedocs.io/en/latest/
-
-## Consensus Builder
-
-### Justin Cappos
-
-Email: jcappos@nyu.edu
-
-GitHub username: [JustinCappos](https://github.com/justincappos)
-
-PGP fingerprint: E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A
-
-## Maintainers
-
-Maintainer | Email | GitHub username | PGP fingerprint
-:----------|:------|:----------------|:---------------
-Trishank Karthik Kuppusamy | trishank.karthik@datadog.com | [trishankatdatadog](https://github.com/trishankatdatadog) | 8C48 08B5 B684 53DE 06A3 08FD 5C09 0ED7 318B 6C1E
-Joshua Lock | joshua.lock@uk.verizon.com | [joshuagl](https://github.com/joshuagl) | 08F3 409F CF71 D87E 30FB D3C2 1671 F65C B748 32A4
-Marina Moore | mm9693@nyu.edu | [mnm678](https://github.com/mnm678) | –
-Lukas Pühringer| lukas.puehringer@nyu.edu | [lukpueh](https://github.com/lukpueh) | 8BA6 9B87 D43B E294 F23E 8120 89A2 AD3C 07D9 62E8
diff --git a/content/publications.md b/content/publications.md
deleted file mode 100644
index 479cff6..0000000
--- a/content/publications.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Publications
----
-
-The following papers provide detailed information on securing software updater
-systems, TUF's design, attacks on package managers, and package management
-security:
-
-* [Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against
- Community
- Repositories](/papers/prevention-rollback-attacks-atc2017.pdf?raw=true)
-
-* [Diplomat: Using Delegations to Protect Community
- Repositories](/papers/protect-community-repositories-nsdi2016.pdf?raw=true)
-
-* [Survivable Key Compromise in Software Update
- Systems](/papers/survivable-key-compromise-ccs2010.pdf?raw=true)
-
-* [A Look In the Mirror: Attacks on Package
- Managers](/papers/attacks-on-package-managers-ccs2008.pdf?raw=true)
-
-* [Package Management
- Security](/papers/package-management-security-tr08-02.pdf?raw=true)
diff --git a/content/reporting.md b/content/reporting.md
deleted file mode 100644
index 26ab6a4..0000000
--- a/content/reporting.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Reporting issues
----
-
-Security issues can be reported by emailing [jcappos@nyu.edu](mailto:jcappos@nyu.edu).
-
-If at all possible, please include the following information in the report:
-
-* Description of the vulnerability.
-* Steps to reproduce the issue.
-
-Optionally, emailed reports can be encrypted with PGP. Use this
-PGP key fingerprint:
-
-**E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A**.
diff --git a/content/security.md b/content/security.md
deleted file mode 100644
index 1b66ed3..0000000
--- a/content/security.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: Security
----
-
-We can think of a software update system as "secure" if:
-* it knows about the latest available updates in a timely manner
-* any files it downloads are the correct files, and,
-* no harm results from checking or downloading files.
-
-Making this happen requires workable preventive strategies against a number of potential attacks.
-
-## Attacks and Weaknesses
-
-The following are some of the known attacks on software update systems,
-including the weaknesses that make these attacks possible. To design
-a secure software update framework, these attacks need to be understood and
-strategies to defend against them must be specified.
-Some of these issues are, or can be, related, depending on the design and
-implementation of the given software update system.
-
-* **Arbitrary software installation**. An attacker can provide arbitrary files in
-response to download requests and install anything on the client system, yet none will be detected as illegitimate.
-
-* **Rollback attacks**. An attacker presents files to a software update system
-that are older than those the client has already seen. With no way
-to tell it is an obsolete version that may contain vulnerabilities, the user
-installs the software. Later on, the vulnerabilities can be exploited by
-attackers.
-
-* **Fast-forward attacks**. An attacker arbitrarily increases the version
-numbers of project metadata files in the snapshot
-metadata well beyond the current value, thus tricking a software update system
-into thinking that any subsequent updates are trying
-to rollback the package to a previous, out-of-date version.
-In some situations, such as those where there is a maximum possible
-version number, the perpetrator could use a number so high that the system
-would never be able to match it with the one in the
-snapshot metadata, and thus new updates could never be downloaded.
-
-* **Indefinite freeze attacks**. An attacker continues to present files to
-a software update system files that the client has already seen. As a result,
-the client is kept unaware of new files.
-
-* **Endless data attacks**. An attacker responds to a file download request
- with an endless stream of data, causing harm to clients (e.g. a disk partition
-filling up or memory exhaustion).
-
-* **Extraneous dependencies attacks**. An attacker indicates to clients that,
- in order to install the software they want, they also need to install
- unrelated software. This extra software may be from a trusted source,
- but could still have known vulnerabilities that are exploitable by the attacker.
-
-* **Mix-and-match attacks**. An attacker presents clients with a view of a
-repository that includes files that did not exist there together at the same time.
-This can result in outdated versions of
-dependencies being installed, and other complications.
-
-* **Wrong software installation**. An attacker provides a client with a
- trusted file that is just not the one the client wanted.
-
-* **Malicious mirrors preventing updates**. An attacker controls one
-repository mirror and is able to use it to prevent clients from obtaining updates from other,
-non-malicious mirrors.
-
-* **Vulnerability to key compromises**. An attacker who can compromise the one key
-in a single key system, or less than a given threshold of keys, can compromise
-clients. These attacks can occur whether the client relies on a single online
-key (if only being protected by SSL) or a single offline key (if protected by
-most software update systems that use keysigning).
-
-## Security Design Principles
-
-To ensure systems are secure against all of the above attacks, the design and
-implementation of TUF relies on a few basic concepts.
-For details of how TUF conveys the information discussed below, see the
-[Metadata documentation](/metadata.html).
-
-### Trust
-
-Trusting downloaded files really means assuming the files were provided by
-party without malicious designs. Two frequently overlooked aspects of trust
-in a secure software update system are:
-
-* Trust should not be granted forever. Trust should expire if it is not renewed.
-* Trust should not be granted equally to all parties. This type of compartmentalized
-trust means a party is only to be trusted for the files that the root role stipulates it is
-to provide.
-
-### Mitigating Key Risk (Compromise-Resilience)
-
-Cryptographic signatures are a necessary component in securing a software update
-system. The safety of the keys used to create these signatures directly affects the
-security of the clients the system protects. Rather than naively assume
-that private keys are always safe from compromise, a secure software update
-system must anticipate how to keep clients as safe as possible when a compromise
-of those keys occurs. This is the basic principle of compromise resilience.
-
-Keeping clients safe despite a key compromise involves:
-
-* Fast and secure key replacement and revocation.
-* Minimal trust placed in keys that are at high risk. Keys that are kept online
- or used in an automated fashion should not pose an immediate risk to clients
-if compromised.
-* Multiple key usage and a threshold/quorum of signatures.
-
-### Integrity
-
-Ensuring integrity in TUF not only refers to single files, but also to repository
-as a whole. It's fairly obvious that clients must verify that
-individual downloaded files are correct. It's not as obvious, but still very
-important for clients to be certain that their entire view of a
-repository is correct. For example, if a trusted party is providing two files,
-a software update system should see the latest versions of both files,
-not just one, and not versions of the two files that were never provided together.
-
-### Freshness
-
-Since software updates often fix security bugs, it is important for software
-update systems to obtain the latest versions available of these files. An attacker
-may want to trick a client into installing outdated versions of software or
-even just convince a client that no updates are available.
-
-Ensuring freshness means:
-
-* Never accepting files older than those that have been seen previously.
-* Recognizing when there may be a problem obtaining updates.
-
-Note that it won't always be possible for a client to successfully update if an
-attacker is responding to their requests. However, a client should be able
-to recognize that updates may exist that they haven't been able to obtain.
-
-## Implementation Safety
-
-In addition to a secure design, TUF also works to be secure against
-implementation vulnerabilities, including those common to software update
-systems. In some cases this is assisted by the inclusion of additional
-information in metadata. For example, knowing the expected size of a
-target file that is to be downloaded allows TUF to limit the amount of
-data it will download when retrieving the file. As a result, TUF is
-secure against endless data attacks (discussed above).
diff --git a/content/taps.md b/content/taps.md
deleted file mode 100644
index 1442f23..0000000
--- a/content/taps.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Enhancement proposals
----
-
-### What is a TAP?
-
-A TAP (TUF Augmentation Proposal) is a design document providing information to
-the TUF community, or describing a new feature for TUF or its processes or
-environment. We intend TAPs to be the primary mechanisms for proposing major
-new features, for collecting community input on an issue, and for documenting
-the design decisions that have gone into TUF.
-
-Please visit the [TAPs GitHub repo](https://github.com/theupdateframework/taps)
-to review design changes that have been proposed to date, or to submit your own
-new feature. See [TAP
-1](https://github.com/theupdateframework/taps/blob/master/tap1.md) for
-instructions on how to submit a TAP.
diff --git a/content/timeline.md b/content/timeline.md
deleted file mode 100644
index 98fc932..0000000
--- a/content/timeline.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Timeline
----
-
-**2010**: Improving upon the Thandy software updater for the Tor private
-browser, Justin Samuel and Justin Cappos collaborate to design and publish an
-academic research paper on The Update Framework (TUF).
-
-**2011**: TUF Project moves to New York University Polytechnic School of
-Engineering (later NYU Tandon School of Engineering) when Justin Cappos
-accepts a post as an assistant professor at the Brooklyn, NY, school.
-
-**2013**: Justin Cappos, Trishank Kuppusamy, and Vladimir Diaz begin research
-into adapting and improving TUF for Python, Ruby, and other environments used
-for cloud computing.
-
-**2013**: [PEP 458](https://www.python.org/dev/peps/pep-0458/), the first of
-two Python Enhancement Proposals dealing with TUF is published.
-"Surviving a Compromise of PyPI" details
-the integration of TUF into the Python package manager.
-
-**2014**: Flynn becomes the first tech organization to adopt TUF when
-it independently implements the program in its Go programming language.
-
-**2014**: [PEP 480](https://www.python.org/dev/peps/pep-0480/), a
- maximum security version of PEP 458, is published.
-
-**2015**: Docker launches Notary, an implementation of TUF
-used to publish and manage trusted collections of content. It also launches
-Docker Content Trust, which uses Notary to sign and verify container images.
-
-**2016**: *Diplomat: Using Delegations to Protect Community Repositories*
-is presented at NSDI 2016. The subject of the paper, Diplomat, is the first of several
-TUF adaptations developed to address a specific identified problem in practice.
-In this case,
-the problem was the need for faster registration of new projects on community
-repositories without sacrificing security. It also introduced the concept
-of delegation of trust.
-
-**2016**: A consortium including NYU Tandon (Cappos, Kuppusamy, Diaz, Awwad),
-the University of Michigan Transportation Research Institute (UMTRI), and the
-Southwest Research Institute (SWRI), begin developing Uptane, another evolution of
-TUF designed to protect updates for vehicles from being easily compromised by rogue
-nation-state attackers.
-
-**2016**: *Uptane: Securing Software Updates for Automobiles* is presented at
-escar 16.
-
-**2017**: Uptane is officially introduced at press events in Ann Arbor, MI, and
-Brooklyn, NY.
-
-**2017**: *Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against
-Community Repositories* is presented at USENIX ATC 2017. Mercury is another TUF
-adaptation, and was developed to protect against rollback attacks on community repositories at
-a reasonable bandwidth cost.
-
-**2017**: Uptane is named one of the year's most important innovations in
-security by *Popular Science*.
-
-**2017**: The Linux Foundation announces at Open Source Summit
-Europe that it was adding TUF as the 14th hosted project for its Cloud Native
-Computing Foundation.
-
-**2018**: Aktualizr, an open source C++ implementation of Uptane developed by Advanced Telematic Systems (now HERE technologies), is integrated into Automotive Grade Linux (AGL). AGL, a collaborative open source project of the Linux
-Foundation, has been adopted by a number of U.S. and international manufacturers.
-
-**2018**: NYU Tandon School of Engineering becomes an associate member of the Linux Foundation and a Bronze member of AGL on the strength of the Foundation’s adoption of Uptane and TUF projects.
-
-**2018**: The Uptane Alliance, a nonprofit entity organized under the umbrella of IEEE’s International Standards and Technology Organization (ISTO), is formed to oversee development of standards for the secure implementation/deployment of Uptane.
-
-**2019**: [IEEE-ISTO 6100.1.0.0 Uptane Standard for Design and Implementation](https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html) is released.
-
-**2019**: Uptane becomes a Linux Foundation Joint Development Foundation project.
-
-**2019**: TUF is awarded graduate status within the organization, signifying completion of a series of steps needed to move the project to the highest level of maturity in the CNCF. In achieving this status, TUF becomes both the first security project and the first project led by an academic researcher to graduate within CNCF.
diff --git a/hugo.yaml b/hugo.yaml
new file mode 100644
index 0000000..c33e639
--- /dev/null
+++ b/hugo.yaml
@@ -0,0 +1,111 @@
+# cSpell:ignore docsy github goldmark linkify netlify
+
+baseURL: https://theupdateframework.io
+title: TUF
+disableKinds: [taxonomy]
+theme: [docsy]
+enableGitInfo: true
+
+#
+# Outputs and Netlify _redirects file support
+#
+
+disableAliases: true # We do redirects via Netlify's _redirects file
+
+mediaTypes:
+ text/netlify: {}
+
+outputFormats:
+ REDIRECTS:
+ mediaType: text/netlify
+ baseName: _redirects
+ notAlternative: true
+
+outputs:
+ home: [HTML]
+ section: [HTML]
+
+#
+# Language settings
+#
+
+enableMissingTranslationPlaceholders: true
+defaultContentLanguage: en
+
+languages:
+ en:
+ languageName: English
+ languageCode: en-US
+ params:
+ description: A Framework for securing software update systems
+
+#
+# Markup and imaging
+#
+
+markup:
+ goldmark:
+ extensions:
+ linkify: false
+ parser:
+ attribute:
+ block: true
+ wrapStandAloneImageWithinParagraph: false
+ renderer:
+ unsafe: true
+ highlight:
+ noClasses: false # Required for dark-mode
+ tableOfContents: { endLevel: 4 }
+
+imaging:
+ resampleFilter: CatmullRom # cspell:disable-line
+ quality: 75
+ anchor: smart
+
+params:
+ copyright:
+ authors: >-
+ The Update Framework Authors| [CC BY
+ 4.0](https://creativecommons.org/licenses/by/4.0) |
+ # from_year: 2024
+ github_repo: https://github.com/theupdateframework
+ gcs_engine_id: 011217106833237091527:la2vtv2emlw # CUSTOMIZE # FIXME get an ID for the starter?
+ privacy_policy: https://www.linuxfoundation.org/legal/privacy-policy
+ ui:
+ navbar_logo: true
+ showLightDarkModeMenu: true
+ sidebar_search_disable: true
+ feedback: # CUSTOMIZE
+ enable: false # FIXME: setting to false until the feedback can be better configured
+ 'yes': >-
+ Glad to hear it! Please tell us how we can
+ improve.
+ 'no': >-
+ Sorry to hear that. Please tell us how we can
+ improve.
+ links: # CUSTOMIZE
+ user:
+ - name: TUF Google group
+ url: https://groups.google.com/g/theupdateframework
+ icon: fa-solid fa-envelope
+ desc: Sign up for TUF announcements
+ - name: Slack channel
+ url: https://communityinviter.com/apps/cloud-native/cncf
+ icon: fa-brands fa-slack
+ desc: Connect with us on CNCF Slack channel for TUF
+ - name: Community meetings
+ url: https://github.com/theupdateframework/community?tab=readme-ov-file
+ icon: fa-regular fa-calendar-days
+ desc: Join our community meetings
+ developer:
+ - name: GitHub repository
+ url: https://github.com/theupdateframework/theupdateframework.io
+ icon: fa-brands fa-github
+ desc: Development takes place here!
+
+module:
+ mounts:
+ - source: content/en
+ target: content
diff --git a/layouts/_default/_markup/render-heading.html b/layouts/_default/_markup/render-heading.html
new file mode 100644
index 0000000..6cb98f1
--- /dev/null
+++ b/layouts/_default/_markup/render-heading.html
@@ -0,0 +1,4 @@
+{{ template "_default/_markup/td-render-heading.html" . -}}
+
+{{/* By default, the markdown processor emits a heading on its own line, so we
+don't trim whitespace from the end of this template. */}}
diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html
deleted file mode 100644
index b127aab..0000000
--- a/layouts/_default/baseof.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{ $lang := site.LanguageCode }}
-
-
-
- {{ partial "meta.html" . }}
-
- {{ block "title" . }}
- {{ site.Title }}
- {{ end }}
-
- {{ partial "css.html" . }}
- {{ partial "favicon.html" . }}
-
-
-
- {{ partial "navbar.html" . }}
-
- {{ block "main" . }}
- {{ end }}
-
-
- {{ partial "footer.html" . }}
- {{ partial "javascript.html" }}
-
-
diff --git a/layouts/_default/single.html b/layouts/_default/single.html
deleted file mode 100644
index 3cb11c0..0000000
--- a/layouts/_default/single.html
+++ /dev/null
@@ -1,46 +0,0 @@
-{{ define "title" }}
-{{ site.Title }} | {{ .Title }}
-{{ end }}
-
-{{ define "main" }}
-{{ $hasToc := gt (len .TableOfContents) 32 }}
-
-