[ima-evm-utils:,5/5] ima-evm-utils: travis: openssl gost engine
diff mbox series

Message ID 20200731182408.696931-6-zohar@linux.ibm.com
State New
Headers show
Series
  • initial travis support
Related show

Commit Message

Mimi Zohar July 31, 2020, 6:24 p.m. UTC
The openssl version on travis doesn't have gost openssl engine support.
Download from source, rebuild and install local version.

Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
---
 .travis.yml                  |  7 +++++++
 tests/install-gost-engine.sh | 10 ++++++++++
 2 files changed, 17 insertions(+)
 create mode 100755 tests/install-gost-engine.sh

Comments

Vitaly Chikunov July 31, 2020, 6:56 p.m. UTC | #1
Mimi,

On Fri, Jul 31, 2020 at 02:24:08PM -0400, Mimi Zohar wrote:
> The openssl version on travis doesn't have gost openssl engine support.
> Download from source, rebuild and install local version.
> 
> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
>  .travis.yml                  |  7 +++++++
>  tests/install-gost-engine.sh | 10 ++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100755 tests/install-gost-engine.sh
> 
> diff --git a/.travis.yml b/.travis.yml
> index 11a827c02f0a..f5fb2c1da448 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -15,6 +15,13 @@ matrix:
>     include:
>       - env: TSS=ibmtss
>       - env: TSS=tpm2-tss
> +
> +before_install:
> +   - if [ "${SSL}" = "openssl" ]; then
> +        ./tests/install-gost-engine.sh;
> +        openssl version;
> +     fi
> +
>  install:
>     - if [ "${TSS}" = "tpm2-tss" ]; then
>             sudo apt-get install lcov pandoc autoconf-archive liburiparser-dev;
> diff --git a/tests/install-gost-engine.sh b/tests/install-gost-engine.sh
> new file mode 100755
> index 000000000000..01bcf2c3bc21
> --- /dev/null
> +++ b/tests/install-gost-engine.sh
> @@ -0,0 +1,10 @@
> +#!/bin/sh
> +
> +openssl version
> +
> +git clone https://github.com/gost-engine/engine.git

gost-engine master branch corresponds to openssl-3.0 which is probably
not on Travis systems yet. I think branch `openssl_1_1_0` should be used.

  git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git

Thanks,

> +cd engine
> +#cmake -DOPENSSL_INCLUDE_DIR=/usr/local/include/openssl -DOPENSSL_SSL_LIBRARY=/usr/local/lib64/libss.so -DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib64/libcrypto.so -DOPENSSL_ENGINES_DIR=/usr/local/lib64/engines-1.1 .
> +cmake .
> +sudo make install
> +cd ..
> -- 
> 2.18.4
Petr Vorel July 31, 2020, 8:18 p.m. UTC | #2
Hi,

> > +++ b/tests/install-gost-engine.sh
> > @@ -0,0 +1,10 @@
> > +#!/bin/sh
> > +
> > +openssl version
> > +
> > +git clone https://github.com/gost-engine/engine.git

> gost-engine master branch corresponds to openssl-3.0 which is probably
> not on Travis systems yet. I think branch `openssl_1_1_0` should be used.

>   git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git

FYI: it work on current setup.
https://travis-ci.org/github/pevik/ima-evm-utils/builds/713815774

Kind regards,
Petr
Vitaly Chikunov July 31, 2020, 8:26 p.m. UTC | #3
Petr,

On Fri, Jul 31, 2020 at 10:18:08PM +0200, Petr Vorel wrote:
> > > +++ b/tests/install-gost-engine.sh
> > > @@ -0,0 +1,10 @@
> > > +#!/bin/sh
> > > +
> > > +openssl version
> > > +
> > > +git clone https://github.com/gost-engine/engine.git
> 
> > gost-engine master branch corresponds to openssl-3.0 which is probably
> > not on Travis systems yet. I think branch `openssl_1_1_0` should be used.
> 
> >   git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git
> 
> FYI: it work on current setup.
> https://travis-ci.org/github/pevik/ima-evm-utils/builds/713815774

I think `install-gost-engine.sh` is not executed in this line:

  257 $ if [ "${SSL}" = "openssl" ]; then ./tests/install-gost-engine.sh; openssl version; fi   0.00s

> 
> Kind regards,
> Petr
Petr Vorel July 31, 2020, 8:40 p.m. UTC | #4
> Petr,

> On Fri, Jul 31, 2020 at 10:18:08PM +0200, Petr Vorel wrote:
> > > > +++ b/tests/install-gost-engine.sh
> > > > @@ -0,0 +1,10 @@
> > > > +#!/bin/sh
> > > > +
> > > > +openssl version
> > > > +
> > > > +git clone https://github.com/gost-engine/engine.git

> > > gost-engine master branch corresponds to openssl-3.0 which is probably
> > > not on Travis systems yet. I think branch `openssl_1_1_0` should be used.

> > >   git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git

> > FYI: it work on current setup.
> > https://travis-ci.org/github/pevik/ima-evm-utils/builds/713815774

> I think `install-gost-engine.sh` is not executed in this line:

>   257 $ if [ "${SSL}" = "openssl" ]; then ./tests/install-gost-engine.sh; openssl version; fi   0.00s

Good catch!
$ ./tests/install-gost-engine.sh
OpenSSL 1.1.1g  21 Apr 2020
fatal: destination path 'engine' already exists and is not an empty directory.
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR: Found unsuitable version "1.1.1g", but
  required is at least "3.0" (found /usr/lib64/libcrypto.so, )
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:456 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindOpenSSL.cmake:486 (find_package_handle_standard_args)
  CMakeLists.txt:11 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/pvorel/install/src/ima-evm-utils.git/engine/CMakeFiles/CMakeOutput.log".
make: *** No rule to make target 'install'.  Stop.

And when using suggested branch openssl_1_1_0, it also fails on make install
$ ./tests/install-gost-engine.sh
OpenSSL 1.1.1g  21 Apr 2020
Cloning into 'engine'...
remote: Enumerating objects: 63, done.
remote: Counting objects: 100% (63/63), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 2738 (delta 33), reused 32 (delta 21), pack-reused 2675
Receiving objects: 100% (2738/2738), 2.48 MiB | 2.09 MiB/s, done.
Resolving deltas: 100% (1735/1735), done.
-- The C compiler identification is GNU 10.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "1.1.1g", minimum required is "1.1")
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Searching 16 bit integer - Using unsigned short
-- Check if the system is big endian - little endian
-- LITTLE_ENDIAN
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pvorel/install/src/ima-evm-utils.git/engine
make: *** No rule to make target 'install'.  Stop.

=> It'd be good to fix this and add some test with SSL=openssl variable.
But the branch would have to be updated time to time.

BTW do you plan to test other crypto libraries?

