Partage d'ecran : premier mot et 3 derniers caracteres visibles
(ssh ••••.11), dans le panneau et la recherche rapide. Filtre, copie et
remplissage gardent le vrai texte. Aide de la recherche rapide adaptee aux
commandes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modele "commands" : "# titre" ouvre un groupe, chaque ligne est une
commande. Le corps reste du texte (aucune colonne, sync et APK inchanges).
Panneau : liste avec Copier. Recherche rapide : la note s'ouvre sur sa
liste filtrable ; Entree tape la commande sans Entree et sans vider le
champ, Ctrl+Entree copie, Esc revient. Decoupage teste.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fleches dans l'en-tete du panneau et Alt+fleches, comme un navigateur :
un clic par erreur dans une liste filtree ne force plus a refaire la
recherche. Historique en memoire (50), vide au verrouillage ; la navigation
repasse par openSlideOver et sa confirmation de modifications non
enregistrees. Logique pure testee (history.test.js).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Off = vk 0, non enregistre : la combinaison reste libre pour les autres
applis. Combinaisons retenues en pref DPAPI et rejouees au demarrage, pour
qu'un raccourci coupe le reste coffre ferme. Esc annule enfin la capture au
lieu de fermer les reglages.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Autofill with global hotkey" desactive faisait ignorer a la page toute
demande, barrette comprise. Delphi dit maintenant d'ou vient la demande ;
seuls les raccourcis sont coupes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Demarrage dans le tray, veille ou Win+L avant toute connexion : lockVault
posait state.locked, et seul doUnlock le levait - la connexion complete non.
Le coffre s'affichait ouvert, l'autofill repondait "Vault is locked".
state.locked = false dans enterApp, commun a tous les chemins d'ouverture.
Reproduit avec l'exe precedent, corrige avec celui-ci.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Apres un demarrage en tray, une connexion reussie puis un remplissage
repondait "Vault is locked" sans rien dire de plus. Chaque lockVault() porte
desormais sa cause (inactivite, session Windows verrouillee ou en veille, menu
du tray, PIN faux, geste manuel) avec l'heure ; sans verrouillage connu, le
message donne l'heure de chargement de la page - ce qui trahit une page
rechargee entre la connexion et le remplissage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le champ de recherche gardait la largeur de son texte d'aide (min-width par
defaut) et poussait l'interrupteur et Esc hors du panneau. Le texte d'aide
parlait aussi de copier alors que Fill est souvent actif : il dit "Search..."
tout court. Et le bouton d'une note precise, en mode Fill, qu'une note n'est
jamais tapee.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ouverte par Ctrl+Shift+Q ou la barrette, la recherche remplissait toujours ;
copier restait impossible alors que le remplissage echoue vers une application
lancee en administrateur, ou quand le gestionnaire de Chrome s'en mele. Sans
cible (tray, palette), l'interrupteur n'apparait pas : remplir n'aurait rien a
viser. Le choix est retenu en pref DPAPI, les verbes des boutons et l'aide
suivent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un QR de texte, ou un QR dynamique qui encode un lien de suivi, etait lu puis
ecarte en silence : l'exe repondait "aucun QR 2FA trouve", l'APK continuait de
viser sans rien dire. Le texte d'un autre QR ne part toujours pas a la page ;
seul le fait qu'un QR a ete lu est signale.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'historique du depot affichait "sync from <utilisateur du coffre>" a chaque
envoi du poste, et le telephone y ecrivait ce qu'il venait de faire ("new entry
from phone", "icon fetched from phone", "entries deleted from phone"). Le
contenu est chiffre, ces lignes ne l'etaient pas. Il ne reste que l'appareil
d'origine - le detail vit dans le journal local, ou il sert au diagnostic sans
quitter l'appareil.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un fichier nomme "vault-sync.json" annonce un coffre a qui parcourt la liste
des depots ; le contenu est chiffre, le nom ne l'etait pas. Les configurations
existantes gardent leur nom - c'est l'URL complete qui est enregistree - et le
QR du poste ne raccourcit plus que le nom par defaut courant, sinon le
telephone rallongerait vers un autre fichier.
Synchroniser coffre ferme ouvre d'abord le coffre : ce chemin depliait le
clavier de recherche au milieu d'une synchro.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un jeton faux faisait repondre 401 a GitHub avant tout verdict : le refus
d'un depot public ne pouvait pas s'exprimer. Public = visible en anonyme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub parle la meme API des contenus (base64, sha, corps du PUT) : meme
chemin, reconnu a api.github.com/repos/. User-Agent pose partout (GitHub
refuse sans). Un depot public est refuse avant toute lecture ou ecriture,
Gitea comme GitHub : l'historique garde tous les instantanes chiffres.
Telephone : github.com/O/R se convertit en URL d'API et inversement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- boutons choisis (Full, Password, 2FA, Add current window, Search, Open),
style icones (Segoe MDL2 Assets) ou texte, opacite au repos, allumee ou non
- clic droit sur la barrette : Show icons / Show text en plus de l'opacite
- info-bulles sur chaque bouton
- Add et Search reprennent les corps extraits de Ctrl+Shift+A et Ctrl+Shift+Q
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le scanner du telephone envoyait le texte a une recherche web (Google,
Chrome) : le jeton serait parti a un appui pres. Le lien a schema propre
n'a qu'une application pour l'ouvrir. Rien n'est enregistre avant Save.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le poste genere le QR (DelphiZXingQRCode, Apache 2.0) depuis ses prefs :
URL + jeton, jamais le mot de passe de synchro. Le telephone lit le texte
copie par l'appareil photo et remplit les champs ; Save valide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les onglets etaient visibles par defaut puis masques a la reponse de
/ping : Register restait affiche quelques millisecondes. Ils naissent
maintenant invisibles (visibility, place reservee) et ne sont reveles
qu'une fois la reponse connue — licence valide, ils apparaissent sans
rien decaler ; licence refusee, Register n'est jamais montre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A l'arrivee sur l'ecran de connexion, /ping est interroge : son 404 JSON
exact ne peut venir, avant connexion, que de la 2e couche. Dans ce cas les
onglets disparaissent et seul Login reste. Tout autre echec laisse
Register visible — le masquer a tort empecherait un vrai client de creer
son compte. Le test porte sur le corps JSON, pas sur le seul statut : le
verrou du jeton repond aussi 404, sans corps.
Cosmetique : /register etait deja refuse cote serveur. On cesse seulement
de proposer un formulaire qui n'aboutit jamais.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Avant toute session, le 404 generique ne peut venir que de la 2e couche :
les routes appelees a ce stade existent toutes, et leurs vraies erreurs
portent un autre texte. api() vide son message, toast() ignore un message
vide — qui a rapiece la 1re couche ne voit rien.
Apres connexion rien ne change : pieces jointes et dossiers renvoient un
404 'Not found' legitime qu'il faut montrer. Prix assume : une route
perdue par un build casse echouerait aussi en silence avant connexion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LICENCE-TESTS.md : cinq series. B eprouve ce qui doit tomber (chaine
quelconque, licence tronquee, charge utile trafiquee, autre poste, autre
paire de cles), C le risque symetrique et plus couteux — refuser un
client qui a paye (espaces colles, retour a la ligne, redemarrage
machine). D est dediee a la stabilite de l'empreinte, le defaut deja
rencontre. E delimite la portee de l'activation.
Le plan citait cmd://licence/clear sans moyen de l'appeler : un bouton
"Deactivate (debug)" au bas de Settings -> Licence, revele seulement
quand config.txt existe. Il donne au passage son unique appelant a
ClearLicence, qui etait du code mort.
Le document dit aussi ce qu'aucun essai ne prouve : rapiecer l'exe reste
possible, il n'y a pas de revocation, et le brouillage n'est pas du
chiffrement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Porteur, courriel, date d'emission et Installation ID, lus dans la charge
utile deja verifiee. Rempli une fois au demarrage sur les deux chemins
(deja licencie, activation reussie) : rien n'y change pendant une
session. Section masquee hors navigateur hote.
Les champs sont echappes avant interpolation dans ExecuteJavaScript bien
qu'ils viennent d'une charge utile signee — signee ne veut pas dire
inoffensive.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
C'etait la decision prise, et je l'avais mal lue : "pour le moment 1"
repondait a la question 1, pas "une seule licence".
PM.MachineId melange l'UUID de la carte mere (WMI) et la serie du volume
systeme, puis n'en publie que 16 hexa : l'empreinte se recopie dans un
courriel, l'UUID brut n'a pas a circuler. Un UUID nul ou tout a FF est
rejete — VM et images clonees l'annoncent, et deux postes tomberaient
alors sur la meme empreinte.
Le champ m est compare APRES la signature. m absent = licence flottante,
acceptee : seule la cle privee peut en emettre, et le champ ne peut pas
etre retire sans casser la signature. Cote script -Machine est
obligatoire sauf -Floating explicite.
L'ecran d'activation affiche l'Installation ID : une licence liee ne peut
plus etre emise avant l'installation.
Verifie sur ce poste : liee a lui acceptee, liee a un autre refusee,
flottante acceptee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le cyan de .auth-hint dit "voici l'etat des choses" (session expiree,
coffre verrouille). Un refus n'est pas un etat, c'est un echec : il doit
se distinguer a la couleur avant d'etre lu. Variante .is-error posee sur
le refus, retiree a chaque nouvel essai.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ensureLicence() en tete d'init(), avant tout le reste : un ecran
d'authentification qui s'affiche puis se fait recouvrir donnerait
l'impression que le coffre etait accessible.
L'ecran reprend les classes de l'ecran d'authentification — zero style
nouveau hormis un z-index. Le statut est demande deux fois avant de le
montrer : un demarrage a froid lent manquerait la fenetre de reponse, et
le silence se lirait comme un refus.
Une cle refusee ne dit pas pourquoi, et le journal note le verdict sans
jamais la cle.
ATTENTION : tant que LicencePublicKeyBlob est a zero, l'ecran est
infranchissable. Poser la cle publique avant de deployer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
localStorage meurt avec l'origine a chaque lancement, donc un autofill
desactive revenait sur ON. Miroite en pref DPAPI comme unlockMode et
rememberedUsername ; la copie DPAPI fait autorite, relue dans enterApp
juste avant la poussee des combos vers Delphi.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Synchroniser est une ACTION, pas un reglage. Elle n'existait qu'au fond
du panneau des reglages, a cote de l'URL et du jeton : on l'y configure
une fois, on la declenche tous les jours.
Sans URL, sans "Enable sync" ou sans mot de passe de sync, l'appui ouvre
les reglages ET DESCEND jusqu'a la section - un bouton qui ne peut
qu'echouer ne vaut pas mieux que pas de bouton, et repondre "Sync not
configured" laisse chercher ou reparer. Le panneau n'a pas d'onglets,
c'est une colonne longue : le battement dit lequel des blocs on est venu
chercher.
L'etat est lu SANS les secrets - hasEncPwd dit que le mot de passe existe
sans le lire, ce que loadSyncConfig documente : les tirer les planterait
dans le renderer pour la vie du processus.
L'entree disparait sans le pont, comme la section : le frontend PHP n'a
pas de sortie reseau.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le meme defaut, par une autre porte : restaurer une sauvegarde par-dessus
des entrees existantes passe aussi par encryptImportEntry puis PUT, donc
re-chiffre un mot de passe inchange et fait croire au serveur qu'il a
change. La sync etait la cause de ce qui se voyait, pas la seule.
La regle est extraite en une fonction, keepCiphertextIfSamePassword,
appelee par les deux. Les re-publications partielles - tag, dossier,
migration des metadonnees - sont hors de cause : elles reutilisent deja
le chiffre stocke.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'instantane transporte le mot de passe EN CLAIR, et encryptImportEntry
le re-chiffre avec un IV neuf : le chiffre differe donc toujours, meme
quand le mot de passe n'a pas bouge. Or le serveur decide d'ecrire une
version dans l'historique en comparant les chiffres
(`encrypted_password <> :newenc`) - il voyait une difference la ou il n'y
en avait aucune, et chaque synchronisation qui redescendait une entree y
deposait un doublon date du jour. L'historique montrait la meme valeur
deux fois, a des jours d'ecart.
Le serveur ne peut pas trancher, il ne voit que du chiffre. Seul le
client connait les deux clairs : il compare, et rend le chiffre d'origine
quand ils sont egaux - ce que le commentaire du handler appelle deja
"JS reuses originalEncrypted bit-for-bit".
Trouve en deroulant la serie H sur le telephone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The desktop keeps twenty previous versions per entry and never sent any. It
now sends three.
Three, not twenty, because the trade is not symmetrical. On the desktop they
sit encrypted column by column and never move. In the snapshot everything
travels in the clear inside the container, and comes down into a phone cache
sealed only by the device key - not by the master password. An old password
stays sensitive: it is often still valid somewhere else. The real use of the
list is short - "I changed it recently, what was it?" - and three cover it.
The other seventeen would be copies with no need facing them.
The phone reads them ON DEMAND from the raw snapshot, never into TVault:
loading them with the vault would put every entry's old passwords in the clear
in memory from the moment it opens, for something one looks at now and then.
Copying goes by RANK, not by value. The page displays the text but never sends
it back - that is the bridge's rule everywhere else, and an old password has
no reason to be the exception just because it happens to be on screen.
They leave with the plaintext at lock, on both sides.
Measured on the phone, opening a cached vault: 121 ms to read the sealed file,
14 ms to display it - and then 5718 ms decrypting a snapshot it already had.
The cause is upstream. A sync pushes unconditionally at the end, and the push
is never a no-op: the container is re-encrypted with a fresh salt and IV, so an
identical vault produces completely different bytes. On Gitea that is one more
commit and a new blob sha, so every other device sees a "new" snapshot and pays
a full key derivation to arrive back where it started. It also grew the
repository on every sync that changed nothing, which is the history cost the
plan warns about.
The merged state is now compared against what was pulled, as plaintext -
the only place equality is observable - ignoring snapshot_at, which changes by
construction. Equal means the push is skipped and the sync still counts as done,
timestamp included: having nothing to write is a success, not an absence.
The comparison is deliberately strict. A false negative costs one commit; a
false positive would silence a push that carried a change and lose it for the
other devices. Four tests fix where that line sits, including a modified
updated_at (which arbitrates the merge elsewhere) and a tombstone (a deletion
that has to propagate).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renaming the label from "Sync (WebDAV)" to "Sync (WebDAV or Gitea)" hid the
whole section from the Sync & Backup tab: applySettingsTab maps sections to
tabs BY THEIR VISIBLE LABEL TEXT, so the miss fell through to 'general'. The
section was not lost - it moved to the General tab, which is worse than
missing, because it is nowhere you would look for it.
The map is updated, and the coupling is now written down where the map lives:
these keys are the displayed strings, word for word, and rewording one means
touching both sides.
Checked every key against the labels in index.html; the only sections without
an entry are "Getting started" and "Startup & tray", which belong in General
anyway.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Same discriminant as the Android client - "/api/v1/repos/" in the URL - so one
address tells both ends which transport to speak, and nothing new appears in
Settings beyond a placeholder and a warning.
The bridge stays shared. Three things differ, and they are confined: the header
is "token <PAT>" rather than Basic (Gitea answers a silent 401 to the other),
a PUT carries a JSON envelope with the file base64-encoded inside it, and the
connection test uses GET because the contents API does not answer HEAD.
The sha does the ETag's whole job. It comes back from the pull, rides in the
PUT body instead of an If-Match, and a stale one earns a 409 - handled exactly
like WebDAV's 412, by re-running pull->merge->push so the other device's
changes are folded in rather than clobbered. On a first push `sha` is OMITTED
rather than sent empty: Gitea reads its presence as "replace that exact
version". `branch` is omitted too, so the repo's default is used instead of a
name we would be guessing.
A failing PUT now reads its response body: Gitea explains a 409 or a 422 there,
and without it the error was just a number.
The test button checks the SHAPE of what came back, not only the status. A URL
one path segment off answers 200 with valid JSON that is not a file - which
would otherwise surface much later as "wrong sync password" and send you
looking on the wrong side. Four tests cover that parsing, including the
line-wrapped base64 Gitea sends and the array an accidental directory URL
returns.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The map was built from state.entries only, so a container entry whose uuid existed just in the trash looked fresh and inserted a second row sharing that uuid - the identity the sync engine relies on. Same blind spot as the resurrection bug in applyRemoteSnapshot.
Also documents F9 and warns that emptying the trash is the wrong way to clean duplicate uuids: the tombstone would kill the live twin on the other device.
A backup that silently drops the trash is not a backup: export, empty the vault, import, and the trashed entries were gone for good with nothing said. Both containers now carry state.trashed with deleted/deleted_at, and deleted_at is preserved so a restore resumes the auto-purge clock instead of restarting it - hence its addition to the GET echo.
The sync snapshot deliberately does NOT: the trash is device-local, and re-publishing deleted rows is what produced the duplicate-uuid bug. The two identical export loops were folded into buildBackupEntry first, so the trash handling exists once.
The autofill hotkey already picked whichever field still needed filling; quick search forced the password, so a first unlock or one without a remembered username landed the cursor in the second field.
Both locked-vault paths cancelled the autofill with the default refocus, which returns the foreground to the captured target - right after Delphi had raised our window. Ctrl+Shift+Q flashed for a frame then Notepad took over; Ctrl+Shift+L moved the window twice because focusApp had to take it back.
The trash is a soft delete: no tombstone is written and the rows are absent from state.entries, so the merge read their uuids as missing locally and POSTed them back as fresh live entries. Trashing 30 entries then syncing produced 30 live duplicates alongside the trashed originals - two rows sharing one uuid.
applyRemoteSnapshot now loads the trash and skips any uuid found there. Emptying the trash is what writes the tombstone that propagates the delete.
Assigning .value fires nothing, and the code called soDirtyCheck by hand - so the strength bar, which listens to input, stayed frozen on the previous password. Dispatching the event covers every listener on the field instead of one named handler.
r-zakarya