Ich Verstehe dich! I you share with me do you mind if I share on dev@royale?
Sent from my iPhone > On Jan 7, 2019, at 1:55 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi Dave, > > Well it was naturally off list. > > Chris > > Outlook for Android<https://aka.ms/ghei36> herunterladen > > ________________________________ > From: Dave Fisher <w...@apache.org> > Sent: Monday, January 7, 2019 10:32:38 PM > To: builds@apache.org > Subject: Re: Can we package release artifacts on builds.a.o? > > Hi Chris, > > Thank you for providing Carlos with instructions. Was that on or off list? > > Regards, > Dave > > Sent from my iPhone > >> On Jan 7, 2019, at 1:18 PM, Christofer Dutz <christofer.d...@c-ware.de> >> wrote: >> >> 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 >> >> >> >> >
