Avash v0.8.0

Avash 0.8.0

• Paquets .deb et .rpm, et nomenclature logicielle. Chaque release
  porte, à côté de l'AppImage, un paquet Debian (Debian 12, Ubuntu 22.04 et
  suivants) et un paquet RPM (Fedora, openSUSE) qui s'installent par le
  gestionnaire de paquets et dépendent du WebKitGTK et du GTK du système ;
  tous deux ont été installés et lancés dans des conteneurs Ubuntu et Fedora
  avant d'être annoncés. Un SBOM au format SPDX 2.3 (les bibliothèques
  exactes de l'espace de travail, du processus RDP et du front, sans les
  arbres de test) est joint et attesté par Sigstore, lié aux binaires. Le
  README ne parle plus de « binaires reproductibles » : la construction ne
  l'est pas (SECURITY.md le disait déjà), elle est attestée.
• Un site. La vitrine d'Avash est sur https://adrienavalon.github.io/avash/
  (et /en/) : ce que fait l'application, pourquoi elle est sûre, comment
  elle est éprouvée, et les fichiers de la dernière version par système,
  lus sur l'API GitHub avec des liens statiques en repli. Une page HTML par
  langue, une feuille de style, aucun service tiers ; publiée par le
  workflow pages.yml à chaque changement de site/ ou des captures.
• Dépendances. La suite bout en bout n'embarque plus extract-zip
  (GHSA-jmr9-qjv8-65gv, traversée de chemin par lien symbolique, sans
  version corrigée) : @puppeteer/browsers est forcé en version 3, qui
  l'a remplacé par modern-tar ; WebdriverIO ne s'en sert que pour
  installer un pilote de navigateur, ce que la suite ne fait jamais.
  L'avis RUSTSEC-2024-0429 sur glib 0.18, imposé par la pile GTK 3 de
  Tauri et déjà justifié dans deny.toml, est clos côté Dependabot avec la
  même raison.
• Flathub. Le manifeste packaging/flathub/io.github.AdrienAvalon.avash.yml
  construit Avash hors ligne dans le bac à sable de flatpak-builder (runtime
  GNOME 49, Rust stable et Node 22 du SDK, sources cargo et npm figées par
  scripts/flathub-sources.sh), avec les droits que le métier impose et
  pas plus : réseau, agent SSH, trousseau, dossier personnel. Construit,
  installé et lancé sur le poste avant d'être soumis ; l'identifiant suit le
  dépôt GitHub, l'application gardant dev.avash.app pour GTK et D-Bus.
• Le panneau SFTP transfère des dossiers entiers, reprend, envoie en
  bandes, empile et copie d'un hôte à l'autre. Télécharger ou déposer un
  dossier le transfère avec son arborescence (sous-dossiers vides compris),
  fichier par fichier. Un transfert annulé (bouton sur sa ligne) ou coupé
  garde ce qui est fait : une carte de reprise à côté du .part (ou du
  fichier local, pour un envoi) note les bandes complètes, et relancer le
  même transfert ne redemande que le reste, si le fichier n'a pas changé
  entre-temps (taille et date) ; un envoi reprend au dernier point de contrôle
  vidé (tous les 4 Mio). L'envoi en bandes parallèles a été écrit, mesuré
  contre un internal-sftp d'OpenSSH, et refusé : la bibliothèque
  pipeline déjà huit écritures, et huit descripteurs en parallèle étaient
  quatre fois plus lents en réseau local pour 1,2 × à 40 ms d'aller-retour
  (les chiffres sont dans la feuille de route). Un serveur qui nomme une
  entrée « ../x » ou « a/b » dans un dossier parcouru est refusé : rien ne
  s'écrit hors du dossier de réception ni hors du dossier cible d'un relais
  (relevé par la revue de sécurité du commit, avec le test qui le joue). Les transferts vont dans une file, trois à
  la fois, chacun avec sa ligne, sa progression, sa vitesse et son bouton
  d'annulation. « Copier vers un autre hôte… » dans le menu d'un fichier ou
  d'un dossier le copie vers un autre onglet SSH : par défaut les octets
  traversent le poste sans y être écrits (relais par bandes, un descripteur
  de lecture ici, un d'écriture là-bas) ; en cochant « copie directe »,
  l'hôte source envoie lui-même par scp, avec l'agent SSH du poste prêté
  le temps de la commande et refusé à tout autre moment. Le serveur SFTP de
  test gagne un système de fichiers en mémoire ; six tests d'intégration
  jouent le dossier récursif dans les deux sens, la reprise après annulation
  (les bandes faites ne sont pas relues, le fichier repris est identique), le
  relais entre deux serveurs et l'annulation ; le scénario bout en bout
  télécharge un dossier et copie un fichier d'un onglet à l'autre contre le
  vrai sshd.
• Des fichiers par le presse-papiers RDP, dans les deux sens. Quand le
  bureau distant copie des fichiers, Avash n'en demande que la liste (noms,
  tailles) et la montre dans une pastille sous le bureau ; un clic, une
  confirmation qui dit combien, quelle taille et où, et les fichiers
  arrivent dans le dossier des téléchargements, par morceaux d'un mégaoctet,
  quatre en vol, dans un .part promu une fois complet, sans jamais écraser
  un fichier existant (« (2) »). Dans l'autre sens, des fichiers déposés sur
  le bureau (ou choisis par la palette, « Envoyer des fichiers au bureau
  distant… ») lui sont offerts : ils se collent dans son Explorateur, les
  dossiers avec leur arborescence, et le poste sert les octets demandés, y
  compris sur la copie verrouillée par le distant si le presse-papiers change
  entre-temps. Le protocole est celui de mstsc (FileGroupDescriptorW,
  flux FileContentsRequest, verrous), porté par IronRDP ; le processus
  d'Avash tient le découpage et l'écriture (rdp-sidecar/src/fichiers.rs,
  neuf tests, dont l'écriture dans le désordre, le refus d'un fichier, la
  réponse courte et le parcours des dossiers). Le serveur RDP de test offre
  un fichier et reçoit ceux du client ; le scénario bout en bout compare les
  octets d'un fichier de 2,5 Mo dans un sens et de 300 Ko dans l'autre. Les
  chemins reçus sont assainis par IronRDP (ni absolu, ni ..), et le contenu
  n'est jamais téléchargé sans accord.
