Re: [Tails-dev] Persistent Volume Problem
Hi, Yasin Ozel wrote (30 Nov 2013 23:28:35 GMT) : > Hi friends (and sorry for my English), Your English is perfectly fine for me :) > I have got Tails 0.21 on USB stick. I have created a persistent volume > with it. But now, I can't open the persistent volume. I have choosed Yes > for "Use persistence?" and entered the passphrase. After that, I waited > for a while. But nothing happens. > Is this a bug or I make something that wrong? This is the mailing-list for Tails development. For support requests, see https://tails.boum.org/support/. Thanks in advance! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Persistent Volume Problem
Hi friends (and sorry for my English), I have got Tails 0.21 on USB stick. I have created a persistent volume with it. But now, I can't open the persistent volume. I have choosed Yes for "Use persistence?" and entered the passphrase. After that, I waited for a while. But nothing happens. Is this a bug or I make something that wrong? signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
winterfa...@riseup.net wrote (30 Nov 2013 19:00:56 GMT) : > There was a purpose of the code in "import-translations" that was removed > by commit: > e76059cd74bec591d7104b65e3f188e43a36ef7f OK, got it. I'm not excessively convinced by the "if someone commits without running refresh-translations first" part, but OK. Commits b2a3952 and d62bf4c (directly pushed to devel, sorry) should restore the intended behavior back, with a slightly different implementation (factorized functionality from refresh-translations into our shell library). Does this achieve the result you intended? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Kill Your TV wrote (30 Nov 2013 16:48:21 GMT) : > Cheers (and TY), Thank *you*! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Glossary for contributors
Hi, I'm pushing to master ([[contribute/glossary]]) a glossary to contributors, that defines some terms used in a somewhat or 100% special meaning within the Tails community. This is only a beginning, and it needs the input from everyone here who found themselves in front of a work they didn't understand on this list, and it later appeared that this word had special meaning here. Please contribute ideas of words that should be in there — ideally, with definitions attached, but getting a list of words would be awesome already! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Sat, 30 Nov 2013 12:00:29 + (UTC) intrigeri wrote: > Hi, > > Kill Your TV wrote (29 Nov 2013 21:50:31 GMT) : > > Anyhow...I think the issues have been addressed in my branch. > > Merged into devel, imported the i2p source package and the 3 binary > packages it produces. > > Note that I have *not* imported the new service-wrapper from your APT > repository: [..] That's perfectly fine. > > Once service-wrapper migrates to testing, if needed we can upload it > to wheezy-backports and install from there. This is also fine, of course. It may be good to have the new one but probably not essential. I package whatever we're shipping in the upstream I2P bundles for Linux, Windows, OSX, etc. but old versions of the wrapper should "just work". Cheers (and TY), kytv signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
intrigeri wrote: > winterfairy at riseup.net wrote (29 Nov 2013 14:14:46 GMT) : >> Please review and merge: >> - repo "winterfairy/tails", branch "import-translations" (based on >>devel) > > Merged and pushed some refactoring commits on top. There was a purpose of the code in "import-translations" that was removed by commit: e76059cd74bec591d7104b65e3f188e43a36ef7f The purpose was, if one run "import-translations" and then commits (without running "refresh-translations"), there will show up much changes in all po-files, even if no changes really was made. That makes it harder to track how the content in the po-files have changed. Running "intltool-update" is fast, so it being run twice is not a big problem for that reason. And I believe it should be run in "import-translations" too, just to make the logs more clean in those cases someone commit immediately after import. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shutdown stopped working in nightly experimental?
Sorry for the delay, mailing list archives was offline, or whatever... intrigeri wrote: > I can reproduce winterfairy's results on a ThinkPad X201 (both with > the shutdown applet and with the emergency shutdown). FWIW, both this > system and the ThinkPenguin Royal have Intel graphics. I can't > reproduce this issue in libvirt/qemu (qxl graphics). winterfairy, what > graphics driver is used by the system exposing this bug? lspci: 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (using "i915" driver according to lsmod) > I've seen no indication that the kernel has finished loading and run > the initramfs' init. I haven't checked if the memory wipe did happen > or not. I fear we have to treat this as a serious regression. Was hoping it was just my computer... :( Was there important security fixes in the new kernel version, or is it possible to revert the kernel upgrade if the cause is not found promply enough? > [list of TODO items] > > winterfairy, do you think you can take care of any of this in the next > few days (say, before next Tuesday)? I doubt it, will be kind of busy until Thursday. intrigeri wrote: > winterfairy wrote: >> This makes me believe the memory erasing acts badly with this kernel >> version and hardware combination, possibly writing some data somewhere >> it shouldn't had, causing the kernel or hardware to force a reboot. >> And that it worked with previous kernel versions on this hardware >> by pure luck. > > My understanding is that sdmem shouldn't be allowed to write to places > it shouldn't. Changes in the OOM area, perhaps? > >> I want to look deeper into this, but I cannot find where the actual >> memory erasing code is (where sdmem is started?)? Only where the >> kexec bits are. Where is it? > > You want to look at > https://tails.boum.org/contribute/design/memory_erasure/ and > /usr/share/initramfs-tools/scripts/init-premount/sdmem intrigeri wrote: > I'm more and more inclined to think it's a regression in Linux itself. I still believes what I said about overwriting something it shouldn't, and now I also believe it is directly Intel graphic card related. These are still guesses though, I may be wrong. But, previously on my computer, the screen was always scrambled during memory erasure. The exact pattern sometimes varied between Tails releases, but it was just scrambled. Expected, maybe, since the video memory is RAM mapped. But a few releases back, when Tails switched to a much newer Linux kernel, the scrambling stopped, and I instead got blue twinkling stars (pixels actually) during the erasure procedure. Now, how is that possible, unless the video card is put in some absurd state? And now it broke? So, I will look into that sdmem script and see if there is something odd there, for starters. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
On Sat, Nov 30, 2013 at 04:08:35PM +0100, intrigeri wrote: > Hi, > > winterfa...@riseup.net wrote (29 Nov 2013 14:14:46 GMT) : > > Please review and merge: > > - repo "winterfairy/tails", branch "import-translations" (based on > >devel) > > Merged and pushed some refactoring commits on top. bertagaz should be > reviewing my own changes soonish. Works fine, thanks! That sounds good to me, so I think I won't merge it anywhere, since it's already done. :) Thanks winterfairy for your quality contributions! bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing packages from Tails for testing smaller attack surface
Hi, Thomas Benjamin wrote (29 Nov 2013 23:14:42 GMT) : > Is there any particular good procedure for removing packages from > Tails, Not really, sorry. > (and I don't understand why the -f > parameter is not used so that the build will not fail if that package is > not included). It is intentional that the build fails if we're trying to delete something we didn't install in the first place, so that we notice when we have obsolete cruft that we should get rid of. Sorry, this is optimized for maintainability more than for making customization easy. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
Hi, winterfa...@riseup.net wrote (29 Nov 2013 14:14:46 GMT) : > Please review and merge: > - repo "winterfairy/tails", branch "import-translations" (based on >devel) Merged and pushed some refactoring commits on top. bertagaz should be reviewing my own changes soonish. Works fine, thanks! > - repo "winterfairy/greeter", branch "import-translations" (based on master) The ticket is assigned to me, so I should think of reviewing this shortly. Else, feel free to nag me. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shutdown stopped working in nightly experimental?
Hi, intrigeri wrote (29 Nov 2013 13:16:41 GMT) : > I can't > reproduce this issue in libvirt/qemu (qxl graphics). winterfairy, what > graphics driver is used by the system exposing this bug? Can anyone > try and reproduce this on bare metal with non-Intel graphics? These questions would still be worth answering. > I fear we have to treat this as a serious regression. Filed #6460. > From the top of my head, some notes: > 0. Check that the memory wipe actually did not happen. > > https://tails.boum.org/contribute/release_process/test/erase_memory_on_shutdown/ Will be done today or more likely tomorrow. > 1. It could be worth having another look at the initramfs-tools >changes between 0.114 and 0.115. I would start with an ISO built >from experimental, that downgrades this package to 0.114. Tested with current devel + initramfs-tools 0.114, same issue. > 2. It could be worth trying with kexec-tools 2.0.4-1 from sid and with >2.0.3-1 from Wheezy. Tested with current experimental + kexec-tools 2.0.4-1, same issue. > 3. Any changes to the kexec feature in the kernel that break it for >our usecase? I'm more and more inclined to think it's a regression in Linux itself. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] What to do with Firefox 17.0.11ESR?
Hi, On Fri, 29 Nov 2013 12:25:33 +0100 intrigeri wrote: > sajol...@pimienta.org wrote (26 Nov 2013 12:22:53 GMT) : > > Another possibility would be to do the usual RC, and advertise it > > as a better workaround for people concerned about the libnss issue. > > The ISO will be the same, it's just the way we advertise it that > > changes. No? > > Now that the RC is 3 days away from now, and my email [1] to > pkg-mozilla about fixing NSS in squeeze-backports is still unanswered, > I believe the best course of action is indeed to advertise the RC more > strongly than usual (by having the security issue notification > explicitly suggest to use the RC). > Seems the best we can realistically do. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi, Kill Your TV wrote (29 Nov 2013 21:50:31 GMT) : > Anyhow...I think the issues have been addressed in my branch. Merged into devel, imported the i2p source package and the 3 binary packages it produces. Note that I have *not* imported the new service-wrapper from your APT repository: * it's not made it out of unstable yet * there is no indication in the i2p package's dependencies that the version we're currently installing from Wheezy (3.5.3+repack-0+nmu1) isn't good enough for it * the only explanation I've seen for this upgrade is the support of the umask feature, that we are not using eventually ... so I've prioritized stability (less changes) over getting the latest and shiniest stuff. Once service-wrapper migrates to testing, if needed we can upload it to wheezy-backports and install from there. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Gtk issue [Was: Tails Python library]
Hi, On Wed, 27 Nov 2013 15:00:57 +0100 anonym wrote: > Off topic: As you have a great deal more Gtk experience than me, I'd > like you to have a look at the following (originally posted in email > with msg-id <528da114.7000...@riseup.net>) if you happen to have the > time and will at some point: > I don't have time to look yet, but I added the question to my todo list. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] uVirtus design
Hi, Dlshad Othman wrote (17 Oct 2013 16:36:05 GMT) : > It's great point, we'll work on Firefox add-on to show a notification about > that. Well, this looks like a great idea, but perhaps in the meantime it would be good to make it clear on the web homepage that the announced security features are held only after some manual steps are taken? I'm scared about how potential users of uVirtus could believe what's written on the current web homepage and put themselves at risk, and I find it really worrying to see that the uVirtus team is apparently not taking this risk as seriously as they could. Then I'll stop insisting. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
