Document control

AreaEGI Federation Operations
Procedure status

FINALISED

Owner

David Groep 

ApproversOperations Management Board
Approval status

APPROVED

Approved version and date


Statement

Procedure for the announcement and propagation of a new release of the EGI Trust Anchor distribution

Next procedure reviewtogether with process review
Dissemination Level

TLP:WHITE - public

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments

 

Baptiste Grenier 

Import from former MediawikiTo be updated by procedure owner

 

David Groep Aligned documented with effective processNone

Table of contents

Overview

About this distribution

This page describe the procedure for the announcement and propagation of a new release of the EGI Trust Anchor distribution. The EGI Policy on Approved Certification Authorities describes the set of trust anchors accepted by EGI and put forward for consideration by the NGIs to install as the 'agreed set' of Identity Management trust anchors. For the time being, only PKI trust anchors ('Certification Authorities') are included in this release.

The announcement and distribution of trust anchors within EGI and the NGIs should be done in a well defined order to ensure consistent deployment and to ensure that the monitoring of the NGIs and sites matches the currently recommended version of the trust anchors.

Trust Anchor Policy and Transition Processes

The trust anchor distribution contains two variants integrated in a single release: the "ca-policy-egi-core" that is suitable for all EGI trust scenarios, and a "ca-policy-egi-cam" (combined assurance/adequacy) package based on the approved policy on differentiated assurance. Technically, this means that relying parties, independently or by way of their NGI, must only install the new "ca-policy-egi-cam" packages if they also at the same time implement VO-specific authorisation controls in the software stack.Both variants are always co-released at the dame time, using this same procedure.

Some EGI relying parties that have been in operation since before 2012 may be using the "lcg-CA" meta-package that reflects a combination of EGI as well as wLCG policy on approved CAs. This package is deprecated, and new sites must install the new "ca-policy-egi-core" or "ca-policy-egi-cam" package. In current releases, installing the "lcg-CA" meta-package, having triggered installation of both the "ca-policy-egi-core" package as well as the "ca-policy-lcg" package, can subsequently be removed. It is not guaranteed that in the future the EGI and wLCG policies will stay aligned, so sites that relied on the "lcg-CA" package distributed by EGI to also comply with the wLCG policies on accepted CAs should keep this in mind. Also, the acceptable authentication policy for your organisation, country, or region may be different from the EGI federation: your organisation, NGI, or country may have approved additional trust anchors for use on your infrastructure, or put in specific constraints. As a result, you may want to review the EGI core or cam list.

Definitions

Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Entities involved in the procedure

Triggers

  • Scheduled release: EGI Trust Anchor releases are usually done on the last Monday of the month (except for security or critical bug fixes), but only if such a release would be materially different from the deployed version. EGI will get a preview release in the previous week for Staged Rollout.

Steps

Step# ResponsibleActionPrerequisites, if any
1
IGTF Liaison

Prerequisites:

  • IGTF Liaison builds the IGTF distribution itself, making it available on a pre-release web site for use by major relying parties, at https://dl.igtf.net/distribution/tests/PMA-PRIVATE-PREVIEW/releases/
  • ensure that both the GPG-KEY-EUGridPMA-RPM-3 and GPG-KEY-EUGridPMA-RPM-4 signed bundles have been built:
    IGTF build steps for EGI compatibility
    cd buildtools/
./cabuild4.pl --version=AUTO -s -f -o ~/1.123-GPSK3 --mkdeb -K 3
./cabuild4.pl --version=AUTO -s -f -o ~/1.123-GPSK4 --mkdeb -K 4
rsync -e ssh -rav --delete ~/1.123-GPSK? webegp@dl.igtf.net:/project/srv/www/site/eugridpma-dist/html/distribution/tests/PMA-PRIVATE-PREVIEW/releases/

  • and on dl.igtf.net create the additional symlink(s) for the 1.123 release to point to the 1.123-GPSK3 variant

Internal actions:

  • retrieve pending updates from shared IGTF & EGI/wLCG repository :ext:cvs.eugridpma.org/cvs/eugridpma (both trusted network source and ssh key registration required)
    A source snapshot is made available at https://egi-igtf.ndpf.info/misc/egi-igtf-sources/

  • in util/patches/ca-policy-egilcg/doc, create the documentation files for the new version, e.g. using

    for i in \
  ca-policy-egi-cam-readme ca-policy-egi-core-readme ca-policy-lcg-readme;\ 
  do cp -p $i-1.XXX.txt $i-1.YYY.txt ; \
done ; \
vi *.YYY.txt

    including the designated release date, which should be a Monday.

  • Create, on the upload service (egi-igtf.ndpf.info) the requisite directories and re-point the current version 'egi/' symlink:

    cd www-egi/html/distribution/
mkdir egi-1.123-1
ln -sfn egi-1.123-1 egi
cd egi
touch 1.123-is-current
ln -sfn ca-policy-egi-cam-1.123-1-GPSK3 ca-policy-egi-cam-1.123-1
ln -sfn ca-policy-egi-cam-1.123-1 current
ln -sfn current/GPG-KEY-EUGridPMA-RPM-3 GPG-KEY-EUGridPMA-RPM-3
ln -sfn current/GPG-KEY-EUGridPMA-RPM-4 GPG-KEY-EUGridPMA-RPM-4

  • build the EGI distribution in util/patches/ca-policy-egilcg, building for both the GPG release keys 3 and 4 (the new F38+ compatible one):

    ./builddist-newegi-multi.pl --srcurl=file:///home/davidg/1.123-GPSK4 -f -v -K 4
