[PATCH] doc: Fix several typos in SECURITY.md
Stan Ulbrych
stanulbrych@gmail.com
Tue Oct 13 17:03:30 GMT 2026
Hello!
The attached patch fixes several typos/grammatical errors I noticed in
SECURITY.md. Apologies if anything is incorrect with the patch format, I've
not contributed here before. Please let me know and I'll be happy to adjust
it. :-)
Signed-off-by: Stan Ulbrych stan@python.org
>From 46dc866577ca4127cdf8b9ee0d04ca06dd7a292f Mon Sep 17 00:00:00 2001
From: Stan Ulbrych <stan@python.org>
Date: Tue, 13 Oct 2026 17:58:27 +0100
Subject: [PATCH] doc: Fix several typos in `SECURITY.md`
---
SECURITY.md | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/SECURITY.md b/SECURITY.md
index 82275a5f6f..a22a8ad77f 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -14,14 +14,14 @@ especially for instructions on reporting issues
privately.
Most security vulnerabilities in the GNU C Library materialize only after
an
application uses functionality in a specific way. Therefore, it is
sometimes
difficult to determine if a defect in the GNU C Library constitutes a
-vulnerability as such. The follow guidelines can help with a decision.
+vulnerability as such. The following guidelines can help with a decision.
* Buffer overflows should be treated as security bugs if it is conceivable
that
the data triggering them can come from an untrusted source.
* Other bugs that cause memory corruption which is likely exploitable
should be
treated as security bugs.
-* Information disclosure can be security bugs, especially if exposure
through
- applications can be determined.
+* Information disclosure issues can be security bugs, especially if
exposure
+ through applications can be determined.
* Memory leaks and races are security bugs if they cause service breakage.
* Stack overflow through unbounded alloca calls or variable-length arrays
are
security bugs if it is conceivable that the data triggering the overflow
@@ -68,7 +68,7 @@ with certain classes of patterns.
Consequently, certain issues which can be triggered only with crafted
patterns
(either during compilation or execution) are treated as regular bugs and
not
-security issues. Examples of such issues would include (but is not limited
+security issues. Examples of such issues would include (but are not
limited
to):
* Running out of memory through valid use of malloc
@@ -109,7 +109,7 @@ The `ldd` tool is not expected to be used with
untrusted executables.
#### Post-exploitation countermeasures
Certain features have been added to the library only to make exploitation
of
-security bugs (mainly for code execution) more difficult. Examples
includes
+security bugs (mainly for code execution) more difficult. Examples include
the stack smashing protector, function pointer obfuscation, vtable
validation
for stdio stream handles, and various heap consistency checks. Failure of
such
countermeasures to stop exploitation of a different vulnerability is not a
@@ -157,7 +157,7 @@ The following links are helpful for finding untriaged
bugs:
For changes to master, the regular [consensus-driven
process](https://sourceware.org/glibc/wiki/Consensus) must be followed. It
makes sense to obtain consensus in private, to ensure that the patch is
likely
-in a committable state, before disclosing an emboargoed vulnerability.
+in a committable state, before disclosing an embargoed vulnerability.
Security backports to release branches need to follow the
[release process](https://sourceware.org/glibc/wiki/Release#General_policy
).
--
2.55.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20261013/a8eec9ca/attachment.htm>
More information about the Libc-alpha
mailing list