obs-acl-feature: Mention allowbuilddep=*

Document the `<allowbuilddep name="*">` feature implemented to grant
unrestricted access to binaries in hidden projects.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

content/guides/obs-acl-feature.md

 +++
 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" >}}