fix: MD050 consistent asterisk for strong tags (dotnet#31670)

Author: nschonni

.markdownlint-cli2.jsonc

@@ -56,7 +56,9 @@
             "style": "fenced"
         },
         "MD049": false,
-        "MD050": false,
+        "MD050": {
+            "style": "asterisk"
+        },
         "MD051": false
     },
     "ignores": [

docs/framework/additional-apis/system.data.sqltypes.sqlmoney.-ctor.md

@@ -15,7 +15,7 @@ api_type:
 ---
 # SqlMoney Constructor
 
-Initializes a new instance of the `SqlMoney` struct, where `value` has already been scaled by a ten-thousandth of a currency unit. For example, if __20000__ is provided for the `value` parameter, this `SqlMoney` instance will represent __2__ currency units.
+Initializes a new instance of the `SqlMoney` struct, where `value` has already been scaled by a ten-thousandth of a currency unit. For example, if **20000** is provided for the `value` parameter, this `SqlMoney` instance will represent **2** currency units.
 
 The `ignored` parameter is ignored.
 

docs/framework/additional-apis/system.data.sqltypes.sqlmoney.tosqlinternalrepresentation.md

@@ -16,8 +16,8 @@ api_type:
 # SqlMoney.ToSqlInternalRepresentation Method
 
 Returns the value of this `SqlMoney` instance scaled by a ten-thousandth of a currency unit.
-For example, if the current `SqlMoney` instance represents __2__ currency units, the
-`ToSqlInternalRepresentation` method will return __20000__.
+For example, if the current `SqlMoney` instance represents **2** currency units, the
+`ToSqlInternalRepresentation` method will return **20000**.
 
 If this `SqlMoney` instance represents a null value (see <xref:System.Data.SqlTypes.SqlMoney.IsNull>), calling this method will throw a <xref:System.Data.SqlTypes.SqlNullValueException>.
 

docs/framework/data/adonet/dataset-datatable-dataview/security-guidance.md

@@ -288,7 +288,7 @@ For more information on using the registry to configure `AppContext`, see ["AppC
 
 ## Safety with regard to untrusted input
 
-While `DataSet` and `DataTable` do impose default limitations on the types that are allowed to be present while deserializing XML payloads, __`DataSet` and `DataTable` are in general not safe when populated with untrusted input.__ The following is a non-exhaustive list of ways that a `DataSet` or `DataTable` instance might read untrusted input.
+While `DataSet` and `DataTable` do impose default limitations on the types that are allowed to be present while deserializing XML payloads, **`DataSet` and `DataTable` are in general not safe when populated with untrusted input.** The following is a non-exhaustive list of ways that a `DataSet` or `DataTable` instance might read untrusted input.
 
 * A `DataAdapter` references a database, and the `DataAdapter.Fill` method is used to populate a `DataSet` with the contents of a database query.
 * The `DataSet.ReadXml` or `DataTable.ReadXml` method is used to read an XML file containing column and row information.

docs/orleans/grains/grain-versioning/compatible-grains.md

@@ -15,10 +15,10 @@ When an existing grain activation is about to process a request, the runtime wil
 A grain interface version Vn can be backward compatible with Vm if:
 
 - The name of the interface didn't change (or the overridden typecode).
-- All public methods present in the Vm version are in the Vn version. __It is important that
-    the signatures of the methods inherited from Vm are not modified__: since Orleans use
-    an internal built-in serializer, modifying/renaming a field (even private) can make the
-    serialization to break.
+- All public methods present in the Vm version are in the Vn version.
+  **It is important that the signatures of the methods inherited from Vm are not modified**: since Orleans use
+  an internal built-in serializer, modifying/renaming a field (even private) can make the
+  serialization to break.
 
 Since Vn can have added methods compared to Vm, Vm is not compatible with Vn.
 

docs/orleans/grains/grain-versioning/deploying-new-versions-of-grains.md

@@ -38,7 +38,7 @@ on newer silos.
 
 ### Use a staging environment
 
-With the staging environment methodology, you will need a second environment (Staging environment), on which you will deploy newer silos before stopping the Production environment. The Production and the Staging silos and clients will be __part of the same cluster__. Silos from both environments must have the ability to talk to each other.
+With the staging environment methodology, you will need a second environment (Staging environment), on which you will deploy newer silos before stopping the Production environment. The Production and the Staging silos and clients will be **part of the same cluster**. Silos from both environments must have the ability to talk to each other.
 
 Recommended configuration:
 

docs/standard/io/isolated-storage.md

@@ -82,7 +82,7 @@ The allowed usage specified by <xref:System.Security.Permissions.IsolatedStorage
 
 ## Safety of isolated storage components with regard to untrusted data
 
-__This section applies to the following frameworks:__
+**This section applies to the following frameworks:**
 
 - .NET Framework (all versions)
 - .NET Core 2.1+
@@ -142,14 +142,14 @@ If Mallory wishes to attack Bob, she might write data to the machine-wide storag
 
 #### Elevation of privilege
 
-An __elevation of privilege__ attack occurs when Bob's app reads Mallory's file and automatically tries to take some action based on the contents of that payload. Consider an app that reads the contents of a startup script from the machine-wide store and passes those contents to `Process.Start`. If Mallory can place a malicious script inside the machine-wide store, when Bob launches his app:
+An **elevation of privilege** attack occurs when Bob's app reads Mallory's file and automatically tries to take some action based on the contents of that payload. Consider an app that reads the contents of a startup script from the machine-wide store and passes those contents to `Process.Start`. If Mallory can place a malicious script inside the machine-wide store, when Bob launches his app:
 
 * His app parses and launches Mallory's malicious script _under the context of Bob's user profile_.
 * Mallory gains access to Bob's account on the local machine.
 
 #### Denial of service
 
-A __denial of service__ attack occurs when Bob's app reads Mallory's file and crashes or otherwise stops functioning correctly. Consider again the app mentioned previously, which attempts to parse a startup script from the machine-wide store. If Mallory can place a file with malformed contents inside the machine-wide store, she might:
+A **denial of service** attack occurs when Bob's app reads Mallory's file and crashes or otherwise stops functioning correctly. Consider again the app mentioned previously, which attempts to parse a startup script from the machine-wide store. If Mallory can place a file with malformed contents inside the machine-wide store, she might:
 
 * Cause Bob's app to throw an exception early in the startup path.
 * Prevent the app from launching successfully because of the exception.
@@ -158,15 +158,15 @@ She has then denied Bob the ability to launch the app under his own user account
 
 #### Information disclosure
 
-An __information disclosure__ attack occurs when Mallory can trick Bob into disclosing the contents of a file that Mallory does not normally have access to. Consider that Bob has a secret file *C:\Users\Bob\secret.txt* that Mallory wants to read. She knows the path to this file, but she cannot read it because Windows forbids her from gaining access to Bob's user profile directory.
+An **information disclosure** attack occurs when Mallory can trick Bob into disclosing the contents of a file that Mallory does not normally have access to. Consider that Bob has a secret file *C:\Users\Bob\secret.txt* that Mallory wants to read. She knows the path to this file, but she cannot read it because Windows forbids her from gaining access to Bob's user profile directory.
 
 Instead, Mallory places a hard link into the machine-wide store. This is a special kind of file that itself does not contain any contents, rather, it points to another file on disk. Attempting to read the hard link file will instead read the contents of the file targeted by the link. After creating the hard link, Mallory still cannot read the file contents because she does not have access to the target (`C:\Users\Bob\secret.txt`) of the link. However, Bob _does_ have access to this file.
 
 When Bob's app reads from the machine-wide store, it now inadvertently reads the contents of his `secret.txt` file, just as if the file itself had been present in the machine-wide store. When Bob's app exits, if it attempts to resave the file to the machine-wide store, it will end up placing an actual copy of the file in the *C:\ProgramData\IsolatedStorage\* directory. Since this directory is readable by any user on the machine, Mallory can now read the contents of the file.
 
 ### Best practices to defend against these attacks
 
-__Important:__ If your environment has multiple mutually untrusted users, __do not__ call the API `IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)` or invoke the tool `storeadm.exe /machine /list`. Both of these assume that they're operating on trusted data. If an attacker can seed a malicious payload in the machine-wide store, that payload can lead to an elevation of privilege attack under the context of the user who runs these commands.
+**Important:** If your environment has multiple mutually untrusted users, **do not** call the API `IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)` or invoke the tool `storeadm.exe /machine /list`. Both of these assume that they're operating on trusted data. If an attacker can seed a malicious payload in the machine-wide store, that payload can lead to an elevation of privilege attack under the context of the user who runs these commands.
 
 If operating in a multi-user environment, reconsider use of isolated storage features that target the _Machine_ scope. If an app must read data from a machine-wide location, prefer to read the data from a location that's writable only by admin accounts. The `%PROGRAMFILES%` directory and the `HKLM` registry hive are examples of locations that are writable by only administrators and readable by everyone. Data read from those locations is therefore considered trustworthy.
 

docs/standard/native-interop/best-practices.md

@@ -56,7 +56,7 @@ If you *do* use `StringBuilder`, one last gotcha is that the capacity does **not
 
 For more information on string marshalling, see [Default Marshalling for Strings](../../framework/interop/default-marshalling-for-strings.md) and [Customizing string marshalling](customize-parameter-marshalling.md#customizing-string-parameters).
 
-> __Windows Specific__
+> **Windows Specific**
 > For `[Out]` strings the CLR will use `CoTaskMemFree` by default to free strings or `SysStringFree` for strings that are marked
 as `UnmanagedType.BSTR`.
 > **For most APIs with an output string buffer:**

docs/standard/serialization/binaryformatter-security-guide.md

@@ -35,7 +35,7 @@ As a simpler analogy, assume that calling `BinaryFormatter.Deserialize` over a p
 ## BinaryFormatter security vulnerabilities
 
 > [!WARNING]
-> The `BinaryFormatter.Deserialize` method is __never__ safe when used with untrusted input. We strongly recommend that consumers instead consider using one of the alternatives outlined later in this article.
+> The `BinaryFormatter.Deserialize` method is **never** safe when used with untrusted input. We strongly recommend that consumers instead consider using one of the alternatives outlined later in this article.
 
 `BinaryFormatter` was implemented before deserialization vulnerabilities were a well-understood threat category. As a result, the code does not follow modern best practices. The `Deserialize` method can be used as a vector for attackers to perform DoS attacks against consuming apps. These attacks might render the app unresponsive or result in unexpected process termination. This category of attack cannot be mitigated with a `SerializationBinder` or any other `BinaryFormatter` configuration switch. .NET considers this behavior to be ***by design*** and won't issue a code update to modify the behavior.
 
@@ -66,15 +66,15 @@ The preceding serializers all perform unrestricted polymorphic deserialization a
 
 Frequently, an app developer might believe that they are processing only trusted input. The safe input case is true in some rare circumstances. But it's much more common that a payload crosses a trust boundary without the developer realizing it.
 
-__Consider an on-prem server__ where employees use a desktop client from their workstations to interact with the service. This scenario might be seen naïvely as a "safe" setup where utilizing `BinaryFormatter` is acceptable. However, this scenario presents a vector for malware that gains access to a single employee's machine to be able to spread throughout the enterprise. That malware can leverage the enterprise's use of `BinaryFormatter` to move laterally from the employee's workstation to the backend server. It can then exfiltrate the company's sensitive data. Such data could include trade secrets or customer data.
+**Consider an on-prem server** where employees use a desktop client from their workstations to interact with the service. This scenario might be seen naïvely as a "safe" setup where utilizing `BinaryFormatter` is acceptable. However, this scenario presents a vector for malware that gains access to a single employee's machine to be able to spread throughout the enterprise. That malware can leverage the enterprise's use of `BinaryFormatter` to move laterally from the employee's workstation to the backend server. It can then exfiltrate the company's sensitive data. Such data could include trade secrets or customer data.
 
-__Consider also an app that uses `BinaryFormatter` to persist save state.__ This might at first seem to be a safe scenario, as reading and writing data on your own hard drive represents a minor threat. However, sharing documents across email or the internet is common, and most end users wouldn't perceive opening these downloaded files as risky behavior.
+**Consider also an app that uses `BinaryFormatter` to persist save state.** This might at first seem to be a safe scenario, as reading and writing data on your own hard drive represents a minor threat. However, sharing documents across email or the internet is common, and most end users wouldn't perceive opening these downloaded files as risky behavior.
 
 This scenario can be leveraged to nefarious effect. If the app is a game, users who share save files unknowingly place themselves at risk. The developers themselves can also be targeted. The attacker might email the developers' tech support, attaching a malicious data file and asking the support staff to open it. This kind of attack could give the attacker a foothold in the enterprise.
 
 Another scenario is where the data file is stored in cloud storage and automatically synced between the user's machines. An attacker who is able to gain access to the cloud storage account can poison the data file. This data file will be automatically synced to the user's machines. The next time the user opens the data file, the attacker's payload runs. Thus the attacker can leverage a cloud storage account compromise to gain full code execution permissions.
 
-__Consider an app that moves from a desktop-install model to a cloud-first model.__ This scenario includes apps that move from a desktop app or rich client model into a web-based model. Any threat models drawn for the desktop app aren't necessarily applicable to the cloud-based service. The threat model for the desktop app might dismiss a given threat as "not interesting for the client to attack itself." But that same threat might become interesting when it considers a remote user (the client) attacking the cloud service itself.
+**Consider an app that moves from a desktop-install model to a cloud-first model.** This scenario includes apps that move from a desktop app or rich client model into a web-based model. Any threat models drawn for the desktop app aren't necessarily applicable to the cloud-based service. The threat model for the desktop app might dismiss a given threat as "not interesting for the client to attack itself." But that same threat might become interesting when it considers a remote user (the client) attacking the cloud service itself.
 
 > [!NOTE]
 > In general terms, the intent of serialization is to transmit an object into or out of an app. A threat modeling exercise almost always marks this kind of data transfer as crossing a trust boundary.