From a9e978effb4fc705b8b16f665062587f72af4528 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Mon, 25 Aug 2025 10:29:59 +0000 Subject: [PATCH] A few typo changes --- content/articles/2025-07-26-ctlog-1.md | 2 +- content/articles/2025-08-10-ctlog-2.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/articles/2025-07-26-ctlog-1.md b/content/articles/2025-07-26-ctlog-1.md index cd5c6e1..91c698a 100644 --- a/content/articles/2025-07-26-ctlog-1.md +++ b/content/articles/2025-07-26-ctlog-1.md @@ -14,7 +14,7 @@ subsequently it issued hundreds of fraudulent SSL certificates, some of which we man-in-the-middle attacks on Iranian Gmail users. Not cool. Google launched a project called **Certificate Transparency**, because it was becoming more common -that the root of trust given to _Certification Authorities_ could no longer be unilateraly trusted. +that the root of trust given to _Certification Authorities_ could no longer be unilaterally trusted. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious [[project](https://certificate.transparency.dev/)] to improve security online by bringing diff --git a/content/articles/2025-08-10-ctlog-2.md b/content/articles/2025-08-10-ctlog-2.md index f951d26..48ff2a5 100644 --- a/content/articles/2025-08-10-ctlog-2.md +++ b/content/articles/2025-08-10-ctlog-2.md @@ -14,7 +14,7 @@ subsequently it issued hundreds of fraudulent SSL certificates, some of which we man-in-the-middle attacks on Iranian Gmail users. Not cool. Google launched a project called **Certificate Transparency**, because it was becoming more common -that the root of trust given to _Certification Authorities_ could no longer be unilateraly trusted. +that the root of trust given to _Certification Authorities_ could no longer be unilaterally trusted. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious [[project](https://certificate.transparency.dev/)] to improve security online by bringing @@ -53,11 +53,11 @@ implementations, TesseraCT or Sunlight, he thinks would be a good fit. One thing with me: "The community needs _any_ static log operator, so if Google thinks TesseraCT is ready, by all means use that. The diversity will do us good!". -To find out if one or the other is 'ready' is partly on the software, but importantly also an the +To find out if one or the other is 'ready' is partly on the software, but importantly also on the operator. So I carefully take Sunlight out of its cardboard box, and put it onto the same Dell R630 that I used in my previous tests: two Xeon E5-2640 v4 CPUs for a total of 20 cores and 40 threads, -and 512GB of DDR4 memory. They also sport a SAS controller. In one machine I place 6pcs 1.2TB SAS3 -disks (HPE part number EG1200JEHMC), and in the second machine I place 6pcs of 1.92TB enterprise +and 512GB of DDR4 memory. They also sport a SAS controller. In one machine I place 6 pcs 1.2TB SAS3 +drives (HPE part number EG1200JEHMC), and in the second machine I place 6pcs of 1.92TB enterprise storage (Samsung part number P1633N19). ### Sunlight: setup @@ -70,7 +70,7 @@ tools is easy enough, there are three main tools: 1. ***skylight***: Which serves the read-path. `/checkpoint` and things like `/tile` and `/issuer` are served here in a spec-compliant way. -The YAML configuration file is staight forward, and can define and handle multiple logs in one +The YAML configuration file is straightforward, and can define and handle multiple logs in one instance, which sets it apart from TesseraCT which can only handle one log per instance. There's a `submissionprefix` which `sunlight` will use to accept writes, and a `monitoringprefix` which `skylight` will use for reads.