Re: [Tails-dev] overlay support in bilibop
(please cc me, I'm not subscribed)
Hi,
On 07/05/2015 13:44, intrigeri wrote:
May you please also provide a patch that applies on top of bilibop
0.4.23? I need to build a Tails/Jessie ISO with a newer kernel (that
only supports overlayfs).
'git diff debian/0.4.23..451b58ad17c4ea4a lib/bilibop/common.sh' builds
the attached patch.
Unfortunately, bilibop-lockfs needs more work and tests, and is not
ready for a new release. This means that there will not be a new bilibop
package in debian repositories in the next (two) weeks.
Any news on this front?
Things work pretty good, and will probably be packaged next week.
Cheers,
quidame
diff --git a/lib/bilibop/common.sh b/lib/bilibop/common.sh
index 1fbf549..18c1156 100644
--- a/lib/bilibop/common.sh
+++ b/lib/bilibop/common.sh
@@ -1,6 +1,6 @@
# /lib/bilibop/common.sh
#
-# Copyright (C) 2011-2014, Yann Amar quid...@poivron.org
+# Copyright (C) 2011-2015, Yann Amar quid...@poivron.org
# License GPL-3.0+
#
# This program is free software: you can redistribute it and/or modify
@@ -31,8 +31,9 @@
# and others), and then are replaced by grep and sed heuristics.
# We assume, even if it is not often, that /etc/udev/udev.conf can have been
# modified and that 'udev_root' can be something else than '/dev'.
-# dm-crypt/LUKS, LVM, loopback and aufs root filesystems (and combinations
-# of them) are now fully supported.
+# dm-crypt/LUKS, LVM, loopback, and aufs root filesystems (and combinations
+# of them) are now fully supported. Btrfs and overlay filesystems are also
+# partially supported (not fully tested).
# Functions that just output informations about devices/filesystems can be
# called by any unprivileged user.
@@ -211,56 +212,62 @@ EOF
### Here is the main function's dependency tree {{{
#
# physical_hard_disk
-# |
# |__underlying_partition
-#|
#|__underlying_device
-#| |
#| |__underlying_device_from_device
-#| | |
#| | |__underlying_device_from_dm
#| | |__underlying_device_from_loop
-#| | |
#| | |__backing_file_from_loop
#| | |__device_id_of_file
-#| | |__device_node_from_major_minor
+#| | |__underlying_device_from_file __ see below
+#| | |__device_node_from_major_minor v
#| |
-#| |__underlying_device_from_file
+#| |__underlying_device_from_file possible loop entry point
+#| |__device_id_of_file |
+#| |__find_mountpoint|
+#| |__is_aufs_mountpoint |
+#| | |__canonical |
+#| | |
+#| |__underlying_device_from_aufs|
+#| | |__aufs_readonly_branch|
+#| | | |__aufs_dirs_if_brs0|
+#| | | | |__is_aufs_mountpoint|
+#| | | | |__canonical |
+#| | | | |
+#| | | |__aufs_si_directory|
+#| | | |__is_aufs_mountpoint|
+#| | ||__canonical |
+#| | | |
+#| | |__device_id_of_file |
+#| | |__underlying_device_from_file __| possible loop entry point
+#| | |__device_node_from_major_minor|
+#| | |
+#| |__is_overlay_mountpoint |
+#| | |__canonical |
+#| | |
+#| |__underlying_device_from_overlayfs |
+#| | |__overlay_lowerdir|
+#| | | |__is_overlay_mountpoint|
+#| | | | |__canonical |
+#| | | | |
+#| | | |__canonpath|
+#| | | |
+#| | |__device_id_of_file |
+#| | |__underlying_device_from_file __| possible loop entry point
+#| | |__device_node_from_major_minor
#| |
-#| |__device_node_from_major_minor
-#| |__device_id_of_file
-#| |__find_mountpoint
-#| | |
-#| | |__is_aufs_mountpoint
-#| | |
-#| | |__canonical
+#| |__is_btrfs_mountpoint
+#| | |__canonical
#| |
-#| |__underlying_device_from_aufs
-#||
-#||__aufs_dirs
-#|| |
-#|| |__aufs_dirs_if_brs0
-#|| | |
-#|| | |__is_aufs_mountpoint
-#|| | |
-#|| | |_canonical
-#|| |
-#|| |__aufs_si_directory
-#|| |
-#|| |__is_aufs_mountpoint
-#|||
-#|||__canonical
-#||
-#||__device_id_of_file
-#||__device_node_from_major_minor
+#|
Re: [Tails-dev] extension specification
On 07/05/2015 18:12, sajolida wrote: Hi Giorgio, A few days ago we finished a wireframe of the extension that we believe is a good start for you to work on. It might still change slightly as we continue discussing small details of it. See https://labs.riseup.net/code/attachments/download/759/extension-20150430.fodg. Looks great, thank you! We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ See the sections: - Non goals - User scenario and wireframe - Integration in the web assistant - Initial browser detection - Checksum verification - Data source Regarding initial browser detection, I can also provide the JavaScript for browser sniffing and browser-specific web content provision if needed. Regarding the data source, we need to know whether YAML works for you as we already create very similar YAML files for the automatic upgrades. It works for me, no problem. May I just ask, though, why YAML and not, for instance, JSON? Does all this sounds reasonable to you? Yes it does. I think that what we need to work on together now is to specify which HTML tools (div, class, etc.) you will need in the code of those web pages to be able to do your stuff. Then tchou and I will start writing the HTML code for those pages. I'd actually feel more comfortable with you providing the HTML written the way you prefer best from a web authoring standpoint, and me developing my interaction code around the structure you come up with, bending it to my needs only if really necessary (e.g. by adding a missing id or class attribute) If that's relevant for you, note that we will most likely use bootstrap for the CSS of those pages. So for example the progress bar would have this markup: http://getbootstrap.com/components/#progress That's fine. Before you can start coding for real we'll also need a name for the extension. We'll try to sort this out quickly, see #9295. Feel free to comment on the latest proposals. I cast my vote for Download and Verify Tails: unambiguous and future-proof, in case should the verification process change. In all your work, it's also important to keep in mind that we'll try to have a similar extension for Chrome at least very soon. I don't know if you can make coding decisions that are more portable than others, but we should do that as much as possible. Yes I can and I had already planned to. We should also try to make the code as little Tails specific as possible. Of course it will be Tails specific as a first implementation, but we'd like to keep the Tails specific bits at least easy to factor out later on if other distros want to reuse our design and make it more generic. That was my idea too, I don't like to waste potentially reusable stuff. We also want to ask you whether you think we should have some written contract for your work with the specifications, deadlines, conditions, and so on. We don't usually do that when we work amongst ourselves but if you require one we can maybe get something. Informal email exchanges like this and the ones you initially contacted me with will work just fine, thank you. Otherwise, at least regarding the deadlines we'll have to deliver the web assistant to Hivos by the end of the year but we'll do several iterations before that and it would be great to have something on which we can do user testing let's say before July. Does that sound reasonable to you? I'm currently very busy with the Firefox transition to the Electrolysis multi-process architecture (enhancing security through low-privilege content sandboxing), and specifically with adapting NoScript to it and helping developers of other popular and complex add-ons who are facing the same challenges. Therefore, end of July or beginning of August is more realistic IMO, even though I'll do my best to prototype it ASAP. On the upside, you're guaranteed of being provided with an Electrolysis-ready add-on, rather than testing something earlier which only later is found to cause troubles in multi-process Firefox. Ah, and we took it for granted but your code will be public, GPL, and all from (almost) the beginning, right? Sure thing! Maybe we should create you a repo on git-tails.immerda.ch. Why not? -- G ___ 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] extension specification
Hi Giorgio, Giorgio Maone wrote (08 May 2015 21:29:44 GMT) : May I just ask, though, why YAML and not, for instance, JSON? We already have quite some code to generate, update and validate YAML documents with a very similar purpose and content. Sticking to YAML would allow us to re-use some of this code. Besides, we're using YAML in way more places than JSON in Tails currently, so that's also what we know best in-house. Maybe we should create you a repo on git-tails.immerda.ch. Why not? Please send tails-sysadm...@boum.org, in an OpenPGP-signed email: - your preferred user name there (ma1, just like on Redmine to keep things simple?) - a SSH public key And then the repo will be created in a few days, when I get some credentials of mine back (or earlier if my team-mate beats me to it). 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] [review'n'merge: 1.4] bugfix/9309-default-disconnect-search
On Thu, 7 May 2015 15:10:43 + (UTC) anonym ano...@riseup.net wrote: I won't say much here; read the ticket, especially for the convenient testing instructions. I'll test this soon. pgpjEhm7TfVPl.pgp 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] Truly Random Mac Changer
On 05/08/2015 10:11 PM, intrigeri wrote: Peter N. Glaskowsky wrote (08 May 2015 18:59:35 GMT) : On May 8, 2015, at 10:20 AM, intrigeri intrig...@boum.org wrote: Source Valley wrote (08 May 2015 16:55:50 GMT) : There are countless example I can think of where one might need a truly random mac changer, here is just one example: If I'm sitting in a coffee shop and I'm the only one with a Unique first 3 octet wifi card, then it wouldn't be too difficult to reveal who I am. I don't understand. May you please clarify? I assume this is the usual issue that someone observing the network can look up an OUI, here for example: https://www.wireshark.org/tools/oui-lookup.html and if it turns out to be distinctive— for example, used only in certain Dell-branded laptops— it could potentially identify the user if he or she is the only user with such a machine in the coffee shop at that moment. OK, I see. In such contexts, I don't think it matters much what exact bits of the MAC address we modify, as long as we spoof the MAC address exactly once per session: the timing of connection/disconnection is probably enough to correlate a given MAC address with a physical body with a quite good success rate: the MAC address that suddenly appears on the LAN when $PERSON shows up, takes $COMPUTER of a bag and turns it on, and suddenly disappears when $COMPUTER is put back into a bag and $PERSON leaves, is very likely to be $COMPUTER's MAC address, and the network traffic from that MAC address is very likely $PERSON's network traffic. Exactly. However, having a NIC with a rare OUI is a serious problem in other ways if the attacker takes that in consideration (i.e. treats that OUI as unique in some geographical region, which may be reasonable in some cases I suppose). Just to further elaborate why randomly picking between OUI:s (or (worse!) completely randomizing the vendor bytes) isn't so simple to do in a safe manner, look at this part of the design document: https://tails.boum.org/contribute/design/MAC_address/#index12h2 Those conclusions are not set in stone, feel free to attempt to change our minds! :) 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.
