[Tails-dev] certificate error for immerda.ch
This may already be known by those that can fix it, but I'm getting an error when accessing git-tails.immerda.ch. With Git: fatal: unable to access 'https://git-tails.immerda.ch/tails/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none In Firefox: git-tails.immerda.ch uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The certificate is only valid for git.tails.boum.org (Error code: sec_error_unknown_issuer) Cert info: Signature Algorithm: sha256WithRSAEncryption Issuer: C=CH, ST=Be, L=Bern, O=immerda.ch, CN=immerda_public_web_4-ca Validity Not Before: Nov 16 16:21:06 2014 GMT Not After : Dec 26 16:21:06 2014 GMT Subject: C=CH, ST=Be, L=Be, O=git.tails.boum.org, OU=git.tails.boum.org, CN=git.tails.boum.org -- GPG ID: 0x5BF72F42D0952C5A Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A pgp73Sf8JNZcQ.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] Dropping the alternate US keyboard layout? (#7912)
Hi, anonym wrote (12 Nov 2014 00:05:50 GMT) : > The implication of the comment is that the order of the `layouts` list's > elements doesn't matter, but the current internal state of it does, i.e. > whatever is currently set will be kept. Presumably that is only the case > when the appropriate GNOME part (that deals with keyboard layouts) is > running, so my guess it that #7912 triggers when this script runs but > the GNOME part is *not* (yet) running so there never is an internal > state of `layouts` where it's simply the chosen layout. Makes sense. We're probably racing with gnome-settings-daemon, or its plugin that manages the keyboard IIRC. And we're also configuring this at two different levels (dconf on one side, and also our Greeter does it with xkl, which does impact whatever the GNOME session gets), which feels just wrong and racy too. > Adding a static `sleep 10` at the beginning of the script or similar (so > that the responsible GNOME part is ensured to run) could possibly "fix" > the bug. Please, let's not do that :) > The better solution would be to wait for the exact part of > GNOME to be running and wait for that. Yes. This or, to the contrary, block the startup of the component we're racing with until we're done with our part of the setup. The latter would look a bit nicer to me (pre-configuration vs. re-configuring on-the-fly after letting the defaults be applied). Unfortunately, I see no facility in the desktop file spec for declaring dependencies, so it'll require either ugly hacks, or waiting until the session is managed by `systemd --user', or finding a way to configure this *before* we start the rest of the session (that is, ). > And the best would be if GNOME would do this in a sane manner where > the current state isn't relevant when setting it to a new value. Indeed. But I think we're just not doing things right here: on a non-Tails Debian systems, things just work (both at login time and when reconfiguring them later). I suspect we're simply not using the preferred interface to configure these bits. OTOH, things are a bit different on Jessie, and I'd rather avoid spending too much time on a Wheezy-only solution. > Billions of people use non-latin keyboard layouts so dropping cc4e759e > would make their Tails experience much worse than what #7912 does OK. > (IMHO), so if we're gonna do something like what you suggest, I'm with > sajolida -- we should only add 'us' when a non-latin layout is selected, > and just accept that #7912 happens occasionally for these users (who are > probably (definitely?) well-trained at layout switching any way). Looks good enough to me, at least while we're based on Wheezy. > I have no idea if there's an easy way to detect whether a layout is > latin-based or not. No idea either. Would be worth a research ticket. > And it'd be sad if we'd have to maintain > a gigantic disjunction of checks against the layout like: > [ "$XKBLAYOUT" = "jp" ] || [ "$XKBLAYOUT" = "ar" ] || ... Sure. If we *have to* maintain a hardcoded list (which should ideally be avoided), then I expect we'll be able to implement this in a nicer way (grep -qx "$XKBLAYOUT" "$NON_LATIN_LAYOUTS_FILE", or something). 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] keeping up with transports
On Wed, 19 Nov 2014 12:50:12 +0100 intrigeri wrote: > I'm not sure what problem you're trying to solve here. Let me try > harder. > > If it's about "users always ask if $PT is supported and we need to be > able to point them to some already written answer", then the list of > bridges/PT types we support is maintained on > https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/. > Other bridges/PT types are not supported. Maybe we need a FAQ entry > about "Is $PT supported in Tails?" that simply points to the > corresponding doc. > This is exactly what I wanted to say. There are many users that want to test the last transports, they always want to have the new Barbie or they are interested on testing more private things on Tails. We should spend some time writing documentation like the one we have about VPN and Tor and similar ones, even if it is just linking to the Tor documentation pages. From the frontdesk POV, it would be great to have access to reasoning regarding this problems with an official tone, even if its to say 'we are never going to do that, is crazy!', that's why I hijacked this thread and asked about proxychains and obfs3 bridges. cheers 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] keeping up with pluggable transports by using TBB's Tor and tor-launcher
Hi, Patrick Schleizer wrote (15 Nov 2014 15:38:09 GMT) : > Idea: > - Come with a recent release of original TBB from TPO installed by > default with every new release of Tails/Whonix. > - Use the TBB, tor-launcher add-on and pluggable transports from TBB as > the new "system Tor". Indeed, this would allow us to stay on top of things, and probably make the UX clearer, since we would support just the same set of PTs as Tor Browser supports. I must say it's quite tempting. OTOH, given the amount of complicated stuff we already need to get the Tor Browser itself properly integrated in Tails, I'm not too thrilled at the idea of seeing more and more kludges added to do the same for PTs... but maybe an actual implementation wouldn't be that scary, and my fear would be proved to be irrational. > Seems like an approach that needs low maintenance from distribution > developers (Debian/Tails/Whonix) as well as from tor-launcher/TBB > developers? Needs no extraction of stuff like meek, flashproxy, > scramblesuit for packaging (policy conform) for Debian. Unless I'm mistaken, the server-side of these PTs needs to be in Debian anyway, so that people running Debian-based distros can actually provide bridges supporting these PTs. And then, while one is at it, I suspect that maintaining and packaging the client-side while one is at it doesn't involve much more effort. So, I'm not convinced by this specific argument. > This requires tor-launcher having a features such as: I'm afraid I don't understand why we would need any such changes for Tails. May you please clarify? 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] using meek with Tails
Hi, first, thanks *a lot* for reporting back! Emma Peel wrote (15 Nov 2014 12:11:55 GMT) : > On Tue, 11 Nov 2014 16:31:14 +0100 intrigeri wrote: >> Emma Peel wrote (11 Nov 2014 15:14:39 GMT) : >> > and saying that obsf3 bridges are not so available... is this true? >> >> What do you mean exactly with "not so available"? > Many of them are offline, he claims. I've not noticed that, but I can't say I've performed extensive testing. That would be a question for the Tor BridgeDB maintainers. > Another user is asking for 'proxychains' in Tails. Uh, what for? (Please answer in a new, dedicated sub-thread unless it really is on-topic.) > Maybe we can have a nice page mapping the different fancy new > transports and their tickets? > I see many issues tracked from https://labs.riseup.net/code/issues/7980 > but just the ones we are planning to add so far. Maybe we can add all > this under https://tails.boum.org/support/faq/#networking ? I'm not sure what problem you're trying to solve here. Let me try harder. If it's about "users always ask if $PT is supported and we need to be able to point them to some already written answer", then the list of bridges/PT types we support is maintained on https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/. Other bridges/PT types are not supported. Maybe we need a FAQ entry about "Is $PT supported in Tails?" that simply points to the corresponding doc. If it's about tracking the work that needs to be done, then the list of bridges/PT types we should support is vaguely maintained via Redmine tickets, in the "Tor configuration" category, generally marked as related to each other (#7980, #8243, #7909). Seems good enough to me. The main problem I see right now in this are is getting a clear idea of how we should prioritize adding support for these new PTs wrt. to each other. If it's about linking the users and dev areas somehow, then I think the problem to be solved needs to be clarified. Maybe the "Is $PT supported in Tails" FAQ could point to the relevant Redmine category in addition to the end-user doc, for the curious ones. If I totally misunderstood, I'm sorry, and please clarify :) 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] Fwd: the compromised keyboard AND the passphrase of the persistence
Hi, Ilia Alexeev wrote (18 Nov 2014 01:38:28 GMT) : >> > Is it possible to do semi-login (quasi-login) >> >> > after the password was entered by Florence? Can you realize such detour? I doubt we can get Florence in a usable state early enough in the login process. And anyway, I'm pretty sure that implementing this semi-login idea would require way more time/energy than fixing the actual problem, that is the lack of a virtual keyboard (and accessibility tools in general) in the Greeter. 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] Release schedule for Tails 1.2.1
Hi, anonym wrote (18 Nov 2014 10:11:33 GMT) : > So it seems the Firefox 31.3.0esr release will be delayed a week: > https://groups.google.com/forum/#!topic/mozilla.dev.platform/1McXdXSurZQ Yep. Note that this also moves the next releases as well (e.g. the January release will be on the 13th): https://wiki.mozilla.org/RapidRelease/Calendar > Who's available for testing the final 1.2.1 image on 2013-12-02? No. > In case there's a delay, who's available the day after, on > 2013-12-03? Yes. 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] Release schedule for Tails 1.2.1
anonym: > 2014-12-01 TBB 4.x based on Firefox 31.3.0esr is *hopefully* out >Tag 1.2.1 in Git >Build and upload 1.2.1 ISO and IUKs > 2014-12-02 Test (early CEST) and release (late CEST) Tails 1.2.1 > > Who's available for testing the final 1.2.1 image on 2013-12-02? In > case there's a delay, who's available the day after, on 2013-12-03? I can be there either way. -- sajolida ___ 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.2.1
anonym: > 2014-12-01 TBB 4.x based on Firefox 31.3.0esr is *hopefully* out >Tag 1.2.1 in Git >Build and upload 1.2.1 ISO and IUKs > 2014-12-02 Test (early CEST) and release (late CEST) Tails 1.2.1 > > Who's available for testing the final 1.2.1 image on 2013-12-02? In case > there's a delay, who's available the day after, on 2013-12-03? I can be there either way. -- sajolida ___ 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.
