Preparare il progetto¶

Prima di rilasciare del codice come software libero bisogna prestare molta attenzione a ogni singolo contenuto che dovrà essere caricato sul repository e che di conseguenza diventerà pubblicamente fruibile. Bisogna assicurarsi che ogni file (anche a quelli nascosti che a volte potrebbero sfuggire ad un’analisi superficiale) sia adatto alla visualizzazione pubblica, inclusi i commenti del codice, che potrebbero contenere frasi inadatte alla pubblicazione, come la seguente

// Questa funzione fa schifo, ma non ho voglia di riscriverla.
function foo() {
    ...
}

Il codice non deve inoltre contenere informazioni confidenziali come password e token di autenticazione (nemmeno di ambienti di test o sviluppo). usati per accedere a servizi tramite rete.

Il modo migliore è utilizzare strumenti di analisi statica Static Application Security Testing (SAST) disponibili anche con licenze open source.

Dopo aver utilizzato uno strumento di SAST, è possibile fare una ulteriore validazione manuale. Ad esempio, per individuare nomi host, indirizzi di posta elettronica e indirizzi IP, è possibile eseguire questo comando in console:

egrep -r '\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b"

\|([0-9]+\.){3}[0-9]+' ${SOURCE_PATH:=.}

Oppure, per trovare i commenti nei sorgenti in linguaggi Java/C/C++/Go/Objective-C/Objective-C++/Swift/Kotlin è possibile usare il seguente comando:

find ${SOURCE_PATH:=.} -type f \| egrep

'\.(c|cc|h|cpp|go|java|kt|m|mm|swift)' \| while read f; do echo

"------------ $f ------------------"; sed -n -e '/\/\*.*\*\// {p;

b}' -e '/\/\*/,/\*\//p' -e '/\/\//p' "$f"; done

Infine, per vedere i commenti in Python/Bash:

find ${SOURCE_PATH:=.} -type f \| egrep '\.(py|sh)' \| while read f; do
echo "------------ $f ------------------"; grep -o "#.*" "$f"; done

Questi sono solo alcuni esempi utili per trovare rapidi riscontri ma deve essere cura del maintainer effettuare dei controlli approfonditi in questa fase preparatoria alla pubblicazione.

Se è stato utilizzato il sistema di versionamento (e.g. git, svn, ..) fin dall’inizio dello sviluppo le informazioni confidenziali potrebbero restare visibili nella history. Nella fase di preparazione bisogna quindi rimuovere le informazioni sia dal codice finale che dalla history. Per effettuare questo tipo di operazione esistono diversi strumenti. Il documento Removing sensitive data from a repository (scritto dalla piattaforma GitHub ma applicabile in generale a tutti i repository git) rappresenta una guida utile per rimuovere in sicurezza le informazioni sensibili dal proprio codice sorgente e, di conseguenza, dalla history del progetto.

Si raccomanda di eseguire alcuni controlli di base sulla qualità e sulla sicurezza del codice prodotto, utilizzando strumenti disponibili gratuitamente. Ad esempio, molti IDE moderni includono già strumenti di linting per controllare l’assenza sia di errori che di warning, per controllare l’esistenza della documentazione, eventuale codice non utilizzato, variabili non inizializzate e così via. È fortemente consigliato l’utilizzo di questo tipo di strumenti già in fase di sviluppo per trovare e rimuovere i problemi in fase embrionale. Inoltre, si suggerisce di inserire questi controlli (ad es., linting) anche nella propria toolchain di build. La ridondanza, in questo caso, può essere d’aiuto.

Numerosi sono gli strumenti di audit gratuiti che effettuano controlli di sicurezza e di qualità ulteriori per progetti di software libero. Come supporto per la scelta è possibile controllare le comparazioni degli strumenti sia FLOSS che di mercato in queste liste:

• Source Code Analysis Tools

• Source Code Security Analyzers

Come vedremo nel capitolo dedicato, alcuni di questi strumenti sono facilmente integrabili all’interno di diverse piattaforme di code hosting o di Continuous Integration: questo permette di eseguire una serie di controlli automatici per ogni operazione che viene eseguita sul repository (ad esempio, ad ogni commit) ed è quindi considerata una buona pratica.

Gestione delle dipendenze¶

Spesso, nello sviluppo di software, gli sviluppatori usano librerie scaricate localmente nella propria directory di sviluppo. Questa modalità, sebbene possa sembrare utile in fase di testing o prototipazione nell’ambiente di sviluppo locale, è considerata una cattiva pratica nello sviluppo di applicativi moderni. Essenzialmente un approccio di questo tipo comporta una forte difficoltà nella gestione sul lungo periodo, diversi problemi nell’aggiornamento di ogni singola dipendenza e l’impossibilità di usare strumenti automatizzati di rilevazione di vulnerabilità.

