Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

[hui zhang]

I found the case is like this
c code
IgnoreSignal(42);
while(1) {
GoSleep(10);//simulate some call in go runtime , the runtime call stack is
in last mail
int signo = sigwaitinfo(&signal_set, &signal_info); //will use this signo
to do something 
// usleep(1000*1000);
printf("sleep 10s \n");
// raise(42);
}

go code
//export IgnoreSignal
func IgnoreSignal(sig int) {
signal.Ignore(syscall.Signal(sig))
}

//export GoSleep
func GoSleep(x int) {
time.Sleep(time.Duration(x) * time.Second)
}

go build an  so lib ,  c link this so
run app
send signal like below
sigqueue(pid, 42, val);

go will catch that signal ,  and  but ignore it and delete it
what I expect  is passing the signal to  *sigwaitinfo*

hui zhang  于2019年8月13日周二 上午9:58写道：

> I am trying to extend a old c program with go.Add websocket ability to
> this c program.
> first  build  go as a  .so  dynamic lib
> then link the so lib in c program
> I run the cgo ok in an example program.
> But when integrate with old c program,  c program will send a signal 42 to
> itself periodly.
> this cause so lib terminate
>
> rogram received signal SIG42, Real-time event 42.
> [Switching to Thread 0xa53c6b70 (LWP 14957)]
> runtime.futex () at /usr/local/go/src/runtime/sys_linux_386.s:444
> 444 /usr/local/go/src/runtime/sys_linux_386.s: No such file or directory.
> in /usr/local/go/src/runtime/sys_linux_386.s
> Missing separate debuginfos, use: debuginfo-install WBXcms-3.7.0-494.i686
> (gdb) bt
> #0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_386.s:444
> #1 0xb7b04c2a in runtime.futexsleep (addr=0xb7fa47ac, val=0, ns=-1) at
> /usr/local/go/src/runtime/os_linux.go:46
> #2 0xb7ae5437 in runtime.notesleep (n=0xb7fa47ac) at
> /usr/local/go/src/runtime/lock_futex.go:151
> #3 0xb7b0c8f4 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1936
> #4 0xb7b0d848 in runtime.findrunnable (gp=@0x74421300, inheritTime=@0x0)
> at /usr/local/go/src/runtime/proc.go:2399
> #5 0xb7b0e507 in runtime.schedule () at
> /usr/local/go/src/runtime/proc.go:2525
> #6 0xb7b0edac in runtime.goexit0 (gp=0x744000e0) at
> /usr/local/go/src/runtime/proc.go:2722
> #7 0xb7b2f868 in runtime.mcall () at
> /usr/local/go/src/runtime/asm_386.s:345
> #8 0xb7b2f7c0 in runtime.rt0_go () at
> /usr/local/go/src/runtime/asm_386.s:241
> #9 0xb7b2f7c7 in runtime.rt0_go () at
> /usr/local/go/src/runtime/asm_386.s:246
> #10 0x00
>
> My question is
> *how go so lib ignore this signal 42,  and pass the signal handle to old c
> program.*
>
> Thanks
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/1YvP-5V6xSI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/22745e49-1d43-4e3a-9d78-20ff6bb20d4e%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAF7uC_vecUj34DuYteEARMxanWNvGxMT_pWj%3DLjCz7OigFPtvw%40mail.gmail.com.

[go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Volker Dobler]

On Tuesday, 13 August 2019 08:10:56 UTC+2, Sathish VJ wrote:
>
> So doing *type X Y* is just a type declaration then?
>

Yes, of course. It declares a new named type X, the underlying
type is Y which can be some predeclared type like int, some
other named declared type (like MyFooType) or a "type literal"
(a term I made up) like struct{X,Y float64; T string} or
map[string]bool or chan time.Time .

The main reason to declare a new type like
type NewType SomeExistingType
is that NewType starts of with an empty method set and you
can implement totally different methods on it or even implement
the methods with the same name but with different signatures
and/or different semantics.

Type aliases are necessary e.g. during refactoring large code
bases or to provide a certain compatibility. Do not use them
in "regular" code as they do not provide any value but make
reading the code harder.

You might want to read more about "embedding" one type into
a struct type: Grep the Spec for "embedded field". Embedding
allows to have a new type with potentially different method set
but reuse methods of the embedded type.

