Adds Travis-CI configuration

[eriknellessen]

Fixes bad handling of PREFIX in Makefile: What is the advantage of the new version?

Adds initial Travis-CI configuration: If I understand it correctly, the "INSECURE" switch is used to download the dependencies in an insecure way and to switch off peer verification and hostname verification in the eIDClientCore library. Installing software from a not authenticated source is another thing than switching off the security mechanisms in eIDClientCore. Installing software from a not authenticated source opens other possibilities for an attacker than performing the eID service in a non-authentic way. That is why I think, that two switches should be used. This way, one could install the dependencies only from authentic sources while still being able to switch off peer verification and hostname verification (which could make testing easier).

[frankmorgner]

• PREFIX (set with ./configure --prefix=...) determines the installation directory. However, previously PREFIX was used as if it determines the location from where you're building. In other words, you can now specify an install location as done here https://github.com/frankmorgner/eIDClientCore/blob/master/.travis.yml#L16
• If INSECURE is off, all SSL connections are verified as expected made by both, wget and eIDClientCore. This is and should be the default. I agree, that you may switch to the insecure mode while testing. And this is exactly what is needed to get things work in Travis-CI. For whatever reason, the sources for asn1c and for libexpat cannot correctly be verified, even with the correct certificates/sha1sum supplied. This can mean a lot of things, but in the end you only want travis to test your build chain. You don't want travis to be your trusted source for the built binaries...

(By the way, if everyone fetches the sources from Github via SSL, I don't think supplying the trust anchors for other SSL connections is very useful. If an attacker can compromise the connection to asn1c or libexpat, he can surely do the same to the initial github connection. And if he can, he can very well replace the trust anchors given in the repository.)

[eriknellessen]

• About PREFIX: Ok.
• "If an attacker can compromise the connection to asn1c or libexpat, he can surely do the same to the initial github connection." I do not think so. The connection to github is authentic (as we are using SSL). The connection to asn1c or libexpat is not (if the INSECURE switch is set). So compromising the connection to asn1c or libexpat is possible, while compromising the github connection is not without the user noticing it. "And this is exactly what is needed to get things work in Travis-CI. For whatever reason, the sources for asn1c and for libexpat cannot correctly be verified, even with the correct certificates/sha1sum supplied." Ok, so we should not authenticate the source files in Travis-CI. The changes in the Makefile affect all platforms, like building the eIDClientCore in our lab. I suggest the "two-switches-solution" which I already suggested in my first commentary. We could then change the Travis-file to deactivate both security mechanisms. This way, we (and everyone else) can still build the eIDClientCore in a secure way and still test without peer verification and hostname verification (which we need) and Travis-CI also works.

[frankmorgner]

Two switches are fine with me, but please remember to not disable peer/hostname verification for everyone by default.

Have you tried setting CFLAGS or CXXFLAGS the standard way instead of using sed? something like export CFLAGS="..." && make eIDClient or ./configure CFLAGS="..."?

[frankmorgner]

See https://travis-ci.org/frankmorgner/eIDClientCore/jobs/80815883 and https://travis-ci.org/frankmorgner/eIDClientCore/jobs/80807648 if you want to investigate further why disabling the ssl verification and sha1validation was necessary.

[psytester]

After Makefile was changed from

$(PREFIX)/OpenSSL_1_0_2-stable/apps/openssl ciphers 'RSAPSK' -v ;\ 

into

OpenSSL_1_0_2-stable/apps/openssl ciphers 'RSAPSK' -v ;\ 

The build process does not longer work for me, as the make job does not longer find the openssl executable:

/bin/bash: line 10: OpenSSL_1_0_2-stable/apps/openssl: No such file or Directory

[frankmorgner]

it's possible that there was a previous error. Was the executable installed to $PREFIX/bin/openssl?

[wolfmueller]

The problem occurred while testing the fresh built binary for RSA_PSK chiphers.
It was fixed in f56c706d2ab5588dec224bf23c06c086620bc00b :-)

[psytester]

1.) There was no previous error during build process. It simply does not find the executable at the suspected location. make -d in debug mode and an additional pwd in it shows me the simple reason

Im make target openssl first we go into the OpenSSL Directory:

cd OpenSSL_1_0_2-stable ;\

And after the make install_sw the make Job is pretending to leave the directoy

Leaving Directory /........./eIDClientCore-master/OpenSSL_1_0_2-stable

but the pwd command clearly shows that we are still in that Directory ..../OpenSSL_1_0_2-stable

If you don't what to use $(PREFIX) a call will relative path is working too:

../OpenSSL_1_0_2-stable/apps/openssl ciphers 'RSAPSK' -v ;

2.) Yes, the executable was installed to $PREFIX/bin/ and it is executable from there

[frankmorgner]

nevermind, its fixed with 39f402844031add6d09f2c6b8c6cca5d502f1c0b

[psytester]

Yes, after Pull request 44 with usage of "apps/openssl ciphers 'RSAPSK' -v ;\ " it works as expected