[Gt-eos] myproxy w/o globus

Mischa Salle msalle at nikhef.nl
Wed Nov 8 21:33:28 CET 2017


Hi Jim,

On Tue, Nov 07, 2017 at 06:00:27PM +0000, Jim Basney wrote:
> On 10/30/17, 12:05 PM, Gt-eos on behalf of Mischa Salle wrote:
> > On Fri, Oct 27, 2017 at 04:37:32PM +0000, Jim Basney wrote:
> >> Venkat and I have been exploring what it would take to make a MyProxy
> >> release without Globus dependencies. Our current work in progress is
> >> at https://github.com/ncsa/myproxy. We welcome your input and help!
> > that's good news!
> > Is there specific things you need help with or input for?
> 
> Yes:
> * input on whether this MyProxy fork is worthwhile to continue pursuing
> * help with proxy cert functionality (which CILogon and XSEDE don't use, so we're less motivated to work on)

Concerning the first, it's certainly useful, but I think (see below) we
should wait a little till we know what happens to the gcf. If we manage
to get maintenance if the gct to work out fine, there is no need to
decouple and that's probably less work in the end (hard to say).

Concerning the second, yes sure, it's essential for our MasterPortal
implementations and for EGI for long-running grid-jobs (proxy renewal)
and several other scenarios.
But again, only when the need really arises...

> > [...]
> > I would say that looking at current grid deployment, the proxy
> > repository functionality with corresponding myproxy-init (and perhaps
> > store) would probably be even more important than the CA functionality.
> > It's probably also a lot more tricky. Are you planning to take over code
> > from GT or VOMS or cANL for doing this?
> > [...]
> 
> My preference would be to try to use the OpenSSL proxy cert APIs rather than maintain the duplicate proxy cert code from GT that was written before OpenSSL supported proxy certs.
> Does VOMS or cANL use the OpenSSL proxy cert APIs or do they also have proxy cert code duplicating OpenSSL's proxy cert support? (Sorry I'm fuzzy on these details.)
As far as I know OpenSSL only has some basic functionality to verify RFC
proxy chains. I'm not 100% it even can do path-length constraint checks
as part of that and certainly does not know about limited proxies (OID
was never part of RFC3820, 1.3.6.1.4.1.3536.1.1.1.9 which is from Globus).
Creating RFC proxies and hence doing delegation is also not really part
of OpenSSL itself, you'll have to do that by hand in any case. VOMS,
cANL and Globus therefore have their own code but all using OpenSSL.
So there is code duplication between Globus, VOMS and cANL, each being
independent of the other two, but each using similar code.

> In any case, we don't have immediate plans for continued work on this MyProxy fork. For now, I think it's a higher priority to get gct off the ground with minimal code changes
I fully agree
If the myproxy code in the gcf keeps the current functionality and has
at least security support, I'm already pretty much satisfied.

> For what it's worth, I believe in do-ocracy. If there's a volunteer to do some proxy cert work for this MyProxy fork, I'm happy for the volunteer to choose a technical path forward. I'm liberal when merging pull requests. :)
(-:

    Best wishes,
    Mischa

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3402 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20171108/717b968a/attachment.p7s>


More information about the Gt-eos mailing list