ossf
diff --git a/‎README.md
Lines changed: 3 additions & 3 deletions b/‎README.md
Lines changed: 3 additions & 3 deletions
diff --git a/‎docs/Compiler-Hardening-Guides/Compiler-Annotations-for-C-and-C++.md
Lines changed: 5 additions & 5 deletions b/‎docs/Compiler-Hardening-Guides/Compiler-Annotations-for-C-and-C++.md
Lines changed: 5 additions & 5 deletions
@@ -77,17 +77,17 @@ Our work is organized into several discrete-yet-related projects that help us ac
 | Effort                  |     Description           |       Git Repo        | Slack Channel | Mailing List |
 | ------------------      | ------------------------  |  -------------------  |  -----------  |  ----------  |
 | Best Practices Guides   | Longer reference documents on implementing specific secure techniques   | - [Compiler Annotations for C and C++ (incubating)](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Annotations-for-C-and-C++.html), </p> - [Compiler Options Hardening Guide for C and C++](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++), </p> - [Existing Guidelines for Developing and Distributing Secure Software](https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Existing%20Guidelines%20for%20Developing%20and%20Distributing%20Secure%20Software.md), </p> - [Package Manager Best Practices (incubating)](https://github.com/ossf/package-manager-best-practices), </p> - [npm Best Practices Guide](https://github.com/ossf/package-manager-best-practices/blob/main/published/npm.md), </p> - [Source Code Management Platform Configuration Best Practices](docs/SCM-BestPractices/README.md), </p> - [Secure Coding Guide for Python](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Secure-Coding-Guide-for-Python), | - [#wg-best-practices-compilers](https://openssf.slack.com/archives/C07LH7RH8MT), </p> - [#wg-best-practices-scm](https://openssf.slack.com/archives/C058EC1EZ5Y) | |
-|  Concise Guides SIGs   |  Quick Guidance around Open Source Software Develpment Good Practices | - [Concise Guide for Developing More Secure Software](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software), </p> - [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software) |  | [Mailing List](https://lists.openssf.org/g/openssf-wg-best-practices) |
+|  Concise Guides SIGs   |  Quick Guidance around Open Source Software Development Good Practices | - [Concise Guide for Developing More Secure Software](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software), </p> - [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software) |  | [Mailing List](https://lists.openssf.org/g/openssf-wg-best-practices) |
 | Education SIG - (incubating) | To provide industry standard secure software development training materials that will educate learners of all levels and backgrounds on how to create, compose, deploy, and maintain software securely using best practices in cyber and application security. | [EDU.SIG](https://github.com/ossf/education/) (course links are there) | [stream-01-security-education](https://openssf.slack.com/archives/C03FW3YGXH9)  |  [Mailing List](https://lists.openssf.org/g/openssf-sig-education)  |
 |[OpenSSF Best Practices Badge - formerly CII Best Practices badge](https://www.bestpractices.dev/) | Identifies FLOSS best practices & implements a badging system for those practices, | [best-practices-badge](https://github.com/coreinfrastructure/best-practices-badge) | | |
 | [OpenSSF Scorecard](https://scorecard.dev/) | Automate analysis on the security posture of open source projects | [OpenSSF Scorecard](https://github.com/ossf/scorecard) | [#scorecard](https://openssf.slack.com/archives/C0235AR8N2C) | [Contribute!](https://github.com/ossf/scorecard?tab=readme-ov-file#contribute) |
 | [OpenSSF Scorecard — Allstar](https://github.com/ossf/allstar) | Monitors GitHub organizations or repositories for adherence to security best practices | [Allstar](https://github.com/ossf/allstar) | [#allstar](https://openssf.slack.com/archives/C02UQ2RL0HM) | [Contribute!](https://github.com/ossf/scorecard?tab=readme-ov-file#contribute) |
-| [OpenSSF Security Baseline](https://github.com/ossf/security-baseline) | Provide avenue for particpants to help evolve the OpenSSF security baseline into a security baseline that can be applied to a broad range of software-based projects |[OpenSSF Security Baseline](https://github.com/ossf/security-baseline) | [#sig-security-baseline](https://app.slack.com/client/T019QHUBYQ3/C07DC6TT2QY) | [Mailing List](https://lists.openssf.org/g/openssf-sig-security-baseline) |
+| [OpenSSF Security Baseline](https://github.com/ossf/security-baseline) | Provide avenue for participants to help evolve the OpenSSF security baseline into a security baseline that can be applied to a broad range of software-based projects |[OpenSSF Security Baseline](https://github.com/ossf/security-baseline) | [#sig-security-baseline](https://app.slack.com/client/T019QHUBYQ3/C07DC6TT2QY) | [Mailing List](https://lists.openssf.org/g/openssf-sig-security-baseline) |
 | [Secure Software Development Fundamentals - online course](https://openssf.org/training/courses/)  |Teach software developers fundamentals of developing secure software  | [GitHub](https://github.com/ossf/secure-sw-dev-fundamentals) | | |
 | Memory Safety SIG | The Memory Safety SIG is a group working within the OpenSSF's Best Practices Working Group formed to advance and deliver upon The OpenSSF's Mobilization Plan - Stream 4.   |[Git Repo](https://github.com/ossf/Memory-Safety) | [Slack](https://openssf.slack.com/archives/C03G8NZH58R) | [Mailing List](https://lists.openssf.org/g/openssf-sig-memory-safety) |
 |  The Security Toolbelt | Assemble a “sterling” collection of capabilities (**software frameworks, specifications, and human and automated processes**) that work together to **automatically list, scan, remediate, and secure the components flowing through the software supply chain** that come together as software is written, built, deployed, consumed, and maintained. Each piece of the collection will represent an **interoperable** link in that supply chain, enabling adaptation and integration into the major upstream language toolchains, developer environments, and CI/CD systems. | [Security Toolbelt](https://github.com/ossf/toolbelt) | [security-toolbelt](https://openssf.slack.com/archives/C057BN7K19B) | [Mailing List]([email protected]) |
 | Python Hardening Guide SIG | A group working to document a secure coding guide for python and associates code examples | [Git Repo](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Secure-Coding-Guide-for-Python) | [#secure-coding-guide-for-python](https://openssf.slack.com/archives/C07LH7RH8MT) |  |
-| Web Developer Security Guidelines | A group working on security guidelines specifc to web developers. This work is happening in the W3C SWAG Community Group in coordination with the OpenSSF Best Practices working group. (W3C communith groups are open to any participant.) | [SWAG home page](https://www.w3.org/community/swag/) [Git Repo](https://github.com/w3c-cg/swag) | [#swag-cg on the W3C Community Slack](https://w3ccommunity.slack.com/archives/C079JKV32RX) |  |
+| Web Developer Security Guidelines | A group working on security guidelines specific to web developers. This work is happening in the W3C SWAG Community Group in coordination with the OpenSSF Best Practices working group. (W3C communith groups are open to any participant.) | [SWAG home page](https://www.w3.org/community/swag/) [Git Repo](https://github.com/w3c-cg/swag) | [#swag-cg on the W3C Community Slack](https://w3ccommunity.slack.com/archives/C079JKV32RX) |  |
 
 ## Related resources
 
 
@@ -1,6 +1,6 @@
 # Compiler Annotations for C and C++
 
-> ⓘ NOTE: _This is a draft document by the [Open Source Security Foundation (OpenSSF)](https://openssf.org) [Best Practices Working Group](https://best.openssf.org/). Help to [improve it on Github](https://github.com/ossf/wg-best-practices-os-developers/edit/main/docs/Compiler-Hardening-Guides/Compiler-Annotations-for-C-and-C++.md)._
+> ⓘ NOTE: _This is a draft document by the [Open Source Security Foundation (OpenSSF)](https://openssf.org) [Best Practices Working Group](https://best.openssf.org/). Help to [improve it on GitHub](https://github.com/ossf/wg-best-practices-os-developers/edit/main/docs/Compiler-Hardening-Guides/Compiler-Annotations-for-C-and-C++.md)._
 
 Compile time security analysis and runtime mitigation implemented in compilers both depend on the compiler being able to see the flow of data between different points in a program, across functions and modules. This is quite a challenge in C and C++ because both languages allow passing around opaque references, thus losing information about objects.  To work around this problem, both GCC and Clang implement attributes to annotate source code, especially functions and data structures, to allow them to do better analysis of source code.  These annotations are not only beneficial for security, but they also help the compilers make better optimization decisions, often resulting in better code.
 
@@ -77,7 +77,7 @@ In GCC, the `malloc (`_`deallocator`_`)` and `malloc (`_`deallocator`_`,` _`ptr-
 
 Clang supports both forms of the `malloc` attribute but does not yet implement the `-Wmismatched-dealloc` and `-Wmismatched-new-delete` warnings. Instead, Clang provides the `ownership_returns`, `ownership_takes`, and `ownership_holds` attributes[^clang-ownership]: that interact with the Clang static analyzer[^clang-checkers].
 
-In Clang, the `ownership_returns(`_`allocation-type`_`)` associates the pointer returned by the marked function with an _`allocation-type`_. Here, _`allocation-type`_ is any string which will subsequently be used to detect mismatched allocations in cases where the pointer is passed to a deallocator marked with another _`allocation-type`_. The _`allocation-type`_ `malloc` has a special meaning and causes the Clang static analyzer to treat the associated pointer as though the allocated storage would have been allocatated using the standard `malloc()` function, and can subsequently be safely deallocated with the standard `free()` function.
+In Clang, the `ownership_returns(`_`allocation-type`_`)` associates the pointer returned by the marked function with an _`allocation-type`_. Here, _`allocation-type`_ is any string which will subsequently be used to detect mismatched allocations in cases where the pointer is passed to a deallocator marked with another _`allocation-type`_. The _`allocation-type`_ `malloc` has a special meaning and causes the Clang static analyzer to treat the associated pointer as though the allocated storage would have been allocated using the standard `malloc()` function, and can subsequently be safely deallocated with the standard `free()` function.
 
 The Clang `ownership_takes(`_`allocation-type`_`,` _`ptr-index`_`)` attribute marks a function as a deallocator for pointers of _`allocation-type`_ and `ownership_holds(`_`allocation-type`_`,` _`ptr-index`_`)` marks a function as taking over the ownership of a pointer of _`allocation-type`_ and will deallocate it at some unspecified point in the future. Here, _`ptr-index`_ denotes the positional argument to where the pointer must be passed in order to deallocate or take ownerwship of the storage.
 
@@ -88,7 +88,7 @@ Using the the `ownership_returns`, `ownership_takes`, and `ownership_holds` attr
 - **Use-after-free** (`unix.Malloc`, `cplusplis.NewDelete`) if there is an execution path in which the memory passed by pointer to a function annotated with `ownership_takes` is used after the call. Using memory passed to a function annotated with `ownership_holds` is considered valid.
 - **Memory leaks** (`unix.Malloc`, `cplusplus.NewDeleteLeaks`) if if there is an execution path in which the result of an allocation call goes out of scope without being passed to a function annotated with `ownership_takes` or `ownership_holds`.
 - **Dubious `malloc()` arguments involving `sizeof`** (`unix.MallocSizeof`) if the size of the pointer type the returned pointer does not match the size indicated by `sizeof` expression passed as argument to the allocation function.
-- **Potentially attacker controlled `size` parameters to allocation functions** (`optin.taint.TaintedAlloc`) if the `size` parameter originates from a tained source and the analyzer cannot prove that the size parameter is within reasonable bounds (`<= SIZE_MAX/4`).
+- **Potentially attacker controlled `size` parameters to allocation functions** (`optin.taint.TaintedAlloc`) if the `size` parameter originates from a tainted source and the analyzer cannot prove that the size parameter is within reasonable bounds (`<= SIZE_MAX/4`).
 
 #### Example usage
 
@@ -180,7 +180,7 @@ assert(__builtin_object_size(s, 0) == 100);
 |:-----------------------------------------------------------------------------------------------|:---------------------------:|:----------------------------:|:------------------------------------------------------------------------------------------------- |
 | `access(`_`mode`_`,`_`ref-index`_`)`<br/>`access(`_`mode`_`,`_`ref-index`_`,`_`size-index`_`)` | GCC 11.0.0                  | Function                     | Mark access restrictions for positional argument.                                                 |
 
-The `access` attribute in GCC[^gcc-acess] indicates the intended mode in which the annotated function operates on the specified positional argument. GCC uses this information to detect non-confirming accesses by the annotated function or their callers, as well as write-only accesses to objects that are never read from. Diagnostics of such non-conforming accesses are reported through the `-Wstringop-overread`, `-Wstringop-overflow`, `-Wuninitialized`, `-Wmaybe-uninitialized`, and `-Wunused` warnings.
+The `access` attribute in GCC[^gcc-access] indicates the intended mode in which the annotated function operates on the specified positional argument. GCC uses this information to detect non-confirming accesses by the annotated function or their callers, as well as write-only accesses to objects that are never read from. Diagnostics of such non-conforming accesses are reported through the `-Wstringop-overread`, `-Wstringop-overflow`, `-Wuninitialized`, `-Wmaybe-uninitialized`, and `-Wunused` warnings.
 
 The `access(`_`mode`_`,`_`ref-index`_`)` form indicates to GCC that the annotated function accesses the object passed to the function by-reference denoted the by the positional argument at _`ref-index`_ (using one-based indexing) according to _`mode`_, where _`mode`_ is one of the following access modes:
 
@@ -222,6 +222,6 @@ void to_uppercase(char *buffer, size_t size) __attribute__((access(read_write, 1
 
 [[Extended example at Compiler Explorer](https://godbolt.org/z/K44d89YM7)]
 
-[^gcc-acess]: GCC team, [Using the GNU Compiler Collection (GCC): 6.35.1 Common Function Attributes: access](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute), GCC Manual, 2024-08-01.
+[^gcc-access]: GCC team, [Using the GNU Compiler Collection (GCC): 6.35.1 Common Function Attributes: access](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute), GCC Manual, 2024-08-01.
 
 ---