From 6ee8ac5bb191b80e1375ec771f42de2612b089e1 Mon Sep 17 00:00:00 2001
From: Tai Lam <47955724+taivlam@users.noreply.github.com>
Date: Tue, 14 May 2024 16:56:13 +0000
Subject: [PATCH] Fix typo in split-gpg.md

Add missing period
---
 user/security-in-qubes/split-gpg.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 8335d9e6..eeb6f92b 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -32,7 +32,7 @@ While this might be true (unless the attacker can find a usually-very-expensive-
 However, there is usually nothing that could stop the attacker from requesting the smart card to perform decryption of all the user documents the attacker has found or need to decrypt.
 In other words, while protecting the user's private key is an important task, we should not forget that ultimately it is the user data that are to be protected and that the smart card chip has no way of knowing the requests to decrypt documents are now coming from the attacker's script and not from the user sitting in front of the monitor.
 (Similarly the smart card doesn't make the process of digitally signing a document or a transaction in any way more secure -- the user cannot know what the chip is really signing.
-Unfortunately this problem of signing reliability is not solvable by Split GPG)
+Unfortunately this problem of signing reliability is not solvable by Split GPG.)
 
 With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
 This way it would be easy to spot unexpected requests to decrypt documents.