igtf-ca-bundle @1.57: new submission

[petrrr]

This port packages the ICTF bundle. It will be especially useful for future Globus ports, but is sufficiently independent to be already committed. The name of the port can be changed if you think it is not appropriate.

igtf-bundle @1.55 (security, net)
Variants:             universal

Description:          The International Grid Trust Federation (IGTF) maintains a
                      list of trust anchors, root certificates and related
                      meta-information for all the accredited authorities, i.e.,
                      those that meet or exceed the criteria mentioned in the
                      Authentication Profiles accepted by the IGTF. For a list
                      of those profiles, please refer to the website.
Homepage:             http://www.igtf.net

Platforms:            darwin
License:              CCBY-3 Permissive MPL-1.1+
Maintainers:          dennisvd@nikhef.nl, openmaintainer@macports.org

Remarks:

(1) I leave Dennis as maintainer here, but would be available as co-maintainer if this is considered useful;

(2) I left the license line quite explicit to give full info on the license: license {CCBY-3 Permissive} MPL-1.1+. It probably could be reduced to license Permissive MPL-1.1+ for practical reasons.

(3) This port might be supported_archs noarch, but I am not 100% sure if hashes effectively are always platform-independent.

(4) I add two LICENCE texts to the dist, because I understand that the MPL would be required for MPL compliance and add the CC text for consistency.

I CC Dennis (as maintainer) and Adam, who assisted Dennis with Globus related stuff before.

[petrrr]

files/LICENCE-MPL-1_1 - additional licence text

[petrrr]

files/LICENCE-MPL-1_1 - additional licence text

[petrrr]

files/LICENCE-CC-BY-3_0 - additional licence text

[petrrr]

This file is an duplicate, it was added unintentionally (probably by clicking twice): LICENSE-MPL-1_1.2​ (25.2 KB), please cancel!

[skymoo (Adam Mercer)]

