From 4763923727a2025b7cc38e8dc2171593d0b53790 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1s=20Gonz=C3=A1lez?= Date: Tue, 12 Sep 2023 11:58:23 +0100 Subject: [PATCH] Fix typos and change to USA english MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Tomás González --- src/archive/system_architecture.md | 12 ++++++------ src/contributing/adding_new_operation_how_to.md | 2 +- src/contributing/package_management.md | 4 ++-- src/getting_started/README.md | 2 +- src/getting_started/installation_options.md | 8 ++++---- src/overview.md | 4 ++-- src/parsec_client/api_overview.md | 16 ++++++++-------- src/parsec_client/operations/list_providers.md | 2 +- src/parsec_client/wire_protocol.md | 8 ++++---- src/parsec_service/README.md | 2 +- src/parsec_service/adding_provider.md | 2 +- src/parsec_service/key_info_managers.md | 4 ++-- src/parsec_service/source_code_structure.md | 8 ++++---- src/parsec_service/stability.md | 10 +++++----- src/parsec_service/tests/existing_tests.md | 4 ++-- 15 files changed, 44 insertions(+), 44 deletions(-) diff --git a/src/archive/system_architecture.md b/src/archive/system_architecture.md index 2303e657..184ec5b0 100644 --- a/src/archive/system_architecture.md +++ b/src/archive/system_architecture.md @@ -111,7 +111,7 @@ co-reside on the same physical host: providing the API in a form that is simple to consume and hard to get wrong. This means that it has facilities for things like smart defaulting, so that the client application can call APIs with fewer arguments and simplified contracts that are tailored for specific use cases. The - client library is then fundamentally an adaptor or wrapper: it converts between the simplified + client library is then fundamentally an adapter or wrapper: it converts between the simplified developer experience and the comprehensive API definition based on the PSA Crypto API. It makes calls to the security service according to the defined [**wire protocol specification**](../parsec_client/wire_protocol.md). @@ -292,7 +292,7 @@ header can be used in a variety of ways. It would be entirely possible for the c simply pass its application identity directly as a cleartext string. The security service would support this (and it offers an authentication style known as **direct authentication** for this purpose). This is simple, and works well in a demo or proof-of-concept environment. But it is not -suitable for a deployed system architecture, because it does not fulfil the stated design goal of +suitable for a deployed system architecture, because it does not fulfill the stated design goal of secretless communication. One solution to this problem is for the authentication header to contain a payload that not only @@ -317,7 +317,7 @@ relationships that were defined above. Another solution to the authentication problem is to use Unix peer credentials with the [Unix peer credentials authenticator](../parsec_service/authenticators.md). Unix peer credentials are connection metadata which specify the effective Unix user ID (UID) and group ID (GID) of the -connecting process. When using a Unix domain sockets tranport, the endpoints can get each other's +connecting process. When using a Unix domain sockets transport, the endpoints can get each other's UID and GID via the operating system. In Unix peer credential authentication, the connecting process self-declares its UID inside the @@ -358,7 +358,7 @@ service. Trust relationships require intermediate key pairs to be generated periodically in order to fulfil the stated design objective around short-lived cryptography. The root key pairs generated in the -bootstrapping phase do not fulfil this objective by themselves. +bootstrapping phase do not fulfill this objective by themselves. Intermediate key pairs are generated by both the orchestrator and identity provider. Each component stores its private key in local process memory, but needs to share the public key. As with the @@ -421,8 +421,8 @@ required to make them suitable for the application developer. ### Sequence Diagram -All flows are summarised and captured in the sequence diagram below. The diagram attempts to collect -together and summarise all of the flows that are needed for bootstrapping, background operations and +All flows are summarized and captured in the sequence diagram below. The diagram attempts to collect +together and summarize all of the flows that are needed for bootstrapping, background operations and also general usage as described above. In order to strike the right balance between completeness and simplicity, the flow diagram does not include every possible path. In particular, the actions taken in response to errors or failed verifications are not captured here. diff --git a/src/contributing/adding_new_operation_how_to.md b/src/contributing/adding_new_operation_how_to.md index 4c0b22fc..be11980d 100644 --- a/src/contributing/adding_new_operation_how_to.md +++ b/src/contributing/adding_new_operation_how_to.md @@ -38,7 +38,7 @@ client library and protobuf on the client side. Take care when deciding on datat should be wrapped in either [`Zeroizing`](https://docs.rs/zeroize/latest/zeroize/struct.Zeroizing.html) or [`Secret`](https://docs.rs/secrecy/latest/secrecy/struct.Secret.html) (choose depending on the -sensitivity of the data. Favour +sensitivity of the data. Favor [`Zeroizing`](https://docs.rs/zeroize/latest/zeroize/struct.Zeroizing.html) unless there is a clear requirement for [`Secret`](https://docs.rs/secrecy/latest/secrecy/struct.Secret.html)) to ensure they are wiped from memory when dropped and should not have any output for debugging. The operation diff --git a/src/contributing/package_management.md b/src/contributing/package_management.md index 31acbfd6..e68e40f7 100644 --- a/src/contributing/package_management.md +++ b/src/contributing/package_management.md @@ -27,7 +27,7 @@ to publish a crate, check out the [Dependency management](#dependency-management - Follow the instructions [here](https://doc.rust-lang.org/cargo/reference/publishing.html) to create your account and to set your workspace up. - If you'd like to publish a new version of an existing crate using the ownership granted to the - Parallaxsecond Admin group, you need to enable crates.io to access that organisation. You can do + Parallaxsecond Admin group, you need to enable crates.io to access that organization. You can do so from the [applications page](https://github.com/settings/applications) in your account settings - in the [crates.io application](https://github.com/settings/connections/applications/9fe8110dfe185fe90b5c) settings @@ -116,7 +116,7 @@ community channels! ### Docker images End-to-end testing for the Parsec service (and for some of the other projects under the -Parallaxsecond organisation) is built on top of Docker images. These images are required because of +Parallaxsecond organization) is built on top of Docker images. These images are required because of the multitude of dependencies needed, generally for connecting to various backends through 3rd party libraries. The Docker images separate the process of setting up this environment from the actual running of tests, allowing very short CI runs. diff --git a/src/getting_started/README.md b/src/getting_started/README.md index ce813a0d..dfc06276 100644 --- a/src/getting_started/README.md +++ b/src/getting_started/README.md @@ -23,7 +23,7 @@ You can consume Parsec API's in several programming languages. You can learn how ## I Want to Use Parsec from the Command Line -Take your first steps with Parsec using the command-line `parsec-tool`. Follow our [familiarisation +Take your first steps with Parsec using the command-line `parsec-tool`. Follow our [familiarization guide](parsec_tool_use.md) to learn how to use the tool to check the service configuration, create key pairs, sign/decrypt messages and create certificate requests. diff --git a/src/getting_started/installation_options.md b/src/getting_started/installation_options.md index 6bdf4dbf..1e399320 100644 --- a/src/getting_started/installation_options.md +++ b/src/getting_started/installation_options.md @@ -108,7 +108,7 @@ can get familiar with Parsec by downloading the latest release from GitHub and r as a quick-start package. This is currently supported for any 64-bit Linux system running on the x86 architecture. -**Note:** this method is suitable for familiarisation and experimentation only. **Do not** use this +**Note:** this method is suitable for familiarization and experimentation only. **Do not** use this method in production environments. To securely install Parsec on Linux for production, check [this guide instead](../parsec_service/install_parsec_linux.md). @@ -271,7 +271,7 @@ A6 F5 90 24 DF FF 50 1F 29 2E .... ``` -The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behaviour. +The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behavior. You can use the `-h` option to get additional help on these. **Note:** If openssl is not installed into a directory included in `PATH` then you also need to @@ -287,7 +287,7 @@ If you'd like to isolate your quickstart experience to a temporary Docker contai familiar with Parsec by utilizing a pre-built image available on ghcr.io. This is currently supported for any system able to run 64-bit Linux x86 Docker images. -**Note:** this method is suitable for familiarisation and experimentation only. **Do not** use this +**Note:** this method is suitable for familiarization and experimentation only. **Do not** use this method in production environments. To securely install Parsec on Linux for production, check [this guide instead](../parsec_service/install_parsec_linux.md). @@ -421,7 +421,7 @@ A6 F5 90 24 DF FF 50 1F 29 2E .... ``` -The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behaviour. +The `parsec-cli-tests.sh` script also accepts some command-line parameters to adjust its behavior. You can use the `-h` option to get additional help on these. ## Option 4: Build from Source Code diff --git a/src/overview.md b/src/overview.md index 3fd792bc..4d6e6b19 100644 --- a/src/overview.md +++ b/src/overview.md @@ -5,7 +5,7 @@ provide a common [API](parsec_client/api_overview.md) to secure services in a pl Parsec aims to define a universal software standard for interacting with secure object storage and cryptography services, creating a common way to interface with functions that would traditionally -have been accessed by more specialised APIs. Parsec establishes an ecosystem of developer-friendly +have been accessed by more specialized APIs. Parsec establishes an ecosystem of developer-friendly libraries in a variety of popular programming languages. Each library is designed to be highly ergonomic and simple to consume. This growing ecosystem will put secure facilities at the fingertips of developers across a broad range of use cases in infrastructure computing, edge computing and the @@ -183,7 +183,7 @@ But Parsec's focus on developer ergonomics goes further than this. Parsec's clie filled with conveniences to eliminate complexity unless complexity is required. The Parsec API is functionally equivalent with the PSA Crypto API, and none of this functional completeness is lost in the client layer. All possible variants of key type and algorithm type are exposed in case they are -needed. But the client library offers smart default behaviours so that simple use cases can be +needed. But the client library offers smart default behaviors so that simple use cases can be achieved with very little code. Parsec enables client code to be small and elegant. And even if it needs to be less small, it should still be elegant. diff --git a/src/parsec_client/api_overview.md b/src/parsec_client/api_overview.md index de7806cc..3740f167 100644 --- a/src/parsec_client/api_overview.md +++ b/src/parsec_client/api_overview.md @@ -3,7 +3,7 @@ ## Introduction This document introduces the API contract that exists between the client and the service, covering -its general principles and organisation. Use this document in combination with the [**wire protocol +its general principles and organization. Use this document in combination with the [**wire protocol specification**](wire_protocol.md) and the [**operation directory**](operations) as a reference guide for the development of client libraries. @@ -101,9 +101,9 @@ through updates, the allowed changes are restricted to the following: - Adding a new *optional* field to an existing type. If not set, the contract containing the new field should behave exactly the same as the version without it. The new field should be ignored - if not recognised by an old version. That means that the functionality brought by a new optional + if not recognized by an old version. That means that the functionality brought by a new optional field might not be exercised if the service is older than the client, without an error returned. -- Adding a new variant to an existing enumerated type. If not recognised during deserialization, the +- Adding a new variant to an existing enumerated type. If not recognized during deserialization, the `InvalidEncoding` error should be returned. In the future, [capabilities discovery](https://github.com/parallaxsecond/parsec/issues/426) @@ -117,8 +117,8 @@ have been introduced, it may sometimes be necessary to deprecate specific operat often be to encourage the use of a new operation with an improved feature set and a different contract. Deprecation is largely a documentation exercise: the [**operation directory**](operations) will indicate when an operation has been deprecated. This does not mean that the operation will no -longer work. It simply means that any new use of the operation is strongly discouraged in favour of -a better alternative. +longer work. It simply means that any new use of the operation is strongly discouraged in favor of a +better alternative. ## Capability Checks @@ -151,7 +151,7 @@ should remain the same over time, even across system resets. The granularity of application identities is not defined. In particular, there is no assumption that a client *application* corresponds precisely with a single client *process*. A client application might be composed of multiple processes. Conversely, a single process might contain multiple -distinct client applications. Client applications might also be organised into isolated environments +distinct client applications. Client applications might also be organized into isolated environments such as containers. Provided that client application is able to present a unique and stable identity string for each API call, it does not matter how they are structured and deployed. @@ -184,7 +184,7 @@ self-declared UID matches the actual UID of the connecting process via the Unix mechanism. When it makes an API request, the client needs to tell the server which kind of authentication is -being used. This is so that the server knows how to interepret the bytes in the **authentication** +being used. This is so that the server knows how to interpret the bytes in the **authentication** field of the request. As described in the [**wire protocol specification**](wire_protocol.md), the client does this by setting an integer value in the **auth type** field of the request header. The permitted numerical values for this field are given as follows:- @@ -268,7 +268,7 @@ invoked to export the key (and the key's usage policy permits for such an export The use of string names offers greater flexibility in how names can be chosen and structured. It allows for names to be readable and meaningful. It also allows for names to follow a structured pattern with separators, similar to a file path. This allows keys to not only be named in meaningful -ways, but also for them to be organised according to a meaningful structure, just like files on a +ways, but also for them to be organized according to a meaningful structure, just like files on a file system. Keys with a similar purpose, for example, can be stored in the same part of the notional "tree". diff --git a/src/parsec_client/operations/list_providers.md b/src/parsec_client/operations/list_providers.md index 94ade40e..b3beb963 100644 --- a/src/parsec_client/operations/list_providers.md +++ b/src/parsec_client/operations/list_providers.md @@ -1,6 +1,6 @@ # ListProviders -Gets a prioritised list of available Parsec providers to be used by clients. Opcode: 8 (`0x0008`) +Gets a prioritized list of available Parsec providers to be used by clients. Opcode: 8 (`0x0008`) ## Parameters diff --git a/src/parsec_client/wire_protocol.md b/src/parsec_client/wire_protocol.md index 5f176b7e..7cbdecb1 100644 --- a/src/parsec_client/wire_protocol.md +++ b/src/parsec_client/wire_protocol.md @@ -12,7 +12,7 @@ code. This document describes the principles, patterns and low-level details of the wire protocol. This covers the details that are common to all messages that pass between the service and its clients. This document is *not* an API specification for the service. Individual API operations, along with -their behaviours, inputs and outputs are described separately in the API specification. The wire +their behaviors, inputs and outputs are described separately in the API specification. The wire protocol is the underlying message-passing mechanism that enables the API. ## Audience @@ -43,9 +43,9 @@ distinction between them. ### Analogy With HTTP and REST -The request-response pattern of the wire protocol is intentionally modelled on the familiar notion -of calling a REST API over HTTP. In fact, one of the guiding principles of the wire protocol design -has been to create something that might loosely be called a "lightweight REST". This term must be +The request-response pattern of the wire protocol is intentionally modeled on the familiar notion of +calling a REST API over HTTP. In fact, one of the guiding principles of the wire protocol design has +been to create something that might loosely be called a "lightweight REST". This term must be applied with caution, however. REST is a collection of architectural principles, not a protocol. It does not follow that all of the RESTful principles are adopted here. However, thinking of the wire protocol as being like a web service protocol, only without any dependency on HTTP or similar diff --git a/src/parsec_service/README.md b/src/parsec_service/README.md index 6bcdfa47..f5ee6f51 100644 --- a/src/parsec_service/README.md +++ b/src/parsec_service/README.md @@ -6,7 +6,7 @@ They cover the following concepts: - [Interfaces and Dataflow](interfaces_and_dataflow.md) - description of all the components forming the Parsec service and their interactions - [Source Code Structure](source_code_structure.md) - overview of Parsec service source code - organisation + organization - [Parsec Providers](providers.md) - overview of current Parsec providers - [Parsec Converters](converters.md) - overview of current Parsec converters - [Parsec Authenticators](authenticators.md) - overview of current Parsec authenticators diff --git a/src/parsec_service/adding_provider.md b/src/parsec_service/adding_provider.md index 89ae85f3..62518e09 100644 --- a/src/parsec_service/adding_provider.md +++ b/src/parsec_service/adding_provider.md @@ -60,7 +60,7 @@ key in the keystore backend. Providers should implement the following policies t `psa_destroy_key` when implementing those `Provide` methods. The goal of those policies is to make sure, in a best-effort way, that key management operations -have the behaviour wanted: it is possible to create a key with the same name if the key +have the behavior wanted: it is possible to create a key with the same name if the key creation/deletion operation failed and that at any given time only valid keys can be used. Because of those policies focused on clients' convenience, it might be possible that some keys diff --git a/src/parsec_service/key_info_managers.md b/src/parsec_service/key_info_managers.md index 6153b369..aff780d7 100644 --- a/src/parsec_service/key_info_managers.md +++ b/src/parsec_service/key_info_managers.md @@ -18,8 +18,8 @@ the recommended choice for any new deployments. # On-Disk Key Info Manager -**Warning:** The on-disk KIM will be deprecated in future versions of the Parsec service in favour -of the SQLite manager described above. +**Warning:** The on-disk KIM will be deprecated in future versions of the Parsec service in favor of +the SQLite manager described above. The on-disk KIM stores the mapping between key identity and key information directly on disk, in a folder with a configurable path. diff --git a/src/parsec_service/source_code_structure.md b/src/parsec_service/source_code_structure.md index 651f8283..dc383dff 100644 --- a/src/parsec_service/source_code_structure.md +++ b/src/parsec_service/source_code_structure.md @@ -2,7 +2,7 @@ ## Introduction -This document presents the overall organisation of the source code repository, and provides pointers +This document presents the overall organization of the source code repository, and provides pointers to key definitions and implementations. ## Audience @@ -26,17 +26,17 @@ The API is closely aligned with the [Platform Security Architecture (PSA) Crypto API](https://github.com/ARMmbed/mbed-crypto/blob/psa-crypto-api/docs/PSA_Cryptography_API_Specification.pdf). PSA Crypto is specifically a C interface. This project takes the operations of that C interface and wraps each of them in an IPC [wire protocol](../parsec_client/wire_protocol.md). There is -intentionally a very close correpondence between the two APIs, and the contracts of the operations +intentionally a very close correspondence between the two APIs, and the contracts of the operations are identical in the majority of cases. However, the service also exposes a number of new operations that are designed to help clients consume it more easily. -The Parsec project is organised over [multiple repositories](https://github.com/parallaxsecond). The +The Parsec project is organized over [multiple repositories](https://github.com/parallaxsecond). The remainder of the document will examine the contents of some of these. ## The Parsec Repository The `parsec` repository contains the code for the service. The service is written in -[**Rust**](https://www.rust-lang.org). Rust projects are organised into modular units known as +[**Rust**](https://www.rust-lang.org). Rust projects are organized into modular units known as [**crates**](https://doc.rust-lang.org/beta/book/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html), each of which is formed of one or more [**modules**](https://doc.rust-lang.org/beta/book/ch07-02-defining-modules-to-control-scope-and-privacy.html), diff --git a/src/parsec_service/stability.md b/src/parsec_service/stability.md index 8ec8ed89..5bf049ca 100644 --- a/src/parsec_service/stability.md +++ b/src/parsec_service/stability.md @@ -39,7 +39,7 @@ The communication channels that need to be stable are (some of them are not in t 1. Communication with clients 1. Definition of requests/responses (their format) - 2. Definition of operation contracts (their intended behaviour) + 2. Definition of operation contracts (their intended behavior) 3. Definition of Listeners endpoints (how to contact Parsec) 2. Communication with authenticators 3. Communication received from the CLI invocation @@ -68,16 +68,16 @@ Let's look at each of the points above and check: | Stability Requirement | Stability Definition | Stability Enforcement | Stability Test | |--------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------| | Communication with clients (requests/responses) | Requests and responses must be understood correctly by different versions of the service/clients. | The Wire Protocol is [stable by design](../parsec_client/wire_protocol.md#wire-protocol-versions). | [Done](https://github.com/parallaxsecond/parsec/issues/388) | -| Communication with clients (operation contracts) | The behaviour of operations must remain the same for all versions of the service. | There is a [defined behaviour](https://parallaxsecond.github.io/parsec-book/parsec_client/operations/index.html) for all operations that is respected. | [Done](https://github.com/parallaxsecond/parsec/issues/389) | +| Communication with clients (operation contracts) | The behavior of operations must remain the same for all versions of the service. | There is a [defined behavior](https://parallaxsecond.github.io/parsec-book/parsec_client/operations/index.html) for all operations that is respected. | [Done](https://github.com/parallaxsecond/parsec/issues/389) | | Communication with clients (listeners endpoint) | Listeners endpoint must be discovered in a stable way. | A [service discovery mechanism](../parsec_client/api_overview.md#service-discovery) exists. | [Done](https://github.com/parallaxsecond/parsec/issues/390) | | Authenticators | Authentication requests sent by future stable versions of Parsec should be understood by the same version of the authenticators present on the system. | Unix Peer Crendentials: based on top of stable C standard library APIs. JWT SVID: authentication is based on the [SPIFFE Workload API](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Workload_API.md) which is a standard and should remain stable. | [Done](https://github.com/parallaxsecond/parsec/issues/391) | | CLI invocation | Old CLI invocations of Parsec should still work with for future stable Parsec versions. Optional flags should have the same defaults. | CLI flags should not be removed. Defaults should not be changed. New flags should be optional. | [Done](https://github.com/parallaxsecond/parsec/issues/392) | | Configuration file | Old configuration files should still work with future stable Parsec versions, with the same default for optional options. | Configuration options should not disappear in future stable Parsec versions. Configuration defaults should remain the same. New options should be optional. | [Done](https://github.com/parallaxsecond/parsec/issues/393) | | Persistent state (key mappings) | Old key mappings should still be read correctly by future stable Parsec versions. | The way the KIM persistently stores the mappings need to be backward-compatible in regards with reading/writing. | [Done](https://github.com/parallaxsecond/parsec/issues/394) for the Mbed Crypto, PKCS11 and TPM providers. | -| OS signals | OS signals should still have the same behaviour in future stable Parsec versions. | Signal handlers must not be removed in Parsec. | [Done](https://github.com/parallaxsecond/parsec/issues/395) | +| OS signals | OS signals should still have the same behavior in future stable Parsec versions. | Signal handlers must not be removed in Parsec. | [Done](https://github.com/parallaxsecond/parsec/issues/395) | | systemd communication | systemd should receive the same status information from Parsec in future stable versions. | Status notifications must not be removed. | [Done](https://github.com/parallaxsecond/parsec/issues/396) | | Dynamic libraries dependencies | Linking and loading the same versions of libraries should still work in future stable versions of Parsec. | Stable versions of Parsec should not require newer dependencies. | [Done](https://github.com/parallaxsecond/parsec/issues/397) and see [the list](#dynamic-libraries) | -| Environment variables | Environment variables should still have the same behaviour in future stable Parsec versions. | Environment variable behaviours must not be removed in Parsec. | [Done](https://github.com/parallaxsecond/parsec/issues/405) | +| Environment variables | Environment variables should still have the same behavior in future stable Parsec versions. | Environment variable behaviors must not be removed in Parsec. | [Done](https://github.com/parallaxsecond/parsec/issues/405) | | Hardware backends | Communication with hardware backends for crypto and key management should still work in future Parsec versions. | The communication channels with the hardware backends should remain the same. | [Done](https://github.com/parallaxsecond/parsec/issues/412) | | Build toolchain | Parsec build should not break for defined versions of the Rust compiler. | Each commit is tested with specific supported versions of the Rust compiler. | [Done](https://github.com/parallaxsecond/parsec/issues/408) | @@ -96,6 +96,6 @@ Crypto compliant version of Mbed Crypto, stability guarantees will be made on th The Trusted Service provider is currently built using a pre-release version of the Trusted Services library. We aim to keep the Parsec service aligned with recent revisions of the TS code, however since no release has been made, no guarantees can be offered about stability. At the time of -writing, no platform is officially supported for Trused Services deployments. +writing, no platform is officially supported for Trusted Services deployments. *Copyright 2021 Contributors to the Parsec project.* diff --git a/src/parsec_service/tests/existing_tests.md b/src/parsec_service/tests/existing_tests.md index 3e0dd251..a1d0314e 100644 --- a/src/parsec_service/tests/existing_tests.md +++ b/src/parsec_service/tests/existing_tests.md @@ -27,7 +27,7 @@ folder contain the configuration needed to run Parsec for the corresponding test |--------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | [All providers normal e2e tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/all_providers/normal.rs) | End-to-end tests on a service with all providers. Mostly to test core operations. | | [All providers cross-providers e2e tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/all_providers/cross.rs) | Test that the output of various operations from different providers is accepted by the other providers. | -| [All providers configuration e2e tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/all_providers/config) | These check if the behaviour of the service is correct before and after reloading with a different configuration. | +| [All providers configuration e2e tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/all_providers/config) | These check if the behavior of the service is correct before and after reloading with a different configuration. | | [All providers multitenancy e2e tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/all_providers/multitenancy.rs) | Test that multiple tenants of Parsec using different authentication methods can not access each other's keys. | | [Per provider normal tests](https://github.com/parallaxsecond/parsec/tree/master/e2e_tests/tests/per_provider/normal_tests) | E2E tests checking most cryptographic operations on a single provider. Parsec results are also verified with third party software crypto implementations (ring, the rsa crate, etc...). | | [Per provider key mappings tests](https://github.com/parallaxsecond/parsec/blob/main/e2e_tests/tests/per_provider/key_mappings.rs) | E2E tests checking that key created by an older version of Parsec can still be retrieved and used correctly. It also checks that wrong mappings are deleted. | @@ -68,7 +68,7 @@ run in `x86_64-linux-gnu`. ## In dependencies -The dependencies that we maintain in the `parallaxsecond` organisation also contain their own set of +The dependencies that we maintain in the `parallaxsecond` organization also contain their own set of integration and unit tests: `parsec-interface-rs`, `rust-psa-crypto`, `rust-tss-esapi`, and `rust-cryptoki`.