Re: [Tails-dev] Removing or blacklist kernel modules
Hi, (Created https://labs.riseup.net/code/issues/7639 to track this all.) Jacob Appelbaum wrote (21 Jul 2014 19:54:57 GMT) : > On 7/21/14, intrigeri wrote: >> However, removing modules altogether is no more work than blacklisting >> them: we can do it either via chroot_local-hooks (and then, regenerate >> the initrd's), or with the exclude file passed to mksquashfs (but in >> this case, if any of the blacklisted module is in the initrd's, then >> we're not really removing it; so likely a hook is better). >> > Is that true? Isn't blacklisting them as simple as adding a few lines > to /etc/modprobe.d/blacklist.conf? Right. Which is not much easier than maintaining a text file with a list of module names, and writing a ~10-lines build-time hook that runs find -delete on these names, and then runs update-initramfs. If we prefer to remove modules entirely, I can do that. In any case, I think the (one-time) cost of implementing this mechanism will be totally neglictible, compared to the energy needed to create and maintain the blacklist. > I think there are some modules we will never want (eg: appletalk) and > some people may oneday force load (ax25) for their HAM radio > emergencies. Good point. Then, we might want to keep some modules blacklisted, even when we move from blacklisting to removing. So, we need two lists. > Is the right place to put things in /etc/modprobe.d/blacklist.conf > as I think? I think we'll want to use a less generic name, such as tails-blacklist.conf. > This would be my first addition to that file: I've just created https://tails.boum.org/blueprint/blacklist_modules/, and added your list to it. Please add a rationale for each module there (why it's useless and/or dangerous), as we won't just add modules to the blacklist because someone pretending to be Jake on a mailing-list said so :) Also, for anyone interested in working on this blacklist, Ubuntu and Fedora have had some for years: * https://fedoraproject.org/wiki/Security_Features_Matrix#Blacklist_Rare_Protocols * https://wiki.ubuntu.com/Security/Features#blacklist-rare-net These are well tested, and would be a good basis. Likely we'll want to go further in Tails, but at least *this* should really be ported to Debian, and not carried as a Tails delta. 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] Removing or blacklist kernel modules
On 7/21/14, intrigeri wrote: > Hi, > > Jurre van Bergen wrote (11 Jul 2014 15:20:22 GMT) : >> I feel that it's important to reconsider what we would like to ship >> in Tails as the more kernel modules we load and/or ship we also >> increase the attack vector. > > Fine with me, as there seems to be energy willing to be put into > this :) > >> I feel that actually _removing_ modules is a better way to achieve a >> slightly safer kernel as the code could not be reached anymore. Less >> attack vector! > >> Blacklisting kernel modules allows you to compile them in, but not use >> them, however, *perhaps* code could still be reached which might be >> exploitable with some crazy exploit. > > My understanding is that to have a blacklisted module loaded, assuming > one isn't root yet (otherwise, we've lost already), one needs to find > a way to exploit a bug in modprobe so that it ignores at least part of > its configured blacklist. And then, one has to have the module loaded > (not so hard, in many cases) and exploit it. So, my take on it is that > blacklisting should be Good Enough™, at least for a first iteration > (see below). I'm not clear that this is correct but I think we should find a way to test this theory. > > However, removing modules altogether is no more work than blacklisting > them: we can do it either via chroot_local-hooks (and then, regenerate > the initrd's), or with the exclude file passed to mksquashfs (but in > this case, if any of the blacklisted module is in the initrd's, then > we're not really removing it; so likely a hook is better). > Is that true? Isn't blacklisting them as simple as adding a few lines to /etc/modprobe.d/blacklist.conf? > The only downside I can see to removing the modules (as opposed to > blacklisting them) is that it entirely prevents users from > force-loading a module they need. Which will probably matter in the > initial stages of preparing, and fine-tuning, the list of modules we > don't want: hardening is great, but regressions are bad. > I think there are some modules we will never want (eg: appletalk) and some people may oneday force load (ax25) for their HAM radio emergencies. > So, I would suggest to blacklist (and document how to bypass the > blacklist) as an initial step, and once we're happy with the > blacklist, and haven't seen serious complains about it for a few > releases, then we can remove modules for real. Makes sense? > That sounds reasonable. > Now, regardless of the method used to disable these modules, the list > will have to be maintained. Jurre, I guess you're volunteering, > right? :) Is the right place to put things in /etc/modprobe.d/blacklist.conf as I think? This would be my first addition to that file: +blacklist ipx +blacklist appletalk +blacklist ax25 +blacklist psnap +blacklist rose +blacklist p8023 +blacklist llc +blacklist p8022 All the best, Jacob ___ 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] user-agent analysis and suggestions: hooray!
On 7/21/14, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (24 Jun 2014 10:56:54 GMT) : >> I think agreeing on a specific user agent and having a central place >> to find it makes the job much easier to tackle. In any case, I think >> setting a few shell aliases would not hurt and if they source a common >> file for a user agent, it should be straight forward to keep things in >> sync with perhaps no upstream modifications? > >> For example: > >> wget --user-agent="$useragent" >> curl --user-agent "$useragent" >> GET -H "User-Agent:$useragent" > > This would definitely work. We ship a getTorBrowserUserAgent program, > that's used by the curl processes started by htpdate. Its results > could be cached at ISO build time, and then used by these aliases. Seems fine, yes. > > One should look for other instances of using wget, curl, LWP and > friends without going through the shell, too. Any taker? Not it. :) > >> For the discussion at hand, I sniffed my own sessions and saw the >> following data transmissions. > > Woohoo \o/ .. and sorry for the delay. > >> wget: >> [...] >> Accept: */* >> Connection: keep-alive > >> curl: >> [...] >> Accept: */* >> Proxy-Connection: Keep-Alive > >> GET: >> [...] >> TE: deflate,gzip;q=0.3 >> Connection: TE, close > >> This is Tor Browser on Tails for the same file but on a different web >> server: >> [...] >> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip, deflate >> Connection: keep-alive > > So, this shows that we have an identifying set of headers for each of > these four clients, even if we ignore the user-agent information. ... > > ... but, in the following tests (with a forged user-agent), most of > these discrepancies disappear, so I'm confused: > >> Here are the same clients with a forged User Agent: > >> wget --user-agent="User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) >> Gecko/20100101 Firefox/24.0" >> [...] >> Accept: */* >> Connection: keep-alive > >> curl --user-agent "User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) >> Gecko/20100101 Firefox/24.0" >> http://people.torproject.org/~ioerror/misc/tor-ips.txt; shows: >> [...] >> Accept: */* >> Connection: keep-alive > > I'm surprised: without faking the user-agent, we had > "Proxy-Connection" instead of "Connection". Is one of these results > wrong, or is curl behaving erratically, or is there another > rational explanation? > I don't remember? :-) >> GET -H "User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) >> Gecko/20100101 Firefox/24.0" >> [...] >> Connection: keep-alive > > Same here, we had "Connection: TE, close" previously => same question. > >> My conclusion is that setting the user agent for curl and wget to >> match Tor Browser isn't a horrible idea. It even seems like on a >> single GET request, it would be helpful for privacy and anonymity set >> reasons. It certainly reduces the version information leakage that is >> absolutely useful for fingerprinting and exploitation. For `GET` - we >> might also add -H="Accept: */*" and then all three would be aligned. > > I'll wait for the surprising things highlighted above to be clarified, > before commenting on this one. > I think the first set was wrong or weird and the second set was mostly correct. It would be good if someone could re-run the tests on Tails 1.1 anyway. Any takers? All the best, Jacob ___ 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] user-agent analysis and suggestions: hooray!
Hi, Jacob Appelbaum wrote (24 Jun 2014 10:56:54 GMT) : > I think agreeing on a specific user agent and having a central place > to find it makes the job much easier to tackle. In any case, I think > setting a few shell aliases would not hurt and if they source a common > file for a user agent, it should be straight forward to keep things in > sync with perhaps no upstream modifications? > For example: > wget --user-agent="$useragent" > curl --user-agent "$useragent" > GET -H "User-Agent:$useragent" This would definitely work. We ship a getTorBrowserUserAgent program, that's used by the curl processes started by htpdate. Its results could be cached at ISO build time, and then used by these aliases. One should look for other instances of using wget, curl, LWP and friends without going through the shell, too. Any taker? > For the discussion at hand, I sniffed my own sessions and saw the > following data transmissions. Woohoo \o/ .. and sorry for the delay. > wget: > [...] > Accept: */* > Connection: keep-alive > curl: > [...] > Accept: */* > Proxy-Connection: Keep-Alive > GET: > [...] > TE: deflate,gzip;q=0.3 > Connection: TE, close > This is Tor Browser on Tails for the same file but on a different web server: > [...] > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip, deflate > Connection: keep-alive So, this shows that we have an identifying set of headers for each of these four clients, even if we ignore the user-agent information. ... but, in the following tests (with a forged user-agent), most of these discrepancies disappear, so I'm confused: > Here are the same clients with a forged User Agent: > wget --user-agent="User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) > Gecko/20100101 Firefox/24.0" > [...] > Accept: */* > Connection: keep-alive > curl --user-agent "User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) > Gecko/20100101 Firefox/24.0" > http://people.torproject.org/~ioerror/misc/tor-ips.txt; shows: > [...] > Accept: */* > Connection: keep-alive I'm surprised: without faking the user-agent, we had "Proxy-Connection" instead of "Connection". Is one of these results wrong, or is curl behaving erratically, or is there another rational explanation? > GET -H "User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:24.0) > Gecko/20100101 Firefox/24.0" > [...] > Connection: keep-alive Same here, we had "Connection: TE, close" previously => same question. > My conclusion is that setting the user agent for curl and wget to > match Tor Browser isn't a horrible idea. It even seems like on a > single GET request, it would be helpful for privacy and anonymity set > reasons. It certainly reduces the version information leakage that is > absolutely useful for fingerprinting and exploitation. For `GET` - we > might also add -H="Accept: */*" and then all three would be aligned. I'll wait for the surprising things highlighted above to be clarified, before commenting on this one. Thanks a lot! 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 again plz] #7156 Create a donation form to receive fiat currencies
intrigeri: > u wrote (21 Jul 2014 11:34:40 GMT) : >> Not sure if the review and merge request was clear enough, changing the >> subject line. > > I've done some ticket gardening on #7156 and its two child tickets, to > make things easier for sajolida when he has time to review'n'merge > this. Also, flagged these tickets for the next release, so that it > shows up on top of his "tickets assigned to me" view, and on the > release managers' radar too :) Thanks :) ___ 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] user-agent analysis and suggestions: hooray!
Hi, Jacob Appelbaum wrote (25 Jun 2014 14:39:19 GMT) : > On the subject of generic and easy to maintain fixes, we may also want > to investigate using Privoxy: Actually, there's ongoing work to simply *remove* polipo: https://labs.riseup.net/code/issues/5379 ... and it seems like we're almost there :) I quite like the idea of reducing the attack surface and memory bloat caused by running a HTTP proxy. Not sure if the problems described on this thread are worth introducing another one. 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] 1st usability testing session results
Hi, [Adding tails-ux@ to the Cc list.] u wrote (23 Jun 2014 21:57:05 GMT) : > here is some feedback we gathered at the first Tails UX session with > NUMA experiments. Thanks a lot! > [...] > If you're only interested in the tickets, here they are: > Tails: > - https://labs.riseup.net/code/issues/5417 > Improve user experience when wiping memory at shutdown > - https://labs.riseup.net/code/issues/7440 > Implement a progress indicator while establishing a connection to Tor > - https://labs.riseup.net/code/issues/7436 > Contact Riseup on how we could help towards publishing a list of > recommended email providers > - https://labs.riseup.net/code/issues/7433 > Have Tails OpenPGP Applet in the menu > - https://labs.riseup.net/code/issues/7449 > UX: Add Seahorse to application menu > - https://labs.riseup.net/code/issues/7448 > UX: Check whether we might be on a captive portal if Tor fails to connect [... snipping the MAT ones ...] Most of these tickets have been commented upon since then, yay. In some cases, the next smallish thing to do has been clarified. So, anyone interested in making Tails more usable: I believe that now is the right time to have a look at these tickets again, pick one, assign it to you, and go :) 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] Removing or blacklist kernel modules
Hi, Jurre van Bergen wrote (11 Jul 2014 15:20:22 GMT) : > I feel that it's important to reconsider what we would like to ship > in Tails as the more kernel modules we load and/or ship we also > increase the attack vector. Fine with me, as there seems to be energy willing to be put into this :) > I feel that actually _removing_ modules is a better way to achieve a > slightly safer kernel as the code could not be reached anymore. Less > attack vector! > Blacklisting kernel modules allows you to compile them in, but not use > them, however, *perhaps* code could still be reached which might be > exploitable with some crazy exploit. My understanding is that to have a blacklisted module loaded, assuming one isn't root yet (otherwise, we've lost already), one needs to find a way to exploit a bug in modprobe so that it ignores at least part of its configured blacklist. And then, one has to have the module loaded (not so hard, in many cases) and exploit it. So, my take on it is that blacklisting should be Good Enough™, at least for a first iteration (see below). However, removing modules altogether is no more work than blacklisting them: we can do it either via chroot_local-hooks (and then, regenerate the initrd's), or with the exclude file passed to mksquashfs (but in this case, if any of the blacklisted module is in the initrd's, then we're not really removing it; so likely a hook is better). The only downside I can see to removing the modules (as opposed to blacklisting them) is that it entirely prevents users from force-loading a module they need. Which will probably matter in the initial stages of preparing, and fine-tuning, the list of modules we don't want: hardening is great, but regressions are bad. So, I would suggest to blacklist (and document how to bypass the blacklist) as an initial step, and once we're happy with the blacklist, and haven't seen serious complains about it for a few releases, then we can remove modules for real. Makes sense? Now, regardless of the method used to disable these modules, the list will have to be maintained. Jurre, I guess you're volunteering, right? :) 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] Tails build broken?
Hi, [No need to Cc me, I read the list. If the same for you, just tell.] brain_str...@tushmail.com wrote (03 Jul 2014 05:25:47 GMT) : > I cloned the tails git repo and tried to follow the install instructions > (using stable instead of devel). The first time I ran rake build it failed, > the second time it claimed to succeed. Can anyone offer help on determining > my success? May you please try setting up your Vagrant environment with the documentation that's in the feature/vagrant-wheezy-basebox branch, and to build from that branch? Sorry for the delay, we've been swamped with the HackFest + summit.. 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] grsec, again [Was: Removing or blacklist kernel modules]
Hi, David McKinney wrote (11 Jul 2014 19:53:05 GMT) : > We're happy to work with everybody towards getting a minimal > grsecularized kernel into Debian. The last discussion about it starts there: https://mailman.boum.org/pipermail/tails-dev/2014-April/005414.html Last time I gave it a thought, it seemed to me that having a linux-grsecurity source package, that build-depends on linux-source-$VERSION, would be the best way forward to start with: it would make the grsec flavour non-blocking for the regular Linux updates, and would be a good place to show-case that there's a well-functioning team, who's able to cope with the workload for a while. Once this has been demonstrated, then possibly the grsec flavour can be integrated into the regular src:linux package, and both teams can be merged. The only serious concern I see with this approach (without having re-read Debian#605090 recently, though) is the code duplication, which the Debian security team is usually (and rightfully) quite opposed too. But I'm sure this can be discussed, and some of them really would like to see a grsec kernel in Debian. To end with, note that nobody on the current Tails team has the needed skills to contribute to this effort, so if it happens, it won't be thanks to us. I guess some of us would be happy to be beta-testers, though :) 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 again plz] #7156 Create a donation form to receive fiat currencies
u wrote (21 Jul 2014 11:34:40 GMT) : > Not sure if the review and merge request was clear enough, changing the > subject line. I've done some ticket gardening on #7156 and its two child tickets, to make things easier for sajolida when he has time to review'n'merge this. Also, flagged these tickets for the next release, so that it shows up on top of his "tickets assigned to me" view, and on the release managers' radar too :) 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] Replacing TrueCrypt with cryptsetup 1.6 + documentation? [Was: tcplay in tails]
Hi,
intrigeri wrote (21 Jun 2014 10:34:44 GMT) :
> intrigeri wrote (29 Apr 2014 07:03:02 GMT) :
>> OTOH, it seems to me that most usecases of TC volumes are about
>> interoperability with major non-free OS, so assuming one is
>> comfortable unlocking a TC volume (created in Tails) using one such
>> OS, then why not use it as well to create the volume in the first
>> place. With this in mind, including tcplay could be seen as a mere
>> temporary measure, aimed at addressing #1 only, and valid only until
>> we ship a version of cryptsetup that supports unlocking TC volumes on
>> the command-line (Tails/Jessie, or cryptsetup 1.6+ in
>> wheezy-backports). But then, if we go this way, perhaps it would be
>> worth skipping the tcplay step and jumping directly at a cryptsetup
>> backport attempt.
> Are you interested in trying to backport cryptsetup for Wheezy?
I've given it a quick try, and it was pretty easy. I only had to add
the attached quilt patch, dch --bpo, and it just built. Quickly tried
the resulting binary packages in Tails 1.1 (creating a LUKS volume in
GNOME Disks, unlocking and locking it again), seems to work fine.
Since Tails 0.20 (a year ago), we've been telling TrueCrypt users that
we mean to remove it. Besides, the recent events on the upstream front
make it even more doubtful to go on shipping TC in Tails.
So, I'm starting to think that we should just include cryptsetup
1.6.x, drop TrueCrypt, and document 1. how to get one's documents out
of a TC volume, for those who've just been waiting for when it's too
late; and 2. how to unlock a TC volume on the command-line with
cryptsetup, for those who badly need to interoperate with
non-Linux systems.
The timeline I have in mind is:
1. In Tails 1.1.1, modify the TC wrapper to announce that it'll be
removed in 1.2.
2. In Tails 1.2, do the rest of the plan described above.
3. On the long term, anyone who wants anything better can work on
#6337 ("Add support for TrueCrypt volumes in udisks") and its
logical next steps (Nautilus / GNOME integration).
Thoughts?
Cheers,
--
intrigeri
--- a/configure.ac
+++ b/configure.ac
@@ -17,8 +17,8 @@
# http://lists.gnu.org/archive/html/automake/2013-01/msg00060.html
# For old automake use this
-#AM_INIT_AUTOMAKE(dist-bzip2)
-AM_INIT_AUTOMAKE([dist-bzip2 1.12 serial-tests])
+AM_INIT_AUTOMAKE(dist-bzip2)
+#AM_INIT_AUTOMAKE([dist-bzip2 1.12 serial-tests])
if test "x$prefix" = "xNONE"; then
sysconfdir=/etc
___
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] Release schedule for Tails 1.1.1
intrigeri wrote: > Fair enough? Yes. You're the one doing the work after all... -- 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] [review'n'merge:1.1] feature/vagrant-wheezy-basebox (#7133, #6736)
21/07/14 11:03, intrigeri wrote: > Hi, > > tl;dr: all looks good now, *but* I didn't test it. jvoisin, may you > please (ETA: August 12): > > 1. remove all Vagrant files and artifacts from your local system > 2. checkout the latest version of feature/vagrant-wheezy-basebox > 3. try building a Tails ISO from there > > ? > > ... or maybe one should tell me that the only changes, since last > jvoisin's try, were about the basebox building, so we don't care and > I should just merge it? This is exactly the case, so I think jvoisin can skip the test and you merge if you're happy with the code review. After all, the only code change is dropping the `-a` parameter for gpg --export. > anonym wrote (20 Jul 2014 20:00:15 GMT) : >> 11/07/14 02:10, intrigeri wrote: >>> Commit fe9da04 is a pain to review, as it mixes renaming files, with >>> changing their content. So, I'm manually diff'ing the old files with >>> the new ones. > >> Sorry, didn't think about that. OTOH it didn't feel like it would make >> sense to rename the old directory to wheezy in a separate commit... or >> do you think it's worth that, for future reference? > > No, let's keep it as is. > >>> Does #5498 still apply? The notes about it were removed, but we still >>> instruct to install the gem as root, so I'm wondering. > >> I did try `gem --user` earlier, which said there was no such option. >> Apparently it is `gem install --user`, duh! Adapted. > > OK, I've closed #5498, then. Or was there a reason why you didn't do it? No. 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] OnionMail + HTTP + Thunderbitd autoconfig + OnionMail root directory.
In a near future we want create an OnionMail root directory: A simple hidden service where to find a list of open and public OnionMail servers. Today there is a little implementation of this feature (is a little script onion.py to configure Claws-Mail and GPG in tails). In the next version of OnionMail 1.6 (available in test section today) the sysop can open a little HTTP server to: * Thunderbird autoconfiguration. * User subscription. * Server statistics. * Create a WebPage of server. All in one TOR hidden service. Sometimes onionmail.info become some friends of "HiddenSerice.onion". (LOL somebody is running OnionMail without edit the default configuration file servers.conf). New features in the next version: * GPG Key generation (server). * Thunderbird Autoconfiguration. * Simple web server. * Subscription WebPage. ___ 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] filename problem
Hi, > I Am on Windows 7 64-bits and I would like to contribute to #7506 and #7508 > but > I have this error too when cloning the repo. > Creating a virtual machine is a solution, but it would be better if Windows > contributors could clone the repo. OK, that's a usecase I'd like us to support. We have *many* files in Git that have colons in their name, so updating all that (and the blueprint fields in Redmine, and adding RewriteRule's) is quite some work. Any taker? (@Patrick: I suggest going the VM way unless someone volunteers shortly.) Note that there are more forbidden chars, see "Allowed characters in filenames" on https://en.wikipedia.org/wiki/NTFS. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review again plz] #7156 Create a donation form to receive fiat currencies
intrigeri: > u wrote (14 Jul 2014 20:19:44 GMT) : >> Thanks. I tried to follow this. Can you tell me if it's ok now? > > The resulting Git diff against current master looks good! > > Cheers! > Not sure if the review and merge request was clear enough, changing the subject line. 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] Firefox extension for downloading Tails
Giorgio Maone wrote: > On 10/07/2014 23:35, sajol...@pimienta.org wrote: >> 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 agree and I'm almost done with that: I managed to make Firefox perform > SHA-256 verification of the current ISO asynchronously, without blocking > the browser GUI at all, in 7 seconds, which oddly seems significantly > faster than the native GPG CLI (blocking), at least on my system. Woh, exciting! > Now I "just" have to wrap this code in a nice UI and package ;) And just tell us if you need a Git repo to host our code on our infrastructure. -- 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] [review and merge] filename problem
Hi, I Am on Windows 7 64-bits and I would like to contribute to #7506 and #7508 but I have this error too when cloning the repo. Creating a virtual machine is a solution, but it would be better if Windows contributors could clone the repo. Regards, Patrick Le 16/07/2014 15:53, DP Tor-Contact a écrit : I am using a Windows Vista 32-bit machine. (yeah pretty awful but I'm at work) I have tried to cole the repo again, it showed the same mistake. I also saw that there are some more filenames with colons. Is there a contributer-base of Windows users? If not we should leave it in that way, I can switch to a virtual machine with Debian. And the documentation should be updated regarding to that. Regards spriver Am 2014-07-16 14:53, schrieb u: intrigeri: u wrote (16 Jul 2014 11:28:59 GMT) : as seen on tails-l10n, there is a folder in the wiki which contains a colon. This results in problems on Windows systems, where contributors might want to translate.. but can't checkout this folder. Can one build the website (with ikiwiki) on Windows? (I'm fine with adding constraints on filenames if it *really* allows people to do their translation work on Windows. If it's removing one stumbling block only to then unhide the next one, I'm not sure it's worth it.) you are absolutely right. Let's ask the person first. Eventually, we should then also update the documentation accordingly. cheers 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. ___ 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. -- Patrick ZAJDA Skype: gansta93 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge:1.1] feature/vagrant-wheezy-basebox (#7133, #6736)
Hi, tl;dr: all looks good now, *but* I didn't test it. jvoisin, may you please (ETA: August 12): 1. remove all Vagrant files and artifacts from your local system 2. checkout the latest version of feature/vagrant-wheezy-basebox 3. try building a Tails ISO from there ? ... or maybe one should tell me that the only changes, since last jvoisin's try, were about the basebox building, so we don't care and I should just merge it? anonym wrote (20 Jul 2014 20:00:15 GMT) : > 11/07/14 02:10, intrigeri wrote: >> Commit fe9da04 is a pain to review, as it mixes renaming files, with >> changing their content. So, I'm manually diff'ing the old files with >> the new ones. > Sorry, didn't think about that. OTOH it didn't feel like it would make > sense to rename the old directory to wheezy in a separate commit... or > do you think it's worth that, for future reference? No, let's keep it as is. >> Does #5498 still apply? The notes about it were removed, but we still >> instruct to install the gem as root, so I'm wondering. > I did try `gem --user` earlier, which said there was no such option. > Apparently it is `gem install --user`, duh! Adapted. OK, I've closed #5498, then. Or was there a reason why you didn't do 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.