V.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c2b3a8b9-fef1-4fc5-b605-10f1fb67eebf%40googlegroups.com.

Re: [go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Jan Mercl]

On Tue, Aug 13, 2019 at 9:24 AM Volker Dobler
 wrote:

> Yes, of course. It declares a new named type X, the underlying
> type is Y which can be some predeclared type like int, some
> other named declared type (like MyFooType) or a "type literal"
> (a term I made up) like struct{X,Y float64; T string} or
> map[string]bool or chan time.Time .

"Type literal" is not made up, it's a well defined part of the
specification: https://golang.org/ref/spec#TypeLit ;-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X5Vr0nhGeuysJaAK4Y8pqptOC6s9qDENnic9Xv0sT1iw%40mail.gmail.com.

Re: [go-nuts] how cgo handle user define signal ? need go pass the signal handle to c

[hui zhang]

in other words
we need a *go runtime signal mask .*
just google, no such api provided by go yet .
I want know why ?
any workaround?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fcdceef3-6bcc-46cc-bf37-004b379c70bc%40googlegroups.com.

Re: [go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Volker Dobler]

On Tuesday, 13 August 2019 09:43:05 UTC+2, Jan Mercl wrote:
>
> On Tue, Aug 13, 2019 at 9:24 AM Volker Dobler 
> > wrote: 
>
> > Yes, of course. It declares a new named type X, the underlying 
> > type is Y which can be some predeclared type like int, some 
> > other named declared type (like MyFooType) or a "type literal" 
> > (a term I made up) like struct{X,Y float64; T string} or 
> > map[string]bool or chan time.Time . 
>
> "Type literal" is not made up, it's a well defined part of the 
> specification: https://golang.org/ref/spec#TypeLit ;-) 
>
 
Thanks for pointing to the spec!
I actually did made it up while writing but was luck to choose
come up with the correct term; probably because I read it in the
spec some time ago ;-)

V.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/935b956d-f33e-4492-b9b9-564a89317c2e%40googlegroups.com.

[go-nuts] Proposal: provide runtime sigprocmask api to block some signal for go runtime

[hui zhang]

check this  https://groups.google.com/forum/#!topic/golang-nuts/1YvP-5V6xSI
when we code golang with c,   some c code used *  sigwait  sigwaitinfo* 
function to wait signal.
sometime this signal is caught by golang runtime,  and this cause cash.
we want the signal continue to be handled by *sigwait  sigwaitinfo*


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/086f1e16-c8ea-4970-b4e8-98b34c4dec75%40googlegroups.com.

[go-nuts] Open Source audit of go package dependencies for security vulnerabilities?

[Steve Mynott]

I've been introduced to https://rubysec.com/ which has a database
which easily integrates with builds to check for known security
vulnerabilities in third party libraries and was wondering whether
anything similar exists for go packages?

A quick search finds https://snyk.io/vuln?type=golang which appears
similar but is basically a pay service based on node.js.

Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project
looks interesting but doesn't include go.

Does such an open source version exist for go which is written in go
and integrates easily with builds?

-- 
Steve Mynott 
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANuZA8RhYQrLY%3DJ_BgqYzJm%3Dehyr%3DbCo1F%3D2pCcJJ8cf2u-Vig%40mail.gmail.com.

Re: [go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Jesper Louis Andersen]

On Tue, Aug 13, 2019 at 8:10 AM Sathish VJ  wrote:

> So doing *type X Y* is just a type declaration then?
>
>
In a certain sense

  type X Y

and

  type X = Y

are both type declarations. They differ in that the first is generative,
whereas the other is a synonym. In a generative pattern, you are
generating, or minting, a new type X which differs from Y; whereas in the
the synonym situation, the types X and Y admits equality at the type level.
Historically, Go only had generative types. The second case was added to
the language, because of a need to facilitate large scale program
rewriting. By aliasing a type, you can point an older implementation to a
new one or vice versa, until the work has been completed. This avoids the
need of one large patch across several modules, and allows for a more
partial approach in which the programmer can split the patch over multiple
commits.

As a simple example of why you would often prefer types to differ, consider
something like

  type meter int
  type yard int

