404 a la lecture pendant une publication etait traite comme un echec : sur un
depot neuf, rien ne partait jamais. Sans sha, l'API des contenus cree le
fichier. Et le lien Wi-Fi de ce telephone perd des paquets (ping 71-236 ms
alors que le port 443 s'ouvre depuis le shell) : deux essais de 20 s valent
mieux qu'une attente unique de 40 s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le telephone verifiait le mot de passe de synchro en telechargeant
l'instantane et s'arretait sur 404 : rien ne partait jamais vers un depot
neuf. Mesure : un 404 de GitHub a pris 16,3 s, au-dela du delai de 15 s du
client et sous le garde-fou de 25 s - d'ou les 'HTTP 0' intermittents.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le formulaire se declare comme une vue ('state?view=edit') : la fleche de
l'en-tete et la touche retour du telephone le referment d'abord.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un crayon ouvre un formulaire pre-rempli : tous les champs modifiables a la
fois, un seul Save, donc UN commit au lieu d'un par champ ('setfields',
plusieurs PatchEntryField dans le meme CommitChange).
L'icone quitte le menu de l'entree pour ce formulaire : From site (recherche),
Image... (galerie, reduite a 128 px, provenance custom) et Remove.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Android ne laisse pas choisir l'app qui passe devant : moveTaskToBack
ramenait souvent l'ecran d'accueil. Le coffre se reverrouillait aussi
apres 30 s, avant qu'on revienne chercher le mot de passe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- OpenContainer reutilisait la cle de l'ancien mot de passe : jamais tant
qu'un nouveau n'est pas verifie
- un essai rate vidait FKey (parametres out TBytes) : derivation dans des
locales, rangee seulement apres succes
- Save coffre ouvert : verification immediate (DoSync), le bon mot de passe
est range dans le coffre scelle ; coffre ferme, le champ est grise
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le sha inchange faisait repondre 'rien n'a change' sans dechiffrer : un
mot de passe faux passait pour bon. Tant qu'il n'est pas verifie, le depot
est retelecharge en entier ; la synchro reprend ensuite si rien n'echoue.
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>
- de sur le champ mot de passe (nouvelle entree et modification), tirage
crypto.getRandomValues avec rejet
- Download vault sans reglages ouvre les reglages
- 404/401 tranches (jeton refuse, utilisateur ou depot inexistant, fichier
absent) et mauvais mot de passe de synchro : les reglages s'ouvrent avec
le message en rouge
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Delphi ecrivait android:debuggable=true meme en Release : sur un telephone
avec le debogage USB actif, adb run-as ouvrait le dossier prive de l'app.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En release le telephone ne sait que reprendre le coffre du depot : l'ecran
d'accueil n'offre plus que Download vault, et RegisterLocal refuse aussi.
Depot vide (404) ou conteneur illisible : rien n'est cree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le scanner du systeme demandait avec quoi ouvrir le lien. L'app ouvre la
camera arriere, decode une image sur quatre et remplit URL + jeton des
qu'un lien pmserver://sync est lu. Rien n'est enregistre avant Save.
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>
Le formulaire New entry n'avait pas le champ et AddEntry ecrivait
totp_secret = '' en dur : il fallait enregistrer l'entree puis la rouvrir
pour poser un second facteur, alors que l'editeur portait deja le champ.
Meme intitule que l'editeur ("2FA secret"), masque pour une note comme
site et identifiant, et achemine par &o= — t, s, u, p, k, d etaient
pris.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FRemoteAhead etait remis a faux a trois endroits - publication,
publication differee, rafraichissement - et aucun ne le disait a la page.
Seul l'allumage etait pousse. Le point bleu restait donc affiche apres la
synchronisation qui venait de le rendre caduc, jusqu'au retour suivant
sur l'accueil.
Un temoin qui reste allume apres qu'on a fait ce qu'il demandait ne
demande plus rien : il decore, et on apprend a ne plus le regarder.
Le drapeau et son affichage passent maintenant par SetRemoteAhead, dans
les deux sens. Meme asymetrie, meme correction que pour le point orange.
PROBE_EVERY_TICKS revient a 40 : la bascule a 8 n'etait que pour rendre
la serie E observable en deux minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le chien de garde mesurait la duree TOTALE, alors que son message dit
"no reply from the server". Sur un coffre devenu gros - 286 Ko - la
reponse arrivait en 841 ms et les vingt secondes suivantes partaient dans
la derivation de la cle puis l'affichage : il criait donc a l'absence de
reponse alors que tout avait reussi, cache ecrit compris. Un faux echec
est pire qu'un vrai, il apprend a se mefier de ce que l'application dit.
Il est desarme des que le statut HTTP est connu, quel qu'il soit : ce qui
suit ne depend plus du reseau, et le voile est leve par le finally.
Au passage, les boutons des reglages n'avaient pas de margin-top : le
champ du code et ses deux boutons se touchaient et se lisaient comme un
seul bloc. Les piles de l'accueil ont leur gap ; ici les elements se
suivent en flux normal, donc c'est au bouton de reserver sa place.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FPending est relu au demarrage, mais PM.setPending n'etait pousse que par
OpenLocalNow : la page n'apprenait donc l'attente qu'en OUVRANT le
coffre. Un demarrage a froid montrait Sync sans point orange - l'ecran ou
l'on decide de synchroniser, et le seul moment ou ce drapeau relu au
demarrage sert a quelque chose. Il fallait ouvrir puis reverrouiller pour
qu'il paraisse.
Les deux temoins se reposent maintenant dans ShowUnlock, donc a chaque
retour sur l'accueil.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il vit en bas des reglages, apres tout le reste, et demande deux appuis :
un effacement sans retour ne se declenche pas sur un doigt qui glisse.
Absent en release, et pas seulement cache : la commande du pont n'est pas
compilee et Delphi ne devoile la section que dans une version de
debogage. Le bouton ne peut donc pas reapparaitre par accident. Verifie -
Release compte 8060 lignes contre 8072 en debug, soit exactement ce bloc.
DropLocalVault efface le cache, le conteneur local et le drapeau
d'attente, chacun sous son propre try : un fichier absent ou verrouille
ne doit pas empecher les deux autres de partir. Les reglages du depot
restent - c'est le coffre qu'on jette, pas la facon d'aller le rechercher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sans biometrie utilisable et sans code pose, le cache s'ouvrait sans rien
demander - or il CONTIENT le mot de passe de sync. Qui tenait le
telephone deverrouille obtenait donc le coffre ET le secret du depot.
Il est desormais scelle sous le mot de passe qui vient de le rapporter :
celui-ci est deja dans ce fichier, donc rien de neuf n'est expose, et
l'utilisateur le connait puisqu'il vient de le taper. C'est aussi la
seule forme de cache qui survive a une reinitialisation du verrouillage
d'ecran.
Pas quand l'appareil sait authentifier : VER_PIN et VER_WRAP s'excluent,
et imposer une frappe a qui a une empreinte serait un recul.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Register et Login mettaient leur gestionnaire d'erreur en file avec
TThread.Queue, puis y lisaient E.ClassName et E.Message. Or la file
s'execute sur le thread principal bien apres que le except a rendu la
main, et Delphi libere E en sortant du gestionnaire : c'etait une lecture
apres liberation.
Elle rendait un message vide - "Login failed: EPMACrypto - " sans la
raison - et parfois une violation d'acces qui remontait a FMX sans rien
laisser au journal. Le vrai motif de l'echec n'a donc jamais ete affiche.
On ne met plus en file que des chaines, qui survivent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le dispatch n'etait garde par rien : une faute dans un handler remontait
jusqu'a FMX, qui affichait "Access violation" avec une adresse, tandis
que le journal ne montrait que la commande recue suivie de rien. On
savait qu'une commande echouait, jamais laquelle ni pourquoi.
On attrape, on nomme, et on rend la main - une commande fautive ne doit
pas laisser l'interface voilee derriere une boite de dialogue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le coffre ouvert ne prouvait rien : il peut l'etre depuis une heure et
rester a l'ecran. Quiconque trouvait le telephone dans cet etat levait la
protection en deux appuis, sans que rien ne le lui demande.
Le code courant voyage maintenant avec la demande, et Delphi le compare a
FPinSealed - ce sous quoi le cache est REELLEMENT scelle, pose seulement
par une ouverture reussie, jamais par un champ.
Fermee au passage : SetUnlockCode('') retirait le code en silence, ce qui
contournait le controle qu'on vient de poser.
Le FBusy de ClearUnlockCode ne sort plus sans un mot - une sortie muette
se lit comme une reussite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un refus s'affichait du meme gris qu'un etat : "Master password: 8
characters at least" se lisait comme "Vault on this device", et rien ne
disait que l'application venait de refuser. StatusErr le met en rouge -
deux procedures plutot qu'un drapeau devine du texte, parce que trier des
messages sur leur contenu a deja detruit un cache dans ce projet. C'est
l'appelant qui sait s'il refuse.
La croix des champs etait calee a top: 8px, en compensation du margin-top
du champ. Les piles annulent ce margin depuis qu'on y a unifie
l'espacement, et la croix restait donc 8 px trop bas. Elle s'ancre
desormais au bord INFERIEUR, le seul que le champ touche dans les deux
cas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il ne servait qu'une fois, a la creation : le cache s'ouvrait ensuite
sans rien demander, et n'importe qui tenant le telephone deverrouille
lisait le coffre.
Il est desormais pose comme code de deverrouillage - c'est exactement ce
que ce format sait faire, et il accepte un mot de passe entier aussi bien
que des chiffres depuis qu'on a retire le clavier numerique. Le cache
porte donc VER_PIN, la seule forme qui survive aussi a une
reinitialisation du verrouillage d'ecran.
Retirable en deux appuis depuis les reglages, pour qui prefere
l'ouverture immediate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Coffre ouvert" se lisait sur le nombre d'entrees. Or un coffre vide en
compte zero, exactement comme un coffre ferme - et le coffre d'essai
l'est. Le garde de DoSync restait donc vrai apres l'ouverture, rearmait
la reprise, et l'on tournait en rond : le journal repetait "Vault opened
from cache", l'interface clignotait et ne repondait plus.
Le meme idiome se trouvait a deux autres endroits. Le second compte :
OnIdleTimer se coupait de lui-meme sur un coffre vide, qui restait donc
ouvert indefiniment - et vide aujourd'hui ne veut pas dire vide dans dix
minutes.
FPlain, le clair en main, est le seul signal qui ne mente pas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le garde ne couvrait que le cache scelle par un code. Depuis que les deux
secrets sont separes, la reconciliation a besoin de celui du conteneur
local - qui ne se pose qu'a l'ouverture - donc un coffre ne ici refusait
aussi, avec "open vault first", et ouvrir ensuite ne relancait rien : le
bouton Sync ne vit que sur l'accueil, et le coffre ouvert on est sur la
liste.
Un seul garde desormais : s'il y a un cache lisible et que le coffre
n'est pas ouvert, on ouvre et on reprend la synchronisation. Un appareil
sans cache n'est pas concerne - c'est le premier telechargement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La separation laissait FVaultPwd vide apres une ouverture depuis le
cache - seules la creation et la connexion le posaient - et la
reconciliation refusait donc en boucle, "open vault first" alors que le
coffre etait ouvert.
Le cache porte un secret et un seul : celui du conteneur local pour un
coffre ne ici, celui du depot pour un coffre publie. Les deux ne
coexistent jamais, puisque la reconciliation detruit le conteneur local
en passant l'autorite au depot. CachePwd choisit a l'ecriture, et la
relecture le range dans la meme case.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le mot de passe de creation scellait le conteneur local ET pretendait
sceller l'instantane du depot. Un coffre cree ici publiait donc sous son
propre mot de passe, que le poste ne savait plus ouvrir - et le
rafraichissement echouait avec "wrong password" sur un depot pourtant
intact.
FVaultPwd ouvre le conteneur local et s'arrete la. Le secret du depot vit
dans les reglages, doit etre le meme sur tous les appareils, et c'est lui
seul qui ouvre et rescelle l'instantane.
Les deux ne se rencontrent qu'a UN endroit, la reconciliation : le
conteneur local s'ouvre sous le sien, puis la cle est jetee avant de
toucher au depot - la garder rescellerait le depot sous le mauvais
secret. Ailleurs ils ne se croisent jamais : un coffre ne ici ne publie
pas, un coffre publie n'a plus de conteneur local.
Migration : rien a rechiffrer. Les coffres existants ont simplement les
deux valeurs egales, et cessent d'etre forces de le rester.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La correction precedente ne portait que sur la creation et la connexion
locales, qui n'arrivent qu'une fois. Le chemin reellement emprunte est
l'ouverture depuis le cache, a chaque lancement : PushConfig y reposait
la valeur de premier lancement, l'ouverture ne la remplacait pas, et
DoSync la prefere a celle du coffre. Les reglages continuaient donc
d'afficher TEST_PWD.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Local vault unreadable" laissait croire a une corruption, donc a une
perte, alors que le coffre est intact dans le depot. Quand Android a
lui-meme detruit la cle - verrouillage d'ecran retire ou reinitialise -
l'application le dit maintenant, et dit aussi que rien n'est perdu.
Le tri passe par un drapeau pose la ou l'invalidation se constate, pas
par un test sur le texte du message : c'est ce tri-la, fait sur des
chaines, qui detruisait autrefois le cache en se trompant.
Le code de deverrouillage accepte un mot de passe, et l'a toujours
accepte - aucune validation n'a jamais impose des chiffres. Seul
inputmode="numeric" le laissait croire, et le clavier numerique
decourageait d'essayer. Clavier complet, libelles et note mis a jour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PushConfig pose FPwd a la valeur de premier lancement - en debogage une
constante, en release du vide - et rien ne la remplacait ensuite. Creer
ou ouvrir un coffre local mettait a jour FSyncPwd seul, si bien que les
reglages continuaient d'afficher l'autre.
Ce n'etait pas qu'un affichage : DoSync PREFERE FPwd a FSyncPwd, au nom
de "ce qui est tape l'emporte" - or rien n'avait ete tape. Les deux
chemins de synchronisation, le rafraichissement de fond et le bouton,
travaillaient donc avec deux mots de passe differents sur le meme coffre.
Le coffre qui vient de s'ouvrir dit desormais son mot de passe, et les
reglages le montrent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le masquage ne demande rien - il suffit de ne pas etre sur l'accueil pour
que la vue disparaisse avant la capture des applications recentes, coffre
ouvert ou non. La restitution, elle, exigeait un coffre ouvert.
Consulter les REGLAGES coffre ferme, puis laisser le telephone se
verrouiller, cachait donc la page pour de bon : au retour il ne restait
que le fond de la fenetre, un aplat bleu sans rien dessus et sans rien
pour en sortir.
La vue revient maintenant dans tous les cas, et APRES le verrouillage
eventuel pour ne jamais montrer une liste qu'on vient d'effacer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
r-zakarya