Release of "target" in VOMS proxy is not checked

[federicaagostini]

When a user asks for a target during voms-proxy-init, it appears in the VOMS proxy without any further check. For instance, this test should be green.

Add checks on the target parameter as per specification.

[giacomini]

In fact the check in voms-proxy-init (C/C++ version) is probably wrong, since the target represents where the proxy will be used, not where it is generated; it corresponds to the audience in tokens.

[federicaagostini]

Reference about target parameter: https://datatracker.ietf.org/doc/html/rfc3281#section-4.3.2

[enricovianello]

VOMS-aa should check that the requested target is not an empty string (according with GeneralName definition). The failing test should be fixed expecting a successful voms-proxy-init

[maarten-litmaath]

Hi all, as the target option has never been used in production at large scale if at all, we should be careful with "fixing" its behavior and in particular avoid that a VOMS proxy may suddenly have extra content (like "target: NULL") that the VOMS code of a random service may be unprepared for, potentially causing such a proxy to be rejected... Also mind there exist several VOMS stacks.

[giacomini]

I agree with the general attitude not to break anything and we try to have a testsuite with good coverage. The ts uses our products, but you allude to other stacks; can you be more specific?

[maarten-litmaath]

I meant "several stacks examining VOMS proxy contents." There are of course these:

• VOMS C++
• VOMS Java

But it looks possible to me that some of these also look under the hood, where perhaps they should not:

• CaNL C
• CaNL C++ (possibly discontinued)
• CaNL Java
• GridSite

And mind that several versions of any of them may be in production, some of which might need to be upgraded on non-trivial changes, which can bring further complications.

Finally, if the output format of voms-proxy-info were to change, even that might break some (fragile) code...