Skip to content

2022

Portable LaTex

Dato che ho l'esigenza di creare dei documenti LaTex sulla mia macchina Windows 11, ho verificato quali soluzioni siano possibili.

Esiste un'ampia scelta di possibilità ma dato che il mio utilizzo sarà saltuario, ho ritenuto che la versione MikTex fosse la più vicina alle mie esigenze, soprattutto per il fatto che si trova disponibile anche in versione Portable.

Ho quindi deciso di installarla sotto la mia cartella usuale per i software portable:

 c:\Users\[username]\Documents\sw\

Nella sezione MikTex Downloads si trova la versione Windows, ed è possibile scegliere l'installer standard, la versione "portable" oppure la versione installabile a riga di comando, utile per distribuire il software in automatico su numerosi computer aziendali.

La versione "portable" in realtà non richiede un installer separato: va semplicemente scaricato l'installer per windows e rinominato in miktex-portable.exe. Una volta eseguito è necessario assicurarsi di scegliere la seguente cartella di destinazione:

c:\Users\[username]\Documents\sw\miktex\

al cui interno si troverà lo script miktex-portable.cmd pronto per essere lanciato.

Tale script una volta lanciato apre una piccola icona nella barra di windows, dalla quale è possibile lanciare il terminale TeXworks. Oppure, in alternativa, è possibile eseguire ogni programma che si troverà nel seguente percorso:

c:\Users\[username]\Documents\sw\miktex\texmfs\install\miktex\bin\x64\

Un file di partenza che ho incominciato ad utilizzare è il seguente:

\documentclass{article}

\usepackage{graphicx}
\usepackage{amsmath}

\input{./pandoc_syntax.tex}

\begin{document}
    \input{./title.tex}
    \tableofcontents
    \newpage

    \section{Hello World!} % creates a section

    \textbf{Hello World!} Today I am learning \LaTeX. %notice how the command will end at the first non-alphabet charecter such as the . after \LaTeX
     \LaTeX{} is a great program for writing math. I can write in line math such as $a^2+b^2=c^2$ %$ tells LaTexX to compile as math
     . I can also give equations their own space: 
    \begin{equation} % Creates an equation environment and is compiled as math
    \gamma^2+\theta^2=\omega^2
    \end{equation}
    If I do not leave any blank lines \LaTeX{} will continue  this text without making it into a new paragraph.  Notice how there was no indentation in the text after equation (1).  
    Also notice how even though I hit enter after that sentence and here $\downarrow$
     \LaTeX{} formats the sentence without any break.  Also   look  how      it   doesn't     matter          how    many  spaces     I put     between       my    words.

    For a new paragraph I can leave a blank space in my code.
\end{document}

dove ho importato la seguente definizione dei colori:

% color syntax from pandoc
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
\newenvironment{Shaded}{}{}
\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}}
\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\BuiltInTok}[1]{#1}
\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}}
\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}}
\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}}
\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}}
\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
\newcommand{\ExtensionTok}[1]{#1}
\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}}
\newcommand{\ImportTok}[1]{#1}
\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
\newcommand{\NormalTok}[1]{#1}
\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}}
\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}}
\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}}
\newcommand{\RegionMarkerTok}[1]{#1}
\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}}
\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
% end of color syntax

e la seguente prima pagina:

\begin{titlepage}
    \newcommand{\HRule}{\rule{\linewidth}{0.4mm}}

    \center
    \textsc{\LARGE Marjor heading}\\[0.5cm] % Major heading such as course name
    \textsc{\large Main heading}\\[0.5cm] % Main heading such as the name of your university/college
    \textsc{\large Course title}\\[1.5cm] % Minor heading such as course title
    \includegraphics[width=4cm]{logo.jpg}\\[1.5cm]


    \HRule\\[0.4cm]
    {\huge\bfseries Project}\\[0.4cm]   
    \HRule\\[2.5cm]

    {\large\textit{Author}}\\
    Federico \textsc{Thiella}

    \vfill\vfill\vfill

    {\large\today}
    \vfill
