[Tails-dev] Rete TOR non connessa
Salve, ho scaricato e avviato TAILS, ma quando provo a cercare qualcosa su TOR mi dice che è impossibile raggiungere il sito, anche se ho impostato la connessione che ho casa. Potreste aiutarmi a trovare una soluzione, grazie in anticipo. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge] Remove useless alt in documentation
sajolida: > Right, xin and u are right on this one. The alt attribute is mandatory > but can be empty. I also learned a lot from this article (now in > /contribute/how/website): > http://webaim.org/techniques/alttext/ Thanks a lot to u, xin and sajolida for spending time educating me (and possibly others) on this one. So I'm glad I've asked and did not merge the branch blindly ;) Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [help needed] explaining the way we use Redmine fields
intrigeri: > hi, > Woo! \o/ > > Sorry for the delay… > Well... I took my time too! So, I agree with most of what you suggested, and made changes based on your input. Some doubts/questions below: >> and would benefit for some more insight on > > Regarding "Debian": the current description makes it sound anything > that has to be done upstream should have Type of work = Debian, which > is not the case. Some work has to be done upstream _elsewhere_, and > then we generally use Communicate (e.g. when the action is to report > a bug upstream), or Code (e.g. when the action is to do the needed > tech work upstream), or Wait (when we're waiting for upstream to do > it themselves). > > > * Dev Needed: "Choose this when you think a developer will have enough > information to start working on this ticket" ← I'm not aware of such > usage; do we really use it this way? How would you define it? > > * Generally: in a few places it's written "code", while the text is > valid for any kind of contribution that lives in Git; I would love > to see the language be a bit more inclusive wrt. these other kinds > of contributions. If you don't feel like working on this yourself, > I'll be happy to give it a try once you see the branch as ready > for QA. > I understand your reasoning, but I didn't acted much upon that... please change what you find misleading.. > * "If you create a ticket you become automatically > a watcher" ← really? > Yes signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why Tails partition is non-deterministic?
Joanna Rutkowska: > On Sat, Aug 27, 2016 at 06:54:10PM +, segfault wrote: > The added value would be ensuring the unused portion of the disk blocks > (occupied by the Tails partition) are not populated with some random garbage, > which might be e.g. user's previous (unencrypted) content, such as... family > pictures ;) Ok, but data leakage and verification are different problems IMO. In the tails-verifier I did not try to prevent data leakage or the other possibility of using unverified parts as a hidden channel (which could be used by malware), but only focus on modifications which could alter the behavior of Tails (i.e. changes in boot code or files). I think preventing data leakage and hidden channels is also desirable, but because of the behavior of flash drives you mentioned, I think it is hard to guarantee this. > Generally, I think the Tails installer should at least ask the user to wipe > the > disk with 'dd if=/dev/zero'. Admittedly, because of wear leveling mechanisms > this might not be effective, because AFAIU modern flash memories would include > (X*size) of the actual physical storage in order to expose (size) bytes of > storage to the host, where X > 1. Right, so `dd if=/dev/zero` would not always protect from data leakage. So I tend to disagree that we should do this in Tails Installer, because it would make the installation process slower and might give a wrong feeling of security. > But perhaps if the wiping were repeated N times, where N = ceiling (X), with > random content this time (in order to fool any optimizations by the device), > then it should be fine? Would this guarantee that every byte was overwritten? Wouldn't it be possible that the same (size) bytes get overwritten multiple times but the (X-1)*size other bytes stay the same? Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Why Tails partition is non-deterministic?
On Sat, Aug 27, 2016 at 06:54:10PM +, segfault wrote: > Hi, > > somehow I missed this thread, just noticed it right now. > > intrigeri: > > Hi, > > > > thanks Joanna for raising this topic! > > > > I've just thought about it a little bit and I see no technical reason > > that prevents us from resetting all timestamps in the filesystem to > > some fixed value that depends only (if at all) on the version of Tails > > being installed/upgraded, during some late stage of the > > installation process. > > I think you're right. I did not test if the modification date is indeed > the only thing that differs, but I think Joanna is right, I don't see > anything else that should differ. This would also make tails-verifier > less complex, because we wouldn't have to look at each file but can > check the whole partition at once, like Joanna suggested (although the > file verification is not the complex part). > The added value would be ensuring the unused portion of the disk blocks (occupied by the Tails partition) are not populated with some random garbage, which might be e.g. user's previous (unencrypted) content, such as... family pictures ;) Generally, I think the Tails installer should at least ask the user to wipe the disk with 'dd if=/dev/zero'. Admittedly, because of wear leveling mechanisms this might not be effective, because AFAIU modern flash memories would include (X*size) of the actual physical storage in order to expose (size) bytes of storage to the host, where X > 1. But perhaps if the wiping were repeated N times, where N = ceiling (X), with random content this time (in order to fool any optimizations by the device), then it should be fine? Cheers, joanna. signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
