diff --git a/.prettierignore b/.prettierignore index 9b698c5..783655f 100644 --- a/.prettierignore +++ b/.prettierignore @@ -1,2 +1,3 @@ # Ignore some template partials, because prettier adds closing HTML tags -layouts/partials/header.html \ No newline at end of file +layouts/partials/header.html +layouts/partials/md-top-context.html \ No newline at end of file diff --git a/assets/sass/_theme-overrides.scss b/assets/sass/_theme-overrides.scss index 39ca753..4c8cb2c 100644 --- a/assets/sass/_theme-overrides.scss +++ b/assets/sass/_theme-overrides.scss @@ -72,6 +72,25 @@ body, background-color: #051735 !important; } -.pt-md-8 { +@media (min-width: 768px) { + .pt-md-8 { + padding-top: 8rem !important; + } +} + +.pt-10 { + padding-top: 1; +} + +.pt-7 { + padding-top: 7rem !important; +} +.pt-8 { padding-top: 8rem !important; } +.pt-9 { + padding-top: 9rem !important; +} +.pt-10 { + padding-top: 10rem !important; +} diff --git a/assets/sass/main.scss b/assets/sass/main.scss index aac1095..ef1b2e4 100644 --- a/assets/sass/main.scss +++ b/assets/sass/main.scss @@ -34,3 +34,24 @@ body { transform: rotate(-1deg); display: inline-block; } + +.initiative_list_item { + .initiative-status { + text-align: center; + } + &__meta { + .initiative-status { + padding-top: 20px; + } + } + + &__blogLanding { + margin-bottom: 20px; + } +} + +.initiative-description { + ol { + padding-left: 17px; + } +} diff --git a/content/en/about.html b/content/en/about.html index 13404d0..77f7ed5 100644 --- a/content/en/about.html +++ b/content/en/about.html @@ -3,9 +3,6 @@ slug: about --- -
-
-

Who We Are

Prossimo is an Internet Security Research Group project (ISRG) project.

@@ -14,15 +11,33 @@

Who We Are

Goals

-

Our first goal is to move the Internet's security-sensitive software infrastructure to memory safe code. Many of the most critical software vulnerabilities are memory safety issues in C and C++ code. While there are ways to reduce the risk, including fuzzing and static analysis, such mitigations do not eliminate the risk and they consume a lot of resource on an ongoing basis. Using memory safe languages eliminates the entire class of issues. We recognize the amount of work it will take to move significant portions of the Internet’s C and C++ software infrastructure to memory safe code, but the Internet will be around for a long time. There is time for ambitious efforts to pay off. By being smart about our initial investments, focusing on the most critical components, we can start seeing significant returns within 1-2 years.

- -

Our second goal is to change the way people think about memory safety. Today it’s considered perfectly normal and acceptable to deploy software written in languages that aren't memory safe, like C and C++, on a network edge, despite the overwhelming evidence for how dangerous this is. Our hope is that we can get people to fully recognize the risk and view memory safety as a requirement for software in security-sensitive roles.

+

+ Our first goal is to move the Internet's security-sensitive software infrastructure to memory safe code. Many of the most + critical software vulnerabilities are memory safety issues in C and C++ code. While there are ways to reduce the risk, including fuzzing and static analysis, + such mitigations do not eliminate the risk and they consume a lot of resource on an ongoing basis. Using memory safe languages eliminates the entire class of + issues. We recognize the amount of work it will take to move significant portions of the Internet’s C and C++ software infrastructure to memory safe code, but + the Internet will be around for a long time. There is time for ambitious efforts to pay off. By being smart about our initial investments, focusing on the + most critical components, we can start seeing significant returns within 1-2 years. +

+ +

+ Our second goal is to change the way people think about memory safety. Today it’s considered perfectly normal and acceptable to deploy software written in + languages that aren't memory safe, like C and C++, on a network edge, despite the overwhelming evidence for how dangerous this is. Our hope is that we can get + people to fully recognize the risk and view memory safety as a requirement for software in security-sensitive roles. +

Prossimo's Role

-

We view ISRG's role as providing strategic planning, facilitation, and communication. We identify high impact projects, build and maintain relationships with maintainers and funders, help develop plans, and coordinate the work. This includes raising the necessary funds and getting them to the right people (often maintainers). We communicate with the public regarding progress and momentum in order to build support for the project and the ideas behind it.

+