Let's wait to hear from Dennis to see if he's OK with maintaining this. Another certificate bundle that would be useful is the OSG CA Bundle (​http://software.grid.iu.edu/cadist/), this is a superset of the IGTF bundle and is used on the Open Science Grid, we use this bundle at work.

[dennisvd@…]

Replying to ram@…:

Let's wait to hear from Dennis to see if he's OK with maintaining this.

I am. I'm just glad Peter did the hard work for initial submission ;-)

Another certificate bundle that would be useful is the OSG CA Bundle (​http://software.grid.iu.edu/cadist/), this is a superset of the IGTF bundle and is used on the Open Science Grid, we use this bundle at work.

I'll have to look into what's in there in addition to the IGFT stuff; instead of having another bundle it would be better to have the additional CAs separated out.

[petrrr]

I intend to work on the globus ports by Dennis a bit, we just have an urgent need for them and having them in the official repo would be the easiest solution for us. I need them for various other ports I would like to submit as well. (But maybe we discuss it in a different place, not in this ticket) I just choose to start with this port because it is mostly independent.

For the maintainer:

I personally have no strong preferences for any solution. I just think Dennis should be maintainer of the port, he started the work and is quite close to the source, so may get news early. On the other hand, it might be unusual to have a submission from a non-maintainer, so I mentioned that co-maintainance would be okay as well. Just do whatever is most appropriate.

For alternative CA bundles:

Well, I could imagine having more than one CA bundle available in Macports and the user would choose which one he prefers (or trusts). These collections might be exclusive (install together) or overlapping (and therefore conflicting). Not sure what's the best approach.

Just let me know if you want me to take so action!

[petrrr]

Concerning the OSG CA Bundle:

If I understand correctly the IGTF bundle provides 101 CAs, the OSG bundle adds two form the same organization, "unaccredited":

67e8acfaPurdueTeragridRA 67e8acfa.0 ​http://tg-ca.purdue.teragrid.org:8080/ejbca/ OSG-1.35 unaccredited

95009ddcPurdueCA 95009ddc.0 ​http://tg-ca.purdue.teragrid.org:8080/ejbca/ OSG-1.35 unaccredited

So maybe in such a case, it is preferable the user install such certificates manually under personal responsibility?

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

I'll have to look into what's in there in addition to the IGFT stuff; instead of having another bundle it would be better to have the additional CAs separated out.

Sounds like the best approach.

[skymoo (Adam Mercer)]

Replying to Peter.Danecek@…:

So maybe in such a case, it is preferable the user install such certificates manually under personal responsibility?

For some of the users I need to support that doesn't sound like a good idea. A separate port that depends on igtf-bundle and installs these extra certs with an appropriate warning is probably the best approach.

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

I am. I'm just glad Peter did the hard work for initial submission ;-)

Great, I'll get this committed.

[petrrr]

Replying to ram@…:

Replying to dennisvd@…:

I am. I'm just glad Peter did the hard work for initial submission ;-)

Great, I'll get this committed.

Thanks for the work! Expect more of this ;-)

Please have a look at the points i highlighted (license in particular); There is also the noarch doubt. I remember some hash mismatch problems some time ago, so I needed to do configure and make. But now I could imagine this is just due to OpenSSL versions. So probably one single packages for all platforms should work;

[petrrr]

Replying to ram@…:

Replying to Peter.Danecek@…:

So maybe in such a case, it is preferable the user install such certificates manually under personal responsibility?

For some of the users I need to support that doesn't sound like a good idea. A separate port that depends on igtf-bundle and installs these extra certs with an appropriate warning is probably the best approach.

Agreed!

[skymoo (Adam Mercer)]

Looking at the Portfile I've got a question, you're passing $[destroot}${prefix}/etc/grid-security/certificates to configure and then creating a symlink to ${destroot]${prefix}/share/certificates in post-destoot. The later is on the default certificate search path but the former, i.e. where you're installing the certificates to, isn't. Wouldn't it make more sense to simply install to ${destroot}${prefix}/share/certificates? I know that the usual place for certificates in /etc/grid-security/certificates but as we're installing in prefix it seems like we should just install to a path that is searched?

[skymoo (Adam Mercer)]

Replying to Peter.Danecek@…:

Please have a look at the points i highlighted (license in particular);

There is also the noarch doubt.

I think that can be solved by adding supported_archs noarchs to the Portfile, this just installs text files.

I remember some hash mismatch problems some time ago, so I needed to do configure and make. But now I could imagine this is just due to OpenSSL versions. So probably one single packages for all platforms should work;

You probably won't be able to use both OpenSSL-0.9.x and OpenSSL-1.0.x and these certificates without some extra steps as the hashing algorithms are different, but as we'll be using a globus linked against OpenSSL-1.0.x from MacPorts then this shouldn't be an issue.

[petrrr]

Replying to ram@…:

Replying to Peter.Danecek@…:

Please have a look at the points i highlighted (license in particular);

There is also the noarch doubt.

I think that can be solved by adding supported_archs noarchs to the Portfile, this just installs text files.

I remember some hash mismatch problems some time ago, so I needed to do configure and make. But now I could imagine this is just due to OpenSSL versions. So probably one single packages for all platforms should work;

You probably won't be able to use both OpenSSL-0.9.x and OpenSSL-1.0.x and these certificates without some extra steps as the hashing algorithms are different, but as we'll be using a globus linked against OpenSSL-1.0.x from MacPorts then this shouldn't be an issue.

This is what I understood now as well. Hash mismatch is due to OpenSSL mismatch but within MP we would not have this problem.

[petrrr]

I updated the file Portfile, as follows:

• checksums changed; For some reason I realised there was a checksum mismatch. I tested, so I am bit puzzled how this could happen exactly, probably I tested with a RC version lying around);
• I added a mirror site to to master_sites;
• supported_archs noarch; I concluded it is save here;
• I added myself as maintainer, so I get notified if there is some need for action;
• The port now installed directly in ${destroot}${prefix}/share/certificates, no symlink;

I guess, I considered all comments, so have a look if it is now ready for commit. Thanks!

[dennisvd@…]

Replying to ram@…:

I know that the usual place for certificates in /etc/grid-security/certificates but as we're installing in prefix it seems like we should just install to a path that is searched?

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

Also, the IGTF relies heavily on CRLs, and the fetch-crl tool places them next to the certificate files. Aren't there also objections against having such variable data in .../share/...?

[petrrr]

Replying to dennisvd@…:

Replying to ram@…:

I know that the usual place for certificates in /etc/grid-security/certificates but as we're installing in prefix it seems like we should just install to a path that is searched?

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

I understand, that there are tools which expect to have certificates in /etc/grid-security/certificates. But are there any tools expecting it to be in ${prefix}/etc/grid-security. If yes we can of cause put certificates in that location, if not there is probably no point in doing so. I personally, do not know of any (but have limited experience). The Globus toolkit for Macports currently looks up in /etc/grid-security and /opt/local/share/certificates and all software using GSI authentication does as we.

Also, the IGTF relies heavily on CRLs, and the fetch-crl tool places them next to the certificate files. Aren't there also objections against having such variable data in .../share/...?

Okay! Should, as a general rule, variable data not go into .../var/... then? I was assuming that is what is ${prefix}/var/cache/fetch-crl for.

