Hi, On Mon, Feb 13, 2017 at 09:14:31AM +0000, Caolán McNamara <caol...@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
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
