lsh123
cleanup release (targeting spring 2023)
- Bump version to xmlsec 1.3.1
- Remove soap support
- Remove OpenSSL 1.0.0 support
- Remove LibreSSL before version 2.7.0
- Remove all XMLSEC_DEPRECATED functions and macros
libxml2 2.10.0 disables FTP by default and there's bugs in it which won't be fixed. Maybe worth dropping FTP support entirely, or making it optional with a configure option?
Sure, xmlsec uses libxml2 anyway for this so if it is disabled there, then it will be disabled here
libxml2 2.10.0 disables FTP by default and there's bugs in it which won't be fixed. Maybe worth dropping FTP support entirely, or making it optional with a configure option?
I double checked the code, the xmlsec relies on LIBXML_FTP_ENABLED flag so ftp in xmlsec is enabled/disabled at the same time as LibXML2
Right, the problem is that if you rebuild libxml2 to a newer version without FTP on by default, your xmlsec binary is then broken. xmlsec needs to make it configurable to allow you to explicitly say what you want.
Right, the problem is that if you rebuild libxml2 to a newer version without FTP on by default, your xmlsec binary is then broken. xmlsec needs to make it configurable to allow you to explicitly say what you want.
Indeed, but I think it is true regardless: if one links against a library with feature X enabled, and then library disables feature X -> the upstream binary will be broken.
Usually such options don't then control ABI though and/or consumers have a hard requirement on it being on/off, rather than "automagic". It poses a problem for distributions (https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies).
sure but even if there is a configure flag for xmlsec, it means xmlsec has to be re-built
Yeah, that's a consequence of libxml2's choice and unavoidable unfortunately. But with e.g. a proper configure argument, you can disable ftp support in xmlsec, rebuild it, then rebuild libxml2 without it, without the xmlsec binary being broken at any point in time.
Yeah, that's a consequence of libxml2's choice and unavoidable unfortunately. But with e.g. a proper configure argument, you can disable ftp support in xmlsec, rebuild it, then rebuild libxml2 without it, without the xmlsec binary being broken at any point in time.
There are many dependencies between the two libraries: iconv support, unicode support (windows), etc. Changing configuration params one side w/o changing the other is going to break things. As I mentioned above, any feature X removed from a dependency library will cause problems.
Yes, that's fine, but the lack of a configure option for xmlsec means that you can't do it in a clean order which means you have a working xmlsec binary throughout (see previous comment).
Yes, that's fine, but the lack of a configure option for xmlsec means that you can't do it in a clean order which means you have a working xmlsec binary throughout (see previous comment).
PR #577