[petrrr]

Replying to dennisvd@…:

Replying to ram@…:

Also, the IGTF relies heavily on CRLs, and the fetch-crl tool places them next to the certificate files. Aren't there also objections against having such variable data in .../share/...?

Okay, I see it now. This is from fetch-crl Portfile

post-build {
[...]
    # update the standard config file
    reinplace "s|/etc|${prefix}/etc|" fetch-crl.cnf
    system "echo 'statedir ${prefix}/var/cache/fetch-crl' >> ${worksrcpath}/fetch-crl.cnf"
}

And the result is here:

#
# Default configuration file for fetch-crl3
# @(#)$Id$
#
infodir = /opt/local/etc/grid-security/certificates
agingtolerance = 24
nosymlinks
nowarnings
statedir /opt/local/var/cache/fetch-crl

But if we want to be consistent here, we would need to patch all the Globus Toolkit to behave in the same way, right? I guess in the current version this is not the case.

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

That path is outside of the MacPorts prefix, so it makes me uncomfortable installing files to there.

[petrrr]

Replying to ram@…:

Replying to dennisvd@…:

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

That path is outside of the MacPorts prefix, so it makes me uncomfortable installing files to there.

I do not think the intention here is to install anything outside ${prefix}, i.e. we will not install in /etc/grid-security/certificates, but in the analogues location in Macports, which would translate to `${perfix}/etc/grid-security/certificates. This is what Dennis is arguing for, right?

And there is this other point: In ${what-ever-location}/certificates/ there will go other files, i.e. CRLs which are fetched by fetch-crl in some way and are not registered with MP (I am just revising the relation igtf-bundle and fetch-crl). So the content is changing slightly over time, and Dennis (and me as well) is wondering if ${prefix}/share/certificates is really the right place to have changing content. Ideally, varying content would go in ${prefix}/var, but than again this is not what is done usually.

So in the end it may perfectly make sense to put the certificates along with (changing / unregistered) CRLs into ${prefix}/etc/grid-security/certificate. I would argue, it is more acceptable to have changing and above all, not registered content under ${prefix}/etc, than having it somewhere under ${prefix}/share.

So what you think?

[dennisvd@…]

Replying to Peter.Danecek@…:

Replying to ram@…:

Replying to dennisvd@…:

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

That path is outside of the MacPorts prefix, so it makes me uncomfortable installing files to there.

I do not think the intention here is to install anything outside ${prefix}, i.e. we will not install in /etc/grid-security/certificates, but in the analogues location in Macports, which would translate to `${perfix}/etc/grid-security/certificates. This is what Dennis is arguing for, right?

Actually I was aiming at /etc/ but I understand why this is frowned upon. Most software can probably be made to work with other paths using config files or environment variables.

And there is this other point: In ${what-ever-location}/certificates/ there will go other files, i.e. CRLs which are fetched by fetch-crl in some way and are not registered with MP (I am just revising the relation igtf-bundle and fetch-crl). So the content is changing slightly over time, and Dennis (and me as well) is wondering if ${prefix}/share/certificates is really the right place to have changing content. Ideally, varying content would go in ${prefix}/var, but than again this is not what is done usually.

I've never encountered a system where the certificates live in one place, and the CRLs live in another. It seems highly unlikely that this is going to work.

So in the end it may perfectly make sense to put the certificates along with (changing / unregistered) CRLs into ${prefix}/etc/grid-security/certificate. I would argue, it is more acceptable to have changing and above all, not registered content under ${prefix}/etc, than having it somewhere under ${prefix}/share.

Indeed, and users can make the conscious choice to make /etc/grid-security a symlink to ${prefix}/etc/grid-security.

[petrrr]

Replying to dennisvd@…:

Replying to Peter.Danecek@…:

Replying to ram@…:

Replying to dennisvd@…:

There is some software (such as VOMS) that defaults to /etc/grid-security/certificates. It's been common practice with the European grid projects. Usually the location can be overridden with an environment variable, but are there any profound objections against having the certificates in that place?

That path is outside of the MacPorts prefix, so it makes me uncomfortable installing files to there.