Clearly, you don't want to admit the interchange of two different distance
units (Even worse: Pound-Force to Newton's). This is by far the common case
in programming, and they are crucial for producing modular code via
encapsulation and isolation.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiXCSygqAC%3DyqPY%2But0Hm_MZ49qX2ZJnixuE1%2BLt6aVv-w%40mail.gmail.com.

Re: [go-nuts] I know you cannot kill a goroutine, but ...

[Jesper Louis Andersen]

On Fri, Aug 9, 2019 at 8:34 PM  wrote:

> The current Go implementation smells of cooperative multitasking. Not a
> bad thing, per se, but makes it hard to stop in certain degenerate cases.
> Have I missed a way to deal with some of the discussed issues?
>
>
My spider sense (intuition) says you might enjoy reading up on the
"context" package in the standard library. The core idea is to create a
"network" of poison channels on which you send messages if things needs to
stop. These channels are used solely for the purpose of managing lifetime
of goroutines, not for normal communication[0] As long as a goroutine
checks for the poison pill eventually, you can send an event to it in order
to stop it. It will require some adaptation to your needs, but I think
there are salvageable ideas in there for you to pursue.

[0] Essentially, you have a bigraph: the message channels forms the
hypergraph part of the bigraph, and the context tree forms one of the tree
sets of the bigraph. The context tree is mapping the "location" of
goroutines, i.e., who belongs together. This allows the conjuration of your
inner Alexandre Dumas: "Un pour tuos, tuos pour un"

-- 
J.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiXdkuUh7cjOKMw8xdX-Cg-GxjDNzkMMgBRT789fsvYzNQ%40mail.gmail.com.

Re: [go-nuts] [gccgo] weird constant values in sysinfo.go

['Than McIntosh' via golang-nuts]

Hi,

Thanks for the heads-up.

I also see what you're seeing for my build, and this is a mystery for me as
well.

The libgo makefile generates "sysinfo.go" by running the C compiler on a
source that includes various system headers, so as to capture Go versions
of C-specific constants and types. This is done using the
-fdump-go-spec= command line option.

I ran GCC under the debugger and looked at the value for FLT128_MAX at the
point where the go-dumpspec code executes, and it is indeed "1.1", so I
don't think this is a bug in the Go-specific code.  What's more surprising
is that when I start with the same compile command used to generate the Go
file, remove "-fdump-go-spec, and add in "-E -dM", I do see a correct
definition for FLT128_MAX (very weird).

Given that Go doesn't use float128, I'm not sure it will really matter a
whole lot in the long run, but it is a surprising oddity.

Thanks, Than

On Mon, Aug 12, 2019 at 11:21 PM Xiangdong JI  wrote:

> Hello,
>
> The .go files generated during building gccgo seem to have a few constants
> with weird values, for example:
>
> // sysinfo.go (on x86-64, latest gcc-9 trunk)
>
> const ___FLT128_MAX__ = 1.1
> const ___FLT32X_DENORM_MIN__ = 1.1
>
> as a comparison, gollvm generates expected values.
> Could it be caused by incorrect building setting?
> Thanks.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b808ccdd-023c-4b95-9db0-2a00b3435735%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EDGqJFzBCW5etNeyzsSNpjzxA2x_goe9NxsEjT0Xuk2Q%40mail.gmail.com.

[go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[jochen . czemmel]

type X Y is a type declaration, you have to cast between the types
type X=Y is a type alias, where X can be used as Y without casting

Am Dienstag, 13. August 2019 06:53:20 UTC+2 schrieb Sathish VJ:
>
> And what is the difference between each of these: type alias, type 
> redefinition, type adapter.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ffaba699-f9c6-4418-857e-999a693206a6%40googlegroups.com.

[go-nuts] Broken links on some blogs

[Shulhan]

Hello gophers,

I am not sure where or how to report this problem, but all of the links
from the following blog

  https://blog.golang.org/upcoming-google-io-go-events

are 404.  Some of examples,

  *  http://code.google.com/events/io/2010/
  *  http://code.google.com/events/io/2010/bootcamp.html
  *  http://code.google.com/events/io/2010/sessions/go-programming.html
  *  http://code.google.com/events/io/2010/officehours.html

There are probably other links in other posts that also broken.  Let me
known if I should open an issue and/or check other links.

-- 
{ "github":"github.com/shuLhan", "site":"kilabit.info" }

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20190814011259.5a10882e%40kilabit.local.

[go-nuts] Re: When doing "type X Y", is it a type alias or type redefinition or type adapter or something else?

[Volker Dobler]

On Tuesday, 13 August 2019 17:03:36 UTC+2, jochen...@gmx.de wrote:
>
> type X Y is a type declaration, you have to cast between the types
> type X=Y is a type alias, where X can be used as Y without casting
>

There are no type cast in Go. Only type conversions.

V.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56bc89db-b018-4508-917b-ea6234b53bad%40googlegroups.com.

[go-nuts] [security] Go 1.12.8 and Go 1.11.13 are released

[Dmitri Shuralyov]

Hi gophers,

We have just released Go 1.12.8 and Go 1.11.13 to address recently reported
security issues. We recommend that all users update to one of these
releases (if you’re not sure which, choose Go 1.12.8).

   - net/http: Denial of Service vulnerabilities in the HTTP/2
   implementation

   net/http and golang.org/x/net/http2 servers that accept direct
   connections from untrusted clients could be remotely made to allocate an
   unlimited amount of memory, until the program crashes. Servers will now
   close connections if the send queue accumulates too many control messages.
   The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue
   golang.org/issue/33606.
   Thanks to Jonathan Looney from Netflix for discovering and reporting
   these issues.

   This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of
   golang.org/x/net/http2.


   - net/url: parsing validation issue

   url.Parse would accept URLs with malformed hosts, such that the Host
   field could have arbitrary suffixes that would appear in neither Hostname()
   nor Port(), allowing authorization bypasses in certain applications. Note
   that URLs with invalid, not numeric ports will now return an error from
   url.Parse.
   The issue is CVE-2019-14809 and Go issue golang.org/issue/29098.
   Thanks to Julian Hector and Nikolai Krein from Cure53, and Adi Cohen (
   adico.me) for discovering and reporting this issue.

Downloads are available at https://golang.org/dl for all supported
platforms.

Thank you,
Dmitri on behalf of the Go team

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BON-PEjQFgeSCRenLKgW7LzBfLV8Gk368-85rGde-LC-8O3Ag%40mail.gmail.com.

[go-nuts] Re: functions with arguments vs. function with a receiver?

[Victor Giordano]

Hi Joe, to my current understanding of things i would say that both ways 
are the same and without further context it seems similar.
Using a pointer reciever it seems more object-oriented to me, as i have 
spend many years working in Java. 

I know this:

type S struct {}

func (s S) pepe () {}

"s.pepe()" is Equals to "S.pepe(s)"

So... very good question! I hope someone could answer with more information.


El sábado, 10 de agosto de 2019, 19:57:34 (UTC-3), joe mcguckin escribió:
>
> Is there a recommended usage for either style?
>
> Take ListenPacket for example. There a (*ListenConfig).ListenPacket 
> version and a version that takes arguments.
>
> What's the difference and what is the desired usage of either?
>
> Thanks,
>
> Joe
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0e4d5d73-4815-4650-989a-b4ffd8dc5474%40googlegroups.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

['Eric Johnson' via golang-nuts]

It would be great to hear of an answer to this question. I suspect there 
isn't one, though.

The trouble is, one of the first hurdles is to identify Go libraries that 
have CVEs against them. It is very easy to find CVEs for the Go standard 
library, but I cannot see any easy way to scan the vulnerability databases 
for vulnerable projects that happen to be implemented in Go.

On top of that, for the purposes of dependency scanning, we really only 
need to care about those projects implemented in Go that have non-main 
packages. The main packages may have vulnerabilities, but those will never 
show up in a dependency scan...

If one can identify that list, then the open source tool to find any 
dependent libraries that might have vulnerabilities would be pretty 
straightforward.

Unfortunately, identifying that list is might be really hard. Currently 
probably only possible for companies that have a business model that 
supports paying people to investigate each and every one of the 
vulnerabilities that shows up with a CVE

Maybe someone on this list can think of a great way to filter the CVE 
list

Eric.

On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>
> I've been introduced to https://rubysec.com/ which has a database 
> which easily integrates with builds to check for known security 
> vulnerabilities in third party libraries and was wondering whether 
> anything similar exists for go packages? 
>
> A quick search finds https://snyk.io/vuln?type=golang which appears 
> similar but is basically a pay service based on node.js. 
>
> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
> looks interesting but doesn't include go. 
>
> Does such an open source version exist for go which is written in go 
> and integrates easily with builds? 
>
> -- 
> Steve Mynott > 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c5ea3214-26ef-41c9-a5eb-b8ed4c65c448%40googlegroups.com.

Re: [go-nuts] Open Source audit of go package dependencies for security vulnerabilities?

[Paul Jolly]

Some related discussion in https://github.com/golang/go/issues/24031 and
linked issues.

On Tue, 13 Aug 2019 at 10:32, Steve Mynott  wrote:

> I've been introduced to https://rubysec.com/ which has a database
> which easily integrates with builds to check for known security
> vulnerabilities in third party libraries and was wondering whether
> anything similar exists for go packages?
>
> A quick search finds https://snyk.io/vuln?type=golang which appears
> similar but is basically a pay service based on node.js.
>
> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project
> looks interesting but doesn't include go.
>
> Does such an open source version exist for go which is written in go
> and integrates easily with builds?
>
> --
> Steve Mynott 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANuZA8RhYQrLY%3DJ_BgqYzJm%3Dehyr%3DbCo1F%3D2pCcJJ8cf2u-Vig%40mail.gmail.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn4cAa-t%2B12C0br2tMo0fef0fs%3D4rSnikVkuGrWsxQ-V3g%40mail.gmail.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

['Eric Johnson' via golang-nuts]

And then, it also occurs to me that perhaps I can answer my own question. 
Taking advantage of three aspects of the ecosystem.

#1) Most open source Go libraries are on GitHub
#2) Many (most?) CVEs for open source projects will include a reference 
back to the project, and these references can be extracted from the cvelist 
 project.
#3) GitHub has an API to fetch the language of a GitHub repository.

Putting those three together, it might be possible to filter every CVE 
entry that has a reference to GitHub, then every GitHub project in that 
list that is implemented in Go, and turn that into a list of 
vulnerabilities for packages. Then match on those packages. That might 
generate a short list of projects that have had vulnerabilities. That far 
more reasonable list could then be augmented by a small amount of open 
source labor to annotate with the versions known to be vulnerable, when new 
items appear.

>From a completely different direction, the CVE quality team is looking to 
add more data to CVE entries. Seems like implementation language + package 
management name as additional data in the CVE record itself might also help 
address the issue. That would be generalizable to Java, Javascript. Rust, 
Python, and Go, for starters.

Before I send that idea in to the quality WG, does anyone here have a 
better suggestion?

Eric

On Tuesday, August 13, 2019 at 9:50:19 PM UTC-7, Eric Johnson wrote:
>
> It would be great to hear of an answer to this question. I suspect there 
> isn't one, though.
>
> The trouble is, one of the first hurdles is to identify Go libraries that 
> have CVEs against them. It is very easy to find CVEs for the Go standard 
> library, but I cannot see any easy way to scan the vulnerability databases 
> for vulnerable projects that happen to be implemented in Go.
>
> On top of that, for the purposes of dependency scanning, we really only 
> need to care about those projects implemented in Go that have non-main 
> packages. The main packages may have vulnerabilities, but those will never 
> show up in a dependency scan...
>
> If one can identify that list, then the open source tool to find any 
> dependent libraries that might have vulnerabilities would be pretty 
> straightforward.
>
> Unfortunately, identifying that list is might be really hard. Currently 
> probably only possible for companies that have a business model that 
> supports paying people to investigate each and every one of the 
> vulnerabilities that shows up with a CVE
>
> Maybe someone on this list can think of a great way to filter the CVE 
> list
>
> Eric.
>
> On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>>
>> I've been introduced to https://rubysec.com/ which has a database 
>> which easily integrates with builds to check for known security 
>> vulnerabilities in third party libraries and was wondering whether 
>> anything similar exists for go packages? 
>>
>> A quick search finds https://snyk.io/vuln?type=golang which appears 
>> similar but is basically a pay service based on node.js. 
>>
>> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
>> looks interesting but doesn't include go. 
>>
>> Does such an open source version exist for go which is written in go 
>> and integrates easily with builds? 
>>
>> -- 
>> Steve Mynott  
>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/95bd2530-182c-4d0f-8d70-b303bf8b1e9d%40googlegroups.com.