| 6 Jun 2023 |
 Pol | Pareil! | 08:56:20 |
 Gaétan Lepage | Bon visiblement il y a déjà pas mal de discussions sur des alternatives ditribuées sur le topic discourse. | 08:57:48 |
 Reventlov | en fait ça rejoint le problème de la reproductibilité binaire… | 09:06:23 |
| Reventlov | (ce que nix fait bof) | 09:06:30 |
 nim65s | Ok. Y’a quand même un set de paquets pour lesquels c’est bon ? | 09:07:04 |
| Reventlov | oui, mais de toute façon c'est signé par hydra | 09:07:16 |
| Reventlov | le problème c'est que t'as une seule "source of trust", au fond, c'est les paquets compilés par NixOS, et qu'il faut de toute façon arriver à les faire sortir de S3 à un moment (donc, probablement les 30k€ de frais de ransomware là) | 09:08:03 |
| Reventlov | (après est-ce que ça a une importance de garder les paquets compilés d'il y a 5 ans, peut être pas) | 09:08:44 |
| nim65s | ok, merci :) | 09:08:58 |
| Reventlov | en fait, hydra compile et signe les paquets binaires, qui actuellement restent stockés là bas, et la distribution est faite par un CDN. Le CDN peut tout à fait se faire remplacer par des miroirs communautaires (ce que font, au fond, toutes les distros). | 09:10:03 |
| Gaétan Lepage | ok, donc la signature est un truc indépendant du hash de la dérivation (au sens de nix) ? | 09:14:51 |
| nim65s | https://nixos.wiki/wiki/Binary_Cache du coup je comprends pas pourquoi les caches doivent avoir une paire de clefs | 09:15:02 |
| nim65s | à moins que ce dont parle cette page soit de "caches sources" par opposition à des mirroirs qui seraient simplement réplicateuers ? | 09:15:41 |
| nim65s | * à moins que ce dont parle cette page soit de "caches sources" par opposition à des mirroirs qui seraient simplement réplicateurs ? | 09:15:46 |
| nim65s | https://github.com/nix-community/harmonia/#configuration-for-public-binary-cache-on-nixos et ici ça dit qu’il faut ajouter une trusted-public-keys | 09:17:08 |
| 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 |
 nbp | Avoir un cache distribué mais une signature centralisé est techniquement faisable, mais ensuite il y a toujours un risque.
Le plus grand risque selon moi est si le cache est composé de logiciel utilisé par la machine qui fourni le cache, car là il y a un risque d'attaque potentielle.
Si quelqu'un est capable de déterminé que Apache est pas à jour, et donc vulnérable … alors il y a un risque. | 10:03:16 |
| Reventlov | (en fait t'as déjà la signature centralisée, de fait, avec celle de cache.nixos.org) | 10:03:45 |
| Reventlov | et le cache distribué, moi ça m'arrive de mettre un simple nginx qui cache nixos.org pour éviter d'aller retaper dessus | 10:04:10 |