\end{titlepage}

Per inserire del codice sorgente correttamente colorato e formattato, ho pensato di scrivere il codice in formato Markdown e di tradurlo in LaTex con Pandoc

pandoc codice.md -t latex

anche Pandoc sarà oggetto di un prossimo articolo!

Portable Tomcat

In questi giorni avevo necessità di testare nella mia macchina di sviluppo delle servlet utilizzando la versione portable di Apache Tomcat.

Di seguito la procedura che ho utilizzato.

Predisposizione Ambiente

Ho scelto di installare tutti i software portable sotto la directory sw della cartella dei documenti:

c:\Users\[username]\Documents\sw\

Ho quindi scaricato la versione 64-bit per Windows in formato zippato dalla sezione Download di Tomcat 10 ed ho estratto il contenuto in:

c:\Users\[username]\Documents\sw\apache-tomcat-10\

Il sistema richiede che sia definita la variabile di ambiente JRE_HOME, nel caso in cui non sia già configurata nel sistema è consigliabile predisporre il file setenv.bat all'interno della cartella bin come segue:

@echo off
set "JRE_HOME=c:\Program Files\Java\jdk-17.0.2\"
exit /b 0

Attivazione del server

Dato che si tratta di un ambiente di test, non ho necessità che il sistema sia sempre in esecuzione ma lo voglio lanciare quando necessario.

I comandi da lanciare sono pertanto, in sequenza, i seguenti:

setenv.bat
catalina.bat run

Mentre per terminare è sufficiente un normale CTRL+C.

Configurazione CmdEr

Dato che utilizzo il sistema CmdEr ho pensato di predisporre il seguente script che configura l'ambiente e lancia il server. L'ho chiamato catalina.cmd all'interno del seguente percorso C:\Users\[username]\Documents\sw\cmder\bin in modo che sia disponibile direttamente dalla console:

@echo on
pushd "c:\Users\[username]\Documents\sw\apache-tomcat-10.0.27\bin\"
call setenv.bat
call catalina.bat %*
popd

Configurazione utente Tomcat

Sotto la directory conf di Tomcat si trova il file di configurazione tomcat-users.xml al quale ho aggiunto, nella sezione users, la seguente definizione:

Accesso al sistema

Il sistema è accessibile quindi via browser al seguente indirizzo http://localhost:8080/.

L'installazione in ambiente di produzione richiede naturalmente una configurazione più attenta e curata (gestione privilegi utente, permessi file e directory, gestione servizi, gestione e rotazione log, ...) ma non è oggetto di questo articolo.

Recuperare una Password cifrata da Pentaho

Connessioni Database

Se si utilizza un repository centralizzato su database, Pentaho registra le informazioni legate alle connessioni (host_name, database_name, ..) nella tabella r_database, assieme alle credenziali in formato "offuscato". Non si tratta di un hash monodirezionale ma di un formato che, pur non direttamente leggibile, può essere facilmente decifrato.

select
  id_database,
  name,
  username,
  password
from
  r_database

Recupero password Offuscate

Le password offuscate sono precedute dalla stringa Encrypted. Se prendiamo come esempio la password prova, questa verrà salvata in tabella con la stringa Encrypted 2be98afc86aa7f2e4cb79ce60cc9db9db.

Quale metodo viene utilizzato per codificare e decodificare le password? Pentaho utilizza la libreria Encr.java che richiama diverse funzioni presenti in KettleTwoWayPasswordEncoder.java.

Un sistema per decifrare la password è dimostrato nella trasformazione Pentaho-Kettle-Password-Decrypt che lo trovo interessante perché permette di integrare la libreria Java che gestisce l'offuscamento delle password all'interno di una trasformazione, importanto la libreria e definendo la funzione da richiamare:

import org.pentaho.di.core.encryption.Encr;
Encr.decryptPassword(encrypted_password)

