AUTOMATED - update patch docs

docs/PATCHES.md

@@ -132,6 +132,8 @@
 |**Do not link with libatomic** <br><sub><nobr> Tue, 11 Jan 2022 13:59:32 +0000</nobr> <br>File: [Do-not-link-with-libatomic.patch](/build/patches/Do-not-link-with-libatomic.patch) <br><nobr>Author: uazo</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-3.0-only</nobr> |Compiler has built-in support thus libatomic linking is no more needed<br>This patch allows building with use_sysroot=false|
 |**Do not store passwords by default** <br><sub><nobr> Wed, 11 Oct 2017 23:17:17 +0200</nobr> <br>File: [Do-not-store-passwords-by-default.patch](/build/patches/Do-not-store-passwords-by-default.patch) <br><nobr>Author: csagan5</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-3.0-only</nobr> ||
 |**DoH improvements** <br><sub><nobr> Sat, 26 Sep 2020 14:23:19 +0100</nobr> <br>File: [DoH-improvements.patch](/build/patches/DoH-improvements.patch) <br><nobr>Author: csagan5</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-3.0-only</nobr> |Enable secure mode by default<br>Always enforce DoH even with inconsistent system DNS configuration|
+|**Emoji Fonts fingerprinting mitigation 01-02** <br><sub><nobr> Wed, 3 Apr 2024 13:32:27 +0000</nobr> <br>File: [Emoji-Fonts-fingerprinting-mitigation-01-02.patch](/build/patches/Emoji-Fonts-fingerprinting-mitigation-01-02.patch) <br><nobr>Author: uazo</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-2.0-or-later</nobr> |Replaces the platform emoji font with the one embedded in the apk.<br>Require: Fonts-fingerprinting-mitigation.patch|
+|**Emoji Fonts fingerprinting mitigation 02-02** <br><sub><nobr> Wed, 3 Apr 2024 13:32:42 +0000</nobr> <br>File: [Emoji-Fonts-fingerprinting-mitigation-02-02.patch](/build/patches/Emoji-Fonts-fingerprinting-mitigation-02-02.patch) <br><nobr>Author: uazo</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-2.0-or-later</nobr> |Replaces the platform emoji font with the one embedded in the apk.<br>Part two: resources data only.|
 |**Enable -fwrapv in Clang for non-UBSan builds** <br><sub><nobr> Thu, 22 Dec 2016 07:15:34 -0500</nobr> <br>File: [Enable-fwrapv-in-Clang-for-non-UBSan-builds.patch](/build/patches/Enable-fwrapv-in-Clang-for-non-UBSan-builds.patch) <br><nobr>Author: Daniel</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-3.0-only</nobr> |Using -fwrapv (notably only when not using signed integer overflow checking -<br>since it will override it and result in not performing checks) is just common<br>sense since it eliminates the chance of security vulnerabilities being<br>introduced by optimizations based on signed overflow being undefined.<br>That has happened before, and those optimizations don't even add up to a 0.1%<br>performance increase for this kind of software. It's not worth having.<br>The Linux kernel passes -fwrapv and also -fno-strict-aliasing to disable those<br>dangerous optimizations (since there is so much incorrect code they can break).<br>In fact, it is easy to point to dozens of known examples of invalid code that<br>could potentially be broken by those optimizations.<br>It is not acceptable for projects to be using optimizations that are known to<br>be broken with a bunch of code in their tree.<br>They put barely any effort into even fixing the known cases.<br>Chromium has blacklists for UBSan for 'false positives' (none of which are<br>actually false positives, but rather "undefined, but not a bug beyond<br>potentially being broken by optimizations or even code generation without<br>them") and also for components too full of these bugs for them to currently<br>want to bother with it. That includes a bunch of signed overflow issues<br>(there is sadly no detection for aliasing violations, which are fairly common,<br>but not that common).<br>Ideally, -fwrapv could be always passed, but unfortunately the way it is<br>implemented has silly interactions with other switches.<br>The reason it would still make sense to pass it is because due to their UBSan<br>blacklists, they get far from full coverage with it, so -fwrapv would still<br>be better than nothing where it's not being used.<br>Since -fwrapv makes signed integer overflow well-defined, Clang will disable<br>the UBSan checks for signed integer overflow, including in the<br>production-oriented trapping mode used for hardening.<br>Excerpt from https://github.com/bromite/bromite/issues/226|
 |**Enable Android Dynamic Performance Framework** <br><sub><nobr> Wed, 23 Aug 2023 13:49:19 +0000</nobr> <br>File: [Enable-Android-Dynamic-Performance-Framework.patch](/build/patches/Enable-Android-Dynamic-Performance-Framework.patch) <br><nobr>Author: uazo</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-2.0-or-later</nobr> ||
 |**Enable Certificate Transparency** <br><sub><nobr> Fri, 10 Jun 2022 14:20:02 +0200</nobr> <br>File: [Enable-Certificate-Transparency.patch](/build/patches/Enable-Certificate-Transparency.patch) <br><nobr>Author: csagan5</nobr> <br><nobr>Context: </nobr> <br><nobr>License: GPL-3.0-only</nobr> |Reporting/auditing functionalities are disabled; a flag is exposed.<br>Add guard to make sure that certificate transparency stays enabled<br>by default.|