Date: Thu, 28 Mar 2024 16:41:23 +0000 (UTC) Message-ID: <496878859.15.1711644083923@637274d5a2f3> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_14_1703195158.1711644083922" ------=_Part_14_1703195158.1711644083922 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Please review these rele= ase notes before upgrading your system. You should review the notes for all= the versions subsequent to the one you're running prior to upgrade, includ= ing referring back to older V2 notes.
Release date: 2020-12-15
XSTJ-67: In this release of xmlsec=
tool
, the --key
option has been split into&nb=
sp;--keyAlias
and --keyFile
depend=
ing on operation (--keyFile
is used with --cer=
tificate
while --keyAlias
is used with =
keystores and with PKCS#11 tokens). The --key
option=
can still be used in both contexts but will result in a deprecation warnin=
g. The --key
option will be removed in the next majo=
r release of xmlsectool
(4.0.0).
XSTJ-68: Previous versions of =
xmlsectool
set an explicit heap limit of 256MB to compens=
ate for the very low defaults imposed by early versions of Java. xmlsectool
no longer does this, as recent Java versions on mod=
ern hardware now allows the allocation of a much larger heap by default. Th=
is means that xmlsectool
will be more likely to work on l=
arge documents. For documents which need still more heap, set a non-default=
heap size by invoking xmlsectool
like this:
JVMOPTS= =3D"-Xmx1.5G" ...xmlsectool --sign ...
XSTJ-69: xmlsectool
&nb=
sp;3.0.0 includes defensive coding to limit the effect of some changes that=
have been made to the XML DSIG code within the JDK and the Santuario XML s=
ecurity dependency library. The intention is to ensure that xmls=
ectool
produces the same output across versions of these depend=
encies, and to ensure that signed output does not include encoded CR charac=
ters (
or similar) known to cause problems for some c=
onsumers. One result is that in most circumstances, xmlsectool=
code> 3.0.0 produces identical output to
xmlsectool
&=
nbsp;2.0.0, although this is not guaranteed and in particular may not be th=
e case for a future major version of xmlsectool
.
XSTJ-73: xmlsectool
&nb=
sp;3.0.0 is now based on the Shibboleth Project's Java 11 product platform. This means tha=
t it requires a minimum of Java 11 to run. For more details on supported Ja=
va versions and distributions, see System R=
equirements.
XSTJ-82: Changes in the way Java handles the SunPKCS11 provider have n=
ecessarily resulted in changes to the way xmlsectool provides this functionality=
. The full details can be found in Using PKCS#11 Credentials=
; if you are upgrading from a p=
revious version of
xmlsectool
then Upgrading from a previous version of xmlsectool=
gives detailed instruct=
ions.
XSTJ-85: for reasons of clarity and inclusivity, the following command-line= options have been renamed:
--clearBlacklist
becomes --allowAllDigests
--blacklistDigest
becomes --disallowDigest
--whitelistDigest
becomes --allowDigest
--listBlacklist
becomes --listAlgorithms
If you use one of the old option names, i=
t will still work but you will be reminded to use the new name through a de=
precation warning. The old names for these options will be removed in the n=
ext major release of xmlsectool
(4.0.0).