# [Portage] Disabilitare i digest

## Fuzzo

Ciao a tutti!

Ho notato che portage verifica per ogni file ben 4 digest più il filesize   :Rolling Eyes: 

Vorrei sapere se è possibile disabilitarne 3 (magari lasciando solo SHA256, ma basterebbe un MD5 a mio avviso) e il filesize...

----------

## Luca89

PerchÃ¨ vuoi fare ciÃ²? Non Ã¨ piÃ¹ sicuro controllare il file tramite vari algoritmi anzichÃ¨ uno solo?

----------

## Fuzzo

Si, certo, è più sicuro ma è anche da maniaci   :Very Happy: 

Penso che uno solo possa bastare, riducendo (non di tanto) il tempo necessario all'emerge dei pacchetti   :Smile: 

----------

## fejfbo

Il minimo tempo che perdi con quei controlli (con i computer che ci sono ora nemmeno quasi ce ne si accorge) per me non vale il "rischio" di non farli

----------

## .:chrome:.

 *Fuzzo wrote:*   

> Si, certo, è più sicuro ma è anche da maniaci   

 

questi sono i ragionamenti che portano a software-aborti del calibro di windows

e poi non mi sembra che il tempo necessario a verificare i digest sia paragonabile a quello necessario per la compilazione

----------

## gioi

 *fejfbo wrote:*   

> Il minimo tempo che perdi con quei controlli (con i computer che ci sono ora nemmeno quasi ce ne si accorge) per me non vale il "rischio" di non farli

 

Ma scusa... anche ad avere un processore lento, e pure ammesso di emergere solo pacchetti minuscoli, cmq il tempo di verifica dei digest << compilazione/installazione... che senso ha?

Secondo me è più da maniaci delle prestazioni disabilitarli, che da maniaci (paranoici delle sicurezza) tenerli!

----------

## Fuzzo

Le ragioni per le quali di default i digest attivi sono 4 le conosciamo tutti. 

Voglio vedere chi mi trova 2 file che diano lo stesso MD5   :Mad: 

Il fatto è che a casa ho ISDN condivisa con mio fratello e ho pochissimo tempo per i download dei file: il tempo per la "ripresa" dell'emerge di 60 pacchetti quando ti mancano solo gli ultimi 2 per me è di vitale importanza.

La domanda non è sull'utilità dei digest, che ribadisco tutti conosciamo, ma se sapere o meno dirmi come lasciarne solo 1 (e, per acconentarvi, sarà SHA256   :Very Happy:  )

----------

## Onip

@Fuzzo

Se hai problemi di tempo puoi abilitare il parallel-fetching: intanto che emerge compila vengono scaricati in background tutti i distfiles necessari ai pacchetti successivi.

Basta aggiungere parallel-fetch alle FEATURES

----------

## Luca89

Quoto Onip, il risultato che vuoi tu Ã¨ piÃ¹ facile raggiungerlo con il parallel-fetch oppure con un "emerge -f" preventivo.

----------

## .:chrome:.

 *Fuzzo wrote:*   

> Le ragioni per le quali di default i digest attivi sono 4 le conosciamo tutti. 
> 
> Voglio vedere chi mi trova 2 file che diano lo stesso MD5   

 

tu non hai mai letto gli articoli sulle collisioni di MD5, SHA-0, SHA-1, SHA-256, vero?

 *Fuzzo wrote:*   

> Il fatto è che a casa ho ISDN condivisa con mio fratello e ho pochissimo tempo per i download dei file: il tempo per la "ripresa" dell'emerge di 60 pacchetti quando ti mancano solo gli ultimi 2 per me è di vitale importanza.

 

discorso assolutamente privo di senso. a verificare il digest ci mette pochi secondi. meno di quanto sia necessario per scaricare il pacchetto stesso, soprattutto se hai una linea lenta

 *Fuzzo wrote:*   

> La domanda non è sull'utilità dei digest, che ribadisco tutti conosciamo, ma se sapere o meno dirmi come lasciarne solo 1 (e, per acconentarvi, sarà SHA256   )

 

perché SHA-256? SHA è broken

generare collisioni su un algoritmo di crittografia non è tanto difficile

generarle contemporaneamente su 4 hash è estremamente difficile (forse impossibile)

per la cronaca. SHA-256 non è ancora stato rotto in pratica, ma sulla carta si.

e RMD160 dove lo lasci? in determinate condizioni è più robusto e affidabile di SHA

se sei così convinto delle tue argomentazioni, e che sia tanto importante risparmiare 2 secondi su 2 ore di compilazione puoi sempre usare gli algoritmi ottimizzati

----------

## Fuzzo

@luca89

Il fatto è che calcola il MD anche durante il fetch preventivo...

 *k.gothmog wrote:*   

> 
> 
> tu non hai mai letto gli articoli sulle collisioni di MD5, SHA-0, SHA-1, SHA-256, vero?

 

