www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Can we package release artifacts on builds.a.o?
Date Sun, 20 Jan 2019 17:43:30 GMT
FYI, I managed to build Royale using Maven using Royale instructions [1]
The only missing instruction was about mvn install-file for airglobal-20.0.swc.

I measured what you deploy to the repository: with 206 MB of content for asjs containing a
distribution of 2 files of 50 MB each, I can understand that any network issue can cause a
failure here and that's unpleasant.

I just added a documentation in maven-deploy-plugin on how to deal with network issues [2]:
I'm pretty sure the local staging directory strategy could perfectly match your case.

Hope this helps,

Hervé

[1] https://github.com/apache/royale-asjs/wiki/Build-Apache-Royale-with-Maven

[2] https://maven.apache.org/plugins-archives/maven-deploy-plugin-LATEST/examples/deploy-network-issues.html

Le mercredi 9 janvier 2019, 08:54:10 CET Hervé BOUTEMY a écrit :
> 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" <aharui@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" <gstein@gmail.com> wrote:
> > >         On Mon, Jan 7, 2019 at 12:23 PM Alex Harui
> > > 
> > > <aharui@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





Mime
View raw message