From 9fbb94f15f797352a3bae3e957d5bdf5c77703fa Mon Sep 17 00:00:00 2001 From: Dariksha Date: Thu, 29 Aug 2024 00:29:57 +0530 Subject: [PATCH] fixed format --- .prettierignore | 17 +- assets/scss/_styles_project.scss | 2 +- assets/scss/_variables_project.scss | 19 +- content/en/_index.md | 28 +-- content/en/blog/2023/security-audit-23.md | 30 +-- content/en/community/_index.md | 1 - content/en/docs/faq.md | 13 +- content/en/docs/getting-started/_index.md | 195 +++++++++++-------- content/en/docs/system-overview.md | 221 ++++++++++++++++------ content/en/docs/what-is-in-toto.md | 31 ++- content/en/search.md | 1 - data/news.yaml | 6 +- data/specs.yaml | 17 +- hugo.yaml | 50 ++--- package.json | 2 +- 15 files changed, 419 insertions(+), 214 deletions(-) diff --git a/.prettierignore b/.prettierignore index 68d87df..833ff04 100644 --- a/.prettierignore +++ b/.prettierignore @@ -1,15 +1,2 @@ -.* -/* -!/content -/content/* -!/content/en -/content/en/* - -!/content/en/docs -/content/en/docs/* -!/content/en/docs/_index.md - -!/content/en/docs/adding-content -/content/en/docs/adding-content/* - -!/content/en/docs/adding-content/lookandfeel.md +/themes +/layouts \ No newline at end of file diff --git a/assets/scss/_styles_project.scss b/assets/scss/_styles_project.scss index df89642..7b498ac 100644 --- a/assets/scss/_styles_project.scss +++ b/assets/scss/_styles_project.scss @@ -2,7 +2,7 @@ /* Custom styles for the navbar */ .td-navbar { - background-color: $primary !important; /* Set background color to black */ + background-color: $primary !important; /* Set background color to black */ opacity: 1; /* Ensure the navbar is fully opaque */ } diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss index 7c454df..c875c31 100644 --- a/assets/scss/_variables_project.scss +++ b/assets/scss/_variables_project.scss @@ -1,12 +1,19 @@ /* Updated color scheme to match the background image */ $in-toto-colors: ( - 'orange': #ed4b27, // Keep existing - 'orange-light': #f47a39, // Keep existing - 'blue': #1b2838, // Darker blue for better contrast - 'blue-light': #a3b5c8, // Lighter blue for accentss + 'orange': #ed4b27, + // Keep existing + 'orange-light': #f47a39, + // Keep existing + 'blue': #1b2838, + // Darker blue for better contrast + 'blue-light': #a3b5c8, + // Lighter blue for accentss ); -$primary: map-get($in-toto-colors, 'blue'); // Darker blue for primary elements -$secondary: map-get($in-toto-colors, 'orange'); // Bright orange for secondary elements +$primary: map-get($in-toto-colors, 'blue'); // Darker blue for primary elements +$secondary: map-get( + $in-toto-colors, + 'orange' +); // Bright orange for secondary elements $td-enable-google-fonts: false; diff --git a/content/en/_index.md b/content/en/_index.md index dab40ce..e967c3d 100644 --- a/content/en/_index.md +++ b/content/en/_index.md @@ -4,6 +4,7 @@ description: A framework to secure the integrity of software supply chains --- {{% blocks/cover image_anchor="top" height="max" %}} + @@ -11,29 +12,34 @@ description: A framework to secure the integrity of software supply chains {{% param description %}} {.display-6} -Learn More -Try the demo -Explore integrations +Learn +More +Try +the demo +Explore +integrations {.p-initial .my-5} +
Get started
{{% blocks/link-down color="info" %}} {{% /blocks/cover %}} -{{% blocks/lead color="primary" %}} -**in-toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order.** -{{% /blocks/lead %}} +{{% blocks/lead color="primary" %}} **in-toto is designed to ensure the +integrity of a software product from initiation to end-user installation. It +does so by making it transparent to the user what steps were performed, by whom +and in what order.** {{% /blocks/lead %}} {{% blocks/section color="dark" type="row" %}} {{% blocks/feature icon="fa-solid fa-lock" title="Software supply chain protection" url="/docs/system-overview/" %}} -**Supply chain compromises are becoming a frequent occurrence. in-toto can help you protect your software supply chain.** -{{% /blocks/feature %}} +**Supply chain compromises are becoming a frequent occurrence. in-toto can help +you protect your software supply chain.** {{% /blocks/feature %}} {{% blocks/feature icon="fa-solid fa-book" title="Open, extensible standard" url="/docs/specs/" %}} -**in-toto is an open metadata standard that you can implement in your software's supply chain toolchain.** -{{% /blocks/feature %}} +**in-toto is an open metadata standard that you can implement in your software's +supply chain toolchain.** {{% /blocks/feature %}} {{% blocks/feature icon="fa-solid fa-gear" title="Extensive tooling" url="https://github.com/in-toto" %}} **You can use in-toto today by using our Apache-licensed libraries and tools.** @@ -43,7 +49,7 @@ description: A framework to secure the integrity of software supply chains {{% blocks/section color="secondary" type="cncf" %}} -**in-toto is a [CNCF][] [incubating][] project**.
+**in-toto is a [CNCF][] [incubating][] project**.
[![CNCF logo][]][cncf] diff --git a/content/en/blog/2023/security-audit-23.md b/content/en/blog/2023/security-audit-23.md index 8f82e15..3165573 100644 --- a/content/en/blog/2023/security-audit-23.md +++ b/content/en/blog/2023/security-audit-23.md @@ -2,7 +2,8 @@ title: Security Audit '23 description: Explore our latest security audits and findings. date: 2023-05-11 -author: 'Aditya Sirish, [NYU Secure Systems Lab](https://ssl.engineering.nyu.edu)' +author: + 'Aditya Sirish, [NYU Secure Systems Lab](https://ssl.engineering.nyu.edu)' --- We are excited to announce completion of a source code audit of the in-toto @@ -39,15 +40,16 @@ all security findings and GitHub issues for the informational findings It shall be noted that all security-relevant issues can be mitigated by a correct usage of in-toto, or by understanding its scope. In fact the issue marked high-severity was well known to us as a possible use pattern and had an -issue open for several years. Thus, our fixes consist, above all, of -clarifications in the specification and usage documentation. Below we give an +issue open for several years. Thus, our fixes consist, above all, of +clarifications in the specification and usage documentation. Below we give an overview of all security-relevant findings and our response to them. More comprehensive details can be found in the linked advisories and the [report](/2023-security-audit-report.pdf). ### File Metadata Ignored (medium severity) -Advisory: [GHSA-wqrg-wjp9-wqfq](https://github.com/in-toto/docs/security/advisories/GHSA-wqrg-wjp9-wqfq) +Advisory: +[GHSA-wqrg-wjp9-wqfq](https://github.com/in-toto/docs/security/advisories/GHSA-wqrg-wjp9-wqfq) in-toto does not verify the integrity of file metadata. This might allow attackers to provoke privilege escalation or degradation of the final product. @@ -59,9 +61,11 @@ as part of the file contents. ### Configuration Read From Local Directory (medium severity) -Advisory: [GHSA-wqrg-wjp9-wqfq](https://github.com/in-toto/in-toto/security/advisories/GHSA-wc64-c5rv-32pf) +Advisory: +[GHSA-wqrg-wjp9-wqfq](https://github.com/in-toto/in-toto/security/advisories/GHSA-wc64-c5rv-32pf) -CVE: [CVE-2023-32076](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32076) +CVE: +[CVE-2023-32076](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32076) The link generation tool of the reference implementation can be configured using RC files stored in directories following the XDG base directory specification. @@ -70,7 +74,7 @@ attacker that controls the inputs to a step may compromise the link metadata and evade detection by including such a configuration with their materials in transit, which, e.g. filter certain artifacts from being recorded. -This is a special case of “Functionaries Do Not Perform Verification”, which is +This is a special case of “Functionaries Do Not Perform Verification”, which is described below. Further, after conversations with in-toto adopters, we realized that while RC files are widely used by other systems, in-toto users typically set configurations using API parameters or CLI arguments. As such, we removed @@ -78,7 +82,8 @@ support for RC files from the reference implementation. ### Layout Replay (low severity) -Advisory: [GHSA-73jv-h86v-c2vh](https://github.com/in-toto/docs/security/advisories/GHSA-73jv-h86v-c2vh) +Advisory: +[GHSA-73jv-h86v-c2vh](https://github.com/in-toto/docs/security/advisories/GHSA-73jv-h86v-c2vh) It is possible for an attacker to replay an older, since-replaced layout that has not yet expired. @@ -93,7 +98,8 @@ conjunction with in-toto to defend against layout replay attacks. ### Link File Reuse (medium severity) -Advisory: [GHSA-6q78-j78h-pqm2](https://github.com/in-toto/docs/security/advisories/GHSA-6q78-j78h-pqm2) +Advisory: +[GHSA-6q78-j78h-pqm2](https://github.com/in-toto/docs/security/advisories/GHSA-6q78-j78h-pqm2) Link metadata files are not inherently tied to a layout, which might allow an attacker to replay ​​steps by replacing link files with ones from an earlier @@ -107,7 +113,8 @@ ITE-3 are designed to prevent unallowed metadata reuse. ### Functionaries Do Not Perform Verification (high severity) -Advisory: [GHSA-p86f-xmg6-9q4x](https://github.com/in-toto/docs/security/advisories/GHSA-p86f-xmg6-9q4x) +Advisory: +[GHSA-p86f-xmg6-9q4x](https://github.com/in-toto/docs/security/advisories/GHSA-p86f-xmg6-9q4x) An attacker, who controls the product in transit, may compromise the whole supply chain and stay undetected, by modifying only the product in transit, and @@ -124,7 +131,8 @@ we have added, can be found in the advisory. ### Several PGP Issues (varying severity) -Advisory: [GHSA-jjgp-whrp-gq8m](https://github.com/in-toto/in-toto/security/advisories/GHSA-jjgp-whrp-gq8m) +Advisory: +[GHSA-jjgp-whrp-gq8m](https://github.com/in-toto/in-toto/security/advisories/GHSA-jjgp-whrp-gq8m) PGP keys in the reference implementation are not validated when verifying metadata signatures. More specifically, in-toto does not check if the validity diff --git a/content/en/community/_index.md b/content/en/community/_index.md index a122ba1..3feeca4 100644 --- a/content/en/community/_index.md +++ b/content/en/community/_index.md @@ -6,4 +6,3 @@ cascade: --- {{% community-lists %}} - diff --git a/content/en/docs/faq.md b/content/en/docs/faq.md index 5bc5fe3..07b8e57 100644 --- a/content/en/docs/faq.md +++ b/content/en/docs/faq.md @@ -6,10 +6,16 @@ weight: 10 ### Why the name “in-toto”? -in-toto is Latin for "as a whole." We chose the name because our objective with in-toto is to build a system to protect the whole software supply chain. +in-toto is Latin for "as a whole." We chose the name because our objective with +in-toto is to build a system to protect the whole software supply chain. ### What is the difference between in-toto and The Update Framework? -[The Update Framework](https://theupdateframework.io) (TUF) provides a framework that can be used to secure update systems, i.e. the "last mile," whereas in-toto lets you verify the whole software supply chain. TUF and in-toto can play together very well, as you can use TUF to deliver updates and their corresponding in-toto metadata. + +[The Update Framework](https://theupdateframework.io) (TUF) provides a framework +that can be used to secure update systems, i.e. the "last mile," whereas in-toto +lets you verify the whole software supply chain. TUF and in-toto can play +together very well, as you can use TUF to deliver updates and their +corresponding in-toto metadata. ### Is Python 3 supported? @@ -17,4 +23,5 @@ Yes, Python 3 is supported with in-toto. ### Is there a timeline for the support of Python 2.7? -We have released the final version of in-toto, v1.0.1, that supports Python 2. Our next release, at the end of April 2021, will drop support for Python 2. +We have released the final version of in-toto, v1.0.1, that supports Python 2. +Our next release, at the end of April 2021, will drop support for Python 2. diff --git a/content/en/docs/getting-started/_index.md b/content/en/docs/getting-started/_index.md index ff08687..2c791e1 100644 --- a/content/en/docs/getting-started/_index.md +++ b/content/en/docs/getting-started/_index.md @@ -5,13 +5,22 @@ weight: 2 ## Introduction -in-toto provides a framework to protect the integrity of the software supply chain. It does so by verifying that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with in transit. - -in-toto requires a **project owner** to create a **layout**. A layout lists the sequence of **steps** of the software supply chain, and the **functionaries** authorized to perform these steps. -When a functionary performs a step in-toto gathers information about the used command and the related files and stores it in a **link** metadata file. As a consequence link files provide the required evidence to establish a continuous chain that can be validated against the steps defined in the layout. - -The layout, signed by the project owners, together with the links, signed by the designated functionaries, are released as part of the final product, and can be validated manually or via automated tooling in, e.g. a package manager. - +in-toto provides a framework to protect the integrity of the software supply +chain. It does so by verifying that each task in the chain is carried out as +planned, by authorized personnel only, and that the product is not tampered with +in transit. + +in-toto requires a **project owner** to create a **layout**. A layout lists the +sequence of **steps** of the software supply chain, and the **functionaries** +authorized to perform these steps. When a functionary performs a step in-toto +gathers information about the used command and the related files and stores it +in a **link** metadata file. As a consequence link files provide the required +evidence to establish a continuous chain that can be validated against the steps +defined in the layout. + +The layout, signed by the project owners, together with the links, signed by the +designated functionaries, are released as part of the final product, and can be +validated manually or via automated tooling in, e.g. a package manager. ## Getting Started @@ -26,33 +35,54 @@ recommendations. ```shell pip install in-toto ``` + ### Create layout, run supply chain steps and verify final product #### Layout The in-toto software supply chain layout consists of the following parts: - - **expiration date** - - **readme** (an optional description of the supply chain) - - **functionary keys** (public keys, used to verify link metadata signatures) - - **signatures** (one or more layout signatures created with the project owner key(s)) - - **software supply chain steps** - correspond to steps carried out by a functionary as part of the software supply chain. The steps defined in the layout list the functionaries who are authorized to carry out the step (by key id). Steps require a unique name to associate them (upon verification) with link metadata that is created when a functionary carries out the step using the `in-toto` tools. Additionally, steps must have material and product rules which define the files a step is supposed to operate on. Material and product rules are described in the section below. - - **inspections** define commands to be run during the verification process and can also list material and product rules. - -Take a look at the [demo layout creation example](https://in-toto.readthedocs.io/en/latest/layout-creation-example.html) + +- **expiration date** +- **readme** (an optional description of the supply chain) +- **functionary keys** (public keys, used to verify link metadata signatures) +- **signatures** (one or more layout signatures created with the project owner + key(s)) +- **software supply chain steps** correspond to steps carried out by a + functionary as part of the software supply chain. The steps defined in the + layout list the functionaries who are authorized to carry out the step (by key + id). Steps require a unique name to associate them (upon verification) with + link metadata that is created when a functionary carries out the step using + the `in-toto` tools. Additionally, steps must have material and product rules + which define the files a step is supposed to operate on. Material and product + rules are described in the section below. +- **inspections** define commands to be run during the verification process and + can also list material and product rules. + +Take a look at the +[demo layout creation example](https://in-toto.readthedocs.io/en/latest/layout-creation-example.html) for further information on how to create an in-toto layout. +#### Artifact Rules +A software supply chain usually operates on a set of files, such as source code, +executables, packages, or the like. in-toto calls these files artifacts. A +material is an artifact that will be used when a step or inspection is carried +out. Likewise, a product is an artifact that results from carrying out a step. -#### Artifact Rules -A software supply chain usually operates on a set of files, such as source code, executables, packages, or the like. in-toto calls these files artifacts. A material is an artifact that will be used when a step or inspection is carried out. Likewise, a product is an artifact that results from carrying out a step. +The in-toto layout provides a simple rule language to authorize or enforce the +artifacts of a step and to chain them together. This adds the following +guarantees for any given step or inspection: -The in-toto layout provides a simple rule language to authorize or enforce the artifacts of a step and to chain them together. This adds the following guarantees for any given step or inspection: -- Only artifacts **authorized** by the project owner are created, modified or deleted, +- Only artifacts **authorized** by the project owner are created, modified or + deleted, - each defined creation, modification or deletion is **enforced**, and also -- restricted to the scope of its definition, which **chains** subsequent steps and inspections together. +- restricted to the scope of its definition, which **chains** subsequent steps + and inspections together. + +Note that it is up to you to properly secure your supply chain, by authorizing, +enforcing and chaining materials and products using any and usually multiple of +the following rules: -Note that it is up to you to properly secure your supply chain, by authorizing, enforcing and chaining materials and products using any and usually multiple of the following rules: - `CREATE ` - `DELETE ` - `MODIFY ` @@ -61,56 +91,64 @@ Note that it is up to you to properly secure your supply chain, by authorizing, - `REQUIRE ` - `MATCH [IN ] WITH (MATERIALS|PRODUCTS) [IN ] FROM ` -*Rule arguments specified as `` allow for Unix shell-style wildcards as implemented by Python's [`fnmatch`](https://docs.python.org/3/library/fnmatch.html).* +_Rule arguments specified as `` allow for Unix shell-style wildcards as +implemented by Python's +[`fnmatch`](https://docs.python.org/3/library/fnmatch.html)._ -in-toto's Artifact Rules, by default, allow artifacts to exist if they are not explicitly disallowed. As such, a `DISALLOW *` invocation is recommended as the final rule for most step definitions. To learn more about the different rule types, their guarantees and how they are applied, take a look at the [Artifact Rules](https://github.com/in-toto/docs/blob/master/in-toto-spec.md#433-artifact-rules) section of the in-toto specification. +in-toto's Artifact Rules, by default, allow artifacts to exist if they are not +explicitly disallowed. As such, a `DISALLOW *` invocation is recommended as the +final rule for most step definitions. To learn more about the different rule +types, their guarantees and how they are applied, take a look at the +[Artifact Rules](https://github.com/in-toto/docs/blob/master/in-toto-spec.md#433-artifact-rules) +section of the in-toto specification. #### Carrying out software supply chain steps ##### in-toto-run + `in-toto-run` is used to execute a step in the software supply chain. This can be anything relevant to the project such as tagging a release with `git`, running a test, or building a binary. The relevant step name and command are passed as arguments, along with materials, which are files required for that -step's command to execute, and products which are files expected as a result -of the execution of that command. These, and other relevant details -pertaining to the step are stored in a link file, which is signed using the -functionary's key. - -If materials are not passed to the command, the link file generated just -doesn't record them. Similarly, if the execution of a command via -`in-toto-run` doesn't result in any products, they're not recorded in the link -file. Any files that are modified or used in any way during the execution of -the command are not recorded in the link file unless explicitly passed as -artifacts. Conversely, any materials or products passed to the command are -recorded in the link file even if they're not part of the execution -of the command. - -See [this simple usage example from the demo application -for more details](https://github.com/in-toto/demo). +step's command to execute, and products which are files expected as a result of +the execution of that command. These, and other relevant details pertaining to +the step are stored in a link file, which is signed using the functionary's key. + +If materials are not passed to the command, the link file generated just doesn't +record them. Similarly, if the execution of a command via `in-toto-run` doesn't +result in any products, they're not recorded in the link file. Any files that +are modified or used in any way during the execution of the command are not +recorded in the link file unless explicitly passed as artifacts. Conversely, any +materials or products passed to the command are recorded in the link file even +if they're not part of the execution of the command. + +See +[this simple usage example from the demo application for more details](https://github.com/in-toto/demo). For a detailed list of all the command line arguments, run `in-toto-run --help` -or look at the [online -documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-run.html). +or look at the +[online documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-run.html). ##### in-toto-record -`in-toto-record` works similar to `in-toto-run` but can be used for -multi-part software supply chain steps, i.e. steps that are not carried out -by a single command. Use `in-toto-record start ...` to create a -preliminary link file that only records the *materials*, then run the -commands of that step or edit files manually and finally use -`in-toto-record stop ...` to record the *products* and generate the actual -link metadata file. For a detailed list of all command line arguments and their usage, -run `in-toto-record start --help` or `in-toto-record stop --help`, or look at -the [online -documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-record.html). + +`in-toto-record` works similar to `in-toto-run` but can be used for multi-part +software supply chain steps, i.e. steps that are not carried out by a single +command. Use `in-toto-record start ...` to create a preliminary link file that +only records the _materials_, then run the commands of that step or edit files +manually and finally use `in-toto-record stop ...` to record the _products_ and +generate the actual link metadata file. For a detailed list of all command line +arguments and their usage, run `in-toto-record start --help` or +`in-toto-record stop --help`, or look at the +[online documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-record.html). #### Release final product -In order to verify the final product with in-toto, the verifier must have access to the layout, the `*.link` files, -and the project owner's public key(s). +In order to verify the final product with in-toto, the verifier must have access +to the layout, the `*.link` files, and the project owner's public key(s). #### Verification + Use `in-toto-verify` on the final product to verify that + - the layout was signed with the project owner's private key(s), - has not expired, - each step was performed and signed by the authorized functionary, @@ -120,17 +158,19 @@ Use `in-toto-verify` on the final product to verify that For a detailed list of all command line arguments and their usage, run `in-toto-verify --help` or look at the -[online -documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-verify.html). +[online documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-verify.html). #### Signatures -`in-toto-sign` is a metadata signature helper tool to add, replace, and -verify signatures within in-toto Link or Layout metadata, with options to: -- replace (default) or add signature(s), with layout metadata able to be -signed by multiple keys at once while link metadata can only be signed by one key at a time + +`in-toto-sign` is a metadata signature helper tool to add, replace, and verify +signatures within in-toto Link or Layout metadata, with options to: + +- replace (default) or add signature(s), with layout metadata able to be signed + by multiple keys at once while link metadata can only be signed by one key at + a time - write signed metadata to a specified path (if no output path is specified, -layout metadata is written to the path of the input file while link metadata -is written to `..link`) + layout metadata is written to the path of the input file while link metadata + is written to `..link`) - verify signatures This tool serves well to re-sign test and demo data. For example, it can be used @@ -138,32 +178,37 @@ if metadata formats or signing routines change. For a detailed list of all command line arguments and their usage, run `in-toto-sign --help` or look at the -[online -documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-sign.html). - +[online documentation](https://in-toto.readthedocs.io/en/latest/command-line-tools/in-toto-sign.html). ## in-toto demo -You can try in-toto by running the [demo application](https://github.com/in-toto/demo). -The demo basically outlines three users viz., Alice (project owner), Bob (functionary) and Carl (functionary) and how in-toto helps to specify a project layout and verify that the layout has been followed in a correct manner. + +You can try in-toto by running the +[demo application](https://github.com/in-toto/demo). The demo basically outlines +three users viz., Alice (project owner), Bob (functionary) and Carl +(functionary) and how in-toto helps to specify a project layout and verify that +the layout has been followed in a correct manner. ## Specification + You can read more about how in-toto works by taking a look at the [specification](https://github.com/in-toto/docs/blob/master/in-toto-spec.md). - ## Security Issues and Bugs -See [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). +See [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). ## Governance and Contributing - For information about in-toto's governance and contributing guidelines, see - [GOVERNANCE.md](https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md) and [CONTRIBUTING.md](https://github.com/in-toto/in-toto/blob/develop/doc/source/CONTRIBUTING.md). +For information about in-toto's governance and contributing guidelines, see +[GOVERNANCE.md](https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md) +and +[CONTRIBUTING.md](https://github.com/in-toto/in-toto/blob/develop/doc/source/CONTRIBUTING.md). ## Acknowledgments -This project is managed by Prof. Santiago Torres-Arias at Purdue University. -It is worked on by many folks in academia and industry, including members of -the [Secure Systems Lab](https://ssl.engineering.nyu.edu/) at NYU and the + +This project is managed by Prof. Santiago Torres-Arias at Purdue University. It +is worked on by many folks in academia and industry, including members of the +[Secure Systems Lab](https://ssl.engineering.nyu.edu/) at NYU and the [NJIT Cybersecurity Research Center](https://centers.njit.edu/cybersecurity). This research was supported by the Defense Advanced Research Projects Agency @@ -172,4 +217,4 @@ Foundation (NSF). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of DARPA, AFRL, and NSF. The United States Government is authorized to reproduce and distribute reprints notwithstanding any copyright -notice herein. \ No newline at end of file +notice herein. diff --git a/content/en/docs/system-overview.md b/content/en/docs/system-overview.md index 0e458b7..2dc87d5 100644 --- a/content/en/docs/system-overview.md +++ b/content/en/docs/system-overview.md @@ -1,102 +1,197 @@ --- -title: "System Overview" -description: "An overview of the in-toto framework, detailing its components and workflow for software supply chain security." +title: 'System Overview' +description: + 'An overview of the in-toto framework, detailing its components and workflow + for software supply chain security.' weight: 3 --- ## System Overview -The main goal of in-toto is to provide authentication, integrity and auditability guarantees for the supply chain that created a final product that a client will install. - -To avoid ambiguity, we will refer to any files in the final product that in-toto does not use to verify supply chain integrity as "target files". Target files are opaque to the framework. Whether target files are packages containing multiple files, single text files, or executable binaries is irrelevant to in-toto. - -The portion of the in-toto layout describing target files is the information necessary to indicate which functionaries are trusted to modify or create such a file. Additional metadata, besides layout and link metadata, can be provided along with target files to verify other properties of the supply chain (e.g., was a code review policy applied?) when inspecting the final product. - -The following are the high-level steps for using the framework, as seen from the viewpoint of an operating system’s package manager. This is an error-free case: - -1. The project owner creates a layout. This describes the steps that every functionary must perform, as well as the specific inspection steps that must be performed on the client's machine. -2. Each functionary performs their usual tasks within the supply chain (e.g., the functionary in charge of compilation compiles the binary), and records link metadata about that action. After all steps are performed by functionaries, the metadata and target files are aggregated into a final product. -3. The client obtains the final product, and verifies that all steps were performed correctly. This is done by checking that all materials used were products of the intended steps, that each step was performed by the authorized functionary, and that the layout was created by the right project owner. If additional verification is required on the accompanying metadata (e.g., to verify VCS-specific metadata), the client will then perform additional inspection steps. If verification is successful, installation is carried out as usual. +The main goal of in-toto is to provide authentication, integrity and +auditability guarantees for the supply chain that created a final product that a +client will install. + +To avoid ambiguity, we will refer to any files in the final product that in-toto +does not use to verify supply chain integrity as "target files". Target files +are opaque to the framework. Whether target files are packages containing +multiple files, single text files, or executable binaries is irrelevant to +in-toto. + +The portion of the in-toto layout describing target files is the information +necessary to indicate which functionaries are trusted to modify or create such a +file. Additional metadata, besides layout and link metadata, can be provided +along with target files to verify other properties of the supply chain (e.g., +was a code review policy applied?) when inspecting the final product. + +The following are the high-level steps for using the framework, as seen from the +viewpoint of an operating system’s package manager. This is an error-free case: + +1. The project owner creates a layout. This describes the steps that every + functionary must perform, as well as the specific inspection steps that must + be performed on the client's machine. +2. Each functionary performs their usual tasks within the supply chain (e.g., + the functionary in charge of compilation compiles the binary), and records + link metadata about that action. After all steps are performed by + functionaries, the metadata and target files are aggregated into a final + product. +3. The client obtains the final product, and verifies that all steps were + performed correctly. This is done by checking that all materials used were + products of the intended steps, that each step was performed by the + authorized functionary, and that the layout was created by the right project + owner. If additional verification is required on the accompanying metadata + (e.g., to verify VCS-specific metadata), the client will then perform + additional inspection steps. If verification is successful, installation is + carried out as usual. ### 2.1 Involved parties and their roles -In the context of in-toto, a role is a set of duties and actions that an actor must perform. +In the context of in-toto, a role is a set of duties and actions that an actor +must perform. -In the description of the roles that follows, it is important to remember that the framework has been designed to allow a large amount of flexibility for many different use cases. Given that every project uses a very specific set of tools and practices, this is a necessary requirement for in-toto. +In the description of the roles that follows, it is important to remember that +the framework has been designed to allow a large amount of flexibility for many +different use cases. Given that every project uses a very specific set of tools +and practices, this is a necessary requirement for in-toto. There are three roles in the framework: 1. Project owner: defines the layout of a software supply chain. -2. Functionary: performs a step in the supply chain and provides a piece of link metadata as a record that such a step was carried out. -3. Client: Performs verification on the final product by checking the provided layout and link metadata. +2. Functionary: performs a step in the supply chain and provides a piece of link + metadata as a record that such a step was carried out. +3. Client: Performs verification on the final product by checking the provided + layout and link metadata. -In addition, there are third-party equivalents of the above roles, which are managed by the sublayout mechanism, described in section 2.1.3. We will elaborate on these roles in depth now. +In addition, there are third-party equivalents of the above roles, which are +managed by the sublayout mechanism, described in section 2.1.3. We will +elaborate on these roles in depth now. #### 2.1.1 Project owner -As previously stated, the project owner sets the required steps to be performed in the supply chain. For each step, its requirements, and the specific public keys that can sign for evidence of the step are included to ensure compliance and accountability. In addition, the layout file will contain the definition of inspection steps to be carried out when verifying the final product. +As previously stated, the project owner sets the required steps to be performed +in the supply chain. For each step, its requirements, and the specific public +keys that can sign for evidence of the step are included to ensure compliance +and accountability. In addition, the layout file will contain the definition of +inspection steps to be carried out when verifying the final product. #### 2.1.2 Functionaries -Functionaries are intended to carry out steps within the supply chain, and to provide evidence of this by means of link metadata. +Functionaries are intended to carry out steps within the supply chain, and to +provide evidence of this by means of link metadata. -A functionary is uniquely identified by the public key that they will use to sign a piece of link metadata as evidence that a step within the supply chain was performed. +A functionary is uniquely identified by the public key that they will use to +sign a piece of link metadata as evidence that a step within the supply chain +was performed. -A functionary can allow a third-party define a step or series of steps of the supply chain a sublayout. In this case, a subset of the steps to be performed are defined by such a functionary, who adopts the role of a project owner for this sublayout. +A functionary can allow a third-party define a step or series of steps of the +supply chain a sublayout. In this case, a subset of the steps to be performed +are defined by such a functionary, who adopts the role of a project owner for +this sublayout. #### 2.1.3 Clients Clients are users or automated tools who want to use the product. -The client will perform verification on the final product. This includes verifying the layout metadata, and that the link metadata provided matches the specified layout described in the metadata, and performing inspection steps to ensure that any additional metadata and target files meet the criteria specified by the layout for this inspection step. +The client will perform verification on the final product. This includes +verifying the layout metadata, and that the link metadata provided matches the +specified layout described in the metadata, and performing inspection steps to +ensure that any additional metadata and target files meet the criteria specified +by the layout for this inspection step. -A client will likely not interact with the in-toto framework directly, as it should be integrated into system installation tools, or package managers. +A client will likely not interact with the in-toto framework directly, as it +should be integrated into system installation tools, or package managers. #### 2.1.4 Third-party sublayouts -Sublayouts allow a functionary to further define steps within the supply chain. When a functionary defines a sublayout, instead of carrying out the next step, they will define the series of steps required as if they were a project owner for the steps in this sublayout. This is helpful if the project owner does not know the specifics of a step, but trusts a functionary to specify them later. +Sublayouts allow a functionary to further define steps within the supply chain. +When a functionary defines a sublayout, instead of carrying out the next step, +they will define the series of steps required as if they were a project owner +for the steps in this sublayout. This is helpful if the project owner does not +know the specifics of a step, but trusts a functionary to specify them later. -Sublayouts can also be used for third-party sections of the supply chain. For example, a package maintainer for a Linux distribution will likely trust all the steps in the version control system as a sublayout defined by upstream developers of each package. +Sublayouts can also be used for third-party sections of the supply chain. For +example, a package maintainer for a Linux distribution will likely trust all the +steps in the version control system as a sublayout defined by upstream +developers of each package. ### 2.2 in-toto components A in-toto implementation contains three main components: -1. A tool to generate and design supply chain layouts. This tool will be used by the project owner to generate a desired supply chain layout file. There are many tools in the reference implementation to aid project owners in creating and signing layouts. -2. A tool that functionaries can use to create link metadata about a step. For example, in the reference implementation, this feature is provided by the "in-toto-run" and "in-toto-record" tools. -3. A tool to be used by the client to perform verification on the final product. This tool uses all of the link and layout metadata generated by the previous tools. It also performs the inspection steps, as directed by the layout. This tool is often included in a package manager or system installer. In the case of the reference implementation, the tool performing this operation is "in-toto-verify". +1. A tool to generate and design supply chain layouts. This tool will be used by + the project owner to generate a desired supply chain layout file. There are + many tools in the reference implementation to aid project owners in creating + and signing layouts. +2. A tool that functionaries can use to create link metadata about a step. For + example, in the reference implementation, this feature is provided by the + "in-toto-run" and "in-toto-record" tools. +3. A tool to be used by the client to perform verification on the final product. + This tool uses all of the link and layout metadata generated by the previous + tools. It also performs the inspection steps, as directed by the layout. This + tool is often included in a package manager or system installer. In the case + of the reference implementation, the tool performing this operation is + "in-toto-verify". ### 2.3 System workflow example -To exemplify how these roles interact, we will describe a simple scenario. We provide more specific scenarios in section 5.3, after we have presented a more thorough description of the framework. +To exemplify how these roles interact, we will describe a simple scenario. We +provide more specific scenarios in section 5.3, after we have presented a more +thorough description of the framework. -Consider a project owner, Alice, and her two functionaries, Diana and Bob. Alice wants Diana to write a Python script (foo.py). Then, Alice wants Bob to package the script into a tarball (foo.tar.gz). This tarball will be sent to the client, Carl, as part of the final product. Carl’s target file is foo.tar.gz. +Consider a project owner, Alice, and her two functionaries, Diana and Bob. Alice +wants Diana to write a Python script (foo.py). Then, Alice wants Bob to package +the script into a tarball (foo.tar.gz). This tarball will be sent to the client, +Carl, as part of the final product. Carl’s target file is foo.tar.gz. -When providing the tarball to Carl, Alice will create a layout file that Carl will use to make sure of the following: +When providing the tarball to Carl, Alice will create a layout file that Carl +will use to make sure of the following: - That the script was written by Diana - That the packaging was done by Bob -- That the script contained in the tarball matches the one that Diana wrote, so if Bob is malicious or if the packaging program has an error, Carl will detect it. - -In order to do this, Carl will require four files in the final product: first, Alice’s layout, describing the requirements listed above. Then, a piece of link metadata that corresponds to Diana’s action of writing a script, and a piece of link metadata for Bob’s step of packaging the script. Finally, the target file (foo.tar.gz) must also be contained in the final product. - -When Carl verifies the final product, his installer will perform the following checks: - -- The layout file exists and is signed with a trusted key (in this case, Alice's). -- Every step in the layout has one or more corresponding link metadata files signed by the intended functionaries, as described in the layout (in this case, the link metadata provided by Bob and Diana). -- All the materials and products listed in the link metadata match, as specified by the layout. This will be used to prevent packages from being altered without a record (missing link metadata), or tampered with while in transit. In this case, the products reported by Diana should match the materials reported by Bob and so on. -- Finally, as is specified in the layout metadata, inspection steps are run on the client side. In this case, the tarball will be inspected to verify that the extracted foo.py matches the one that was written by Diana. +- That the script contained in the tarball matches the one that Diana wrote, so + if Bob is malicious or if the packaging program has an error, Carl will detect + it. + +In order to do this, Carl will require four files in the final product: first, +Alice’s layout, describing the requirements listed above. Then, a piece of link +metadata that corresponds to Diana’s action of writing a script, and a piece of +link metadata for Bob’s step of packaging the script. Finally, the target file +(foo.tar.gz) must also be contained in the final product. + +When Carl verifies the final product, his installer will perform the following +checks: + +- The layout file exists and is signed with a trusted key (in this case, + Alice's). +- Every step in the layout has one or more corresponding link metadata files + signed by the intended functionaries, as described in the layout (in this + case, the link metadata provided by Bob and Diana). +- All the materials and products listed in the link metadata match, as specified + by the layout. This will be used to prevent packages from being altered + without a record (missing link metadata), or tampered with while in transit. + In this case, the products reported by Diana should match the materials + reported by Bob and so on. +- Finally, as is specified in the layout metadata, inspection steps are run on + the client side. In this case, the tarball will be inspected to verify that + the extracted foo.py matches the one that was written by Diana. If all of these verifications pass, then installation continues as usual. -![Supply Chain Example](/images/in-toto-metadata.png) -Figure 1: The supply chain pieces for this example +![Supply Chain Example](/images/in-toto-metadata.png) Figure 1: The supply chain +pieces for this example ## Final Product -The final product is the bundle of link metadata, layout metadata and target files that will be used by the client's system. Additional, project-specific metadata can be also bundled in the final product for verification during inspection steps. +The final product is the bundle of link metadata, layout metadata and target +files that will be used by the client's system. Additional, project-specific +metadata can be also bundled in the final product for verification during +inspection steps. -An installer or package manager uses the framework to inspect the final product and verify its contents. Each project will have specific requirements to verify. For example, a project may want to impose a review policy on the VCS. Thus, it requires in-toto to validate additional accompanying link and layout metadata to verify the review policy was followed. +An installer or package manager uses the framework to inspect the final product +and verify its contents. Each project will have specific requirements to verify. +For example, a project may want to impose a review policy on the VCS. Thus, it +requires in-toto to validate additional accompanying link and layout metadata to +verify the review policy was followed. ### 3.1 Contents @@ -106,28 +201,46 @@ The final product must contain at least these three files: 2. A link metadata file 3. A target file -More complex and robust supply chain layouts will contain more pieces of link metadata, as well as additional sublayout files. Additional metadata (e.g., a signed git commit log) can also be provided to be used during inspection phases. +More complex and robust supply chain layouts will contain more pieces of link +metadata, as well as additional sublayout files. Additional metadata (e.g., a +signed git commit log) can also be provided to be used during inspection phases. #### 3.1.1 Supply chain Layout -The supply chain layout specifies each of the different steps and its requirements, as well as the public keys used by functionaries to sign the link metadata for steps within the chain. +The supply chain layout specifies each of the different steps and its +requirements, as well as the public keys used by functionaries to sign the link +metadata for steps within the chain. -The layout will also specify how each piece of link metadata will be verified, and how the chain steps are interconnected via their materials and products. +The layout will also specify how each piece of link metadata will be verified, +and how the chain steps are interconnected via their materials and products. #### 3.1.2 Link metadata -Link metadata is a statement that a step was carried out. Each piece of link metadata will be used by the framework to ensure that the contents of materials and products have not been altered in an unauthorized manner (e.g., while in transit), and, that any alterations have been done only by an intended functionary. +Link metadata is a statement that a step was carried out. Each piece of link +metadata will be used by the framework to ensure that the contents of materials +and products have not been altered in an unauthorized manner (e.g., while in +transit), and, that any alterations have been done only by an intended +functionary. -A step may be performed a single time but it may be a part of multiple supply chains. in-toto supports such scenarios by not directly associating link metadata with a specific layout. Multiple layouts, therefore, can use the same link metadata during their respective verifications. +A step may be performed a single time but it may be a part of multiple supply +chains. in-toto supports such scenarios by not directly associating link +metadata with a specific layout. Multiple layouts, therefore, can use the same +link metadata during their respective verifications. #### 3.1.3 Target files -Target files are the files clients will install and use in their systems. For example, a target file could be an installation disk image, which will be bundled with link metadata for each step performed to create the target file. +Target files are the files clients will install and use in their systems. For +example, a target file could be an installation disk image, which will be +bundled with link metadata for each step performed to create the target file. #### 3.1.4 Additional metadata files -Additional metadata files can be shipped within the final product for verification. In this case, inspection steps that utilize this metadata can be declared to determine if this metadata is correct. These metadata files will be treated as regular target files by the framework. +Additional metadata files can be shipped within the final product for +verification. In this case, inspection steps that utilize this metadata can be +declared to determine if this metadata is correct. These metadata files will be +treated as regular target files by the framework. ## Further Information -For more detailed information, refer to the [Document Formats](https://github.com/in-toto/docs/blob/v1.0/in-toto-spec.md#4-document-formats). +For more detailed information, refer to the +[Document Formats](https://github.com/in-toto/docs/blob/v1.0/in-toto-spec.md#4-document-formats). diff --git a/content/en/docs/what-is-in-toto.md b/content/en/docs/what-is-in-toto.md index cddc5a3..55eff95 100644 --- a/content/en/docs/what-is-in-toto.md +++ b/content/en/docs/what-is-in-toto.md @@ -3,12 +3,33 @@ title: What is in-toto? description: A short explanation of what in-toto is. weight: 1 --- -A software supply chain is the series of steps performed when writing, testing, packaging, and distributing software. A typical software supply chain is composed of multiple steps "chained" together that transform (e.g., compilation) or verify the state (e.g., linting) of the project in order to drive it to a final product. -Supply chain security is crucial to the overall security of a software product. An attacker who is able to control a step in the supply chain can alter the product for malicious intents that range from introducing backdoors in the source code to including vulnerable libraries in the final product. As a result, supply chain breaches are an impactful means for an attacker to affect multiple users at once. +A software supply chain is the series of steps performed when writing, testing, +packaging, and distributing software. A typical software supply chain is +composed of multiple steps "chained" together that transform (e.g., compilation) +or verify the state (e.g., linting) of the project in order to drive it to a +final product. -Although many frameworks exist to ensure security in the "last mile" (e.g., software updaters), they may be providing integrity and authentication to a product that is already vulnerable; it is possible that, by the time the package makes it to a software update repository, it has already been compromised. +Supply chain security is crucial to the overall security of a software product. +An attacker who is able to control a step in the supply chain can alter the +product for malicious intents that range from introducing backdoors in the +source code to including vulnerable libraries in the final product. As a result, +supply chain breaches are an impactful means for an attacker to affect multiple +users at once. -in-toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order. As a result, with some guidance from the group creating the software, in-toto allows the user to verify if a step in the supply chain was intended to be performed, and if the step was performed by the right actor. +Although many frameworks exist to ensure security in the "last mile" (e.g., +software updaters), they may be providing integrity and authentication to a +product that is already vulnerable; it is possible that, by the time the package +makes it to a software update repository, it has already been compromised. -You can read more about in-toto's internals in our [latest](https://github.com/in-toto/docs/blob/master/in-toto-spec.md) or [stable](https://github.com/in-toto/docs/blob/v1.0/in-toto-spec.md) specification. \ No newline at end of file +in-toto is designed to ensure the integrity of a software product from +initiation to end-user installation. It does so by making it transparent to the +user what steps were performed, by whom and in what order. As a result, with +some guidance from the group creating the software, in-toto allows the user to +verify if a step in the supply chain was intended to be performed, and if the +step was performed by the right actor. + +You can read more about in-toto's internals in our +[latest](https://github.com/in-toto/docs/blob/master/in-toto-spec.md) or +[stable](https://github.com/in-toto/docs/blob/v1.0/in-toto-spec.md) +specification. diff --git a/content/en/search.md b/content/en/search.md index 4cde3a9..394feea 100644 --- a/content/en/search.md +++ b/content/en/search.md @@ -2,4 +2,3 @@ title: Search Results layout: search --- - diff --git a/data/news.yaml b/data/news.yaml index 4864ab4..c8750ca 100644 --- a/data/news.yaml +++ b/data/news.yaml @@ -48,13 +48,13 @@ We released the first version of the [official in-toto Jenkins plugin](https://plugins.jenkins.io/in-toto). This provenance Agent will help you track and sign link metadata for any step within your pipeline in a secure and distributed way. - date: 2018-10-19 text: | - [Colin Domoney gave a talk on this year's DevSecCon London](https://www.devseccon.com/london-2018/session/supply-chain-achilles-heel/). He covered some of the fundamentals of in-toto to protect your cloud native deployment, as well as some other good supply-chain security practices. + [Colin Domoney gave a talk on this year's DevSecCon London](https://www.devseccon.com/london-2018/session/supply-chain-achilles-heel/). He covered some of the fundamentals of in-toto to protect your cloud native deployment, as well as some other good supply-chain security practices. - date: 2018-05-29 text: | [Pacman 5.1 has been released](http://allanmcrae.com/2018/05/pacman-5-1-dont-use-the-force-luke/)! This new version adds support for reproducible builds, and includes a security check for tampered [git tag metadata](https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html). - date: 2018-05-17 text: | - A [LWN](https://lwn.net/Articles/754443/) article has been published, covering various supply chain security issues and their solutions, including grafeas, the update framework, and in-toto. + A [LWN](https://lwn.net/Articles/754443/) article has been published, covering various supply chain security issues and their solutions, including grafeas, the update framework, and in-toto. - date: 2018-05-02 text: | We presented in-toto along with Grafeas at [Kubecon 2018](https://kccnceu18.sched.com/event/Dqtx/completely-securing-the-software-supply-chain-using-grafeas-in-toto-lukas-puehringer-nyu-wendy-dembowski-google-any-skill-level-slides-attached?iframe=yes&w=100%&sidebar=yes&bg=no#). @@ -78,7 +78,7 @@ We presented a demo of in-toto at [Dockercon 2017](https://2017.dockercon.com). You can watch the video [here](https://www.youtube.com/watch?v=SNge7-t4JRE&index=34&list=PLkA60AVN3hh_nihZ1mh6cO3n-uMdF7UlV). - date: 2017-01-17 text: | - A fix to our git tag metadata tampering vulnerability was merged into git's master branch and will be available starting from [git v2.12](https://public-inbox.org/git/20170117233723.23897-1-santiago@nyu.edu/). You can read more about it in our [USENIX '16](https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias) paper. + A fix to our git tag metadata tampering vulnerability was merged into git's master branch and will be available starting from [git v2.12](https://public-inbox.org/git/20170117233723.23897-1-santiago@nyu.edu/). You can read more about it in our [USENIX '16](https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias) paper. - date: 2016-10-14 text: | We presented a demo of in-toto in the [Docker Distributed System Summit](https://blog.docker.com/2016/10/docker-distributed-system-summit-videos-podcast-episodes/). You can watch the video [here](https://youtu.be/Aryr0O6H_2U?t=25m58s). diff --git a/data/specs.yaml b/data/specs.yaml index d7365f9..aff4341 100644 --- a/data/specs.yaml +++ b/data/specs.yaml @@ -1,12 +1,21 @@ - version: in-toto Stable (v1.0) url: https://github.com/in-toto/docs/blob/v1.0/in-toto-spec.md - description: This is a thoroughly-reviewed version of the specification (and probably what you're looking for). + description: + This is a thoroughly-reviewed version of the specification (and probably + what you're looking for). - version: in-toto Latest url: https://github.com/in-toto/docs/blob/master/in-toto-spec.md - description: If you want to see the latest changes and possible features, click this. + description: + If you want to see the latest changes and possible features, click this. - version: in-toto Attestation Framework Stable (v1.0) url: https://github.com/in-toto/attestation/tree/v1.0/ - description: The in-toto Attestation Framework is developed independently of the in-toto specification. A future version of the in-toto specification will incorporate this framework as the mechanism to express software supply chain claims. + description: + The in-toto Attestation Framework is developed independently of the in-toto + specification. A future version of the in-toto specification will + incorporate this framework as the mechanism to express software supply chain + claims. - version: in-toto Attestation Framework Latest url: https://github.com/in-toto/attestation/tree/main - description: If you want to see the latest changes to the in-toto Attestation Framework, click this. + description: + If you want to see the latest changes to the in-toto Attestation Framework, + click this. diff --git a/hugo.yaml b/hugo.yaml index 65c5f9e..8474b57 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -36,7 +36,7 @@ markup: noClasses: false # Required for dark-mode params: - logo: "/images/logo.png" # Add this line + logo: '/images/logo.png' # Add this line copyright: authors: >- in-toto Authors | Documentation Distributed under CC-BY-4.0[CC BY @@ -66,33 +66,37 @@ params: feedback: enable: true 'yes': >- - Glad to hear it! Please tell us how we can improve. + Glad to hear it! Please tell us how we + can improve. 'no': >- - Sorry to hear that. Please tell us how we can improve. + Sorry to hear that. Please tell us how we + can improve. readingtime: enable: false links: user: - - name: GitHub Discussions - url: https://github.com/in-toto/community - icon: fa-brands fa-github - desc: Discussion and help from your fellow users - - name: User mailing list - url: mailto:in-toto-public@googlegroups.com - icon: fa-solid fa-envelope - desc: Sign up for Docsy announcements - - name: Slack - url: https://slack.cncf.io/ - icon: fa-brands fa-slack - desc: in-toto on CNCF Slack Workspace - - name: IRC - url: https://web.libera.chat/#in-toto - icon: fa-solid fa-comments - desc: in-toto on libera - - name: Email the Developers - url: mailto:in-toto-dev@googlegroups.com - icon: fa-solid fa-envelope - desc: Email the developers + - name: GitHub Discussions + url: https://github.com/in-toto/community + icon: fa-brands fa-github + desc: Discussion and help from your fellow users + - name: User mailing list + url: mailto:in-toto-public@googlegroups.com + icon: fa-solid fa-envelope + desc: Sign up for Docsy announcements + - name: Slack + url: https://slack.cncf.io/ + icon: fa-brands fa-slack + desc: in-toto on CNCF Slack Workspace + - name: IRC + url: https://web.libera.chat/#in-toto + icon: fa-solid fa-comments + desc: in-toto on libera + - name: Email the Developers + url: mailto:in-toto-dev@googlegroups.com + icon: fa-solid fa-envelope + desc: Email the developers plantuml: enable: true diff --git a/package.json b/package.json index 50b4902..4ed0df3 100644 --- a/package.json +++ b/package.json @@ -51,4 +51,4 @@ "proseWrap": "always", "singleQuote": true } -} \ No newline at end of file +}