shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2024-12-22 17:35:55 +03:00
Code Issues Projects Releases Wiki Activity
8aaea0c65d
ostree/tests/test-remote-gpg-import.sh

340 lines
16 KiB
Bash
Raw Normal View History

tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
#!/bin/bash
#
# Copyright (C) 2015 Red Hat, Inc.
#
Add SPDX-License-Identifier to source files SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
2018-01-30 22:26:26 +03:00
# SPDX-License-Identifier: LGPL-2.0+
#
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
Update FSF license notices to use URL instead of address
2021-12-07 04:20:55 +03:00
# License along with this library. If not, see <https://www.gnu.org/licenses/>.
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
tests: Use "bash strict mode" I noticed in the static deltas tests, there were some tests that should have been under `-o pipefail` to ensure we properly propagate errors. There were a few places where we were referencing undefined variables. Overall, this is clearly a good idea IMO.
2016-01-27 19:44:10 +03:00
set -euo pipefail
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
. $(dirname $0)/libtest.sh
# We don't want OSTREE_GPG_HOME used for these tests.
unset OSTREE_GPG_HOME
tree-wide: Replace archive-z2 with archive In almost all places. There are just a few exceptions; one tricky bit for example is that the repo config must still have `mode=archive-z2`, since `archive` used to mean something else. (We could very likely just get rid of that check, but eh, later). I also added a test that one can still do `ostree repo init --mode=archive-z2`. Closes: #1125 Approved by: jlebon
2017-09-01 23:15:33 +03:00
setup_fake_remote_repo1 "archive"
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
tests/gpg: Add tests for importing updated remote GPG keys This checks whether gpg-import will properly update the keyring for a key that already exists. In particular, we check that changing the key expiration time or revoking it results in commit verification failure after re-importing the keys.
2019-06-21 14:59:56 +03:00
# Some tests require an appropriate gpg
num_non_gpg_tests=4
num_gpg_tests=2
num_tests=$((num_non_gpg_tests + num_gpg_tests))
echo "1..${num_tests}"
tests: Port to glib-tap.mk, make `make check` run all of the tests OSTree's code for testing predates the `glib-tap.mk` making its way into GLib. Let's switch to it, as it provides a number of advantages. By far the biggest advantage is that `make check` can start to run most of the tests *in addition* to having them work installed. This commit keeps the installed tests working, but `make check` turns out to be really broken because...our TAP usage has bitrotted to say the least. Fix that all up. Do some hacks so that the tests work uninstalled as well - in particular, `glib-tap.mk` and the bits encoded into `g_test_build_filename()` assume *recursive* Automake (blah). Work around that by creating a symlink when installed to loop back.
2016-03-02 18:28:04 +03:00
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
cd ${test_tmpdir}
mkdir repo
core: Fix default value of disable_xattrs Sigh. Rather awful regression from https://github.com/ostreedev/ostree/pull/759 Closes: #775 Approved by: jlebon
2017-04-04 03:35:58 +03:00
ostree_repo_init repo
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
#----------------------------------------------
# Test synchronicity of keyring file and remote
#----------------------------------------------
assert_not_has_file repo/R1.trustedkeys.gpg
${OSTREE} remote add R1 $(cat httpd-address)/ostree/gnomerepo
assert_not_has_file repo/R1.trustedkeys.gpg
# Import one valid key ID
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/gpghome/trusted/pubring.gpg R1 ${TEST_GPG_KEYID_1} | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 1 GPG key'
assert_has_file repo/R1.trustedkeys.gpg
${OSTREE} remote delete R1
assert_not_has_file repo/R1.trustedkeys.gpg
#---------------------------------------
# Test gpg-import with --keyring option
#---------------------------------------
${OSTREE} remote add R1 $(cat httpd-address)/ostree/gnomerepo
# Import one valid key ID
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/gpghome/trusted/pubring.gpg R1 ${TEST_GPG_KEYID_1} | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 1 GPG key'
# Import multiple valid key IDs
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/gpghome/trusted/pubring.gpg R1 ${TEST_GPG_KEYID_2} ${TEST_GPG_KEYID_3} | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 2 GPG key'
# Import key IDs we already have, make sure they're caught
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/gpghome/trusted/pubring.gpg R1 ${TEST_GPG_KEYID_1} ${TEST_GPG_KEYID_3} | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 0 GPG key'
${OSTREE} remote delete R1
${OSTREE} remote add R1 $(cat httpd-address)/ostree/gnomerepo
# Import all keys from keyring
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/gpghome/trusted/pubring.gpg R1 | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 3 GPG key'
${OSTREE} remote delete R1
#-------------------------------------
# Test gpg-import with --stdin option
#-------------------------------------
${OSTREE} remote add R1 $(cat httpd-address)/ostree/gnomerepo
# Import ASCII-armored keys thru stdin
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
cat ${test_tmpdir}/gpghome/key{1,2,3}.asc | ${OSTREE} remote gpg-import --stdin R1 | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 3 GPG key'
${OSTREE} remote delete R1
#------------------------------------------------------------
# Divide keys across multiple remotes, test GPG verification
# For testing purposes the remotes all point to the same URL
# This also tests "remote add" with --gpg-import.
#------------------------------------------------------------
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote add --gpg-import ${test_tmpdir}/gpghome/key1.asc R1 $(cat httpd-address)/ostree/gnomerepo | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 1 GPG key'
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote add --gpg-import ${test_tmpdir}/gpghome/key2.asc R2 $(cat httpd-address)/ostree/gnomerepo | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 1 GPG key'
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${OSTREE} remote add --gpg-import ${test_tmpdir}/gpghome/key3.asc R3 $(cat httpd-address)/ostree/gnomerepo | grep -o 'Imported [[:digit:]] GPG key' > result
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
assert_file_has_content result 'Imported 1 GPG key'
# Checkout the "remote" repo so we can add more commits
${CMD_PREFIX} ostree --repo=ostree-srv/gnomerepo checkout main workdir
# Sign a new commit with key1 and try pulling from each remote
echo shadow > workdir/blinky
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${CMD_PREFIX} ostree --repo=ostree-srv/gnomerepo commit -b main -s "Add blinky" --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome workdir
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
if ${OSTREE} pull R2:main >/dev/null 2>&1; then
assert_not_reached "(key1/R2) GPG verification unexpectedly succeeded"
fi
if ${OSTREE} pull R3:main >/dev/null 2>&1; then
assert_not_reached "(key1/R3) GPG verification unexpectedly succeeded"
fi
${OSTREE} pull R1:main >/dev/null
# Sign a new commit with key2 and try pulling from each remote
echo speedy > workdir/pinky
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${CMD_PREFIX} ostree --repo=ostree-srv/gnomerepo commit -b main -s "Add pinky" --gpg-sign ${TEST_GPG_KEYID_2} --gpg-homedir ${test_tmpdir}/gpghome workdir
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
if ${OSTREE} pull R1:main >/dev/null 2>&1; then
assert_not_reached "(key2/R1) GPG verification unexpectedly succeeded"
fi
if ${OSTREE} pull R3:main >/dev/null 2>&1; then
assert_not_reached "(key2/R3) GPG verification unexpectedly succeeded"
fi
${OSTREE} pull R2:main >/dev/null
# Sign a new commit with key3 and try pulling from each remote
echo bashful > workdir/inky
tests: Use temporary gpg homedir libtest always makes a copy of the gpghome directory to the test directory, so there's no need to operate on the installed copy. This allows test-remote-gpg-import to pass as an unprivileged user since it otherwise couldn't create the temp files gpgme creates.
2015-06-03 22:54:36 +03:00
${CMD_PREFIX} ostree --repo=ostree-srv/gnomerepo commit -b main -s "Add inky" --gpg-sign ${TEST_GPG_KEYID_3} --gpg-homedir ${test_tmpdir}/gpghome workdir
tests: Add test-remote-gpg-import.sh
2015-05-07 20:42:19 +03:00
if ${OSTREE} pull R1:main >/dev/null 2>&1; then
assert_not_reached "(key3/R1) GPG verification unexpectedly succeeded"
fi
if ${OSTREE} pull R2:main >/dev/null 2>&1; then
assert_not_reached "(key3/R2) GPG verification unexpectedly succeeded"
fi
${OSTREE} pull R3:main >/dev/null
tests: Port to glib-tap.mk, make `make check` run all of the tests OSTree's code for testing predates the `glib-tap.mk` making its way into GLib. Let's switch to it, as it provides a number of advantages. By far the biggest advantage is that `make check` can start to run most of the tests *in addition* to having them work installed. This commit keeps the installed tests working, but `make check` turns out to be really broken because...our TAP usage has bitrotted to say the least. Fix that all up. Do some hacks so that the tests work uninstalled as well - in particular, `glib-tap.mk` and the bits encoded into `g_test_build_filename()` assume *recursive* Automake (blah). Work around that by creating a symlink when installed to loop back.
2016-03-02 18:28:04 +03:00
echo "ok"
Add "gpgkeypath" option to remotes For Project Atomic, we already have RPM signatures which use files in `/etc/pki/rpm-gpg`. It's convenient to simply bind the OSTree remote configuration to those file paths, rather than having duplicate key data. This does mean that we need to parse the files for verification, so we end up importing them into the verifier's temporary keyring, which is a bit ugly, but it's what other projects do. Closes: https://github.com/ostreedev/ostree/issues/573 Closes: #575 Approved by: giuseppe
2016-11-16 17:13:54 +03:00
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
# Test the successful gpgkeypath option
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/key3.asc R4 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R4:main >/dev/null
lib/repo: Search a list of paths in gpgkeypath for gpg keys This allows specifying gpgpath as list of paths that can point to a file or a directory. If a directory path is given, paths to all regular files in the directory are added to the remote as gpg ascii keys. If the path is not a directory, the file is directly added (whether regular file, empty - errors will be reported later when verifying gpg keys e.g. when pulling). Adding the gpgkeypath property looks like: ostree --repo=repo remote add --set=gpgpath="/path/key1.asc,/path/keys.d" R1 https://example.com/some/remote/ostree/repo Closes #773 Closes: #1773 Approved by: cgwalters
2018-11-06 23:25:15 +03:00
# Test gpgkeypath success with multiple keys to try
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/key1.asc,${test_tmpdir}/gpghome/key2.asc,${test_tmpdir}/gpghome/key3.asc R7 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R7:main >/dev/null
# Test gpgkeypath failure with multiple keys but none in keyring
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/key1.asc,${test_tmpdir}/gpghome/key2.asc R8 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R8:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with different key"
fi
lib/gpg: Add more specific OstreeGpgError codes Currently `ostree_gpg_verify_result_require_valid_signature` always returns an error that the key used for the signature is missing from the keyring. However, all that's been determined is that there are no valid signatures. The error could also be from an expired signature, an expired key, a revoked key or an invalid signature. Provide values for these missing errors and return them from `ostree_gpg_verify_result_require_valid_signature`. The description of each result is appended to the error message, but since the result can contain more than one signature but only a single error can be returned, the status of the last signature is used for the error code. See the comment for rationale. Related: flatpak/flatpak#1450
2019-06-15 17:56:44 +03:00
assert_file_has_content err.txt "public key not found"
lib/repo: Search a list of paths in gpgkeypath for gpg keys This allows specifying gpgpath as list of paths that can point to a file or a directory. If a directory path is given, paths to all regular files in the directory are added to the remote as gpg ascii keys. If the path is not a directory, the file is directly added (whether regular file, empty - errors will be reported later when verifying gpg keys e.g. when pulling). Adding the gpgkeypath property looks like: ostree --repo=repo remote add --set=gpgpath="/path/key1.asc,/path/keys.d" R1 https://example.com/some/remote/ostree/repo Closes #773 Closes: #1773 Approved by: cgwalters
2018-11-06 23:25:15 +03:00
# Test gpgkeypath success with directory containing a valid key
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/ R9 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R9:main >/dev/null
# Test gpgkeypath failure with nonexistent directory
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/INVALIDKEYDIRPATH/ R10 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R10:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key directory"
fi
assert_file_has_content err.txt "INVALIDKEYDIRPATH.*No such file or directory"
# Test gpgkeypath failure with a directory containing a valid key, and a nonexistent key
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/,${test_tmpdir}/gpghome/INVALIDKEYPATH.asc R11 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R11:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key"
fi
assert_file_has_content err.txt "INVALIDKEYPATH.*No such file or directory"
# Test gpgkeypath success with a directory containing a valid key, and a key not in keyring
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/,${test_tmpdir}/gpghome/key1.asc R12 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R12:main >/dev/null
# Test gpgkeypath failure with a nonexistent directory, and a valid key
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/INVALIDKEYDIRPATH/,${test_tmpdir}/gpghome/key3.asc R13 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R13:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key directory"
fi
assert_file_has_content err.txt "INVALIDKEYDIRPATH.*No such file or directory"
# Test gpgkeypath failure with a nonexistent directory and a nonexistent key
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/INVALIDKEYDIRPATH/,${test_tmpdir}/gpghome/INVALIDKEYPATH.asc R14 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R14:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key"
fi
assert_file_has_content err.txt "INVALIDKEYDIRPATH.*No such file or directory"
# Test gpgkeypath success for no trailing slash in directory path
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome R15 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R15:main >/dev/null
# Test gpgkeypath failure with prefixed separator giving an empty path, and a nonexistent key
${OSTREE} remote add --set=gpgkeypath=,${test_tmpdir}/gpghome/INVALIDKEYPATH.asc R16 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R16:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key"
fi
assert_file_has_content err.txt "().*No such file or directory"
# Test gpgkeypath success with suffixed separator
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/key3.asc, R17 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R17:main >/dev/null
# Test gpgkeypath success with multiple keys specified, with semicolons
${OSTREE} remote add --set=gpgkeypath="${test_tmpdir}/gpghome/key1.asc;${test_tmpdir}/gpghome/key2.asc;${test_tmpdir}/gpghome/key3.asc" R18 $(cat httpd-address)/ostree/gnomerepo
${OSTREE} pull R18:main >/dev/null
# Test gpgkeypath failure multiple keys specified, with mix of commas and semicolons
${OSTREE} remote add --set=gpgkeypath="${test_tmpdir}/gpghome/key1.asc,${test_tmpdir}/gpghome/key2.asc;${test_tmpdir}/gpghome/key3.asc" R19 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R19:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with invalid gpgkeypath value"
fi
assert_file_has_content err.txt ".*key value list contains more than one separator"
Add "gpgkeypath" option to remotes For Project Atomic, we already have RPM signatures which use files in `/etc/pki/rpm-gpg`. It's convenient to simply bind the OSTree remote configuration to those file paths, rather than having duplicate key data. This does mean that we need to parse the files for verification, so we end up importing them into the verifier's temporary keyring, which is a bit ugly, but it's what other projects do. Closes: https://github.com/ostreedev/ostree/issues/573 Closes: #575 Approved by: giuseppe
2016-11-16 17:13:54 +03:00
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/INVALIDKEYPATH.asc R5 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R5:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with nonexistent key"
fi
assert_file_has_content err.txt "INVALIDKEYPATH.*No such file or directory"
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
${OSTREE} remote add --set=gpgkeypath=${test_tmpdir}/gpghome/key2.asc R6 $(cat httpd-address)/ostree/gnomerepo
if ${OSTREE} pull R6:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling with different key"
fi
lib/gpg: Add more specific OstreeGpgError codes Currently `ostree_gpg_verify_result_require_valid_signature` always returns an error that the key used for the signature is missing from the keyring. However, all that's been determined is that there are no valid signatures. The error could also be from an expired signature, an expired key, a revoked key or an invalid signature. Provide values for these missing errors and return them from `ostree_gpg_verify_result_require_valid_signature`. The description of each result is appended to the error message, but since the result can contain more than one signature but only a single error can be returned, the status of the last signature is used for the error code. See the comment for rationale. Related: flatpak/flatpak#1450
2019-06-15 17:56:44 +03:00
assert_file_has_content err.txt "public key not found"
Add "gpgkeypath" option to remotes For Project Atomic, we already have RPM signatures which use files in `/etc/pki/rpm-gpg`. It's convenient to simply bind the OSTree remote configuration to those file paths, rather than having duplicate key data. This does mean that we need to parse the files for verification, so we end up importing them into the verifier's temporary keyring, which is a bit ugly, but it's what other projects do. Closes: https://github.com/ostreedev/ostree/issues/573 Closes: #575 Approved by: giuseppe
2016-11-16 17:13:54 +03:00
echo "ok"
pull: Do GPG verify commit objects when using deltas The fact that we weren't doing this is at best an oversight, and for some deployment models a security vulnerability. Having both `gpg-verify` and `gpg-verify-summary` shows that we were intending them to be orthogonal/independent. Lately I've been advocating moving towards pinned TLS instead of gpg-signed summaries, and if we follow that path, performing GPG verification of commit objects even if using deltas is more important, as it provides an at-rest verifiable authenticity and integrity mechanism. Content providers which are signing their summary files and/or using TLS (particularly pinned TLS) for transport should treat this as a nice-to-have. However, for providers which are serving content over plain HTTP and relying on GPG, this is a critical update. Closes: https://github.com/ostreedev/ostree/issues/517 Closes: #589 Approved by: jlebon
2016-11-21 00:17:22 +03:00
# Test deltas with signed commits; this test is a bit
# weird here but this file has separate per-remote keys.
cd ${test_tmpdir}
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
echo $(date) > workdir/testfile-for-deltas-1
# Sign with keyid 1 for first commit
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo commit -b main --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome workdir
prevrev=$(${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo rev-parse main)
# Pull the previous revision
${OSTREE} pull R1:main
assert_streq $(${OSTREE} rev-parse R1:main) ${prevrev}
# Sign with keyid 2, but use remote r1
echo $(date) > workdir/testfile-for-deltas-2
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo commit -b main --gpg-sign ${TEST_GPG_KEYID_2} --gpg-homedir ${test_tmpdir}/gpghome workdir
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo static-delta generate main
# Summary is signed with key1
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo summary -u --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome
newrev=$(${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo rev-parse main)
if ${OSTREE} pull --require-static-deltas R1:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling commit signed with untrusted key"
fi
lib/gpg: Add more specific OstreeGpgError codes Currently `ostree_gpg_verify_result_require_valid_signature` always returns an error that the key used for the signature is missing from the keyring. However, all that's been determined is that there are no valid signatures. The error could also be from an expired signature, an expired key, a revoked key or an invalid signature. Provide values for these missing errors and return them from `ostree_gpg_verify_result_require_valid_signature`. The description of each result is appended to the error message, but since the result can contain more than one signature but only a single error can be returned, the status of the last signature is used for the error code. See the comment for rationale. Related: flatpak/flatpak#1450
2019-06-15 17:56:44 +03:00
assert_file_has_content err.txt "public key not found"
pull: Do GPG verify commit objects when using deltas The fact that we weren't doing this is at best an oversight, and for some deployment models a security vulnerability. Having both `gpg-verify` and `gpg-verify-summary` shows that we were intending them to be orthogonal/independent. Lately I've been advocating moving towards pinned TLS instead of gpg-signed summaries, and if we follow that path, performing GPG verification of commit objects even if using deltas is more important, as it provides an at-rest verifiable authenticity and integrity mechanism. Content providers which are signing their summary files and/or using TLS (particularly pinned TLS) for transport should treat this as a nice-to-have. However, for providers which are serving content over plain HTTP and relying on GPG, this is a critical update. Closes: https://github.com/ostreedev/ostree/issues/517 Closes: #589 Approved by: jlebon
2016-11-21 00:17:22 +03:00
echo "ok gpg untrusted signed commit for delta upgrades"
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo reset main{,^}
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo commit -b main --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome workdir
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo static-delta generate main
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo summary -u --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome
${OSTREE} pull --require-static-deltas R1:main
echo "ok gpg trusted signed commit for delta upgrades"
tests/gpg: Add tests for importing updated remote GPG keys This checks whether gpg-import will properly update the keyring for a key that already exists. In particular, we check that changing the key expiration time or revoking it results in commit verification failure after re-importing the keys.
2019-06-21 14:59:56 +03:00
# Run some more tests if an appropriate gpg is available
GPG=$(which_gpg)
if [ -z "${GPG}" ]; then
# Print a skip message per skipped test
for (( i = 0; i < num_gpg_tests; i++ )); do
echo "ok # SKIP this test requires gpg"
done
else
# Create a commit signed with keyid 1
echo $(date) > workdir/testfile-for-key-mangling
${CMD_PREFIX} ostree --repo=${test_tmpdir}/ostree-srv/gnomerepo commit -b main --gpg-sign ${TEST_GPG_KEYID_1} --gpg-homedir ${test_tmpdir}/gpghome workdir
# Re-add the remote
${OSTREE} remote delete R1
${OSTREE} remote add --gpg-import ${test_tmpdir}/gpghome/key1.asc R1 $(cat httpd-address)/ostree/gnomerepo | grep -o 'Imported [[:digit:]] GPG key' > result
assert_file_has_content result 'Imported 1 GPG key'
# Expire key 1, wait for it to be expired and import the expired key. Only
# new keys are reported.
${GPG} --homedir=${test_tmpdir}/gpghome --quick-set-expire ${TEST_GPG_KEYFPR_1} seconds=1
sleep 2
${GPG} --homedir=${test_tmpdir}/gpghome --armor --export ${TEST_GPG_KEYID_1} > ${test_tmpdir}/key1expired.asc
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/key1expired.asc R1 | grep -o 'Imported [[:digit:]] GPG key' > result
assert_file_has_content result 'Imported 0 GPG key'
# Pulling should fail since the key is expired
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
if ${OSTREE} pull R1:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling commit signed with expired key"
fi
assert_file_has_content err.txt "Key expired"
echo "ok imported expired key"
# Unexpire keyid 1 and revoke it. Revoking is done by importing the
# pre-generated revocation certificate.
${GPG} --homedir=${test_tmpdir}/gpghome --quick-set-expire ${TEST_GPG_KEYFPR_1} seconds=0
${GPG} --homedir=${TEST_GPG_KEYHOME} --import ${TEST_GPG_KEYHOME}/revocations/key1.rev
${GPG} --homedir=${test_tmpdir}/gpghome --armor --export ${TEST_GPG_KEYID_1} > ${test_tmpdir}/key1revoked.asc
${OSTREE} remote gpg-import --keyring ${test_tmpdir}/key1revoked.asc R1 | grep -o 'Imported [[:digit:]] GPG key' > result
assert_file_has_content result 'Imported 0 GPG key'
# Pulling should fail since the key is revoked
rm repo/refs/remotes/* -rf
${OSTREE} prune --refs-only
if ${OSTREE} pull R1:main 2>err.txt; then
assert_not_reached "Unexpectedly succeeded at pulling commit signed with revoked key"
fi
assert_file_has_content err.txt "Key revoked"
echo "ok imported revoked key"
fi
Reference in New Issue Copy Permalink