No, ma se metti qualche link sarò felice di farlo...

 *k.gothmog wrote:*   

> 
> 
> discorso assolutamente privo di senso. a verificare il digest ci mette pochi secondi. meno di quanto sia necessario per scaricare il pacchetto stesso, soprattutto se hai una linea lenta

 

Il fatto che io abbia esigenze particolari, tra cui le ridottissime finestre di banda a disposizione, non ti mette in una posizione tale da guidicare il senso o meno dei miei discorsi   :Confused: 

 *k.gothmog wrote:*   

> perché SHA-256? SHA è broken
> 
> generare collisioni su un algoritmo di crittografia non è tanto difficile
> 
> generarle contemporaneamente su 4 hash è estremamente difficile (forse impossibile)

 

Perchè è l'algoritmo che ha più bit nel messaggio e, in teoria, meno probabilità di collisioni. 

Voglio la dimostrazione PRATICA che 2 file diversi con lo stesso size diano lo stesso MD.

 *k.gothmog wrote:*   

> 
> 
> per la cronaca. SHA-256 non è ancora stato rotto in pratica, ma sulla carta si.
> 
> e RMD160 dove lo lasci? in determinate condizioni è più robusto e affidabile di SHA
> ...

 

Io sono fermamente convinto delle mie argomentazioni, come delle mie priorità che sono tali da preferire di risparmiare qualche ms nel calcolo degli hash. Se non sai come fare a disabilitarli, evita di postare   :Mr. Green: 

----------

## Cazzantonio

non l'ho mai fatto ma prova con 

```
FEATURES ="assume-digests"
```

 in make.conf   :Rolling Eyes: 

Leggiti bene 

```
man make.conf
```

 per vedere se è la cosa che serve a te

----------

## .:chrome:.

 *Fuzzo wrote:*   

> Io sono fermamente convinto delle mie argomentazioni, come delle mie priorità che sono tali da preferire di risparmiare qualche ms nel calcolo degli hash. Se non sai come fare a disabilitarli, evita di postare

 

che tu sia convinto di quello che scrivi mi pareva ovvio. quello di cui mi permetto di dubitare è la tua conoscenza della materia che stando a quello che scrivi sembra molto approssimativa:

 *Fuzzo wrote:*   

> Perchè è l'algoritmo che ha più bit nel messaggio e, in teoria, meno probabilità di collisioni.

 

in rete puoi trovare molti documenti che trattano queste argomentazioni

----------

## Fuzzo

@Cazzantonio

Grazie!  :Smile: 

@k.gothmog

Guarda, non mi considero affatto un esperto in materia, ma assumendo che il risultato dell'hash sia influenzato da tutti i bit, a parità di algoritmo, 2^128 (MD5) < 2^160 (SHA1) < 2^256 (SHA256).

Non era mia intenziona scatenare un flame a riguardo perchè, ribadisco, non mi considero un esperto in materia   :Surprised: 

----------

## .:deadhead:.

Non entro nel merito della questione, ma credo che forse un diverso approcio al problema avrebbe portato ad una più rapida soluzione.

Il problema in questo caso non è il calcolo degli hash , bensì il tempo totale impiegato nell'emerge dei pacchetti.

Una domanda così posta avrebbe dato carta bianca a tutte le possibili soluzioni.

Personalmente sono solito, per emerge di numerosi pacchetti, far partire un emerge -fetch in una console e dopo il download dei primi pacchetti far partire in una seconda console emerge -update . Così facendo si risolve in collo di bottiglia. In alternativa c'è il parallel fetch che è stato già citato sopra, ma devo esser onesto, tempo addietro avevo letto che era un po' bacato e non l'ho mai usato.

----------

## Luca89

 *.:deadhead:. wrote:*   

> Non entro nel merito della questione, ma credo che forse un diverso approcio al problema avrebbe portato ad una piï¿½ rapida soluzione.
> 
> Il problema in questo caso non ï¿½ il calcolo degli hash , bensï¿½ il tempo totale impiegato nell'emerge dei pacchetti.

 

Esatto, sono d'accordo sul fatto che questo approccio sarebbe stato molto migliore.

 *Quote:*   

> Personalmente sono solito, per emerge di numerosi pacchetti, far partire un emerge -fetch in una console e dopo il download dei primi pacchetti far partire in una seconda console emerge -update . Cosï¿½ facendo si risolve in collo di bottiglia. In alternativa c'ï¿½ il parallel fetch che ï¿½ stato giï¿½ citato sopra, ma devo esser onesto, tempo addietro avevo letto che era un po' bacato e non l'ho mai usato.

 

Si, non Ã¨ perfetto. Nel suo caso comunque ribadisco che un "emerge -f" preventivo risolve egregiamente il problema, poi ognuno come vuole fare fa.

----------