• VNC. Avash ouvre les bureaux VNC (RFB 3.8, authentification VNC
  classique, ZRLE, CopyRect, Raw, taille de bureau suivie) par le même
  processus, le même canal local et le même canvas que le RDP : « Connexion
  directe » et le formulaire d'un bureau enregistré ont un protocole, VNC met
  le port à 5900 et rend l'utilisateur facultatif, le mot de passe va dans le
  trousseau sous un compte vnc:. Le clavier voyage en keysyms X11 (le
  caractère obtenu, « a » sur un AZERTY comme sur un QWERTY, message [14])
  là où le RDP transporte la touche physique ; un cran de molette est un
  bouton virtuel ; le presse-papiers passe dans les deux sens (Latin-1, ce que
  le protocole classique sait faire). Le client est vnc-rs, copié dans
  rdp-sidecar/vendor/ avec ce qu'une relecture a rendu nécessaire avant de
  l'embarquer : toute allocation dictée par le serveur bornée à 8192 × 8192
  pixels, un transmute sur le résultat d'authentification et deux paniques
  remplacés par des erreurs, la file des événements détachée du verrou du
  client (une frappe ne pouvait pas partir tant qu'aucune image n'arrivait),
  un refus sans raison qui s'affichait « unexpected end of file », le
  presse-papiers en Latin-1 au lieu d'UTF-8 doublé ; le flux entier d'un
  serveur hostile a sa cible cargo-fuzz. Un serveur VNC de test
  (test-vnc-server/, rustvncserver, ZRLE) sert une image connue et réagit
  aux entrées ; le scénario bout en bout mesure les pixels : rouge et bleu au
  départ, un carré magenta là où l'on clique, tout vert après « g », le
  keysym 0xe9 reçu pour « é », et un mauvais mot de passe refusé avec sa
  raison. VNC ne chiffre rien : le formulaire le dit, et SECURITY.md
  recommande un tunnel SSH hors du réseau local.
• Avash se soumet à winget. scripts/winget-manifeste.sh <version> écrit
  les quatre manifestes du paquet AdrienCros.Avash (version, installeur
  NSIS par utilisateur avec sa clé de désinstallation, locales en-US et
  fr-FR) depuis la release GitHub et son SHA256SUMS ; ceux de la 0.7.2
  sont dans packaging/winget/ et soumis à microsoft/winget-pkgs depuis
  le fork du mainteneur, par l'API, sans cloner le dépôt. La procédure, et
  l'automatisation possible depuis le workflow Release, sont dans
  RELEASE.md.
• Le front est mesuré, sur la vraie application. scripts/mesures-front.sh
  lance le harnais bout en bout et relève, machine au repos, le démarrage
  (189 ms d'exécution des modules JavaScript en médiane, 101 ms avant le
  premier contenu peint) et la latence à la frappe sur le sshd local (11 ms
  jusqu'à l'écho, 18 ms jusqu'à l'image suivante, médianes sur quarante
  touches). La feuille de route reprend ces chiffres : le cap de 16 ms à la
  frappe est tenu ; le découpage du paquet front attend une mesure qui
  sépare la compilation de xterm.js de l'initialisation d'avash.
