travis-ci: update pkcs11-helper to 1.22
PATCH 1/3 travis-ci: update pkcs11-helper to 1.22
use pkcs11-helper from https://github.com/OpenSC/pkcs11-helper/
to match build process used in windows installer build
--- .travis.yml | 2 +- .travis/build-deps.sh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
.travis.yml +1 -1
@@ -14,7 +14,7 @@ env: - PREFIX="${HOME}/opt" - TAP_WINDOWS_VERSION=9.21.2 - LZO_VERSION=2.10 - - PKCS11_HELPER_VERSION=1.11 + - PKCS11_HELPER_VERSION=1.22 - MBEDTLS_VERSION="2.4.0" - MBEDTLS_CFLAGS="-I${PREFIX}/include" - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto"
.travis/build-deps.sh +2 -2
@@ -35,7 +35,7 @@ build_lzo () { download_pkcs11_helper () { if [ ! -f "pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" ]; then wget -P download-cache/ \ - "http://downloads.sourceforge.net/project/opensc/pkcs11-helper/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" + "https://github.com/OpenSC/pkcs11-helper/releases/download/pkcs11-helper-${PKCS11_HELPER_VERSION}/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" fi }
@@ -46,7 +46,7 @@ build_pkcs11_helper () { cd "pkcs11-helper-${PKCS11_HELPER_VERSION}" ./configure --host=${CHOST} --program-prefix='' --libdir=${PREFIX}/lib \ - --prefix=${PREFIX} --build=x86_64-pc-linux-gnu --disable-crypto-engine-gnutls --disable-crypto-engine-nss + --prefix=${PREFIX} --build=x86_64-pc-linux-gnu --disable-crypto-engine-gnutls --disable-crypto-engine-nss --disable-crypto-engine-polarssl --disable-crypto-engine-mbedtls make all install ) echo "${PKCS11_HELPER_VERSION}" > "${PREFIX}/.pkcs11_helper-version"
Signature · 1 line
2.13.3
PATCH 2/3 travis-ci: update openssl to 1.0.2l, update mbedtls to 2.5.1
--- .travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
.travis.yml +2 -2
@@ -15,10 +15,10 @@ env: - TAP_WINDOWS_VERSION=9.21.2 - LZO_VERSION=2.10 - PKCS11_HELPER_VERSION=1.22 - - MBEDTLS_VERSION="2.4.0" + - MBEDTLS_VERSION="2.5.1" - MBEDTLS_CFLAGS="-I${PREFIX}/include" - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto" - - OPENSSL_VERSION="1.0.2k" + - OPENSSL_VERSION="1.0.2l" - OPENSSL_CFLAGS="-I${PREFIX}/include" - OPENSSL_LIBS="-L${PREFIX}/lib -lssl -lcrypto"
Signature · 1 line
2.13.3
Re: [Openvpn-devel] [PATCH 2/3] travis-ci: update openssl to 1.0.2l, update mbedtls to 2.5.1
Hi,
Quoted 12 lines · Ilya Shipitsin
--- .travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-).travis.yml +0
-0@@ -15,10 +15,10 @@ env: - TAP_WINDOWS_VERSION=9.21.2 - LZO_VERSION=2.10
.travis.yml env: · line 24
Quoted 10 lines
.travis.yml +2
-2- PKCS11_HELPER_VERSION=1.22 - - MBEDTLS_VERSION="2.4.0" + - MBEDTLS_VERSION="2.5.1" - MBEDTLS_CFLAGS="-I${PREFIX}/include" - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto" - - OPENSSL_VERSION="1.0.2k" + - OPENSSL_VERSION="1.0.2l" - OPENSSL_CFLAGS="-I${PREFIX}/include" - OPENSSL_LIBS="-L${PREFIX}/lib -lssl -lcrypto"
Bumping these versions every now and then makes sense. ACK.
-Steffan
Re: [Openvpn-devel] [PATCH applied] travis-ci: update openssl to 1.0.2l, update mbedtls to 2.5.1
In reply to Ilya Shipitsin-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Your patch has been applied to the following branches
commit 4a9306255cf0e1cc056e66ed4fa0f2e687c137f6 (master) commit 14f67c3c9091c4adf903c25eb88c0b281fa3b15f (release/2.4)
Author: Ilya Shipitsin Date: Mon Aug 7 18:23:00 2017 +0500
travis-ci: update openssl to 1.0.2l, update mbedtls to 2.5.1
Acked-by: Steffan Karger <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg15171.html
Signed-off-by: David Sommerseth <[email protected]...>- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJZjg+wAAoJEIbPlEyWcf3yrGwQAJwuwvNBwon3WAoMC7qxx8gm j/at9JNZKUaehhinZOOrmGYXeC6W/z/DxVYUjiALcNPHVabEex12C+Wo8ycOWVt8 nrEtOtrzrCHiHm69VRhhsiOvJlbJF0qfjboLeLq2YWEOtkYHL4TIMbU00DpbJKe+ a9r9LZe0Tv4UiMFIGeWgG+0xUtsARdhyJBhEmZ9XOYEexuqhDA8Fgc9/5oWf5K6S ajVV8AClaqYYhQFY2Zr9eZx1d7uDfVbKux6OvIyCnHT1HtTDdE9URHsboGwAOzy0 Vg2yOJz0gWflkUy0RXky/jmkBMBVquCBamsSrW4CM9nshIO+8wrFgJDWdmHf02hb qpLjIbLJbJixflaSBfUUP5AVpdGF55ViDGR53T6XmW9X24Sa0Xc5EC7KGo1o0Nvy 5lGAoAQjAQjaQah/zRQcdcoyklXjnojZracLQIzeOSsTPuQksPo2OTLw/Rxxv65K 0l+zIC0rDmQdBmvoArrzQ0nSX7bpfZPqXT7PKmwqZhOPvyBshjxx6SfdG42sTUMY 6+IRgPvIWYwu5dQ2IH1yrwrUl4Hg2yovhyvpsVmVdPc4s63m1DwIs+kwhj4qA319 GRdx6Eu6ro8S7hWWy+mtrFgmTUm1b4f2okbULnk/UB6L4JlvnzPUXc0wPRmZfiXq UshMOTMNvwU3QwhlIqW/
=P+7T
-----END PGP SIGNATURE-----
PATCH 3/3 add a test to "openvpn --help"
In reply to Ilya Shipitsininspired by https://www.mail-archive.com/[email protected]/msg13808.html
--- tests/Makefile.am | 2 +- tests/t_usage.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100755 tests/t_usage.sh
tests/Makefile.am +1 -1
@@ -14,7 +14,7 @@ MAINTAINERCLEANFILES = \ SUBDIRS = unit_tests -test_scripts = t_client.sh +test_scripts = t_client.sh t_usage.sh if ENABLE_CRYPTO test_scripts += t_lpback.sh t_cltsrv.sh endif
tests/t_usage.sh new file +29 -0
@@ -0,0 +1,29 @@ +#!/bin/sh +# +# run "openvpn --help" +# - check that openvpn did not crash +# +# prerequisites: +# - openvpn binary in current directory +# +# inspired by https://www.mail-archive.com/[email protected]/msg13808.html +# + +top_builddir="${top_builddir:-..}" + +if [ ! -x "${top_builddir}/src/openvpn/openvpn" ] +then + echo "no (executable) openvpn binary in current build tree. FAIL." >&2 + exit 1 +fi + +exit_code=0 + +"${top_builddir}/src/openvpn/openvpn" --help >/dev/null + +if [ $? -ne 1 ] +then + exit_code=1 +fi + +exit $exit_code
Signature · 1 line
2.13.3
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
Quoted 43 lines · Ilya Shipitsin
inspired by https://www.mail-archive.com/[email protected]/msg13808.html
--- tests/Makefile.am | 2 +- tests/t_usage.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100755 tests/t_usage.shtests/Makefile.am +1
-1@@ -14,7 +14,7 @@ MAINTAINERCLEANFILES = \ SUBDIRS = unit_tests -test_scripts = t_client.sh +test_scripts = t_client.sh t_usage.sh if ENABLE_CRYPTO test_scripts += t_lpback.sh t_cltsrv.sh endiftests/t_usage.sh new file +17
-0@@ -0,0 +1,29 @@ +#!/bin/sh +# +# run "openvpn --help" +# - check that openvpn did not crash +# +# prerequisites: +# - openvpn binary in current directory +# +# inspired by https://www.mail-archive.com/[email protected]/msg13808.html +# + +top_builddir="${top_builddir:-..}" + +if [ ! -x "${top_builddir}/src/openvpn/openvpn" ] +then + echo "no (executable) openvpn binary in current build tree. FAIL." >&2 + exit 1
tests/t_usage.sh line 27
Quoted 10 lines
tests/t_usage.sh new file +10
-0+fi + +exit_code=0 + +"${top_builddir}/src/openvpn/openvpn" --help >/dev/null + +if [ $? -ne 1 ] +then + exit_code=1 +fi
This check is odd. Where the --help option is parsed, it calls usage(), usage_small(). And those functions will always call:
openvpn_exit(OPENVPN_EXIT_STATUS_USAGE);
And OPENVPN_EXIT_STATUS_USAGE is defined as:
error.h:#define OPENVPN_EXIT_STATUS_USAGE 1
I would rather recommend you to grep for some information you expect to be listed in --help and check if that was found instead.
For example:
$ ./openvpn --help | grep -- ^-- | wc -l 238
As we might vary number of options from time to time, I wouldn't check against 238. But that it should be above 220 in the foreseeable future would not be an unreasonable assumption. *BUT* the number of options might differ more in some other builds (depending on --enable-*/--disable-* arguments given to ./configure).
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
7 авг. 2017 г. 20:34 пользователь "David Sommerseth" < [email protected]...> написал:
Quoted 1 line · Ilya Shipitsin
inspired by https://www.mail-archive.com/[email protected]...
sourceforge.net/msg13808.html
Quoted 25 lines
--- tests/Makefile.am | 2 +- tests/t_usage.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100755 tests/t_usage.shtests/Makefile.am +1
-1@@ -14,7 +14,7 @@ MAINTAINERCLEANFILES = \ SUBDIRS = unit_tests -test_scripts = t_client.sh +test_scripts = t_client.sh t_usage.sh if ENABLE_CRYPTO test_scripts += t_lpback.sh t_cltsrv.sh endiftests/t_usage.sh new file +0
-0
tests/t_usage.sh line 9
Quoted 9 lines
tests/t_usage.sh new file +9
-0@@ -0,0 +1,29 @@ +#!/bin/sh +# +# run "openvpn --help" +# - check that openvpn did not crash +# +# prerequisites: +# - openvpn binary in current directory +# +# inspired by https://www.mail-archive.com/[email protected]...
sourceforge.net/msg13808.html
Quoted 9 lines
tests/t_usage.sh new file +7
-0+# + +top_builddir="${top_builddir:-..}" + +if [ ! -x "${top_builddir}/src/openvpn/openvpn" ] +then + echo "no (executable) openvpn binary in current build tree. FAIL."&2
tests/t_usage.sh new file +1
-0+ exit 1
tests/t_usage.sh line 27
Quoted 10 lines
tests/t_usage.sh new file +10
-0+fi + +exit_code=0 + +"${top_builddir}/src/openvpn/openvpn" --help >/dev/null + +if [ $? -ne 1 ] +then + exit_code=1 +fi
This check is odd. Where the --help option is parsed, it calls usage(), usage_small(). And those functions will always call:
Sometimes it segfaults.
openvpn_exit(OPENVPN_EXIT_STATUS_USAGE);
And OPENVPN_EXIT_STATUS_USAGE is defined as:
error.h:#define OPENVPN_EXIT_STATUS_USAGE 1
I would rather recommend you to grep for some information you expect to be listed in --help and check if that was found instead.
I tried to implement it with cmocka. However, I gave up
For example:
$ ./openvpn --help | grep -- ^-- | wc -l 238
As we might vary number of options from time to time, I wouldn't check against 238. But that it should be above 220 in the foreseeable future would not be an unreasonable assumption. *BUT* the number of options might differ more in some other builds (depending on --enable-*/--disable-* arguments given to ./configure).
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
On 07/08/17 20:25, Илья Шипицин wrote:
[...]
Quoted 11 lines
tests/t_usage.sh line 27
Quoted 6 lines
+"${top_builddir}/src/openvpn/openvpn" --help >/dev/null
tests/t_usage.sh new file +5
-0+ +if [ $? -ne 1 ] +then + exit_code=1 +fiThis check is odd. Where the --help option is parsed, it calls
usage(),usage_small(). And those functions will always call:Sometimes it segfaults.
That's no real argument, see below.
Quoted 11 lines
openvpn_exit(OPENVPN_EXIT_STATUS_USAGE);And
OPENVPN_EXIT_STATUS_USAGEis defined as:error.h:#define
OPENVPN_EXIT_STATUS_USAGE1I would rather recommend you to grep for some information you expect to be listed in --help and check if that was found instead.
I tried to implement it with cmocka. However, I gave up
I didn't say this should be implemented in C and CMocka ... hence the example below. And that check below would implicitly account for SEGV scenarios as well.
Quoted 4 lines
For example:
$ ./openvpn --help | grep -- ^-- | wc -l
238But to do the spoon feeding:
optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E -- ^-- | wc -l)" if [ $outcount -lt 220 ];
then
exit_code=1
fi
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
2017-08-08 23:44 GMT+05:00 David Sommerseth <
[email protected]...>:
Quoted 9 lines · Илья Шипицин
[...]
Quoted 7 lines
Quoted 6 lines
+"${top_builddir}/src/openvpn/openvpn" --help >/dev/null
tests/t_usage.sh new file +5
-0+ +if [ $? -ne 1 ] +then + exit_code=1 +fi
Quoted 8 lines
Quoted 1 line
This check is odd. Where the --help option is parsed, it calls
usage(),Quoted 3 lines
usage_small(). And those functions will always call:Sometimes it segfaults.
That's no real argument, see below.
the one and only thing I wish to check here is whether functions reaches "exit 1" or crashes before.
Quoted 24 lines
Quoted 8 lines
openvpn_exit(OPENVPN_EXIT_STATUS_USAGE);And
OPENVPN_EXIT_STATUS_USAGEis defined as:error.h:#define
OPENVPN_EXIT_STATUS_USAGE1I would rather recommend you to grep for some information you expect
to
Quoted 4 lines
be listed in --help and check if that was found instead.
I tried to implement it with cmocka. However, I gave up
I didn't say this should be implemented in C and CMocka ... hence the example below. And that check below would implicitly account for SEGV scenarios as well.
Quoted 4 lines
For example: $ ./openvpn --help | grep -- ^-- | wc -l 238
Quoted 10 lines
But to do the spoon feeding:
optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E -- ^-- | wc -l)"
if [ $outcount -lt 220 ];
thenexit_code=1fi
if you suggest "that's a better check", please describe your idea. it is not clear for me why your approach is better
Quoted 9 lines
--
kind regards,David Sommerseth
OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
On 09/08/17 07:55, Илья Шипицин wrote:
[...]
Quoted 15 lines
Quoted 4 lines
For example: $ ./openvpn --help | grep -- ^-- | wc -l 238But to do the spoon feeding: optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E -- ^-- | wc -l)" if [ $outcount -lt 220 ]; then exit_code=1 fi
Quoted 2 lines
if you suggest "that's a better check", please describe your idea. it is not clear for me why your approach is better
The approach I suggest above covers:
a) The program is able to execute and usage() works
b) There is no unexpected bigger changes in usage(), the number of options are within a reasonable threshold. Granted, only minimum options is checked in the example above; extending with an upper limit is easy and quick (for example add '-o -gt 245')
c) If the program segfaults, optcount => 0 which ensures this test fails.
With your check only testing if the exit code is not 1, you only have an indication if the program segfaults or not. You don't know if usage() provides nothing but garbage and then exiting with 1. Checking that a certain amount of outputted lines starting with '--' gives an indication that usage() most likely have a reasonable output.
It would also be possible to build further on this check I suggest, to also check for mandatory options (--dev, --dev-type, --remote, --listen, --port, --proto, etc, etc). It is also possible to have a copy of the expected "openvpn --help | grep -E -- ^--" output and do a diff -
probably filter out some less important/deprecated options). While
these are a nice checks too, it is not as crucial as ensuring we have at least an reasonable expected amount of options.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
2017-08-09 14:31 GMT+05:00 David Sommerseth <
[email protected]...>:
Quoted 40 lines · Илья Шипицин
[...]
Quoted 15 lines
Quoted 4 lines
For example: $ ./openvpn --help | grep -- ^-- | wc -l 238But to do the spoon feeding: optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E -- ^-- | wc -l)" if [ $outcount -lt 220 ]; then exit_code=1 fiQuoted 2 lines
if you suggest "that's a better check", please describe your idea. it is not clear for me why your approach is better
The approach I suggest above covers:
a) The program is able to execute and
usage()worksb) There is no unexpected bigger changes in
usage(), the number of options are within a reasonable threshold. Granted, only minimum options is checked in the example above; extending with an upper limit is easy and quick (for example add '-o -gt 245')c) If the program segfaults, optcount => 0 which ensures this test fails.
With your check only testing if the exit code is not 1, you only have an indication if the program segfaults or not. You don't know if
usage()provides nothing but garbage and then exiting with 1. Checking that a certain amount of outputted lines starting with '--' gives an indication thatusage()most likely have a reasonable output.
Quoted 8 lines
It would also be possible to build further on this check I suggest, to also check for mandatory options (--dev, --dev-type, --remote, --listen, --port, --proto, etc, etc). It is also possible to have a copy of the expected "openvpn --help | grep -E -- ^--" output and do a diff -
probably filter out some less important/deprecated options). While
these are a nice checks too, it is not as crucial as ensuring we have at least an reasonable expected amount of options.
I'm afraid that that approach introduce implicit things (while my is pretty explicit).
Value seems questionable for me.
Quoted 10 lines
--
kind regards,David Sommerseth
OpenVPN Technologies, Inc
Re: [Openvpn-devel] [PATCH 3/3] add a test to "openvpn --help"
Quoted 56 lines · Илья Шипицин
2017-08-09 14:31 GMT+05:00 David Sommerseth
<[email protected]...
<mailto:[email protected]...>>:On 09/08/17 07:55, Илья Шипицин wrote:
[...]
> > For example:
> >
> > $ ./openvpn --help | grep -- ^-- | wc -l
> > 238
>
> But to do the spoon feeding:
>
> optcount="$(${top_builddir}/src/openvpn/openvpn --help | grep -E --
> ^-- | wc -l)"
> if [ $outcount -lt 220 ];
> then
> exit_code=1
> fi
>
>
> if you suggest "that's a better check", please describe your idea. > it is not clear for me why your approach is betterThe approach I suggest above covers:
a) The program is able to execute and
usage()worksb) There is no unexpected bigger changes in
usage(), the number of options are within a reasonable threshold. Granted, only minimum options is checked in the example above; extending with an upper limit is easy and quick (for example add '-o -gt 245')c) If the program segfaults, optcount => 0 which ensures this test fails.
With your check only testing if the exit code is not 1, you only have an indication if the program segfaults or not. You don't know if
usage()provides nothing but garbage and then exiting with 1. Checking that a certain amount of outputted lines starting with '--' gives an indication thatusage()most likely have a reasonable output.It would also be possible to build further on this check I suggest, to also check for mandatory options (--dev, --dev-type, --remote, --listen, --port, --proto, etc, etc). It is also possible to have a copy of the expected "openvpn --help | grep -E -- ^--" output and do a diff -
probably filter out some less important/deprecated options). While
these are a nice checks too, it is not as crucial as ensuring we have at least an reasonable expected amount of options.
Quoted 3 lines
I'm afraid that that approach introduce implicit things (while my is pretty explicit).
Value seems questionable for me.
Well, then I'm just giving this patch a NAK, to be explicit.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Hi,
Quoted 34 lines · Ilya Shipitsin
use pkcs11-helper from https://github.com/OpenSC/pkcs11-helper/
to match build process used in windows installer build--- .travis.yml | 2 +- .travis/build-deps.sh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-).travis.yml +1
-1@@ -14,7 +14,7 @@ env: - PREFIX="${HOME}/opt" - TAP_WINDOWS_VERSION=9.21.2 - LZO_VERSION=2.10 - - PKCS11_HELPER_VERSION=1.11 + - PKCS11_HELPER_VERSION=1.22 - MBEDTLS_VERSION="2.4.0" - MBEDTLS_CFLAGS="-I${PREFIX}/include" - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto".travis/build-deps.sh +1
-1@@ -35,7 +35,7 @@ build_lzo () { download_pkcs11_helper () { if [ ! -f "pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" ]; then wget -P download-cache/ \ - "http://downloads.sourceforge.net/project/opensc/pkcs11-helper/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" + "https://github.com/OpenSC/pkcs11-helper/releases/download/pkcs11-helper-${PKCS11_HELPER_VERSION}/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2" fi }
.travis/build-deps.sh build_pkcs11_helper () { · line 49
Quoted 5 lines
.travis/build-deps.sh +1
-1@@ -46,7 +46,7 @@ build_pkcs11_helper () { cd "pkcs11-helper-${PKCS11_HELPER_VERSION}" ./configure --host=${CHOST} --program-prefix='' --libdir=${PREFIX}/lib \ - --prefix=${PREFIX} --build=x86_64-pc-linux-gnu --disable-crypto-engine-gnutls --disable-crypto-engine-nss + --prefix=${PREFIX} --build=x86_64-pc-linux-gnu --disable-crypto-engine-gnutls --disable-crypto-engine-nss --disable-crypto-engine-polarssl --disable-crypto-engine-mbedtls
This line is getting really long. Let's break this up into 80-char lines again. Other than that, change looks good to me. So, please send a v2 with this line broken up, and then I think we're good to go.
-Steffan