Metadata-Version: 2.4
Name: 2025_assignment2_vaultPasswordManager
Version: 1.5.0
Summary: Python Password Manager
Home-page: https://gitlab.com/mbroglio/2025_assignment2_vaultPasswordManager
Author: EmacsSoftwares
Author-email: matteo.broglio3@gmail.com
License: MIT
Classifier: Topic :: Security
Classifier: Topic :: Security :: Cryptography
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: MacOS
Classifier: Operating System :: POSIX :: Linux
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: pycryptodome==3.20.0
Requires-Dist: pyperclip
Requires-Dist: tabulate
Requires-Dist: passwordgenerator
Requires-Dist: SQLAlchemy==1.4.41
Requires-Dist: sqlcipher3==0.5.4
Dynamic: license-file

# VAULT PASSWORD MANAGER

Broglio Matteo - 899562\
Caputo Lorenzo - 894528 \
El Hanafi Nadim - 894489\
Fuso Valentina - 899972\
Giuggioli Daniel - 894415 

***Repo GitLab:*** https://gitlab.com/mbroglio/2025_assignment2_vaultPasswordManager.git

## DESCRIZIONE

### Applicazione
Il progetto consiste in un password manager da linea di comando.
Il suo principale scopo è quello di gestire ed archiviare in modo sicuro e completamente locale le credenziali. Viene utilizzato una database SQLite che, tramite la libreria `sqlcipher`, implementa un sistema di crittografia AES-256.
#### Componenti Principali:
1. **Entry Point**: `src/vault.py` è il file principale che gestisce l'interfaccia a linea di comando e le operazioni principali del password manager.
2. **Libreria di Crittografia**: `lib/Encryption.py` gestisce tutte le operazioni di crittografia e decrittografia delle password.
3. **Gestione Database**: `models/` definisce la struttura del database (utenti, categorie, segreti) tramite SQLAlchemy ORM.

### GitLab Repository
Il progetto ha due branch principali:
- `main`: Contiene la versione stabile del codice
- `dev`: Da noi creato, al fine di garantire la presenza di un ulteriore branch dedicato all'introduzioone di nuove funzionalità non ancora definitive. \
All'interno del branch `dev` è stata aggiunta la funzionalità di classificazione delle password sulla base del loro livello di sicurezza.

*Note: Il lavoro si è svolto in contemporanea tra i membri del gruppo tramite la funzionalità Live Share di Visual Studio Code. Per tale motivo le commit risultano tutte effettuate da `mbroglio` seppur comprendano il lavoro svolto dal resto dei componenti*

## Pipeline CI/CD
La pipeline CI/CD è definita nel file `.gitlab-ci.yml`. Essa ha lo scopo di automatizzare il ciclo di vita del software, dalla fase di build fino alla distribuzione e documentazione. \
La pipeline è suddivisa in diversi stage, ognuno con un compito specifico

### CONFIGURAZIONE DELL'AMBIENTE
**Scopo:** Definire l'ambiente di esecuzione per tutti gli stage successivi.

**Strumenti**: Docker, Python 3.11-slim

**Motivazione:** Docker garantisce un ambiente di esecuzione isolato. Python 3.11-slim è scelto per la sua leggerezza e compatibilità con le librerie del progetto. Le dipendenze come `gcc`, `libffi-dev`, `libssl-dev`, `make`, `libsqlite3-dev` vengono preinstallate per assicurare che tutti i pacchetti Python possano essere installati correttamente.

### STAGE BUILD
**Scopo:** Preparare l'ambiente Python ed installare le dipendenze necessarie tramite `requirements.txt`.

**Strumenti**: venv, pip

**Motivazione:** `venv` crea un ambiente virtuale isolato per il progetto, evitando conflitti tra le dipendenze, esso agisce anche come cache per le installazioni successive e gli artefatti generati. L'aggiornamento di `pip` assicura la compatibilità con le versioni più recenti delle librerie. Il file `requirements.txt` elenca tutte le dipendenze necessarie per il progetto, esse verranno installate tramite `pip`.

