Update rule metadata (#4731)

Author: kaufco

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html

@@ -5,6 +5,8 @@ <h2>Why is this an issue?</h2>
 control systems, making code reviews easier.</p>
 <p>This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is
 reported.</p>
+<p>The rule behaves consistently when the indentation settings of the IDE use <em>spaces</em> instead of <em>tabs</em>. Using <em>tabs</em> can lead
+to inconsistent indentation because the width of a <em>tab</em> can be configured differently in different environments.</p>
 <h3>What is the potential impact?</h3>
 <p>The readability is decreased. It becomes more tedious to review and modify the code.</p>
 <h2>How to fix it</h2>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S117.html

@@ -9,15 +9,17 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Inconsistent naming of local variables and method parameters can lead to several issues in your code:</p>
 <ul>
-  <li> Reduced Readability: inconsistent local variable and method parameter names make the code harder to read and understand; consequently, it is
-  more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
-  <li> Difficulty in Identifying Variables: local variables and method parameters that don’t adhere to a standard naming convention are challenging to
-  identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
-  <li> Increased Risk of Errors: inconsistent or unclear local variable and method parameter names lead to misunderstandings about what the variable
-  represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
-  <li> Collaboration Difficulties: in a team setting, inconsistent naming conventions lead to confusion and miscommunication among team members. </li>
-  <li> Difficulty in Code Maintenance: inconsistent naming leads to an inconsistent codebase. The code is difficult to understand, and making changes
-  feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain. </li>
+  <li> <strong>Reduced Readability</strong>: Inconsistent local variable and method parameter names make the code harder to read and understand;
+  consequently, it is more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
+  <li> <strong>Difficulty in Identifying Variables</strong>: The local variables and method parameters that don’t adhere to a standard naming
+  convention are challenging to identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
+  <li> <strong>Increased Risk of Errors</strong>: Inconsistent or unclear local variable and method parameter names lead to misunderstandings about
+  what the variable represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
+  <li> <strong>Collaboration Difficulties</strong>: In a team setting, inconsistent naming conventions lead to confusion and miscommunication among
+  team members. </li>
+  <li> <strong>Difficulty in Code Maintenance</strong>: Inconsistent naming leads to an inconsistent codebase. The code is difficult to understand,
+  and making changes feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain.
+  </li>
 </ul>
 <p>In summary, not adhering to a naming convention for local variables and method parameters can lead to confusion, errors, and inefficiencies, making
 the code harder to read, understand, and maintain.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html

@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Non-static initializers, also known as instance initializers, are blocks of code within a class that is executed when an instance of the class is
+<p>Non-static initializers, also known as instance initializers, are blocks of code within a class that are executed when an instance of the class is
 created. They are executed when an object of the class is created just before the constructor is called. Non-static initializers are useful when you
 want to perform some common initialization logic for all objects of a class. They allow you to initialize instance variables in a concise and
 centralized manner, without having to repeat the same initialization code in each constructor.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html

@@ -4,8 +4,8 @@ <h2>Why is this an issue?</h2>
 <h3>Exceptions</h3>
 <p>To prevent generating some false-positives, literals having less than 5 characters are excluded.</p>
 <h2>How to fix it</h2>
-<p>Instead, use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a
-single place.</p>
+<p>Use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a single
+place.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <p>With the default threshold of 3:</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html

@@ -6,7 +6,7 @@ <h2>Why is this an issue?</h2>
 to manually check the types using <code>instanceof</code> because Java automatically matches the exception type to the appropriate catch block based
 on the declared exception type in the catch clauses.</p>
 <h2>How to fix it</h2>
-<p>Replace <code>if</code> statements that check the exception type using <code>instaceof</code> with corresponding <code>catch</code> blocks.</p>
+<p>Replace <code>if</code> statements that check the exception type using <code>instanceof</code> with corresponding <code>catch</code> blocks.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1312.json

@@ -13,7 +13,8 @@
     "constantCost": "5min"
   },
   "tags": [
-    "convention"
+    "convention",
+    "logging"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-1312",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html

@@ -5,16 +5,16 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Having unused local variables in your code can lead to several issues:</p>
 <ul>
-  <li> Decreased Readability: Unused variables can make your code more difficult to read. They add extra lines and complexity, which can distract from
-  the main logic of the code. </li>
-  <li> Misunderstanding: When other developers read your code, they may wonder why a variable is declared but not used. This can lead to confusion and
-  misinterpretation of the code’s intent. </li>
-  <li> Potential for Bugs: If a variable is declared but not used, it might indicate a bug or incomplete code. For example, if you declared a variable
-  intending to use it in a calculation, but then forgot to do so, your program might not work as expected. </li>
-  <li> Maintenance Issues: Unused variables can make code maintenance more difficult. If a programmer sees an unused variable, they might think it is
-  a mistake and try to 'fix' the code, potentially introducing new bugs. </li>
-  <li> Memory Usage: Although modern compilers are smart enough to ignore unused variables, not all compilers do this. In such cases, unused variables
-  take up memory space, leading to inefficient use of resources. </li>
+  <li> <strong>Decreased Readability</strong>: Unused variables can make your code more difficult to read. They add extra lines and complexity, which
+  can distract from the main logic of the code. </li>
+  <li> <strong>Misunderstanding</strong>: When other developers read your code, they may wonder why a variable is declared but not used. This can lead
+  to confusion and misinterpretation of the code’s intent. </li>
+  <li> <strong>Potential for Bugs</strong>: If a variable is declared but not used, it might indicate a bug or incomplete code. For example, if you
+  declared a variable intending to use it in a calculation, but then forgot to do so, your program might not work as expected. </li>
+  <li> <strong>Maintenance Issues</strong>: Unused variables can make code maintenance more difficult. If a programmer sees an unused variable, they
+  might think it is a mistake and try to 'fix' the code, potentially introducing new bugs. </li>
+  <li> <strong>Memory Usage</strong>: Although modern compilers are smart enough to ignore unused variables, not all compilers do this. In such cases,
+  unused variables take up memory space, leading to inefficient use of resources. </li>
 </ul>
 <p>In summary, unused local variables can make your code less readable, more confusing, and harder to maintain, and they can potentially lead to bugs
 or inefficient memory use. Therefore, it is best to remove them.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1696.json

@@ -29,5 +29,5 @@
       395
     ]
   },
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2053.html