+ We view ISRG's role as providing strategic planning, facilitation, and communication. We identify high impact projects, build and maintain relationships with + maintainers and funders, help develop plans, and coordinate the work. This includes raising the necessary funds and getting them to the right people (often + maintainers). We communicate with the public regarding progress and momentum in order to build support for the project and the ideas behind it. +

-

We believe we have a strong competency in identifying work that is both high impact and efficiently achievable. Our aim is for funding entrusted to us to provide a strong return on investment in terms of making the Internet’s software infrastructure safer for everyone.

+

+ We believe we have a strong competency in identifying work that is both high impact and efficiently achievable. Our aim is for funding entrusted to us to + provide a strong return on investment in terms of making the Internet’s software infrastructure safer for everyone. +

Development Model

@@ -34,22 +49,44 @@

1. Identify critical projects with the best return on investment potential2. Work with maintainers whenever possible

-

Maintainers have valuable knowledge and the ability to ship memory safety updates to their existing users. Building competing software and getting users to switch is much more difficult. By working with maintainers, and funding them when it makes sense, we can get safer software into the hands of users more quickly.

+

+ Maintainers have valuable knowledge and the ability to ship memory safety updates to their existing users. Building competing software and getting users to + switch is much more difficult. By working with maintainers, and funding them when it makes sense, we can get safer software into the hands of users more + quickly. +

Funding maintainers for the work helps to create buy-in and alleviates resource concerns.

3. Prefer a modular approach

-

We encourage projects to replace libraries or modular functionality with memory safe libraries, rather than embark upon ground-up rewrites. This allows us to break up the work into manageable pieces and deliver value incrementally.

+

+ We encourage projects to replace libraries or modular functionality with memory safe libraries, rather than embark upon ground-up rewrites. This allows us to + break up the work into manageable pieces and deliver value incrementally. +

-

It also allows for build-time configuration to select implementations when existing users need the ability to opt-in to the older unsafe versions, either because their environment does not support the new language or because there is a functionality difference. This addresses the concern many maintainers have about abandoning certain specialized users.

+

+ It also allows for build-time configuration to select implementations when existing users need the ability to opt-in to the older unsafe versions, either + because their environment does not support the new language or because there is a functionality difference. This addresses the concern many maintainers have + about abandoning certain specialized users. +

-

Since many projects will end up using the same memory safe libraries, this approach also allows us to invest and build confidence in a particular set of libraries. Investments in a library for one project will add value across multiple projects. For example - the curl project will use the Hyper and Rustls libraries. The work we do to build excellent C API wrappers and improve the integration experience will help with many projects that will use the libraries in the future.

+

+ Since many projects will end up using the same memory safe libraries, this approach also allows us to invest and build confidence in a particular set of + libraries. Investments in a library for one project will add value across multiple projects. For example - the curl project will use the Hyper and Rustls + libraries. The work we do to build excellent C API wrappers and improve the integration experience will help with many projects that will use the libraries in + the future. +

4. Build trust by providing additional success stories over time

-

Some maintainers are understandably hesitant to make fundamental changes to how their projects work, such as adding a new language or replacing important libraries with new ones. It’s on us to make the case, and we will do that by building up a corpus of success stories and continuing to engage with maintainers about how their concerns can be addressed.

- -

We will start by working with more progressive maintainers that need less convincing. As those projects succeed and get positive feedback, other maintainers will come to trust the model that we advocate. Our hope is that over time we can convince more conservative maintainers that moving to memory safe code, with our support, is a worthwhile endeavor.

-
-
+

+ Some maintainers are understandably hesitant to make fundamental changes to how their projects work, such as adding a new language or replacing important + libraries with new ones. It’s on us to make the case, and we will do that by building up a corpus of success stories and continuing to engage with maintainers + about how their concerns can be addressed. +

+ +

+ We will start by working with more progressive maintainers that need less convincing. As those projects succeed and get positive feedback, other maintainers + will come to trust the model that we advocate. Our hope is that over time we can convince more conservative maintainers that moving to memory safe code, with + our support, is a worthwhile endeavor. +

diff --git a/content/en/initiative/rustls.html b/content/en/initiative/rustls.html index 2ab6bfa..355a5a1 100644 --- a/content/en/initiative/rustls.html +++ b/content/en/initiative/rustls.html @@ -11,15 +11,29 @@

The Story

-

The story of our work with Rustls begins with another piece of software, OpenSSL. OpenSSL is a ubiquitous TLS library, used in a large percentage of all devices connected to the Internet. Unfortunately, it's written in C and has a long history of memory safety vulnerabilities.

+