Kind regards,
Petr
Vitaly Chikunov July 31, 2020, 9:06 p.m. UTC | #5
On Fri, Jul 31, 2020 at 10:40:44PM +0200, Petr Vorel wrote:
> And when using suggested branch openssl_1_1_0, it also fails on make install
> $ ./tests/install-gost-engine.sh
> OpenSSL 1.1.1g  21 Apr 2020
> Cloning into 'engine'...
> remote: Enumerating objects: 63, done.
> remote: Counting objects: 100% (63/63), done.
> remote: Compressing objects: 100% (40/40), done.
> remote: Total 2738 (delta 33), reused 32 (delta 21), pack-reused 2675
> Receiving objects: 100% (2738/2738), 2.48 MiB | 2.09 MiB/s, done.
> Resolving deltas: 100% (1735/1735), done.
> -- The C compiler identification is GNU 10.1.1
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "1.1.1g", minimum required is "1.1")
> -- Check if the system is big endian
> -- Searching 16 bit integer
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of unsigned short
> -- Check size of unsigned short - done
> -- Searching 16 bit integer - Using unsigned short
> -- Check if the system is big endian - little endian
> -- LITTLE_ENDIAN
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/pvorel/install/src/ima-evm-utils.git/engine
> make: *** No rule to make target 'install'.  Stop.

It seems this branch does not have install target. I think,

- `engine/bin/gost.so` should be moved in platform dependent engines dir,
for example for debian9 it's `/usr/lib/x86_64-linux-gnu/engines-1.1/`
(found with strace).

- Or, just keep it as is, but `OPENSSL_ENGINES` env should be set to
`/home/pvorel/install/src/ima-evm-utils.git/engine/bin/`.

- Or even better, Bionic (which is supported by Travis) should have
  gost-engine already in the libengine-gost-openssl1.1 package.

  In that case `.travis.yml` should have `dist: bionic`.
    https://docs.travis-ci.com/user/reference/bionic/



> 
> => It'd be good to fix this and add some test with SSL=openssl variable.
> But the branch would have to be updated time to time.
> 
> BTW do you plan to test other crypto libraries?
> 
> Kind regards,
> Petr
Mimi Zohar July 31, 2020, 10:32 p.m. UTC | #6
On Sat, 2020-08-01 at 00:06 +0300, Vitaly Chikunov wrote:
> On Fri, Jul 31, 2020 at 10:40:44PM +0200, Petr Vorel wrote:
> > And when using suggested branch openssl_1_1_0, it also fails on
> > make install
> > $ ./tests/install-gost-engine.sh
> > OpenSSL 1.1.1g  21 Apr 2020
> > Cloning into 'engine'...
> > remote: Enumerating objects: 63, done.
> > remote: Counting objects: 100% (63/63), done.
> > remote: Compressing objects: 100% (40/40), done.
> > remote: Total 2738 (delta 33), reused 32 (delta 21), pack-reused
> > 2675
> > Receiving objects: 100% (2738/2738), 2.48 MiB | 2.09 MiB/s, done.
> > Resolving deltas: 100% (1735/1735), done.
> > -- The C compiler identification is GNU 10.1.1
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Check for working C compiler: /usr/bin/cc - skipped
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version
> > "1.1.1g", minimum required is "1.1")
> > -- Check if the system is big endian
> > -- Searching 16 bit integer
> > -- Looking for sys/types.h
> > -- Looking for sys/types.h - found
> > -- Looking for stdint.h
> > -- Looking for stdint.h - found
> > -- Looking for stddef.h
> > -- Looking for stddef.h - found
> > -- Check size of unsigned short
> > -- Check size of unsigned short - done
> > -- Searching 16 bit integer - Using unsigned short
> > -- Check if the system is big endian - little endian
> > -- LITTLE_ENDIAN
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/pvorel/install/src/ima-
> > evm-utils.git/engine
> > make: *** No rule to make target 'install'.  Stop.
> 
> It seems this branch does not have install target. I think,
> 
> - `engine/bin/gost.so` should be moved in platform dependent engines
> dir,
> for example for debian9 it's `/usr/lib/x86_64-linux-gnu/engines-1.1/`
> (found with strace).
> 
> - Or, just keep it as is, but `OPENSSL_ENGINES` env should be set to
> `/home/pvorel/install/src/ima-evm-utils.git/engine/bin/`.
> 
> - Or even better, Bionic (which is supported by Travis) should have
>   gost-engine already in the libengine-gost-openssl1.1 package.
> 
>   In that case `.travis.yml` should have `dist: bionic`.
>     https://docs.travis-ci.com/user/reference/bionic/

Yes, for the internal git repo I made this change.   The internal
travis support for bionic is different than the external travis.   I'll
post what I have as an RFC.
 
> 
> 
> > => It'd be good to fix this and add some test with SSL=openssl
> > variable.
> > But the branch would have to be updated time to time.
> > 
> > BTW do you plan to test other crypto libraries?

Mikhail Novosyolov posted a patch for libressl, but didn't followup
with v2.   The openssl code version/release sections need to be cleaned
up for libressl some more for libressl.

For matrix testing, it would be nice for the package names and versions
to be included in the output.

Mimi
Mimi Zohar Aug. 3, 2020, 2:53 a.m. UTC | #7
On Fri, 2020-07-31 at 22:40 +0200, Petr Vorel wrote:
> > Petr,
> > On Fri, Jul 31, 2020 at 10:18:08PM +0200, Petr Vorel wrote:
> > > > > +++ b/tests/install-gost-engine.sh
> > > > > @@ -0,0 +1,10 @@
> > > > > +#!/bin/sh
> > > > > +
> > > > > +openssl version
> > > > > +
> > > > > +git clone https://github.com/gost-engine/engine.git
> > > > gost-engine master branch corresponds to openssl-3.0 which is
> > > > probably
> > > > not on Travis systems yet. I think branch `openssl_1_1_0`
> > > > should be used.
> > > >   git clone --branch openssl_1_1_0 
> > > > https://github.com/gost-engine/engine.git
> > > FYI: it work on current setup.
> > > https://travis-ci.org/github/pevik/ima-evm-utils/builds/713815774
> > I think `install-gost-engine.sh` is not executed in this line:
> >   257 $ if [ "${SSL}" = "openssl" ]; then ./tests/install-gost-
> > engine.sh; openssl version; fi   0.00s
> 
> Good catch!
> $ ./tests/install-gost-engine.sh
> OpenSSL 1.1.1g  21 Apr 2020
> fatal: destination path 'engine' already exists and is not an empty
> directory.
> CMake Error at
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:165
> (message):
>   Could NOT find OpenSSL, try to set the path to OpenSSL root folder
> in the
>   system variable OPENSSL_ROOT_DIR: Found unsuitable version
> "1.1.1g", but
>   required is at least "3.0" (found /usr/lib64/libcrypto.so, )
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:456
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake/Modules/FindOpenSSL.cmake:486
> (find_package_handle_standard_args)
>   CMakeLists.txt:11 (find_package)
> 
> -- Configuring incomplete, errors occurred!
> See also "/home/pvorel/install/src/ima-evm-
> utils.git/engine/CMakeFiles/CMakeOutput.log".
> make: *** No rule to make target 'install'.  Stop.
> 
> And when using suggested branch openssl_1_1_0, it also fails on make
> install
> $ ./tests/install-gost-engine.sh
> OpenSSL 1.1.1g  21 Apr 2020
> Cloning into 'engine'...
> remote: Enumerating objects: 63, done.
> remote: Counting objects: 100% (63/63), done.
> remote: Compressing objects: 100% (40/40), done.
> remote: Total 2738 (delta 33), reused 32 (delta 21), pack-reused 2675
> Receiving objects: 100% (2738/2738), 2.48 MiB | 2.09 MiB/s, done.
> Resolving deltas: 100% (1735/1735), done.
> -- The C compiler identification is GNU 10.1.1
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version
> "1.1.1g", minimum required is "1.1")
> -- Check if the system is big endian
> -- Searching 16 bit integer
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of unsigned short
> -- Check size of unsigned short - done
> -- Searching 16 bit integer - Using unsigned short
> -- Check if the system is big endian - little endian
> -- LITTLE_ENDIAN
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/pvorel/install/src/ima-
> evm-utils.git/engine
> make: *** No rule to make target 'install'.  Stop.
> 
> => It'd be good to fix this and add some test with SSL=openssl
> variable.
> But the branch would have to be updated time to time.
> 
> BTW do you plan to test other crypto libraries?

