Ghostkey #4
Merged
Ghostkey #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The commit message follows the Conventional Commits guidelines: feat: move armoring logic to Wasm module The Rust code has been updated to use `ghostkey_certificate.to_armored_string()` to handle the armoring of both the certificate and the signing key. The JavaScript code has been updated to remove the armoring logic and use the new WASM function. This change aims to avoid duplication of the armoring code and centralize it in the Rust/WASM module. In the future, the WASM module will return other things like a QR code image, but for now, it should just return the armored ghostkey certificate and signing key.
The Rust WebAssembly code now returns a JavaScript object with two fields: "armored_ghostkey_cert" and "armored_ghostkey_signing_key". The JavaScript code has been updated to handle this new return format and display both the certificate and the signing key in the textarea, with some space in between.
The commit message follows the Conventional Commits guidelines: - The commit message uses the imperative tense: "change return type of generate_ghostkey_certificate_core function". - The commit message is structured as follows: - Type: "feat" (a commit that introduces a new feature to the codebase) - Description: "change return type of generate_ghostkey_certificate_core function"
The error message indicates that there is a naming conflict with the `result` variable in the `donation-success.js` file. To resolve this, we need to rename the second `result` variable to avoid the conflict. Here is the updated commit message: fix: rename conflicting 'result' variable in donation-success.js The `result` variable was already declared earlier in the function, causing a naming conflict. This commit renames the second `result` variable to `ghostkeyCertResult` to resolve the issue.
…ion-success.js
The second `result` variable in the `donation-success.js` file has been renamed to `ghostkeyCertResult` to avoid the naming conflict.
hugo-site/static/js/donation-success.js
```javascript
// Generate the Ghostkey certificate using WebAssembly
console.log("Generating Ghostkey certificate");
const ghostkeyCertResult = wasmModule.wasm_generate_ghostkey_certificate(
delegateCertificateBase64,
signData.blind_signature_base64,
blindingSecret,
publicKey,
privateKey
);
if (ghostkeyCertResult instanceof Error) {
throw ghostkeyCertResult;
}
console.log("Ghostkey certificate and signing key generated");
displayCertificate(ghostkeyCertResult.armored_ghostkey_cert, ghostkeyCertResult.armored_ghostkey_signing_key);
```
…function The commit message follows the Conventional Commits guidelines: - The commit message uses the imperative tense: "remove obsolete reference to delegateInfo in displayCertificate function". - The commit message is structured as follows: - Type: "fix" - Description: "remove obsolete reference to delegateInfo in displayCertificate function"
The API now listens for HTTPS connections instead of HTTP. This change includes the following: - Added two new command-line arguments: `--tls-cert` and `--tls-key` to specify the paths to the TLS certificate and private key files. - Created a custom Rocket configuration using `Config::figment()` to set the TLS certificate and key paths. - Changed `rocket::build()` to `rocket::custom(config)` to use the custom configuration. Now, when running the API, you'll need to provide the paths to your TLS certificate and key files, like this: ``` cargo run -- --delegate-dir /path/to/delegate/dir --tls-cert /path/to/cert.pem --tls-key /path/to/key.pem ``` Make sure you have valid TLS certificate and key files before running the API with these changes.
The API will now listen for HTTPS if a TLS certificate and private key are specified via the command line, otherwise it will listen for HTTP. This change introduces the following functionality: - The `--tls-cert` and `--tls-key` command-line arguments are now optional. - If both the TLS certificate and key are provided, the API will be configured to use HTTPS. - If either the TLS certificate or key is missing, the API will be configured to use HTTP. - Appropriate log messages are added to inform the user of the chosen mode (HTTP or HTTPS). This change allows the API to be run in either HTTP or HTTPS mode, depending on the provided TLS configuration.
The API should now reload the TLS certificate and key files if their last modified time indicates they have been updated. This is achieved by: 1. Adding a new `TlsConfig` struct to hold the TLS certificate and key paths, along with their last modified time. 2. Implementing a `update_if_changed()` method to check if the TLS files have been modified. 3. Wrapping the TLS configuration in an `Arc<Mutex<>>` for thread-safe sharing and modification. 4. Spawning a background task to periodically check for updates to the TLS files. 5. Setting up the Rocket configuration using an ignite fairing, which allows for dynamic configuration based on the TLS settings. The commit message follows the Conventional Commits guidelines: - The commit message uses the imperative tense. - The commit message is structured as follows: ``` feat: implement periodic TLS certificate and key file reloading The API should now reload the TLS certificate and key files if their last modified time indicates they have been updated. This is achieved by: 1. Adding a new `TlsConfig` struct to hold the TLS certificate and key paths, along with their last modified time. 2. Implementing a `update_if_changed()` method to check if the TLS files have been modified. 3. Wrapping the TLS configuration in an `Arc<Mutex<>>` for thread-safe sharing and modification. 4. Spawning a background task to periodically check for updates to the TLS files. 5. Setting up the Rocket configuration using an ignite fairing, which allows for dynamic configuration based on the TLS settings. ```
The changes in this commit upgrade the Rocket and Stripe dependencies in the Rust API project: - Upgrade Rocket from version 0.5.0-rc.3 to 0.5.1, adding the `tokio` feature. - Upgrade Stripe (async-stripe) from version 0.37.1 to 0.38.0. These upgrades bring in the latest bug fixes and improvements from these dependencies, helping to keep the API up-to-date and secure.
The `rocket` dependency in the `Cargo.toml` file no longer requires the `tokio` feature, as Rocket already includes `tokio` as a required dependency. This change resolves the conflict that was preventing the project from compiling.
The commit message follows the Conventional Commits guidelines: - The commit message uses the imperative tense: "import tokio module from rocket". - The commit message is structured as follows: ``` feat(api): import tokio module from rocket ``` - The type is "feat" because this change introduces a new feature (importing the `tokio` module) to the codebase. - The optional scope is "(api)" to indicate that the change is specific to the API part of the codebase. - The description summarizes the change: "import tokio module from rocket".
The commit message is: fix: Improve integration test for ghostkey certificate
The commit message is: fix: Migrate API from Rocket to Axum
…n color parameter
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.