voms-proxy-init fails when LSC file broken for another VO

[maarten-litmaath]

It is already questionable for voms-proxy-init to check LSC files in the first place...

This matter gets even worse when any LSC file happens to be broken, in this case for an unrelated VO:

LSC file parsing error: Malformed LSC file (vo=[...] host=[...]): Odd number of distinguished name entries.

Seen when the second line in the broken LSC file does not start with a '/' character.

$ voms-proxy-init --version
voms-proxy-init v. 3.3.5 (voms-api-java/3.3.5 canl/2.8.3 bcprov/1.70.0 bcpkix/1.70.00.0)

[maarten-litmaath]

Broken LSC files need to be skipped.

A broken configuration for 1 VO must not block another VO.

A warning could be printed on stderr, depending on the circumstances.

[giacomini]

The issue concerns only the Java client, so I will transfer this issue to the corresponding project, either voms-clients or voms-api-java (TBD).

The C/C++ client looks only in the relevant LSC file.

Note that there is an option to avoid the check (-dont-verify-ac for the C/C++ client, -dont_verify_ac for the Java client).

[maarten-litmaath]

OK.

[giacomini]

A possible fix would change DefaultLSCParser::validateChain to return true/false based on the result of the validation and DefaultLSCParser::parse to return an Optional<LSCFile>, with a warning logged sometime in the process.

Note that in the Java API, contrary to the C/C++ API, all the available LSC files are loaded at startup, independently of whether they are used by the specific program. The behaviour may be fine for a server which may have to serve multiple VOs, but not for a user-facing command; a user is typically interested only in their own VO. The above change would make a program using the API no more fail in case of a wrong LSC, which may not be ideal for a server.

[maarten-litmaath]

Even for a service, the current behavior is wrong, IMO.
A broken configuration for 1 VO must not prevent it from working for other VOs.

[federicaagostini]

After talking with Francesco, we are more thinking about adding a constructor in the DefaultVomsTrustStore class with another parameter, the VO name, such to implement the validation for the requested VO only. We should update the clients in the DefaultVOMSProxyInitBehaviour class where the information is present. The rationale is do not introduce breaking changes to the services depending by voms-api-java.

[maarten-litmaath]

OK. Mind this issue is not urgent, thanks!

[msalle]

Just for clarity: we agree that a broken LSC file for the actual relevant VO should cause an error, right? And that is the behaviour for both C/C++ and Java? A missing LSC file isn't per se a user bug in itself since a PEM could be provided instead.

[maarten-litmaath]

Each LSC file corresponds to a VOMS server for the associated VO: if such a file is broken or absent, VOMS ACs signed by that server cannot be verified (*) and the proxy will thus be rejected.

(*) Assuming also its host certificate PEM file is absent, which the normal situation since 10+ years.

[msalle]

I agree it won't pass verification, but my point was (probably not clearly enough formulated) that it would be good to inform the user of a malformed .lsc file and not only say something like verification failed, which a user would probably expect to be an issue with the certificate itself? I triggered on your "Broken LSC files need to be skipped", in particular the skipped.

[maarten-litmaath]

That behavior would depend on the service and such information might be hard to send back to the client...