From 13f61206a75dc525122c0d81f5ef2e732e7ecb94 Mon Sep 17 00:00:00 2001
From: Marno van der Maas <34654485+marnovandermaas@users.noreply.github.com>
Date: Wed, 28 Aug 2024 21:04:49 +0100
Subject: [PATCH] Minor changes to safe language myth blog

---
 _posts/2024-08-28-cheri-myths-safe-languages.markdown | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/_posts/2024-08-28-cheri-myths-safe-languages.markdown b/_posts/2024-08-28-cheri-myths-safe-languages.markdown
index 940dd8a..a487d46 100644
--- a/_posts/2024-08-28-cheri-myths-safe-languages.markdown
+++ b/_posts/2024-08-28-cheri-myths-safe-languages.markdown
@@ -113,7 +113,6 @@ This may be in the form of timing side channels, or more subtle things such as c
 This doesn't always apply.
 For more common tasks, the metaprogramming facilities in a higher-level language may make the rewrite significantly simpler to write and maintain than a C original.
 
-
 ## CHERI does not fix bugs for you
 
 CHERI doesn't guarantee that your code is free from memory-safety errors, it guarantees that any memory-safety bugs will trap and not affect confidentiality or integrity of your program.
@@ -180,7 +179,7 @@ The [`cheriot-audit` tool](https://github.com/CHERIoT-Platform/cheriot-audit) le
 You can reason about the damage from a compromise even if an attacker can gain arbitrary-code execution in a compartment.
 For supply-chain security, you should assume that a third-party component is compromised and includes malicious code.
 CHERIoT lets you reason about what it can do in these cases.
-In contrast, if a Java or Rust component is malicious and uses (intentional or otherwise) unsafe language features, it can to anything that the program can do.
+In contrast, if a Java or Rust component is malicious and uses (intentional or otherwise) unsafe language features, it can do anything that the program can do.
 
 ## The future should be safe languages on CHERI