Tuttavia non è strettamente necessario utilizzare questo sistema.

Facendo una breve analisi del codice sorgente, si riesce facilmente ad individuare la logica del funzionamento, ovvero la definizione di una chiave "segreta":

public KettleTwoWayPasswordEncoder() {
    String envSeed = Const.NVL( EnvUtil.getSystemProperty( Const.KETTLE_TWO_WAY_PASSWORD_ENCODER_SEED ), "0933910847463829827159347601486730416058" ); // Solve for PDI-16512
    Seed = envSeed;
}

(che corrisponde alla costante KETTLE_TWO_WAY_PASSWORD_ENCODER_SEED nel caso essa sia configurata, oppure al valore fisso 0933910847463829827159347601486730416058)

e l'algoritmo di codifica/decodifica che, senza sorpresa, avviene semplicemente tramite OR esclusivo. Il codice che decifra la password, semplificando al massimo e togliendo diversi controlli, è sostanzialmente questo:

import java.math.BigInteger;

public class Main
{
        public static void main(String[] args) {
                String envSeed = "0933910847463829827159347601486730416058";
                String encrypted = "2be98afc807ce808daa1dab65d281bc8e";
                int RADIX = 16;

                BigInteger bi_confuse = new BigInteger( envSeed );
                BigInteger bi_r1 = new BigInteger( encrypted, RADIX );
                BigInteger bi_r0 = bi_r1.xor( bi_confuse );

                System.out.println(new String( bi_r0.toByteArray() ));
        }
}

"Dato un sufficiente numero di occhi, i bug tendono a zero" non funziona

Commento su un blog del 2022, in risposta a una discussione sulla Legge di Linus e sul ruolo del code review nell'open source.

L'idea che "dato un sufficiente numero di occhi, i bug tendono a zero" non funziona.

Trovare bug è un lavoro a tempo pieno, e spesso complesso. Non è che ti metti a leggere il codice sorgente sotto l'ombrellone e sei in grado di scoprire e risolvere i bug. Qualcuno forse, ma solo se il bug è banale o il codice è stato scritto da un principiante.

Il problema della Legge di Linus

La frase di Eric Raymond — "given enough eyeballs, all bugs are shallow" — è una semplificazione affascinante ma fuorviante. Funziona per i bug evidenti, quelli che si vedono leggendo il codice con attenzione. Non funziona per i bug che contano davvero.

I bug seri sono spesso:

  • di concorrenza, si manifestano solo in determinate condizioni di timing, e non si vedono leggendo il codice;
  • di stato, dipendono da una sequenza specifica di operazioni, che il lettore non può ricostruire senza eseguire il programma;
  • di casi limite, coinvolgono input che il lettore non ha motivo di considerare, perché non sono nel percorso principale;
  • di integrazione, emergono solo quando il codice interagisce con altri componenti, versioni diverse, ambienti diversi.

Questi bug non si trovano "guardando". Si trovano testando, strumentando, eseguendo. E il code review, da solo, non basta.

Il caso del codice offuscato

Se poi qualcuno vuole intenzionalmente offuscare del codice e nascondere delle funzionalità, il discorso cambia completamente.

Il code review diventa inefficace: il codice è scritto apposta per sembrare innocuo. Servono analisi dinamiche, reverse engineering, strumenti di tracing. E anche con tutto questo, dipende caso per caso: potrebbe essere molto difficile da scoprire.

Questo vale sia per il codice open source che per quello proprietario. Anzi, nel caso del codice proprietario la situazione è peggiore, perché non hai nemmeno la possibilità di leggere il sorgente.

Conclusione

La Legge di Linus ha un fondo di verità — più occhi possono trovare più bug — ma è una verità statistica, non una garanzia. E vale solo per i bug che si possono trovare leggendo. Gli altri richiedono lavoro, strumenti, e tempo.

Trovare bug è un mestiere. Non è una passeggiata sotto l'ombrellone.