dCache SRM Client 2.10.7 Release Notes

Changes:

• Add support for extra-info for srmcp

  The SRM protocol's copy request allows the client to specify zero or more keyword-value pairs as “extra info”. This extra info allows the client to provide hints on how the copy should be processed. This release adds support for the -extraInfo command-line option to the srmcp command, which allows specifying these hints.

• Fix logging output

  Previous versions of srm-client contained logback configuration that could result in commands producing excessive logging. This release fixes that issue.

• delegate same type of certificate

  The delegation shell allows delegating (“uploading”) a credential so the SRM server can copy files on the users behalf. The delegated credential, which the server receives, comes either from the users CA-issued credential (the user's EEC) or from a proxy credential.

  There are several kinds of proxy certificate. Previously, the delegated credential's certificate was always a “GSI v4 unlimited” credential; however, using this type of certificate could cause problems if the users credential (either proxy or EEC) certificate was of a different type. Now the delegated credential certificate has the same type as the user's credential certificate.

• Fix srmcp processing a list of files

  Previously, downloading several files using a command like srmcp -copyjobfile=transfers (where transfers is a file containing a list of source-destination pairs) could result in a ArrayIndexOutOfBoundsException error message. This problem is now fixed.

• Do not fail for TLS 1.2 servers

  The TLS protocol supports the server and client negotiating which version of the protocol they both support. For example, a client that does not support TLS v1.2 can negotiate the use of a TLS version it supports when establishing a connection with a TLS v1.2 server.

  Earlier versions of srm-client would simply fail when presented with a server advertising TLS v1.2. With this release, the negotiation process is used so the client and server may communicate using a supported version of the protocol.

• Handle end-of-stream alerts correctly

  Under normal circumstances, when the server wants to close its end of the TCP connection it first sends an SSL Alert indicating this to the client. Clients should accept this alert as advice that no further messages from the server are expected and act accordingly.

  Previous versions of srm-client did not handle this alert in this fashion, but treated such end-of-stream alerts as indicative of some failure. The result was additional, spurious logging. The client also considered the operation to have failed.

  By default, the dCache SRM does not send end-of-stream alerts; however, this will change in the future. Therefore, with this release of srm-client, handling of an end-of-stream alert has been fixed: it is not considered non-fatal and receiving the alert results in the client accepting no further traffic from the server.