./builddist-newegi-multi.pl --srcurl=file:///home/davidg/1.123-GPSK3 -f -v -K 3

    this builds the EGI-specific trust anchor package, currently called "ca-policy-egi-cam" and dependencies, and makes that available on the dedicated site intended for internal use and upload by the deployment process.
    An additional package, "ca-policy-lcg" is included as a convenience service to the wLCG community, but its availability is contingent on it being fully compatible with the EGI processes and policies. It doe snot have a special status and may be withdrawn at any moment regardless.

  • Agree to copy sync the directories to both targets using rsync

  • Recreate the file listing for ftp directory listings and archie

    cd www-egi/html/distribution/egi/
ls -lR | sed -e 's/davidg/nobody/g;s/emin/nobody/g' > ls-lR

  • This EGI distribution contains:

    • all CAs accredited under the IGTF "classic", "mics", "slcs", and "iota" profiles (following the Policy on Accepted CAs)
    • the "ca-policy-egi-core" and "ca-policy-egi-cam" meta-packages, as well as the legacy/compatibility packages "lcg-CA" and its corresponding "ca-policy-lcg" meta package
    • any other EGI specific CAs or exception as decided by EGI (currently none)
    • the patch RPM for the Apache mod_ssl bug (the "dummycas" RPM)
    • the appropriate NRMS XML, meta-data, SAM/Nagios XML (release date set 2 days to the future), README.txt file, and repo headers.
  • Download the NRMS XML file from and validate it as an internal technology provider at https://admin-repo.egi.eu/XMLvalidator/


  • This distribution is RPM (only!) unit tested before upload by installing it on a reference system, using the RPMs copied to the internal release web. This uses the repo file

    [egi-test]
name=EGI Trust Anchors test
baseurl=https://egi-igtf.ndpf.info/distribution/egi/current/
gpgcheck=1
enabled=0
gpgkey=https://dl.igtf.net/distribution/igtf/current/GPG-KEY-EUGridPMA-RPM-3
  • Verify the egi-igtf site so that the symlink "egi/" is set to the proper version before opening the sw-rel ticket.



2
IGTF Liaison

Submit a software RT ticket to the sw-rel queue https://rt.egi.eu/rt/Ticket/Create.html?Queue=24:

Add In the description field

  • comment inside saying: "please, follow the EGI-IGTF release process PROC05".
  • systematically include a reminder not to start after mid-week, and preferably on a Monday.
  • status of the urgency (regular release: 8 day grace, emergency: 1-day grace)
  • the EGI specific change log in the release file. This change log is intended for direct distribution to the EGI sites

In the RT ticket, the monitoring team should be involved via a CC to eimamagi@srce.hr, and the security officers via sveng@nikhef.nl.



2bSR Repo

Ticket triggers the import of distribution to the EGI Repository "unverified" repository for starting the staged-rollout process as documented in the NSRW New Software Release Workflow

To ensure a smooth, parallel update of the repository and the monitoring/Nagios tests, the non-urgent updates should be started before Wednesdays noon-time.


3
IGTF Liaison

announce new ticket (with ticket ID) (following on or forwarding the EUGridPMA-Announce list) to

Mail paste list: egi-csirt-team@mailman.egi.eu, jpina@lip.pt, jorge@lip.pt, eimamagi@srce.hr, noc-managers@mailman.egi.eu, sveng@nikhef.nl, egi-igtf-liaison@nikhef.nl, dennisvd@nikhef.nl, dsimmel@psc.edu, jteheran@fnal.gov, umd-team@mailman.egi.eu.

Either the EGI CSIRT, the EGI Operational Security Coordinators, or the MW unit can declare this update as urgent.


4
SR team

Run initial acceptance process to check compliance with the package requirements and upload report.

Progress ticket state

  • to Staged Rollout, or
  • cancel release and request re-upload. This would bring the process back to step 1 (where the public release version number may be kept to "-1", but the NRSM release number would then increment, e.g. to "2" - this does not affect the final released distribution).
distribution available in .../unverified/
5
SR team

verifies  if the package works in an at-most-one-day process, but does not close the ticket and does NOT progress to production at this stage.

At the transition to .../sw/stagerollout/
6
All entitiesWAIT for the official IGTF release, which will be announced through the RT ticket as a comment.
The new EGI trust anchor release should not progress to production until the IGTF announcement is out (please!)
7
SR teamcan now progress to release:
  • check the date. If the date in the SAM/Nagios "release.xml" file (<Date> entry) is already passed, ask Kostas to update this file in the repo on final release. Otherwise, just continue...
  • moves release from staged roll-out to production (so not to UMD), triggering over-write (non-incremental) of the .../sw/production/cas/1/ directory.
  • verifies that the update was non-incremental and that the whole contents of the ".../production/cas/1/" directory has indeed been replaced at http://repository.egi.eu/sw/production/cas/1/. If the repository has not properly updated itself, contact the repo team (Kostas Koumantatos at <kkoum@grnet.gr>) to have it fixed: the URL http://repository.egi.eu/sw/production/cas/1/current/ MUST point to the new release!
  1. IGTF has announced and published the underlying release on https://igtf.net/
  2. Comment in RT ticket is present

2SR team

sends the announcement with changelog (from the RT ticket) to the NGI contacts and the sites through the Operations Portal (select "To ROC Managers", "To Production Site Admin","Operation tools"), with a CC to the gLite EMT. The change log to be included in the mail is part of the RT ticket NSRW XML and can also be found at http://repository.egi.eu/sw/production/cas/1/current/meta/ as file ca-policy-egi-core-readme-X.Y.txt(with X.Y the version number).


8
EGI-CSIRT

Verifies that

If a critical update was not released in time, it will (i) warn the technical and operational coordinators of EGI thereof, and (ii) take appropriate action to ensure the security of the infrastructure.

In case the update was marked critical