[jira] [Commented] (MJARSIGNER-74) Allow usage of multiple Time Stamping Authority (TSA) servers

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MJARSIGNER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800080#comment-17800080 ] 

ASF GitHub Bot commented on MJARSIGNER-74:
------------------------------------------

schedin opened a new pull request, #19:
URL: https://github.com/apache/maven-jarsigner-plugin/pull/19

   Implementation of support for multiple TSA servers. A new server will be tried if the jarsigner command fails. The failure could be with communication with the TSA server, or could be something unrelated to TSA (for example access to a network based PKSC11 keystore).
   
   I have also implemented support for:
   
   1. Specifying multiple TSA keystore aliases as an alternative to specifying TSA URLs directly
   2. Specify `tsapolicyid` OID(s) to send to the TSA server(s)
   3. Specify the message digest algorithm (`tsadigestalg`) to use in communication with the TSA server (no multi-support, only one value for all TSA servers).
   
   The hardest thing working with this ticket was to figure out what should be possible to configure from an end user perspective. This is what I came up with (and would like feedback on):
   
   1. I did not see any need to throw an exception (abort the Mojo) if the end user configured something that I consider "wrong". Instead I have logged warnings when this happens
   2. Setting both `tsa` and `tsacert` seems wrong. At least jarsigner will ignore `-tsacert` if `-tsa` is set. However from a bigger perspective it might be possible for the end user to want to configure 1 TSA url and 2 keystore alias as to try 3 TSA servers in total? But this scenario felt too complicated to document and specify, so I skipped it.
   3. As I tested this feature against public TSA servers it became clear that they will typically have a dedicated, vendor specific OID. For example http://timestamp.digicert.com will only accept the DigiCert created [OID 2.16.840.1.114412.7.1](http://www.oid-info.com/cgi-bin/display?oid=2.16.840.1.114412.7&submit=Display&action=display). I therefore tried to document that the number of OIDs specified by the end user should be the same as the number of TSA servers the user wants to try.
   4. For `tsadigestalg` on the other hand I did not see any need to specify multiple. All TSA servers will handle the most common message digest algorithms.
   5. The usage of `tsacert`,  `tsapolicyid` and `tsadigestalg` is probably obscure. I'm not sure anybody is interested in using these features. It took me many hours before I could create a testing keystore that contained a valid certificate to use. And it took me some additions hours to figure out what OIDs to use. It was only after using Wireshark to sniff the traffic that I understood how the protocol in RFC 3161 worked.
   
   **Note:** this pull request can not be merged until a new release build of https://github.com/apache/maven-jarsigner has been made.




> Allow usage of multiple Time Stamping Authority (TSA) servers
> -------------------------------------------------------------
>
>                 Key: MJARSIGNER-74
>                 URL: https://issues.apache.org/jira/browse/MJARSIGNER-74
>             Project: Maven Jar Signer Plugin
>          Issue Type: New Feature
>    Affects Versions: 3.0.0
>            Reporter: Lennart Schedin
>            Priority: Minor
>
> h3. Background
> A Timestamping Authority (TSA) server is used to add a timestamp to the digital signature. This timestamp indicates when the code was signed and helps prevent issues that may arise if a certificate used for code signing expires.
> The jarsigner command has 4 parameters relating to TSA (see [https://docs.oracle.com/en/java/javase/17/docs/specs/man/jarsigner.html):]
> 1. {{-tsa url}}
> 2. {{-tsacert alias}}
> 3. {{-tsapolicyid policyid}}
> 4. {{-tsadigestalg algorithm}}
> The maven-jarsigner-plugin currently has support to set {{-tsa}} and {{-tsacert}} (the same goes for the library JarSignerSignRequest in the [https://github.com/apache/maven-jarsigner] project).
> h3. Feature requested
> Allow usage of multiple TSA servers when signing. This could be useful for:
> 1. Better stability if one TSA server is down.
> 2. Better stability if a TSA server has imposed a rate-limit when signing many jar files at the same time.
> This feature has both been suggested by Thorsten Meinl as a patch to [https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-59] and also by @jcompagner in [https://github.com/apache/maven-jarsigner-plugin/pull/1#issuecomment-1412344998]. But since those suggestions were not tied to a direct ticket, I felt it would be good to collect their feature requests as a separate dedicated ticket.
> h3. Implementation suggestions
> I don’t plan to implement this feature myself. But since I have analyzed the issue, I can give my suggestions on how to implement it:
>  # The {{-tsapolicyid}} parameter is currently missing in the maven-jarsigner project. Consider adding support for this while implementing this ticket.
>  # Since {{{}-tsa{}}}, {{{}-tsacert{}}}, {{-tsapolicyid}} all belong together, I would recommend making a list of all 3.
>  # If the user specifies 3 tsa URLs but only 1 tsacert it gets a bit tricky. The easiest way to handle this is to use validateParameters() (see [https://github.com/apache/maven-jarsigner-plugin/pull/13/]) and throw a MojoExecutionException if this happens.
>  # I recommend using a comma as separator for the items in the list. This way it would be possible to change the data type from String to String[] and Maven will itself handle the splitting on the comma (if using the command format) or mangling of nested XML tags into a String[] (if using nested XML format). Thus, the JarsignerSignMojo would not need to do any String splitting.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)