Thanks, Vitaly, Petr, for catching this.  SSL isn't define yet.   The
test should be removed.  If/when libressl is added, it would look like:

-     - env: TSS=ibmtss
-     - env: TSS=tpm2-tss
+     - env: TSS=ibmtss SSL=openssl
+     - env: TSS=ibmtss SSL=libressl;
+     - env: TSS=tpm2-tss SSL=openssl
 
 before_install:
+   - if [ "${SSL}" = "libressl" ]; then
+        ./tests/install-libressl.sh;
+     fi

Mimi
Mimi Zohar Aug. 3, 2020, 3:09 a.m. UTC | #8
On Fri, 2020-07-31 at 18:32 -0400, Mimi Zohar wrote:
> 
> > - Or even better, Bionic (which is supported by Travis) should have
> >   gost-engine already in the libengine-gost-openssl1.1 package.
> > 
> >   In that case `.travis.yml` should have `dist: bionic`.
> >     https://docs.travis-ci.com/user/reference/bionic/
> 
> Yes, for the internal git repo I made this change.   The internal
> travis support for bionic is different than the external
> travis.   I'll post what I have as an RFC.

The internal travis support on ppc defaults to using Bionic, but the
way of specifying it is different.

+os: linux-ppc64le
 language: C
 addons:
  apt:

Mimi
Petr Vorel Aug. 3, 2020, 1:07 p.m. UTC | #9
Hi all,

> On Fri, 2020-07-31 at 18:32 -0400, Mimi Zohar wrote:

> > > - Or even better, Bionic (which is supported by Travis) should have
> > >   gost-engine already in the libengine-gost-openssl1.1 package.

> > >   In that case `.travis.yml` should have `dist: bionic`.
> > >     https://docs.travis-ci.com/user/reference/bionic/

> > Yes, for the internal git repo I made this change.   The internal
> > travis support for bionic is different than the external
> > travis.   I'll post what I have as an RFC.

> The internal travis support on ppc defaults to using Bionic, but the
> way of specifying it is different.

> +os: linux-ppc64le
>  language: C
>  addons:
>   apt:

@Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once
other issues are addressed, if this setup work for your internal travis support
as well. See examples .travis.yml [1] [2], builds: [3] [4].

Advantages are more realistic builds for distro maintainers (different libc and
libraries versions, you can test old and new distro releases, etc), but maybe
that's not what you want/need.

Disadvantage is that sometimes docker releases have temporary packaging related
issues (first build in [3]; failure in first build [4] is a bug in LTP, corner
case, which would be otherwise undiscovered a long time).

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/blob/master/.travis.yml
[2] https://github.com/iputils/iputils/blob/master/.travis.yml
[3] https://travis-ci.org/github/iputils/iputils/builds/714445071
[4] https://travis-ci.org/github/linux-test-project/ltp/builds/714400199
Petr Vorel Aug. 3, 2020, 1:11 p.m. UTC | #10
Hi all,

> Thanks, Vitaly, Petr, for catching this.  SSL isn't define yet.   The
> test should be removed.  If/when libressl is added, it would look like:

> -     - env: TSS=ibmtss
> -     - env: TSS=tpm2-tss
> +     - env: TSS=ibmtss SSL=openssl
> +     - env: TSS=ibmtss SSL=libressl;
> +     - env: TSS=tpm2-tss SSL=openssl

>  before_install:
> +   - if [ "${SSL}" = "libressl" ]; then
> +        ./tests/install-libressl.sh;
> +     fi

FYI: Libressl is packaged for some distros (if docker based Travis is used):

https://pkgs.org/download/libressl

Kind regards,
Petr
Mimi Zohar Aug. 3, 2020, 2:29 p.m. UTC | #11
On Mon, 2020-08-03 at 15:07 +0200, Petr Vorel wrote:
> Hi all,
> 
> > On Fri, 2020-07-31 at 18:32 -0400, Mimi Zohar wrote:
> > > > - Or even better, Bionic (which is supported by Travis) should have
> > > >   gost-engine already in the libengine-gost-openssl1.1 package.
> > > >   In that case `.travis.yml` should have `dist: bionic`.
> > > >     https://docs.travis-ci.com/user/reference/bionic/
> > > Yes, for the internal git repo I made this change.   The internal
> > > travis support for bionic is different than the external
> > > travis.   I'll post what I have as an RFC.
> > The internal travis support on ppc defaults to using Bionic, but the
> > way of specifying it is different.
> > +os: linux-ppc64le
> >  language: C
> >  addons:
> >   apt:
> 
> @Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once
> other issues are addressed, if this setup work for your internal travis support
> as well. See examples .travis.yml [1] [2], builds: [3] [4].
> 
> Advantages are more realistic builds for distro maintainers (different libc and
> libraries versions, you can test old and new distro releases, etc), but maybe
> that's not what you want/need.
> 
> Disadvantage is that sometimes docker releases have temporary packaging related
> issues (first build in [3]; failure in first build [4] is a bug in LTP, corner
> case, which would be otherwise undiscovered a long time).

Nice!  I definitely want to move to a docker based travis.   How should
we move forward?   Should there be a 1.3.1 release now with just the
few changes in the next branch and include the existing travis branch
with changes to address Vitaly's comments?

Mimi

