Re: [Tails-dev] Firefox extension for downloading Tails
Hi, sajolida wrote (06 Jul 2014 15:01:07 GMT) : Together with Giorgio Maone from NoScript and tchou we designed a crazy new plan to solve a great deal of ISO verification for the masses. Here it is: https://tails.boum.org/blueprint/download_extension/ Now that the plan was apparently checked by several people, this needs to be tracked as a sub-task of #6851, right? (And maybe other #6851's children need to be updated or closed.) Cheers, -- intrigeri ___ 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] The future of Vagrant Tails builds [Was: Fwd: Bug#753095: RFH: vagrant]
Hi, BS wrote (03 Jul 2014 16:25:09 GMT) : I must admit, I'm pretty confused. I thought the docs stated that wheezy was the only environment which Tails would build in. There are two different things here: a) the *host* operating system b) the system running in the VM that is *dedicated* to build Tails (a) can very well run Wheezy. (b) runs on (a). Our Vagrant basebox for (b) is still based on Squeeze, but work is in progress (and almost completed) to update it for Wheezy. If that's not the case, how is Tails building Tails? I'm not aware of anyone doing this. intrigeri wrote (29 Jun 2014 11:01:19 GMT) : 1. Someone who maintains the package in Debian. Is that an absolute requirement? Yes. What about downloading from vagrant's 'legacy' page Quoting https://tails.boum.org/blueprint/replace_vagrant/ : Vagrant's upstream provides a .deb, but no proper source package (they're using FPM). There's no strong cryptographic way to authenticate this package after downloading it. We don't want to rely on that package, nor to advertise it, for security reasons, and also due to our policy to do things with/in Debian. Any idea if there's a good alternative to Vagrant, that requires less work from us? Would e.g. Docker be an option? Can Gitian be used without Vagrant, e.g. thanks to its LXC backend? Docker is available in jessie, but not as a back port. Indeed, we want to evaluate Docker: https://labs.riseup.net/code/issues/7530 It's also limited to amd64 machines, because it uses go. I don't think it's a blocker to require a 64-bit machine to build Tails. Also, FWIW, the docker team says you shouldn't use docker in production. Good to know, thanks. I assume Tails counts itself as production? Yes, and no. Our usage of Docker, as far as this discussion is concerned, would only be about developers machines and CI infrastructure, and would not run on end-user systems. (also http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/) It's not a design goal of what we currently have with VirtualBox (Vagrant) to have the basebox guest VM isolation secure the host system against malicious code running as part of our build system. Note that our build system runs as root in the guest VM. So, this requirement doesn't really apply to Linux namespaces (Docker) either. 1) Rebuild the squeeze.box with the version of vagrant available on wheezy This may resolve current box add issues on wheezy and may buy some time. It does not seem like a permanent solution. Yes, that's the short-term plan, and WIP :) 2) Move the vagrant related Rakefile code into the vagrant file or use the vagrant CLI, where appropriate This should allow for easier upgrades, and the opportunity to explore other versions of vagrant Before investing more time into Vagrant, I think we'll want to investigate alternative solutions and decide if we want to go on (#7526). Cheers, -- intrigeri ___ 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] [PATCH] [review'n'merge] bugfix/#5387 Tails-greeter fix quick search in Other... window
Hi, my first little patch :) Thanks for your contribution. Tested on Tails 1.0. I'm afraid you didn't test exactly that. I had to change search_column from 0 to 1. Anyway that's a minor think that I changed, but I had to amend your commit and thus change its id. Test passes in 1.1~rc1 and it's now merged in greeter's master. For next time when you assign a ticket to a reviewer please set QA check to Ready for QA If you are interested on tackling a slightly more complicated task in the same field you might be interested by: - #5760: tails-greeter: feedback when repairing damaged persistent filesystem (Python/Gtk) - #5502: Notify user if hardware requirements are not met Thank you Alan! Thank *you*! Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [review'n'merge:documentation] #7534 Fix outdated documentation about checking md5 in Firefox
Hello, I suggest to remove the misleading documentation on the website regarding checking the ISO with a Firefox plugin. Here is the ticket: https://labs.riseup.net/code/issues/7534 Here is the commit to review: http://repo.or.cz/w/tails/hyas.git/shortlog/refs/heads/doc/7534-checksum Cheers, Hyas signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [PATCH] [review'n'merge] bugfix/#5387 Tails-greeter fix quick search in Other... window
Hi, Alan wrote (10 Jul 2014 09:46:18 GMT) : Test passes in 1.1~rc1 and it's now merged in greeter's master. Uh, that branch is supposed to be frozen. But oh well, let's assume this change is small enough, and enough not-risky, to warrant a freeze exception. Still, in the future, it would be good to first ask the RM if they're fine with such an exception. Anyway: great job U., congrats! ... and thank you, Alan, for promptly taking care of the review etc. :) Cheers, -- intrigeri ___ 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] [PATCH] [review'n'merge] bugfix/#5387 Tails-greeter fix quick search in Other... window
Alan: Hi, my first little patch :) Thanks for your contribution. Tested on Tails 1.0. I'm afraid you didn't test exactly that. I had to change search_column from 0 to 1. Indeed :))) Anyway that's a minor think that I changed, but I had to amend your commit and thus change its id. Test passes in 1.1~rc1 and it's now merged in greeter's master. For next time when you assign a ticket to a reviewer please set QA check to Ready for QA Ok. If you are interested on tackling a slightly more complicated task in the same field you might be interested by: - #5760: tails-greeter: feedback when repairing damaged persistent filesystem (Python/Gtk) - #5502: Notify user if hardware requirements are not met Thanks for the pointers, u. ___ 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] Tails Slides
Hi Rob, The slides of my talk @ Tails HackFest last weekend are available here: http://www.techn0polis.net/2016-07-06_Conf_Tails/index.html I also have a bunch of (very light) slides in French, which I used at a Ubuntu Party a few weeks ago. Those were dedicated to a more tech-savvy audience: http://www.techn0polis.net/2016-07-06_Conf_Tails/Workshop_Tails.pdf Dunno if it might help, but feel free to grab anything you like. I think the interesting point is to identify and word key features for non-technical users (that was the Reception chapter of my talk). That's an ongoing work these days :) Cheers, Amaelle --- On 10/07/2014 06:22, Robert Gurley wrote: Hello and thank you for corresponding w/ me about the Tails slides. I'm not in Paris, unfortunately, but I'd welcome any help you would like to provide via email. I've been consuming as much documentation on Tails and its constituent programs as possible - and I'll start mocking up some slides and a brochure this weekend. I have some less tech-savvy co-workers to bounce working off of, and we'll see how things end up. V/R Rob signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Milestones created: 1.1.1 to 1.3
Hi, as discussed today at the summit, now that we know the planned release date for Tails 1.1.1 to 1.3, we could finally create the corresponding milestones in Redmine. So, if you want to tackle some task in this time-frame, you might want to assign it to you, and flag it for the relevant milestone. Of course, an option is to pick tasks that are on the 2.0 or 3.0 milestone :) Cheers, -- intrigeri ___ 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] Tracking derivatives delta: explanations, history [Was: Sponsoring a Tails hackfest?]
Hi,
Paul Wise wrote (02 Jun 2014 15:56:56 GMT) :
On Mon, Jun 2, 2014 at 9:03 PM, intrigeri wrote:
It seems to me that having more information about the content of
this delta, and perhaps more importantly the reasons behind it,
would be needed to make it useful.
I'll look into the DEX and the derivatives census scripts for ideas,
focusing on what kind of question on this topic do we need to easily
find the answer to? first. Input is welcome, of course :)
The replacement for stabile.d.o (snapshot.d.o secondary replica) is
getting closer to being ready, [...]. Here are the results from
before the stabile.d.o hardware failure though: [...]
We have looked into this today at the Tails summit. [Disclaimer:
sorry if we've missed existing data or tools.] We have identified two
possible goals that are not achieved by the existing tools' output:
a. Enable anyone to easily find potential action items; that is:
make it easy to filter what should be ignored (legit delta) and
what should be improved.
b. Visualize the evolution of a given derivative's delta with Debian
= detect if the situation is improving or getting out of control
= derivatives developers can be happy and proud, or react
promptly; Debian contributors can evaluate how a given derivative
is nice to Debian.
We have also thought *a bit* of potential technical changes that would
help us reach these goals:
1. Have explanations about the delta in each case
Ideally, for 3.0 (quilt) packages, compare-source-package-list
could look into debian/patches for derivatives-specific patches,
and retrieve information from DEP-3 headers.
For other kinds of packages, it seems that the metadata would need
to be added to some fine in the debian/ directory, possibly using
the DEP-3 format. This also would be useful to document the delta
of 3.0 (quilt) packages that is not expressed in debian/patches,
e.g. shipping a newer upstream version than Debian.
2. Generate graphs displaying the evolution of a derivative's delta
This requires storing history of at least sources.{new,patches},
and having some code that generates graphs out of it. Presumably,
once specified properly, this could be a great task for someone
learning programming.
Thoughts, opinions?
Volunteers to do give a hand?
Cheers,
--
intrigeri
___
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] quickstart for new developer?
Vagrant itself works perfectly fine - I can run vagrant up and connect no problem. That's a pretty good news, actually! My main interests lie in finding new attacks against tails (and fixing them) and making the software absurdly easy to use on just about every machine. At some point I'd also be interested in porting tails to run on android - an obvious way would just to run a modified version of tails in a chroot environment, similar to what the pwnpad people do. (Of course, the ideal case is being able to dual boot via an SD card). Right now, I was planning on picking an easy task like adding a reboot button to the installer for the persistence setup but even something like that needs the full toolchain it seems. Actually, the whole idea of the easy tasks is to not require a full toolchain. So if this is the case, it needs to be fixed. For example, it is possible to work on the Greeter by doing: 1. Boot Tails and set up an administration password. 2. Modify the local copy of the Python files. 3. Press Ctrl + Alt + F1 to Switch to a console. 4. Login as root. 5. Restart GDM by doing service gdm* restart. But please, don't hesitate to ask for clarification if you plan to work on some easy tasks. It is often difficult for us to know how much details we should put in such tickets or to motivate ourselves to detail them a lot if we don't know that people are going to work on it. So you might find them in pretty obscure states sometimes... -- sajolida signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
Giorgio Maone wrote: On 09/07/2014 01:41, Alasdair Young wrote: I'm not a fan of openpgp.js for a lot of reasons. http://tonyarcieri.com/whats-wrong-with-webcrypto explains why in a much better way than I ever could. I'm very new to this community and its mindset, so I know I've got a lot to learn and I'm certainly missing something essential, but I fail to understand how those (mostly valid) objections apply to our scenario, since they are directed either against the webcrypto standardization process or aganst cryptography performed in the context of a web page: 1. OpenPGP.js does not *depend* on webcrypto, even if it supports it 2. We wouldn't run as web content, but as privileged code, with the same powers and the same isolation as the browser itself (much like any platform-native program, even if written in cross-platform JavaScript). 3. We don't need to deal with private keys Hey Giorgio! Thanks for clarifying that. Your reasoning sounds good to me, but I don't have the technical insight to validate everything that we are saying here. I added the idea to the blueprint (d5bc710) feel free to add more technical details. Still, I'd suggest not losing focus with that discussion now, and moving on to the initial implementation to verify SHA-256 and reconsider all that later on :) I created #7552 on our Redmine to track that project. Feel free to create yourself an account and assign that task to you. -- sajolida signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] greeter devel branch [was: bugfix/#5387 Tails-greeter fix quick search in Other... window]
Hi, On Thu, 10 Jul 2014 13:56:22 +0200 intrigeri intrig...@boum.org wrote: Alan wrote (10 Jul 2014 09:46:18 GMT) : Test passes in 1.1~rc1 and it's now merged in greeter's master. Uh, that branch is supposed to be frozen. But oh well, let's assume this change is small enough, and enough not-risky, to warrant a freeze exception. Still, in the future, it would be good to first ask the RM if they're fine with such an exception. I first checked out devel which had not changed since 2013 if I'm not mistaken. So in what branch are we supposed to develop? Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails Slides
Amaelle Guiton wrote: The slides of my talk @ Tails HackFest last weekend are available here: http://www.techn0polis.net/2016-07-06_Conf_Tails/index.html Hi Amaelle, Do you think we can put those on our website? https://tails.boum.org/promote/slides/ -- sajolida signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [review'n'merge:1.1] feature/vagrant-wheezy-basebox (#7133, #6736)
Hi, This branch makes it possible to build Tails from disk again, and as a bonus it should make any future upgrades of the basebox painless for users (and us thanks to the new documentation). jvoisin has tested the Tails build (not basebox build), and a `rake build` was all that was needed, so IMHO only a code review is necessary, which I've assigned to intrigeri. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails Slides
On 11/07/2014 00:05, sajol...@pimienta.org wrote: Amaelle Guiton wrote: The slides of my talk @ Tails HackFest last weekend are available here: http://www.techn0polis.net/2016-07-06_Conf_Tails/index.html Hi Amaelle, Do you think we can put those on our website? https://tails.boum.org/promote/slides/ Sure! I just licensed them under the Do What The Fuck You Want To Public License :D I used reveal.js, if you need the files, just tell me. Cheers, Amaelle signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tracking derivatives delta: explanations, history [Was: Sponsoring a Tails hackfest?]
On Fri, Jul 11, 2014 at 4:50 AM, intrigeri wrote:
Paul Wise wrote (02 Jun 2014 15:56:56 GMT) :
The replacement for stabile.d.o (snapshot.d.o secondary replica) is
getting closer to being ready, [...]. Here are the results from
before the stabile.d.o hardware failure though: [...]
An update on that:
The new hardware is setup and DSA have installed the necessary tools.
There are two limitations with the current setup though:
Less disk space available for the census scripts/patches. Workarounds
might be to not store new/modified packages and not store giant
patches (some were 1GB in size). Moving the debdiffs from
pre-generated to just-in-time might help too.
Generation will be slower, needs more memory and a tmpfs. I will
probably workaround this by putting some limitations on which packages
will get debdiffs.
Couple ideas that came out of the resulting discussion with DSA:
Expand snapshot.d.o to the derivatives too. This would require more hardware.
Add a debdiff service to snapshot.d.o for just-in-time diffs.
a. Enable anyone to easily find potential action items; that is:
make it easy to filter what should be ignored (legit delta) and
what should be improved.
My idea here was to add that to the new tracker.d.o interface and
associate it with the person who logged in, since what people want to
see might be different.
b. Visualize the evolution of a given derivative's delta with Debian
= detect if the situation is improving or getting out of control
= derivatives developers can be happy and proud, or react
promptly; Debian contributors can evaluate how a given derivative
is nice to Debian.
Should be easy to add rrdtool graphs or the like. If we want something
more advanced than that, a database would probably be required.
We have also thought *a bit* of potential technical changes that would
help us reach these goals:
1. Have explanations about the delta in each case
That information should be in debian/changelog, which would be in the delta.
Ideally, for 3.0 (quilt) packages, compare-source-package-list
could look into debian/patches for derivatives-specific patches,
and retrieve information from DEP-3 headers.
That sounds like an interesting complement to diffs of debian/changelog.
2. Generate graphs displaying the evolution of a derivative's delta
This requires storing history of at least sources.{new,patches},
and having some code that generates graphs out of it. Presumably,
once specified properly, this could be a great task for someone
learning programming.
sources.{new,patches} already store both current and historical data.
The reason is that even if a derivative drops a patch you might still
want to include it in Debian, deciding on that should be up to the
maintainer.
BTW: I plan to have a DebConf14 BoF about the derivatives
patch-generation stuff.
--
bye,
pabs
https://wiki.debian.org/PaulWise
___
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] Integrate GoldBug - Secure Instant Messenger. Secure P2P Instant Messaging
Hi Tails Dev team please integrate GoldBug - Secure Instant Messenger. Secure P2P Instant Messaging Chat from Friend to Friend without relying on a central server. # Key- / Repleo-Exchange. Define Add your friends. # Full decentral Chat- Instant Messaging-Network using the Echo Protocol (EMPP = Echoed Messaging and Presence Protocol) # Store Email for Offline-Friends in the P2P Network. # e2e Encryption (PK over SSL: using libgcrypt with LGPLv2.1+ License). # OpenSSL # Easy Setup for Listening Services of a decentral dedicated EMPP-Chat-Server. # Libspoton Integration. # Additional Security Layer with the Gemini-Feature for Chat-Partners. # Preventing Data Retention (VDS). WoT-less. # HTTP HTTPS Connections. # Open Source. BSD License for GUI. For libraries see libraries: libgcrypt with LGPLv2.1+ license, Open SSL with OpenSSL license and Qt is available under GPL v3, LGPL v2. Official site http://sourceforge.net/projects/goldbug/?source=navbar Debian Version http://sourceforge.net/projects/goldbug/files/goldbug-im_DEBIAN/0.9.02/ http://goldbug.sourceforge.net/ Read the official program manual .Greetings ___ 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.
