Fix typos

README.md

@@ -54,7 +54,7 @@ ntpd-rs.pool.ntp.org:123/162.159.200.123:123 (4): +0.000111±0.000076(±0.004066
 
 Servers:
 ```
-The top part shows the overal quality of the time synchronization, and the time sources section shows which servers are used as well as offsets and uncertainties of those individual servers.
+The top part shows the overall quality of the time synchronization, and the time sources section shows which servers are used as well as offsets and uncertainties of those individual servers.
 
 For more details on how to install and use ntpd-rs, see our [documentation website].
 

docs/development/ca.md

@@ -4,7 +4,7 @@
 
     Setting up your own CA is not recommended except for development purposes
     and setting up internal-only networks. For all other purposes, we would
-    recommend to use a widely trusted CA for issueing certificates. See the
+    recommend to use a widely trusted CA for issuing certificates. See the
     [NTS guide](../guide/nts.md) for more information.
 
 Setting up NTS-KE when your server has no public domain name is still possible
@@ -92,7 +92,7 @@ openssl x509 -req -in ntpd-rs.test.csr -CA ca.pem -CAkey ca.key -CAcreateserial
 The above command gives the certificate a period validity of 5 years. If a
 different lifetime is desired, change the number following the `-days` argument
 to the number of days the certificate should be valid. The generated certificate
-should be concattenated together with the CA certificate, as ntpd-rs needs the
+should be concatenated together with the CA certificate, as ntpd-rs needs the
 full certificate chain in order to operate. We can use a simple command to do
 this:
 

docs/development/threat-model.md

@@ -194,7 +194,7 @@ We model the following assets:
         <td>Create - N/A</td>
         <td bgcolor="red">Read - Never</td>
         <td>Create - N/A</td>
-        <td bgcolor="orange">Read - Someitmes</td>
+        <td bgcolor="orange">Read - Sometimes</td>
         <td bgcolor="orange">Create - Sometimes</td>
         <td bgcolor="orange">Read - Sometimes</td>
         <td bgcolor="red">Create - Never</td>

docs/guide/installation.md

@@ -50,8 +50,8 @@ main NTP daemon. Running it from the command line to test it should provide outp
 2023-09-04T12:01:44.071735Z  INFO ntpd::daemon::system: new source source_id=SourceId(2) addr=162.159.200.1:123 spawner=SpawnerId(1)
 2023-09-04T12:01:44.071944Z  INFO ntpd::daemon::system: new source source_id=SourceId(3) addr=45.138.55.62:123 spawner=SpawnerId(1)
 2023-09-04T12:01:44.072150Z  INFO ntpd::daemon::system: new source source_id=SourceId(4) addr=213.154.236.182:123 spawner=SpawnerId(1)
-2023-09-04T12:01:44.084626Z  INFO ntp_proto::algorithm::kalman: No concensus cluster found
-2023-09-04T12:01:44.085422Z  INFO ntp_proto::algorithm::kalman: No concensus cluster found
+2023-09-04T12:01:44.084626Z  INFO ntp_proto::algorithm::kalman: No consensus cluster found
+2023-09-04T12:01:44.085422Z  INFO ntp_proto::algorithm::kalman: No consensus cluster found
 2023-09-04T12:01:44.086879Z  INFO ntp_proto::algorithm::kalman: Offset: 2.3686082232975885+-72.6249392570874ms, frequency: 0+-5773502.691896258ppm
 2023-09-04T12:01:44.087846Z  INFO ntp_proto::algorithm::kalman: Offset: 2.7204471636925773+-61.339759726948046ms, frequency: 0+-5000000.000000001ppm
 ```

docs/guide/migrating-chrony.md

@@ -75,7 +75,7 @@ The current version of ntpd-rs does not yet support local reference clocks, but
 The minimum number of sources needed for time synchronization in ntpd-rs is configured through `minimum-agreeing-sources`:
 ```toml
 [synchronization]
-mininum-agreeing-sources = <minsources>
+minimum-agreeing-sources = <minsources>
 ```
 Note that although the effect of this option is the same as chrony's `minsources`, the default in ntpd-rs is 3, rather than the default 1 source required by chrony. Although 3 is recommended for security, it may not be appropriate for all configurations, particularly configurations where few remote sources are configured.
 

docs/guide/migrating-ntpd.md

@@ -55,7 +55,7 @@ The current version of ntpd-rs does not yet support local reference clocks, but
 The minimum number of time sources needed for time synchronization in ntpd-rs is configured through `minimum-agreeing-sources`:
 ```toml
 [synchronization]
-mininum-agreeing-sources = <minsources>
+minimum-agreeing-sources = <minsources>
 ```
 If fewer agreeing source are available, no synchronization is performed and the clock will drift. This option is a combination of ntpd's `minclock` and `minsane`. Its default value is 3, the recommended value from a security perspective. In ntpd, a default of 3 is used for `minclock` and 1 for `minsane`.
 

docs/guide/migrating-ntpsec.md

@@ -76,7 +76,7 @@ The current version of ntpd-rs does not yet support local reference clocks, but
 The minimum number of time sources needed for time synchronization in ntpd-rs is configured through `minimum-agreeing-sources`:
 ```toml
 [synchronization]
-mininum-agreeing-sources = <minsources>
+minimum-agreeing-sources = <minsources>
 ```
 If fewer agreeing source are available, no synchronization is performed and the clock will drift. This option is a combination of ntpd's `minclock` and `minsane`. Its default value is 3, the recommended value from a security perspective. In ntpd, a default of 3 is used for `minclock` and 1 for `minsane`.
 

docs/guide/nts.md

@@ -64,7 +64,7 @@ once to ensure that a third party cannot track its connection, and it receives a
 new cookie with each server response.
 
 These cookies are an opaque bag of bytes for the client, and the server can put
-in them whatever it finds usefull for identifying the proper keys for that
+in them whatever it finds useful for identifying the proper keys for that
 particular client. Cookies do however have to be unique, a cookie cannot be
 reused once a message with it was sent. If the client ever runs out of cookies
 (a cookie is lost whenever an NTP message or the response to that message got
@@ -100,7 +100,7 @@ Once the NTS-KE server is setup the NTP server you have setup in your
 configuration will automatically start responding to valid NTS messages, there
 is no additional setup required.
 
-Getting a certificate for your server can be a quite involved proces. We would
+Getting a certificate for your server can be a quite involved process. We would
 recommend you use a [Let's Encrypt][1] ACME client for setting up a TLS
 certificate (similarly to how you would set this up for a webserver). Below you
 will find some examples using some popular clients.
@@ -160,7 +160,7 @@ guide. Please read the [certbot documentation][3] for more details.
 
 Certbot automatically sets up a task that renews these certificates, because
 Let's Encrypt certificates are valid for only 90 days. The `--deploy-hook`
-argument tells cerbot to restart the ntpd-rs daemon whenever a new certificate
+argument tells certbot to restart the ntpd-rs daemon whenever a new certificate
 is issued, because ntpd-rs does not automatically reload the certificate files.
 
 We can now update our configuration with the paths of the generated certificate

docs/guide/security-guidance.md

@@ -13,7 +13,7 @@ Many of the measures against missteering increase the risk of unavailability and
 
 For instance, the risk of missteering is large if your system deals with public key cryptography. The security of the current web certificate system hinges on having a rough (<1day) consensus on what time it is. Similarly, the security and functioning of your applications may also be affected. A tradeoff that limits the risk of missteering is probably the correct choice.
 
-On the other hand, a lack of synchronization can cause issues in a distributed system. Such systems require a small upper bound on the time difference between the machines they run on. When time synchronization fails the clocks can quickly drift outside of these bounds and the system may fail. Furthermore it may be most important that the machines are synchronized with each other, not necesarilly that they use the true time. Configuring ntpd-rs for maximum availability seems the best approach for this scenario.
+On the other hand, a lack of synchronization can cause issues in a distributed system. Such systems require a small upper bound on the time difference between the machines they run on. When time synchronization fails the clocks can quickly drift outside of these bounds and the system may fail. Furthermore it may be most important that the machines are synchronized with each other, not necessarily that they use the true time. Configuring ntpd-rs for maximum availability seems the best approach for this scenario.
 
 Since there is no universally best solution to this tradeoff, you as the end user will have to consider which of these factors weighs more heavily, and adjust your configuration accordingly.
 

ntp-proto/src/algorithm/kalman/config.rs

@@ -56,7 +56,7 @@ pub struct AlgorithmConfig {
 
     /// Maximum source uncertainty before we start disregarding it
     /// Note that this is combined uncertainty due to noise and
-    /// possible assymetry error (see also weights below). (seconds)
+    /// possible asymmetry error (see also weights below). (seconds)
     #[serde(default = "default_maximum_source_uncertainty")]
     pub maximum_source_uncertainty: f64,
     /// Weight of statistical uncertainty when constructing

ntp-proto/src/algorithm/kalman/mod.rs

@@ -195,7 +195,7 @@ impl<C: NtpClock, SourceId: Hash + Eq + Copy + Debug> KalmanClockController<C, S
                 self.timedata.leap_indicator = leap;
             }
 
-            // After a succesfull measurement we are out of startup.
+            // After a successful measurement we are out of startup.
             self.in_startup = false;
 
             StateUpdate {

ntp-proto/src/algorithm/kalman/source.rs

@@ -51,7 +51,7 @@
 /// 1   0
 /// 0 t_m-t_p
 ///
-/// To estimate the measurement noise, the variance s of the tranmission
+/// To estimate the measurement noise, the variance s of the transmission
 /// delays r is used. Writing r as r1 - r2, where r1 is the time
 /// difference on the client-to-server leg and r2 the time difference on
 /// the server to client leg, we have Var(D) = Var(1/2 (r1 + r2)) = 1/4
@@ -111,7 +111,7 @@ impl KalmanState {
             return *self;
         }
 
-        // Time step paremeters
+        // Time step parameters
         let delta_t = (time - self.time).to_seconds();
         let update = Matrix::new([[1.0, delta_t], [0.0, 1.0]]);
         let process_noise = Matrix::new([
@@ -438,7 +438,7 @@ impl SourceFilter {
             return false;
         }
 
-        // This was a valid measurement, so no matter what this represents our current itertation time
+        // This was a valid measurement, so no matter what this represents our current iteration time
         // for the purposes of synchronizing
         self.last_iter = measurement.localtime;
 
@@ -519,7 +519,7 @@ impl SourceState {
         }))
     }
 
-    // Returs whether the clock may need adjusting.
+    // Returns whether the clock may need adjusting.
     pub fn update_self_using_measurement(
         &mut self,
         source_defaults_config: &SourceDefaultsConfig,

ntp-proto/src/algorithm/mod.rs

@@ -35,9 +35,9 @@ pub struct StateUpdate<SourceId, ControllerMessage> {
     pub next_update: Option<Duration>,
 }
 
-// Note: this default implementation is neccessary since the
+// Note: this default implementation is necessary since the
 // derive only works if SourceId is Default (which it isn't
-// neccessarily)
+// necessarily)
 impl<SourceId, ControllerMessage> Default for StateUpdate<SourceId, ControllerMessage> {
     fn default() -> Self {
         Self {
@@ -60,7 +60,7 @@ pub trait TimeSyncController: Sized + Send + 'static {
         SourceMessage = Self::SourceMessage,
     >;
 
-    /// Create a new clock controller controling the given clock
+    /// Create a new clock controller controlling the given clock
     fn new(
         clock: Self::Clock,
         synchronization_config: SynchronizationConfig,

ntp-proto/src/config.rs

@@ -236,7 +236,7 @@ pub struct SynchronizationConfig {
 
     /// The maximum amount the system clock is allowed to change in a single go
     /// before we conclude something is seriously wrong. This is used to limit
-    /// the changes to the clock to reasonable ammounts, and stop issues with
+    /// the changes to the clock to reasonable amounts, and stop issues with
     /// remote servers from causing us to drift too far.
     ///
     /// Note that this is not used during startup. To limit system clock changes

ntp-proto/src/identifiers.rs

@@ -91,7 +91,7 @@ mod tests {
         let b = ReferenceId::from_bytes(rep);
         assert_eq!(a, b);
 
-        // TODO: Generate and add a testcase for ipv6 adresses once
+        // TODO: Generate and add a testcase for ipv6 addresses once
         // we have access to an ipv6 network.
     }
 }

ntp-proto/src/ipfilter.rs

@@ -59,7 +59,7 @@ impl BitTree {
             // To calculate the child index we need to know how many symbols smaller
             // than our symbol are not decided here. We do this by generating the bitmap
             // of symbols neither in in or out, then masking out all symbols >=cur
-            // and finaly counting how many are left.
+            // and finally counting how many are left.
             let next_idx =
                 node.child_offset + (!(node.inset | node.outset) & (cur - 1)).count_ones();
             node = &self.nodes[next_idx as usize];
@@ -108,7 +108,7 @@ impl BitTree {
             match segment.first().copied() {
                 // Probably empty, unless covered earlier, but we fix that later
                 None => node.outset |= 1 << i,
-                // Definetly covered, mark all that is needed
+                // Definitely covered, mark all that is needed
                 // Note that due to sorting order, len here
                 // is guaranteed to be largest amongst all
                 // parts of the segment

ntp-proto/src/nts_pool_ke.rs

@@ -60,7 +60,7 @@ impl SupportedAlgorithmsDecoder {
     }
 }
 
-/// Pool KE decoding records fron the client
+/// Pool KE decoding records from the client
 #[derive(Debug, Default)]
 pub struct ClientToPoolDecoder {
     decoder: NtsRecordDecoder,

ntp-proto/src/nts_record.rs

@@ -2236,7 +2236,7 @@ mod test {
             cookie_data: EXAMPLE_COOKIE_DATA.to_vec(),
         };
 
-        // this fails. In theory it's allright if the protocol ID is not 0,
+        // this fails. In theory it's alright if the protocol ID is not 0,
         // but we do not support any. (we assume ntpv5 has the same behavior as ntpv4 here)
         let records = [
             cookie.clone(),

ntp-proto/src/packet/extension_fields.rs

@@ -603,7 +603,7 @@ impl<'a> ExtensionFieldData<'a> {
             };
 
             // the authenticated extension fields are always followed by the encrypted extension
-            // field. We don't (currently) encode a MAC, so the minimum size per RFC 7822 is 16 octecs
+            // field. We don't (currently) encode a MAC, so the minimum size per RFC 7822 is 16 octets
             let minimum_size = 16;
 
             for field in &self.authenticated {
@@ -1059,7 +1059,7 @@ mod tests {
         let ef = ExtensionField::decode(raw, ExtensionHeaderVersion::V4).unwrap();
 
         let ExtensionField::DraftIdentification(ref parsed) = ef else {
-            panic!("Unexpected extensionfield {ef:?}... expected DraftIdentification");
+            panic!("Unexpected extension field {ef:?}... expected DraftIdentification");
         };
 
         assert_eq!(parsed, test_id);
@@ -1134,7 +1134,7 @@ mod tests {
             .unwrap();
         assert_eq!(w.len(), expected_size);
 
-        // NOTE: encryped fields do not have a minimum_size
+        // NOTE: encrypted fields do not have a minimum_size
     }
 
     #[test]
@@ -1286,7 +1286,7 @@ mod tests {
     }
 
     #[test]
-    fn serialize_untrused_fields() {
+    fn serialize_untrusted_fields() {
         let cookie = ExtensionField::NtsCookie(Cow::Borrowed(&[0; 16]));
 
         let data = ExtensionFieldData {
@@ -1312,7 +1312,7 @@ mod tests {
     }
 
     #[test]
-    fn serialize_untrused_fields_smaller_than_minimum() {
+    fn serialize_untrusted_fields_smaller_than_minimum() {
         let cookie = ExtensionField::NtsCookie(Cow::Borrowed(&[0; 4]));
 
         let data = ExtensionFieldData {
@@ -1400,7 +1400,7 @@ mod tests {
         let n = cursor.position() as usize;
         let slice = &w.as_slice()[..n];
 
-        // now use a differnt (valid) cipher for deserialization
+        // now use a different (valid) cipher for deserialization
         let c2s = [0; 32];
         let cipher = AesSivCmac256::new(c2s.into());
 

ntp-proto/src/packet/mod.rs

@@ -767,7 +767,7 @@ impl<'a> NtpPacket<'a> {
                         .into_iter()
                         .filter(|ef| matches!(ef, ExtensionField::UniqueIdentifier(_)))
                         .collect(),
-                    // Ignore encrypted so as not to accidentaly leak anything
+                    // Ignore encrypted so as not to accidentally leak anything
                     untrusted: vec![],
                 },
                 mac: None,
@@ -841,7 +841,7 @@ impl<'a> NtpPacket<'a> {
                 efdata: ExtensionFieldData {
                     authenticated: vec![],
                     encrypted: vec![],
-                    // Ignore encrypted so as not to accidentaly leak anything
+                    // Ignore encrypted so as not to accidentally leak anything
                     untrusted: packet_from_client
                         .efdata
                         .untrusted
@@ -858,7 +858,7 @@ impl<'a> NtpPacket<'a> {
                 efdata: ExtensionFieldData {
                     authenticated: vec![],
                     encrypted: vec![],
-                    // Ignore encrypted so as not to accidentaly leak anything
+                    // Ignore encrypted so as not to accidentally leak anything
                     untrusted: packet_from_client
                         .efdata
                         .untrusted
@@ -925,7 +925,7 @@ impl<'a> NtpPacket<'a> {
                 efdata: ExtensionFieldData {
                     authenticated: vec![],
                     encrypted: vec![],
-                    // Ignore encrypted so as not to accidentaly leak anything
+                    // Ignore encrypted so as not to accidentally leak anything
                     untrusted: packet_from_client
                         .efdata
                         .untrusted
@@ -942,7 +942,7 @@ impl<'a> NtpPacket<'a> {
                 efdata: ExtensionFieldData {
                     authenticated: vec![],
                     encrypted: vec![],
-                    // Ignore encrypted so as not to accidentaly leak anything
+                    // Ignore encrypted so as not to accidentally leak anything
                     untrusted: packet_from_client
                         .efdata
                         .untrusted