• Arch Linux, macOS et les logithèques : les paquets sont prêts. Un
  PKGBUILD (packaging/aur/avash/) construit Avash depuis l'archive de la
  version publiée, front, processus RDP et application, à jeu de dépendances
  figé, et installe binaires, icônes, entrée de menu et métadonnées ; éprouvé
  sur le poste par makepkg puis en installant le paquet. Un cask Homebrew
  (packaging/homebrew/avash.rb, image disque et empreinte de la release,
  livecheck) attend un Mac pour être essayé puis soumis. Un fichier
  AppStream (packaging/dev.avash.app.metainfo.xml, validé par
  appstreamcli) décrit l'application aux logithèques et prépare Flathub. La
  publication sur l'AUR demande le compte du mainteneur ; les étapes sont dans
  RELEASE.md.
• Les correctifs du décodeur RDP remontent à IronRDP. Le drapeau de
  différence des tuiles progressives et la continuité du lecteur SRL sont déjà
  corrigés sur la branche principale d'IronRDP ; la palette RLEX à une seule
  couleur ne l'était pas (l'octet compacté était pris pour une longueur), la
  correction est proposée en amont avec son test
  (Devolutions/IronRDP#1903).
  Les copies portées dans rdp-sidecar/vendor/ restent en place tant que la
  version publiée ne les contient pas.
• Chaîne d'approvisionnement : l'image de la chaîne GitLab est épinglée et
  Node y est installé sans rien exécuter de téléchargé. Le Scorecard de
  l'OpenSSF, désormais affiché sur le README, relevait deux choses dans
  ci/Dockerfile : une image de base sur une étiquette mobile
  (rust:1-bookworm) et le script d'installation de NodeSource téléchargé
  puis exécuté. L'image est fixée par empreinte, Dependabot (écosystème
  docker) propose la suivante ; Node 22 vient de l'archive officielle,
  vérifiée par sa somme publiée, essayée dans un conteneur jetable avant
  d'être confiée à la chaîne. Le paquet wnaf, retiré du registre dans sa
  version 0.14.0 (dépendance de russh par p256), passe en 0.14.1 dans les
  deux arbres. Les autres avis que le Scorecard compte, la famille GTK 3
  non maintenue qu'embarque Tauri sous Linux et l'attaque Marvin sur rsa
  via russh, n'ont pas de correctif en amont.
• Le dépôt se présente comme les projets qu'on adopte. README refondu
  sur le modèle des dépôts les plus suivis : accroche, badges réels (version,
  téléchargements, chaînes, Scorecard de l'OpenSSF, licence), une vraie
  capture en tête, une grille de fonctionnalités, l'installation par système
  avec la vérification des fichiers, un tableau face à PuTTY, MobaXterm,
  Remmina et Termius, et la qualité résumée en un tableau dont le détail (ce
  que chaque dispositif a trouvé) part dans docs/qualite.md. Une version
  anglaise, README.en.md, avec un sélecteur de langue en tête des deux. Les
  captures (docs/captures/) sont prises sur l'application réelle par le
  harnais bout en bout, bac à sable semé d'hôtes plausibles, session SSH
  ouverte sur le sshd local, bureau Windows du parc ; scripts/captures- readme.sh les régénère, mot de passe lu dans le trousseau. Une image
  d'aperçu social (1280 × 640) attend d'être déposée dans les réglages
  GitHub. Côté dépôt : description accentuée, vingt sujets, page d'accueil
  vers la dernière version, discussions ouvertes, gabarits d'issue (défaut,
  proposition, faille redirigée vers la divulgation privée) et de PR, code
  de conduite. Les notes de chaque release reprennent désormais la section
  du CHANGELOG de la version, avec les commandes de vérification ; une
  section absente fait échouer la publication plutôt que de publier sans un
  mot. Puis, sur les deux plateformes : une démonstration animée en tête
  (WebP de onze secondes et cent trente kilooctets, accueil, terminal SSH,
  connexion directe, bureau Windows, montée par le même harnais), un schéma
  d'architecture Mermaid rendu nativement par GitHub et GitLab, un
  « premier lancement en trois gestes », et, côté GitLab, trois badges de
  projet (pipeline, version, licence) posés par l'API ; le rendu GitLab a
  été contrôlé par son API markdown (blocs centrés, largeurs d'images,
  tableaux et badges conservés).

---

Vérifier un fichier téléchargé : sha256sum -c SHA256SUMS depuis le dossier de téléchargement, et gh attestation verify <fichier> --repo AdrienAvalon/avash pour sa provenance. La nomenclature logicielle (SBOM, SPDX) est jointe et attestée elle aussi. Mise à jour automatique depuis une version installée : pastille de version, « vérifier les mises à jour ».

What's Changed

• build(deps): Bump the cargo-mineur group with 3 updates by @dependabot[bot] in #16
• build(deps): Bump the front-mineur group across 1 directory with 4 updates by @dependabot[bot] in #15
• build(deps): Bump rust from 4e4a7e7 to 82150a5 in /ci by @dependabot[bot] in #14

Full Changelog: v0.7.2...v0.8.0