Only the Visual Studio 2017 toolset is currently preinstalled on Travis.
Use this, instead of our solution's default which is VS 2010.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Travis now offers a Windows environment. Do a build with Visual
Studio. This brings diversity into the Travis CI which otherwise only
uses GCC and Clang.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Keep it simple and mostly non-parametrizable for now.
A path to Visual Studio 2017 is hard-coded.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Just do the default build with Clang and run the unit tests. The
objective is to have one build on a Unix-like platform other than
Linux.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a baremetal build to Travis, to catch inadvertent dependencies on
platform functions.
The exact choice of target platform doesn't matter for this purpose.
Pick one that's present in all.sh, that uses a compiler that's
available in the Travis build environment (Ubuntu 16.04), and that
happens to be close to the Debian "armel" distribution.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Call all.sh to run all the available test_depends_* components. This
adds a run of depends-hashes.pl and depends-pkgalgs.pl.
Keep invoking test-ref-configs.pl rather than via all.sh so that it
doesn't run with ASan. This saves some time and ASan there doesn't
turn up much more than in the full config.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some jobs don't actually test against GnuTLS, but all.sh checks its
presence in all test jobs, so it needs to be installed regardless.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For the one long job with ASan, use the full configuration.
We get more coverage this way, at the cost of a slightly longer
runtime which we can afford since the "enumerated configurations" job
is slower.
Add a default-configuration build to the "basic checks" job. This job
is fairly quick (no ASan, no SSL testing).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This way anything we change in all.sh, such as adding tests for
programs/*/*, will be reflected here.
The build now uses GCC instead of Clang, which doesn't make much
difference in practice. The build now enables ASan and UBSan.
The tests now run compat.sh and ssl-opt.sh fully.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Different releases have different sets of sanity checks. Keep the list
in one place, namely all.sh.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Declare an explicit Python version. Pick 3.5 which is the default
version on Ubuntu 16.04. This is necessary on Travis to have a working
pip for Python 3.
Install Pylint 2.4.4. There's nothing special about this version, it's
just the latest version.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split the build between:
* Basic checks
* A build in the default configuration with extensive tests
* Builds in other configurations with less testing
The intent is to have one shorter job with basic tests, and two longer
jobs that take roughly the same amount of time (split as evenly as
possible while keeping an easy-to-understand separation).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In practice, we hardly ever get different outcomes, so there is no
gain in running tests with different compilers.
Experimentally, with the builds and tests we currently do and with the
compiler versions on a Travis Ubuntu 16.04, gcc jobs are significantly
faster than clang jobs (13 min vs 24 min). So use gcc.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make it possible to use a compiler that isn't in $PATH, or that's
installed with a different name, or even a compiler for a different
target such as arm-linux-gnueabi.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Almost everything the selftest program does is in the test suites. But
just in case run the selftest program itself once in the full
configuration, and once in the default configuration with ASan, in
addition to running it out of box.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When parsing a certificate with the basic constraints extension
the max_pathlen that was read from it was incremented regardless
of its value. However, if the max_pathlen is equal to INT_MAX (which
is highly unlikely), an undefined behaviour would occur.
This commit adds a check to ensure that such value is not accepted
as valid. Relevant tests for INT_MAX and INT_MAX-1 are also introduced.
Certificates added in this commit were generated using the
test_suite_x509write, function test_x509_crt_check. Input data taken
from the "Certificate write check Server1 SHA1" test case, so the generated
files are like the "server1.crt", but with the "is_ca" field set to 1 and
max_pathlen as described by the file name.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Signed-off-by: Piotr Nowicki <piotr.nowicki@arm.com>
When building with MBEDTLS_MEMORY_DEBUG enabled, and running the ecdh part,
the benchmark program would start writing a very large number of space
characters on stdout, and would have to be killed because it never seemed to
terminate.
This was due to an integer overflow in computing how many space to leave after
the title in order to get memory measurements aligned, which resulted in up
to SIZE_MAX spaces being printed.
This commit just fixes the overflow, the next commit is going to fix the magic
number (12).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Don't mix Windows and Unix line endings, it's the worst of both worlds.
Update the Visual Studio templates and regenerate the generated files.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Check Windows files for some issues, including permissions. Omit the
checks related to special characters (whitespace, line endings,
encoding) as appropriate.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
To test a file name exactly, prepend a / to the base name.
files_to_check actually checks suffixes, not file names, so rename it
to extensions_to_check.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
