xmlsec patches

[Miklos Vajna]

Hi,

On Mon, Feb 13, 2017 at 09:14:31AM +0000, Caolán McNamara <caolanm at redhat.com> wrote:
> the one that bothers me the most is libxmlsec because we never got the
> modifications upstream or found another way to do whatever it is we do
> to it.

I started to care about this when I added a few more patches (which are
now upstreamed), here is what I know currently:

external/libxmlsec/xmlsec1-1.2.14_fix_extern_c.patch.1: build fix, not
too interesting

external/libxmlsec/xmlsec1-configure.patch.1: same

external/libxmlsec/xmlsec1-customkeymanage.patch.1: this is a monster, I
think this has to do something with smart-card handling, but I never got
around to actually understand what it does. This is the real blocker
wrt. building against system xmlsec.

external/libxmlsec/xmlsec1-noverify.patch.1: I submitted patches
upstream to have a flag that does this so after the next upstream
release this can go away.

external/libxmlsec/xmlsec1-nssdisablecallbacks.patch.1
external/libxmlsec/xmlsec1-nssmangleciphers.patch.1: I didn't look into
these yet, but they do not look too complicated, probably they do not
block the system-xmlsec effort.

external/libxmlsec/xmlsec1-vc.patch.1: not relevant for Linux.

The worst thing about the custom key manage patch is that most of it was
introduced in commit ebd1b95bb5f9235d1dba1b840fd746c9b53320d2 (13891
insertions!) without any real commit message. I wonder if perhaps there
is still somewhere a description of what the xmlsec08 CWS was about...
:-)

Regards,

Miklos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20170213/f6b129bb/attachment.sig>