Here's my current summary:
I think at least 3 projects are interested in sharing a computer to build all
or some of their release artifacts.
I don't know who actually wears an Infra hat other than Greg, but his response
was maybe.
Other feedback seems to be "if you do more work, then we don't have to ask
infra for anything". I don't know if that is an Infra response or not. Of
course we could do more work. The 3 RMs that tried and gave up didn't have to
give up. But they did because they don't have the time or desire to keep
figuring out why something didn't work for them. They could explore these
ideas as well. Maybe they will, maybe they won't. But to me, the point is
that it will be save the community much time and energy if we have one shared
machine that can crank artifacts. Most of us change computers every few years
and have to get set up all over again. Under this "do more work" logic,
builds.a.o doesn't have to exist. Communities can do more work and set up
their own Jenkins somewhere.
If someone with an Infra hat on tells me to go away, I will, but all of the
responses that amount to "do more work" really seem tangential. Either there
is going to be too much risk to allowing shared machines to commit code from
inside or outside of a.o, and either it will be a huge amount of work for Infra
or it won't.
Can we get back to discussing the risk and work aspects? I think the risk is
minimal. Someone would have to time the rogue changes so that it coincides
with other desired changes and we would have to miss those changes in the
review. What is the amount of work? Is it major work to add accounts and keys
for a non-person?
Thanks,
-Alex
On 1/8/19, 11:54 PM, "Hervé BOUTEMY" <herve.bout...@free.fr> wrote:
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
