(Re-ordered the quoted email for more readable reply) On Fri, Dec 9, 2016 at 11:06 PM, Marek Marczykowski-Górecki <[email protected]> wrote: > Depending only on github repo permissions is against the rule of not > trusting the infrastructure.
I definitely agree, and on the "here's what we actually download and compile" there is no substitute for consistent signature verification. However, for the purpose of tracking what work is to be done, we already trust github very much. > As we don't trust the external infrastructure, everything downloaded > from the network have signatures checked - this include checking git > tags on git fetch/pull. And I think exactly this mechanism can be used > to mark reviewed code. So, a community member could push a code to > qubesos-contrib/... repo, then wait for it being reviewed - and when got > reviewed, will get tagged by qubes core team. This will allow (and > actually will trigger) build process. The purpose of the github PRs here would be to improve the workflow of a maintainer telling the world "Hey, here's a set of complete and locally-tested changes, please review." with two goals: 1) Help ensure things get reviewed in a timely fashion and don't get forgotten about. 2) Provide a clear default way to provide feedback in the case of unacceptable changes. This is a much more familiar workflow to people than a push of a signed tag meaning "please review this, and push another signed tag". What if these changes are unacceptable when reviewed? Do we open an issue? AFAICT PRs are just issues with additional user interface to refer to specific changes in exactly the manner we would need to poorly emulate with issues. The actual reviewing should happen on a developers local machine (not github UI), to: 1) verify that the changes being reviewed are indeed what the maintainer proposes (by verifying the maintainer's tag) 2) verify that all commits since the last review have indeed been reviewed (as determined by the reviewer's own last signed tag) Then it's a simple fast-forward of master pushing to close the PR. No additional trust in github besides essentially for to-do list management (which we already do). IMO something like this should already be the workflow for reviewing PRs to core (non -contrib) code. (Perhaps it is, idk.) > Also, I think it will be less work for qubes team to just stick tags > after reviewing the code, than merging pull requests (and handling > possible conflicts etc) - this should be a role of tool maintainer. I guess that answers: >> 3) How should patches to these contributed components from people >> other than the original author be handled? Should we require they be >> merged (or at least OK'd, perhaps with some timeout) by the original >> author? Slightly off-topic: This discussion reminds me that I should really get around to standing my PGP infrastructure back up and signing select mails again :) I suppose I'm a bit of a hypocrite in this regard! I stopped because the security of my key was depended on by others for code-signing, vulnerability reporting, and web-of-trust verification (I'm rather well cross-signed), and I deemed having my private key accessible to my entire daily-use machine to be an unacceptable risk. Of course, the entire reason for Qubes' existence is to decrease this category of risk, so perhaps it's time to reconsider. :) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_AFNG%2BPx3U_m%2BqvLFVAGv6oinT6cLT7jnF%3D2HLA5b%2BseQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
