Hi,
I'm glad to announced that the macOS services (.app signing, .dmg packaging and .dmg signing) have been restored on a new machine hosted within the Foundation VLAN.
If you've disabled their usages, you can now re-enable them as it was before. The authentication layer I was talking about in my initial mail will be released later to possibly let us use resources outside of the Foundation VLAN. We will keep you posted.
Thanks for your patience while we were resolving this issue.
Cheers, Mikael
--
Mikaël Barbero - Eclipse Foundation IT Services - Release Engineering 📱 (+33) 642 028 039 🐦 @mikbarbero
Hi Dani, Just a clarification -- the current (broken) Mac services are
hosted on our hardware. We are working on two fronts --
1. Provision a temporary new Mac to re-establish the current
service 2. Provision managed/hosted Mac services to avoid these problems
in the future, as our in-house hardware is not redundant, and does
not scale.
In the immediate terms, you can disable the signing parts in your
build scripts for basically no cost, as signing is likely not
needed on I-builds, nor to validate test results.
Mikael has offered to manually sign your the last release
candidates so that release deadlines can be met.
I apologize for the inconveniences this causes, and thank you for
your continued patience while we resolve this issue and make it
better.
Denis
On 11/09/17 08:14 AM, Daniel Megert
wrote:
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/
Dani
From:
Mikaël Barbero
<mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx>
To:
"Eclipse platform
release engineering list."
<platform-releng-dev@xxxxxxxxxxx>,
Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>
Cc:
Webmaster
<webmaster@xxxxxxxxxxx>,
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
07.09.2017 14:07
Subject:
[platform-releng-dev]
Issue with the macOS bundle signing, dmg
packaging and signing
Sent by:
platform-releng-dev-bounces@xxxxxxxxxxx
(cross-posting to platform-releng, epp-dev and
cross-projects)
Hi,
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
teams.
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
temporary plan:
If you need to sign a macOS app and/or create a
signed
DMG for it, just open
a bug against CBI / signing service and we will
do it for you. You will need to give us the path on download.eclipse.orgto the .tar.gz of the macOS application you want us to
sign / package on
download.eclipse.org.
You will probably have to deactivate the usage of the CBI maven
plugins
(eclipse-macsigner-plugin
and eclipse-dmg-packager)
if you use Tycho. The output of the product build should then be
a simple
tar.gz of your .app Eclipse product.
If you have any question, feel free to open a bug
against
CBI or just ask it here.
Thanks for your patience.
Mikael
--
Mikaël Barbero - Eclipse
Foundation
IT Services - Release Engineering
📱 (+33) 642 028 039
📧 mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx
🐦 @mikbarbero
[attachment "signature.asc"
deleted by Daniel Megert/Zurich/IBM] _______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________ epp-dev mailing list epp-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/epp-dev
|