È invece buona pratica gestire le dipendenze esterne del software da rilasciare usando il gestore di pacchetti del linguaggio usato (ad es. npm, composer, ecc.). In questo modo le dipendenze e le loro versioni saranno dichiarate all’interno di un file tracciato da git e presente nel repository (ad es., package.json, ecc.) il che rende la loro gestione e l’aggiornamento più facile e immediato. Per un approfondimento è possibile consultare la sezione dedicata della 12 factor app (https://12factor.net/it/dependencies).

Inoltre, anche in questo caso esistono degli strumenti automatizzati che facilitano non solo l’aggiornamento delle singole dipendenze, ma anche la segnalazione di potenziali vulnerabilità in una particolare versione utilizzata. Questi strumenti sono spesso disponibili direttamente all’interno delle piattaforme di code-hosting o possono essere trovati sotto forma di plugin facilmente installabili. Le singole dipendenze vengono analizzate e, nel caso vi siano delle potenziali vulnerabilità, il maintainer verrà notificato e spesso la soluzione sarà suggerita in automatico.

Tra gli strumenti disponibili è possibile citare:

• npm-audit, strumento FOSS per la gestione delle dipendenze e notifica delle vulnerabilità per Javascript/Node.js

• Dependency Scanning GitLab, scanner integrato nella piattaforma (solo alcune versioni)

• Dependabot - ora integrato in GitHub

• Snyk, sistema proprietario in SaaS disponibile gratuitamente per progetti di software libero.

Molto software libero moderno è composto da numerosissime dipendenze, come ad esempio librerie di terze parti, e pensare di aggiornarle indipendentemente senza utilizzare degli strumenti di supporto è un’operazione molto esosa e incline ad errori. È perciò fortemente consigliato adottare le buone pratiche qui descritte sia per la gestione delle dipendenze tramite il gestore dei pacchetti che per quanto riguarda gli strumenti di supporto messi a disposizione dalle varie piattaforme.

Responsabilità di terzi¶

Le licenze chiariscono che gli autori del software non hanno nessuna responsabilità in merito alla completezza e funzionalità, e che è sempre l’utente a doversi assumere la responsabilità per l’adozione di tale codice.

Ad esempio, questo è quanto prevede la BSD-3:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

È dunque compito di chi sviluppa e mantiene il software rilasciato in come software libero assicurarsi che sia sicuro, privo di bug o di vulnerabilità, e quindi adottare strumenti finalizzati alla qualità del codice, come ad esempio: unit tests, CI, auditing, checklist per feature parity. Problemi o limitazioni note devono essere accuratamente documentati come issue, e nei casi più importanti anche esplicitati nel README.

I file da inserire nel repository¶

E’ buona pratica che un repository contenga dei file che permettano al visitatore di familiarizzare col progetto, e in particolare capire:

• se è il progetto che stanno cercando e se gli è utile;

• come iniziare a lavorare sul progetto nel minor tempo possibile (e.g. entrare nel dettaglio la natura del progetto

  senza dover leggere da principio il codice sorgente).

Tra questi file ci sono il README, il file LICENSE e il file AUTHORS. Vediamoli ora più in dettaglio

Rilascio¶

Una volta creato il repository pubblico è necessario pubblicare tutto il codice sorgente contenente i file già elencati più sopra. Se il software da pubblicare è già stato scritto in modalità “chiuso”, è importante riportare tutti i commit passati in modo da facilitare l’interazione con i contributori terzi. Effettuare un singolo commit in modalità “bulk” è considerata una cattiva pratica, proprio perché non rende trasparenti le singole modifiche effettuate nel tempo dagli sviluppatori.

I messaggi di commit sono importanti in quanto comunicano in breve quali operazioni sono state effettuate dallo sviluppatore. Esistono anche in questo caso diversi approcci e buone pratiche. Una di queste è Conventional Commits che presenta il seguente formato:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Lo scopo è quello di trasmettere molte informazioni in modo semplice, che siano leggibili e interpretabili, sia da essere umani che da sistemi automatici. Anche in questo caso sarà dunque possibile sfruttare degli automatismi integrabili nelle piattaforme di code hosting o di Continuous Integration.

Dopo il rilascio, tutte le operazioni successive che verranno effettuate saranno pubbliche. Per prevenire la pubblicazione di altre informazioni sensibili oppure evitare di commettere errori prima del push sul repository è considerata una buona pratica l’utilizzo di sistemi di controllo pre-commit. Tali sistemi, come ad esempio https://pre-commit.com/, si possono installare negli ambienti locali di sviluppo e permettono di eseguire una serie di controlli prima di effettuare il commit o il push: in questo modo la pubblicazione viene bloccata fino a che il problema non è risolto.