Re: [Tails-dev] Getting rid of review'n'merge email on this list
intrigeri: some of us are tired of having to ask for review'n'merge on this list, duplicating the (semantically more powerful) action of setting a ticket as Ready for QA in Redmine. Recently, we tend to forget more and more often to send such email; moreover, some teams (e.g. the doc and test suite teams) have simply stopped sending them already. People on this list are probably glad that we don't open a thread for each one of our documentation tickets :) Nevertheless, at least I have always resisted getting rid of these email, on the grounds that we have no other working, tested and advertised way of following what changes are proposed to go into Tails, and of voicing concerns *before* changes land in our release Git branches. I still strongly feel we need that, but perhaps I'm overdoing it a little bit. I'm not in favor of completely getting rid of them. I think that even if we use one of the solutions that you are proposing, we should still notify the list when we feel that more than two people should have a look at a branch. For example, when doing non-trivial changes to the code or when writing big chunks of documentation. I will at least continue doing that. I know that this might be completely subjective but I believe it will work and be better than do reviews only on Redmine. The point is to find the best signal/noise ratio on the list. A) Decide that the Atom feed is good enough and document it, with its aforementioned limitation (so that people can adjust their config). I volunteer to do that if we decide to go this way. Sounds good. -- 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] #8999: Claws Mail leaks cleartext of encrypted email to the IMAP server [was: Re: PGP MIME is insecure (for me)]
sajolida: During the last monthly meeting I volunteered to issue a security advisory about the fact that Claws saved unencrypted emails to Drafts and Queue folders on the IMAP server. I've been gathering info and doing shitloads of testing, and I think we have (almost) all the information to explain this properly and fix what can be fixed in Tails. So please review and comment on the synopsis from #9161. During the monthly meeting I realized that my analysis was actually pretty wrong all the way. Thanks everybody for correcting me! So here is a draft of the security advisory, please review and comment: https://tails.boum.org/blueprint/claws_mail_leaks_plaintext_to_imap/ I'd like to publish it on Thursday morning (or early afternoon) to have it visible over the week-end before the release. I pointed upstream to it on http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2965#c9. On Thursday, I'll also integrate this in the Claws Mail doc and fix #9159 at last. -- 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] Getting rid of review'n'merge email on this list
On 04/05/2015 17:35, intrigeri wrote: Besides, I bet that some list subscribers would be glad if such notifications were opt-in. Hello, I'm a lurker on this mailing list, therefore my opinion is barely important. I actually read 10% of such review'n'merge emails with interest. It's a good way for me to follow what's going on, take a look at the code, etc. A) Decide that the Atom feed is good enough and document it, with its aforementioned limitation (so that people can adjust their config). I volunteer to do that if we decide to go this way. B) Decide that it's not good enough, and then look into a push notification solution. Or, set up a dedicated mailing-list that a rss2email instance will email. That rss2email will need to run as often as reasonably possible, so that it misses as few Ready for QA tickets as possible.. any of these solutions will be just as good for me. -- boyska gpg --recv-keys 0x58289ca9 ___ 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] Build failed in Jenkins: build_Tails_ISO_experimental #2244
See https://jenkins.tails.boum.org/job/build_Tails_ISO_experimental/2244/ -- [...truncated 14896 lines...] Hit http://ftp.us.debian.org unstable/non-free i386 Packages/DiffIndex Hit http://ftp.us.debian.org unstable/contrib Translation-en/DiffIndex Hit http://ftp.us.debian.org unstable/main Translation-en/DiffIndex Hit http://ftp.us.debian.org unstable/non-free Translation-en/DiffIndex Hit http://ftp.us.debian.org testing/main i386 Packages/DiffIndex Hit http://ftp.us.debian.org testing/contrib i386 Packages/DiffIndex Hit http://ftp.us.debian.org testing/non-free i386 Packages/DiffIndex Hit http://ftp.us.debian.org testing/contrib Translation-en/DiffIndex Hit http://ftp.us.debian.org testing/main Translation-en/DiffIndex Hit http://ftp.us.debian.org testing/non-free Translation-en/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/main i386 Packages/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/contrib i386 Packages/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/non-free i386 Packages/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/contrib Translation-en/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/main Translation-en/DiffIndex Hit http://ftp.us.debian.org wheezy-backports/non-free Translation-en/DiffIndex Reading package lists... W: Ignoring Provides line with DepCompareOp for package php-psr-log-implementation W: You may want to run apt-get update to correct these problems Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Building dependency tree... Reading state information... debian-archive-keyring is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Hit http://deb.tails.boum.org devel Release.gpg Hit http://deb.torproject.org obfs4proxy Release.gpg Hit http://security.debian.org wheezy/updates Release.gpg Hit http://ftp.us.debian.org wheezy Release.gpg Hit http://deb.tails.boum.org devel Release Hit http://deb.tails.boum.org devel/main i386 Packages Hit http://deb.torproject.org wheezy Release.gpg Hit http://security.debian.org wheezy/updates Release Hit http://ftp.us.debian.org experimental Release.gpg Hit http://deb.torproject.org sid Release.gpg Hit http://security.debian.org wheezy/updates/main i386 Packages Hit http://ftp.us.debian.org jessie Release.gpg Hit http://deb.torproject.org obfs4proxy Release Hit http://security.debian.org wheezy/updates/contrib i386 Packages Hit http://deb.torproject.org wheezy Release Hit http://security.debian.org wheezy/updates/non-free i386 Packages Hit http://ftp.us.debian.org unstable Release.gpg Ign http://deb.tails.boum.org devel/main Translation-en Hit http://deb.torproject.org sid Release Hit http://security.debian.org wheezy/updates/contrib Translation-en Hit http://deb.torproject.org obfs4proxy/main i386 Packages Hit http://ftp.us.debian.org testing Release.gpg Hit http://security.debian.org wheezy/updates/main Translation-en Hit http://security.debian.org wheezy/updates/non-free Translation-en Hit http://ftp.us.debian.org wheezy-backports Release.gpg Hit http://deb.torproject.org wheezy/main i386 Packages Hit http://ftp.us.debian.org wheezy Release Hit http://deb.torproject.org sid/main i386 Packages Hit http://ftp.us.debian.org experimental Release Hit http://ftp.us.debian.org jessie Release Hit http://ftp.us.debian.org unstable Release Hit http://ftp.us.debian.org testing Release Hit http://ftp.us.debian.org wheezy-backports Release Hit http://ftp.us.debian.org wheezy/main i386 Packages Ign http://deb.torproject.org obfs4proxy/main Translation-en Hit http://ftp.us.debian.org wheezy/contrib i386 Packages Ign http://deb.torproject.org wheezy/main Translation-en Hit http://ftp.us.debian.org wheezy/non-free i386 Packages Ign http://deb.torproject.org sid/main Translation-en Hit http://ftp.us.debian.org wheezy/contrib Translation-en Hit http://ftp.us.debian.org wheezy/main Translation-en Hit http://ftp.us.debian.org wheezy/non-free Translation-en Hit http://ftp.us.debian.org experimental/main i386 Packages/DiffIndex Hit http://ftp.us.debian.org experimental/main Translation-en/DiffIndex Hit http://ftp.us.debian.org jessie/main i386 Packages Hit http://ftp.us.debian.org jessie/contrib i386 Packages Hit http://ftp.us.debian.org jessie/non-free i386 Packages Hit http://ftp.us.debian.org jessie/contrib Translation-en Hit http://ftp.us.debian.org jessie/main Translation-en Hit http://ftp.us.debian.org jessie/non-free Translation-en Hit http://ftp.us.debian.org unstable/main i386 Packages/DiffIndex Hit http://ftp.us.debian.org unstable/contrib i386 Packages/DiffIndex Hit http://ftp.us.debian.org unstable/non-free i386 Packages/DiffIndex Hit http://ftp.us.debian.org
[Tails-dev] review and merge bugfix/9327-disable-starttls-warnings
Ticket: #9327 - Claws and Tor shouldn't warn on StartTLS connections to port 110 (POP3) and 143 (IMAP) Branch: bugfix/9327-disable-starttls-warnings into testing We've been carefully training our users to click through security warnings relayed from Tor by Vidalia when connecting to their emails server using StartTLS. I understand the idea behind this option in Tor but I think that the remedy in this case is worse than the cure as more and more email providers are advertising StartTLS and preventing plaintext connections anyway. This is for example the only working configuration to connect to Riseup and the option they document on their help page (though they're not mentioning the warning). https://help.riseup.net/en/email/clients/claws I also think that this will reduce a bit the load on frontdesk after the Claws Mail advisory is out. That's why I'm proposing this for 1.4. Tested directly in Tails but I haven't built an ISO. -- 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.
[Tails-dev] A suggestion regarding the kernel that Tails uses
The website of Tails claims that Tails is free software. But recently I've learned that it isn't quite so. Apparently Tails uses the version of Linux that contains proprietary binary blobs. In my opinion that is quite weird considering that the kernel that Debian GNU/Linux uses doesn't contain binary blobs at all. Tails developers must have thought that getting Tails to boot up on as many kinds of hardware as possible is important. But I would argue that security is more important than that, because as you know since the source code of those binary blobs is not available nobody can really verify what they do. And Tails is a distribution that claims it focueses on security and privacy, not on hardware compatilibity. So I would suggest that Tails developers would do one of the following: 1. Get rid of the kernel that contains binary blobs and replace it with a one that doesn't contain them. Or if this is asking too much 2. Make it clear that Tails indeed isn't completely made up of free software on your website. ___ 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.4.1] feature/5623-Installer-should-refuse-empty-device
Hi, Ticket: https://labs.riseup.net/code/issues/5623 Feature branch: https://git-tails.immerda.ch/kurono/liveusb-creator/log/?h=feature/5623-Installer-should-refuse-empty-device Could you please review and merge? Thanks, kurono ___ 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] Getting rid of review'n'merge email on this list
sajolida wrote (05 May 2015 13:45:39 GMT) : I'm not in favor of completely getting rid of them. I think that even if we use one of the solutions that you are proposing, we should still notify the list when we feel that more than two people should have a look at a branch. For example, when doing non-trivial changes to the code or when writing big chunks of documentation. I will at least continue doing that. I know that this might be completely subjective but I believe it will work and be better than do reviews only on Redmine. The point is to find the best signal/noise ratio on the list. Full ack! ___ 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] Getting rid of review'n'merge email on this list
On 05/05/2015 08:42 PM, intrigeri wrote: sajolida wrote (05 May 2015 13:45:39 GMT) : I'm not in favor of completely getting rid of them. I think that even if we use one of the solutions that you are proposing, we should still notify the list when we feel that more than two people should have a look at a branch. For example, when doing non-trivial changes to the code or when writing big chunks of documentation. I will at least continue doing that. I know that this might be completely subjective but I believe it will work and be better than do reviews only on Redmine. The point is to find the best signal/noise ratio on the list. Full ack! My only relevant piece of input was to suggest what sajolida just said. Other than, as intrigeri already know, I welcome this move with my full heart, and have sometimes (mistakenly?) been practicing it before its time. :) 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] Getting rid of review'n'merge email on this list
On 05/04/2015 05:35 PM, intrigeri wrote: I see two options from this point: A) Decide that the Atom feed is good enough and document it, with its aforementioned limitation (so that people can adjust their config). I volunteer to do that if we decide to go this way. B) Decide that it's not good enough, and then look into a push notification solution. Or, set up a dedicated mailing-list that a rss2email instance will email. That rss2email will need to run as often as reasonably possible, so that it misses as few Ready for QA tickets as possible.. With my OMG we need to provide a Perfect™ way to track this stuff hat on, of course I'm inclined to prefer (B). But realistically, I believe that (A) will be good enough for 99.99% of use cases I care about, and our sysadmin team is overloaded with new services design help + deployment requests already, so the benefits of (B) don't seem worth adding it to that team's plate. It seems we can get a perfect solution easier by having an Atom feed for both to Ready for QA and Fix committed. Full background: (21:31:37) anonym: intrigeri: actually, I just thought of something you said in your email re: killing review'n'merges (21:33:38) anonym: intrigeri: Goal: enough time to voice concerns *before* changes land in our release Git branches (21:33:38) anonym: Problem with solution A: if a ticket was marked as Ready for QA, and then review'n'merged, and then flagged as Fix committed, all that between two fetches of my feed reader, then I would never get any notification for that ticket (21:33:57) anonym: I don't see how a review'n'merge email would have avoided that problem (21:34:19) anonym: it would be sent at the same time as the ticket was marked Ready for QA (21:34:24) anonym: so you would still miss it (21:34:40) intrigeri: anonym: Right, a review'n'merge email would not solve the before part. (21:35:16) intrigeri: anonym: But in 99% of cases, it'll still allow interested control freaks^W^Wpeople to notice the change before next release. (21:35:39) anonym: intrigeri: so, augment solution A with also subscribing to Fix committed (21:36:04) anonym: a bit more noise, but oh well (21:36:06) intrigeri: anonym: you're totally right. awesome! 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:1.4] feature/9340-Linux-from-Stretch
Hi, as explained on #9340, without this change, our build system will very soon start producing unbootable ISO images. Please merge into stable, testing, devel and feature/jessie. Filed #9341 for the next steps (once Linux 4.0 migrates to Debian testing). 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] Getting rid of review'n'merge email on this list
intrigeri: Hi, some of us are tired of having to ask for review'n'merge on this list, duplicating the (semantically more powerful) action of setting a ticket as Ready for QA in Redmine. Recently, we tend to forget more and more often to send such email; moreover, some teams (e.g. the doc and test suite teams) have simply stopped sending them already. [snip detailed explanations] Very good point. I see two options from this point: A) Decide that the Atom feed is good enough and document it, with its aforementioned limitation (so that people can adjust their config). I volunteer to do that if we decide to go this way. B) Decide that it's not good enough, and then look into a push notification solution. Or, set up a dedicated mailing-list that a rss2email instance will email. That rss2email will need to run as often as reasonably possible, so that it misses as few Ready for QA tickets as possible.. With my OMG we need to provide a Perfect™ way to track this stuff hat on, of course I'm inclined to prefer (B). But realistically, I did not expect otherwise from you with that hat on ;) From my point of view (B) would be the Perfect™ solution, but... read on. I believe that (A) will be good enough for 99.99% of use cases I care about, and our sysadmin team is overloaded with new services design help + deployment requests already, so the benefits of (B) don't seem worth adding it to that team's plate. I should probably simply start using a feed reader and then I'll be part of that 99.99% of people :) See if it works out for some time and if not, switch to solution (B)? Thoughts, opinions? 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.