## Sparker

 *Fuzzo wrote:*   

> 
> 
> Guarda, non mi considero affatto un esperto in materia, ma assumendo che il risultato dell'hash sia influenzato da tutti i bit, a parità di algoritmo, 2^128 (MD5) < 2^160 (SHA1) < 2^256 (SHA256)

 

Questo sarebbe vero, se gli algoritmi di hash fossero tutti perfetti. Ma poichè il problema che porta alla possibilità di creare collisioni (in tempo ragionevole) è insito nell'algoritmo, il numero di bit ha poca importanza.

Comuque, secondo me usare 4 hash è veramente da paranoici, si potrebbe eliminare MD5 che sicuramente è il più broken del gruppo.Last edited by Sparker on Tue Sep 19, 2006 2:29 pm; edited 1 time in total

----------

## Cazzantonio

Volendo velocizzare emerge si può anche usare psyco. C'è un howto sullo wiki che spiega come.

Velocizza tutte le operazioni in python (non le compilazioni ovviamente   :Wink:  )

----------

## Onip

io fino ad adesso non ho riscontrato nessun problema col parallel fetch. mi fate un po' di esempi?

----------

## Kernel78

con un banale emerge -pf ti becchi una lista di url dei pacchetti che dovrebbero essere scaricati, direi che con una riga di bash riesci a scaricare in distfiles tutti i pacchetti così l'isdn la liberi nel minor tempo possibile senza andare a modificare emerge e il suo comportamento ...

----------

## Luca89

 *Cazzantonio wrote:*   

> Volendo velocizzare emerge si può anche usare psyco. C'è un howto sullo wiki che spiega come.
> 
> Velocizza tutte le operazioni in python (non le compilazioni ovviamente   )

 

Lo sconsiglio, spesso da problemi (dovrebbero esserci topic sul forum a riguardo).

----------

## Fuzzo

 *Kernel78 wrote:*   

> con un banale emerge -pf ti becchi una lista di url dei pacchetti che dovrebbero essere scaricati, direi che con una riga di bash riesci a scaricare in distfiles tutti i pacchetti così l'isdn la liberi nel minor tempo possibile senza andare a modificare emerge e il suo comportamento ...

 

Questa mi pare un'idea eccellente!

In questo modo si potrebbe anche ottenere un file da dare in pasto ad un download manager per il solo e semplice download dei sorgenti (effettuabile anche al lavoro o quando mio fratello è a scuola e ISDN non la usa  :Smile:  )   :Very Happy: 

C'è un'opzione di emerge (ne dubito...) che restituisca solo gli URL dei file da scaricare? Quale sarebbe la riga di bash che li estrae?

Aggiungo che così facendo non "sprecherei" il tempo per il calcolo dei MD durante il download, controllo che relegherei volentieri a 10 algoritmi DOPO aver scaricato il tutto.

----------

## bender86

 *Fuzzo wrote:*   

> C'è un'opzione di emerge (ne dubito...) che restituisca solo gli URL dei file da scaricare? Quale sarebbe la riga di bash che li estrae?

 

Esattamente emerge -pf pacchetto. Guarda l'output prodotto e trova il modo di estrarre esattamente le righe che ti interessano (mi sembra che stampi una decina di mirror diversi per ogni file, magari basta un grep con uno dei mirror).

----------

## Maxxer

se vuoi ridurre i tempi di download dai un occhio a deltup (e getdelta)

c'è un howto su gentoo-wiki.com

Se non hai molti overlay e non cancelli i distfiles risparmi parecchio (per firefox 1507 ho scaricato meno di un mega!)!

----------

## Kernel78

Trovi una guida sul wiki italiano

----------

## Ic3M4n

personalmente se vuoi lasciare la linea libera il più velocemente possibile non utilizzerei il parallel-fetch in quanto scarica il sorgente del pacchetto successivo. molto più semplice, immediato e senza problemi è lanciare un emerge -fuDN world in un terminale e da quello a fianco un emerge -uDN world. in questo modo i due processi vanno avanti contemporaneamente e senza perdite di tempo. inoltre non da alcun problema grazie al locking sui sorgenti.

per quanto riguarda il controllo dell'md5 o quello che è io lo lascerei. come hanno detto gli altri non è quello che ti fa perdere tempo.

----------

## Onip

ehm... Veramente il parallel-fetch fa la stessa identica cosa che hai detto tu

----------

## Ic3M4n

no, a meno che non sia cambiato con l'ultima versione di portage prima scaricava esclusivamente il pacchetto successivo a quello in compilazione. ultimamente non l'ho più provato e quindi non so dirti.

----------

## Onip

Quando ho fatto emerge -e world mi pare di ricordare che avesse scaricato tutti quanti i pacchetti, anche se in realtà non ho controllato. Alla prossima occasione, se mi ricordo, ci sto attento

----------

