On 2018/12/08 17:43:37, Alex Harui <aha...@adobe.com.INVALID> wrote:
> Gavin, Alan, Karl,
>
> Thanks for the information.
>
> This email implies that there is a Jenkins node that can commit something.
> What creds are used for that? Is there a buildbot user?
> https://lists.apache.org/thread.html/efed1ff44fbfe5770ea1574b2f53a5295ae8326c5a3a5feb9f88cd48@%3Cbuilds.apache.org%3E
>
> If so, I was imagining the following workflow:
>
> 1) Jenkins runs Maven release. I forgot about the PGP signing part. If
> there is no way to skip it, then can a buildbot "user" PGP sign it?
So I have long had an idea in the back of my head (I discussed it a little with
Hervé Boutemy) to leverage the work I did on the Jenkins SSH Agent plugin to
allow it to act as a GPG agent (since GPG Agent protocol is just an extension
of the SSH Agent protocol)
Or rather to act as a GPG Agent proxy.
The user would run a command locally to connect a tunnel of their local GPG
Agent process to Jenkins and then on to the specific build agent (probably by
having a build step that outputs a one time key and pauses the build until
connected)... thus the one time key allows you to ensure that only the build
agent you selected gets access to your GPG Agent.
This would enable builds on an ASF owned Jenkins that have been signed by the
user triggering the build without their GPG key ever leaving their machine.
> 2) RM downloads the artifacts and verifies them. The source package has to
> match the tag so I think that would detect any injections from other stuff
> running in Jenkins or elsewhere on the build server. There's been a recent
> discussion on reproducible binaries and if this workflow is approved I would
> make our binaries are reproducible, and that should again detect any
> injections from the build server.
> 3) RM adds his/her PGP signature to the artifacts. Not sure if there is a
> Maven way to do that.
Actually I had another idea (I briefly discussed with Brian Fox) namely if
Nexus allowed appending GPG signatures to staged artifacts... perhaps could be
written as a nexus plugin.
This would mean that the build artifacts could start off unsigned... or signed
with a one-time key of the build agent. As each vote is cast by committers,
they would upload the signatures to the relevant artifacts in the staging repo.
When the vote is closed and the artifacts are released they would be signed by
everyone who voted rather than the one signature of the RM.
> 4) Voting and other steps follow from there.
>
> These would not be continuously running jobs. They would have to be kicked
> off manually so it shouldn't add significant load, and we would know which
> commits came from buildbot so we could detect if anything went funky.
>
> Thoughts?
> -Alex
>
> On 12/8/18, 7:54 AM, "Gavin McDonald" <ipv6g...@gmail.com> wrote:
>
> additionally, nobody should have their creds stored anyway other than
> their
> own machine.
>
> On Sat, Dec 8, 2018 at 3:49 PM Allen Wittenauer
> <a...@effectivemachines.com.invalid> wrote:
>
> >
> >
> > > On Dec 7, 2018, at 11:56 PM, Alex Harui <aha...@adobe.com.INVALID>
> > wrote:
> > >
> > >
> > >
> > > On 12/7/18, 10:49 PM, "Allen Wittenauer"
> <a...@effectivemachines.com.INVALID>
> > wrote:
> > >
> > >
> > >
> > >> On Dec 7, 2018, at 10:22 PM, Alex Harui <aha...@adobe.com.INVALID>
> > wrote:
> > >>
> > >> Maven's release plugins commit and push to Git and upload to
> > repository.a.o. I saw that some folks have a node that can commit to
> the
> > a.o website SVN. Is anyone already doing releases from builds? What
> > issues are there, if any?
> > >
> > > It's just flat out not secure enough to do a release on.
> > >
> > > Can you give me an example of how it isn't secure enough?
> >
> >
> > The primary purpose of these servers is to run untested,
> > unverified code.
> >
> > Jenkins has some very sharp security corners that makes it
> > trivially un-trustable. Something easy to understand: when Jenkins is
> > configured to run multiple builds on a node, all builds on that node
> run in
> > the same user space. Because there is no separation between executors,
> it's
> > very possible for anyone to execute something that modifies another
> running
> > build. For example, probably the biggest bang for the least amount of
> work
> > would be to replace jars in the shared maven cache.
> >
> > [... and no, Docker doesn't help.]
> >
> > There are other, bigger problems, but I'd rather not put that
> out
> > in the public.
> >
> >
> >
>
> --
> Gav...
>
>
>
