summaryrefslogtreecommitdiff
path: root/share
diff options
context:
space:
mode:
authorVanessasaurus <814322+vsoch@users.noreply.github.com>2021-09-02 00:46:27 -0600
committerGitHub <noreply@github.com>2021-09-02 08:46:27 +0200
commit8e61f542601083f363c5910a5ed74c8dae44e69d (patch)
tree0ffcb59cec1bd70e90403b793cb2f98e333e8579 /share
parent8a7af82a82fb80b660a08ab54e8d8402d7ca27b5 (diff)
downloadspack-8e61f542601083f363c5910a5ed74c8dae44e69d.tar.gz
spack-8e61f542601083f363c5910a5ed74c8dae44e69d.tar.bz2
spack-8e61f542601083f363c5910a5ed74c8dae44e69d.tar.xz
spack-8e61f542601083f363c5910a5ed74c8dae44e69d.zip
start of work to add spack audit packages-https checker (#25670)
This PR will add a new audit, specifically for spack package homepage urls (and eventually other kinds I suspect) to see if there is an http address that can be changed to https. Usage is as follows: ```bash $ spack audit packages-https <package> ``` And in list view: ```bash $ spack audit list generic: Generic checks relying on global variables configs: Sanity checks on compilers.yaml Sanity checks on packages.yaml packages: Sanity checks on specs used in directives packages-https: Sanity checks on https checks of package urls, etc. ``` I think it would be unwise to include with packages, because when run for all, since we do requests it takes a long time. I also like the idea of more well scoped checks - likely there will be other addresses for http/https within a package that we eventually check. For now, there are two error cases - one is when an https url is tried but there is some SSL error (or other error that means we cannot update to https): ```bash $ spack audit packages-https zoltan PKG-HTTPS-DIRECTIVES: 1 issue found 1. Error with attempting https for "zoltan": <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'www.cs.sandia.gov'. (_ssl.c:1125)> ``` This is either not fixable, or could be fixed with a change to the url or (better) contacting the site owners to ask about some certificate or similar. The second case is when there is an http that needs to be https, which is a huge issue now, but hopefully not after this spack PR. ```bash $ spack audit packages-https xman Package "xman" uses http but has a valid https endpoint. ``` And then when a package is fixed: ```bash $ spack audit packages-https zlib PKG-HTTPS-DIRECTIVES: 0 issues found. ``` And that's mostly it. :) Signed-off-by: vsoch <vsoch@users.noreply.github.com> Co-authored-by: vsoch <vsoch@users.noreply.github.com>
Diffstat (limited to 'share')
-rwxr-xr-xshare/spack/spack-completion.bash11
1 files changed, 10 insertions, 1 deletions
diff --git a/share/spack/spack-completion.bash b/share/spack/spack-completion.bash
index ef15f38c6b..436ff345e7 100755
--- a/share/spack/spack-completion.bash
+++ b/share/spack/spack-completion.bash
@@ -386,7 +386,7 @@ _spack_audit() {
then
SPACK_COMPREPLY="-h --help"
else
- SPACK_COMPREPLY="configs packages list"
+ SPACK_COMPREPLY="configs packages-https packages list"
fi
}
@@ -394,6 +394,15 @@ _spack_audit_configs() {
SPACK_COMPREPLY="-h --help"
}
+_spack_audit_packages_https() {
+ if $list_options
+ then
+ SPACK_COMPREPLY="-h --help --all"
+ else
+ SPACK_COMPREPLY=""
+ fi
+}
+
_spack_audit_packages() {
if $list_options
then