[pmg-devel] [PATCH pmg-api 3/4] cluster: use old and new fingerprint on master

[Stoiko Ivanov]

when triggering a fingerprint update on master right after reloading
pmgproxy as we do for ACME certificates it can happen that the
connection is made against the old pmgproxy process (with the old
fingerprint). Simply trusting both fingerprints in that case seems
acceptable from a security perspective and makes the fingerprint
update more robust

Signed-off-by: Stoiko Ivanov <s.ivanov at proxmox.com>
---
 src/PMG/Cluster.pm | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/PMG/Cluster.pm b/src/PMG/Cluster.pm
index e7bf266..acaea8d 100644
--- a/src/PMG/Cluster.pm
+++ b/src/PMG/Cluster.pm
@@ -316,11 +316,13 @@ sub trigger_update_fingerprints {
     my ($cinfo) = @_;
 
     my $master = $cinfo->{master} || die "unable to lookup master node\n";
-    my $master_fp = $master->{fingerprint};
+    my $cached_fp = { $master->{fingerprint} => 1 };
 
     # if running on master the current fingerprint for the API-connection is needed
+    # in addition (to prevent races with restarting pmgproxy
     if ($cinfo->{local}->{type} eq 'master') {
-	$master_fp = PMG::Cluster::read_local_ssl_cert_fingerprint();
+	my $new_fp = PMG::Cluster::read_local_ssl_cert_fingerprint();
+	$cached_fp->{$new_fp} = 1;
     }
 
     my $ticket = PMG::Ticket::assemble_ticket('root at pam');
@@ -330,10 +332,8 @@ sub trigger_update_fingerprints {
 	csrftoken => $csrftoken,
 	cookie_name => 'PMGAuthCookie',
 	host => $master->{ip},
-	cached_fingerprints => {
-	    $master_fp => 1,
-	},
-    );
+	cached_fingerprints => $cached_fp,
+	);
 
     $conn->post("/config/cluster/update-fingerprints", {});
     return undef;
-- 
2.20.1