Re: [T(A)ILS-dev] BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
Hi,
This thread on or-talk made me discover a way that might be interesting to
implement to actually wipe encrypted disks key material.
When you luksClose a disk/volume, it's key material is forgotten by the
kernel, but still in memory (if I understood how it works). But it seems
that in the kernel the code to wipe a key material is already there, and
used by cryptsetup with the luksSuspend command (used whe suspending a
machine).
I'm no kexec expert, what I understood was loading a kernel this way
overwrite the previous kernel ram space, but I'm actually not sure (well,
I doubt) that a remainig unused key material would be overwritten. That
would require some tests I guess, or explanation of the kexec process
which I'm not sure to understand completely.
Still, if the kexec method don't help in wiping key material, I suppose
writing a very simple wrapper to cryptsetup that use luksSuspend then
luskClose when cryptsetup is called to luksClose an encrypted disk might
be an excellent way to wipe remaining key materials.
Any opinions?
bert.
On Thu, Jan 13, 2011 at 12:37:51PM +0100, intrigeri wrote:
Hi,
(Now Cc'ing tails-dev mailing list.)
coderman wrote (12 Jan 2011 12:06:05 GMT) :
however, more than just wipe at shutdown is useful.
Ack. On second thought, it appears to me the current T(A)ILS wipe
memory on shutdown implementation does not necessarily protect
against the attacks that the mentioned talk will probably highlight.
It is likely that some other similar implementations in Live systems
are affected as well.
In short: we wipe *free* memory only, in order to keep the system in
working state and let the shutdown sequence finish its work afterwards
(i.e. actually halt or reboot the system). On the other hand, data
saved in the {union,au}fs ramdisk branch is not free memory and might
thus be recovered. A security announce about this is being worked on
(explaining this problem and the possible consequences to
non-technical users is, well, tricky).
explicit ordered zeroisation is handy. (starting with keys and key
schedules, working cipher state, then on to user data, before
completing a full pass or three. this takes a smart kexec or other
ham fisted - still worth the effort.)
The kexec idea seems brilliant to me: this is the best way I can think
of to run the memory wipe process inside an environment where almost
all of the memory is considered as being free.
I have thus started implementing this idea in T(A)ILS. Thanks to
Debian's initramfs-tools and kexec-tools, drafting an early prototype
was quite easy. Stay tuned, more to come soon.
in any case, this begs the question of best practice in solid state
remanence avoidance. it would make a good FAQ entry, perhaps...
T(A)ILS specification and security design document (draft almost ready
to be published to a wild, unsuspecting world) intends to propose a
set of best practices in this field.
Bye,
--
intrigeri intrig...@boum.org
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Do not be trapped by the need to achieve anything.
| This way, you achieve everything.
___
tails-dev mailing list
tails-dev@boum.org
https://boum.org/mailman/listinfo/tails-dev
___
tails-dev mailing list
tails-dev@boum.org
https://boum.org/mailman/listinfo/tails-dev
Re: [T(A)ILS-dev] BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
On Fri, Jan 14, 2011 at 12:26:13AM +0100, intrigeri wrote: Hi, Still, if the kexec method don't help in wiping key material, I suppose writing a very simple wrapper to cryptsetup that use luksSuspend then luskClose when cryptsetup is called to luksClose an encrypted disk might be an excellent way to wipe remaining key materials. As I explained above, kexec itself does not wipe the key material. It is merely a tool that provides us a fresh runtime environment, inside which we can wipe all free memory without the system getting stuck, i.e. we can still properly halt/shutdown the system afterwards, without relying on really black magic tricks and calculations that cache stuff and kill smem before it erases tools needed to shutdown the system. The work I am doing aims at booting (using kexec) a kernel+ramdisk that: 1. wipes memory (i.e. all memory but the one that is used by the new kernel/ramdisk) 2. halts/reboots the system, accordingly to what the user asked for. This is surely a big enhancement over our previous implementation, nice you're working on it. Having cryptsetup wipe the key material itself on luksClose would nevertheless be welcome: not only defense in depth seems really useful in our usecase, but doing this would ensure the key material for closed encrypted devices is not available anymore, even in case the shutdown-time memory erasure cannot happen for whatever reason. On that subject, I realized this morning that I was wrong, actually cryptsetup DO wipe keys on luksClose and some other operations. It has implemented it in lib/volumekey.c (crypt_free() function), which I hadn't really reviewed yet. Sorry for my mistake, but happy being safe :) bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [T(A)ILS-dev] doc: warnings
Hi, Did a review and corrected some tiny typos or formulations, but so far looks like you did a great job! bert. On Thu, Apr 14, 2011 at 05:28:37PM +0200, sajolida wrote: Hi everybody, In the process of rewriting Tails' documentation I worked yesterday on the warning page. The idea is to have a page that new users would read before downloading Tails in order to understand what Tails doesn't protect them against. I started working on the basis of the list we established (see my mail from 17/02/11 10:19). So I'm asking for your review. I pushed my work on the dedicated branch of the repo call 'doc-rework'. The page is wiki/src/doc/warning.mdwn. Thanks, -- sajolida ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [T(A)ILS-dev] Linux kernel shipped in upcoming 0.7.x
Hi, On Mon, Apr 18, 2011 at 11:39:18AM +0200, intrigeri wrote: Hi, Input data: - a great number of Tails 0.7 users are affected by Debian bug #618665 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618665) - this bug is fixed in an updated kernel that is available in the squeeze-proposed-updates repository, but not in the main Squeeze repository yet - the DHCP software shipped in Tails 0.7 is affected by a remote arbitrary code execution flaw (DSA-2216) = I think we should prepare and publish a 0.7.1 release that would fix these bugs, presumably using the updated kernel from s-p-u. On the other hand, as stated in our design document, we generally want to ship the latest kernel available in Debian backports for better hardware support; we can expect 2.6.38 to reach backports pretty soon: http://lists.debian.org/debian-backports/2011/04/msg00027.html So I'm not sure what we should do. What do you think? Shall we wait for 2.6.38 to be available in backports and ship it in 0.7.1? Does it seem robust and tested enough for our needs? This is a tough question! I'd be in favor to update asap, as this pointer bug seems to happen a lot, and the DSA is quite serious. However, the kernel choice sure isn't easy. Seems like the last 2.6.38 upstream stable (.4) happened 4 days ago, and this kernel is included in stable since a month or so into Debian unstable. There's no bug report on it in the Debian Bug Tracker. I think it might be a bit soon to ship this kernel into tails yet. Sounds like it'd need some more testing, but maybe I'm wrong. Do others here run this kernel since some times? bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] Anonymous Blogging with WordPress and Tor
Hi, Nice email, I did some corrections though. bert. On Mon, Jul 04, 2011 at 09:38:57AM +0200, sajolida wrote: Hi, Here is the draft of the email I'm planning to send to the author of this guide. I'd like to have a quick review from you before sending it. × × × Hi, This week I found out about your document called « Anonymous Blogging with WordPress and Tor » and read it carefully and with interest. I'm part of the team developing Tails, a live CD or live USB that aims at preserving your privacy and anonymity; first, by redirecting all outgoing traffic to Tor, and second, by taking special to leave no trace on the computer you're using unless you ask it explicitly, see: http://tails.boum.org/ Tails is now listed by The Tor Project as it's recommended live distribution, see: https://www.torproject.org/projects/projects.html.en I would like to suggest you trying out Tails and possibly adapting some part of your guide to using it. I believe it would make parts of it easier to document and also improve the overall solution that you're proposing. I'll tell you why. Trusting your OS A central vision of Tails is that it is crucial to trust, as a whole, the operating system that you are using if you're planning to do any sensitive task on a computer, like protecting your anonymity or working on sensitive documents. For example, on page 8, I agree with you when you advocate the use of Firefox over Internet Explorer but following the same assumption you should not advocate the use of Tor from Windows. The operating system is the central piece of software managing all your applications, having direct access to your files, your disks, your network interfaces, etc. If you can't trust your OS, any security measure that you try to build on top of it is bound to be flawed. The assumption of Tails regarding this is that you'd better trust open source software, in our case Debian GNU/Linux on which Tails is based and which is quite well know to be reactive on security issues than proprietary software like Windows, quite well know for just the opposite. Plus, since Tails is a live distribution, the OS is restarted in its original state at every use so that viruses, buggy software or misuse can't affect the system on the long run, especially if run from a read-only support like a CD. This is how we try to provide an improved level of trust on the OS and then build security measures at the application level on top of that. Regarding your document, that would resolve the issue you're mentioning on page 1 and provide you an OS easier to trust against keyloggers and viruses. About secure deletion - When writing documentation about security measures it's both hard to know where to stop and at the same time be sure you wrote enough. For example, on page 20 you advise to use securely delete posts after publishing them. This means that you include in the thread model of the people reading your document that the computer they use could be seize and investigate by forensics in search of traces from those documents. For example, on page 20, you advise to securely delete files used for the post after publishing it. (or something like that) could be seized and investigated by forensics experts Tails could help you addressing better this thread by: - ensuring that every document written during a Tails session won't leave any trace on the computer since it's a live distribution running from RAM and that it takes special care to not leave any trace on the local storage of the computer unless asked explicitly, - being shipped already with tools for secure deletion — then actually documenting how to use them would be shorter and easier. For example, when you're saying on page 21 « Write your blog post offline. Not only is this a good way to keep from losing a post if your browser crashes or your net connection goes down, it means you can compose your posts somewhere more private than a cybercafe. », if using normal operating systems, you are very likely to leave traces of the document on both your machine and the public one. Plus, it would be a good idea to suggest the users safe ways to carry their drafts from one machine to another, for example: to suggest to users 1. Using an encrypted USB stick. That would be something else to document well since actually securely delete a single file on a USB is much more problematic that on a hard drive, see : http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf Tails provide tools to fully encrypt USB sticks. 2. Saving the drafts in the disposable mailbox. That might be a better solution if it is encrypted using FireGPG. Tails also comes with FireGPG installed. Furthermore, it is good to advertise the securely deletion of files but then to be coherent you should also advertise the secure
Re: [Tails-dev] tails-greeter conversion to dh_python2
On Tue, Jul 19, 2011 at 01:10:21AM +0700, † wrote: 18.07.2011 04:04, intrigeri пишет: I've pushed a branch called dh_python2 into your tails-greeter Git repository. This branch converts the packaging to dh_python2; it also has a few other commits with tiny packaging improvements. Merge was successful but after that installation to my test system fails with following error: tails-greeter depends on python (= 2.6.6-7~); however: Version of python on system is 2.6.6-3+squeeze6 Is this some glitch in my build env or it's intended behavior and I should update python in test env? Seems that in squeeze the actual python package is 2.6.6-8, so I guess yes, you should update your build env. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
Hi again, Also I just notices intrigeri asked you a late question about your last week report on the tails-dev mailing list without any answer. Please see his last mail to you and tails-dev from August 04 about using a shell script. Did you answer to this question privately? bert. On Fri, Aug 05, 2011 at 05:25:22PM +0200, berta...@ptitcanardnoir.org wrote: Hi, I'm trying to catch up on this GSOC work, so I might be lacking some informations to correctly understand everything. Don't hesitate to correct me if I make any mistake. I've tested your previous 0.0.5 release as well as this week's one in a fresh VM, and read your previous exchanges with intrigeri. On Fri, Aug 05, 2011 at 02:15:52AM +0800, † wrote: Hello. Current progress: obtain list of kb layouts and variants available (via python-xklavier) - DONE. populate layout widget with kb variants - DONE. merge feature/better_root_access_control branch - DONE. Confirm the above three DONE items. Well done! apply correct layout after it's been chosen (both to present and following greeter widgets and to actual session) - postponed. verify that layout switching works after login - postponed version tag and update - DONE. As I understood, you were also supposed to upload a Debian package to your tails repo, which I can't find. Problems: tails-greeter is run under gdm's account but altering gdm PostLogon files (to set env variables) or locale compilation via localedef require root privileges. Seems like intrigeri already proposed a workaround to this last week, please read again his answer to your report last week. xklavier set and check layout without errors but it doesn't affect greeter nor following session. better_root_access_control feature requires env. variable to be set which is not possible yet. Near-future plans: wait for answer from gdm and xklavier devs to figure out workarounds for current problems Do you have pointers to this conversation? I might be interested to follow it, and eventually help you with it. replace 2 widgets with 1 panel with same functionality test the result with tails Sounds to me that the next step to this dev would be to implement a way to pass env variables too. Additional notes: right now there are 2 screens which user moves through by pressing next button. That's rather ugly and is planned to be replaced with one of the following: 1) single screen with requests for both at the same time 2) 2 screens with language and layout requests on first one and admin password request on second one Which do you think is better and why? Please feel free to discuss it on irc this Saturday during regular meeting time or whenever you'll see max-gsoc I think intrigeri already made that clear when you started with 2 screens that at the end we wanted to have only one screen with all options on it. We don't want to bother too much our users with multiple screens. Another question: reading your commits, you removed the babel module importation. Do you plan to put it back, or are you just getting rid of it? In the latter case, you should also consider removing it from the install dependencies of the Debian package in debian/control. See you tomorrow morning. bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
On Sat, Aug 06, 2011 at 12:24:36AM +0800, † wrote: 05.08.2011 23:53, berta...@ptitcanardnoir.org пишет: Also I just notices intrigeri asked you a late question about your last week report on the tails-dev mailing list without any answer. Please see his last mail to you and tails-dev from August 04 about using a shell script. Did you answer to this question privately? He departed to vacation before that. In short - yes, rewriting sh to python is doable but the code which supposed to be rewritten is (or, to be more precise - will be) obsolete after some workaround to pass env. vars will be implemented anyway. Fair enough. We'll see if such a workaround exists though. bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] [gsoc] tails-greeter progress report
On Sat, Aug 06, 2011 at 12:38:24AM +0800, † wrote: 05.08.2011 23:25, berta...@ptitcanardnoir.org пишет: As I understood, you were also supposed to upload a Debian package to your tails repo, which I can't find. Sorry, forgot to push it. Should be available now. Seems not really, can't find any new commit with the new Debian package. Seems like intrigeri already proposed a workaround to this last week, please read again his answer to your report last week. Just to get potential readers up-to-date: the idea is following tails-greeter writes some instructions (env. variables, locale generation parameters smth else) to the place writable for it's user (Debian-gdm) for example. Upon logon some startup script parse this file and execute them (as amnesia user or as root). That'll be next thing I'll try to implement and that's actually what I'd like to discuss: So that maybe should be added to your schedule for next week, it was my suggestion in my last email. - how good\safe is this approach? Using such tricks to have something executed by root might sure bring the question, and that's nice it pops up in your head. But well, we're talking about mostly predefined choices, and run once during the system boot time. I'm not sure to see what an attacker could do to take advantage of this and s/he is able to do this, s/he can do a lot more. - are there better alternatives? I'm out of idea for the moment, but will sleep on this. Note that at least some of the instructions from this file got to be executed with root privileges. Just to clarify: by executed I don't mean sh file.sh - it might be $ARG1 supplied to sudo ls $ARG1. Do you have pointers to this conversation? I might be interested to follow it, and eventually help you with it. http://mail.gnome.org/archives/gdm-list/2011-August/msg2.html Thanks. Looks like for the moment they don't really have answers to your issue, we'll see in the next days, but I suspect you won't have much choices. replace 2 widgets with 1 panel with same functionality test the result with tails Sounds to me that the next step to this dev would be to implement a way to pass env variables too. Not really sure what you mean. If you're talking about task priorities than - yes, that's true. The tasks are orthogonal though. I meant: add to the next week plan the work on implementing a way to pass env variables to the session. I'm not sure to get why this two tasks are orthogonal, I rather feel that the env thing is not that much related to how the widget/panel are organized and can be developed independently from the other one. But maybe I'm wrong and missing the big picture, and would be glad to have your input in this case. It seems that there is not much time left before the end of your GSOC, and this is a critical piece of the project I'd like to see getting forward. I'm not asking for this task to be completely done at the end of next week, but given the time spent on the GSOC your commits seems to reveal, I'd prefer to see some work going on in this area, and the plan you posted initially might have some room left to add it. But sure the panel reorganisation is also important. :) Another question: reading your commits, you removed the babel module importation. Do you plan to put it back, or are you just getting rid of it? In the latter case, you should also consider removing it from the install dependencies of the Debian package in debian/control. That was just part of pylint warnings cleanup. I didn't notice that it's completely gone now :) Great! bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] ***SPAM*** Re: ***SPAM*** [gsoc] tails-greeter update
Hi Max, Nice to see new commits! Comments below: On Mon, Aug 08, 2011 at 05:29:14PM +0800, † wrote: And another update - a bit quicker than I've expected :) Layout selection is now working for both greeter and gnome session. However it's been tested mostly with English and Русский, so if you'd like to see YOUR favorite keyboard layout properly supported than please test it and get back with the feedback. The layout indicator question is still under investigation. I'm not sure what you mean by that. Testing it I have several issues : * When choosing the French language, the locale form get updated correctly, and I can choose between fr_BE, fr_FR, etc. Still the keyboard layout selection form only show the be and us layouts. I guess it is what your last sentence is related to. * Choosing the be keyboard layout doesn't actually change the keyboard layout in the greeter itself. It is applied in the GNOME session though. I have attached the greeter logs. I'll give it a closer look too. Nice to see the greeter going forward. :) bert. gnome-session[1599]: atk-bridge-WARNING: AT_SPI_REGISTRY was not started at session startup. gnome-session[1599]: atk-bridge-WARNING: IOR not set. gnome-session[1599]: atk-bridge-WARNING: Could not locate registry ** (unknown:1609): DEBUG: Client registered with session manager: /org/gnome/SessionManager/Client1 Window manager warning: Failed to read saved session file /var/lib/gdm3/.config/metacity/sessions/109521db6f30dedb2013128018994797770015990004.ms: Failed to open file '/var/lib/gdm3/.config/metacity/sessions/109521db6f30dedb2013128018994797770015990004.ms': No such file or directory (polkit-gnome-authentication-agent-1:1638): GLib-GObject-WARNING **: cannot register existing type `_PolkitError' (polkit-gnome-authentication-agent-1:1638): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed [WARNING] pixmap.py:65 get_pixmap: No pixmap file 'default' in ./pixmaps/lang [DEBUG] language.py:36 module: 234 languages found: helper returned 0 [ERROR] language.py:85 get_texts: Failed to get texts for hr locale [ERROR] language.py:85 get_texts: Failed to get texts for ti locale [ERROR] language.py:85 get_texts: Failed to get texts for si locale [ERROR] language.py:85 get_texts: Failed to get texts for ja locale [ERROR] language.py:85 get_texts: Failed to get texts for hy locale [ERROR] language.py:85 get_texts: Failed to get texts for ko locale [ERROR] language.py:85 get_texts: Failed to get texts for uz locale [ERROR] language.py:85 get_texts: Failed to get texts for pa locale [ERROR] language.py:85 get_texts: Failed to get texts for el locale [ERROR] language.py:85 get_texts: Failed to get texts for be locale [ERROR] language.py:85 get_texts: Failed to get texts for da locale [ERROR] language.py:85 get_texts: Failed to get texts for ts locale [ERROR] language.py:85 get_texts: Failed to get texts for ht locale [ERROR] language.py:85 get_texts: Failed to get texts for kl locale [ERROR] language.py:85 get_texts: Failed to get texts for shs locale [ERROR] language.py:85 get_texts: Failed to get texts for fil locale [ERROR] language.py:85 get_texts: Failed to get texts for am locale [ERROR] language.py:85 get_texts: Failed to get texts for ta locale [ERROR] language.py:85 get_texts: Failed to get texts for tig locale [ERROR] language.py:85 get_texts: Failed to get texts for ar locale [ERROR] language.py:85 get_texts: Failed to get texts for wa locale [ERROR] language.py:85 get_texts: Failed to get texts for th locale [ERROR] language.py:85 get_texts: Failed to get texts for pap locale [ERROR] language.py:85 get_texts: Failed to get texts for hsb locale [ERROR] language.py:85 get_texts: Failed to get texts for tg locale [ERROR] language.py:85 get_texts: Failed to get texts for yi locale [ERROR] language.py:85 get_texts: Failed to get texts for tk locale [ERROR] language.py:85 get_texts: Failed to get texts for oc locale [ERROR] language.py:85 get_texts: Failed to get texts for ky locale [ERROR] language.py:85 get_texts: Failed to get texts for pt locale [ERROR] language.py:85 get_texts: Failed to get texts for zu locale [ERROR] language.py:85 get_texts: Failed to get texts for lg locale [ERROR] language.py:85 get_texts: Failed to get texts for kw locale [ERROR] language.py:85 get_texts: Failed to get texts for crh locale [ERROR] language.py:85 get_texts: Failed to get texts for sd locale [ERROR] language.py:85 get_texts: Failed to get texts for te locale [ERROR] language.py:85 get_texts: Failed to get texts for bg locale [ERROR] language.py:85 get_texts: Failed to get texts for gez locale [ERROR] language.py:85 get_texts: Failed to get texts for id locale [ERROR] language.py:85 get_texts: Failed to get texts for az locale [ERROR] language.py:85 get_texts: Failed to get texts for an locale [ERROR] language.py:85 get_texts: Failed to get texts for af locale [ERROR] language.py:85 get_texts: Failed to get
Re: [Tails-dev] ***SPAM*** Re: ***SPAM*** group change on login
On Tue, Aug 16, 2011 at 01:32:36AM +0800, † wrote: 15.08.2011 20:09, intrigeri пишет: The easiest workaround I can see would be to add a line in /etc/sudoers for the amnesia user, Just tried adding antry into /etc/sudoers.d from PostLogin: it doesn't affect current session. From you commits, it seems you didn't set /etc/sudoers.d/tails.conf permissions to 0440 as /etc/sudoers as to be to work, so might be why. You also might want to comment out the last line of /etc/sudoers : #includedir /etc/sudoers.d or just echo a similar line so that the file gets included. This is all explained in /etc/sudoers.d/README on Debian systems. The suggested workaround should be completed by having the PostLogin/Default script create a file named /etc/polkit-1/localauthority.conf.d/52-tails.conf, with following content, iff. a admin password was provided: [Configuration] AdminIdentities=unix-user:1000 Also tried on my squeeze test machine but not sure how to test it. Is there a way to restart polkit? /etc/init.d/policykit restart, but I'm not sure of the side effects it could bring. bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
Re: [Tails-dev] meeting time
On Mon, Aug 22, 2011 at 10:45:51AM +0200, intrigeri wrote: † wrote (21 Aug 2011 18:24:37 GMT) : In a mean time, I've tried to add PostSession script which resets the password to default (this workaround was suggested before) but the problem is the there's already dummy script in squeeze for that. So installation (via install directive in debian/rules) fails. I've tried to add divert into .postinst/.prerm but it still fails - it looks like 'rules' script is executed earlier than .postinst - where should I add divert directives to make it work? The diversions mechanism should not be used for conffiles (ref: dpkg-divert(8)); /etc/gdm3/PostSession/Default is a conffile (ref: dpkg -s gdm3). Anyway, gdm3(8) reads: When the session has completed, gdm attempts to run /etc/gdm3/PostSession/display, or /etc/gdm3/PostSession/Default. Have you experimented with /etc/gdm3/PostSession/display ? (I wonder if it's litteraly display or rather a value of $DISPLAY, such as :0 in Tails. If the former does not work, the latter should be tried.) Examples I've seen on the web tends to say display should be written in the later form (:0). bert. ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
[Tails-dev] automated tests
Hi, Been a long time I haven't pop up around. Hope everyone is fine here. I'm slowly recovering from my burn out and try to catch up on the todo items I left over. Still it doesn't prevent me to procrastinate. :) Lately I have played with cucumber for another project and thought it would be fun to write Tails' tests with it. So I've looked a bit more at the sikuli developement status and noticed there as a ruby gem to use it. It has been pretty easy then to plug cucumber + libvirt + sikuli so that it is possible to write tests and have them run against a VM display. It requires to use jruby, as sikuli is java. But there might be other ways to implement it. I've pushed my POC in a new branch `feature/automated_tests/cucumber` and documented it a bit on the wiki : https://tails.boum.org/todo/automated_builds_and_tests/cucumber It shouldn't be very hard to had some more functionalities, like sniffing the libvirt network traffic to add cucumber steps like Then the network traffic should flow only though Tor. I've heard that some of you are commited to work on the automatic builds and tests part of the project soon, and I've seen that it was also mentioned in this year GSOC (congrats Julien btw). So might be usefull at some point. Take care bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] automated tests
On Tue, Jun 19, 2012 at 01:53:38AM +0200, intrigeri wrote:
This does look awesome!
Thanks I agree ;)
It requires to use jruby, as sikuli is java. But there might be
other ways to implement it.
Just curious: is this requirement brought in by the sikuli gem?
Totally, because sikuli is java. I didn't choose this dep by taste ;) If
one day sikuli can be used with another language, I'm totally ready to
switch.
You also need a Jruby = 1.6 environnement, which sadly isn't
possible using debian packages yet
Any hint / idea / pointer why?
See bug #636554, the maintainer seems to say back in september 2011 that
he is willing to upload jruby 1.6 *after* the testing migration. Not
sure what he means by that, probably after wheeze is released. Adding a
word on this bug is prolly a good idea, so if you want to you're welcome.
Also, it's not clear to me what guest or host means in there:
- on the VM guest or host who does the tests
- everything happens on the host or guest where the build happen
Could you please clarify this kind of sentences?
I guess this means the system, that may be either a bare-metal one,
or itself some kind of VM (with nested virtualization enabled), right?
Exactly, and that's why that was not easy to word correctly. I'll fix
this.
Also, I'm unsure about where the build happen. Do you mean where
the tests are run from, or anything else?
Yep, builds and tests are supposed to be started in the same system.
It is also possible to add and remove different types of storages,
and thus test persistence or filesystem modifications.
Have you by chance found a way to *emulate* a USB 2.0 device in
software? (qemu-kvm from current Debian testing/sid supports USB 2.0
passthrough, but this is quite different as far as automated tests
are concerned.)
Not really investigated in this area yet sorry. Apart from the
pass-through method I haven't seen anything else.
but anyway you need this gems to be installed
Do you want to {add references to,file} the corresponsding RFP bugs,
or shall I?
As you wish. As long as jruby is 1.6 in Debian at least the sikuli gem
won't be packageable anyway. Might help to get a jruby upgrade.
setup a basic VM
Providing a guest XML skeleton would be perfect :)
Yeah, that's one of the questions brought by this tool. Might be usefull
if it contains a basic domain definition for sure. For consistency of
devices name for example.
To test different feature, there will be need for diffferent VMs
configurations, for example some with more memory for the memory wiping
on shutdown feature. There are mainly two different ways to achieve this:
* programatically by using libvirt ruby bindings and use the functions to
attach/remove devices, modify the basic VM configuration, etc, which is
the current roughly implemented way.
* enable the tests to be shipped with a full domain definition, that would
be automatically loaded rather than a default one.
Between the two, tests could be shipped only with xml domain snippet
corresponding to the configuration changes to be done on the domain.
The second one would be the easiest, and might have the advantage to be a
totally stop and throw away this domain solution, so would help not to
modify too much the domain definition and keep consistency upon tests. But
there might be drawbacks too in this implementation.
Set the DISPLAY env to something relevant
What do you mean? Some unused X display?
Yes, on this unused display (so typically :7), a Xvfb virtual X server
will be attached, and virt-viewer will be told to display the domain
display in full screen there. This is the trick to have sikuli detecting
the display (thgrough the $DISPLAY env variable) and using it for the
tests without having to play to much with vnc. :)
Thanks for the feedbacks.
bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] automated tests
On Tue, Jun 19, 2012 at 01:59:14AM +0200, intrigeri wrote: Tiny remark: I think we could drop the last features component of features/cucumber/features/, so that features/cucumber/features/iceweasel/torified_browsing.feature becomes features/cucumber/iceweasel/torified_browsing.feature Makes sense? Do you want to do it, or shall I do it? Yeah, I thought about that too after pushing. It requires to slightly modify the logic that search for the iso in the vm_helper.rm though. I'll do it. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] automated tests
On Tue, Jun 19, 2012 at 01:39:17PM +0200, berta...@ptitcanardnoir.org wrote: On Tue, Jun 19, 2012 at 01:53:38AM +0200, intrigeri wrote: Have you by chance found a way to *emulate* a USB 2.0 device in software? (qemu-kvm from current Debian testing/sid supports USB 2.0 passthrough, but this is quite different as far as automated tests are concerned.) Not really investigated in this area yet sorry. Apart from the pass-through method I haven't seen anything else. Actually I just found http://www.linux-usb.org/gadget/ after a quick search. I haven't yet really understood all of this project, but it seems it has the feature to emulate USB at the kernel level without any hardware. At least if you look at [1], it says: /* 17 * This exposes a device side USB gadget API, driven by requests to a 18 * Linux-USB host controller driver. USB traffic is simulated; there's 19 * no need for USB hardware. Use this with two other drivers: 20 * 21 * - Gadget driver, responding to requests (slave); 22 * - Host-side device driver, as already familiar in Linux. 23 * 24 * Having this all in one kernel can help some stages of development, 25 * bypassing some hardware (and driver) issues. UML could help too. 26 */ It requires USB_DUMMY_HCD to be configured in the kernel config, which isn't in Debian kernel AFAIK. Maybe I misunderstood the features, but might deserve some more digging still. bert. [1] https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/usb/gadget/dummy_hcd.c;h=170cbe89d9f8ad47b9bb6ee54596521012c8de7f;hb=HEAD ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] automated tests
On Wed, Jun 20, 2012 at 01:02:30AM +0200, intrigeri wrote: berta...@ptitcanardnoir.org wrote (19 Jun 2012 11:39:17 GMT) : Also, I'm unsure about where the build happen. Do you mean where the tests are run from, or anything else? Yep, builds and tests are supposed to be started in the same system. Why? (In the setup we had in mind for the upcoming autobuild/autotest server, the builds and tests would be started from different systems, due to incompatibility between the VirtualBox and KVM kernel modules.) Probably because I didn't know or forgot this part of the specs. :) You mean we can't build Tails inside a kvm domain because then virtualbox has trouble installing? I admit I haven't tested. But well, basically all that this cucumber tests need are an iso file, and its path can be configured by the ISO env variable as stated in the README. So I guess we can answer to your first question as where the tests are run from and update the documentation. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] automated tests
On Sun, Jun 24, 2012 at 08:55:00AM +0200, intrigeri wrote: - file a whishlist bug, if needed, so that the Debian kernel gets these modules enabled? #678731 Nice work! So we have a reliable tested solution for this part of the tests AND in the future it will be usable in Debian. :) On my side, I've added the ability to handle domain and network xml definitions to the code. It uses the default ones actually pushed in the repo, and remove them from the libvirt conf after the tests. It can be configured through environment variables to use other xml files. I've also added a basic sniffer. It's working, but tcpdump's habits to output stats when stoped kinda mess with the cucumber output. So if someone knows a tool that is more quiet, I'll be happy to replace tcpdump. Otherwise, it shouldn't be too hard to code a basic sniffer for our use. Now in the step_definitions, it is possible to start one or several sniffers, and use `@sniffer1.packets` to post-process the network traffic. I began to think about how to filter the network traffic depending on being inside or outside of Tor's network. I see 3 ways to get a list of Tor's network ips to test against: - Simple and dumb: collect every node ip from the dir authorities - Run a Tor on the testing system, and parse its cached consensus file. - Have an access to the system under test Tor instance to get the entry_guards informations. First is easy (I made such a tool monthes ago, but we could also ask to Mr. Filliol ;)) but gets you 4000+ ips to filter against. Second sounds like another easy solution and maybe the best for now. Third would mean having to modify the system under test configuration, which isn't really desirable. Do any of you see another way? I already did some work on the doc on its wiki page, but I still have to reword it to follow this new features. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fwd: Re: [tor-assistants] deb.tp.o only serves experimental builds
On Thu, Jun 28, 2012 at 12:31:50PM +0200, anonym wrote: 27/06/12 23:12, intrigeri: anonym wrote (27 Jun 2012 19:35:06 GMT) : Therefore I'd like to stick with the (still stable) 0.2.2.x series, Agreed. but I'm unsure what our best option for that is. What comes to mind is yet another config/chroot-local_includes, although that will bloat our git repo quite significantly (the tor package is 1.2M, and tor-geoipdb is 1.4M). Given testing currently has 0.2.2.37-1, one could push it to squeeze-backports and install from there. Or, even simpler, temporarily add the testing repo, pin tor from there. I don't think that would work unfortunately, Tor in testing has a dependency on libssl 1.0, and it's only 0.9 in Squeeze. That's why a backport is needed. weasel wants me to ask him again about it tomorrow. Ping me on IRC if it looks like I forgot. Ask about what? Backporting? Yeah must be something like that. Else, I don't care that much bloating our Git repo, since we are supposed to split it and get an APT repository soon. Sure, but my above solution avoids that and is just as easy. An intermediate solution would be to backport Tor from testing ourselves and add it to our git. Or use the actual Tor that is in squeeze-backport, which is 0.2.2.34. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] roadmap and broken windows
Hi, As a reminder, here's the decisions we took when discussing about the roadmap and how we'll solve the broken windows. * We'll organize sprints to work specifically on broken windows. It will likely be impossible in 2012 though, and hardly depends on fundings. But there are good chances to see this happening in 2013. * During our monthly meeting, we'll organize Broken Window Fixing weeks, on quick and easy ones. During this week, people will dedicate their Tails time to work on those bugs rather than on new features. Likely this week will be the one following the monthly meeting. * We'll organize our team to do shifts on the forum and support tasks so that some of us will have free time to work on those broken window items. Someone will setup a bot to automatically remind us of the next upcoming meeting date. I think that's mostly what we decided. Please amend if I forgot or misunderstood something. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] roadmap and broken windows
On Fri, Aug 17, 2012 at 10:22:51PM +0200, intrigeri wrote: Robert Ransom wrote (17 Aug 2012 15:53:46 GMT) : re https://tails.boum.org/todo/fix_Internet_FTP_support/ : See https://bugs.torproject.org/1259 and https://bugs.torproject.org/3290 . You probably won't be able to fix this bug. Thanks a lot for the information. Fellow Tails developers, I'm afraid this a broken window will last a bit more than we would like. Given this additional piece of information, I don't think it should block the Tails 1.0 release. Thoughts? Agree. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fwd: live-config_3.0.4-1_i386.changes ACCEPTED into unstable
On Fri, Aug 24, 2012 at 05:03:50PM +0200, intrigeri wrote: Hi, live-config (3.0.4-1) unstable; urgency=low . * Using /etc/live/config/* instead of /etc/live/config.d/*.conf and /live/image/live/config/* instead of /live/image/live/config.d/*.conf for consistency reasons. * Removing leftover from live-debconfig in postrm. * Recreating /etc/live/config in postinst. * Removing /etc/live/config if empty on purge in postrm. Given we install live-config from sid, I think next builds (including 0.13~rc2) will get that one, and then we're affected by the config directory name change. Do we want to keep the current version tested in rc1 (live-config 3.0.3-1) or get the new one and adapt? I'm strongly tempted by the former. Given the current state of our work for the 0.13 release, I'm also tempted to say we should delay this for the next point release too. We're supposed to have freezed after all. bert, slowly getting into wearing its neatpicker hat :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/assymetric_gpgApplet [sic!]
On Fri, Aug 24, 2012 at 09:21:22AM +0200, intrigeri wrote: anonym wrote (22 Aug 2012 08:53:02 GMT) : All is merged into experimental. Thanks. Unfortunately, I forgot to merge it at pre-freeze time, and unfortunately nobody noticed it in time since the todo/qa tag was not set after the last development round, so that will be stuff for the 0.14 merge window. I updated the ticket to reflect the current state of things. Sorry about that :( (To clarify: when, after I've reviewed a branch, I'm asking for more development to be done before merging, then I'm setting the ticket back to todo/code state, and I consider it's the responsibility of the branch/ticket holder to change it back to todo/qa once they consider the issues raised by the reviewer were fixed. If we agree on that, perhaps it's material for our upcoming how changes go into Tails improved process doc.) Sounds like a good process, agree to add this in the documentation. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Upcoming release schedule plan
Hi, Following our discussions on the timeline for the next release, here is the plan we ended up with and I committed to send on this list : - Theoritically: ESR (August 28th) + 1 week = September 4th - August 23: release 0.13~rc1, do the test suite together - Week 35 - Mon 27th: ESR is out update of the GnuPG docs - Week 36 - Tue 4th: release 0.13~rc2, testing phase - Thu 6th: monthly meeting - Week 37 - Tue 11th: release 0.13 (final) Hope I didn't forget anything. If anyone on this list is willing to participate to the release tests, help on this is more than appreciated. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please test 0.13-rc1
Hi, Done the memory wiping on shutdown test, seems to work in the expected way. I've added the liveusb-installer breaks emergency shutdown bug to the known issue page. Please remember to update this page while testing. So far, here are the remaining release tests for this RC : # Monkeysphere * Monkeysphere validation agent key search/receive: torified? uses configured keyserver? # Persistence * Activate persistence on a Tails USB install with all presets on. * Reboot, enable persistence. Verify via `mount` that each preset has a mount that seem correct (e.g. Pidgin preset = `/home/amnesia/.purple` has something mounted on it). * Try read-write mode. Make sure that persistent files are writeable, and that changes do survive reboot. * Try read-only mode. Make sure that persistent files are writeable, but that no changes survive reboot. * Test adding a few custom directories. * Turn off some persistence presets, reboot, and make sure they are not activated. I'll make a pause today, but will be able to do some other tests tomorrow. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Fri, Aug 31, 2012 at 11:15:41AM +, Ague Mill wrote: On Mon, Aug 27, 2012 at 12:51:04AM +0200, intrigeri wrote: As you know, I tend to think the problem fixed by this patch is not worth the risks involved at this stage of the release process, but my extra-carefulness does not extend to vetoing if there is a general agreement with applying this patch before rc2. + start-stop-daemon \ + --start --background --pid /var/run/background-readahead.pid --startas /bin/sh -- \ + -c $BG_FILES | xargs cat /dev/null 21) I assume you wanted to write --pidfile, as --pid does not exist in my copy of start-stop-daemon. Beware before s/pid/pidfile/, though: given --pidfile presence/absence changes quite drastically the behavior of start-stop-daemon, if the proposed patch works, then this option is probably not needed, is it? Actually, this works due to GNU getopt magic: $ /sbin/start-stop-daemon --start --background --pidfile /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' $ /sbin/start-stop-daemon --start --background --pid /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' $ /sbin/start-stop-daemon --start --background --pi /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' This fails: $ /sbin/start-stop-daemon --start --background --p /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' /sbin/start-stop-daemon: option '--p' is ambiguous Getting rid of `--pidfile` also fails: $ /sbin/start-stop-daemon --start --background \ --startas /bin/sh -- -c 'date /tmp/test' /sbin/start-stop-daemon: need at least one of --exec, --pidfile, --user or --name What this made me realize, though, is that `--pidfile` is useless without `--make-pidfile` in this context. So I have updated the branch to fully spell `--pidfile` and to also create that pid file. The broken sed invocation was also fixed, and as added bonus, the foreground progress bar now goes to 100%. I still would like to see this reach 0.13~rc2. Given we're supposed to be freezed, I'm not sure this is a good idea, unless there is has been tested a lot before being merged, and there is a strong commitment to test this in the 0.13~rc2. Is the goodness of this patch worth the effort or risk to include this so lately in the release process? Also I haven't found a corresponding ticket in the wiki, appart from the old todo/improve_boot_time_on_cd, which is marked as done. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Disabling 'PC speaker'?
On Fri, Aug 24, 2012 at 10:23:54PM +0200, sajol...@pimienta.org wrote: On 24/08/12 11:19, Ague Mill wrote: Hi! I would like to blacklist the 'pcspkr' module. It is responsible for making the old-style 'PC speaker' work. On some computers, having the module loaded means loud beep at bootup, shutdown and when using the console. The idea is already to start Tails with a muted soundcard. Does anyone see a reason not to kill the 'PC speaker' as well? Implementation is straightforward, it's a new file in /etc/modprobe.d/no-pcspkr.conf with: blacklist pcspkr (I'll push that change after 0.13 is released if no one cares.) We're not shipping the `beep` package so that's fine with me ;) Can't see a reason not to include this change actually, so I'm fine with it. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sat, Sep 01, 2012 at 11:02:22AM +, Ague Mill wrote: On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote: Also I haven't found a corresponding ticket in the wiki, appart from the old todo/improve_boot_time_on_cd, which is marked as done. What should be written in there? Like you described in your previous mail I guess, something like Since 0.12, a regression was introduced in the readahead mechanism that makes the bloot slower because it pauses (rephrase this lame words as you want). I don't know, I'm not the one who worked on this. Sorry if you feel I'm behaving like an asshole, but I'm just doing my job of nitpicker like we decided, and try to push the process we decided about how we document our changes in tickets. At least you'll have the joy to tagging it pending if no one opposes to its inclusion in RC2. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Iceweasel backports experiments
On Thu, Sep 20, 2012 at 01:26:23PM -0400, Robert Ransom wrote: On 9/20/12, berta...@ptitcanardnoir.org berta...@ptitcanardnoir.org wrote: Then by curiosity, I tried to see if Torbrowser's patches apply in Iceweasel source tree, starting from the current squeeze-backports version. And it appears they are. I've imported all of them but four that I felt weren't necessary: * 0007-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch Do not omit this patch. But in Tails, the browser isn't started by vidalia. Is there another reason I don't get? * 0012-Rebrand-Firefox-to-TorBrowser.patch * 0014-Add-DDG-and-StartPage-to-Omnibox.patch * 0019-Adapt-Steven-Michaud-s-Mac-crashfix-patch.patch (related to OSX) This patch appears to be required on all OSes. Ah, the header was quite specific about OSX, will investigate this, thanks. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/use_ferm
Hi, On Mon, Sep 24, 2012 at 12:27:59PM +0200, intrigeri wrote: Hi, Reviews welcome, candidate for the next major release. I'm not too happy with the initial commit (f00effb), because it removes the check for the needed tool existence and leaves the exit code checking to the implicit. I suggest: * re-adding something like: [ -x /usr/sbin/ferm ] || exit 2 * clarifying with a comment that the ferm command invocation should remain the last one in this script. About ferm.conf, the Emacs mode line sets shell-script, but given the syntax, apparently conf-space-mode or perl-mode do a quite better job, so I suggest: # -*- mode: conf[space] -*- Other than that, static reviews passes as far as I'm concerned, and I'll test and merge this later today or tomorrow. Oops, I was doing the test and merged the branch in devel as the firewall configuration doesn't seem to have changed with this feature. Then I saw your email... Too late, already pushed it :/ Feel free to revert the merge, or do another merge if/when intrigeri suggestions are implemented. Nice job, anonym and ague! +1 bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Wed, Sep 26, 2012 at 07:43:22PM +0200, a...@boum.org wrote: Hi, From: berta...@ptitcanardnoir.org Date: Mon, 24 Sep 2012 11:28:28 +0200 Tested, works, merged into devel. Well done! I can't find it on devel. Did I miss something ou did you forget to push? Damn you nitpicker! :) My fault, I did a simple merge and forgot the --no-ff option :/ How can I solve this? bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Thu, Sep 27, 2012 at 09:26:51AM +0200, intrigeri wrote: berta...@ptitcanardnoir.org wrote (26 Sep 2012 18:28:06 GMT) : My fault, I did a simple merge and forgot the --no-ff option :/ How can I solve this? We won't rewrite history for such a tiny detail, so you cannot solve what already happened. That's what I thought, asked just in case I missed a trick. However, you may solve it for future cases by writing a how to review and merge a branch checklist, that would contain often forgotten bits such as check that the design doc was updated, check that user doc was written and reviewed, use --no-ff, once merged, tag the ticket pending, etc. Good idea. I think now I've made the mistake, it will already solve that part. But a documentation page would still be precious, so let's do that. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
On Thu, Sep 27, 2012 at 11:24:04AM +0200, intrigeri wrote: Hi, Ague Mill wrote (26 Sep 2012 12:08:08 GMT) : htpdate lists a --proxy option. I may assume that when I don't specify this option, it will not use a proxy at all. But, the current code will still use a proxy if HTTPS_PROXY or ALL_PROXY are set. I think this is confusing. Fair enough, nice catch. Here's what I did, then: -[ 'proxy|p:s', what to pass to curl's --socks5-hostname ], +[ 'proxy|p:s', what to pass to curl's --socks5-hostname (if unset, environment variables may affect curl's behavior -- see curl(1) for details) ], Uh... and actually, those changes might require to add some more tests to the checklist. What do you think? I'll think of it later today or tomorrow. Done (19b552f) -- yeah, that's the bare minimum. I'm not sure if, and how, we would want to deeper dive into checking that Tor itself works as advertised. If the current state of this branch looks good enough, I suggest you build an ISO from devel + feature/separate_Tor_streams, and run these tests before merging. Done the tests, works as expected, merged (with --no-ff this time) in devel, and pushed. I haven't updated the ticket, there was no qa tag in there, and I was not really sure about the chenges that have to be done. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]
On Thu, Oct 04, 2012 at 05:33:18PM +, Ague Mill wrote: On Wed, Oct 03, 2012 at 11:21:05PM +0200, intrigeri wrote: intrigeri wrote (03 Oct 2012 17:30:10 GMT) : anonym wrote (03 Oct 2012 14:34:59 GMT) : So, with the current state of things it still looks like a bug to me, although with nice side-effects. Making it into a proper feature (i.e. patching nm-applet) is definitely desirable, but not something I'm willing to take on for the 0.14 release. I'm now convinced. Let's document this as a known issue, and create a ticket to remember we need to make up our mind some day on this topic (possibly after Wheezy is released). I've tested the branch and I'll be happy to merge it once we have made a decision on the autoconnect thing (deadline for anonym's proposal: Friday at noon CEST). Don't wait for me, I am convinced as well. Same here :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge bugfix/udisks-do-not-make-Tails-USB-unbootable
Hi, On Sat, Mar 23, 2013 at 07:26:14PM +0100, intrigeri wrote: Hi, Ticket: todo/palimpsest:_do_not_make_Tails_USB_unbootable (updated and tagged todo/qa locally, can't push right now as the live website is locked / being rebuilt). Merged into experimental, candidate for 0.17.2 and 0.18 = please review merge into stable and devel. [...] All this was implemented in bugfix/udisks-do-not-make-Tails-USB-unbootable. It works for me: * I still can install Tails on USB, boot from USB, setup persistence, reboot, delete persistent volume, reboot. One can check with sgdisk that the bootable flag is still here. * I now can install Tails on USB, boot from USB, create a partition with GNOME Disk Utility, reboot. Note that even with the parted bugfix in place, only the bootable flag is preserved, not the 3 non-critical other ones we set, but I consider they're merely bonus, so I'm ignoring this for now (and actually, I doubt we can ever do better without patching parted, which does not seem worth it, so I'm not even filing a ticket about it). Most of the changes are in the APT repository, t-p-s Git repo and liveusb-creator repo, so reviewers should inspect these in addition to the minor commit in our main Git repo. Tested, works as explained, so : - Cherry-picked commit f1ccd742 back from experimental, as it wasn't in the bugfix/udisks-do-not-make-Tails-USB-unbootable branch. - Merged into stable and devel, in git and the apt repo - Updated the ticket to pending. Hope I didn't miss something. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge bugfix/udisks-do-not-make-Tails-USB-unbootable
On Thu, Mar 28, 2013 at 06:22:07PM +0100, intrigeri wrote: hi, berta...@ptitcanardnoir.org wrote (28 Mar 2013 13:58:38 GMT) : - Updated the ticket to pending. I can't see this. Perhaps you forgot to push your master branch? Right, forgot to push this one. Now fixed. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Jenkins setup: present and future
On Fri, Apr 12, 2013 at 04:10:08PM +, Abel Luck wrote: Amazing! As someone whose grappling with Jenkins and Android emulators, the idea of getting it working with a complicated vagrant setup is scary. We don't really use vagrant for the jenkins build. We do explain to people who wants to build Tails to use our vagrant scripts though, as in https://tails.boum.org/contribute/build/ In jenkins, we use a kvm guest as build slave. As a lot of bricks can change the build result, it's better to use the same tools as much as possible everywhere. So we just adapted the script we provide for our vagrant build so that it also works for our jenkins builds. Props all around! Thanks! bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Jenkins setup: present and future
On Sat, Apr 13, 2013 at 01:28:27AM +, adrelanos wrote: Sounds great. intrigeri: Tails core developers can now push stable, testing, devel and experimental branches to `gitol...@git.puppet.tails.boum.org:tails'. Whenever they do this, an ISO image is built on builder.lizard. The product of this build is kept there for a while. While I am not a core developer but I could imagine to contribute some patches. Building requires setting a build environment, takes a lot space and a long time. Could I push my branch somewhere and you initiate the build? That is something being think about, but at the moment we're in a very early deployment state. Learning the tools. Before allowing something like that we have to first close some more items of the roadmap : https://tails.boum.org/todo/automated_builds_and_tests/ Bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review merge feature/install_gnome-accessibility-themes
Hi, On Thu, Apr 25, 2013 at 10:15:36AM +0200, sajol...@pimienta.org wrote: As suggested on the forum [1], I created a branch to install gnome-accessibility-theme. Ticket: /todo/install_gnome-accessibility-themes Branch: feature/install_gnome-accessibility-themes Candidate for Tails 0.18. Tested, simple and efficient, so merged into devel. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please reviewmerge feature/obfs3
On Fri, Apr 12, 2013 at 12:05:00PM +0200, intrigeri wrote: Hi, the feature/obfs3 branch adapts the ClientTransportPlugin line added to torrc when needed to support the obfs3 bridges, that the new obfsproxy 0.2.x (automatically picked up by the latest Tails ISO image builds) supports. Please reviewmerge. ticket: todo/obfs3 branch: feature/obfs3 candidate for Tails 0.18 Tested and happy with it so merged in devel. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Release schedule for Tails 0.20.1
On Thu, Aug 22, 2013 at 03:32:38PM +0200, intrigeri wrote: Hi, Core developers: please volunteer for the test day, or make it clear that you can't make it ASAP, thanks! Count me in for the 09/18 release tests! bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
Hi, Branch: feature/More_uniq_built_iso_name_in_jenkins Ticket: #6248 (https://labs.riseup.net/code/issues/6248) 64f39f1 Use more unique iso name when building from jenkins. This commit introduces more unique iso name when building in jenkins so that we will be able to keep several isos per day in our CI environment. Details are in the ticket. I've extensively tested it, by building fake 0.19 iso (modifying debian/changelog and /etc/amnesia/version's date) and playing with the $JENKINS_URL env variable. This branch is based on stable and should be merged in every branches currently build in our jenkins setup: experimental, testing and devel. The devel branch should probably get merged again into feature/wheezy too so that it gets the benefit of this patch. Thanks. Bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
On Tue, Sep 03, 2013 at 08:03:48PM +0200, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (02 Sep 2013 10:59:48 GMT) : Branch: feature/More_uniq_built_iso_name_in_jenkins Ticket: #6248 (https://labs.riseup.net/code/issues/6248) 64f39f1 Use more unique iso name when building from jenkins. This commit introduces more unique iso name when building in jenkins so that we will be able to keep several isos per day in our CI environment. Yeah :) [...] All remarks have been corrected in a commit pushed in the same branch. Didn't want to debate :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
On Wed, Sep 04, 2013 at 09:02:19PM +0200, intrigeri wrote: (seems like I haven't sent this email yet, oh.) berta...@ptitcanardnoir.org wrote (03 Sep 2013 19:04:38 GMT) : All remarks have been corrected in a commit pushed in the same branch. I've tentatively merged this into my local stable, devel, experimental feature/wheezy, then pushed *to lizard*, and as a result the ISO images are named just as usual. Please test *live* on Jenkins (e.g. by pushing an experimental branch there) for the next iteration :) Perhaps we need to export JENKINS_URL somewhere, so that auto/build knows about it? Exactly, in the build process, the `build-tails` script sudo call drops most of the environment variables. Fix has been commited in the dedicated branch and merged into the experimental one (on both lizard's and origin's repo). Build on jenkins resulted in a correct iso naming: http://nightly.tails.boum.org/build_Tails_ISO_experimental/ Local build also named correctly the resulting iso. Ready to be merged into the remaining branches for a final review round. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/More_uniq_built_iso_name_in_jenkins
On Fri, Sep 06, 2013 at 08:30:45PM +0200, intrigeri wrote: berta...@ptitcanardnoir.org wrote (06 Sep 2013 16:15:41 GMT) : Ready to be merged into the remaining branches for a final review round. I was going to merge into the other branches and push to lizard, but I'll let you turn the (obviously temporary) message of commit 500710 into something meaningful first :) Jeez, i didn't thought this commit msg was so important that it required to rewrite the whole history. It's done though, but means that the experimental and feature branches histories are heavily rewritten. Please hard reset on $ORIGIN. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Release schedule for Tails 0.20.1
On Mon, Sep 09, 2013 at 01:27:42PM +0200, intrigeri wrote: Needless to say, with Tor 0.2.4 in and an updated Linux kernel, it would be most welcome if everyone who can gives it a try and makes sure their usecases still work as good as before. I've missed the review'n'merge window even if I wanted to, I'll build and begin to test this RC ASAP, hopefully. :) anonym, will you be able to run the automated test suite? I'm not confident enough on my own setup here to step up on that task, but hope to be able to fire it up for the next releases, now that the Jenkins front is closed to a milestone. But I'm also still tackling up with other needed stuffs (like emails), so... Bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/linux-3.10.11
On Sun, Sep 15, 2013 at 07:07:06PM +0200, intrigeri wrote: Hi, = please review feature/linux-3.10.1, and merge it into devel. Reviewed, tested successfully, so merged into devel. Congrats! bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review'n'merge feature/Sign_jenkins_builds_artifacts
Hi, The feature/Sign_jenkins_builds_artifacts branch add the ability to our build-tails script to automatically sign the build result when run in a jenkins environment. It has been merged into the experimental branch of lizard's Tails repo, and tested on jenkins.tails.boum.org. The result can be checked on nightly.tails.boum.org. Ticket : #6267 - Add checksum signing ability to the Tails build script Commit : 31be69f Please merge this branch in experimental, devel, stable, testing and feature/wheezy if happy with it. This change goes together with two changes in our puppet modules: A new one has been created to deploy the gnupg keyring in our autobuilder VM on lizard, and has been reviewed already by intrigeri. Another change in our puppet setup is related to our rotation script, which needed to be aware that it needs to take care of two new files (*.iso.shasum and *.iso.shasum.asc). This last change can be checked in our main puppet git repo for lizard Ticket : #6268 - Adapt the Jenkins artifacts rotation script Commit : fdecb95 and 6eef9d6 If happy with them, the reviewer can also push the new signing key on the keyserver. It has already been signed by our main signing key. If not, I can take care of that. Thanks bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/Sign_jenkins_builds_artifacts
On Sun, Sep 29, 2013 at 01:36:28PM +0200, intrigeri wrote: berta...@ptitcanardnoir.org wrote (28 Sep 2013 09:22:16 GMT) : Please merge this branch in experimental, devel, stable, testing and feature/wheezy if happy with it. I'd be happy too, but the branch is based on devel, so I can't merge it into stable. Please rebase on stable, and reassign the ticket to me. Oooch, you're right. I've just force updated the branch for it to be based on the stable one. Thanks for the reminder. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/same-startpage-custom-url-as-tbb
On Sat, Oct 12, 2013 at 12:39:37PM +0200, intrigeri wrote: Hi, this branch makes Tails use the same custom Startpage search URL as the TBB. This disables the new broken family filter, that e.g. is being assholish about LGBT stuff. See https://trac.torproject.org/projects/tor/ticket/8839 for details. I've tested this for English and all languages we provide a localized Startpage engine for, and it now does return results that would be hidden otherwise. No ticket, candidate for 0.21. Tested and reviewed, now merged in devel. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/Debian-proposed-updates
On Sat, Oct 12, 2013 at 02:31:10PM +0200, intrigeri wrote: Hi, the next point release for Squeeze (6.0.8) is scheduled for Saturday October 19th. We'll have built 0.21~rc1 already at this point, so if we want it to have a set of packages as close as possible to the final ISO's, then we need to enable squeeze-proposed-updates before building our RC. So, please review'n'merge feature/Debian-proposed-updates before we freeze 0.21. I'll revert it on October 20th, once the packages have migrated to the regular Debian oldstable repositories. Reviewed, tested (read buildlogs, start it and look at the apt conf as well as the system behavior) and merged into devel. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge test/fix-detection-of-used-display
On Mon, Sep 30, 2013 at 11:41:35AM +0200, intrigeri wrote: Hi, the test suite never starts on my new test suite VM since it's looking for a file that never appears. Fixed in branch test/fix-detection-of-used-display. Please review and merge into devel. Tested, updated and merged into devel. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge (again) security/vidalia_in_its_own_user
On Fri, Oct 18, 2013 at 03:03:42PM +0200, intrigeri wrote: Hi, Branch: security/vidalia_in_its_own_user (no APT stuff) No ticket. Please review and merge into testing (and devel) in time for 0.21 final. Tested, merged and pushed into devel and testing. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/linux-3.10.11
On Sun, Oct 20, 2013 at 02:29:51PM +0200, intrigeri wrote: intrigeri wrote (20 Oct 2013 11:45:54 GMT) : Actually, please merge feature/linux-3.10.11 into testing only, and please merge feature/linux-3.11-1 into devel (it his feature/linux-3.10.11 in, plus the revert, plus the switch to 3.11-1 that unbreaks the devel build). Hmm, actually not, feature/linux-3.11-1 can't be built yet. So, back to my original request: please merge feature/linux-3.10.11 into devel testing. Sorry for the noise. Then after booting and shutting down a test iso, I merged and pushed it in devel and testing. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/world-readable-persistence-state-file
On Fri, Oct 18, 2013 at 02:19:13PM +0200, intrigeri wrote: Hi, * branch: bugfix/world-readable-persistence-state-file, both in the tails-greeter and main Git repositories (+ APT) * ticket: https://labs.riseup.net/code/issues/6374 This branch fixes #6374, that was discovered while testing 0.21~rc1 today. Please review'n'merge in time for the final 0.21. Tested by live patching a 0.21~rc1, and also in a build from experimental. Tested in a VM upgrading a 0.20.1 usb with an iso of this branch, I get the error message that t-p-s can't delete the persistent partition when it is activated. Merged and pushed. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/perl5lib
On Wed, Nov 13, 2013 at 04:40:48PM +0100, intrigeri wrote: Hi, I'll try to avoid pushing a huge review'n'merge request about incremental updates at the last minute before the 0.22 freeze, so here we go for a first batch. That's very kind of yours, and I must say that I'm impressed by the transition work you've slightly done! feature/perl5lib extracts some code from t-p-s into a new package called tails-perl5lib, that provides Perl libraries that other Tails-specific code may want to use. This refactoring was needed to make tails-iuk (incremental updates software) share code with t-p-s. Candidate for 0.22, no ticket. Branches: * t-p-s feature/extract-code-to-perllib * Tails feature/perl5lib * an APT suite to merge Note that the t-p-s branch also contains Andres fixes for the persistent volume deletion warning (#5888), and it also supersedes my review'n'merge request for bugfix/persistence-cleanups. This is on purpose, so that we'll save a review'n'merge pass or two. I've build this branch, and installed a Tails usb stick from this Iso, created a persitent partition and ensured it worked. Then I deleted it. I'm not sure I understood all perl's arcanes in there, but still 1) tests didn't show regressions from what I saw 2) changes seem consistent from what I get In the end I merged it in the three mentioned repos. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Testing feature/ff24 [Was: Release schedule for Tails 0.22]
Hi, On Fri, Nov 15, 2013 at 10:16:48AM +0100, intrigeri wrote: Kill Your TV wrote (14 Nov 2013 21:26:22 GMT) : As reported in IRC, I tested using KVM [...] Testing this branch on commit 0f5eab28. It seems that the unsafe browser now works. I can use it to navigate on the web. It also refuses to work when I configure it to use polipo, like it is supposed to do. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review whisperback:a4dfd008
Hi,
On Sun, Nov 24, 2013 at 12:51:10PM +, Alan wrote:
Please review the following commit in whisperback master (yes, I know
it's bad to work on master...)
commit a4dfd008a9b11c9f6d41d4e25de891c21af6d235
Author: Tails developers amne...@boum.org
Date: Tue Oct 29 14:15:05 2013 +
More generic IP and MAC sanitizing regexp
This fixes #6391
diff --git a/whisperBack/utils.py b/whisperBack/utils.py
index 1a62a45..2adc504 100644
--- a/whisperBack/utils.py
+++ b/whisperBack/utils.py
@@ -159,11 +159,11 @@ def sanitize_hardware_info(log_string):
log_string)
# IPs
-log_string = re.sub(r'\([\d]{1,3}\.){3}[\d]{1,3}\',
+log_string = re.sub(r'([\d]{1,3}\.){3}[\d]{1,3}',
r'[IP REMOVED]',
log_string)
# MAC addresses
-log_string = re.sub(r'\([0-9a-fA-F]{2}:){5,}[0-9a-fA-F]{2}\',
+log_string = re.sub(r'([0-9a-fA-F]{2}:){5,}[0-9a-fA-F]{2}',
r'[MAC REMOVED]',
log_string)
return log_string
That sound relevant to me, so I guess we're good to go with this change.
bert.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Release schedule for Tails 0.22
Hi, Given Alan is in a review'n'merge hell of a mood, I'm committing to the following: On Sun, Nov 24, 2013 at 12:49:35PM +, Alan wrote: Hi, intrigeri wrote (24 Sep 2013 17:51:54 GMT) : * feature/incremental-upgrades: I should have a beta ready to be reviewed'n'merged by Friday night. Yeah, last minute. Given it is self-contained, disabled by default, and does not impact the rest of Tails, I'll feel free to merge it so that it lands into the RC. Someone will still need to review it at some point, though. Any taker? I should be available at that time, and will do so to review this And I have something to add (cf upcoming email): commit a4dfd008 in whisperback master (yes I should have done a topic branch). Done. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/incremental-upgrades
Hi, On Thu, Nov 28, 2013 at 06:26:51PM +0100, intrigeri wrote: Hi, I believe the incremental upgrades stuff is now in good shape for beta testing. The thing is, it's a bit complicated to actually test this *before* this branch is part of a release (candidate). I think the best course of action is: 1. Someone does the code review, makes sure the changes are self-contained enough not to break anything else, and merges into devel in time for the 0.22 freeze. No testing at this stage. (It's late, just as planned and announced previously. bertagaz volunteered to review'n'merge it already.) I did, and prepared this cold winter-like night to read your code. Expect a merge tonight or tomorrow in the morning if everything goes well. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/incremental-upgrades
On Thu, Nov 28, 2013 at 06:26:51PM +0100, intrigeri wrote: Hi, 1. Someone does the code review, makes sure the changes are self-contained enough not to break anything else, and merges into devel in time for the 0.22 freeze. No testing at this stage. (It's late, just as planned and announced previously. bertagaz volunteered to review'n'merge it already.) Ok, didn't see any problems in there so I merged it, in git and APT. Updated the tickets too. I hope my lame perl understanding didn't miss something in iuk's code, but maybe this review wasn't needed. bert. ___ 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] Tor Browser branding in Tails?
On Mon, Dec 02, 2013 at 09:50:15AM +0100, intrigeri wrote: Hi, anonym wrote (01 Dec 2013 23:51:06 GMT) : I'm worried that this may fail several scenarios (and even complete features) in the automated test suite. Does the new branding also change the icon in the window title? Please see features/images/IceweaselRunning.png -- does that part of the new Iceweasel/Tor browser still look the same? (Sorry, I don't have time (or the bandwidth) to check this myself right now.) The window titlebar icon doesn't change so I hope it does not break the test suite. bertagaz will be running it today, so we'll soon know. It doesn't. The unsafe browser feature/image does though. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/back-to-linux-3.10 [Was: Fix sdmem on Intel graphic hardware, please review]
On Mon, Dec 02, 2013 at 02:43:21PM +0100, intrigeri wrote: Hi, intrigeri wrote (01 Dec 2013 19:19:51 GMT) : Done. Didn't see issues when building and starting it. Plus it had lot of tests lately. So merged into testing and devel, both in git and APT. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/monkeysign
On Fri, Dec 06, 2013 at 08:39:58PM +0100, intrigeri wrote: Hi, please review'n'merge feature/monkeysign into devel (candidate for 0.23). Ticket: #6338 Merged even if this might need a bit of documentationi though, as monkeysign errors out with a backtrace if one don't use the --no-mail option, as there is no /usr/sbin/sendmail in Tails. But the signature is added to the key still. When using the --no-mail option, it outputs quite a lengthy mail, with mime headers and all, but that isn't really possible to use it in claws-mail, as you can't edit the email source. Best is probably to just paste the pgp public key bloc part of it into a new mail. It's an enhancement, as it automates the key retrieval and signing process, but might need some more to be really usable by monkeys. Bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/unsafe-browser-vs.-FF24
On Wed, Dec 11, 2013 at 03:15:32PM +0100, intrigeri wrote: Hi, bugfix/unsafe-browser-vs.-FF24 fixes #6479 (Unsafe Browser cannot connect to the Internet) for me. Please review'n'merge into testing and devel. Depending on how we reschedule 0.22 or not, this will go into 0.22 or 0.22.1. bertagaz volunteered to take care of it. Merged. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbutton-1.6.5.1
On Wed, Dec 11, 2013 at 03:13:45PM +0100, intrigeri wrote: Hi, feature/torbutton-1.6.5.1 brings the latest Torbutton in. It fixes a bug in the New Identity feature, that we lack, but I expect we'll need an even newer version anyway for 0.22.1 or something, so let's merge incrementally and detect issues ASAP. Please review'n'merge into devel (not testing, IMHO it's not worth it). bertagaz volunteered to take care of it. Merged into APT, but git refused to merge it in devel, already up-to-date it says, surprisingly. :) Shall I merge into testing and experimental too, now that the release has been done? bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/tor-0.2.4-is-stable [Was: Build broken, stay tuned (or try bugfix/tor-0.2.4-is-stable)]
On Fri, Dec 13, 2013 at 11:50:06PM +0100, intrigeri wrote: Hi, intrigeri wrote (13 Dec 2013 13:38:02 GMT) : all our branches currently fail to build since deb.tpo's tor-0.2.4.x-squeeze APT source was deprecated, as Tor 0.2.4.x was declared stable. = please review bugfix/tor-0.2.4-is-stable and merge it into stable and devel. No ticket. This has been merged together with the bugfix/use-our-own-sqlite which contained it. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/use-our-own-sqlite
On Sun, Dec 15, 2013 at 04:31:17PM +0100, intrigeri wrote: Hi, Mike Homey has made his last Iceweasel package use some in-tree libraries instead of the system one, and hence has removed some of these libraries from mozilla.d.n's squeeze-backports repository. Too bad we need these libraries at ISO build time. So, I've imported the .deb's we need (sqlite, nss, nspr) into our own APT repository. This will be useless once we base our own Iceweasel on the last official one that was out today (WIP), but this fixes the Tails ISO build for the time being. Please review'n'merge bugfix/use-our-own-sqlite (sic) into stable, devel and experimental. I've not done a full build yet, but at least it goes further than the stage at which it used to fail. You were right, with this branch the build works again. Merged in Git and APT. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/monkeysign
On Tue, Dec 17, 2013 at 10:06:53AM +, sajol...@pimienta.org wrote: intrigeri: Merged I push a minor documentation fix with commit f0762cd. Shall I merge it myself? That seems minor and relevant, I guess you can. :) even if this might need a bit of documentationi though, as monkeysign errors out with a backtrace if one don't use the --no-mail option, as there is no /usr/sbin/sendmail in Tails. But the signature is added to the key still. When using the --no-mail option, it outputs quite a lengthy mail, with mime headers and all, but that isn't really possible to use it in claws-mail, as you can't edit the email source. Best is probably to just paste the pgp public key bloc part of it into a new mail. Doesn't piping it to Mutt work? monkeysign currently being command-line only, I was thinking more of Mutt users than Claws Mail's ones when I thought we wanted this in Tails. Hopefully this will change at some point. I've tried that, but couldn't find a way to have it working. That was a short session though, I might have missed something. Note that monkeysign also includes and graphical tool for fingerprint scanning: monkeyscan; with QR codes and all :) Which doesn't work in Tails, as we don't ship the recommends of monkeysign (python-qrencode, python-gtk2, python-zbar, python-zbarpygtk). Not sure if it is that usefull in Tails' usecase though (like, not running on a mobile platform). Regarding the need for documentation, well, I don't think this would be a good use of our time. I expect that the kind of public that's addressed by a command-line only piece of software will know what to do with its output and manpage. Writing monkeysign documentation for newbies seems very hard a task to me, and I doubt more than a handful of people would benefit from it. If someone wants to make monkeysign better suited for other kinds of users, IMHO they should instead write a GUI for it, or (even better) integrate it into Seahorse, or something. Agreed. I admit it is sometimes a bit blurry but our position was to only document on our website things that were specific to Tails (see the Pidgin and OTR documentation for example). So writing a tutorial on using monkeysign is out of scope. I admin that some pieces of software are documented beyond this requirement already (for example KeepassX) but it is also much more advertised and a key feature than monkeysign ever will be. I tried to improve a bit on this by improving the visibility of the list of included software from the documentation index. That's commit e8a33f6 in master. Agreed. That sounds relevant regarding our actual documentation. Having given it a bit of tries, I believe monkeysign at the moment is only for power users, they should be able to get it by themselves. If we want it to be usable for everyone, I think we'd have to work a bit with upstream so that it integrates a bit better. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [Was: Please test incremental upgrades (from 0.22~rc1 to 0.22~rc2)]
On Tue, Dec 17, 2013 at 06:13:41PM +0100, intrigeri wrote: Hi, I've just released Tails-IUK 0.13, that fixes all coding tasks left for phase three. I'm giving it a manual testing session as we speak. Please use this version (or later) for any further testing, documentation work and comments. If you want to test the incremental upgrader itself, install Tails 0.22~rc2, set an admin password, retrieve the latest tails-iuk package from our APT repo (http://deb.tails.boum.org/pool/main/t/tails-iuk/, or preferably by adding our feature-incremental-upgrades-integration suite to your APT sources), install it and run: $ tails-upgrade-frontend-wrapper Given sajolida agreed and nobody objected, I'm now targetting to ship Tails 0.22.1 with incremental upgrades enabled by default (that's the stuff in feature/incremental-upgrades-integration), and I've flagged the remaining phase three tickets accordingly: https://labs.riseup.net/code/issues/6014 Yay. Congrats, I'm excited to see this coming in the wild! Next steps: * bertagaz reviews feature/incremental-upgrades-integration (but does not merge it yet) and hopefully ACK's it; ETA? I'll try to do that tomorrow if I have remaining time after the other review'n'merge I have planned to do, but that sounds unlikely, so if not I should be able to do that before the end of the week. I wanted to test this incremental upgrade feature since a while anyway. while, in parallel: 1. sajolida writes doc (based on the feature/incremental-upgrades-integration branch!) and proposes various phrasing changes to the UI 2. I update the code accordingly. And then, we merge feature/incremental-upgrades-integration, I'll tag a 0.22.1~beta1 or something, and I'll prepare a test IUK so that anyone can try the latest stuff in realistic settings. And hopefully the Transifex situation improves soon enough... Sounds good, did I miss anything? You have a far better idea of the situation than me, so I'd say you're probably right. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/monkeysign
On Tue, Dec 17, 2013 at 08:27:57PM +0100, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (17 Dec 2013 11:44:11 GMT) : Doesn't piping it to Mutt work? monkeysign currently being command-line only, I was thinking more of Mutt users than Claws Mail's ones when I thought we wanted this in Tails. Hopefully this will change at some point. I've tried that, but couldn't find a way to have it working. That was a short session though, I might have missed something. Ah crap, so I've really had you merge something that is *far* from being usable out-of-the-box. Still, I think it makes sense to ship it, at least for a while, for the reasons I've given previously. Yep, that's why I merged it. I've just reported this problem upstream. Being the one that raised the issue. I could have done that myself after our discussion. Credits, etc... Note that monkeysign also includes and graphical tool for fingerprint scanning: monkeyscan; with QR codes and all :) Which doesn't work in Tails, as we don't ship the recommends of monkeysign (python-qrencode, python-gtk2, python-zbar, python-zbarpygtk). My intent was to ship these packages in Tails, and it was a mistake from my part to act as if we installed Recommends by default: before I uploaded these packages to Debian backport, I've verified that each of these packages as available in Squeeze. I'll submit a branch that installs all that stuff, as it was part of what convinced me it was worth shipping monkeysign at all. Ok, I'll stay tuned, but might not be able to test this fancy feature *that* extensively (meaning I'll probably just check that the UI starts). Not sure if it is that usefull in Tails' usecase though (like, not running on a mobile platform). Most laptops have a camera these days. Making fingerprint verification easier is (part of) what makes monkeysign potentially more relevant than caff. Yeah, sorry I have hard time thinking about people showing themselves their laptop that way, but why not. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/monkeysign
On Wed, Dec 18, 2013 at 12:26:32AM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (17 Dec 2013 22:29:20 GMT) : I've just reported this problem upstream. Being the one that raised the issue. I could have done that myself after our discussion. Credits, etc... I felt it was my responsibility to follow-up on the problems that go with a branch I've submitted. I'm sorry. Ah, my bad, didn't think about it that way, and it makes sense. Nevermind then. This confirms that we really need to get you a spare laptop for testing :p Hmm, well, make it two then, as my computer actually don't have a camera. :) I'll think about it, and if I don't find a way to test it, I'll ask for someone else to take over. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [
On Tue, Dec 17, 2013 at 08:36:29PM +0100, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (17 Dec 2013 18:10:18 GMT) : Congrats, I'm excited to see this coming in the wild! :) ... and I'm scared to discover the remaining bugs we've missed :] Next steps: * bertagaz reviews feature/incremental-upgrades-integration (but does not merge it yet) and hopefully ACK's it; ETA? I'll try to do that tomorrow if I have remaining time after the other review'n'merge I have planned to do, but that sounds unlikely, so if not I should be able to do that before the end of the week. I wanted to test this incremental upgrade feature since a while anyway. IMHO this review (without merge) is higher-priority than the other ones you have on your plate (namely: #6477 and #6496). Ok, then I did test it the way you proposed, and it works great. So I've marked the ticket QA-Pass, and assigned it to sajolida. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review'n'merge test/rjb-migration
Hi, Now that a more recent libvirt containing patches to support the removable flag for USB devices has been uploaded to Wheezy-backports, I've updated the test/rjb-migration feature branch so that installation now is easy for anyone running Wheezy. Test process of this branch should be to start from a fresh Wheezy installation (on bare metal or in a VM), and install all the necessary packages, following https://tails.boum.org/contribute/release_process/test/setup, and then run the test suite. Failures that might appear should be related to outdated scenarios or steps rather than libvirt or rjb problems. If happy with it, please merge it into devel and experimental. Tickets to take care of should be #6399 and #6314. Congrats goes to anonym, who did great work for this migration. I just tested it works and updated the documentation. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge test/rjb-migration
On Wed, Dec 25, 2013 at 08:36:57PM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (24 Dec 2013 11:39:27 GMT) : and then run the test suite. I get the same error you had a week ago or so: Call to virDomainCreateWithFlags failed: unsupported configuration: ich9-usb-ehci1 not supported in this QEMU binary (Libvirt::Error) How did you fix this? If I'm the second one to hit it, perhaps this should be documented? To be honest, it did get fixed almost by itself. I just played a bit manually with virsh to create the VM while trying to understand the issue, and at some point it did worked. As I didn't changed anything really, in the host configuration nor in the VM one, I assumed I did something wrong at first and there were in fact no issue at all. I also did a search on Debian's BTS and qemu/libvirt sources to find reports or changes that might be related, but found nothing. Did you restart the computer/VM where you installed the test suite after having done so? I remember I did, that might be why I had it to work. If you get this issue too, sure it needs to be documented. But we have to understand it first. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge test/rjb-migration
On Fri, Dec 27, 2013 at 01:16:05AM +0100, intrigeri wrote: intrigeri wrote (26 Dec 2013 18:17:21 GMT) : I don't want to merge this branch with so many failing tests, as one expected failure (e.g. due to a missing image update) may very well hide other issues that might be caused by the migration to RJB. So, I've started fixing every test case I could. Doing this in the test/rjb-migration branch too, even if it doesn't 100% belong here, because IMO this goes with merging this branch. In the state where I've brought test/rjb-migration today, all tests now pass but: * the USB -related tests. Reported as #6537. I'm going to try and fix those now. I believe I've done what #6537 was about, but this feature still fails for me a bit later (#6539). I'll try re-running it entirely, but well, seeing the installer stuck at various stages of the process is no news, and that's why we have never removed these steps from the manual test suite yet. So IMO this is not a blocker. * the Windows should appear like those in Microsoft Windows XP scenario: in 0.22, the browser's title bar displays the Iceweasel icon, instead of the IE one, so it looks like the Windows camouflage script misses an update for FF24. Reported as #6536, will try to fix in time for 0.22.1 as it's a regression. I'm testing a fix for this. Once I'm done with validating this part of the test suite, I'll ask bertagaz to review all the commits I've added on top of what he submitted, and to merge the branch. Stay tuned, we're getting close :) /me is very happy to be able to run this test suite in good conditions, finally! I am too, and find it is running quicker than when using Jruby. I intended to start to fix the outdated scenarios in another branch, as when I asked for the merge, the rjb test suite was running as good (or bad, depends how we see) as the previous Jruby implementation, failing at the same places. So I thought there were no regressions, and the branch was ok for a merge. But you spend time doing it (and having fun hacking it seems), and it's great. I'll reserve some time to test it when you'll send your review'n'merge. Just one word to sum up my feelings: hurray! :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Release schedule for Tails 0.22.1
On Sun, Dec 29, 2013 at 04:27:03PM +0100, intrigeri wrote: Hi, here's an update on the 0.22.1 release process. See the bottom part, that expects answers from core developers. intrigeri wrote (08 Dec 2013 17:19:51 GMT) : I'm prepared to make exceptions to our usual stable merge rules for some edge cases: * upgrading Linux to 3.12, to fix security issues in 3.10; this is blocked by #6460 (memory wipe broken with 3.11+); this is high priority IMHO. Any taker? I've made some progress (more failed attempts to fix it), and the ticket has more ideas to be tried. It would be really great if someone took it over from here. I understand that, but can't promise much myself on it at the moment. My plate is already quite filled, but if I find some spare time, I'll have a look, even if I feel like it's a quite over my capacities. * enabling incremental upgrades by default, if testing is successful enough, and if fixing most important problems is possible with minor changes Looks like this will happen: I expect we can merge feature/incremental-upgrades-integration very early in January :) Yay! Core developers: ASAP, please volunteer for the test days, or make it clear that you can't make it, so we can reschedule slightly if needed. Ping? I'm good and should be available for the planned test days. Also, the freeze is coming soon, quite a few bugfix branches are pending for review'n'merge, and there are more to come soon (Torbutton and Iceweasel prefs updates). bertagaz said he would take care of these ones today: * #6496 (Drop sqlite3, nss and nspr backports from our APT repository) * #6477 (getTorbuttonUserAgent differs from browser user-agent) I'll finish these tonight, already spend my afternoon testing your test/rjb-migration branch enhancement. ... but those other ones need a reviewer: * #6478 (Keyboard shortcuts use QWERTY mapping instead of AZERTY on French keyboard) * #6536 (Windows camouflage script does not set the browser icon to IE's one anymore) If there is no takers, I should be available to review them before the merge, but I have to admit I'd be glad not to do so: I feel like spending my time reviewing those times :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge test/rjb-migration
On Fri, Dec 27, 2013 at 07:36:15PM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (27 Dec 2013 09:36:32 GMT) : Just one word to sum up my feelings: hurray! :) :) The test suite is now entirely green for me, with the two known exceptions that are documented (git grep XXX -- features). Please review my changes and merge it into devel if it looks good! Tickets that will go away: #6314, #6399. Done, merged into devel, haven't seen the test suite in such a good shape since a long time, congrats! 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. Shall we just forget about it and close #6400 as rejected? Thoughts? 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 particular, I'd like to hear what anonym thinks of it. Me too. :) bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1
On Mon, Dec 16, 2013 at 01:42:34PM +0100, intrigeri wrote: Hi, this is a follow-up, with a better fix, to the quick fix introduced by bugfix/use-our-own-sqlite. The details are on the ticket: https://labs.riseup.net/code/issues/6496 When merging this branch, please drop the packages listed on the ticket from our APT repo. Then, we can 1. drop the corresponding temporary APT pinning rules since they won't be needed anymore; 2. take care of #6497 (I'm on it). Assigned to bertagaz for review, candidate for 0.22.1. Done, branch merged in devel (git and APT repo), packages removed from the APT repo, in the devel suite. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/6536-IE-icon-in-Windows-camouflage-mode
On Mon, Dec 30, 2013 at 12:55:39AM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:37:53 GMT) : Candidate for 0.22.1 = please merge into stable and devel. While testing other branches, I tested this one too, so I merged it too. Cool! It seems you forgot to merge into stable. Oh right, will do so. Nice catch! Our automated test suite catched it! :) No idea why this was not detected when it was run for 0.22, but oh well, I guess some earlier step was broken, and we did not do the rest of the tests manually for some reason. Yeah, I think I did the tests manually in the end, but didn't notice that the icon wasn't the right one. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbrowser-24.2.0esr-1+tails1
On Mon, Dec 30, 2013 at 12:53:30AM +0100, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (29 Dec 2013 23:34:43 GMT) : Assigned to bertagaz for review, candidate for 0.22.1. Done, branch merged in devel (git and APT repo), packages removed from the APT repo, in the devel suite. Great! That's a candidate for 0.22.1, so please merge into stable too (and do the APT thing too). If you prefer, I can do it. Done. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/torbutton-1.6.5.3 (#6566)
On Sat, Jan 04, 2014 at 01:46:23PM +0100, intrigeri wrote: Hi, the usual Torbutton upgrade before we freeze, brings only one code change (clean up the temporary NoScript permissions on New Identity) that does not affect us (we don't provide the New Identity feature), so that's just for the sake of easing bug reporting upstream etc. It passes the automated test suite (torified_browsing, unsafe_browser features). Candidate for 0.22.1 = please merge into stable and devel. No commits, only an APT merge to do. Assigned to bertagaz, but if e.g. Alan wants to do it, I'm sure bertagaz won't mind. Done, merged in APT into devel and stable. Merged in git into devel, but wasn't able to do so in stable, as the branch don't contain any changes. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/dont_autostart_iceweasel + test/dont_autostart_iceweasel
On Thu, Jan 09, 2014 at 11:52:20AM +0100, intrigeri wrote: Hi, intrigeri wrote (09 Jan 2014 10:26:11 GMT) : I patched it so it needs another review before merging. Sorry... I'll take care of it. Updated the ticket. Done and merged. Now, what about the test/dont_autostart_iceweasel branch? I'm on it now. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/dont_autostart_iceweasel + test/dont_autostart_iceweasel
On Thu, Jan 09, 2014 at 05:53:49PM +0100, berta...@ptitcanardnoir.org wrote: On Thu, Jan 09, 2014 at 11:52:20AM +0100, intrigeri wrote: Hi, intrigeri wrote (09 Jan 2014 10:26:11 GMT) : I patched it so it needs another review before merging. Sorry... I'll take care of it. Updated the ticket. Done and merged. Now, what about the test/dont_autostart_iceweasel branch? I'm on it now. Finished, works like a chaem. Merged. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [review'n'merge:1.3] bugfix/8082-remove-PulseAudio-warning
Hi, On Mon, Oct 13, 2014 at 12:58:38PM +0200, intrigeri wrote: Hi, please merge bugfix/8082-remove-PulseAudio-warning into devel, for Tails 1.3. Merged, congrats. bert. ___ 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] Build failed in Jenkins: build_Tails_ISO_experimental #1457
Hi, On Tue, Dec 23, 2014 at 06:29:31PM +, Alan wrote: These are the result of review and merges that built fine on my machine. I don't understand where is the problem... Network troubles as I read it : Translation-en 404 Not Found Fetched 24.5 MB in 40min 47s (10.0 kB/s) W: Failed to fetch http://ftp.us.debian.org/debian/dists/unstable/main/i18n/Translation-en 404 Not Found W: Failed to fetch http://ftp.us.debian.org/debian/dists/unstable/non-free/i18n/Translation-en 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. P: Begin unmounting filesystems... Command exited with non-zero status 100 ___ 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] Lizard services outage
Hi, To prepare Lizard to host its new shiny hardware, it needs to get its kernel upgraded to the Wheezy-backports one to support such new bones. But the upgrade seems to raise troubles in the virtual network firewalling, so expect outages of Lizard's services today while I'm trying to debug it and get it back on the net. bert. ___ 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] Automated builds specification
Hi, On Mon, Jan 19, 2015 at 08:14:55PM +0100, bertagaz wrote: On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote: bertagaz: 0. We might also want a mechanism for devs to pro-actively state they want to keep their branches being build even if the last commit was older than the last release. IIRC If I understand correctly, adding a dummy commit would bring back my branch in the set of branches that are automatically built. So maybe we don't need a dedicated mechanism handle those rare cases. That's the idea, having a timestamp file that would be use for this dummy commit. But it comes for free, sure. :) I had Alan having a look at the blueprint too, she fixed some issues in the scenario and added one for the future. The blueprint has been updated with some proposalsi for each question. If you want to consider them, or propose another one, please have a look. bert. ___ 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] AdBlock Plus in Tails' Tor Browser
Hi, This answer might pop up late now that #8665 is in Ready for QA state, still it might bring new questions. Sorry for that. On Fri, Jan 23, 2015 at 12:49:10AM +0100, intrigeri wrote: mercedes508 wrote (22 Jan 2015 17:54:53 GMT) : And I'm wondering how important the fingerrint issue is, considering how easy it is to change it (e.g. by enlarging the browser window), I'm more concerned about behavioral differences (compared to the Tor Browser) that we ship by default (XXX: we haven't summed up what they were recently, by the way), than about bits of fingerprinting information that every Tor Browser user, be it upstream or within Tails, can individually choose to leak. I'm tempted to propose that on this topic, just like for resizing the browser: * we provide safer defaults; * we let users manually opt-in if they want to block ads and diverge from the Tor Browser anonymity set. (Of course the current behaviour for resizing the window is not a good implementation of opting-in to diverge, as the security consequences of this action are completely non-obvious to the user. There are tickets in the right place about asking for a confirmation in this case, I think.) [And I'm starting to wonder if this wouldn't be better to put that in the upcoming Tor Browser's security slider. At first glance: Then if we go for safer defaults, I agree Ad Block+ would be more close to NoScript in term in UX and fingerprinting. We could integrate Ad Block+ the same way: installed but disabled by default. That sure would be something to discuss further with the TorBrowser people. We could help them to upstream our Ad Block+ rules update process. Shall we engage a discussion about this? That's https://trac.torproject.org/projects/tor/ticket/9387 block ads, not JS block neither ads nor JS block JS, not ads (default) but once you block JS, your fingerprint is so much different anyway that blocking ads on top don't make a big difference, so possibly this would be better, although awkward and then perhaps confusing for users: block ads, not JS block neither ads nor JS block JS and ads Food for thought.] I'm not even sure we need to decouple both, but why not. It might be hard to fit in the TorLauncher slider though if we want to push this forward. Bert. ___ 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.3] feature/7999-Vietnamese-input
On Sun, Nov 30, 2014 at 11:07:31AM +0100, intrigeri wrote: this branch adds support for Vietnamese input via the IBus Unikey engine. Please review'n'merge into devel for 1.3. I'm not much comfortable with the workaround of Debian bug #714932, I think the patch lying in this bug report would deserve a NMU, but that's out of this branch and review, so I merged it into devel after testing it. bert. ___ 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] Sandboxing Tor Browser: strategy for tracking upstream AppArmor profile
On Wed, Feb 04, 2015 at 12:10:31PM +0100, anonym wrote: On 04/02/15 11:36, intrigeri wrote: [...] Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. I'm convinced and have nothing more to add than well done!. :) I do too. That sounds more bullet-proof than the first iteration. bert. ___ 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.3] bugfix/quote-wrappers-arguments (#8830, #8603)
Hi, On Mon, Feb 02, 2015 at 12:27:37PM +0100, intrigeri wrote: Hi, sajolida discovered a bug in the way some of our torifying wrappers handle passed-through arguments. This branch fixes that bug, and adds automated tests for some of it. Note that one of these wrappers (connect-socks) affects e.g. Git cloning over SSH, which should be tested when reviewing #8680 too, so I've assigned this new merge request to bertagaz (who took #8680 a week ago) for review. bertagaz, if that's not OK with you, please de-assign yourself. Tested by hand, wget and git works fine, so merged into devel. Congrats to have found and fixed this. bert. ___ 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] Automated builds specification
Hi, On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote: bertagaz: 0. We might also want a mechanism for devs to pro-actively state they want to keep their branches being build even if the last commit was older than the last release. IIRC If I understand correctly, adding a dummy commit would bring back my branch in the set of branches that are automatically built. So maybe we don't need a dedicated mechanism handle those rare cases. That's the idea, having a timestamp file that would be use for this dummy commit. But it comes for free, sure. :) bert. ___ 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] Automated builds specification
Hi,
Some thoughts and questions, raised in parts from past IRL discussions.
Consider it like a ping for this thread. :)
On Sun, Jan 11, 2015 at 08:07:13PM +0100, Jurre van Bergen wrote:
Hi,
For the first iteration, which is automatically build of interesting
branches, we need to specify:
* Which branches we want to build?
We might want to use several algorithms / tricks to select the branches to
be build automatically.
One of this algo could be:
0. Build all {feature,bugfix} branch that are not merged in
stable, devel and testing, and had new commits since the last release.
I have a script that does this roughly and it says that currently, that
means 11 branches. [1]
That would make sense, but might require to have some stats about how much
it has meant for the past releases. I'm not sure how to do that though.
0. We might also want a mechanism for devs to pro-actively state they want to
keep their branches being build even if the last commit was older than the
last release. IIRC
0. Do we think we might also need or want a mechanism to blacklist a branch,
or we should just assume that our algos will only select the right ones
and not hit any corner cases?
Thoughts, answers, ideas?
bert.
[1] bugfix/8680-git-without-polipo
bugfix/8714-tor-is-ready-robustness
feature/6297-save-packages-list
feature/6992-whisperback-email-address
feature/7450-openpgp-applet-exit
feature/7779-revisit-touchpad-settings
feature/8681-test-suite-ramdisk
feature/8719-mount-output-in-bug-reports
feature/jessie
feature/linux-3.18
feature/torbrowser-alpha
___
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 and merge feature/7752-keyringer
On Sun, Feb 01, 2015 at 11:49:40AM +, sajolida wrote: Emma Peel: sajolida sajol...@pimienta.org wrote: Ticket: https://labs.riseup.net/code/issues/7752 Branch: feature/7752-keyringer into devel Milestone: 1.3 At the end of the documentation it says: Make sure to update your *dotfiles* each time you use the **init**, **teardown**, **destroy**, or **preferences** command of *keyringer*. But I don't really understand from this phrase what is it I have to do to update. Do I have to run the previous command? If so, I would change it for Make sure you do this to update your *dotfiles* each time you use the **init**, **teardown**, **destroy**, or **preferences** command of *keyringer*. (but English is not my language, maybe there is a nicer version) Thanks for the review! Does 726c821 solves your issue? Merged in devel. Congrats! bert. ___ 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] Automated builds specification
Hi, On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote: bertagaz wrote (16 Feb 2015 14:32:57 GMT) : On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote: That's a logical awesome idea I'm ashamed not to have had sooner. Still, it seems that it comes too late, after some searching it appears that our Jenkins don't keep much stats. As discussed on IRC, we have about 10 days of logs on the filesystem currently, so you can still retrieve recent stats about it. The earlier, the better, as we're frozen and the more we wait, the less the numbers will be meaningful. I've just pushed a new page in the blueprint section, that contains the number of branches merged per release (as your script told us), and the number of builds per day that happened since 2015-02-10. https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_stats/ The Global build stats Jenkins plugin [1] seems interesting to display the stats once more logs are kept. Shall I install it? Let's give it a try, yes. I'll do that soon then. * Scenario 3 : RM says I need to know when a branch FTBFS, but I see no notification mechanism planned, so... how is the RM supposed to know. Also, whenever stalled topic branches start failing, this can imply an avalanche of daily email to the RM, who will of course start ignoring all email from Jenkins and then we've lost. I'm particularly worried about this topic since anonym (our RM most of the time) didn't comment on this proposal yet, and has already expressed concerns about this kind of issues. I think anonym did comment on this proposal, he did a review of this blueprint already. OK. Let's keep in mind that he may not have thought of this potential problem yet. Now, I wonder if we could solve this quite simply by having the RM be notified for *base* branch build failure only. The RM doesn't care about topic branches that haven't been submitted for merging yet, right? I like this idea, simple and effective. :) So for the base branches, the RM would be the contact point for daily and on push build failure notifications. And for topic branches, that would be the last commiter. One thing that this question also raise is the fact that the RM is not always the same person, so I'm wondering how to have jenkins notifying the right email depending on who is the RM for the next release. First thing that come in top of my mind is... a schleuder address. :) Indeed, that's the kind of aliases the RMs can trivially update themselves, without asking the infra team to do anything. Great, I'll add that to the specs and will open the corresponding tickets. bert. ___ 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] Automated builds specification
Hi, On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote: bertagaz wrote (16 Feb 2015 12:03:12 GMT) : Ack, sounds reasonable. However from what I've seen, it sometimes means a lot of branches so I wonder if we scaled our infra enough for that, as we didn't include this branches in our maths since the beginning of the discussion. This seems like a serious bug in this discussion process. May you please then provide example numbers that match what the proposed algorithm would output, so that we can reason about it? I've added to the statistic page the doc branches that have been merged. Part of them were not in the output of the script because they often get merged in master. It seems to add 4 to 6 branches per release, but their development and integration flaw is a bit different. So in the end, I'm not sure they'll add a lot more load, but we have to count them in our maths. bert. ___ 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] Automated builds specification
On Wed, Feb 11, 2015 at 11:29:45PM +0100, intrigeri wrote: Hi, bertagaz wrote (18 Jan 2015 16:39:28 GMT) : 0. Do we think we might also need or want a mechanism to blacklist a branch, or we should just assume that our algos will only select the right ones and not hit any corner cases? I think this is a good question, that deserves more thought. Unfortunately I've not found any discussion about it on the blueprint nor on the list, not even an example use case for such a blacklist, so right now — sorry to be harsh — it looks like a technical idea that's looking for a problem it might help solving. It's just that, something that did pop up in my head while writing the blueprint, but I didn't find much corresponding branches while watching the unmerged ones during the 1.3 release cycle. So, what would be the use cases? I can think of a few potential ones: 1. A branch that satisfies the criteria for automatic builds, but starts failing continuously, e.g. because its developer is on vacation for 2 weeks. = as far as I understood, only that branch's developer is nagged by failure notifications, so... who cares if it fails to build for 2 weeks? 2. Branches that modify only the doc or website = indeed, at first glance it seems a bit sad to spend CPU cycles on building and potentially testing such branches. OTOH, these branches, like any other, must not break the build, otherwise they're not fit for merging, so it makes sense to build an ISO (yes, an ISO, not only the website: we have quite a few things in the ISO build process that somewhat depend on the website, run `git grep usr/share/doc/tails/website -- config' if unconvinced). And they must not break functionality either, so IMO it makes sense to run the automated test suite on it too (again, we have quite a few runtime functionality that depends on the bundled static website). Ack, sounds reasonable. However from what I've seen, it sometimes means a lot of branches so I wonder if we scaled our infra enough for that, as we didn't include this branches in our maths since the beginning of the discussion. bertagaz, any other use case you were thinking of? Not really at the moment. bert. ___ 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] Automated builds specification
Hi, Thx for the extensive review! On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote: We're already drafted some scenario's on: https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/ I have a few concerns, though: * Scenario 2 : developer doesn't make it clear if branch T is build *after being locally merged into branch B*, or not. Given that's what we're really interested in, and given Scenario 1 : reviewer is clearer (answer is: yes), I guess the answer is yes here too, but this should be clarified. IIRC that was something Alan had troubles with, as not being the way she usually work on a feature branch, which I think was more close to Work work work on the branch, and then when the feature is ready, merge the base branch in it. So she usually do not merge the base branch very often. But I agree this is not the best way to go, so if Alan doesn't come up with a block on this, I agree to add the clarification. * I see no statistics about how many ISOs we are *currently* building each day. So it's not clear to me if our current setup can support building N more branches, once a day each. It would be useful to have this number (e.g. raw number per day during the 1.3 release cycle, and daily average). Of course we can fix that later (either by throwing more hardware at it, or by tweaking the branch selection algorithm a bit, or by decreasing the build frequency a bit for some branches based on some criteria), but if we can know *right now* that the designed plan cannot possibly work, then I would find it a bit sad to invest time into it. That's a logical awesome idea I'm ashamed not to have had sooner. Still, it seems that it comes too late, after some searching it appears that our Jenkins don't keep much stats. I'll extend the jjb setting that remove build logs after 1 day. The Global build stats Jenkins plugin [1] seems interesting to display the stats once more logs are kept. Shall I install it? * Scenario 3 : RM says I need to know when a branch FTBFS, but I see no notification mechanism planned, so... how is the RM supposed to know. Also, whenever stalled topic branches start failing, this can imply an avalanche of daily email to the RM, who will of course start ignoring all email from Jenkins and then we've lost. I'm particularly worried about this topic since anonym (our RM most of the time) didn't comment on this proposal yet, and has already expressed concerns about this kind of issues. I think anonym did comment on this proposal, he did a review of this blueprint already. But I agree the RM notification part is not very clear. We could make it so that the RM is emailed when a daily build job fails, the build failed on git push one being sent to the commit author anyway, according to our scenarios. Of course the commit author would also be notified for the daily ones too. If that's still too much from the RM point of view, we could have the RM notified only the first time a daily job fails. That seems to make sense to me: the RM gets a notification in the mailbox once a day for failed jobs, and then he/she either fix it, or ask someone to work on that. To have a developer claiming to Jenkins he/she is now responsible of that branch (and thus is getting the next notifications), he/she would just have to do a dumb commit on the branch. One thing that this question also raise is the fact that the RM is not always the same person, so I'm wondering how to have jenkins notifying the right email depending on who is the RM for the next release. First thing that come in top of my mind is... a schleuder address. :) I assume these concerns (except the 2nd one probably) are not blocking wrt. starting to implement stuff, so: Go! Great! To end with, I find two things confusing in the rest of the document: * Scenario numbering is reset in the Future ideas section, so one cannot simply refer to scenario 2 unambiguously, without making it clear if they're speaking of scenario 2 in the Scenarios section, or of scenario 2 in the Future ideas section; I suggest you avoid assigning duplicated scenario identifiers. Fixed. * The tag T notation (undefined) is somewhat conflicting with the branch T one that's defined earlier. Fixed. bert. [1] https://wiki.jenkins-ci.org/display/JENKINS/Global+Build+Stats+Plugin ___ 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.
