[Tails-dev] Tor Browser 6.0.5 Released Early
Hi, Late last week ( no later than 17 September) my Tor Browser updated itself (after prompting me) to 6.0.5. Yet, the changelog ( /tor-browser_en-US/Browser/TorBrowser/Docs/ChangeLog.txt ) gives the release date as September 20th (future date). Likewise, a September 12th email sent to the Tails-dev list with the subject, "New release schedule for Tails 2.6", begins, > So Mozilla has decided to delay the upcoming Firefox release until > 2016-09-20, so the upcoming Tor Browser (6.0.5) is delayed as much, and > hence Tails should follow suit. I'm just wondering what accounts for TB 6.0.5 being released at least several days ahead of the date announced (20 Sept.) ___ 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 Mon, Aug 8, 2016, at 03:32 PM, Joanna Rutkowska wrote: > Hello, > > Is there any special reason why the partition where Tails installs itself > is > non-deterministic? It is thanks to differing timestamps on the > filesystem. What you have asked about sounds at least similar to an issue I had reported on this list a while back. I had reported that the checksums (sha256, sha1, md5, etc.) of the Tails partition (on USB, created by dd) no longer matched that of the Tails ISO from which said partition was written. I say "no longer" because there had been a time when these values did match. That changed at some point with one of the releases and the change remained for an extended period, through a number of releases. Then, I believe with the latest release, Tails 2.5, the hashes for the ISO and the partition of the installation written from the ISO (via dd, on USB) once again were the same. The cause of these changes remains a mystery to me. > This posses a problem for a prudent user who would like to be able to > verify > Tails integrity, e.g. by typing: > > dd if=/dev/sda1 | sha1sum How is that different from "sha1sum /dev/sdX*"? Isn't your version just a lengthier and less simple means of achieving the identical end: obtaining the checksum of a given partition (in this case, the sha1 of the partition that Tails installed itself on). Perhaps I am missing something? *X for the specific device value, which will obviously change > This might be especially useful if one uses the stick on various > computers and > would like to verify if her USB stick holding Tails installs hasn't been > modified (e.g. by a malicious BIOS). Or (and this is obviously applicable even when one always uses his Tails device on the same computer) that the Tails partition itself was not altered by a remote attacker (such as while one was online using Tails) or even a local attacker (such as while one's Tails stick was left unattended-- even if within a secured space, unless one can somehow be sure that no one unauthorized entered said space). Now, of course, this means of verification is still possible even when the hash of the (verified) ISO does /not/ match that of the partition created from same ISO-- providing that one made sure to record the hash of the Tails partition right after creating it (before using it for the first time and before leaving the device it is contained-on unattended). But when the checksums of the Tails partition match those of the ISO that said partition was created from, then one has the additional advantage of knowing that the actual writing/installation itself was completed without error or corruption. >Yes, I'm aware that the first sector > of the > disk (/dev/sda) would still differ thanks to different partition sizes. Right, meaning that an attacker in whatever form (including a compromised BIOS or other hardware component) could leave the Tails partition itself untouched, yet alter another section of the device. What I therefore do, in addition to recording the checksum of the Tails partition that I created from the ISO (/dev/sdX), is to /also/ record the checksum of the /entire device/ (USB stick). In this way, I can presumably be reasonably certain that my stick has not been tampered with by verifying, at any given time (such as after using it or after leaving it unattended) that the checksum for the full-device (/dev/sdX) still matches the one I recorded just after installing Tails on it. /Persistence/, of course, presents an exception to this; obviously, one cannot expect the checksum for the persistence partition not to change with each and every change, no matter how small and insignificant, that the user makes to said partition. Having noted that, however, I must /also/ mention an experience I recall with a USB stick that I had created, with a persistence partition, using Tails Installer. If I recall correctly, I had found that after each use of this USB stick to boot and run Tails, the hash for the persistence partition would change-- /even when I had NOT enabled persistence (or otherwise consciously accessed the persistence partition) for that session. Although I do not know the reason for this behavior, I suspect that it somehow may be very much related to the topic that Ms. Rutkowska created this thread about. ___ 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.
[Tails-dev] Changelog: "Unstable" Huh?!
https://git-tails.immerda.ch/tails/plain/debian/changelog lists each Tails release as "unstable". Why? These are the final releases; not betas or release candidates. ___ 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] Check out Mim's photos on Facebook.
Who is "Mim" and why should anyone on the tails-dev list be interested in seeing her or his photos? On Thu, Jul 14, 2016, at 11:54 AM, Facebook wrote: > Check out Mim's photos on Facebook. > > If you sign up for Facebook, you'll be able to stay connected with > friends by seeing their photos and videos, staying up to date with their > latest status updates, exchanging messages and more. > > Join Mim on Facebook > https://www.facebook.com/p.php?i=100012904231671=AQD76JUlDi7CBhzrfeuKijDlGVTrH1SWsuW1KLWkGLMvPA-tWbGfACChF-7YilFbqv9KlQeKOgRYz9I3rJarCR_N3mg_id=350685531728 > > Already have an account? Add this email address to your account: > https://www.facebook.com/merge_accounts.php?e=tails-dev%40boum.org=AQD7TttwYB86mp1WQX7iKRrjMQxxK0jaC5MtkkqfshuAtg=unknown > > === > This message was sent to tails-dev@boum.org. If you don't want to receive > these emails from Facebook in the future or have your email address used > for friend suggestions, please follow the link below to unsubscribe. > https://www.facebook.com/o.php?k=AS0US_U3-64RrpU4=tails-dev%40boum.org=HMjMzOTQzNzYzOnRhaWxzLWRldkBib3VtLm9yZzo4 > Facebook, Inc., Attention: Community Support, Menlo Park, CA 94025 > > ___ > 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. ___ 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] Elvis, Cantado & Contado
> produção: > > Clique neste link para ser removido: > > http://the-best-of-all.com.br/unsubscribe.php?M=5545118=8995c6e6bc80001b0b0be6e701c6216a=57=478 > > Done that. I thought one is never supposed to reply at all to spam, even to click on a "remove" link, as such links are likely nothing more than a trap, set-out by the spammer, in order to confirm that they reached a live address. ___ 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] gnu.org in "neutral" pool for htpdate
On Tue, May 3, 2016, at 09:45 AM, intrigeri wrote: (in reply to Random User's questions) > I have no clue what's the logging policy of the webserver behind > www.gnu.org. One would need to research that before we can move it to > the "pal" pool. > First, let's not put too much weight behind these "neutral" and "pals" > names. Regarding Startpage and DuckDuckGo: we have no means to verify > their claims, nor personal ties that allow us to trust them by > default. This does *not* mean that we have means to state they are not > trustworthy, or something. It's just that we can't tell. Sounds quite reasonable. Thank you for explaining. ___ 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.
[Tails-dev] gnu.org in "neutral" pool for htpdate
Hi, At https://tails.boum.org/contribute/design/Time_syncing/ , you characterize the web servers that are included in the"pal" pool as, "run by groups that are likely to take great care of their visitors' privacy." I would have surely thought that description would apply to a site such as, "www.gnu.org", from all that I know about the organization behind it (particularly the renowned Richard M. Stallman, who, whatever else one may think of him, would appear to be one of the most outspoken and uncompromising advocates of online privacy). I was therefore rather surprised to see "www.gnu.org" was not listed in the "pal" pool but in the "neutral" pool at https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/etc/default/htpdate.pools I wonder if you could explain your rationale for this. I hope you will not think that I am looking for a fight, as I am honestly just curious and sincerely interested in hearing what you have to say. Thank you. P.S. I am also somewhat curious about the categorization of startpage and duckduckgo, as well, as only "neutral" and not "pals". Wasn't at least one of those two acknowledged for their dedication to user privacy by a third-party that is widely considered credible? ___ 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] memory wipe at shutdown # of wipes
Hopefully one of the devs will answer your question. I'm just curious... > i want to increase the # of wipe$ to tail$ $hutdown. > im not interested in discu$$ing why i want to do thi$ [snip] Is your 's' key broken? Why the '$'s? > i love you Was that meant as an expression of appreciation of the dev team for Tails? ___ 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.
