yes, given Royale issue looks like network connectivity reliability (and I suppose numerous and large artifacts), deploying to a local file:// based repository then having a pure upload step from file:// rlocal repository to network based staging repository could be a solution that would be less intrusive than changing the full process
I don't have immediately a plugin in mind for such a process but I'll investigate Regards, Hervé Le lundi 7 janvier 2019, 22:18:50 CET Christofer Dutz a écrit : > 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" <[email protected]>: > > 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" <[email protected]> wrote: > > On Mon, Jan 7, 2019 at 12:23 PM Alex Harui > <[email protected]> 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 > > > >
