Avash v0.9.1

Avash 0.9.1

• Le lecteur partagé fonctionne contre un vrai Windows 11. Éprouvé contre
  le serveur de test et xfreerdp, il n'apparaissait jamais sur un Windows 11
  du parc : à la Server Client ID Confirm d'un serveur de version 1.13, le
  paquet ironrdp-rdpdr n'annonçait que les cartes à puce et, sans carte,
  n'envoyait rien, alors que Windows attend une Client Device List Announce,
  même vide, avant d'émettre la Server User Logged On qui déclenche l'annonce
  des lecteurs (mstsc et FreeRDP l'envoient toujours, MS-RDPEFS 2.2.2.9).
  Le paquet est porté dans rdp-sidecar/vendor/ironrdp-rdpdr avec ce seul
  changement et deux tests. Rejoué contre un Windows 11 du parc, traces du
  canal à l'appui : le serveur envoie sa Server User Logged On, puis ouvre le
  lecteur et interroge son volume. Un poste dont la session était déjà
  ouverte n'émet pas de Server User Logged On et le lecteur n'y apparaît pas
  tant qu'une ouverture de session ne survient pas, ce qui est le
  comportement de Windows, pas un défaut d'avash.
• Le lot de provenance joint à chaque release. L'attestation Sigstore
  vivait dans l'API de GitHub seulement ; son lot est désormais aussi un
  fichier de la release (avash-vX.Y.Z.intoto.jsonl), vérifiable hors ligne,
  et reconnu par le Scorecard de l'OpenSSF, qui ne voyait aucune provenance.
• Documentation à jour de la 0.9.0 : les README et le site disent le
  lecteur partagé, le son et VeNCrypt, la section Sécurité les gardes qui
  vont avec ; CONTRIBUTING.md décrit la suite Windows complète ; les
  descriptions et sujets des dépôts GitHub et GitLab nomment VNC et le port
  série ; deux badges de plus, couverture et mutants, suivent le relevé du
  workflow qualité.

---

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 ».

Full Changelog: v0.9.0...v0.9.1

Avash v0.9.0

Avash 0.9.0

• Démarrage plus court : xterm.js chargé à part. Deux repères de mesure
  ont montré que l'exécution des modules au démarrage (303 ms de médiane)
  tenait presque entière dans la lecture et la compilation du paquet
  (283 ms), l'évaluation (13 ms) et l'initialisation d'avash (7 ms) n'y
  étant pour rien. xterm.js et ses extensions, la moitié du paquet, sont
  désormais chargés par imports dynamiques (web/xterm-charge.ts), à
  l'oisiveté juste après l'accueil ou au premier terminal : le paquet
  principal passe de 666 à 172 Ko, DOMContentLoaded de 323 à 205 ms de
  médiane, le premier contenu peint de 190 à 152 ms, la latence à la frappe
  inchangée (mesures dans docs/feuille-de-route.md, axe 3).
• Sous AVASH_HOME, les téléchargements restent sous ce toit. Le dossier
  de réception (panneau SFTP, fichiers reçus d'un bureau RDP) était celui du
  système même quand la variable isolait le reste : sous Windows, où
  dirs::download_dir() l'ignore, un bac à sable de test écrivait dans le
  vrai dossier Téléchargements de l'utilisateur. Le sous-dossier des
  téléchargements du foyer est pris s'il existe, le foyer sinon ; un test
  d'intégration et un test du processus le vérifient.
• La suite bout en bout complète tourne sous Windows. Quatre passages
  instrumentés pour trouver que l'action « doubleClick » du protocole
  n'atteint jamais le DOM par le serveur WebDriver embarqué : toute session
  ouverte par double-clic sur un hôte restait « jamais live » sans qu'un seul
  appel n'atteigne le cœur. Les scénarios ouvrent un hôte par une aide qui
  émet l'événement à la main sur ce chemin ; de même pour la frappe dans un
  terminal, le serveur ne synthétisant que keydown et keyup quand xterm.js
  prend les caractères sur l'événement input de son textarea ; le chemin
  d'un enregistrement n'est plus présumé commencer par / ; le scénario de
  réouverture des
  onglets, qui recharge la page, se saute sur ce chemin (le rechargement
  coupe le pilotage embarqué) ; waitForPort attend jusqu'à quinze
  secondes, dépassé une fois en suite complète. Le job e2e-windows de la
  chaîne joue désormais cette suite complète à chaque poussée (sshd
  d'OpenSSH Server, serveurs RDP et VNC de test construits sur place), au
  lieu des seuls scénarios sans serveur ; le workflow d'essai qui a servi
  aux sept passages est retiré.
• Miroir GitLab : le second double-clic sur un hôte. Dans le scénario de
  la vue partagée, le second double-clic suivait immédiatement le premier
  « live », pendant que la barre latérale se reconstruisait (le voyant de la
  ligne) ; la référence était caduque et le double-clic tombait dans le vide
  sans erreur sous WebKitWebDriver. L'aide qui ouvre un hôte attend que la
  même ligne soit rendue deux fois de suite avant de cliquer.
• Chaîne : références visuelles renouvelées (la palette a trois entrées
  de plus : son, partage, diagnostic) ; le workflow qualité ne combinait plus
  --in-place et --jobs, que cargo-mutants refuse ensemble.
• Un dossier du poste comme lecteur du bureau distant (redirection de
  lecteur, MS-RDPEFS). La fiche d'un bureau RDP et la connexion directe
  prennent un « dossier partagé » (champ ou sélecteur du système) ; le
  processus RDP annonce alors le canal rdpdr avec un lecteur « Avash »,
  que le distant voit comme un disque réseau : l'explorateur y lit, écrit,
  crée, renomme et supprime, et n'importe quel programme distant y ouvre un
  fichier. Le serveur pilote tout par des requêtes d'entrée-sortie (ouvrir,
  lire, écrire, énumérer, informations de fichier et de volume, disposition,
  renommage, verrous) ; rdp-sidecar/src/disque.rs y répond depuis un fil
  dédié, hors de la boucle de session, par completion_id. Chaque chemin
  venu du serveur est ramené sous la racine partagée avant toute ouverture
  (.. refusé, parent résolu liens compris et tenu sous la racine, lien en
  dernier composant non suivi) : un serveur hostile ne sort pas du dossier.
  Le volume se présente en NTFS distant (pas FAT32, dont l'explorateur
  refuserait les fichiers de plus de quatre gigaoctets), avec l'espace réel
  du disque du poste. MS-RDPEFS exige que rdpdr soit annoncé avec rdpsnd
  : le son coupé, un canal audio muet (aucun format, pas de drapeau ALIVE)
  reste annoncé pour que le lecteur réponde. Huit tests dans le processus
  (confinement, aller-retour créer-écrire-relire, énumération par motif
  DOS, suppression et renommage, volume, réponse par le fil, motif, dates)
  et deux dans l'interface (dossier absent refusé avant tout lancement, drapeaux du processus). Le
  serveur de test gagne son côté serveur RDPDR (test-rdp-server/src/rdpdr/
  : annonce 1.12, capacités, UserLoggedOn, puis un scénario fixe qui lit
  le volume, énumère, lit bonjour.txt et écrit ecrit.txt, une ligne par
  étape sur sa sortie), sur un ironrdp-server porté dans
  test-rdp-server/vendor/ avec un point d'attache de canal statique que
  le paquet n'offre pas ; 27 tests (décodeurs écrits à la main, automate,
  dialogue complet avec le canal client du paquet), éprouvé aussi contre
  xfreerdp 3.31. Deux scénarios bout en bout : par le formulaire, puis le
  processus seul avec le son coupé.
• VNC chiffré : VeNCrypt, avec le certificat épinglé. Quand le serveur
  offre le type de sécurité VeNCrypt, le client porté le choisit, négocie la
  version 0.2 et un sous-type X.509 (X509Vnc d'abord, X509None sinon ;
  les sous-types TLS anonymes, sans certificat, sont refusés parce qu'ils ne
  prouvent pas à qui l'on parle), rend le flux au processus qui monte TLS
  (rdp-sidecar/src/vnc_tls.rs, le même rustls que le RDP), puis
  s'authentifie sous TLS. Le certificat n'est pas jugé par une autorité mais
  épinglé comme en RDP : clé publique mémorisée au premier contact sous
  vnc:<hôte>:<port> dans rdp_known_hosts, et un changement refuse la
  connexion avant que le mot de passe ne parte, empreintes à l'appui. Sans
  VeNCrypt, l'authentification VNC classique en clair reste ce qu'elle était
  ; le formulaire le dit. Le serveur VNC de test gagne un terminateur
  VeNCrypt (--tls-port, --cert, --key) qui mène la poignée de main et
  TLS puis relie le client au serveur RFB en clair ; deux scénarios bout en
  bout : la connexion chiffrée (type 19, X509Vnc, TLS, pixels, empreinte
  épinglée) et le refus d'un certificat qui change, raison affichée. Au
  passage, l'incrustation « connexion fermée » rend entière une erreur du
  processus sur plusieurs lignes : elle n'en montrait que la dernière, et un
  certificat changé se résumait à « retirez la ligne de rdp_known_hosts ».
• Le son du bureau distant. Le processus RDP annonce le canal rdpsnd
  (MS-RDPEA) avec du PCM 16 bits seulement (44,1 et 48 kHz, stéréo et mono)
  et relaie chaque bloc d'ondes à l'interface (message [20], cadence et
  canaux en tête, un mégaoctet au plus par bloc), qui le joue par WebAudio
  bout à bout sur un curseur de temps, avec le volume que le serveur demande
  ([21]). Aucun périphérique audio ni bibliothèque native dans le
  processus : rien à embarquer dans l'AppImage, rien à réclamer au bac à
  sable Flatpak, et pas de codec à faire décoder à un serveur hostile. La
  palette coupe ou rétablit le son pour les prochaines connexions (le canal
  n'est alors pas annoncé, --sans-son). Trois tests dans le processus
  (formats, message, relais), trois en Vitest (en-tête, désentrelacement,
  gain), et un scénario bout en bout qui pilote le processus contre le
  serveur de test, lequel joue un la 440 Hz : PCM 44,1 kHz stéréo relayé en
  temps réel, pas du silence, et rien avec --sans-son.
• Un onglet fermé laissait son conteneur. closeSession demandait le
  conteneur du terminal après l'avoir disposé, quand xterm avait déjà
  détaché son élément : chaque onglet de terminal fermé laissait un
  conteneur vide dans la zone centrale. Le conteneur se retient avant.
  Vu en écrivant le scénario de la vue partagée, qui compte les conteneurs.
• Test d'annulation d'un téléchargement rendu déterministe. Sur
  l'exécuteur macOS de la chaîne, le transfert de 400 Kio finissait avant
  que la boucle de progression n'ait posé le drapeau d'annulation : Ok au
  lieu de « annulé ». Le fichier passe à 8 Mio (seize blocs par bande, le
  drapeau est vu), et la propriété « la reprise ne relit pas les bandes que
  la carte dit faites » a son propre test, sur une carte posée à la main.
• Publication : un seul motif pour les signatures. Le workflow Release
  listait *.app.tar.gz.sig en plus de *.sig : la signature macOS partait
  deux fois, et la seconde copie, en écrasement, tombait sur un fichier que la
  première venait de remplacer (« Not Found »). La 0.8.0 est restée en
  brouillon sans cette signature, terminée à la main (signature reprise de
  l'artefact du même run, empreintes, manifeste et attestations vérifiés,
  puis publication). Le motif en double est retiré.
• Port série. « Connexion directe » gagne un mode Série : le port (ceux
  du poste sont proposés, un chemin se tape aussi) et la vitesse, 8 bits sans
  parité ni contrôle de flux, le réglage des consoles de commutateurs, de
  routeurs et de cartes. La session vit dans un onglet de terminal comme une
  session SSH (mêmes canaux, même pump, enregistrement asciicast compris),
  sans SFTP ni sonde d'OS. Deux fils bloquants lisent et écrivent le port
  (serialport, sans libudev) ; fermer l'onglet ferme le port. Testé sur un
  pseudo-terminal (openpty) dans le cœur, et de bout en bout sur un
  pseudo-terminal tenu par socat qui renvoie ce qu'il reçoit ; le chemin
  doit ressembler à un port (/dev/…, COMn), pas à un fichier quelconque.
• Vue partagée. Ctrl+Maj+E (le raccourci de Terminator, ou la palette) met l'onglet actif et le
  suivant côte à côte, chacun dans son volet ; un terminal SSH et un bureau
  RDP ou VNC se partagent l'écran de la même façon. L'onglet actif est celui
  des deux...

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 ...

v0.7.2

Full Changelog: v0.7.1...v0.7.2

v0.7.1

Full Changelog: v0.7.0...v0.7.1

v0.7.0

What's Changed

• build(deps): Bump actions/attest-build-provenance from 2.4.0 to 4.2.2 by @dependabot[bot] in #1
• build(deps): Bump actions/setup-node from 4.4.0 to 7.0.0 by @dependabot[bot] in #2
• build(deps): Bump actions/download-artifact from 4.3.0 to 8.0.1 by @dependabot[bot] in #3
• build(deps): Bump gitleaks/gitleaks-action from 2.3.9 to 3.0.0 by @dependabot[bot] in #4
• Add claude GitHub actions 1788384891952 by @AdrienAvalon in #13

New Contributors

• @dependabot[bot] made their first contribution in #1
• @AdrienAvalon made their first contribution in #13

Full Changelog: v0.6.2...v0.7.0

v0.6.2

Full Changelog: v0.6.1...v0.6.2

v0.6.1

Full Changelog: v0.6.0...v0.6.1

v0.6.0

Full Changelog: v0.5.0...v0.6.0

v0.5.0

Full Changelog: v0.4.3...v0.5.0