I have an application that was built with go 1.16.4, which uses (imports) the archive/zip component of the Go std lib. I took a look at the golang Release Notes and see that a security vulnerability has been fixed in archive/zip in golang 1.16.5. How do I ensure that my application is no longer vulnerable? Must I upgrade my version of go itself, and then rebuild with that new version of go? Or could I vendor the newer version of the fixed component then rebuild? Must the files in the build machine's $GOROOT be updated?
Must I upgrade my version of go itself, and then rebuild with that new version of go?
Yes...
Upgrade Go.
Rebuild.
Or could I vendor the newer version of the fixed component then rebuild?
No, you can't vendor the Go standard library.
Must the files in the build machine's $GOROOT be updated?
GOROOT is the root folder of the Go SDK installation. It is updated when you upgrade Go on the machine (or container) that invokes go build/go install.
Related
I'm new using App Engine, and I would appreciate if someone can clarify this doubt:
How can I be sure that AppEngine in the cloud have the correct version of go I need to have in the cloud?
I have read some articles about installing and downloading the SDK for google on my local machine (and of course, I am able to install the version I need on my machine); but once I have generated my app in Go and I want to deploy it to App Engine in the cloud, how can I be sure Google infrastructure has the correct version?
I want to install Iris Web framework as part of the stack but it requires to go vers 1.14 or superior, Google App Engine standard only provides support for Google 1.11 and 1.12+ so I think I would need to go for the Google App Engine Flexible option, if that were the case, how can I be sure it has or support the Go version I need?... Or Is there some procedure to follow to install it ?
Thanks in advance for your support
You can use the standard environment. The documentation for the standard environment says:
The Go 1.12+ runtime supports the following major versions: Go 1.12, Go 1.13, Go 1.14, Go 1.15, and Go 1.16. Your app uses the latest stable release of the version that is specified in your app.yaml file. App Engine automatically updates to new patch revisions, but will not automatically update the major version.
Here's an example version spec in app.yaml:
runtime: go115
With the Flexible environment you have the ability to pin a version rather than using the latest available/supported. In order to do that, you will have to specify in your app.yaml file the exact version you would like it to be:
runtime: go1.14
If you specify only runtime: go it will pull the latest release available for Go language (which seems to be 1.19).
For more information, please refer to this documentation: https://cloud.google.com/appengine/docs/flexible/go/reference/app-yaml#general
Hi I want to pin a particular version of dependency in my go.mod, like
github.com/dependecy v1.7.0
And when I run go test or go build, sometimes it gets updated to
github.com/dependecy v1.8.0
The tricky part is sometimes it changes, and sometimes it does not. We would want to pin to an older version because the new version has a bug. Any idea why this is happening?
I believe the reason why this is happening is because you might have a dependency that might have requirement for higher version of the module. From go documentation here
If multiple versions of a particular module are added to the list, then at the end only the latest version (according to semantic version ordering) is kept for use in the build.
You can try the commands listed in documentation or, run go build with -mod=readonly flag. That should help you understand what might be triggering this.
Go modules does not support multiple minor versions of same package in a single module, if added then at the end only the latest version is kept for use in the build.
You can have some dependency which have requirement of higher version and replacing the old one.
If a module out there pushed v1.8.0 with a bug, file a bug or fork the repository as needed.
Is it ok to use the master branch of lib/pq in production?
When you execute go get gitlab.com/lib/pq you get the master branch, but there is a release v1.0.0.
Would it be better to use releases instead of master branch?
lib/pq
Releases
v1.0.0
Initial tagged release. No major recent changes.
Merge pull request #778 from lib/go-mod
add a go.mod file in preparation for a tagged release
lib/pq v1.0.0 adds support for Go versioned modules.
For Go1.12, consider upgrading your production code for Go versioned modules.
The first beta release of Go 1.12 is scheduled for this week (Dec, 3, 2018).
Go 1.11 Release Notes
Modules, package versioning, and dependency management
Go 1.11 adds preliminary support for a new concept called “modules,”
an alternative to GOPATH with integrated support for versioning and
package distribution. Using modules, developers are no longer confined
to working inside GOPATH, version dependency information is explicit
yet lightweight, and builds are more reliable and reproducible.
Module support is considered experimental. Details are likely to
change in response to feedback from Go 1.11 users, and we have more
tools planned. Although the details of module support may change,
projects that convert to modules using Go 1.11 will continue to work
with Go 1.12 and later. If you encounter bugs using modules, please
file issues so we can fix them. For more information, see the go
command documentation.
Proposal: Versioned Go Modules
Go 1.11 Modules.
I am hitting this error while i try to compile GO code
[root#scsor0014444001 Netapp]# go build -o terraform-provider-xxxx
# github.com/hashicorp/terraform/config
../go/src/github.com/hashicorp/terraform/config/testing.go:9: t.Helper undefined (type *testing.T has no field or method Helper)
[root#scsor0014444001 Netapp]# go version
go version go1.8.3 linux/amd64
Can someone help me in understanding whats wrong here ?
Thanks in advance!
As of the 0.10.3 release, Terraform core now requires Go 1.9 due to the use of the new "test helper" feature.
Since providers depend on some packages from the core system as libraries, this dependency is unfortunately then inherited by the providers too. If you're using vendoring to make Terraform core available to the provider (recommended!) then you can potentially wind back the vendored version to the final commit before this change in order to build with 1.8, though over time this strategy will of course cause the vendored package to fall behind the latest changes.
Upgrading Go to 1.9 should address this in a more permanent way.
I've read a whole bunch of articles and SO questions on importing 3rd party go packages which all seems straight forward, but what I don't understand is that none that I have read make any references to versioning. In Dartlang there's the pubspec file that defines your package including its version and its dependencies including their required versions. What if I do a go get github.com/gorilla/sessions and write my app then 6 months later I have to clear my directories and re get everything again, in which time that package has been update and broken backwards compatibility with my code that was using the older version?
The official version, from the GO FAQ:
If you're using an externally supplied package and worry that it might change in unexpected ways, the simplest solution is to copy it to your local repository. (This is the approach Google takes internally.) Store the copy under a new import path that identifies it as a local copy.
There are many alternative to that approach, mainly based on declaring the exact version of those projects you are using.
See for instance "Dead Simple Dependencies in Go -- Keep it simple and keep your sanity." (based on emil2k/vend)
The main different options for Go Dependency Management are listed at:
"Go Package Management -- A summary of dependency management in Go"
(And its associate GOPM mailing list)
Update July 2015:
the official vendoring approach from Go team is discussed here.
an alternative go build tool called "gb" is proposed at getgb.io by Dave Cheney.
Update Q4 2017: as mentioned below, go dep is the official tool for pinning version of dependencies (even though that pinning approach is not without criticism: see "The cargo cult of versioning").
It should be merged into the toolchain when Go 1.10 development begins, according to its roadmap.
Update Q2 2018: go dep has been replaced by go mod (modules) in Go 1.11, following works on vgo.
I use dep as a dependency management tool for golang project. Please use the following link dep tool for more info.
dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile.
dep was the "official experiment." The Go toolchain, as of 1.11, has (experimentally) adopted an approach that sharply diverges from dep. As a result, we are continuing development of dep, but gearing work primarily towards the development of an alternative prototype for versioning behavior in the toolchain.
Current status: January 2019
dep is safe for production use.