sdboyer

package gps

import (
	"context"
	"sync/atomic"
)

func (sm *SourceMgr) ListPackages(ctx context.Context, id ProjectIdentifier, v Version) (PackageTree, error) {
	subctx, cancel := context.WithCancel(ctx)
	quitchan := make(chan struct{})

sdboyer

package gps

import (
	"context"
	"errors"
	"fmt"
	"net/url"
	"sync"

	radix "github.com/armon/go-radix"

sdboyer

func TestFoo(t *testing.T) {
	higherLevelCheck(t, someArgs{something})
	higherLevelCheck(t, someArgs{somethingElse})
}

func higherLevelCheck(t *testing.T, someArgs Args) {
	r, err := doSomething(someArgs)
	t.HelperAt("first err nil check")
	assert(t, err, nil)
	t.HelperAt("first value match check")

sdboyer

~/ws/go/src/github.com/Masterminds/semver 2.x* ⇣
❯ go test -bench=. -benchmem

BenchmarkNewConstraintUnary-8                   	  300000	      4101 ns/op	    1088 B/op	      10 allocs/op
BenchmarkNewConstraintTilde-8                   	  300000	      5190 ns/op	    1200 B/op	      10 allocs/op
BenchmarkNewConstraintCaret-8                   	  300000	      5158 ns/op	    1200 B/op	      10 allocs/op
BenchmarkNewConstraintWildcard-8                	  300000	      4196 ns/op	    1237 B/op	      13 allocs/op
BenchmarkNewConstraintRange-8                   	  200000	     11089 ns/op	    2374 B/op	      20 allocs/op
BenchmarkNewConstraintUnion-8                   	  100000	     12984 ns/op	    3184 B/op	      31 allocs/op
BenchmarkValidateVersionUnary-8                 	50000000	        32.8 ns/op	       0 B/op	       0 allocs/op

sdboyer

call plug#begin('~/.vim/plugged')
Plug 'fatih/vim-go'
" Group dependencies, vim-snippets depends on ultisnips
Plug 'SirVer/ultisnips' | Plug 'honza/vim-snippets'
Plug 'rdnetto/YCM-Generator', { 'branch': 'stable' }
Plug 'nsf/gocode', { 'rtp': 'vim', 'do': '~/.vim/plugged/gocode/vim/symlink.sh' }
Plug 'tpope/vim-sensible'
Plug 'tpope/vim-surround'
Plug 'tpope/vim-fugitive'
Plug 'tpope/vim-markdown'

sdboyer

When the manifest file of my project/the root project, call it A, contains a dep/constraint statement for another project, say X, that doesn't appear in A's import statements, there are three modes in which tools can interpret that:

1. X must be present in the result (A's lock+vendor), and it must meet the version constraint.
   • (There's a variant where it works like this when it’s the root manifest giving the dep on X, but if it’s a non-root manifest, things work like 2)
2. X needn't be present in the result, and even if it is, it needn't meet the constraint. (Basically, the constraint is cruft and we ignore it)
3. X needn't necessarily be present in the result, but if it is (because some other dep actually does import X), then it must meet A's stated constraint.
   • (Again, there's a variant where it works like this for the root manifest, but like 2 for a non-root manifest.)

The first mode's biggest benefit is up-front intuitiveness for users. As we've discussed, it corresponds nicely to a get or add-

sdboyer

off-the-cuff thought - so, you still respect semver w/the sec release. but, you create an orthogonal dimension for sec info (basically metadata that crates can track, somehow), which marks existing/previous versions as INsecure.

cargo looks at this sec dimension while resolving; if constraints only allow the selection of known-insecure versions (or, perhaps, finding a secure version would require a downgrade, even if constraints allow it), then "peek" ahead at the published versions to see if there's something that constraints disallow, but is NOT marked insecure. if there are any, then bail out and inform the user, suggesting a widening of their constraints

some issues:

1. requires researching previous versions to see how far back a vulnerability goes. (idk how standard practice this is, i'm really not sec)
2. creates a new central attack vector: poisoning the secure/insecure list on crates
3. really forces authors to abdicate control over when they bump e.g. a major version, which will probably make the

sdboyer

On the topic of:

DS19 How do we decide what dependencies are safe/correct to use? DO we decide that at all?

first, @sdboyer comments

by this, i literally meant "what's the algorithm to pick versions." In that context, I'm not sure how "DO we decide that at all?" applies; if we don't have an algorithm that, at minimum, applies version constraints, then we don't have a tool...?

then, response:

There can be no algorithm to pick versions; the user can specify everything manually. I'm not saying it's a good or the right idea, but it is definitely possible.

Now, response to that:

sdboyer

$ cd $GOPATH/github.com/sdboyer/gta
$ gta -v -r "go test" github.com/sdboyer/gps
Checking github.com/sdboyer/gps with the following versions:
	[v0.10.0 v0.9.0 v0.8.2 v0.8.1 v0.8.0 v0.7.0 v0.6.0 v0.5.1 v0.5.0 v0.4.0 v0.3.0 v0.2.0 v0.1.0 v0.0.1 docs-support fix-netname glitter gps improved-trace master overrides prefetching refactor-analyzer test-errors url-separation]
Looking for solution with github.com/sdboyer/[email protected]!
	github.com/Masterminds/glide (from https://github.com/sdboyer/glide) at vsolver (2756e25)
	github.com/spf13/cobra at master (9c28e4b)
	github.com/inconshreveable/mousetrap at 76626ae
	gopkg.in/yaml.v2 at e4d366f
	github.com/sdboyer/gps at v0.10.0 (278a227)

sdboyer

package foo

import "bar"

type Foo struct {
    A bar.Bar
}

func init() {
    thing := Foo{}