Re: [OT - di nuovo] consiglio su uso di git.
Il 09/08/2018 20:16, Gollum1 ha scritto: se io ricreo il repository su bitbucket (questa è la mia intenzione a prescindere), posso entrare in ogni repository, aggiungere bitbucket come remote, e caricarli tutti su di esso? le parti in comune dei vari commit verrebbero messe insieme, e quindi avrei una sola versione delle varie commit? le parti non commitate inizialmente, posso farle andare su vari branch in modo che poi facendo una analisi dei soli file modificati, riesca a ricostruire il mio branch di sviluppo principale? eventualmente con i merge del caso? è possibile e affidabile un approccio del genere? Devi fare il contrario: aggiungere gli altri repo al tuo clone di bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli verso il repo definitivo. Mandi. Paolo
Re: Problema installazione debian su hp
Ho usato una debian(stable) net install. E poi non uso uefi perché sinceramente non mi serve.. anche perche ho un hdd da 500 gb -- Inviato dal mio dispositivo con K-9 Mail. Perdonate non la brevità, ma la prolissitá 樂. Se solo potreste vedere il mondo come lo vedo io https://github.com/vincenzogianfelice https://twitter.com/vincenzogi_
Re: Problema installazione debian su hp
Il 12 agosto 2018 18:36:31 CEST, "developermailist@Vincenzo Gianfelice" ha scritto: >Salve ragazzi. Oggi stavo installando debian 9 su un hp, ma ho notato >differenti problemi: > >- 1° il primo problema é che quando parte l installazione, parte in un >modo del tutto insolito: parte giá con la maggior parte dei parametri >configurati in "default" e non posso cambiarli. > che tipo di immagine stai usando? che modalità di installazione hai scelto? quale branch vuoi installare? nel senso, rimani sulla stable, vuoi passare alla testing o vuoi andare addirittura alla unstable? >- 2° ho notato che su certe usb del mio computer, ( perche sto >effettuando l isntallazione tramite usb ) l installazione parte in modo >diverso se la chiavetta usb la attacco a una porta usb piuttosto che a >una altra... bel mistero. Per modo diverso intendo proprio come se >fosse il pc a "dettare le regole" su come deve avvenire l >installazione. > questa mi giunge nuova, a meno che la tipologia di USB influenzi in qualche modo l'installazione (usb1, usb2 o usb3). sinceramente non ho mai notato qualcosa del genere. >Inoltre il pc ha anche il uefi,ma l ho prontamente disabilitato. perché? uefi è comunque il futuro, e se il disco è maggiore di 2TB, sei obbligato ad usare l'accoppiata uefi+gpt il fatto è che in realtà ci ho sempre litigato in malo modo, l'unica volta in cui tutto è andato subito liscio, è perché c'era su l'innominabile che già lo usava, ed io ho provveduto ad installare senza rimuovere la partizione uefi. >Qualcuno che puo darmi qualche spiegazione in merito? io personalmente preferisco installare con la mini ISO, almeno vado direttamente ad installare il branch che mi interessa (solitamente sis). byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Problema installazione debian su hp
Salve ragazzi. Oggi stavo installando debian 9 su un hp, ma ho notato differenti problemi: - 1° il primo problema é che quando parte l installazione, parte in un modo del tutto insolito: parte giá con la maggior parte dei parametri configurati in "default" e non posso cambiarli. - 2° ho notato che su certe usb del mio computer, ( perche sto effettuando l isntallazione tramite usb ) l installazione parte in modo diverso se la chiavetta usb la attacco a una porta usb piuttosto che a una altra... bel mistero. Per modo diverso intendo proprio come se fosse il pc a "dettare le regole" su come deve avvenire l installazione. Inoltre il pc ha anche il uefi,ma l ho prontamente disabilitato. Qualcuno che puo darmi qualche spiegazione in merito? Grazie. -- Inviato dal mio dispositivo con K-9 Mail. Perdonate non la brevità, ma la prolissitá 樂. Se solo potreste vedere il mondo come lo vedo io https://github.com/vincenzogianfelice https://twitter.com/vincenzogi_
Re: Consigli su volumi criptati su LVM e RAID
Il 12/08/2018 03:07, Lorenzo "Palinuro" Faletra ha scritto: On 08/12/2018 02:40 AM, Felipe Salvador wrote: On Sat, Aug 11, 2018 at 05:13:26PM +0200, gerlos wrote: In ultimo, vi chiedo una conferma: nel momento in cui dovessi dismettere i dischi criptati, per rendere inaccessibili i dati sarebbe sufficiente azzerare i primi MB dei dischi, giusto? Non ne ho idea, immagino di si, spesso immaginare non basta. Io non so se LUKS utilizzi dei meccanismi per permettere un eventuale recupero dei dati o se cancellando i primi MB si perda tutto per sempre, quindi: https://www.kali.org/tutorials/nuke-kali-linux-luks/ Mi pare un metodo valido, se non altro un alternativa assennata al "io speriamo che ho cancellato tutto". Se sai quanto è grande l'header e sovrascrivi solo quello hai già reso il disco irrecuperabile salvo backup dell'header. ovviamente se scrivi un po di piu male non fa, quindi su un disco con una sola partizione luks, scrivere roba pseudorandomica sul primo giga o sui primi 10 giga e già molto piu che sufficiente in quanto davvero il disco perde di significato senza l'header. perchè parlo di singola partizione? perchè cominciando a sovrascrivere dall'inizio del disco, il blocco verrebbe sicuramente sovrascritto, altrimenti c'è da andare a capire dove si trova e mettere l'offset appropriato in fase di cancellazione se la partizione criptata ha l'inizio buttato in giro nel disco tra altre partizioni Grazie per le utili informazioni! Da quel che leggo, se uno vuole poter dismettere un disco senza troppe preoccupazioni per i contenuti, la cosa migliore da fare è mettere una partizione cifrata LUKS il più possibile "vicino al metallo": - Se si usano dischi singoli, meglio fare Metallo -> LUKS -> LVM -> File System - Se si usano dischi in RAID software, meglio fare Metallo -> RAID -> LUKS -> LVM -> File System Al momento di dismettere il disco si possono rendere inaccessibili i dati sovrascrivendo l'header della partizione LUKS (generalmente 2 MB). Poiché quando si usa LUKS per un disco di sistema spesso si usa il primo GB per /boot, per rendere inaccessibili i dati sul disco dovrebbe essere sufficiente sovrascrivere i primi 2-4 GB del disco con dati pseudo random. Per esempio: # dd bs=1k count=2M status=progress if=/dev/urandom of=/dev/sdX && sync Per come funziona LVM, se si annida la partizione LUKS su un volume LVM non c'è modo semplice di sapere in quale area *fisica* del disco si trovi l'header LUKS, e quindi non c'è la certezza di sapere quale area del disco debba essere sovrascritta, e per prudenza uno dovrebbe sovrascrivere tutto (e con dischi di vari TB ci possono volere molte ore). Ovviamente tutto questo supponendo di avere hard disk tradizionali a piatto rotante. Con SSD e SSHD credo che la situazione si faccia più complicata... saluti e grazie ancora, gerlos <>
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno dom 12 ago 2018 alle ore 17:28 Gollum1 ha scritto: > > Il 12 agosto 2018 11:23:47 CEST, Paolo Miotto ha > scritto: > >Devi fare il contrario: aggiungere gli altri repo al tuo clone di > >bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli > >verso il repo definitivo. > > > > vediamo se ho capito. > io ho rifatto il repository vuoto su bitbucket e l'ho clonato in locale, ci > copio dentro quello che credo che sia il più vecchio dei tre che ho a > disposizione, e ne faccio il commit su bitbucket. ci copio dentro il > successivo e faccio il nuovo commit... c'è qualcosa che non mi torna... come si comporterebbe invece il tutto, se io faccio il repository su bitbucket, e me lo porto in locale. vado su uno dei tre repository locali, e lo aggancio come remote al repository locale, e ci paccio un push... a quel punto ho il repository locale con tutti i commit del primo dei repository locali vecchi... faccio così anche per gli altri due, committando di volta in volta, e così facendo dovrebbe fare anche i merge, quando faccio i push da ogni repository vecchio... oppure sto sbagliando ancora la prospettiva? Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
Il 12 agosto 2018 11:23:47 CEST, Paolo Miotto ha scritto: >Il 09/08/2018 20:16, Gollum1 ha scritto: >>> se io ricreo il repository su bitbucket (questa è la mia intenzione >a >>> prescindere), posso entrare in ogni repository, aggiungere bitbucket >>> come remote, e caricarli tutti su di esso? le parti in comune dei >vari >>> commit verrebbero messe insieme, e quindi avrei una sola versione >>> delle varie commit? le parti non commitate inizialmente, posso farle >>> andare su vari branch in modo che poi facendo una analisi dei soli >>> file modificati, riesca a ricostruire il mio branch di sviluppo >>> principale? eventualmente con i merge del caso? >>> >>> è possibile e affidabile un approccio del genere? > >Devi fare il contrario: aggiungere gli altri repo al tuo clone di >bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli >verso il repo definitivo. > >Mandi. > >Paolo vediamo se ho capito. io ho rifatto il repository vuoto su bitbucket e l'ho clonato in locale, ci copio dentro quello che credo che sia il più vecchio dei tre che ho a disposizione, e ne faccio il commit su bitbucket. ci copio dentro il successivo e faccio il nuovo commit... c'è qualcosa che non mi torna... byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: Consigli su volumi criptati su LVM e RAID
On Sun, Aug 12, 2018 at 03:07:04AM +0200, Lorenzo "Palinuro" Faletra wrote: > Se sai quanto è grande l'header e sovrascrivi solo quello hai già reso > il disco irrecuperabile salvo backup dell'header. > ovviamente se scrivi un po di piu male non fa, quindi su un disco con > una sola partizione luks, scrivere roba pseudorandomica sul primo giga > o sui primi 10 giga e già molto piu che sufficiente in quanto davvero il > disco perde di significato senza l'header. > > perchè parlo di singola partizione? perchè cominciando a sovrascrivere > dall'inizio del disco, il blocco verrebbe sicuramente sovrascritto, > altrimenti c'è da andare a capire dove si trova e mettere l'offset > appropriato in fase di cancellazione se la partizione criptata ha > l'inizio buttato in giro nel disco tra altre partizioni > > per i nuke slots di cryptsetup serve ovviamente una versione > appositamente patchata, e attualmente le uniche 2 distro di cui sono a > conoscenza che integrano la patch sono kali [1] e parrot [2] > la patch [3] è uguale per entrambe. > > una nota importante da fare sulla patch è che anche qualora andasse bene > per un uso generico, è quasi inutile in caso lo storage venga sottoposto > ad una corretta procedura forense in quanto dopo l'acquisizione bit per > bit del drive, tutte le prove verrebbero fatte su copie dell'originale, > e qualsiasi dump del blocco chiavi verrebbe ripristinato, motivo per cui > la patch non è stata mai accettata in upstream e viene considerata piu > un giocattolo che una feature. > > un'attenta lettura alla sezione 5.21 della FAQ di cryptsetup [4] è > d'obbligo! Preziosissime informazioni, Grazie Lorenzo :) > [1] http://kali.mirror.garr.it/mirrors/kali/pool/main/c/cryptsetup/ > [2] http://parrot.mirror.garr.it/mirrors/parrot/pool/main/c/cryptsetup/ > [3] > https://dev.parrotsec.org/parrot/cryptsetup/blob/master/debian/patches/cryptsetup_nuke_keys.patch > [4] https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions > > -- > Lorenzo "Palinuro" Faletra > > Parrot Security > > GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4 > > GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4 > GPG Key: http://pgp.mit.edu/pks/lookup?op=get=0x97CAA129F4C6B9A4 -- Felipe Salvador