> 
> [1] https://github.com/linux-test-project/ltp/blob/master/.travis.yml
> [2] https://github.com/iputils/iputils/blob/master/.travis.yml
> [3] https://travis-ci.org/github/iputils/iputils/builds/714445071
> [4] https://travis-ci.org/github/linux-test-project/ltp/builds/714400199
Mimi Zohar Aug. 3, 2020, 2:33 p.m. UTC | #12
On Mon, 2020-08-03 at 15:11 +0200, Petr Vorel wrote:
> Hi all,
> 
> > Thanks, Vitaly, Petr, for catching this.  SSL isn't define yet.   The
> > test should be removed.  If/when libressl is added, it would look like:
> > -     - env: TSS=ibmtss
> > -     - env: TSS=tpm2-tss
> > +     - env: TSS=ibmtss SSL=openssl
> > +     - env: TSS=ibmtss SSL=libressl;
> > +     - env: TSS=tpm2-tss SSL=openssl
> >  before_install:
> > +   - if [ "${SSL}" = "libressl" ]; then
> > +        ./tests/install-libressl.sh;
> > +     fi
> 
> FYI: Libressl is packaged for some distros (if docker based Travis is used):
> 
> https://pkgs.org/download/libressl

Good to know.   There's currently issues compiling ima-evm-utils with
libressl that need to be addressed.

Mimi
Vitaly Chikunov Aug. 3, 2020, 4:32 p.m. UTC | #13
Mimi,

On Fri, Jul 31, 2020 at 06:32:42PM -0400, Mimi Zohar wrote:
> >   In that case `.travis.yml` should have `dist: bionic`.
> >     https://docs.travis-ci.com/user/reference/bionic/
> 
> Yes, for the internal git repo I made this change.   The internal
> travis support for bionic is different than the external travis.   I'll
> post what I have as an RFC.

Excuse ma, what is internal/external travis? I know only travis from
github.

Thanks,
Petr Vorel Aug. 3, 2020, 4:36 p.m. UTC | #14
Hi all,

...
> Excuse ma, what is internal/external travis? I know only travis from
> github.
I guess IBM has some payed service from Travis, which they use internally.

Kind regards,
Petr
Petr Vorel Aug. 3, 2020, 4:46 p.m. UTC | #15
Hi all,

...
> > @Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once
> > other issues are addressed, if this setup work for your internal travis support
> > as well. See examples .travis.yml [1] [2], builds: [3] [4].

> > Advantages are more realistic builds for distro maintainers (different libc and
> > libraries versions, you can test old and new distro releases, etc), but maybe
> > that's not what you want/need.

> > Disadvantage is that sometimes docker releases have temporary packaging related
> > issues (first build in [3]; failure in first build [4] is a bug in LTP, corner
> > case, which would be otherwise undiscovered a long time).

> Nice!  I definitely want to move to a docker based travis.   How should
> we move forward?   Should there be a 1.3.1 release now with just the
> few changes in the next branch and include the existing travis branch
> with changes to address Vitaly's comments?
Yes, that would work for me. Travis changes aren't related to the release
(it just needs to be published in git), let's give users the fixes.

Docker based setup shouldn't take long It's all about to find the dependencies
for used distros (I usually keep them in travis/ directory [5] [6]) and agree on the
variants (which distros, how many jobs are still meaningful, which crypto and
TPM libraries, whether use also: clang, non-intel archs and cross-compilation).

Kind regards,
Petr

> Mimi

> > [1] https://github.com/linux-test-project/ltp/blob/master/.travis.yml
> > [2] https://github.com/iputils/iputils/blob/master/.travis.yml
> > [3] https://travis-ci.org/github/iputils/iputils/builds/714445071
> > [4] https://travis-ci.org/github/linux-test-project/ltp/builds/714400199

[5] https://github.com/linux-test-project/ltp/blob/master/travis/
[6] https://github.com/iputils/iputils/blob/master/travis/
Mimi Zohar Aug. 3, 2020, 5:16 p.m. UTC | #16
On Mon, 2020-08-03 at 18:46 +0200, Petr Vorel wrote:
> Hi all,
> 
> ...
> > > @Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once
> > > other issues are addressed, if this setup work for your internal travis support
> > > as well. See examples .travis.yml [1] [2], builds: [3] [4].
> > > Advantages are more realistic builds for distro maintainers (different libc and
> > > libraries versions, you can test old and new distro releases, etc), but maybe
> > > that's not what you want/need.
> > > Disadvantage is that sometimes docker releases have temporary packaging related
> > > issues (first build in [3]; failure in first build [4] is a bug in LTP, corner
> > > case, which would be otherwise undiscovered a long time).
> > Nice!  I definitely want to move to a docker based travis.   How should
> > we move forward?   Should there be a 1.3.1 release now with just the
> > few changes in the next branch and include the existing travis branch
> > with changes to address Vitaly's comments?

I left off the list TPM 2.0 --pcr support, but the kernel code for
exporting the sysfs TPM 2.0 pcrs hasn't been upstreamed yet.   I guess
we should wait for that to be upstreamed or at least queued to be
upstreamed.

> Yes, that would work for me. Travis changes aren't related to the release
> (it just needs to be published in git), let's give users the fixes.

Ok. 

> 
> Docker based setup shouldn't take long It's all about to find the dependencies
> for used distros (I usually keep them in travis/ directory [5] [6]) and agree on the
> variants (which distros, how many jobs are still meaningful, which crypto and
> TPM libraries, whether use also: clang, non-intel archs and cross-compilation).

Great!

Mimi
Mimi Zohar Aug. 3, 2020, 5:26 p.m. UTC | #17
On Sat, 2020-08-01 at 00:06 +0300, Vitaly Chikunov wrote:
> On Fri, Jul 31, 2020 at 10:40:44PM +0200, Petr Vorel wrote:
> > And when using suggested branch openssl_1_1_0, it also fails on make install
> > $ ./tests/install-gost-engine.sh
> > OpenSSL 1.1.1g  21 Apr 2020
> > Cloning into 'engine'...
> > remote: Enumerating objects: 63, done.
> > remote: Counting objects: 100% (63/63), done.
> > remote: Compressing objects: 100% (40/40), done.
> > remote: Total 2738 (delta 33), reused 32 (delta 21), pack-reused 2675
> > Receiving objects: 100% (2738/2738), 2.48 MiB | 2.09 MiB/s, done.
> > Resolving deltas: 100% (1735/1735), done.
> > -- The C compiler identification is GNU 10.1.1
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Check for working C compiler: /usr/bin/cc - skipped
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "1.1.1g", minimum required is "1.1")
> > -- Check if the system is big endian
> > -- Searching 16 bit integer
> > -- Looking for sys/types.h
> > -- Looking for sys/types.h - found
> > -- Looking for stdint.h
> > -- Looking for stdint.h - found
> > -- Looking for stddef.h
> > -- Looking for stddef.h - found
> > -- Check size of unsigned short
> > -- Check size of unsigned short - done
> > -- Searching 16 bit integer - Using unsigned short
> > -- Check if the system is big endian - little endian
> > -- LITTLE_ENDIAN
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/pvorel/install/src/ima-evm-utils.git/engine
> > make: *** No rule to make target 'install'.  Stop.
> 
> It seems this branch does not have install target. I think,
> 
> - `engine/bin/gost.so` should be moved in platform dependent engines dir,
> for example for debian9 it's `/usr/lib/x86_64-linux-gnu/engines-1.1/`
> (found with strace).
> 
> - Or, just keep it as is, but `OPENSSL_ENGINES` env should be set to
> `/home/pvorel/install/src/ima-evm-utils.git/engine/bin/`.
> 
> - Or even better, Bionic (which is supported by Travis) should have
>   gost-engine already in the libengine-gost-openssl1.1 package.
> 
>   In that case `.travis.yml` should have `dist: bionic`.
>     https://docs.travis-ci.com/user/reference/bionic/

