did anybody try the intersting proposal from Christofer (doing like PCL4X)?
looks promising for Royale Regards, Hervé Le mardi 8 janvier 2019, 02:35:07 CET Hervé BOUTEMY a écrit : > 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" <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