+ The story of our work with Rustls begins with another piece of software, OpenSSL. OpenSSL is a ubiquitous TLS + library, used in a large percentage of all devices connected to the Internet. Unfortunately, it's written in C and has a long history of memory safety + vulnerabilities. +

-

It's important for the security of the Internet that we move away from TLS libraries that aren't memory safe. In our view, however, it's highly unlikely that we can get the OpenSSL project to move away from C. As such, we need to work on a memory safe alternative and get the Internet's critical software infrastructure to make the switch.

+

+ It's important for the security of the Internet that we move away from TLS libraries that aren't memory safe. In our view, however, it's highly unlikely that + we can get the OpenSSL project to move away from C. As such, we need to work on a memory safe alternative and get the Internet's critical software + infrastructure to make the switch. +

-

Fortunately, there is an excellent alternative to OpenSSL for many use cases. Rustls is a high-quality TLS implementation written in Rust, a memory safe language. We believe Rustls represents the future of TLS implementation on the Internet.

+

+ Fortunately, there is an excellent alternative to OpenSSL for many use cases. Rustls is a + high-quality TLS implementation written in Rust, a memory safe language. We + believe Rustls represents the future of TLS implementation on the Internet. +

We're investing in Rustls in two ways:

- +
  1. We've contracted with Dirkjan Ochtman to make a number of improvements to the Rustls library.
  2. -
  3. ISRG engineer Jacob Hoffman-Andrews has developed a C API for Rustls that existing C-based projects can use to make their TLS implementation memory safe.
  4. - +
  5. + ISRG engineer Jacob Hoffman-Andrews has developed a C API for Rustls that existing C-based projects can use to make their TLS implementation memory safe. +
  6. +
diff --git a/layouts/index.html b/layouts/index.html index 38bd1a0..b7c858c 100644 --- a/layouts/index.html +++ b/layouts/index.html @@ -4,7 +4,7 @@ {{ partial "header.html" . }}

Initiatives

- {{ partial "home/initiative_list_item.html" (dict "title" "Linux Kernel" "url" "/initiative/linux-kernel" "image" "/images/tux.svg" "description" "Let's make it possible to write memory-safe drivers for the Linux kernel." "backgroundColor" "#e8fcf8") }} - {{ partial "home/initiative_list_item.html" (dict "title" "curl" "url" "/initiative/curl" "image" "/images/curl.svg" "description" "Let's make TLS and HTTP networking code in curl memory-safe." "backgroundColor" "#e6e9ee") }} - {{ partial "home/initiative_list_item.html" (dict "title" "Rustls" "url" "/initiative/rustls" "image" "/images/rustls.png" "description" "Let's build an excellent memory-safe TLS library intended to replace OpenSSL in many projects." "backgroundColor" "#e8fcf8") }} - {{ partial "home/initiative_list_item.html" (dict "title" "mod_tls" "url" "/initiative/mod_tls" "image" "/images/httpd.svg" "description" "Let's make it possible to use memory safe TLS networking in Apache httpd." "backgroundColor" "#e6e9ee") }} + {{ partial "home/initiative_list_item.html" (dict "title" "Linux Kernel" "project_status" "TK" "funding_status" "TK" "url" "/initiative/linux-kernel" "image" "/images/tux.svg" "description" "Let's make it possible to write memory-safe drivers for the Linux kernel." "backgroundColor" "#e8fcf8") }} + {{ partial "home/initiative_list_item.html" (dict "title" "curl" "project_status" "TK" "funding_status" "TK" "url" "/initiative/curl" "image" "/images/curl.svg" "description" "Let's make TLS and HTTP networking code in curl memory-safe." "backgroundColor" "#e6e9ee") }} + {{ partial "home/initiative_list_item.html" (dict "title" "Rustls" "project_status" "TK" "funding_status" "TK" "url" "/initiative/rustls" "image" "/images/rustls.png" "description" "Let's build an excellent memory-safe TLS library intended to replace OpenSSL in many projects." "backgroundColor" "#e8fcf8") }} + {{ partial "home/initiative_list_item.html" (dict "title" "mod_tls" "project_status" "TK" "funding_status" "TK" "url" "/initiative/mod_tls" "image" "/images/httpd.svg" "description" "Let's make it possible to use memory safe TLS networking in Apache httpd." "backgroundColor" "#e6e9ee") }}
diff --git a/layouts/partials/header.html b/layouts/partials/header.html index 53f7bb4..5b89cb0 100644 --- a/layouts/partials/header.html +++ b/layouts/partials/header.html @@ -88,7 +88,7 @@