Petr, Vitaly, so I should drop  "ima-evm-utils: travis: openssl gost
engine" and add "dist: bionic" instead?

Mimi
Vitaly Chikunov Aug. 3, 2020, 6:42 p.m. UTC | #18
Mimi,

On Mon, Aug 03, 2020 at 01:26:19PM -0400, Mimi Zohar wrote:
> On Sat, 2020-08-01 at 00:06 +0300, Vitaly Chikunov wrote:
> > On Fri, Jul 31, 2020 at 10:40:44PM +0200, Petr Vorel wrote:
> > - Or even better, Bionic (which is supported by Travis) should have
> >   gost-engine already in the libengine-gost-openssl1.1 package.
> > 
> >   In that case `.travis.yml` should have `dist: bionic`.
> >     https://docs.travis-ci.com/user/reference/bionic/
> 
> Petr, Vitaly, so I should drop  "ima-evm-utils: travis: openssl gost
> engine" and add "dist: bionic" instead?

I am not sure yet. As I remember, travis have different available ubuntu
distros for different arches. Thus, for ppc or s490x it may not have bionic.
It would be easier to fix install of gost-engine. It's small and will
build quickly.

Thanks,
Petr Vorel Aug. 4, 2020, 7:22 a.m. UTC | #19
Hi Mimi,

...
> I left off the list TPM 2.0 --pcr support, but the kernel code for
> exporting the sysfs TPM 2.0 pcrs hasn't been upstreamed yet.   I guess
> we should wait for that to be upstreamed or at least queued to be
> upstreamed.
OK, we have to wait. BTW is the patch somewhere on ML? Is it part of this
pathset https://patchwork.kernel.org/cover/11656949/ ?

After merging Lachlan's patchset https://patchwork.ozlabs.org/project/ltp/list/?series=193909
I'll fix ima_ltp only for TPM 1.2 (rebase my patch https://patchwork.ozlabs.org/project/ltp/patch/20200527071434.28574-1-pvorel@suse.cz/).

...
> > Docker based setup shouldn't take long It's all about to find the dependencies
> > for used distros (I usually keep them in travis/ directory [5] [6]) and agree on the
> > variants (which distros, how many jobs are still meaningful, which crypto and
> > TPM libraries, whether use also: clang, non-intel archs and cross-compilation).

> Great!
Just let me know once travis non-docker is fixed and in git (in which branch).

Kind regards,
Petr
Petr Vorel Aug. 4, 2020, 7:54 a.m. UTC | #20
Hi Mimi,

> ...
> > I left off the list TPM 2.0 --pcr support, but the kernel code for
> > exporting the sysfs TPM 2.0 pcrs hasn't been upstreamed yet.   I guess
> > we should wait for that to be upstreamed or at least queued to be
> > upstreamed.
> OK, we have to wait. BTW is the patch somewhere on ML? Is it part of this
> pathset https://patchwork.kernel.org/cover/11656949/ ?
Oh, that's for ima_evm_utils. I meant patchset for kernel space.

Kind regards,
Petr
Mimi Zohar Aug. 4, 2020, 12:05 p.m. UTC | #21
The openssl version might not have gost openssl engine support.
Download from source, rebuild and install local version.

Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
---
 .travis.yml                  | 10 ++++++++++
 tests/install-gost-engine.sh | 10 ++++++++++
 2 files changed, 20 insertions(+)
 create mode 100755 tests/install-gost-engine.sh

diff --git a/.travis.yml b/.travis.yml
index 11a827c02f0a..887f6bbea9b9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,6 +15,13 @@ matrix:
    include:
      - env: TSS=ibmtss
      - env: TSS=tpm2-tss
+
+before_install:
+   - if [ "${SSL}" = "openssl" ]; then
+        ./tests/install-gost-engine.sh;
+        openssl version;
+     fi
+
 install:
    - if [ "${TSS}" = "tpm2-tss" ]; then
            sudo apt-get install lcov pandoc autoconf-archive liburiparser-dev;
@@ -30,6 +37,9 @@ install:
 script:
    - export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib;
    - export PATH=$PATH:/usr/local/bin;
+   - if [ "${SSL}" = "openssl" ]; then
+        export OPENSSL_ENGINES="$OPENSSL_ENGINES:$PWD/engines/bin";
+     fi
    - autoreconf -i && ./configure && make -j$(nproc) && sudo make install && VERBOSE=1 make check;
 
    - tail -3 tests/ima_hash.log;
diff --git a/tests/install-gost-engine.sh b/tests/install-gost-engine.sh
new file mode 100755
index 000000000000..2563aa4953f7
--- /dev/null
+++ b/tests/install-gost-engine.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+openssl version
+
+git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git
+cd engine
+cmake .
+cmake --build .
+# note: install target is missing, later set the environment variable.
+cd ..
Mimi Zohar Aug. 4, 2020, 1:23 p.m. UTC | #22
Hi Petr, Vitaly,

On Tue, 2020-08-04 at 09:54 +0200, Petr Vorel wrote:
> Hi Mimi,
> 
> > ...
> > > I left off the list TPM 2.0 --pcr support, but the kernel code for
> > > exporting the sysfs TPM 2.0 pcrs hasn't been upstreamed yet.   I guess
> > > we should wait for that to be upstreamed or at least queued to be
> > > upstreamed.
> > OK, we have to wait. BTW is the patch somewhere on ML? Is it part of this
> > pathset https://patchwork.kernel.org/cover/11656949/ ?
> Oh, that's for ima_evm_utils. I meant patchset for kernel space.

"[PATCH v3 1/1] tpm: add sysfs exports for all banks of PCR registers"
was posted here on the linux-integrity mailing list[1].  It's important
to get this patch upstreamed, but I think the PCR file format is useful
on its own.  For this reason, I'm going to backtrack and include it in
1.3.1.

I've posted a new version of "travis: openssl gost engine" addressing
the branch version and lack of an install target.   It assumes that
openssl was built with engine support and builds the gost engine
support from the git repo.  The environment variable is set, but has
not been tested.

Everything, including this change, should now be in the next-testing
branch.

thanks,

Mimi

[1] message-id: 
20200722155739.26957-2-James.Bottomley@HansenPartnership.com
Vitaly Chikunov Aug. 4, 2020, 2:45 p.m. UTC | #23
Mimi,