I do not think the intention here is to install anything outside ${prefix}, i.e. we will not install in /etc/grid-security/certificates, but in the analogues location in Macports, which would translate to `${perfix}/etc/grid-security/certificates. This is what Dennis is arguing for, right?

Actually I was aiming at /etc/ but I understand why this is frowned upon. Most software can probably be made to work with other paths using config files or environment variables.

Okay, I understood you wrong. The port as I found it already avoided installing outside ${prefix}, i.e. installed in /opt/local/etc/. I guess, if is really convinced he needs to have certificates in /etc/grid-security, he still could create a symlink from /etc/grid-security to the ${the-location-we-decide}, but manually so not interfere.

And there is this other point: In ${what-ever-location}/certificates/ there will go other files, i.e. CRLs which are fetched by fetch-crl in some way and are not registered with MP (I am just revising the relation igtf-bundle and fetch-crl). So the content is changing slightly over time, and Dennis (and me as well) is wondering if ${prefix}/share/certificates is really the right place to have changing content. Ideally, varying content would go in ${prefix}/var, but than again this is not what is done usually.

I've never encountered a system where the certificates live in one place, and the CRLs live in another. It seems highly unlikely that this is going to work.

Agreed! I am not arguing for putting it into var. One might think of putting stuff into something like ${prefix}/var/certificates, but I do not see why such a solution would be preferable. So, no do not like!

So in the end it may perfectly make sense to put the certificates along with (changing / unregistered) CRLs into ${prefix}/etc/grid-security/certificate. I would argue, it is more acceptable to have changing and above all, not registered content under ${prefix}/etc, than having it somewhere under ${prefix}/share.

Indeed, and users can make the conscious choice to make /etc/grid-security a symlink to ${prefix}/etc/grid-security.

Yes! ;-) Same idea above (Sorry, have no read all immediately)

[petrrr]

In conclusion I propose the following for this port:

• move the location of certificates back to ${prefix}/etc/grid-security/certificates;
• create a symlink from ${prefix}/share to ${prefix}/etc/grid-security to ensure that all grid/Globus related tools work out-of-the-box, without having to patch all tools to see `${prefix}/etc/grid-security/certificates as well;
• make this port depend on fetch-crl;
• configure fetch-crl to fetch CRLs for these certificates;
• install auto-fetch launchd service for this certificates (not 100% sure here); loading this service is delegated to the user itself (as discussed in ticket #41540 before);
• fetch CRLs on activation (post-activate);
• clean up CRLs on deactivation;

The last is a bit problematic to implement. The strategy would be to:

• first deactivate so the certificates disappear;
• run clean-crl to remove all CRLs for missing certificates (this should probably go into post-deactivate);

But I assume this would leave the directory ${prefix}/etc/grid-security/certificate around even if it is now empty. How to solve this elegantly, just try to delete the directory? Or is there a way to retry deactivation now?

[petrrr]

updated Portfile

[petrrr]

I updated tis port it is now @1.56. In addition there are the following changes:

• The certificates now install in ${prefix}/etc/grid-security/certificates again (see discussion);
• A symlink ${prefix}/share/certificates is created, so that these certificates are picked up by globus utilities;
• The port now depends on fetch-crl and uses it get valid CRLs on activation;
• The CRL files are purged on deactivation, a empty directory is removed as well;

This might be reconsidered:

• The state files of fetch-crl are removed as well (not selective);

Maybe these should be left around even if certificates and CRLs are removed. They these would be removed in pre-deactivate of the fetch-crl ?

[skymoo (Adam Mercer)]

Thanks, I'm swamped at the moment, with deadlines at work and visitors in town, but should be able to take a look at this after 3rd June. Hopefully someone else with commit access can get to it sooner...

[petrrr]

I a small change in the Portfile.

It is more consistent to purge the fetch-crl state files only when that utility is uninstalled. It might be reasonable to purge only the state files related to certificates installed by this port (not all) on uninstall. But this requires implementing such feature into clean-crl (proposed to the author).

[petrrr]

Note also, that this port should now be named igtf-ca-bundle and depends on #41540.

[mf2k (Frank Schima)]

A quick note, the ui_msg statements in post-activate and post-deactivate should only be 1 line each and not contain '#' characters. No other ports do it this way, or if they do, they should not be.

[petrrr]

corrected version

[petrrr]

Replying to mf2k@…:

A quick note, the ui_msg statements in post-activate and post-deactivate should only be 1 line each and not contain '#' characters. No other ports do it this way, or if they do, they should not be.

Okay, I corrected this. I probably took this from some other port, but I do not remember which one.

[petrrr]

updated Portfile

[petrrr]

I updated the Portfile to change the maintainer address.

The port is also available here. It works just fine for me, but some audit is appreciated before I commit.

[dennisvd@…]

Just a heads-up:

Since release 1.57, a new profile has been added called IOTA (identifier-only trust assurance). However, in 1.57 there are no CAs for that profile yet. The upcoming release 1.58 (due next week) will have an IOTA CA.

[skymoo (Adam Mercer)]

Sorry for the delay, but this looks good to me.

[petrrr]

Committed in r121399.