diff --git a/content/guides/obs-acl-feature.md b/content/guides/obs-acl-feature.md
index de86e27684f8bb94edbb830b30bf5b8aa353654d..1aa5c49309d9db32d8828b0038ea4646d19639bf 100644
--- a/content/guides/obs-acl-feature.md
+++ b/content/guides/obs-acl-feature.md
@@ -1,7 +1,7 @@
 +++
 title = "OBS Access Control List Feature"
 weight = 100
-date = "2021-05-20"
+date = "2023-08-29"
 +++
 
 This document outlines the OBS ACL feature that has been implemented on the Collabora instance of OBS. This is a feature specific to Collabora OBS only.
@@ -42,6 +42,9 @@ The OBS ACL feature has the following behaviour:
   * the hidden project must whitelist the non-hidden one
   * this is done using the `<allowbuilddep name="name:of:public:project"/>` element in the meta config
   * this element is contained directly in the `<project …>` section, i.e. the same level as the `<title …>`
+  * transitive dependencies need to be explicitly listed in the hidden project, unless the special case
+    `*` glob is used to grant unrestricted usage of the produced binaries by any public project, as in
+    `<allowbuilddep name="*"/>` 
 
 # Example demonstration
 
@@ -186,6 +189,6 @@ As you can see in the image above, the **App Repo Public with allowbuilddep** re
 # Limitations
 There are some limitations in the OBS ACL feature implementation, which are mentioned below:
 
-* Nested ACL dependencies: Nested ACL dependencies, wherein repo A depends on repo B and vice-versa.  Project C, which is a public repostiory with an `<allowbuilddep ...>` attribute, will need to be mentioned in all parent repositories along with their nested dependency repositories. In this case, the `<allowbuilddep ...>` attribute will have to be added to both repo A and repo B. Incorrect definition of ACL rules, especially like this example of nested rules, reflect with an error message like below
+* Transitive dependencies are not supported, wherein hidden project `A` is used by hidden `B` and the public project `C` depends on `B`. In this case, project C needs to be mentioned in *every* ancestor project, recursively. The `<allowbuilddep name="C">` attribute needs to be added to both project `A` and project `B`, unless they use `<allowbuilddep name="*">` to grant access to every public project, which can be useful in cases where access to sources has to be limited but produced binaries are freely shareable. Incorrect definition of ACL rules, especially like this example of nested rules, results in error messages like the one below:
 
 {{< figure src="/images/app_repo_nested_broken.png" alt="Broken ACL setup" title="Broken ACL setup" >}}