On Tue, 20 Feb 2018 12:20:19 -0500
Russ Cox <r...@golang.org> wrote:
> https://research.swtch.com/vgo.
> Russ
Amazing! The 'minimal version selection' approach is briliant.
Where it lacks for me is about keeping up with security patches.
If my module keeps libFoo at 1.2.3 it will not see a backported fix
that came with 1.2.98. At least not without me doing chores and
updating what I have to and leaving out what I don't.
So I'd like to see vgo to tackle also backported security patches.
Namely tags in the form of:
x.y.z+spN where N is a security patch level.
If there is no +spN meta in the chosen tag, sp0 level is assumed.
If there is +spN, vgo SHOULD update dependency to the
highest N it sees - unless forbidden by the go.mod.
So:
require (
"rsc.io/quote" v1.5.2
)
Will use v1.5.2+sp7 if there is a such tag in the repo and 7 is the
highest sp level.
For testing (or govt certification) purposes one may
intentionally keep dependency with a hole; e.g:
"rsc.io/quote" v1.5.2 noSecurityPatchesPlease
or even
"rsc.io/quote" v1.5.2+sp3 noSecurityPatchesPlease
to have quote pinned to exact sp3 level.
In corporate environments it is not unusual to have decades old
software in production and maintenance, where 'maintenance'
is strictly regulated. Above scheme would help with that. IMO.
As vgo promises builds with tags immersed into binary any
security audit of go binaries may just list versions and compare
sp levels with ones at the source repo. If there is higher spN,
we will know something is amiss immediately - without grepping
changelogs for a CVE lines.
m0.2c
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
