[pmg-devel] [PATCH pmg-api] schema: fix verification for transport-domain-or-nexthop type

[pmg-devel] [PATCH pmg-api] schema: fix verification for transport-domain-or-nexthop type

[Fiona Ebner]

Since pmg_verify_transport_address() is called with $noerr set, it
will not die on failure. Make sure that the verification method does
not quietly accept an invalid value in this case by making sure the
code for failure is also executed in this scenario, i.e. moving it
out of the 'else' branch.

As reported in the community forum [0], this could case issues when a
CIDR is specified instead of an IP or domain name for TLS destination
policy, which is not intended.

[0]: https://forum.proxmox.com/threads/165167/

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PMG/Config.pm | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/PMG/Config.pm b/src/PMG/Config.pm
index 82bd42e..0a5dff0 100644
--- a/src/PMG/Config.pm
+++ b/src/PMG/Config.pm
@@ -1141,10 +1141,11 @@ sub pmg_verify_transport_domain_or_nexthop {
 	    $nexthop = $1;
 	}
 	return $name if pmg_verify_transport_address($nexthop, 1);
-    } else {
-	   return undef if $noerr;
-	   die "value does not look like a valid domain or next-hop\n";
+	# else fall through, because it is a failure
     }
+
+    return undef if $noerr;
+    die "value does not look like a valid domain or next-hop\n";
 }
 
 sub read_tls_policy {
-- 
2.39.5



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel

[pmg-devel] applied: [PATCH pmg-api] schema: fix verification for transport-domain-or-nexthop type

[Stoiko Ivanov]

Hi,

Thanks for tackling this and identifying the issue!

gave it a quick spin on my test-setup and applied the patch!

On Thu, 24 Apr 2025 13:34:51 +0200
Fiona Ebner <f.ebner@proxmox.com> wrote:

> Since pmg_verify_transport_address() is called with $noerr set, it
> will not die on failure. Make sure that the verification method does
> not quietly accept an invalid value in this case by making sure the
> code for failure is also executed in this scenario, i.e. moving it
> out of the 'else' branch.
> 
> As reported in the community forum [0], this could case issues when a
> CIDR is specified instead of an IP or domain name for TLS destination
> policy, which is not intended.
> 
> [0]: https://forum.proxmox.com/threads/165167/
> 
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  src/PMG/Config.pm | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/PMG/Config.pm b/src/PMG/Config.pm
> index 82bd42e..0a5dff0 100644
> --- a/src/PMG/Config.pm
> +++ b/src/PMG/Config.pm
> @@ -1141,10 +1141,11 @@ sub pmg_verify_transport_domain_or_nexthop {
>  	    $nexthop = $1;
>  	}
>  	return $name if pmg_verify_transport_address($nexthop, 1);
> -    } else {
> -	   return undef if $noerr;
> -	   die "value does not look like a valid domain or next-hop\n";
> +	# else fall through, because it is a failure
>      }
> +
> +    return undef if $noerr;
> +    die "value does not look like a valid domain or next-hop\n";
>  }
>  
>  sub read_tls_policy {



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel