[Tails-dev] A humble suggestion ...
To the Tails Team: I'm sincerely grateful for what you've accomplished, in a relatively short period of time to ensure privacy for the "Joe Citizen". I was wondering if you've thought about getting Tails out to the general public ala "Chrome Cast"? A hardware dongle with a keyboard or remote? Of course, there are plenty of competitors (Roku, etc.), but there's nothing out there touting/leveraging/with reputation like your platform on a Home Entertainment platform (HTPC). With USB/HDMI integration in most of the new TVs, this seems like a logical step - and the next frontier. Indeed, the objective wouldn't be to stream HD material via Tor/Tails (who knows - maybe a remuneration model to the Tor node providers - if Tor/they so choose), but rather an interface where a non/semi-techincal person could browse the Internet with much needed anonymity (whilst enjoying their Netflix at full speed). Of course, a hybrid solution - where Tails could be the privacy provider of all transactions, and the "media" provider (e.g., Hulu, Netflix, etc.) could simply take care of the delivery/profits? Something to ponder. Let me know your thoughts, as I'd be interested in supporting this hardware/software solution for the masses (monetarily, that is). Thank you. ___ 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] feature/torbrowser-24.5.0esr-1+tails1
anonym wrote (09 May 2014 16:09:40 GMT) : >> If these changes are now good enough for Tails 1.1, all right, I'm >> happy, but then you'll want to update #7127 :) > Perhaps we can just forget about that ticket and close it as the TBB > people apparently thought it ok to ship those changes in the now stable > 3.6.1? I don't see any reason to treat it much differently than any > other of their commit any more. Fine with me, if the user feedback for TBB 3.6.x has not exposed serious issues on this front. I've seen at least one ticket in passing that did not look good. Maybe ask the TBB and Tor QA people? 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 To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge:1.1] #6559, #7062, #6275: test/6559-adapt-test-suite-for-Wheezy
anonym wrote (09 May 2014 15:31:06 GMT) : > Could you please elaborate on all this just so we don't misunderstand > each other, possibly by attaching screenshots of both cases to the ticket? I'll do that later, as we really should fix this properly at some point. But for now, being able to merge this branch seems higher-priority. >> presumably since the move to QXL. > For the record, I get the exact same results with QXL and cirrus (I took > screenshots and compared them to be really sure). > Could you test if the temporary change > sed -i 's/qxl/cirrus/' features/domains/default.xml > fixes the issue (or, equivalently, reverting 353fcde)? This fixes the issue for me. >> Needless to say, it prevents from running 99% of the test suite >> without fixing it myself => reassigning to anonym. > By the way, are you also affected by #7171 (Test suite fails to start > Xorg with cirrus graphics device on x86_64 arch)? I am (at least on this branch - 353fcde). > Even if you are, you could use the cirrus + workaround from #7171 > to be able to run the full test suite and at least test the other things > in the branch, which may be more convenient for you depending on you > availability. For that, just apply the attached patch. Can't do that: Call to virDomainCreateWithFlags failed: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: aes (Libvirt::Error) I think it raises the bar way to high in terms of hardware needed to run the test suite. I also tried: * Westmere: my CPU isn't good enough * Nehalem: fails to start X * fails to start X * kvm64: seems to work, but likely suboptimal => I've started the full test suite run with kvm64, and will report back later. Was the "fails to start X with libvirt from wheezy-backports" bug reported upstream? If you do report the bug, I'll try to reproduce it on current sid. Piling up workarounds is fun, but if this could be fixed properly where it should, we would be very happy in the end :) 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 To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge] feature/torbrowser-24.5.0esr-1+tails1
09/05/14 17:49, intrigeri wrote:
> Hi,
>
> anonym wrote (09 May 2014 15:02:02 GMT) :
>> Please review and merge (both Git and APT suite wise) into devel.
>
> I'll do this by the end of the week, once I get the clarification I'm
> asking below. Please file a ticket to ensure it's not forgotten.
>
> Before I start diving into it, I would not mind some clarification,
> since: on the one hand, #7127 ("Evaluate Tor Browser's new JavaScript
> security enhancements"), that you have created, says we should
> evaluate the JS-related profile changes; and OTOH, the proposed branch
> imports these changes, without any update on #7127.
>
> If these changes are now good enough for Tails 1.1, all right, I'm
> happy, but then you'll want to update #7127 :)
Perhaps we can just forget about that ticket and close it as the TBB
people apparently thought it ok to ship those changes in the now stable
3.6.1? I don't see any reason to treat it much differently than any
other of their commit any more.
I may have overreacted about this change and opening the ticket --
originally the commit message (now rewritten) gave the impression that
it could be quite problematic, but, well, I have little insight and just
took it at face value.
>> I'ts already been merged into experimental.
>
> I cannot confirm this.
Oh, my push failed due to your work on #7065. Now pushed.
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] [review'n'merge] feature/torbrowser-24.5.0esr-1+tails1
Hi,
anonym wrote (09 May 2014 15:02:02 GMT) :
> Please review and merge (both Git and APT suite wise) into devel.
I'll do this by the end of the week, once I get the clarification I'm
asking below. Please file a ticket to ensure it's not forgotten.
Before I start diving into it, I would not mind some clarification,
since: on the one hand, #7127 ("Evaluate Tor Browser's new JavaScript
security enhancements"), that you have created, says we should
evaluate the JS-related profile changes; and OTOH, the proposed branch
imports these changes, without any update on #7127.
If these changes are now good enough for Tails 1.1, all right, I'm
happy, but then you'll want to update #7127 :)
> I'ts already been merged into experimental.
I cannot confirm this.
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] Note [was: Re: Tails contributors meeting: Thursday May 8]
sajol...@pimienta.org wrote (09 May 2014 09:26:18 GMT) : > Here are the notes: Thanks! I've published it on the website (the overhead of asking if frontdesk or you was going to do it seemed not worth it). ___ 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] [review'n'merge:1.1] bugfix/7065-keyboard-localization
Hi, bugfix/7065-keyboard-localization fixes issue #7065 for me. Assigned to the RM (anonym) for review. The solution I've found to this problem is partly implemented in the greeter, and partly in the main Git repo, so it'll require two Git merges + an APT merge (or, ideally, a new tails-greeter release uploaded to the devel suite). I have successfully tested an ISO built from this branch with the French, French (alternative), Italian, English and Chinese keyboard layouts. 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 To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge:1.1] #6559, #7062, #6275: test/6559-adapt-test-suite-for-Wheezy
09/05/14 13:49, intrigeri wrote: > Hi, > > anonym wrote (08 May 2014 15:52:25 GMT) : >> Tickets: https://labs.riseup.net/code/issues/6559 >> https://labs.riseup.net/code/issues/7062 >> https://labs.riseup.net/code/issues/6275 >> Branch: test/6559-adapt-test-suite-for-Wheezy > > The "the computer boots Tails" step fails for me: it does not detect > TailsBootSplash.png. It seems that the syslinux menu is quite smaller > than before (in --view mode, it takes about 2 thirds of the screen), Interesting. For as long as I can remember I've got the initial boot screen to only cover ~2/3 of the full 1024x768 for fresh boots -- fullscreen is used first when Xorg starts. Only after a reboot (e.g. in memory_erasure.feature) does the boot splash cover all 1024x768 of the screen, and I thought this was the reason for TailsBootSplash.png vs TailsBootSplashPostReset.png. Could you please elaborate on all this just so we don't misunderstand each other, possibly by attaching screenshots of both cases to the ticket? > presumably since the move to QXL. For the record, I get the exact same results with QXL and cirrus (I took screenshots and compared them to be really sure). Could you test if the temporary change sed -i 's/qxl/cirrus/' features/domains/default.xml fixes the issue (or, equivalently, reverting 353fcde)? > Needless to say, it prevents from running 99% of the test suite > without fixing it myself => reassigning to anonym. By the way, are you also affected by #7171 (Test suite fails to start Xorg with cirrus graphics device on x86_64 arch)? Even if you are, you could use the cirrus + workaround from #7171 to be able to run the full test suite and at least test the other things in the branch, which may be more convenient for you depending on you availability. For that, just apply the attached patch. Cheers! diff --git a/features/domains/default.xml b/features/domains/default.xml index f65bbf5..95de247 100644 --- a/features/domains/default.xml +++ b/features/domains/default.xml @@ -12,6 +12,10 @@ + +SandyBridge +Intel + destroy restart @@ -53,7 +57,7 @@ - + ___ 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] [review'n'merge] feature/torbrowser-24.5.0esr-1+tails1
Hi, Branch:feature/torbrowser-24.5.0esr-1+tails1 APT suite: feature-torbrowser-24.5.0esr-1-tails1 Ticket:No Please review and merge (both Git and APT suite wise) into devel. I'ts already been merged into experimental. I've run features/torified_browsing.feature in the automated test suite successfully (from branch test/6559-adapt-test-suite-for-Wheezy) for an image built from the branch. 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] #6400: upstreaming our rjb support [Was: Please review'n'merge test/rjb-migration]
20/03/14 13:50, intrigeri wrote: > Hi, > > berta...@ptitcanardnoir.org wrote (29 Dec 2013 17:44:57 GMT) : >> On Fri, Dec 27, 2013 at 07:36:15PM +0100, intrigeri wrote: >>> The parent ticket (#5731) is still blocked by #6400, as nobody >>> commited to either upstream our stuff into the ruby-sikuli Gem, or to >>> maintain our own adapter on the long term. I'm unsure what conclusion >>> we should draw of it. Admitedly, the new setup is way less scary than >>> the previous one, and our adapter is 85 lines long, but still, I'm >>> concerned we might happily be replacing it with another kind of >>> technical debt. > > AFAICT, nothing has happened on this front since then. > >> I've had a quick look at a way to implement that upstream. Using the >> RUBY_ENGINE variable, it seems easy to have the gem selecting the right >> handler depending on which interpreter is used. > >> Still there are some subtilities in our code that I'm not sure to >> understand, this is quite low level, and I'm not sure to be able to handle >> this upstreaming myself alone. > > In the meantime, the sikuli_ruby Gem [1] has been abandonned, and our > current best option for upstreaming seems to be Rukuli [2], that seems > quite alive (10 contributors, a few commits every month). > > [1] https://github.com/chaslemley/sikuli_ruby > [2] https://github.com/andreanastacio/Rukuli > > anonym, bertagaz: want to have a(nother) look, and decide if you > prefer to do the upstreaming work now, or to commit to maintain our > own sikuli/rjb adapter on the long run? I have looked several times at what would be necessary for upstreaming this, and changed my mind about what to do equally many times. It definitely would be some work. We'd need to add a wrapper that either uses RJB or JRuby constructs depending on what's available. While that wouldn't be too hard in principle, it seems RJB handles exceptions in a way that will be complicated to get to a similar state as in JRuby, which is what sikuli-ruby/Rukuli expects. Add to this that I'm neither a Ruby nor (J)Ruby Guru, and all this stuff is pretty low-level and intricate. I think that even RJB may need to adapted a bit, for the exception issue. Furthermore the sikuli-ruby API (inherited to Rukuli) isn't a particularly good fit for us, and has some design issues: * It doesn't expose some functionality we need. When we used it (and JRuby) we had to monkeypatch it from the get go -- it still feels like it's very incomplete, a beta or whatever. * It has completely screwed up by mixing Key:s with KeyModifier:s, which effectively makes it impossible to use the KeyModifiers in combination with a Key, e.g. "Ctrl+C" or whatever. * Other stuff I cannot remember. Add to this that we do not know for how long Rukuli will stay maintained. Lastly I'm personally quite happy with using the proxied Java objects exposed by RJB directly as it allows me to consult Sikuli rather extensive docs, and use any tricks I find used in the (Java-oriented) Sikuli community. Because of all this I've finally concluded that I would prefer to keep on maintaining our "sikuli/rjb adapter" for the time being, and possibly return to this upstreaming process if Rukuli shows promise to at least stay maintained for the foreseeable future. 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.
[Tails-dev] Fwd: Re: Secure android headset integration
Original Message Subject: Re: [Tails-dev] Secure android headset integration Date: Thu, 08 May 2014 19:45:37 +0300 From: Chamelephon To: intrigeri On Thu, 08 May 2014 17:22:31 +0200, intrigeri wrote: > Hi, > > Chamelephon wrote (06 May 2014 13:52:33 GMT) : >> We are releasing soon our version 1 retail product and the idea >> occured to me have it shipped by default with a separate tails >> installation on the internal storage or an external sd-card. I did my >> testing and it works nicely, so a user can boot into it by just >> connecting >> the phone via USB cable and selecting it from the boot options. > > Do you mean booting Tails on the phone itself, or using the phone as > a USB mass storage device for booting Tails on another computer? > Booting from the USB Mass storage off the phone. >> I am writing in the mailing list just because i couldn't find contacts >> for >> a led maintainer here. > > There is not such thing as a lead Tails maintainer, and this is the > right place to talk to us :) So glad to receive an answer then :) > >> My idea is to ask the customers whether they would >> like tails installed on their device by default and pay an extra fee to >> cover SD card costs and donate the rest straight to you guys. > > Good news, we will soon accept donations in fiat currencies (while we > currently only accept Bitcoin). Well, good news indeed. We can convert to bitcoin once some amount has been collected though :) > >> The other thing that hit me in the face is to have a PXE boot app written >> for android that lets the users boot from the nework or tethering network >> and boot tails from there without burning dvds or using usb storage. > > I don't know PXE much, and am unsure if the way it handles network > connections can be secured in a way that satisfies Tails design goals > and threat models. But if you research this any further, I would > personally be curious to read about your results :) I didn't have time the last days for this, but isn't the boot media supposed to be irrelevant with TAILS? I mean no matter what the boot method is, it still loads a ramdisk from the supposed media. If we are talking about persistent storage, that's another story. But i'm looking forward more to a "livecd" amnesiac experience. What is the odd-ball in this quest is actually implementing the PXE server on a non-rooted device, thus making it more installable. > > Cheers, -- The affordable secure handset ___ 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:1.1] #6559, #7062, #6275: test/6559-adapt-test-suite-for-Wheezy
Hi, anonym wrote (08 May 2014 15:52:25 GMT) : > Tickets: https://labs.riseup.net/code/issues/6559 > https://labs.riseup.net/code/issues/7062 > https://labs.riseup.net/code/issues/6275 > Branch: test/6559-adapt-test-suite-for-Wheezy The "the computer boots Tails" step fails for me: it does not detect TailsBootSplash.png. It seems that the syslinux menu is quite smaller than before (in --view mode, it takes about 2 thirds of the screen), presumably since the move to QXL. Needless to say, it prevents from running 99% of the test suite without fixing it myself => reassigning to anonym. 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 To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] status of the experimental branch
01/05/14 12:20, intrigeri wrote: > hi, > > anonym: our experimental APT suite has e.g. an oldish tails-perl5lib > compared to the devel and stable ones. I suspect something went wrong > with this part of the release process. Woah, I had completely missed this email. I've now (AFAICT) fixed the state of experimental's APT suite. 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.
[Tails-dev] Release schedule for Tails 1.1
Hi, I'll be release manager for the Tails 1.1 release. Here's the preliminary release schedule: 2014-05-28 Feature freeze. Tag 1.1-rc1 in Git. Build and upload 1.1-rc1 ISO/IUKs. 2014-05-29 Test 1.1-rc1. 2014-05-30 Officially release 1.1-rc1. 2014-06-08 Firefox 24.6.0 ESR sources are available. Package and upload Firefox 24.6.0 ESR. Tag 1.1 in Git. Start building and uploading 1.1 ISO/IUKs... 2014-06-09 Finish building by 12:00 (CEST) Start testing Tails 1.1 at 12:00 (CEST)... 2014-06-10 ... and finish it by 12:00 (CEST) on the 10th. Officially release Tails 1.1. The dates in June are pretty much set in stone as far as I'm concerned, but the freeze and RC dates may be moved a couple days (so this time the release schedule is indeed very "preliminary") since I have other commitments that may collide. More precisely, the May dates may be moved back (i.e. closer to us) up to three days. Tails developers and contributors, are you available for testing the respective releases on: * RC testing on 2014-05-29 (preliminary) * Final testing on 2014-06-09 afternoon and early 2014-06-09, CEST 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.
[Tails-dev] Note [was: Re: Tails contributors meeting: Thursday May 8]
sajol...@pimienta.org: > Sorry for the short notice, but the next public Tails developers meeting > is scheduled for > > Thursday May 8, on #tails-dev (OFTC) 8pm UTC (10pm CEST) > > Every one interested in contributing to Tails is welcome. > > Feel free to propose and prepare discussion topics. Please raise them in > this thread so that others can ask details and prepare the discussion too. > > If you want to get involved but don't know how yet, please consider > coming and say hello during the meeting: this work meeting probably > won't be the most adequate time and place to properly introduce > newcomers to the development process, but at least it should be a fine > place to tell us you're interested, and possibly to schedule a better > suited event. Here are the notes: #7146: Add a more prominent "Donate" button? - Rationale: make our income sources more diverse, and hopefully more steady — even if smaller — that one-shot grants that are usually paid late. - Adding that to the sidebar to have it appear on all pages. - Adding a "Consider donating or contributing" step to the download page, after step 5, Installation to not break the flow of the download page, and to suggest people can donate if they used it and liked it. - In the future, think about ways of targeting "satisfied return customers" for crowd-funding. That's https://labs.riseup.net/code/issues/7176. - The FPF extended their crowd-funding campaign 3 weeks extra: https://pressfreedomfoundation.org/. We could tell our users about it again. - Create the Donate button of #7146 and point to the campaign. We can disable that button once the campaign is over. - Tweet about it. - Write a new blog post about it. #6992: Put it more clearly that most bug reports without an email address are useless? = The paragraph in the documentation should be improved to say something like: "Giving us an email address allows us to contact you in order to clarify the problem. This is needed for the vast majority of the reports we receive as most reports without any contact information are useless. On the other hand it also provides an opportunity for eavesdroppers, like your email or Internet provider, to confirm that you are using Tails." The same sentence should be used in WhisperBack. In the course of this discussion another proposal arose to remove the right pane of WhisperBack: https://labs.riseup.net/code/issues/7180 #7078: Make it clear in MAC spoofing documentation that only the non-vendor bits are randomized? - The MAC spoofing user doc page is already *extremely* long and difficult. Adding more information about something as technical won't help, and it's probably enough to have it in the design doc. - We already have a FAQ about MAC, but let's keep the FAQ for, well, questions that are asked frequently. - So, let's do nothing for the moment and add a link to the design doc if we feel the need for that again in the future. #7139: Rework /doc/about/anonymity/ === - This page it off-topic given the current scope of Tails documentation. - We usually say that our doc is not the place for general security training, etc. It is not yet another online security guide. - So, let' remove it. #7165: NetworkManager autoconnects to persistent wireless networks in Wheezy = - A proposal was to do nothing, and remove the 3 lines about that from the Known issues. - But that makes it harder to work totally offline. - MAC spoofing does nothing for the edge case where the persistent wireless network has WPA Enterprise with unique user credentials - To work offline people can disconnect before starting any application, so the attack surface is "only" the kernel + whatever runs by default. We can probably live with that. - We decided that was not a blocker for 1.1. - The question remains open whether this would be a desirable behaviour to have back in Tails. - We could have a look at the NetworkManager parameter to not autoconnect and see if it can be made "off" by default. How do we work on the website restructuring, modernizing, and more? === - Having a meeting about that would make the dynamics easier. - Interested or interesting people could be: u and esperal, who already worked on some improvement on the website, tchou, who already expressed interest, BitingBird, as someone doing user support, and knowing what many people have a hard time finding on the website, and sajolida. - But right now the core team is pretty busy working on 1.1, so the proposal was to wait until the summit in July to meet face-to-face. - Still, it would be cool to prepare the ground before
[Tails-dev] Tails report for April, 2014
Releases Tails 1.0 was released on April 29. Metrics === - Tails has been started more than 292 595 times in April. This make 9 753 boots a day in average. - 35 029 downloads of the OpenPGP signature of Tails ISO. - 105 reports were received through WhisperBack. Code * Quite some work was put into adapting Tails to Debian 7 (Wheezy). The result will be released on June 10, as Tails 1.1. - Thanks to the amazing work done in Debian by Ulrike, we are almost there when it comes to adding back support for OpenPGP signature verification in Nautilus (#6608). https://git-tails.immerda.ch/tails/log/?h=feature/6608-OpenPGP-signature-verification-in-Nautilus https://labs.riseup.net/code/issues/6608 - The Vagrant setup was fixed to allow building Tails/Wheezy images in RAM (#7132). https://git-tails.immerda.ch/tails/log/?h=bugfix/vagrant-ram-bump-for-wheezy https://labs.riseup.net/code/issues/7132 - Synaptic was made to start again on Wheezy (#7055). https://git-tails.immerda.ch/tails/log/?h=bugfix/7055-drop-default-APT-release https://labs.riseup.net/code/issues/7055 - The Debian Mozilla team's repository used on the devel branch was updated for Wheezy (#7063). https://git-tails.immerda.ch/tails/log/?h=bugfix/use-Wheezy-repo-for-debian-mozilla - The latest version of the MAT is now installed (#5792). https://git-tails.immerda.ch/tails/log/?h=feature/mat-0.5.2 https://labs.riseup.net/code/issues/5792 - Initial progress was made to update the Windows camouflage. https://git-tails.immerda.ch/tails/log/?h=feature/6342-update-camouflage-for-gnome3 https://labs.riseup.net/code/issues/6342 * The APT suite being used when building from the stable branch was corrected. (#7022). https://git-tails.immerda.ch/tails/log/?h=bugfix/7022-use-stable-APT-suite-when-building-from-stable-branch https://labs.riseup.net/code/issues/7022 * The new logo was integrated in the *About Tails* dialog (#7096). https://git-tails.immerda.ch/tails/log/?h=feature/7096-integrate-the-new-logo-in-about-tails https://labs.riseup.net/code/issues/7096 * Some Vagrant compatibility issues were fixed (#7134). https://git-tails.immerda.ch/tails/log/?h=bugfix/fix-vagrant-compatibility-issues https://labs.riseup.net/code/issues/7134 * The blacklisting of directory authority keys that have been used with versions of OpenSSL affected by Heartbleed was backported into our Tor packages. https://git-tails.immerda.ch/tails/log/?h=feature/tor-0.2.4.21-1+tails1_d70.wheezy+1 * Our modified Tor Launcher was updated to avoid pretending that we ship a default set of bridges. https://git-tails.immerda.ch/tails/log/?h=feature/tor-launcher-0.2.5.3 https://labs.riseup.net/code/issues/6934 * I2P was explicitly told that it cannot receive inbound connections (#7070). https://git-tails.immerda.ch/tails/log/?h=bugfix/i2p_incoming https://labs.riseup.net/code/issues/7070 * An attempt at migrating our source tree to live-build 3.x was made (#5691). It is still entirely unclear whether the cost/benefit ratio is worth it, especially because live-build 4.x has already gone quite further in terms of incompatibilities, and is far from being ready for prime-time yet. https://git-tails.immerda.ch/tails/log/?h=feature/live-build-3.x https://labs.riseup.net/code/issues/5691 * A patch to make the Greeter's help window resolution-aware was proposed (#7009). https://mailman.boum.org/pipermail/tails-dev/2014-April/005451.html https://labs.riseup.net/code/issues/7009 * Another proposed patch aims at fixing the Tails Installer fonts size on Wheezy (#5673). https://labs.riseup.net/code/issues/5673 Documentation and website = * The FAQ was published. https://tails.boum.org/support/faq/index.en.html * The logo that won the contest was integrated in the website, and on the boot loader's splash screen (#7090). https://tails.boum.org/promote/logo/ https://tails.boum.org/news/and_the_winner_is/index.en.html https://git-tails.immerda.ch/tails/log/?h=feature/logo https://labs.riseup.net/code/issues/7090 * Some initial steps were walked to modernize our website's markup and CSS, including moving to HTML5 and better responsiveness (#7021). Compatibility with older browsers is left to be tested before we can apply these changes to the live website. https://git-tails.immerda.ch/451f/tails/log/?h=websitemodernization https://labs.riseup.net/code/issues/7021 * Many documentation pages were deeply reworked as part of #5977: doc/why_tor, doc/vidalia, doc/unsafe_browser, doc/network-manager, doc/introduction. https://labs.riseup.net/code/issues/5977 https://git-tails.immerda.ch/tails/log/?h=doc/why_tor https://git-tails.immerda.ch/tails/log/?h=doc/vidalia https://git-tails.immerda.ch/tails/log/?h=doc/unsafe_browser https://git-tails.immerda.ch/tails/log/?h=doc/network-manager https://git-tails.immerda.ch/tails/log/?h=doc/introduction * The homepage now makes it
Re: [Tails-dev] [review'n'merge] #7166: bugfix/7166-vagrant-memory-checks
Kill Your TV wrote (08 May 2014 21:34:49 GMT) : > I updated the ticket with pretty much the same text as here. Great. Do you want to take care of the code review too? (I don't mind merging it eventually, but given my Vagrant-fu is pretty low, likely you would be better than me at reviewing this branch.) 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 To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
