SignPath · ulrichb · Jun 27, 2025 · Jun 27, 2025
diff --git a/docs/_data/changelog.yml b/docs/_data/changelog.yml
@@ -1,3 +1,23 @@
+- date: '2025-07-01'
+  updates:
+    application:
+      version: 1.191.0
+      new_features:
+        - text: |-
+            REST API: New signing request submission APIs, which allow to separate metadata submission from artifact upload:
+            * `POST /v1/{organizationId}/SigningRequests/SubmitWithoutArtifact` creates a signing request in a "waiting for artifact upload" status.
+            * `POST /v1/{organizationId}/SigningRequests/{id}/UploadUnsignedArtifact` (afterwards) uploads the artifact.
+            * For details see [API definition](https://app.signpath.io/Api/swagger) of the new routes.
+          issues: [SIGN-7786]
+        - text: |-
+            Added `subject` and `author` [`<msi-file>` metadata restrictions](/documentation/artifact-configuration/reference#metadata-restrictions).
+          issues: [SIGN-7695]
+    self_hosted_installations:
+      version: 1.191.0
+      improvements:
+        - text: |-
+            Improved performance for the signing policy-filtered signing request list as well as the "waiting for your approval" list on the dashboard UI.
+          issues: [SIGN-7883]
 - date: '2025-06-19'
   updates:
     github_connector:
@@ -1036,8 +1056,8 @@
       version: 1.157.0
       improvements:
         - text: >-
-            For failed singing requests, the "Retry with current settings" feature was replaced with "_Resubmit_ with current settings". This feature creates
-            a new signing request (linking back to the "original singing request") instead of retrying the same signing request.
+            For failed signing requests, the "Retry with current settings" feature was replaced with "_Resubmit_ with current settings". This feature creates
+            a new signing request (linking back to the "original signing request") instead of retrying the same signing request.
           issues: [SIGN-6744]
         - text: >-
             Stricter validation of email address input.
@@ -1988,7 +2008,7 @@
         - text: The console logging was disabled by default (`SIGNPATH_LOG_CONSOLE_LEVEL=none`).
           issues: [SIGN-5154]
       new_features:
-        - text: 'Cryptoki: Added compatibility with `gnupg-pkcs11-scd` to support GnuPG PGP singing.'
+        - text: 'Cryptoki: Added compatibility with `gnupg-pkcs11-scd` to support GnuPG PGP signing.'
           issues: [SIGN-5154]
     self_hosted_installations:
       version: 1.121.0

diff --git a/docs/documentation/artifact-configuration/examples.md b/docs/documentation/artifact-configuration/examples.md
@@ -86,14 +86,14 @@ Example of a directory structure that would match this configuration:
 
 ## Metadata restrictions
 
-### PE file metadata restriction {#pe-restriction}
+### MSI and PE file metadata restriction {#msi-and-pe-restriction}
 
 ~~~ xml
 <artifact-configuration xmlns="http://signpath.io/artifact-configuration/v1">
   <parameters>
     <parameter name="version" required="true" />
   </parameters>
-  <msi-file>
+  <msi-file subject="MyProduct" author="ACME Inc.">
     <!-- requires all pe-files to have the respective attributes set -->
     <pe-file-set product-name="MyProduct" product-version="${version}" file-version="${version}"
                  company-name="ACME Inc." copyright="Copyright ACME Inc." original-filename="${file.name}">

diff --git a/docs/documentation/artifact-configuration/reference.md b/docs/documentation/artifact-configuration/reference.md
@@ -382,7 +382,7 @@ If you use this method directly to verify signatures, make sure that the public
 
 ## Verification methods {#verification}
 
-Verification directives are used to ensure that files in a singing request are already properly signed by their respective publisher.
+Verification directives are used to ensure that files in a signing request are already properly signed by their respective publisher.
 
 Use this to
 
@@ -433,7 +433,8 @@ The restrictions can be applied to file elements, [file set elements](syntax#fil
 
 | File element | Supported restriction attributes                                                                                        | Example
 |--------------|-------------------------------------------------------------------------------------------------------------------------|--------
-| `<pe-file>`  | PE file headers: `product-name`, `product-version`, `file-version`, `company-name`, `copyright`, `original-filename`    | [PE file restrictions](examples#pe-restriction)
+| `<pe-file>`  | PE file headers: `product-name`, `product-version`, `file-version`, `company-name`, `copyright`, `original-filename`    | [PE file restrictions](examples#msi-and-pe-restriction)
+| `<msi-file>` | MSI properties: `subject`, `author`                                                                                     | [MSI file restrictions](examples#msi-and-pe-restriction)
 | `<xml-file>` | Root element name and namespace: `root-element-name`, `root-element-namespace`                                          | [SBOM restrictions](examples#sbom-restriction)
 
 

diff --git a/docs/documentation/powershell/Submit-SigningRequest.md b/docs/documentation/powershell/Submit-SigningRequest.md
@@ -59,7 +59,7 @@ Submit-SigningRequest
     [-CancellationTimeoutInSeconds <Int32>] 
 ~~~
 
-### Resubmit an existing singing request {#resubmit}
+### Resubmit an existing signing request {#resubmit}
 
 {% include editions.md feature="policy_enforcement.resubmit" %}
 

diff --git a/docs/documentation/projects.md b/docs/documentation/projects.md
@@ -35,7 +35,7 @@ Projects consist of these configuration sections:
 
 Signing policies define the rules and permissions for signing and the certificate that will be used. Each signing request must use a specific signing policy. The signing request will then be processed according to this policy.
 
-Typically, a project contains these two singing policies:
+Typically, a project contains these two signing policies:
 
 * **test-signing** is used for internal builds that will be used for testing. It usually uses a self-signed certificate that is installed on test systems. Since this certificate is typically unknown on customer systems, test-signing often has wide permissions and few restrictions, if any.
 * **release-signing** is used for release builds that are shipped to customers and used on production systems. It typically uses a certificate purchased from a public Certificate Authority (CA). Software releases are sensitive and must be done in a secure, controlled and reproducible manner. Therefore, release-signing is often configured with few permissions and additional restrictions.

diff --git a/docs/product/editions-explained.md b/docs/product/editions-explained.md
@@ -238,7 +238,7 @@ For *Code Signing Starter* and *Code Signing Basic*, you get two signing policie
 * a test-signing policy for testing the signing configuration and signing test builds
 * a release-signing policy for signing builds that will be delivered to end users
 
-*Advanced Code Signing* and *Code Signing Gateway* allow to define any number of singing policies per project. You can use this to create policies with different levels of manual and automatic verification. 
+*Advanced Code Signing* and *Code Signing Gateway* allow to define any number of signing policies per project. You can use this to create policies with different levels of manual and automatic verification. 
 
 Example: