Back on this topic, the recent post on Jenkins has me thinking again.
Jenkins users are deploying directly to Nexus with builds.
Isn't that speaking out of both sides of our mouths at the same time, if Java
developers can push release builds directly to Nexus but non-Java developers
can't?
Perhaps I'm misunderstanding...are the Nexus-published builds not treated the
same because they're not on dist.apache.org? Or are they not release versions?
I'm just asking for equal treatment here.
-Joan
----- Original Message -----
From: "Alex Harui" <aha...@adobe.com>
To: builds@apache.org, woh...@apache.org
Sent: Saturday, December 8, 2018 1:52:14 PM
Subject: Re: Can we package release artifacts on builds.a.o?
Good to know it isn't just me.
I could be wrong, but I believe the "policy" at Apache is only that a human
must verify the packages and PGP sign them. The packages can be built on
another machine.
-Alex
On 12/8/18, 10:48 AM, "Joan Touzet" <woh...@apache.org> wrote:
I would like to see support for something like this as well, even if it
came down to individual VMs/donated HW per project, locked down by project -
only project X can use build machine X'.
Automated repeatable builds actually *increases* trust vs. who knows what a
release manager has running on their workstation. At this point, I trust Docker
builds with published, auditable cryptographic hashes per layer more than I
trust some Apache releases.
I don't actually believe that all projects in the Apache world are actually
following the strict edict of "human must run the build and push any binary
release," but I'm not going to point fingers.
-Joan
----- Original Message -----
From: "Alex Harui" <aha...@adobe.com.INVALID>
To: builds@apache.org
Sent: Saturday, December 8, 2018 12:43:37 PM
Subject: Re: Can we package release artifacts on builds.a.o?
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2Fefed1ff44fbfe5770ea1574b2f53a5295ae8326c5a3a5feb9f88cd48%40%253Cbuilds.apache.org%253E&data=02%7C01%7Caharui%40adobe.com%7C5b7803529e3943bd483808d65d3daf70%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636798916859824875&sdata=vJouQVPXMtHyvxOo%2BZuhhi0TmAdw9nJYPTC3HTaj1%2B0%3D&reserved=0
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?
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.
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...
