Check how GH behaves after Scalepoint certificate expiration

[nieznanysprawiciel]

No description provided.

[stan7123]

Situation when requestor's node descriptor gets expired.

Requestor yagna log:

yagna_gh-1  | [2024-07-30T08:42:13.022+0000 INFO  ya_market::negotiation::requestor] requestor countered proposal entity="proposal" action="counter" proposal_id=R-856f3877b968848cb01ab4539e1ef925020991a94fdec9790c52db3435cc43a0 demand_id=69e8d10201ef46a5bbdc12695cb56278-3da0967c4741d97d659d24dba2a4c86e02f093ba221f6a5b60160eb902aad3fb new_proposal_id=R-8be79e727757ac6737616e25b98f00f05d014f4a585c4853c5a8af345923a940
yagna_gh-1  | [2024-07-30T08:42:13.095+0000 INFO  ya_market::negotiation::common] Provider [0xfbb99844a15bba9a9cabdaedf6be4f1f11e6db4b] rejected Proposal [R-8be79e727757ac6737616e25b98f00f05d014f4a585c4853c5a8af345923a940] 'Allow-only rule: Requestor [0x9ff1c7a8cd6cee43b1c6b0bf4bfb7b7f8002d855] rejected due to suspicious behavior: AllowOnly rule: verification of node descriptor failed: Expired: was valid to 2024-07-30 00:00:00 UTC '.

Provider yagna log:

[2024-07-30T10:42:13.646+0200 INFO  ya_market::negotiation::common] Received counter Proposal [P-8be79e727757ac6737616e25b98f00f05d014f4a585c4853c5a8af345923a940] for Proposal [P-5d1e5ce4d9b384d88be786b3c4b9a59e5d6d6834c6a09e4fee69416d3b2cdefb] from [0x9ff1c7a8cd6cee43b1c6b0bf4bfb7b7f8002d855].
[2024-07-30T10:42:13.653+0200 INFO  ya_market::negotiation::common] Provider [0xfbb99844a15bba9a9cabdaedf6be4f1f11e6db4b] rejected Proposal [P-8be79e727757ac6737616e25b98f00f05d014f4a585c4853c5a8af345923a940] 'Allow-only rule: Requestor [0x9ff1c7a8cd6cee43b1c6b0bf4bfb7b7f8002d855] rejected due to suspicious behavior: AllowOnly rule: verification of node descriptor failed: Expired: was valid to 2024-07-30 00:00:00 UTC '.

No anomalies spotted.
GamerHash desktop app did not show any error.

[stan7123]

Testing main certificate expiration

To not break production providers, we cannot touch current certificate pointed with https://ca.golem.network/cert/scalepoint.signed.json url.
We probably need a special build of facade which will point to a different certificate URL than the one currently used.

Tests to conclude (assuming no changes to the way how certificate is provided - static URL pointing to one certificate):

1. Wait for certificate expiration and see what will happen when agreements proposals are incoming.
2. Provide new certificate under the same URL when old one is expired and check if certificate is refreshed on provider and agreements are established.
3. Provide new certificate under the same URL before old one is expired and check if certificate is refreshed on provider and agreements are established.

[stan7123]

Testability

The proposition is to use env variable like ALLOWED_REQUESTORS_CERTS with value as ,-separated URLs to certificates. When this variable is present we can substitute the default hardcoded value.

I don't think there is any security issue with this solution since there would be a default certificate hardcoded.

[stan7123]

Certificate update on provider

Currently, the certificate is downloaded at golem facade startup.
On running apps, this can be enforced by releasing a new version of the Gamerhash app appropriately early so that most of the users are updated before the certificate expires.
Releasing a new version of the Gamerhash app just to refresh certificates might be assessed as an overkill. In that case, we probably need to implement some kind of cron or thread to observe certificate expiration dates and scheduling updates and reload during app runtime.