Hi Greg,
Thanks for the history. I agree with the general problem, however, for Royale,
I think the problem is constrained, but I could be wrong. I don't think there
are exploits from things like missing semicolons and other code exploits that
can be executed against pom.xml files, so the Royale reviewers are first
looking to see if bot changed any other files. Maybe Maven experts can tell us
what kinds of exploit could be hacked into a pom.xml.
Could you answer another question? What is the current state of SVN/Git
integration? Could we spin up an SVN clone of our Git repos, restrict the bot
via SVN, then sync back from SVN to Git (all from Jenkins)?
Thanks,
-Alex
On 1/7/19, 10:30 AM, "Greg Stein" <gst...@gmail.com> wrote:
On Mon, Jan 7, 2019 at 12:23 PM Alex Harui <aha...@adobe.com.invalid> wrote:
>...
> I still don't get why allowing a bot to commit to a Git repo isn't
> auditable. The changes should all be text and sent to commits@ and the
> RMs job is to verify that those commits are ok before putting the
artifacts
> up for vote. I'd even try to make an email rule that checks for commits
> from buildbot and flags changes to files that are outside of what we
> expected.
>
The historic position of the Foundation is "no ability to commit without a
matched ICLA". That is different from "we'll audit any commits made by
$bot". The trust meter is rather different between those positions,
specifically with the "what if nobody reviews? what if a commit is missed?
what if that added semicolon is missed, yet opens a vuln?" ... With the
"matched ICLA" position, the Foundation has the assurance of *that*
committer, that everything is Good. ... Yet a bot cannot make any such
assurances, despite any "best effort" of the PMC to review the bot's work.
It is likely a solvable problem! My comments here are to outline
history/policy, rather than to say "NO". These are just the parameters of
the problem space.
Cheers,
-g
InfraAdmin