On Tue, Aug 04, 2020 at 08:05:31AM -0400, Mimi Zohar wrote:
> The openssl version might not have gost openssl engine support.
> Download from source, rebuild and install local version.
> 
> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
>  .travis.yml                  | 10 ++++++++++
>  tests/install-gost-engine.sh | 10 ++++++++++
>  2 files changed, 20 insertions(+)
>  create mode 100755 tests/install-gost-engine.sh
> 
> diff --git a/.travis.yml b/.travis.yml
> index 11a827c02f0a..887f6bbea9b9 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -15,6 +15,13 @@ matrix:
>     include:
>       - env: TSS=ibmtss
>       - env: TSS=tpm2-tss
> +
> +before_install:
> +   - if [ "${SSL}" = "openssl" ]; then
> +        ./tests/install-gost-engine.sh;
> +        openssl version;
> +     fi
> +
>  install:
>     - if [ "${TSS}" = "tpm2-tss" ]; then
>             sudo apt-get install lcov pandoc autoconf-archive liburiparser-dev;
> @@ -30,6 +37,9 @@ install:
>  script:
>     - export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib;
>     - export PATH=$PATH:/usr/local/bin;
> +   - if [ "${SSL}" = "openssl" ]; then
> +        export OPENSSL_ENGINES="$OPENSSL_ENGINES:$PWD/engines/bin";

Should be `export OPENSSL_ENGINES=$PWD/engines/bin` since
OPENSSL_ENGINES is not PATH-like variable, but just a path to engines
dir.

Thanks,

> +     fi
>     - autoreconf -i && ./configure && make -j$(nproc) && sudo make install && VERBOSE=1 make check;
>  
>     - tail -3 tests/ima_hash.log;
> diff --git a/tests/install-gost-engine.sh b/tests/install-gost-engine.sh
> new file mode 100755
> index 000000000000..2563aa4953f7
> --- /dev/null
> +++ b/tests/install-gost-engine.sh
> @@ -0,0 +1,10 @@
> +#!/bin/sh
> +
> +openssl version
> +
> +git clone --branch openssl_1_1_0 https://github.com/gost-engine/engine.git
> +cd engine
> +cmake .
> +cmake --build .
> +# note: install target is missing, later set the environment variable.
> +cd ..
> -- 
> 2.18.4
>
Mimi Zohar Aug. 4, 2020, 6:11 p.m. UTC | #24
On Tue, 2020-08-04 at 17:45 +0300, Vitaly Chikunov wrote:
> Mimi,
> 
> On Tue, Aug 04, 2020 at 08:05:31AM -0400, Mimi Zohar wrote:
> > The openssl version might not have gost openssl engine support.
> > Download from source, rebuild and install local version.
> > 
> > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > ---
> >  .travis.yml                  | 10 ++++++++++
> >  tests/install-gost-engine.sh | 10 ++++++++++
> >  2 files changed, 20 insertions(+)
> >  create mode 100755 tests/install-gost-engine.sh
> > 
> > diff --git a/.travis.yml b/.travis.yml
> > index 11a827c02f0a..887f6bbea9b9 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -15,6 +15,13 @@ matrix:
> >     include:
> >       - env: TSS=ibmtss
> >       - env: TSS=tpm2-tss
> > +
> > +before_install:
> > +   - if [ "${SSL}" = "openssl" ]; then
> > +        ./tests/install-gost-engine.sh;
> > +        openssl version;
> > +     fi
> > +
> >  install:
> >     - if [ "${TSS}" = "tpm2-tss" ]; then
> >             sudo apt-get install lcov pandoc autoconf-archive liburiparser-dev;
> > @@ -30,6 +37,9 @@ install:
> >  script:
> >     - export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib;
> >     - export PATH=$PATH:/usr/local/bin;
> > +   - if [ "${SSL}" = "openssl" ]; then
> > +        export OPENSSL_ENGINES="$OPENSSL_ENGINES:$PWD/engines/bin";
> 
> Should be `export OPENSSL_ENGINES=$PWD/engines/bin` since
> OPENSSL_ENGINES is not PATH-like variable, but just a path to engines
> dir.

Done, thanks.  Assuming there is nothing else, I'll release v1.3.1
tomorrow.

thanks!

Mimi
Petr Vorel Aug. 5, 2020, 9:42 a.m. UTC | #25
Hi Mimi, Vitaly,

...
> "[PATCH v3 1/1] tpm: add sysfs exports for all banks of PCR registers"
> was posted here on the linux-integrity mailing list[1].  It's important
> to get this patch upstreamed, but I think the PCR file format is useful
> on its own.  For this reason, I'm going to backtrack and include it in
> 1.3.1.
Thanks a lot for info!

> I've posted a new version of "travis: openssl gost engine" addressing
> the branch version and lack of an install target.   It assumes that
> openssl was built with engine support and builds the gost engine
> support from the git repo.  The environment variable is set, but has
> not been tested.

> Everything, including this change, should now be in the next-testing
> branch.
Nice, thanks! Tested:
https://travis-ci.org/github/pevik/ima-evm-utils

I hope I'll have time for docker based travis patch next week.

Kind regards,
Petr

> [1] message-id: 
> 20200722155739.26957-2-James.Bottomley@HansenPartnership.com
Mimi Zohar Aug. 5, 2020, 1:31 p.m. UTC | #26
On Wed, 2020-08-05 at 11:42 +0200, Petr Vorel wrote:
> Hi Mimi, Vitaly,
> 
> ...
> > "[PATCH v3 1/1] tpm: add sysfs exports for all banks of PCR registers"
> > was posted here on the linux-integrity mailing list[1].  It's important
> > to get this patch upstreamed, but I think the PCR file format is useful
> > on its own.  For this reason, I'm going to backtrack and include it in
> > 1.3.1.
> Thanks a lot for info!
> 
> > I've posted a new version of "travis: openssl gost engine" addressing
> > the branch version and lack of an install target.   It assumes that
> > openssl was built with engine support and builds the gost engine
> > support from the git repo.  The environment variable is set, but has
> > not been tested.
> > Everything, including this change, should now be in the next-testing
> > branch.
> Nice, thanks! Tested:
> https://travis-ci.org/github/pevik/ima-evm-utils

From the log, I see I somehow re-introduced testing "${SSL}" =
"openssl".  I've removed it again and pushed out the update version.

> I hope I'll have time for docker based travis patch next week.

Thanks!

Mimi
Vitaly Chikunov Aug. 5, 2020, 4:18 p.m. UTC | #27
Petr,

