[Tails-dev] Fw: Electrum doc wrt. SPV security
Begin forwarded message: Date: Sun, 15 Feb 2015 23:19:43 + From: Minoru min...@riseup.net To: intrigeri intrig...@boum.org Subject: Re: [Tails-dev] Electrum doc wrt. SPV security Intrigeri, Here is what I would write in the Electrum documentation: Do not blindly trust the bitcoin balance that Electrum displays. Electrum connects to remote servers that can withhold transactions from the client. Read more about the vulnerabilities of SPV in the Bitcoin Developer Guide [https://bitcoin.org/en/developer-guide#simplified-payment-verification-spv].; In addition, I saw that the Electrum documentation stated that bitcoin is not anonymous. This statement is absolutely true, but I would remind the user of a method to increase privacy. After “bitcoin is not anonymous,” I would write: “To increase privacy, remember to use a separate receiving address for each transaction.” If you ever need someone to write more bitcoin related documentation, I would be happy to contribute my knowledge and time. Cheers, Minoru On Sun, 15 Feb 2015 19:14:18 +0100 intrigeri intrig...@boum.org wrote: Hi Minoru, Minoru wrote (15 Feb 2015 14:11:10 GMT) : I want to contribute to the Tails documentation and I was redirected to you. Thanks, this is useful information. How do you suggest we convey the message to the user, without going too deep into technical details? (Still, it would be useful to have a URL to point them to for more info if they wish to.) For contributing to the documentation, surely our frontdesk has already pointed you to the relevant page, but just in case they forgot, here it is: https://tails.boum.org/contribute/how/documentation/ 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] Automated builds specification
On Wed, Feb 11, 2015 at 11:29:45PM +0100, intrigeri wrote: Hi, bertagaz wrote (18 Jan 2015 16:39:28 GMT) : 0. Do we think we might also need or want a mechanism to blacklist a branch, or we should just assume that our algos will only select the right ones and not hit any corner cases? I think this is a good question, that deserves more thought. Unfortunately I've not found any discussion about it on the blueprint nor on the list, not even an example use case for such a blacklist, so right now — sorry to be harsh — it looks like a technical idea that's looking for a problem it might help solving. It's just that, something that did pop up in my head while writing the blueprint, but I didn't find much corresponding branches while watching the unmerged ones during the 1.3 release cycle. So, what would be the use cases? I can think of a few potential ones: 1. A branch that satisfies the criteria for automatic builds, but starts failing continuously, e.g. because its developer is on vacation for 2 weeks. = as far as I understood, only that branch's developer is nagged by failure notifications, so... who cares if it fails to build for 2 weeks? 2. Branches that modify only the doc or website = indeed, at first glance it seems a bit sad to spend CPU cycles on building and potentially testing such branches. OTOH, these branches, like any other, must not break the build, otherwise they're not fit for merging, so it makes sense to build an ISO (yes, an ISO, not only the website: we have quite a few things in the ISO build process that somewhat depend on the website, run `git grep usr/share/doc/tails/website -- config' if unconvinced). And they must not break functionality either, so IMO it makes sense to run the automated test suite on it too (again, we have quite a few runtime functionality that depends on the bundled static website). Ack, sounds reasonable. However from what I've seen, it sometimes means a lot of branches so I wonder if we scaled our infra enough for that, as we didn't include this branches in our maths since the beginning of the discussion. bertagaz, any other use case you were thinking of? Not really at the moment. bert. ___ 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] Automated builds specification
Hi, Thx for the extensive review! On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote: We're already drafted some scenario's on: https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/ I have a few concerns, though: * Scenario 2 : developer doesn't make it clear if branch T is build *after being locally merged into branch B*, or not. Given that's what we're really interested in, and given Scenario 1 : reviewer is clearer (answer is: yes), I guess the answer is yes here too, but this should be clarified. IIRC that was something Alan had troubles with, as not being the way she usually work on a feature branch, which I think was more close to Work work work on the branch, and then when the feature is ready, merge the base branch in it. So she usually do not merge the base branch very often. But I agree this is not the best way to go, so if Alan doesn't come up with a block on this, I agree to add the clarification. * I see no statistics about how many ISOs we are *currently* building each day. So it's not clear to me if our current setup can support building N more branches, once a day each. It would be useful to have this number (e.g. raw number per day during the 1.3 release cycle, and daily average). Of course we can fix that later (either by throwing more hardware at it, or by tweaking the branch selection algorithm a bit, or by decreasing the build frequency a bit for some branches based on some criteria), but if we can know *right now* that the designed plan cannot possibly work, then I would find it a bit sad to invest time into it. That's a logical awesome idea I'm ashamed not to have had sooner. Still, it seems that it comes too late, after some searching it appears that our Jenkins don't keep much stats. I'll extend the jjb setting that remove build logs after 1 day. The Global build stats Jenkins plugin [1] seems interesting to display the stats once more logs are kept. Shall I install it? * Scenario 3 : RM says I need to know when a branch FTBFS, but I see no notification mechanism planned, so... how is the RM supposed to know. Also, whenever stalled topic branches start failing, this can imply an avalanche of daily email to the RM, who will of course start ignoring all email from Jenkins and then we've lost. I'm particularly worried about this topic since anonym (our RM most of the time) didn't comment on this proposal yet, and has already expressed concerns about this kind of issues. I think anonym did comment on this proposal, he did a review of this blueprint already. But I agree the RM notification part is not very clear. We could make it so that the RM is emailed when a daily build job fails, the build failed on git push one being sent to the commit author anyway, according to our scenarios. Of course the commit author would also be notified for the daily ones too. If that's still too much from the RM point of view, we could have the RM notified only the first time a daily job fails. That seems to make sense to me: the RM gets a notification in the mailbox once a day for failed jobs, and then he/she either fix it, or ask someone to work on that. To have a developer claiming to Jenkins he/she is now responsible of that branch (and thus is getting the next notifications), he/she would just have to do a dumb commit on the branch. One thing that this question also raise is the fact that the RM is not always the same person, so I'm wondering how to have jenkins notifying the right email depending on who is the RM for the next release. First thing that come in top of my mind is... a schleuder address. :) I assume these concerns (except the 2nd one probably) are not blocking wrt. starting to implement stuff, so: Go! Great! To end with, I find two things confusing in the rest of the document: * Scenario numbering is reset in the Future ideas section, so one cannot simply refer to scenario 2 unambiguously, without making it clear if they're speaking of scenario 2 in the Scenarios section, or of scenario 2 in the Future ideas section; I suggest you avoid assigning duplicated scenario identifiers. Fixed. * The tag T notation (undefined) is somewhat conflicting with the branch T one that's defined earlier. Fixed. bert. [1] https://wiki.jenkins-ci.org/display/JENKINS/Global+Build+Stats+Plugin ___ 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] Automated builds specification
bertagaz wrote (16 Feb 2015 12:03:12 GMT) : Ack, sounds reasonable. However from what I've seen, it sometimes means a lot of branches so I wonder if we scaled our infra enough for that, as we didn't include this branches in our maths since the beginning of the discussion. This seems like a serious bug in this discussion process. May you please then provide example numbers that match what the proposed algorithm would output, so that we can reason about it? ___ 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.