**Branch:** Build viene eseguito su tutti i branch per garantire che ogni modifica al codice sorgente abbia un ambiente di esecuzione pronto per le fasi successive.

### STAGE VERIFY
**Scopo:** Effettuare un controllo del codice prima di procedere alla fase di testing, esegendo in parallelo analisi statica e dinamica.

**Strumenti:** Prospector (Analisi Statica), Bandit (Controlli di Sicurezza, Analisi Dinamica).

**Motivazione:** Garantire la qualità e la sicurezza del codice prima di eseguire i test. L'analisi statica con Prospector identifica problemi di stile, complessità e potenziali bug, mentre Bandit si concentra su vulnerabilità di sicurezza. \
Sebbene vi siano due definizioni differenti, una per ciascun tool, il fatto di appartenere allo stesso stage implica che entrambi i job vengano eseguiti contemporaneamente. \
La configurazione `allow_failure: true` permette alla pipeline di continuare verso gli stage successivi anche se il job termina notificando un warning.

**Branch:** Viene eseguito su tutti i branch per garantire che ogni modifica al codice sorgente venga verificata.

### STAGE TEST
**Scopo:** Verificare il corretto funzionamento del codice tramite l'esecuzione di test unitari e di performance, misurando inoltre la copertura del codice.

**Strumenti:** Pytest, pytest-cov, pytest-benchmark.

**Motivazione:** `Pytest` analizza tutti i file con prefisso `test_` nella cartella `src/` per eseguire i test unitari e di performance. L'uso di `pytest-cov` consente di misurare la copertura del codice, fornendo un report che indica la percentuale di codice testata. \
Viene inoltre eseguito implicitamente un test di performance tramite `pytest-benchmark` per valutare l'efficienza del codice.

**Branch:** Analogamente allo stage Verify, questo job viene eseguito su tutti i branch al fine di garantire che ogni modifica al codice sorgente sia testata.

### STAGE PACKAGE
**Scopo:** Creare pacchetti distribuibili del progetto.

**Strumenti:** setuptools, wheel.

**Motivazione:** `setuptools` e `wheel` sono utilizzati per creare pacchetti Python con lo standard `sdist` e `bdist_wheel`. Questa operazione consente di preparare il software per la distribuzione, facilitando l'installazione in altri ambienti. \
I file `setup.py` e `setup.cfg` permettono di definire le informazioni necessarie per la creazione del pacchetto, come nome, versione, autore e dipendenze.

**Branch:**  Viene eseguito solo sul branch `main` per garantire che solo il codice stabile venga pacchettizzato e di conseguenza preparato per la distribuzione.

### STAGE RELEASE
**Scopo:** Pubblicare i pacchetti creati nella fase di Package su PiPy.

**Strumenti:** Twine.

**Motivazione:** Lo stage di Release, per mezzo di `Twine`, consente di caricare i pacchetti Python su Repository quali PyPi. Questo facilita la distribuzione e l'installazione del software da parte degli utenti finali. \
L'autenticazione avviene tramite un token API memorizzato in una variabile segreta su GitLab. Questo garantisce l'associazione del pacchetto all'account corretto senza esporre credenziali.

**Branch:** Analogamente allo stage Package, lo stage di Release, viene effettuato solo sul branch `main` per garantire che solo il codice stabile venga rilasciato pubblicamente.

### STAGE DOCUMENTATION
**Scopo:** Generare e archiviare la documentazione del progetto.

**Strumenti:** MkDocs, mkdocs-material.

**Motivazione:** Viene utilizzato `MkDocs` per creare documentazione in formato HTML a partire dai file Markdown presenti nella directory `docs/`. \
Il tema `mkdocs-material` offre un design moderno per la documentazione. \
La documentazione generata viene salvata come artefatto della pipeline e pubblicata su GitLab Pages per la consultazione.

**Branch:** Viene eseguito solo sul branch `main` per garantire che la documentazione rifletta lo stato stabile del progetto.
