kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity
moby--moby/hack/vendor.sh

15 lines
391 B
Bash
Raw Normal View History

Convert script shebangs from "#!/bin/bash" to "#!/usr/bin/env bash" This is especially important for distributions like NixOS where `/bin/bash` doesn't exist, or for MacOS users who've installed a newer version of Bash than the one that comes with their OS. Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
2017-02-13 14:01:54 -05:00
#!/usr/bin/env bash
move deps installation to vendor.sh script
2013-08-26 18:51:22 -04:00
vendor: replace vndr with `go mod vendor` - use `vendor.mod` instead of `go.mod` to avoid issues to do with use of CalVer, not SemVer - ensure most of the dependency versions do not change - only zookeeper client has to change (via docker/libkv#218) as previously used version is no longer maintained and has missing dependencies Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-12-15 14:35:04 -05:00
# This file is just wrapper around 'go mod vendor' tool.
# For updating dependencies you should change `vendor.mod` file in root of the
# project.
Allow granular vendoring hack/vendor.sh can now accept command line arguments `./hack/vendor.sh github.com/docker/engine-api` will revendor only the engine-api dependency. `./hack/vendor.sh github.com/docker/engine-api v0.3.3` will vendor only engine-api at the specified tag/commit. `./hack/vendor.sh git github.com/docker/engine-api v0.3.3` is the same but specifies the VCS for cases where the VCS is something else than git `./hack/vendor.sh git golang.org/x/sys eb2c74142fd19a79b3f237334c7384d5167b1b46 https://github.com/golang/sys.git` will vendor only golang.org/x/sys downloading from the specified URL Signed-off-by: Tibor Vass <tibor@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-19 09:35:06 -04:00
project: use vndr for vendoring Signed-off-by: Alexander Morozov <lk4d4@docker.com>
2016-10-31 14:22:28 -04:00
set -e
vendor: replace vndr with `go mod vendor` - use `vendor.mod` instead of `go.mod` to avoid issues to do with use of CalVer, not SemVer - ensure most of the dependency versions do not change - only zookeeper client has to change (via docker/libkv#218) as previously used version is no longer maintained and has missing dependencies Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-12-15 14:35:04 -05:00
set -x
add gosqlite to vendor.sh Add gosqlite and its latest revision to vendor.sh so that the vendor directory can be reliably recreated.
2013-12-19 12:01:55 -05:00
vendor: replace vndr with `go mod vendor` - use `vendor.mod` instead of `go.mod` to avoid issues to do with use of CalVer, not SemVer - ensure most of the dependency versions do not change - only zookeeper client has to change (via docker/libkv#218) as previously used version is no longer maintained and has missing dependencies Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-12-15 14:35:04 -05:00
SCRIPTDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
hack/vendor.sh: run "go mod tidy" before vendoring The hack/vendor.sh script is used to (re)vendor dependencies. However, it did not run `go mod tidy` before doing so, wheras the vendor _validation_ script did. This could result in vendor validation failing if go mod tidy resulted in changes (which could be in `vendor.sum`). In "usual" situations, this could be easily done by the user (`go mod tidy` before running `go mod vendor`), but due to our (curent) uses of `vendor.mod`, and having to first set up a (dummy) `go.mod`, this is more complicated. Instead, just make the script do this, so that `hack/vendor.sh` will always produce the expected result. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-02-05 05:25:23 -05:00
"${SCRIPTDIR}"/go-mod-prepare.sh
vendor: replace vndr with `go mod vendor` - use `vendor.mod` instead of `go.mod` to avoid issues to do with use of CalVer, not SemVer - ensure most of the dependency versions do not change - only zookeeper client has to change (via docker/libkv#218) as previously used version is no longer maintained and has missing dependencies Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2021-12-15 14:35:04 -05:00
chore: update supported go version to 1.18+ The 1.16 `io/fs` compatibility code was being built on 1.18 and 1.19. Drop it completely as 1.16 is long EOL, and additionally drop 1.17 as it has been EOL for a month and 1.18 is both the minimum Go supported by the 20.10 branch, as well as a very easy jump from 1.17. Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
2022-09-15 12:19:19 -04:00
GO111MODULE=auto go mod tidy -modfile 'vendor.mod' -compat 1.18
Remove local fork of archive/tar package A copy of Go's archive/tar packge was vendored with a patch applied to mitigate CVE-2019-14271. Vendoring standard library packages is not supported by Go in module-aware mode, which is getting in the way of maintenance. A different approach to mitigate the vulnerability is needed which does not involve vendoring parts of the standard library. glibc implements name service lookups such as users, groups and DNS using a scheme known as Name Service Switch. The services are implemented as modules, shared libraries which glibc dynamically links into the process the first time a function requiring the module is called. This is the crux of the vulnerability: if a process linked against glibc chroots, then calls one of the functions implemented with NSS for the first time, glibc may load NSS modules out of the chrooted filesystem. The API underlying the `docker cp` command is implemented by forking a new process which chroots into the container's rootfs and writes a tar stream of files from the container over standard output. It utilizes the Go standard library's archive/tar package to write the tar stream. It makes use of the tar.FileInfoHeader function to construct a tar.Header value from an fs.FileInfo value. In modern versions of Go on *nix platforms, FileInfoHeader will attempt to resolve the file's UID and GID to their respective user and group names by calling the os/user functions LookupId and LookupGroupId. The cgo implementation of os/user on *nix performs lookups by calling the corresponding libc functions. So when linked against glibc, calls to tar.FileInfoHeader after the process has chrooted into the container's rootfs can have the side effect of loading NSS modules from the container! Without any mitigations, a malicious container image author can trivially get arbitrary code execution by leveraging this vulnerability and escape the chroot (which is not a sandbox) into the host. Mitigate the vulnerability without patching or forking archive/tar by hiding the OS-dependent file info from tar.FileInfoHeader which it needs to perform the lookups. Without that information available it falls back to populating the tar.Header with only the information obtainable directly from the FileInfo value without making any calls into os/user. Fixes #42402 Signed-off-by: Cory Snider <csnider@mirantis.com>
2022-01-24 15:33:54 -05:00
GO111MODULE=auto go mod vendor -modfile vendor.mod
Copy permalink