xmlsectool: binary jar file bails out when the built-from-source version works

[Ian Young]

> On 2020-09-27, at 08:42, Weiwu Zhang via dev <dev at shibboleth.net> wrote:
> 
> 
> I have a case that caused the binary distribution† of 27-April-2020 to throw an exception
> 
> † xmlsectool-2.0.0-bin.zip downloaded from http://shibboleth.net/downloads/tools/xmlsectool/2.0.0/

I think you have been misled by the file dates, which were updated when we moved to a new server. In fact, that distribution dates to 2016-06-27. It is still the current stable release, however.

This release is supported under Java 7 (although these days I would recommend against it), Java 8 and Java 11. We neither test nor support XMLSecTool V2 against Java 14. I'm still interested -- in principle -- in getting to the bottom of your issue, so please open a JIRA case. I'd also appreciate it if you can try to reproduce the issue under a supported version of Java, for example Java 11.

It would also help if you could provide steps to generate a similar key (obviously not the one you're using).


> while the source code cloned‡ works.
> ‡ git clone https://git.shibboleth.net/git/xmlsectool

This will build a snapshot of the forthcoming 3.0.0 release. That's obviously very different in some ways, and in particular it is based on Java 11 rather than Java 7. It will support Java 11 and, I expect, Java 17 when it comes along. It will not directly support Java 14, but we do test the snapshots against Java 14 today to make sure that we get everything right for Java 17 (the next LTS release).

If that's working for you, it looks like we have already fixed the problem, possibly just by using more modern dependencies. I'd still like to add a test for this if possible, though, which is why I will be interested to see more details in a JIRA case.


> I am not sure what's the trigger, but my guess is that BouncyCastle
> didn't recognise the secp256r1 EC key used here.

That's entirely possible.


> In the commandline "…" represent the bunch of dependency jar files on
> my system†. Most noticablly, the version of BouncyCastle used is 1.64
> (compared to the embeded 1.53 brprov which threw up). Could it be the
> cause that the binary distribution failed?

No, the binary distribution is correct, but it's from 2016 and it has a lot of 2016-era dependencies included, which may well be the reason it doesn't handle your use case.

However, one thing you really can't do is just substitute a lot of uncontrolled dependencies from your local machine. Or at least, we can't support you if you take that route. What you need to do is instead use Maven to build the project you cloned (mvn -Prelease clean package). This will give you (in target/xmlsectool-3.0.0-SNAPSHOT-bin.zip) something that is directly comparable with the previous release in that it includes all of the dependencies we will ship V3 with (including, of course, BouncyCastle 1.64). If there's a problem with that combination, of course we'll try to address that. 

    -- Ian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20200928/f5fc4808/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3883 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20200928/f5fc4808/attachment.p7s>