Can you explain why this critical/blocking
hardware is hosted outside the Eclipse Foundation, creating more/new issues
and delays? Our automated builds don't play well with filing bugs (for
signing and DMG creation) and wait for resolution ;-). Ah, and BTW, our
latest Photon M2 candidate build just failed again: http://download.eclipse.org/eclipse/downloads/drops4/I20170911-0405/
Mikaël Barbero <mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx> To:
release engineering list." <platform-releng-dev@xxxxxxxxxxx>,
Eclipse Packaging Project <epp-dev@xxxxxxxxxxx> Cc:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> Date:
07.09.2017 14:07 Subject:
Issue with the macOS bundle signing, dmg
packaging and signing Sent by:
(cross-posting to platform-releng, epp-dev and cross-projects)
Recently, we've been facing a lot of issues with the services
we provide for macOS: UI testing, macOS .app bundles signing and DMG files
creation and signing. It has been a combination of hardware, software and
network failures and these issues have already impacted some projects,
delaying their milestones/releases and consuming a lot of time from their
Since the beginning of the week, we've setup a new machine
to run UI tests from the Hudson shared instance (https://hudson.eclipse.org/shared/).
This machine is not hosted on our infra, and thus not everything that was
possible can be done on the new machine (most notably, it's not possible
to access machines inside the Eclipse VLAN). We still need to figure out
if we want to make it possible, or if we want to set this fact as a restriction.
We've also successfully deployed and tested the signing
and dmg packaging services on a similar machine. Unfortunately, we can't
switch the current unreliable services to these new ones as they are also
hosted outside of the Eclipse VLAN. As you may know, the services are insecure
webapps (read plain HTTP) without any sort of authentication. We were using
the fact that the services were running inside the VLAN to "protect"
them. Only Eclipse projects and committers were both trusted to use the
service by having access to the VLAN via their Hudson/Jenkins instance.
Opening the new services on a machine directly connected
to the internet would let anyone sign a macOS application with the Eclipse
certificate. This is something we want to avoid at all cost as it would
ruin all the trust one can have in this certificate. So we are working
hard to add a authentication layer and run the service on top of HTTPS
to be able to provide these services reliably from the new machines. But
it takes some time.
As we don't want these issues to delay the release of
Oxygen.1 or any project that uses these services, we come here with an