Hi Alex,
Ways to do bad stuff with just a pom.xml:
- simply adding a dependency to a vulnerable library, even an intentionally
staged malicious one.
- Adding an evec-maven-plugin to execute anything on the host machine
- Generate code
- Like I introduced into the FlexJS maven build: Patch/Modify source files
Guess the is what I could think of in 5 minutes...
Ways to do bad stuff by just changing one-line versions:
And changing the version of a dependency to a known vulnerable version would be
such a one-liner.
I'm currently introducing vulnerability checks into all of my builds, so I'm
bumping dependencies to unvulnerable versions ...
doing this the other way around would introduce vulnerabilities.
Connectivity problems:
Regarding network problems ... on my way to Montreal I staged the first RC for
Apache PLC4X in a plane ...
it took about 3 hours to upload cause of network problems and latencies.
Maven usually works around connectivity problems quite nicely and reliably.
So all in all I would suggest you sort out the problems in the build with
someone with experience.
I already told Carlos how he could deploy to a local directory during the
release itself and then use another
plugin to stage that release independently.
If it aborts, you just re-start the deployment and close the repo as soon as
all passes.
Chris
Am 07.01.19, 19:39 schrieb "Alex Harui" <aha...@adobe.com.INVALID>:
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
