[Gt-eos] genproxy - create GSI proxy credentials w/o Globus

[Mischa Salle]

Hi Frank,

On Thu, Nov 09, 2017 at 12:44:40PM +0100, Frank Scheiner wrote:
> Hi Mischa,
> 
> On 11/09/2017 12:15 PM, Mischa Salle wrote:
> > Dear Frank,
> > 
> > great! I know his tool (obviously), I like the fact that it finally made
> > it's way to github. Putting it under gcf makes sense to me.
> > Perhaps you can persuade Jan Just to also add his grid-proxy-verify...
> 
> I didn't use that tool yet. Is this an alternative to `grid-proxy-info
> -exists [...]` with more functionality?
It's doing much more: a full-chain verification for all kinds of edge
cases and is a good tool to debug problems arising from broken proxies.
Jan Just wrote it as a single C file, to make it easily installable on
pretty much any system. It's actually on the same page as his genproxy
script: https://www.nikhef.nl/~janjust/proxy-verify/

> > By the way, you know that voms-proxy-init (C or Java) also can create
> > (plain) proxy certs? They have no external dependencies.
> 
> No, didn't know that tool, if users have a C compiler at hand, why not. But
> Java is a heavy dependency, or? :-)
First a disclaimer: the C-clients are not officially supported any more
by INFN, although the underlying VOMS-API library itself is (and is
doing all the actual work) and the two are a single code-base.
I wouldn't let end-users build them by hand (although it's pretty
straightforward), it's available in EPEL as voms-clients-cpp, in Debian
as voms-clients. I've packaged it as addon for OpenSUSE (via the
buildservice) and use it for almost all my grid-related work.

The java clients are a small set of jar files with some shell-script
wrappers. They are build using mvn which isn't difficult either, but
also not for end-users. They are fully supported and available in EPEL
and as voms-clients-java. The disadvantage in my opinion is that java is
(very) slow for cmdline tools. It would be easy to provide a
self-contained pre-build zip or tarball (not sure why no-one is doing
that actually).

> > If you like we can go (together with Jan Just) over some potential
> > improvements, such as pkcs12 support (not difficult).
> 
> PKCS#12 support would be great! Additional improvements are also welcome.
This is probably better for a separate thread but in any case:
In short I would just extract the pem files from the pkcs12 (using
pkcs12 with -nocerts and then with -clcerts -nokeys) and then just use
what you're now using. You can read the pw with a "read -sp 'prompt'
var" and then use the -passin env:.. and -passout env: options to use it
for the openssl commands. Not ideal, but it works and you don't see the
pw in ps. (Ask when you need more details (-; ).
Some other small things: put the proxy pathLengthConstraint to infinity
by default, certainly bigger than 2 (which is typically not enough to
reach a workernode). Probably also a good idea to default to sha255.
And also nice to use a trap on EXIT (something like trap exitfunc EXIT),
to make sure you tidy up any temp file created.

    Cheers,
    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/20171109/013fd86e/attachment-0001.p7s>