V1.01.192.2025.06.06

Signed-off-by: Marc S. Weidner <msw@coresecret.dev>

.gitea/workflows/linter_char_scripts.yaml

@@ -127,10 +127,12 @@ jobs:
           #
           # We capture:
           # - All files '*.sh', '*.rfc.xml'
-          # - All files whose first line begins with “#!” (shebang)
+          # - All files whose first line begins with "#!" (shebang)
           # -------------------------------
           mapfile -t files_to_check < <(
-            find . -type f \( \
+            find . \
+              -path './.git' -prune -o \
+              -type f \( \
                 -iname '*.sh' -o \
                 -iname '*.rfc.xml' -o \
                 -exec grep -Iq '^#!' {} \; \

docs/graphviz/ciss.developer.branch.dot

@@ -138,15 +138,15 @@ digraph CISS_debian_live_builder {
     // Jump Host → Hidden-Master
     Jump_Host -> Hidden_Master [color=green];
 
-    // Hidden-Master → Name servers (each green with the label “HMAC SHA512”)
+    // Hidden-Master → Name servers (each green with the label "HMAC SHA512")
     Hidden_Master -> ns00 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns01 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns02 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns03 [color=green, label="HMAC SHA512"];
 
-    // Red arrows “DNSSEC” from name server cluster (ns_anchor) → B cluster (b_big_anchor)
+    // Red arrows "DNSSEC" from name server cluster (ns_anchor) → B cluster (b_big_anchor)
     ns_anchor -> b_big_anchor [color=red, label="DNSSEC"];
-    // Red arrow “DNSSEC” from nameserver cluster (ns_anchor) → cloud cluster (cloud_anchor)
+    // Red arrow "DNSSEC" from nameserver cluster (ns_anchor) → cloud cluster (cloud_anchor)
     ns_anchor -> cloud_anchor [color=red, label="DNSSEC"];
 
     // Red arrows from TLS Internet → B-Cluster and cloud

draft-weidner-catalog-rr-ext-00.rfc.xml

@@ -1068,7 +1068,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
             After fetching, Certification Authorities parse the file as above.
 
             If the HTTP request fails for whatever reason,
-            (network error, invalid cert, status ≠ 200, or parse error),
+            (network error, invalid cert, status != 200, or parse error),
             the policy is considered unavailable or invalid, and Certification Authorities fall back to "no policy".
 
             HTTP 3xx redirects <strong>MUST NOT</strong> be followed, and HTTP caching
@@ -1377,7 +1377,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
         <name>Policy Redundancy Considerations</name>
         <t>Let c be the number of critical CT-Logs and w be the number of whitelisted (non-critical) CT-Logs,
           then the following expression is strongly <strong>RECOMMENDED</strong>:
-          |c| ≥ n + 1 ∧ |w| ≤ 2
+          |c| >= n + 1 ^ |w| &lt;= 2
         </t>
         <t>While the "critical=true" flag in the CAA <strong>"issuect"</strong> Parameter enforces that every
           Certificate issuance must be logged to all specified CT-Logs, this strict requirement can introduce
@@ -1399,7 +1399,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
           <li>"+ 2" Whitelist of Non-Critical CT-Logs.
             In addition to the n + 1 critical logs, domain owners <strong>SHOULD</strong> nominate at least
             up to two further CT-Logs without the "critical=true" flag.
-            These “whitelisted” CT-Logs provide extra transparency channels,
+            These "whitelisted" CT-Logs provide extra transparency channels,
             enabling issuance to continue if a critical CT-Log fails,
             but do not block issuance if they are unreachable.
             They <strong>MUST NOT</strong> not carry "critical=true"; otherwise,
@@ -1459,10 +1459,10 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
           <li>
             <t>TLSA Usage</t>
             <ul>
-              <li>3 1 1 — SHA-256 hash of the leaf certificate's SPKI</li>
-              <li>3 1 2 — SHA-512 hash of the leaf certificate's SPKI</li>
-              <li>2 1 1 — SHA-256 hash of the issuing intermediate certificate's SPKI</li>
-              <li>2 1 2 — SHA-512 hash of the issuing intermediate certificate's SPKI</li>
+              <li>3 1 1 - SHA-256 hash of the leaf certificate's SPKI</li>
+              <li>3 1 2 - SHA-512 hash of the leaf certificate's SPKI</li>
+              <li>2 1 1 - SHA-256 hash of the issuing intermediate certificate's SPKI</li>
+              <li>2 1 2 - SHA-512 hash of the issuing intermediate certificate's SPKI</li>
             </ul>
             <t>Here, TLSA-usage 3 (DANE-EE) and 2 (DANE-TA), selector 1 (SPKI), and matching
               types 1 (SHA-256) and 2 (SHA-512) ensure that CAs validate the exact certificates
@@ -1600,7 +1600,7 @@ ct_policy: ( "example.ca; \
         <name>Normative References</name>
         <reference anchor="ISO-8601" target="https://www.iso.org/standard/70907.html">
           <front>
-            <title>Date and time — Representations for information interchange</title>
+            <title>Date and time - Representations for information interchange</title>
             <author>
               <organization>International Organization for Standardization</organization>
             </author>
@@ -1659,7 +1659,7 @@ ct_policy: ( "example.ca; \
         <name>Informative References</name>
         <reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/">
           <front>
-            <title>Portable Operating System Interface (POSIX™) - Base Specifications</title>
+            <title>Portable Operating System Interface (POSIX) - Base Specifications</title>
             <author>
               <organization>The Institute of Electrical and Electronics Engineers; The Open Group</organization>
             </author>