[Tails-dev] 我可开增 值(专 用)发、-票(普通)可加薇信电话:1376:448 8837 张财务 。。+\}^@].}
wWEDb___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
intrigeri: > So I propose that we drop the "QA Check" field and instead, introduce > a "Needs Validation" status. Good idea! Works for me. What would happen to tickets that go back-and-forth between the main author and the reviewer? Would they stay in "Needs Validation" or go back-and-forth between "In Progress" and "Needs Validation"? -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
intrigeri: > So I propose that we drop the "QA Check" field and instead, introduce > a "Needs Validation" status. Sounds much simpler, awesome! +1 > Given we now have "mentions" (@nickname) on our Redmine, for the > majority of cases, when the requested info can presumably be provided > cheaply and quickly, I think we should use mentions and not reassign > the ticket. And when I'm mentioned, if I realize that providing the > requested info needs will take me great amounts of work, I should > do whatever works for me to track this work, be it on a new ticket > or my personal offline organization tools. I quite like this feature and have set up filter rules in my email client for the resulting redmine notifications I receive so I don't miss them. However, I wonder how this works out if you don't do something like that. I also fear that the ad hoc tracking of "mentions" that you propose above is easy to forget. I just had a half-baked idea that might have some merit: say I work on ticket X and need info about "foo" from intrigeri. Then I just create a subticket Y of X called "Info needed: foo" and assign it to intri. When intri has posted the information about "foo" to X he can then mark Y as resolved. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
Hello, On 25.03.19 10:10, Daniel Kahn Gillmor wrote: > On Sun 2019-03-24 11:36:11 +0100, intrigeri wrote: >> Thoughts? >> >> I'll be happy to implement this proposal. > > I'm not a regular contributor, so you should weight my opinion very > lightly, but this all sounds quite to me. > > The more i see technical systems in actual use, the more i think that > simpler tooling is better and more likely to be used effectively, even > if it is not as nuanced. > > The argument for nuance is that it can typically represent reality more > closely than the simpler view. But if, in practice, that nuance isn't > widely understood, or is accidentally misused, then that particular > advantage is actually a disadvantage. > > Your proposal sounds simpler and therefore more likely to be accurate. I'm all for simplifications of workflows :) Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi!
On 22.03.19 02:24, Daniel Kahn Gillmor wrote:
> Is the concern that it's too expensive to maintain both the extension
> and the javascript going forward?
Ideally we'd only maintain one of those, but I think your idea is good:
if we could increase verification by having an internal mechanism, this
would be an improvement. However, the question remains: what happens if
an attacker controls the website?
> If the expense of maintaining the extension is too much, i wonder
> whether image verification is the ultimate concern at all. For example,
> should we be considering other approaches like external, spot-checked
> download verification with monitoring and reporting, as some measure of
> resilience against non-targeted attack? (maybe this is already in place
> and i just don't know about it)
I'm not quite sure what you mean but we regularly and automatically
check that all the mirrors serve correct images ({IMG, ISO} + SIG are
checked), independently of the individual verification that users should
do when downloading an image. But there might be a delay with us
reacting to this if a mirror is compromised.
Cheers!
u.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
On Sun 2019-03-24 11:36:11 +0100, intrigeri wrote: > Thoughts? > > I'll be happy to implement this proposal. I'm not a regular contributor, so you should weight my opinion very lightly, but this all sounds quite to me. The more i see technical systems in actual use, the more i think that simpler tooling is better and more likely to be used effectively, even if it is not as nuanced. The argument for nuance is that it can typically represent reality more closely than the simpler view. But if, in practice, that nuance isn't widely understood, or is accidentally misused, then that particular advantage is actually a disadvantage. Your proposal sounds simpler and therefore more likely to be accurate. --dkg signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi! On 22.03.19 15:47, Nicolas Vigier wrote: > On Fri, 22 Mar 2019, sajolida wrote: >> Whether there's a security loss for the 20% of users who currently use >> the extension is precisely what we are asking more opinions about. >> >> For example, jvoisin's primary reaction on this thread is that it's >> doesn't have any significant downsides. >> >> What makes you think that doing the verification in the extension would >> be less secure than doing the verification on the website? What kind of >> attacks are we talking about here? > > It seems the extension is currently only downloading an unsigned json > file with https to verify the checksums, so someone controlling the > website could return a bad json file. Correct. > So it looks like in both cases (the extension and javascript on the > website), an attacker controlling the website could make it possible > for a bad download to be seen as good by the user. However there is > still maybe a small difference: > - with javascript on the website, an attacker controlling the website >could just disable the verification and claim that any download is >good. Correct. > - with the extension, an attacker controlling the website could replace >the json file with one that contain a different checksum. However >they have to guess what the user will have downloaded from the mirrors, >which is maybe not easy if only one of the mirrors is bad. This is >assuming that the extension only accepts json files containing only >one value for the checksum, which I don't know if it is the case. The JSON file can technically contain many files and their checksums. > With the current version of the extension, I don't know if it makes a > big difference. However if there was some plan to improve the extension > to make it verify gpg signatures, then that could be a big difference. Agreed. Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
