Andreas Steffen
2017-05-19 06:51:21 UTC
Hello Noel,
actually the compile option --enable-integrity-test generates
a checksum [which currently is not cryptographically strong]
stored in src/checksum/checksum.c of each strongSwan plugin
and library and includes the checksums in a struct in the
charon daemon code. This guarantees that the daemon always
loads the correct version of the plugins and libraries.
Best regards
Andreas
actually the compile option --enable-integrity-test generates
a checksum [which currently is not cryptographically strong]
stored in src/checksum/checksum.c of each strongSwan plugin
and library and includes the checksums in a struct in the
charon daemon code. This guarantees that the daemon always
loads the correct version of the plugins and libraries.
Best regards
Andreas
Hello list,
I am working on implementing version checking for plugins to prevent the mixing of different
library and plugin versions. This has accidently happened in the past and caused issues.
Implementing this will reduce the work load in support slightly.
The code I wrote thus far is in the "plugin-version-check" branch[1] in my strongSwan repo fork[2]
It works by accessing the "version" attribute of the public interface of the plugin during load time
and compares it with the "version" attribute of libstrongswan. That obviously requires ever plugin
to have that attribute set.
I stumbled upon the problem, that to define a plugin's version and make sure that it is included in the shared object
statically, I'd need to touch that plugin's source files. So if I wanted to introduce version checking,
I'd need to edit every single plugin and at the same time, it will cause that third party plugins won't build
without changes.
Is there another solution to this problem?
Kind regards,
Noel
[1] https://github.com/Thermi/strongswan/tree/plugin-version-check
[2] https://github.com/Thermi/strongswan/
I am working on implementing version checking for plugins to prevent the mixing of different
library and plugin versions. This has accidently happened in the past and caused issues.
Implementing this will reduce the work load in support slightly.
The code I wrote thus far is in the "plugin-version-check" branch[1] in my strongSwan repo fork[2]
It works by accessing the "version" attribute of the public interface of the plugin during load time
and compares it with the "version" attribute of libstrongswan. That obviously requires ever plugin
to have that attribute set.
I stumbled upon the problem, that to define a plugin's version and make sure that it is included in the shared object
statically, I'd need to touch that plugin's source files. So if I wanted to introduce version checking,
I'd need to edit every single plugin and at the same time, it will cause that third party plugins won't build
without changes.
Is there another solution to this problem?
Kind regards,
Noel
[1] https://github.com/Thermi/strongswan/tree/plugin-version-check
[2] https://github.com/Thermi/strongswan/
--
======================================================================
Andreas Steffen ***@strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==
======================================================================
Andreas Steffen ***@strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==