Created attachment 55445 [details]
patch to do this

cmc->mt: In xmlsecurity/util/makefile.mk is a to-do of "#MT: Remove libxml2 and
xs_comm (above) by creating service for base encodings"

I'd like to remove the linkage of libxmlsecurity on libxmlsec, leaving just
libxsec_xmlsec linked to libxmlsec. And removing the duplicated object code of
basencoding.o and biginteger.o which is linked into both. 

The attached patch does this by reusing the base64 encoder of the xmloff
project, and introducing a new uno api for converting the serial numbers to/from
big integer uno::sequences and OUStrings.

Is this ok from your side, or any alternative changes you'd prefer ?

Jochen (jl) took over xmlsecurity some time ago...

Jochen - can you please have a look at that?

Thanks :)

Good idea.
Please use a 'new style'. That is define the service in idl (should be a
separate file). For example:

service SerialNumberAdapter: XSerialNumberAdapter;

An instance is create like this:

Reference<XSerialNumberAdapter> adapter =
SerialNumberAdapter::create(component_context);

You can certainly find a description in the Developer's Guide. There are also
test services in testtools, which use a parameterized constructor. Look for the
service Constructor in 
testtools/source/bridgetest/idl/bridgetest.idl
testools/source/bridgetest/constructors.cxx
testtools/wntmsci12.pro/inc/test/testtools/bridgetest/Constructors.hpp

Having this service, I would create an instance in the classes directly where I
need them and not passing the interface along in the constructors. However, one
always needs the component context. So if you found an easy way to access the
context in the respective classes ...

Created attachment 55480 [details]
updated patch

How about this then, uses new service. 

Though the existing xmlsecurity doesn't keep any component handles around, so
still have to effectively key off the XMultiServiceFactory unless we go
rewriting a chunk of it, which is surely out of scope of this little effort

Looks good. You missed the one creation of SerialNumberAdapter in
certificatechooser.cxx, though :)

Do you mean the comphelper::createProcessComponent usage in
certificatechooser.cxx, (and the same in macrosecurity.cxx), neither of those
already have a convenient handle. So would you prefer that I add a
XMultiServiceFactory member to CertificateChooser, (or add a XComponentContext
member to them) and key off that rather than using createProcessComponent ?

I'd prefer to pass the XComponentContext along. That is,  the initial service
should keep the context and pass it to the constructors of other classes. But
that's the ideal world. So, leave it or change it if you like. :)

Created attachment 55493 [details]
move invasive patch

I kind of wanted to avoid getting sucked into fixing/updating code unrelated to
my mini-mission. But nevertheless, this should do the trick, bumping up from
XMultiServiceManagers to the XComponentContext based stuff the tree of users.

... and while you are at it, how about fixing the whole signing feature? :)

Just kidding. Thanks for your trouble.

Checked into cmcfixes48

reassign for qa

Signing works as expected and fully functional. Checked with Linux and Windows build

Integrated DEV300m30