| 6 Jun 2023 |
Reventlov | « ok, donc la signature est un truc indépendant du hash de la dérivation (au sens de nix) ? » | 09:48:29 |
Reventlov | oui, le hash de la dérivation ne couvre que les sources, et pas la sortie binaire | 09:48:37 |
Reventlov | (mis à part dans du fixed output dérivation) | 09:48:47 |
Reventlov | et pour la paire de clef… en fait… tu as une dérivation avec un ensemble d'inputs, tu prends le hash de ces inputs, et tu query ton cache binaire. Il va te répondre « oui, j'ai le machin buildé qui correspond, voilà son nar hash, et voilà une signature de ce hash » | 10:00:37 |
Reventlov | derrière, ton client télécharge ton binaire, calcule le nar hash du truc, vérifie que c'est bien le nar hash que le cache binaire avait envoyé, et vérifie que la signature est bonne | 10:01:41 |
Reventlov | au fond, ça permet de découpler la partie « résolution » d'un hash d'inputs vers un nar hash de la partie téléchargement (qui pourrait être peer-to-peer) | 10:02:04 |
nim65s | ok, mais ce hash est déjà signé par Hydra, non ? | 10:02:11 |
nim65s | pourquoi ton cache local doit signer aussi ? | 10:02:20 |
Reventlov | c'est un petit abus de langage, quand on dit bincache souvent on veut dire « on a un truc qui build et cache les binaires » | 10:02:45 |
Reventlov | mais, oui, tu pourrais juste reservir les signatures de cache.nixos.org et leurs binaires | 10:02:55 |
nim65s | ok, c’est bien ce que je pensais, merci | 10:02:57 |
Reventlov | et ça irait tout à fait | 10:02:59 |