@@ -19,6 +19,19 @@ <h3>What is the potential impact?</h3>
 of password hashes with identical salt that can then be attacked as explained before.</p>
 <p>With short salts, the probability of a collision between two users' passwords and salts couple might be low depending on the salt size. The shorter
 the salt, the higher the collision probability. In any case, using longer, cryptographically secure salt should be preferred.</p>
+<h3>Exceptions</h3>
+<p>To securely store password hashes, it is a recommended to rely on key derivation functions that are computationally intensive. Examples of such
+functions are:</p>
+<ul>
+  <li> Argon2 </li>
+  <li> PBKDF2 </li>
+  <li> Scrypt </li>
+  <li> Bcrypt </li>
+</ul>
+<p>When they are used for password storage, using a secure, random salt is required.</p>
+<p>However, those functions can also be used for other purposes such as master key derivation or password-based pre-shared key generation. In those
+cases, the implemented cryptographic protocol might require using a fixed salt to derive keys in a deterministic way. In such cases, using a fixed
+salt is safe and accepted.</p>
 <h2>How to fix it in Java SE</h2>
 <h3>Code examples</h3>
 <p>The following code contains examples of hard-coded salts.</p>
@@ -46,7 +59,7 @@ <h4>Compliant solution</h4>
 </pre>
 <h3>How does this work?</h3>
 <p>This code ensures that each user’s password has a unique salt value associated with it. It generates a salt randomly and with a length that
-provides the required security level. It uses a salt length of at least 16 bytes (128 bits), as recommended by industry standards.</p>
+provides the required security level. It uses a salt length of at least 32 bytes (256 bits), as recommended by industry standards.</p>
 <p>Here, the compliant code example ensures the salt is random and has a sufficient length by calling the <code>nextBytes</code> method from the
 <code>SecureRandom</code> class with a salt buffer of 16 bytes. This class implements a cryptographically secure pseudo-random number generator.</p>
 <h2>Resources</h2>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2053.json

@@ -1,5 +1,5 @@
 {
-  "title": "Hashes should include an unpredictable salt",
+  "title": "Password hashing functions should use an unpredictable salt",
   "type": "VULNERABILITY",
   "code": {
     "impacts": {