-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Dec 09, 2016 at 10:46:25PM -0500, Jean-Philippe Ouellet wrote: > On Fri, Dec 9, 2016 at 8:59 PM, Marek Marczykowski-Górecki wrote: > > I think handling contributions there can be easily automated with > > https://github.com/QubesOS/qubes-issues/issues/1818 > > So, the only actual work needed, will be reviewing changes, then adding > > a signed tag. Everything else will be handled automatically. > > I think an important open question is: How should code-reviews be tracked? > > I think qubes-builder's model of not having untrusted code in the > place that trusted code may be expected [1] is a good model. The same > can be applied here with respect to pushing un-reviewed vs. > peer/qubes-core reviewed code to "official" repos. > > I imagine this: > 1) A community member comes up with some cool thing they want to add > to qubes, which is clearly additional separate functionality that does > not belong in a core repo. (Thinking qubes-app-linux-* here.) > 2) The community member writes said code in their own repo. > 3) When they consider it v1.0, they propose for it to be added to the > set of core-approved community-contributed things. > 4) The code is reviewed by core qubes people (and hopefully other > community members) and a the reviewed copy is added to a newly created > github.com/qubesos-contrib/qubes-app-foo-bar repo. > 5) The community member makes some additional changes (features, bug > fixes, etc.) and pushes it to their own repo, and opens a pull request > to the qubesos-contrib/... repo. > 6) The updates are reviewed, and if OK, merged. > > This maintains the invariant that qubesos-contrib/... repos (all heads > of all branches) are always in a reviewed (and hopefully trustworthy) > state, which I argue is a nice property.
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. Depending only on github repo permissions is against the rule of not trusting the infrastructure. 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. > Some issues with this: > 1) There is no longer any reason for the community member (and author > of the contributed component) to be a member of the 2nd github > organization (no nice badge on their github profile, which for some > may serve as incentive to contribute) > 2) If everything is to be reviewed before merging, then there is less > of a reason to have a separate qubesos-contrib org in the first place. > 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? > > [1]: > https://www.qubes-os.org/news/2016/05/30/build-security/#the-sources-verification-bug - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYS389AAoJENuP0xzK19cs8rEH/RNc9/yy2wGNxbQNXllRcigU VhJ/NASRA5nafn+JahSySJy7zEmH6YatMg/hmWId+hS9MNsW0DKn41XVTSwdbD6L L2eJHDDP4c1SGEBBeps/D5gtjEc0Vabc58L1IfqGcDSM8tQgkQ2xz93DtQrJsYTp CkCepxBSvtDQdE+eJK+KMd+LFPnEBfPsSIUdlgLOpD58ejM8beYo18HDSJcIRXka qsuTHl5vKCTKDamVGXXIftavLMOdBs+vhgSoBp0z7HD+FP6JJLwmCS4i/45GJGpr LmM8deH3XDvecNjNs7e3flbk8rKm3pKdUglLhBGUEADNOJpE7jaxain/I8nlznc= =qJcT -----END PGP SIGNATURE----- -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161210040620.GK16264%40mail-itl. For more options, visit https://groups.google.com/d/optout.