On Wed, Aug 05, 2020 at 11:42:15AM +0200, Petr Vorel wrote:
> Hi Mimi, Vitaly,
> 
> ...
> > "[PATCH v3 1/1] tpm: add sysfs exports for all banks of PCR registers"
> > was posted here on the linux-integrity mailing list[1].  It's important
> > to get this patch upstreamed, but I think the PCR file format is useful
> > on its own.  For this reason, I'm going to backtrack and include it in
> > 1.3.1.
> Thanks a lot for info!
> 
> > I've posted a new version of "travis: openssl gost engine" addressing
> > the branch version and lack of an install target.   It assumes that
> > openssl was built with engine support and builds the gost engine
> > support from the git repo.  The environment variable is set, but has
> > not been tested.
> 
> > Everything, including this change, should now be in the next-testing
> > branch.
> Nice, thanks! Tested:
> https://travis-ci.org/github/pevik/ima-evm-utils

Probably not.

I still see there

  https://travis-ci.org/github/pevik/ima-evm-utils/jobs/715092182
  https://travis-ci.org/github/pevik/ima-evm-utils/jobs/715092183

SSL is not set and ./tests/install-gost-engine.sh is not run.
At the bottom we can see

  2077 $ tail -3 tests/ima_hash.log;
  2078 PASS: 14 SKIP: 4 FAIL: 0
  2082 $ tail -3 tests/sign_verify.log;
  2083 PASS: 81 SKIP: 10 FAIL: 0

This means that some tests aren't run. Probably, this is engine related
tests.

Thanks,

> 
> I hope I'll have time for docker based travis patch next week.
> 
> Kind regards,
> Petr
> 
> > [1] message-id: 
> > 20200722155739.26957-2-James.Bottomley@HansenPartnership.com
Vitaly Chikunov Aug. 5, 2020, 4:23 p.m. UTC | #28
Mimi,

On Wed, Aug 05, 2020 at 09:31:40AM -0400, Mimi Zohar wrote:
> On Wed, 2020-08-05 at 11:42 +0200, Petr Vorel wrote:
> > Hi Mimi, Vitaly,
> > 
> > ...
> > > "[PATCH v3 1/1] tpm: add sysfs exports for all banks of PCR registers"
> > > was posted here on the linux-integrity mailing list[1].  It's important
> > > to get this patch upstreamed, but I think the PCR file format is useful
> > > on its own.  For this reason, I'm going to backtrack and include it in
> > > 1.3.1.
> > Thanks a lot for info!
> > 
> > > I've posted a new version of "travis: openssl gost engine" addressing
> > > the branch version and lack of an install target.   It assumes that
> > > openssl was built with engine support and builds the gost engine
> > > support from the git repo.  The environment variable is set, but has
> > > not been tested.
> > > Everything, including this change, should now be in the next-testing
> > > branch.
> > Nice, thanks! Tested:
> > https://travis-ci.org/github/pevik/ima-evm-utils
> 
> >From the log, I see I somehow re-introduced testing "${SSL}" =
> "openssl".  I've removed it again and pushed out the update version.

Maybe I am fetching wrong, but it's still there.

origin is https://git.code.sf.net/p/linux-ima/ima-evm-utils

  $ git fetch origin
  $ git show -m origin/next-testing
  commit 76121b08b479f60a773653889070546002c2e826
  ...
  +before_install:
  +   - if [ "${SSL}" = "openssl" ]; then
  +        ./tests/install-gost-engine.sh;
  +        openssl version;
  +     fi

Thanks,


> 
> > I hope I'll have time for docker based travis patch next week.
> 
> Thanks!
> 
> Mimi
Petr Vorel Aug. 11, 2020, 5:33 p.m. UTC | #29
Hi Mimi, Vitaly,

> > Everything, including this change, should now be in the next-testing
> > branch.
> Nice, thanks! Tested:
> https://travis-ci.org/github/pevik/ima-evm-utils

> I hope I'll have time for docker based travis patch next week.

I prototype docker based Travis [1] (still WIP). It tests various distros,
including cross-compilation, using also clang, even one build with musl (Alpine
distro). But there are many failures.

