And there's the crux and there's the rub.

Perhaps at least some grease to the process could be applied by having a group that is allowed to apply approved patches. Many who are paying attention may immediately conclude that this does no good. But the point would be that gods would be very quick to approve patches where it is obvious that no security problems are being introduced while it is almost never trivial to quickly apply a patch because one must pretty thoroughly vet the patch and then must test whether the application of it actually broke something. So, once a patch is approved, a path applier could, when they had the time, decide that the patch is worth applying, apply it, test the results, and then revert the patch if needed. So that delegates what is often a non-trivial amount of work away from gods.

To complete some security details: Once a patch is approved, the author would no longer be allowed to modify the patch. When a patch applier applies an approved patch, the "current" patch is automatically approved. If there is no "current" patch, then the attempt to apply the patch is denied. Note that finding "the 'current' patch" involves scrolling through the most recently applied (few) patches until you find one that matches. Another possibility would be that modifying a patch unapproves it. But I would only allow that route for patches that have never been applied.

Note that denying the ability to modify something probably needs to be implemented within the canUpdateNode() system. Several previous attempts to deny the ability to modify have turned out to have loop holes if they didn't cause canUpdateNode() to return a false value (due to some poor security-related choices in the Everything codebase). But our new accessRule feature should make this easy to implement. And the "editing removes approval" feature is another likely place for a loop hole to appear. It would probably be better to allow the author to unapprove a node of theirs if it has never been applied (which would then allow them to edit it as a separate step).

On one minor technical point, there is no need to temporarily set $USER to -1. You just pass -1 (instead of $USER) to the updateNode() function.

- tye        

In reply to Re^2: RFC: Create a PatchAppliers group (crub) by tye
in thread RFC: Create a PatchAppliers group by jdporter

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.