The Pulse
Microsoft Research afferma di aver usato PDD Kit per verificare formalmente la logica di login in un’app web Rust
Microsoft Research afferma di aver usato PDD Kit per verificare formalmente la logica di login di Pet Store, un’app web full-stack in Rust. Secondo Microsoft Research, il kit trasforma i requisiti espressi in linguaggio naturale in specific
AI.info Team · Scritto con l’IA · verificato ·
Microsoft Research ha descritto PDD Kit in un post pubblicato il 5 novembre 2026 da Alex Lavaee e Matthai Philipose. I ricercatori affermano di aver usato il kit all’interno di Chopin di GitHub Next per verificare formalmente la logica di login di Pet Store, una vetrina online in Rust. L’app full-stack contiene circa 5.000 righe di codice Rust.
La logica di login mette alla prova il kit
Il backend di Pet Store usa Axum e SQLite e gestisce inventario, promozioni, ordini e checkout; la vetrina online è un’app Leptos compilata in WebAssembly. La dimostrazione si concentra sul login: la richiesta dello sviluppatore, formulata in due frasi, specifica che gli utenti devono ricevere un token solo con la password corretta e che solo gli account amministratore devono ricevere token amministratore. Il post afferma che lo sviluppatore ha esaminato gli intenti e non ha mai letto il codice generato riga per riga.
Microsoft Research descrive il problema come uno scarto tra un piano e la sua implementazione da parte di un agente: l’agente può discostarsi dal piano e scrivere test che danno esito positivo per ciò che ha realizzato, non per ciò che lo sviluppatore ha richiesto. Secondo il post, PDD Kit opera come partner all’interno di Chopin, l’ambiente di pianificazione collaborativo in tempo reale di GitHub Next, dove team e agenti possono pianificare in un documento condiviso. Il kit, si legge nel post, pone domande sulla richiesta e registra le risposte in un artefatto che collega gli intenti dell’utente a specifiche formali o test.
Dagli intenti in linguaggio naturale a una dimostrazione con Verus
Secondo il post, il kit converte le parti degli intenti che possono essere formalizzate in specifiche formali e trasforma il resto in specifiche informali per i test. Prima di scrivere il codice, il suo flusso di pianificazione pone domande sulle decisioni da prendere e spiega le parti pertinenti del codice. Una domanda chiede se la password corretta debba sempre produrre un token: una regola secondo cui i token richiedono password corrette consentirebbe infatti anche un sistema di login che rifiuta tutti.
Lo sviluppatore ha scelto di richiedere entrambi i risultati: una password corretta dà accesso a un token, una password errata no. Secondo il post, PDD Kit genera poi automaticamente dimostrazioni che il codice soddisfa le specifiche formali, insieme a test per le specifiche informali. Microsoft Research afferma che una dimostrazione mostra che il codice soddisfa la sua specifica per ogni input, mentre un test superato mostra solo che il codice ha funzionato con gli input provati.
PDD Kit delimita il perimetro della dimostrazione
Microsoft Research afferma che, attualmente, il verificatore usato da PDD Kit è Verus, un linguaggio di dimostrazione per Rust sviluppato congiuntamente da Microsoft Research e da ricercatori di diverse università e istituti di ricerca. Nella prima bozza del piano, il gestore del login rimaneva affidabile per assunzione e veniva testato, mentre la logica decisionale del login veniva dimostrata. Lo sviluppatore ha invece scelto di assegnare al gestore una propria specifica asincrona, affinché la dimostrazione coprisse anche il codice di raccordo che attende le ricerche nel database e firma il token.
Questa scelta ha portato a una nuova funzione asincrona, login_flow, il cui contratto va dai campi della richiesta al token o all’errore HTTP. Il post afferma che la dimostrazione non può vedere il codice in altri crate, come l’hashing di bcrypt, le query di sqlx o la firma di jsonwebtoken, e non può stabilire fatti esterni come il contenuto attuale di SQLite o l’ora indicata dall’orologio. Secondo il post, PDD Kit esplicita il perimetro delle componenti considerate affidabili, ossia la parte della Trusted Computing Base, o TCB, su cui si basa la dimostrazione, e chiede allo sviluppatore di accettare ciascuna di queste componenti.
Lo sviluppatore ha approvato sei componenti considerate affidabili
Per l’esempio del login, lo sviluppatore ha approvato sei componenti considerate affidabili: le ricerche degli account cliente e amministratore, la verifica della password, la generazione del token, il calcolo della scadenza, la gestione degli errori del database e l’involucro del gestore del login. I contratti delle ricerche stabiliscono che ogni ricerca attesa e riuscita restituisce esattamente la riga presente nella rispettiva tabella per quell’indirizzo email o nome utente, oppure nessuna; il contratto della verifica della password stabilisce che Ok(true) indica esattamente la password corretta. Il contratto del wrapper della scadenza stabilisce che la scadenza è esattamente 24 ore dopo l’ora letta dall’orologio.
Il post afferma che PDD Kit inserisce nel piano un test per ogni clausola assunta. Secondo il post, PDD Kit consiglia di iniziare dalle parti più sensibili di un’applicazione e di procedere con la verifica in modo incrementale.