The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
project is not packaged in distros, compiles only with gcc (no clang, I tested
versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
have git repository (the one on sourceforge is empty).
We could simply patch this file, but I'm not going to do it.
I guess I just skip tpm_server dependency for all non-native projects.
I also need always install gcc even clang is going to be used due tpm_server.

It also find bug in m4/manpage-docbook-xsl.m4 for Alpine, found custom xml
catalog, but value is not redirected into the variable.

Kind regards,
Petr

[1] https://travis-ci.org/github/pevik/ima-evm-utils/builds/716990585
[2] https://sourceforge.net/projects/ibmswtpm2/
Mimi Zohar Aug. 11, 2020, 10:04 p.m. UTC | #30
On Tue, 2020-08-11 at 19:33 +0200, Petr Vorel wrote:
> Hi Mimi, Vitaly,
> 
> > > Everything, including this change, should now be in the next-testing
> > > branch.
> > Nice, thanks! Tested:
> > https://travis-ci.org/github/pevik/ima-evm-utils
> > I hope I'll have time for docker based travis patch next week.
> 
> I prototype docker based Travis [1] (still WIP). It tests various distros,
> including cross-compilation, using also clang, even one build with musl (Alpine
> distro). But there are many failures.
> 
> The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
> project is not packaged in distros, compiles only with gcc (no clang, I tested
> versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
> have git repository (the one on sourceforge is empty).
> We could simply patch this file, but I'm not going to do it.
> I guess I just skip tpm_server dependency for all non-native projects.
> I also need always install gcc even clang is going to be used due tpm_server.

Agreed, getting docker/travis working is independent of tpm_server. 
Without a software TPM, the boot_aggregate test will be skipped.  For
now, until we can straighten this out,  I would modify "make check" to
run the other tests (e.g. make check TESTS="ima_hash.test
sign_verify.test").

thanks,

Mimi

> 
> It also find bug in m4/manpage-docbook-xsl.m4 for Alpine, found custom xml
> catalog, but value is not redirected into the variable.
> 
> Kind regards,
> Petr
> 
> [1] https://travis-ci.org/github/pevik/ima-evm-utils/builds/716990585
> [2] https://sourceforge.net/projects/ibmswtpm2/
>
Petr Vorel Aug. 12, 2020, 1:05 p.m. UTC | #31
Hi Mimi, Vitaly,

...
> > I prototype docker based Travis [1] (still WIP). It tests various distros,
> > including cross-compilation, using also clang, even one build with musl (Alpine
> > distro). But there are many failures.

> > The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
> > project is not packaged in distros, compiles only with gcc (no clang, I tested
> > versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
> > have git repository (the one on sourceforge is empty).
> > We could simply patch this file, but I'm not going to do it.
> > I guess I just skip tpm_server dependency for all non-native projects.
> > I also need always install gcc even clang is going to be used due tpm_server.

> Agreed, getting docker/travis working is independent of tpm_server. 
> Without a software TPM, the boot_aggregate test will be skipped.  For
> now, until we can straighten this out,  I would modify "make check" to
> run the other tests (e.g. make check TESTS="ima_hash.test
> sign_verify.test").
Yes, specifying tests to be tested is an option. But if skipping the compilation
for non-native builds works (e.g. tests which don't specify $VARIANT), I'd go
this way. That help us not having to remember to update tests for non-native
builds (once the new ones are added).

Gost: I just installed it for Debian / Ubuntu, which have a package. Not sure if
it's enough.

Any objections to distros used or anything else?
I'll have look on during this week and hopefully send v1 patchset.

> thanks,

> Mimi


> > It also find bug in m4/manpage-docbook-xsl.m4 for Alpine, found custom xml
> > catalog, but value is not redirected into the variable.
This is not a priority. I'll have look into this sometime in my non-work time
(Alpine doesn't have ima-evm-utils package).

Kind regards,
Petr

> > [1] https://travis-ci.org/github/pevik/ima-evm-utils/builds/716990585
> > [2] https://sourceforge.net/projects/ibmswtpm2/
Mimi Zohar Aug. 13, 2020, 6:15 p.m. UTC | #32
On Wed, 2020-08-12 at 15:05 +0200, Petr Vorel wrote:
> Hi Mimi, Vitaly,
> 
> ...
> > > I prototype docker based Travis [1] (still WIP). It tests various distros,
> > > including cross-compilation, using also clang, even one build with musl (Alpine
> > > distro). But there are many failures.
> > > The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
> > > project is not packaged in distros, compiles only with gcc (no clang, I tested
> > > versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
> > > have git repository (the one on sourceforge is empty).
> > > We could simply patch this file, but I'm not going to do it.
> > > I guess I just skip tpm_server dependency for all non-native projects.
> > > I also need always install gcc even clang is going to be used due tpm_server.
> > Agreed, getting docker/travis working is independent of tpm_server. 
> > Without a software TPM, the boot_aggregate test will be skipped.  For
> > now, until we can straighten this out,  I would modify "make check" to
> > run the other tests (e.g. make check TESTS="ima_hash.test
> > sign_verify.test").
> Yes, specifying tests to be tested is an option. But if skipping the compilation
> for non-native builds works (e.g. tests which don't specify $VARIANT), I'd go
> this way. That help us not having to remember to update tests for non-native
> builds (once the new ones are added).

Sure.  libtmps/swtpm could be installed in lieu of the ibmswtpm2. 
Sample directions for using it are here: 
https://github.com/stefanberger/swtpm/wiki/Using-the-IBM-TSS-with-swtpm
.

thanks,

Mimi
Petr Vorel Aug. 13, 2020, 6:28 p.m. UTC | #33
Hi Mimi, Vitaly,

...
> > > > The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
> > > > project is not packaged in distros, compiles only with gcc (no clang, I tested
> > > > versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
> > > > have git repository (the one on sourceforge is empty).
> > > > We could simply patch this file, but I'm not going to do it.
> > > > I guess I just skip tpm_server dependency for all non-native projects.
> > > > I also need always install gcc even clang is going to be used due tpm_server.
> > > Agreed, getting docker/travis working is independent of tpm_server. 
> > > Without a software TPM, the boot_aggregate test will be skipped.  For
> > > now, until we can straighten this out,  I would modify "make check" to
> > > run the other tests (e.g. make check TESTS="ima_hash.test
> > > sign_verify.test").
> > Yes, specifying tests to be tested is an option. But if skipping the compilation
> > for non-native builds works (e.g. tests which don't specify $VARIANT), I'd go
> > this way. That help us not having to remember to update tests for non-native
> > builds (once the new ones are added).

> Sure.  libtmps/swtpm could be installed in lieu of the ibmswtpm2. 
> Sample directions for using it are here: 
> https://github.com/stefanberger/swtpm/wiki/Using-the-IBM-TSS-with-swtpm

Nice!
I've just send a patch which builds green without this (ibmswtpm2 is installed
just for native gcc builds). I'd prefer to leave this for somebody else.

Kind regards,
Petr
Mimi Zohar Aug. 13, 2020, 8:11 p.m. UTC | #34
On Thu, 2020-08-13 at 20:28 +0200, Petr Vorel wrote:
> Hi Mimi, Vitaly,
> 
> ...
> > > > > The biggest problem is with ibmswtpm2 [2], which contain tpm_server binary. This
> > > > > project is not packaged in distros, compiles only with gcc (no clang, I tested
> > > > > versions 1332 and 1637) and ignore CFLAGS and LDFLAGS settings. It doesn't even
> > > > > have git repository (the one on sourceforge is empty).
> > > > > We could simply patch this file, but I'm not going to do it.
> > > > > I guess I just skip tpm_server dependency for all non-native projects.
> > > > > I also need always install gcc even clang is going to be used due tpm_server.
> > > > Agreed, getting docker/travis working is independent of tpm_server. 
> > > > Without a software TPM, the boot_aggregate test will be skipped.  For
> > > > now, until we can straighten this out,  I would modify "make check" to
> > > > run the other tests (e.g. make check TESTS="ima_hash.test
> > > > sign_verify.test").
> > > Yes, specifying tests to be tested is an option. But if skipping the compilation
> > > for non-native builds works (e.g. tests which don't specify $VARIANT), I'd go
> > > this way. That help us not having to remember to update tests for non-native
> > > builds (once the new ones are added).
> > Sure.  libtmps/swtpm could be installed in lieu of the ibmswtpm2. 
> > Sample directions for using it are here: 
> > https://github.com/stefanberger/swtpm/wiki/Using-the-IBM-TSS-with-swtpm
> 
> Nice!
> I've just send a patch which builds green without this (ibmswtpm2 is installed
> just for native gcc builds). I'd prefer to leave this for somebody else.

Wow, I saw the "green" button.  Thank you so much for spending so much
time on this.  Yes, of course we'll add the libtmps/swtpm support.

Mimi

Patch
diff mbox series

diff --git a/.travis.yml b/.travis.yml
index 11a827c02f0a..f5fb2c1da448 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,6 +15,13 @@  matrix:
    include:
      - env: TSS=ibmtss
      - env: TSS=tpm2-tss
+
+before_install:
+   - if [ "${SSL}" = "openssl" ]; then
+        ./tests/install-gost-engine.sh;
+        openssl version;
+     fi
+
 install:
    - if [ "${TSS}" = "tpm2-tss" ]; then
            sudo apt-get install lcov pandoc autoconf-archive liburiparser-dev;
diff --git a/tests/install-gost-engine.sh b/tests/install-gost-engine.sh
new file mode 100755
index 000000000000..01bcf2c3bc21
--- /dev/null
+++ b/tests/install-gost-engine.sh
@@ -0,0 +1,10 @@ 
+#!/bin/sh
+
+openssl version
+
+git clone https://github.com/gost-engine/engine.git
+cd engine
+#cmake -DOPENSSL_INCLUDE_DIR=/usr/local/include/openssl -DOPENSSL_SSL_LIBRARY=/usr/local/lib64/libss.so -DOPENSSL_CRYPTO_LIBRARY=/usr/local/lib64/libcrypto.so -DOPENSSL_ENGINES_DIR=/usr/local/lib64/engines-1.1 .
+cmake .
+sudo make install
+cd ..