[go-nuts] Interface in go-plugins

[Teng Zhang]

Hi,
I am using plugin package to implement a feature of my project recently,
But some behavior confuses me.

#1 interface

main.go:
type PluginType interface{
GetVersion() string
}

func main() {
plugFile, err := plugin.Open(filepath.Join("plugins", "plugin_sample.so"))
if err != nil {
fmt.Println("Fails to load plugins")
fmt.Println(err)
return
}
plugTarget, err := plugFile.Lookup("PluginTarget")
if err != nil {
fmt.Println("Fails to get target veriable")
fmt.Println(err)
return
}

plug, ok := plugTarget.(PluginType)
if !ok {
fmt.Println("Assert convert fails")
return
}
fmt.Println("plugin version:", plug.GetVersion())
}

if I write plugin_sample.go like this
```
package main

type pluginType struct{}

var PluginTarget *pluginType = &pluginType{}

func (v *pluginType) GetVersion() string {
return ""
}
```

then
go build -buildmode=plugin -o plugins/plugin_sample.so plugin_sample.go
go run main.go

It will print `Assert convert fails`

But If I write like
```
package main

type pluginType struct{}

var PluginTarget pluginType

func (v pluginType) GetVersion() string {
return ""
}
```
It will print `plugin version: ` as expected.

Is this a bug of plugin package of golang?

  #2 I notice buildmode=plugin only support Linux, is there any plan to
support Macos in the feture? I am using go1.12.

Thanks
Teng

-- 
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.

[go-nuts] built-in alternative to bcrypt?

[whitehexagon via golang-nuts]

I'm porting some code over to Go, and currently looking at some password 
hashing.  I'm wondering if there is a 'standard library' alternative to 
using bcrypt?

I am concerned about the Go binary size, since I'm already at 15MB!  So I'm 
trying to limit external dependencies as much as possible.  

The data being stored is not critical or sensitive, just some email address 
mainly.  

>From my research it sounds like 'golang.org/pkg/crypto/sha512/' might be 
what I need, but I dont see any clear alternative for the following 
functions below:  

I'm still new to Go, so I'm wondering what would be the recommended 
solution using the standard library please?

Peter


bcrypt.GenerateFromPassword

bcrypt.CompareHashAndPassword

-- 
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.

[go-nuts] favorite retry libraries

[Joseph Lorenzini]

Hi all,

I am looking for a simple retry library that supports exponential backoffs 
and cancellation via context. I have found several but nothing is standing 
out for me. I was curious to see what experience people have had with the 
various retry libraries out there and what you'd recommend and why.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] built-in alternative to bcrypt?

[Aldrin Leal]

Hashing passwords without salt are prone to rainbow table attacks. I
particularly like this comment in a Java Source Code:

https://github.com/apache/shiro/blob/f782eb1084df73eff3e2ac0f9780cb4a4f429041/core/src/main/java/org/apache/shiro/authc/credential/HashedCredentialsMatcher.java#L56

When storing password, always go for salted approaches (thus bcrypt)

Also, bear in mind upx works like a charm on Go Binaries:

https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/

--
-- Aldrin Leal,  / https://ingenieux.io/about/


On Mon, Apr 22, 2019 at 5:15 AM whitehexagon via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm porting some code over to Go, and currently looking at some password
> hashing.  I'm wondering if there is a 'standard library' alternative to
> using bcrypt?
>
> I am concerned about the Go binary size, since I'm already at 15MB!  So
> I'm trying to limit external dependencies as much as possible.
>
> The data being stored is not critical or sensitive, just some email
> address mainly.
>
> From my research it sounds like 'golang.org/pkg/crypto/sha512/' might be
> what I need, but I dont see any clear alternative for the following
> functions below:
>
> I'm still new to Go, so I'm wondering what would be the recommended
> solution using the standard library please?
>
> Peter
>
>
> bcrypt.GenerateFromPassword
>
> bcrypt.CompareHashAndPassword
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] go execution speed for float64 based calculations vs float32

[Robert Engels]

The email you cite is for integers. Integer math is not performed by the fpu - 
so it is not the same. 

> On Apr 22, 2019, at 12:57 AM, lgod...@gmail.com wrote:
> 
> I note that this issue has been dealt with in a previous post  
> https://groups.google.com/forum/#!topic/golang-nuts/n12khle-mlY
> The gist of which seems to suggest that 32-bit is faster than 64
> 
>> On Sunday, April 21, 2019 at 10:09:09 PM UTC-4, Robert Engels wrote:
>> At least on intel, float64 should be faster than float32 since all math is 
>> done on the fpu in 64 bits, so it needs to be converted, but the memory bus 
>> also comes into play. 
>> 
>> I would doubt it. Float32 is designed for size not performance. 
>> 
>>> On Apr 21, 2019, at 8:55 PM, lgo...@gmail.com wrote:
>>> 
>>> ?? On 64-bit CPUs does anyone have any experience comparing the run-time 
>>> speed of float64 based calculations vs float32 ?
>>> 
>>> Some of my C-code when translated to Go-code seems to run noticeably 
>>> slower, so I'm wondering if I can speed things up by converting float vars 
>>> to float32 vs float64 
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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.

-- 
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.

Re: [go-nuts] go execution speed for float64 based calculations vs float32

[Marvin Renich]

* lgod...@gmail.com  [190422 01:57]:
> I note that this issue has been dealt with in a previous post  
> https://groups.google.com/forum/#!topic/golang-nuts/n12khle-mlY
> The gist of which seems to suggest that 32-bit is faster than 64

That thread was specific to integer remainder (%) and is irrelevant to
any other integer operation and completely irrelevant to floating point.
There was also no mention of architecture, which will also influence the
result.

On the amd64 architecture, the FPU operates internally on 10-byte
floating point values, and there is a conversion when loading and
storing both 4-byte and 8-byte floats.

If performance is important in the part of your app that is doing
floating point manipulation, profile your app.  Write that part of the
app so that you can easily change between float32 and float64, and
profile both cases.

Micro benchmarks can give you some ideas, but for real answers, you need
to test in situ.

...Marvin

-- 
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.

[go-nuts] Re: Working outside of VCS - parent/child modules

[thepudds1460]

You do have the option to nest one module within another module in the same 
repo, but from what I have seen, that is usually not what one wants to do, 
and especially not to start. It can be tricky to set up correctly, and 
usually is more work on an on-going basis.

The clearest statement I've seen might be Russ Cox wrote in #26664:

   "For all but power users, you probably want to adopt the usual 
convention 
that one repo = one module. It's important for long-term evolution of 
code 
storage options that a repo can contain multiple modules, but it's 
almost 
certainly not something you want to do by default."

In terms of your question about each child module being able to specify 
it's own dependencies, that is a more nuanced question, but hopefully this 
at least conveys the gist...

If you have a single go.mod with multiple packages, that go.mod will track 
the dependencies across all packages, which usually works reasonably well 
in practice for most projects.

If we take the example where package foo and bar reside in a single module, 
it is usually not a problem for example if:

 1. foo and bar both require the same v1+ major version of some dependency 
X (including given X should be compatible within a v1+ major version, 
according to semver).
 
 2. foo and bar require different major versions of dependency Y (including 
given Y can be separately tracked within a single go.mod as require Y/v2 
and require Y/v3).

It would however be a problem if:

 3. package foo requires a v0 version of some dependency Z that is 
incompatible with the v0 or v1 version of Z required by bar (because at 
most one v0/v1 version of dependency Z would be tracked within a single 
go.mod).
 
 4. if foo and bar require different incompatible versions of a shared 
dependency that does not follow https://semver.org. (Following semver is a 
requirement for any code opting in to modules, but pre-existing code will 
not have always followed semver).

Perhaps your logging example would fall into the second case of needing to 
use different major versions in a single build? If so, modules allow that.

If you weigh the pros and cons and really do feel the need to nest modules 
within a single repo, the modules wiki has an entire section dedicated to 
that, which I would encourage you to read carefully if you do go down that 
path. As you'll note, though, there is some nuance there:

   https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
   
Regards,
thepudds

On Saturday, April 20, 2019 at 8:57:09 AM UTC-4, whiteh...@googlemail.com 
wrote:
>
>
> https://github.com/golang/go/wiki/Modules#can-i-work-entirely-outside-of-vcs-on-my-local-filesystem
>
> For a simple parent/child module relationship this seems to work, since 
> the 'replace' work-around is in the parent go.mod.  
> But when the childA depends on childB, then the 'replace' directive in 
> childA's go.mod is ignored, and the build fails.  According to the above 
> information this is working as designed.
>
> Since there is no error feedback that the 'replace' directive has been 
> ignored, I eventually stumbled over a couple of similar reported issues.  
> Which is how I also found the information that sub-module 'replace' 
> directives are being ignored.
>
> https://github.com/golang/go/issues/29376
> https://github.com/golang/go/issues/31345
>
> Since I'm just learning Go I would like to understand the approach 
> better.  I come from a Maven background for dependency management.  Here it 
> is a common pattern to have a parent/child module design.  Each child 
> module can specify it's own dependencies.  And in complex projects two 
> different sub-modules or sub-sub-modules may even have requirements on 
> different versions of the same library (Logging I'm looking at you!).
>
> So this question is also applicable when running under VCS. ie that Go 
> sub-modules may want to specify a specific version of a library that they 
> depend upon using the replace directive.
>
> Anyway I am left with the impression that this parent/child module pattern 
> might be considered non idiomatic in the Go world?  ie Go is targeting a 
> 1-to-1 mapping of VCS project to Module.  Is that fair to say?  
>
>

-- 
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.

Re: [go-nuts] go execution speed for float64 based calculations vs float32

[Marvin Renich]

* lgod...@gmail.com  [190421 21:56]:
> ?? On 64-bit CPUs does anyone have any experience comparing the run-time 
> speed of float64 based calculations vs float32 ?
> 
> Some of my C-code when translated to Go-code seems to run noticeably 
> slower, so I'm wondering if I can speed things up by converting float vars 
> to float32 vs float64 

I would be more suspicious of the C-to-Go conversion than float32 vs
float64.  While Go has similarities to C, rewriting in Go with its
strengths and weaknesses in mind will produce much better code all
around (performance and maintainability).

...Marvin

-- 
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.

[go-nuts] Re: Does fmt.Fprint use WriteString ?

[Constantin Konstantinidis]

fmt.Fprint is calling io.WriteString as you can this comment 

 
and the code around indicates.

-- 
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.

[go-nuts] Re: built-in alternative to bcrypt?

[bucarr]

I'm a hobbiest new to Go as well.

In the x library (still part of the standard library) written by the Go 
Authors is argon2. It allows for salting, stretching and hashing 
passwords.  The recent guru commentary I've read is that "new 
implementations of applications which will use password hashing should 
probably use argon2". In my particular case I salt, pepper, stretch and 
hash all passwords. And use sha3 (also in the x library) for preliminary 
twiddling.

Cheers!

-- 
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.

[go-nuts] Re: golang type casting from interface int32 to int

[gr . sasikala477]

You have to convert int 32 to int .


On Wednesday, October 9, 2013 at 12:41:03 AM UTC+5:30, Tong Sun wrote:
>
> Hi, 
>
> I'm trying to assign a variable of type interface {} int32 to another 
> variable 
> of type int, and here are the all the errors that I'm getting:
>
> - cannot use id (type interface {}) as type int in assignment: need type 
> assertion
>
> - panic: interface conversion: interface is int32, not int
>
> - cannot use id.(int32) (type int32) as type int in assignment
>
> - invalid type assertion: id.(int32).(int) (non-interface type int32 on 
> left)
>
> what's the proper way to do it? 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] callgraph: unclear calls in the output of callgraph tool

[ildar97 . 97]

Hi everyone. I came across some unclear result when used callgraph to 
analyze go-ethereum project. Could you give me a clue to find an 
explanation, please?

I used these commands to generate reports:

   1. 
   
   rta analysis:
   callgraph github.com/ethereum/go-ethereum/cmd/geth > go-ethereum_call.txt
   2. 
   
   pta analysis:
   callgraph -algo pta github.com/ethereum/go-ethereum/cmd/geth > 
   go-ethereum_call_pta.txt
   
Specifically, I cannot understand this line which appears in both reports:
(github.com/ethereum/go-ethereum/log.funcHandler).Log --dynamic-36:10--> 
github.com/ethereum/go-ethereum/log.StreamHandler$1


This is supposed should be called here: 
https://github.com/ethereum/go-ethereum/blob/a9835c1816bc49ee54c82b4f2a5b05cbcd89881b/log/handler.go#L36


What is the reason that such dynamic call could occur and in which case it 
is possible?

-- 
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.

[go-nuts] Go Profiling helper extension for VSCode

[mediamax . info]

Hello,


we have published our first version of VSCode extension to help in 
profiling of your benchmarks.
This is a first test version. Please post your feedback here.


marketplace link:
https://marketplace.visualstudio.com/items?itemName=MaxMedia.go-prof

-- 
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.

Re: [go-nuts] go execution speed for float64 based calculations vs float32

[L Godioleskky]

Thanks guys for the cogent clarifications..I will now forget  about
converting to float32 on 64-bit CPUs

I'm in the process of converting my often-used C-code apps to Go because I
see tremendous advantages of Go vs C.

I've been using C,C++ for many years and only recently discovered Go...
My Go knowledge is 100% self-taught and entirely based on Go web docs,
tutorials, blogs etc
A good doc on "C  to Go code conversion",would help me greatly, so if
anyone knows of one, I'd appreciate knowing about it
I'm somewhat reluctant to use software based conversion

On Mon, Apr 22, 2019 at 8:55 AM Marvin Renich  wrote:

> * lgod...@gmail.com  [190421 21:56]:
> > ?? On 64-bit CPUs does anyone have any experience comparing the run-time
> > speed of float64 based calculations vs float32 ?
> >
> > Some of my C-code when translated to Go-code seems to run noticeably
> > slower, so I'm wondering if I can speed things up by converting float
> vars
> > to float32 vs float64
>
> I would be more suspicious of the C-to-Go conversion than float32 vs
> float64.  While Go has similarities to C, rewriting in Go with its
> strengths and weaknesses in mind will produce much better code all
> around (performance and maintainability).
>
> ...Marvin
>
> --
> 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/3Io9xRmqAWM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

[go-nuts] Re: Working outside of VCS - parent/child modules

[whitehexagon via golang-nuts]

Thank you for taking the time for a thoughtful response, it's good to get 
some context about why things are as they are.

Previously I have worked in large organisations were most projects were 
using a single repo for a given project, with multiple projects spread 
across many departments.  So a typical project might be 20-30 developers 
working on a given repo over a number of years, normally grouped into 
traditional tiers of client, server, and persistence, shared comms, utils, 
and monitoring.

So a given release is the total sums of those parts, and probably why 
traditionally they have been kept together in a single repo (and for 
simplicity), since a VCS label represents a known state across all 
inter-dependencies.  Some companies handled this better than others, with 
well documented APIs between dependencies, but not many.  And less so with 
agile polyglot full-stack developers hacking away at all tiers :)

So taking into account my new information, each one of those parts of the 
larger project would now be a single repo+module in Go.  I'm fine with 
that, now I know it's intentional.  But then how would I group these into a 
whole?  I don't see any build tools like ant/maven/graddle that can handle 
Go.  

Would it be reasonable to have another separate repo, that purely holds a 
go.mod file which lists all the different module versions of it's 
constituents? and in doing so represents a given release.  Or how do others 
manage this?

Peter

-- 
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.

[go-nuts] Re: built-in alternative to bcrypt?

[lgodio2]

Try scrypt at   github.com/elithrar/simple-scrypt  . It's not a 
'standard lib' item, but I've found the authors code easy to implemented as 
'package main' code vs 'package' code

On Monday, April 22, 2019 at 6:14:48 AM UTC-4, whiteh...@googlemail.com 
wrote:
>
> I'm porting some code over to Go, and currently looking at some password 
> hashing.  I'm wondering if there is a 'standard library' alternative to 
> using bcrypt?
>
> I am concerned about the Go binary size, since I'm already at 15MB!  So 
> I'm trying to limit external dependencies as much as possible.  
>
> The data being stored is not critical or sensitive, just some email 
> address mainly.  
>
> From my research it sounds like 'golang.org/pkg/crypto/sha512/' might be 
> what I need, but I dont see any clear alternative for the following 
> functions below:  
>
> I'm still new to Go, so I'm wondering what would be the recommended 
> solution using the standard library please?
>
> Peter
>
>
> bcrypt.GenerateFromPassword
>
> bcrypt.CompareHashAndPassword
>

-- 
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.

Re: [go-nuts] built-in alternative to bcrypt?

[Sam Whited]

On Mon, Apr 22, 2019, at 10:14, whitehexagon via golang-nuts wrote:
> I am concerned about the Go binary size, since I'm already at 15MB! So
> I'm trying to limit external dependencies as much as possible.

Staying in the standard library won't help you here. You'll still
have to link in the code you use regardless of where it comes from
(the entire standard library isn't linked into your binary, just
whatever you use).

As someone else mentioned, argon2 is probably what you want [1]. It's
the current OWASP recommendation [2].

—Sam

[1]: https://godoc.org/golang.org/x/crypto/argon2
[2]: 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md#leverage-an-adaptive-one-way-function

-- 
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.

[go-nuts] Re: Mutual tls example

[Timothy Raymond]

I believe Liz Rice covered this in her GopherCon 2018 talk on TLS 
connections: https://www.youtube.com/watch?v=kxKLYDLzuHA

On Sunday, April 21, 2019 at 8:09:17 AM UTC-4, Vasiliy Tolstov wrote:
>
> Hi, I'm try to find mutual tls example in go, but can't find simple 
> example that uses crypto/tls. I need server that for some http handler for 
> user request with token returns tls cert for communication, and client that 
> uses this cert to communication after it returned from request. Ideally 
> with ability to rotate keys on client before previous expired.
> Does anybody knows it?
>
>

-- 
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.

[go-nuts] Re: Does fmt.Fprint use WriteString ?

[codiglot]

Actually, that comment points to the implementation of WriteString for the 
fmt package's internal pp type, which in turn is used by other fmt 
functions to handle strings efficiently. After scanning that source file 
some more, and the source file for io.WriteString (
https://golang.org/src/io/io.go?s=10163:10218#L279) I can see that even 
though fmt.Fprint and others don't use io.WriteString directly, they do 
exactly the same thing io.WriteString does, which is calling the 
destination's Write method exactly once and only once, thus avoiding extra 
allocations. So in conclusion, from what I see, it's equally efficient to 
write a string to a writer via io.WriteString or fmt.Fprint.

On Monday, April 22, 2019 at 9:28:50 AM UTC-4, Constantin Konstantinidis 
wrote:
>
> fmt.Fprint is calling io.WriteString as you can this comment 
> 
>  
> and the code around indicates.
>

-- 
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.

[go-nuts] Re: built-in alternative to bcrypt?

[whitehexagon via golang-nuts]

Thanks everyone, plenty more reading for me!  

I'm also pleased to discover the increasing binary size isn't being ignored 
by the team :) especially since I'm also planning some more Go WASM stuff 
(although currently I switched to Java WASM for exactly this reason for 
that part of the project).  

Also good to know only what I'm using gets linked in, but then the size of 
'hello world' is even more surprising.

The argon2 looks interesting, but it sounds like it could be very memory 
heavy.  The code I'm porting is running on a PAAS/SAAS setup, and that 
might have cost implications exceeding the worth of my low value data.  But 
I will also have a look then at the sha3 that was mentioned, now that I 
know the 'x' stuff is internally produced by the same team!

I get the impression from some of the info I'm going through, that since 
I'm running on hosted systems, which optionally also have encrypted file 
systems, that some of the brute force defense stuff might be less 
applicable?  ie unless the database is physically stolen from some nuclear 
bunker somewhere in the world, and decrypted, and my noddy system is deemed 
worth hacking, it's probably pretty safe already.  So the main attack 
vector would be multiple login attempts, which I can detect fairly easily.  
for example, 5 failed logins and the account is locked...

I was also thinking in this case I could use a client side hash so that the 
backend system never see's a plain text password.  I realise of course that 
the hash becomes the password, but at least the hosted environments would 
never see clear text before reaching my hosted hash stuff. ie clients that 
reuse 123456 for everything :)

Anyway plenty for me to think about, thank you everybody.

Peter



-- 
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.

[go-nuts] Re: gomobile and module

[Elias Naur]

On Mon, Apr 22, 2019 at 9:24 PM Junda Liu  wrote:
>
> Hi Elias,
>
> Thanks so much for working on gomobile! We've used it heavily to ensure same 
> code base between server and client sdk.
>

Hi Junda,

I took the liberty of CC'ing golang-nuts. My replies are below,
perhaps others know more.

> I already read your posts in https://github.com/golang/go/issues/27234
> Consistent dependency based on go.mod is critical to our system, so we're 
> perfectly fine to check the generated main pkg into code base (it actually 
> also helps to capture missed APIs due to unsupported type early)
>
> In my test I first run gobind for java and go, then run go build 
> GOOS=android, hit https://github.com/golang/go/issues/30888. But I'm confused 
> why calling gomobile with same GOOS=android works. Is it due to 
> $GOPATH/src/golang.org/x/sys and $GOPATH/pkg/mod/golang.org/x/sys@... are 
> different?
>
> What's the right env variables and args to run go build?

You can use the -x flag to gomobile to see how it invokes go build. I
suspect gomobile succeeds in building x/sys because it sets
GO111MODULE=off.

> Would also like to hear from you more advice/other possible issues to make 
> modules work with gomobile, thanks!
>

I have never used gomobile with go modules. Perhaps others on this
list have more information.

 - elias

-- 
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.

Re: [go-nuts] Re: Mutual tls example

[Vasiliy Tolstov]

пн, 22 апр. 2019 г. в 20:06, Timothy Raymond :
>
> I believe Liz Rice covered this in her GopherCon 2018 talk on TLS 
> connections: https://www.youtube.com/watch?v=kxKLYDLzuHA
>


Thank you this is very helpful for me.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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.

[go-nuts] why does reading a file on windows add CRLF to unix line endings... sometimes?

[Dan Kortschak]

I have a test that is failing on travis on a windows build due to the
presence of CRLF in the bytes returned by ioutil.ReadFile. The file
itself uses unix line endings, so the CR is inserted by something
somewhere along the line.

However, this is not always the case. On AppVeyor, I do not see this;
it passes using the same tests that pass on travis with linux,
returning only LF new lines.

Is there some reason by file reading on one windows build will behave
differently to another?

thanks
Dan

Logs showing behaviour:

Test code:
```
package crlf

import (
   "bytes"
   "io/ioutil"
   "testing"

   "github.com/kortschak/utter"
)

func TestReadFile(t *testing.T) {
   b, err := ioutil.ReadFile("crlf_test.go")
   if err != nil {
  t.Errorf("unexpected error: %v", err)
   }
   utter.Config.BytesWidth = 8
   dump := utter.Sdump(b)
   t.Log(dump)
   if bytes.Contains(b, []byte("\r\n")) {
  t.Errorf("unexpected CRLF in unix file: %s", dump)
   }
}
```

Failing test on Travis with windows:
=== RUN   TestReadFile
--- FAIL: TestReadFile (0.00s)
crlf_test.go:18: []uint8{
 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x20, // |package |
 0x63, 0x72, 0x6c, 0x66, 0x0d, 0x0a, 0x0d, 0x0a, // |crlf|
 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x20, 0x28, // |import (|
 0x0d, 0x0a, 0x09, 0x22, 0x62, 0x79, 0x74, 0x65, // |..."byte|
 0x73, 0x22, 0x0d, 0x0a, 0x09, 0x22, 0x69, 0x6f, // |s"..."io|
 0x2f, 0x69, 0x6f, 0x75, 0x74, 0x69, 0x6c, 0x22, // |/ioutil"|
 0x0d, 0x0a, 0x09, 0x22, 0x74, 0x65, 0x73, 0x74, // |..."test|
 0x69, 0x6e, 0x67, 0x22, 0x0d, 0x0a, 0x0d, 0x0a, // |ing"|
 0x09, 0x22, 0x67, 0x69, 0x74, 0x68, 0x75, 0x62, // |."github|
 0x2e, 0x63, 0x6f, 0x6d, 0x2f, 0x6b, 0x6f, 0x72, // |.com/kor|
 0x74, 0x73, 0x63, 0x68, 0x61, 0x6b, 0x2f, 0x75, // |tschak/u|
 0x74, 0x74, 0x65, 0x72, 0x22, 0x0d, 0x0a, 0x29, // |tter"..)|
 0x0d, 0x0a, 0x0d, 0x0a, 0x66, 0x75, 0x6e, 0x63, // |func|
 0x20, 0x54, 0x65, 0x73, 0x74, 0x52, 0x65, 0x61, // | TestRea|
 0x64, 0x46, 0x69, 0x6c, 0x65, 0x28, 0x74, 0x20, // |dFile(t |
 0x2a, 0x74, 0x65, 0x73, 0x74, 0x69, 0x6e, 0x67, // |*testing|
 0x2e, 0x54, 0x29, 0x20, 0x7b, 0x0d, 0x0a, 0x09, // |.T) {...|
 0x62, 0x2c, 0x20, 0x65, 0x72, 0x72, 0x20, 0x3a, // |b, err :|
 0x3d, 0x20, 0x69, 0x6f, 0x75, 0x74, 0x69, 0x6c, // |= ioutil|
 0x2e, 0x52, 0x65, 0x61, 0x64, 0x46, 0x69, 0x6c, // |.ReadFil|
 0x65, 0x28, 0x22, 0x63, 0x72, 0x6c, 0x66, 0x5f, // |e("crlf_|
 0x74, 0x65, 0x73, 0x74, 0x2e, 0x67, 0x6f, 0x22, // |test.go"|
 0x29, 0x0d, 0x0a, 0x09, 0x69, 0x66, 0x20, 0x65, // |)...if e|
 0x72, 0x72, 0x20, 0x21, 0x3d, 0x20, 0x6e, 0x69, // |rr != ni|
 0x6c, 0x20, 0x7b, 0x0d, 0x0a, 0x09, 0x09, 0x74, // |l {t|
 0x2e, 0x45, 0x72, 0x72, 0x6f, 0x72, 0x66, 0x28, // |.Errorf(|
 0x22, 0x75, 0x6e, 0x65, 0x78, 0x70, 0x65, 0x63, // |"unexpec|
 0x74, 0x65, 0x64, 0x20, 0x65, 0x72, 0x72, 0x6f, // |ted erro|
 0x72, 0x3a, 0x20, 0x25, 0x76, 0x22, 0x2c, 0x20, // |r: %v", |
 0x65, 0x72, 0x72, 0x29, 0x0d, 0x0a, 0x09, 0x7d, // |err)...}|
 0x0d, 0x0a, 0x09, 0x75, 0x74, 0x74, 0x65, 0x72, // |...utter|
 0x2e, 0x43, 0x6f, 0x6e, 0x66, 0x69, 0x67, 0x2e, // |.Config.|
 0x42, 0x79, 0x74, 0x65, 0x73, 0x57, 0x69, 0x64, // |BytesWid|
 0x74, 0x68, 0x20, 0x3d, 0x20, 0x38, 0x0d, 0x0a, // |th = 8..|
 0x09, 0x64, 0x75, 0x6d, 0x70, 0x20, 0x3a, 0x3d, // |.dump :=|
 0x20, 0x75, 0x74, 0x74, 0x65, 0x72, 0x2e, 0x53, // | utter.S|
 0x64, 0x75, 0x6d, 0x70, 0x28, 0x62, 0x29, 0x0d, // |dump(b).|
 0x0a, 0x09, 0x74, 0x2e, 0x4c, 0x6f, 0x67, 0x28, // |..t.Log(|
 0x64, 0x75, 0x6d, 0x70, 0x29, 0x0d, 0x0a, 0x09, // |dump)...|
 0x69, 0x66, 0x20, 0x62, 0x79, 0x74, 0x65, 0x73, // |if bytes|
 0x2e, 0x43, 0x6f, 0x6e, 0x74, 0x61, 0x69, 0x6e, // |.Contain|
 0x73, 0x28, 0x62, 0x2c, 0x20, 0x5b, 0x5d, 0x62, // |s(b, []b|
 0x79, 0x74, 0x65, 0x28, 0x22, 0x5c, 0x72, 0x5c, // |yte("\r\|
 0x6e, 0x22, 0x29, 0x29, 0x20, 0x7b, 0x0d, 0x0a, // |n")) {..|
 0x09, 0x09, 0x74, 0x2e, 0x45, 0x72, 0x72, 0x6f, // |..t.Erro|
 0x72, 0x66, 0x28, 0x22, 0x75, 0x6e, 0x65, 0x78, // |rf("unex|
 0x70, 0x65, 0x63, 0x74, 0x65, 0x64, 0x20, 0x43, // |pected C|
 0x52, 0x4c, 0x46, 0x20, 0x69, 0x6e, 0x20, 0x75, // |RLF in u|
 0x6e, 0x69, 0x78, 0x20, 0x66, 0x69, 0x6c, 0x65, // |nix file|
 0x3a, 0x20, 0x25, 0x73, 0x22, 0x2c, 0x20, 0x64, // |: %s", d|
 0x75, 0x6d, 0x70, 0x29, 0x0d, 0x0a, 0x09, 0x7d, // |ump)...}|
 0x0d, 0x0a, 0x7d, 0x0d, 0x0a, /* */ // |..}..|
}

crlf_test.go:20: unexpected CRLF in unix file: []uint8{
 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x20, // |package |
 0x63, 0x72, 0x6c, 0x66, 0x0d, 0x0a, 0x0d, 0x0a, // |crlf|

Re: [go-nuts] why does reading a file on windows add CRLF to unix line endings... sometimes?

[Dan Kortschak]

Solved. This is Travis being "helpful" and setting core.autocrlf=true
in git config.

https://travis-ci.community/t/files-in-checkout-have-eol-changed-from-l
f-to-crlf/349/4

On Tue, 2019-04-23 at 07:50 +0930, Dan Kortschak wrote:
> I have a test that is failing on travis on a windows build due to the
> presence of CRLF in the bytes returned by ioutil.ReadFile. The file
> itself uses unix line endings, so the CR is inserted by something
> somewhere along the line.
> 
> However, this is not always the case. On AppVeyor, I do not see this;
> it passes using the same tests that pass on travis with linux,
> returning only LF new lines.
> 
> Is there some reason by file reading on one windows build will behave
> differently to another?
> 
> thanks
> Dan
> 
> Logs showing behaviour:
> 
> Test code:
> ```
> package crlf
> 
> import (
>    "bytes"
>    "io/ioutil"
>    "testing"
> 
>    "github.com/kortschak/utter"
> )
> 
> func TestReadFile(t *testing.T) {
>    b, err := ioutil.ReadFile("crlf_test.go")
>    if err != nil {
>   t.Errorf("unexpected error: %v", err)
>    }
>    utter.Config.BytesWidth = 8
>    dump := utter.Sdump(b)
>    t.Log(dump)
>    if bytes.Contains(b, []byte("\r\n")) {
>   t.Errorf("unexpected CRLF in unix file: %s", dump)
>    }
> }
> ```
> 
> Failing test on Travis with windows:
> === RUN   TestReadFile
> --- FAIL: TestReadFile (0.00s)
> crlf_test.go:18: []uint8{
>  0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x20, // |package
> |
>  0x63, 0x72, 0x6c, 0x66, 0x0d, 0x0a, 0x0d, 0x0a, //
> |crlf|
>  0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x20, 0x28, // |import
> (|
>  0x0d, 0x0a, 0x09, 0x22, 0x62, 0x79, 0x74, 0x65, //
> |..."byte|
>  0x73, 0x22, 0x0d, 0x0a, 0x09, 0x22, 0x69, 0x6f, //
> |s"..."io|
>  0x2f, 0x69, 0x6f, 0x75, 0x74, 0x69, 0x6c, 0x22, //
> |/ioutil"|
>  0x0d, 0x0a, 0x09, 0x22, 0x74, 0x65, 0x73, 0x74, //
> |..."test|
>  0x69, 0x6e, 0x67, 0x22, 0x0d, 0x0a, 0x0d, 0x0a, //
> |ing"|
>  0x09, 0x22, 0x67, 0x69, 0x74, 0x68, 0x75, 0x62, //
> |."github|
>  0x2e, 0x63, 0x6f, 0x6d, 0x2f, 0x6b, 0x6f, 0x72, //
> |.com/kor|
>  0x74, 0x73, 0x63, 0x68, 0x61, 0x6b, 0x2f, 0x75, //
> |tschak/u|
>  0x74, 0x74, 0x65, 0x72, 0x22, 0x0d, 0x0a, 0x29, //
> |tter"..)|
>  0x0d, 0x0a, 0x0d, 0x0a, 0x66, 0x75, 0x6e, 0x63, //
> |func|
>  0x20, 0x54, 0x65, 0x73, 0x74, 0x52, 0x65, 0x61, // |
> TestRea|
>  0x64, 0x46, 0x69, 0x6c, 0x65, 0x28, 0x74, 0x20, // |dFile(t
> |
>  0x2a, 0x74, 0x65, 0x73, 0x74, 0x69, 0x6e, 0x67, //
> |*testing|
>  0x2e, 0x54, 0x29, 0x20, 0x7b, 0x0d, 0x0a, 0x09, // |.T)
> {...|
>  0x62, 0x2c, 0x20, 0x65, 0x72, 0x72, 0x20, 0x3a, // |b, err
> :|
>  0x3d, 0x20, 0x69, 0x6f, 0x75, 0x74, 0x69, 0x6c, // |=
> ioutil|
>  0x2e, 0x52, 0x65, 0x61, 0x64, 0x46, 0x69, 0x6c, //
> |.ReadFil|
>  0x65, 0x28, 0x22, 0x63, 0x72, 0x6c, 0x66, 0x5f, //
> |e("crlf_|
>  0x74, 0x65, 0x73, 0x74, 0x2e, 0x67, 0x6f, 0x22, //
> |test.go"|
>  0x29, 0x0d, 0x0a, 0x09, 0x69, 0x66, 0x20, 0x65, // |)...if
> e|
>  0x72, 0x72, 0x20, 0x21, 0x3d, 0x20, 0x6e, 0x69, // |rr !=
> ni|
>  0x6c, 0x20, 0x7b, 0x0d, 0x0a, 0x09, 0x09, 0x74, // |l
> {t|
>  0x2e, 0x45, 0x72, 0x72, 0x6f, 0x72, 0x66, 0x28, //
> |.Errorf(|
>  0x22, 0x75, 0x6e, 0x65, 0x78, 0x70, 0x65, 0x63, //
> |"unexpec|
>  0x74, 0x65, 0x64, 0x20, 0x65, 0x72, 0x72, 0x6f, // |ted
> erro|
>  0x72, 0x3a, 0x20, 0x25, 0x76, 0x22, 0x2c, 0x20, // |r: %v",
> |
>  0x65, 0x72, 0x72, 0x29, 0x0d, 0x0a, 0x09, 0x7d, //
> |err)...}|
>  0x0d, 0x0a, 0x09, 0x75, 0x74, 0x74, 0x65, 0x72, //
> |...utter|
>  0x2e, 0x43, 0x6f, 0x6e, 0x66, 0x69, 0x67, 0x2e, //
> |.Config.|
>  0x42, 0x79, 0x74, 0x65, 0x73, 0x57, 0x69, 0x64, //
> |BytesWid|
>  0x74, 0x68, 0x20, 0x3d, 0x20, 0x38, 0x0d, 0x0a, // |th =
> 8..|
>  0x09, 0x64, 0x75, 0x6d, 0x70, 0x20, 0x3a, 0x3d, // |.dump
> :=|
>  0x20, 0x75, 0x74, 0x74, 0x65, 0x72, 0x2e, 0x53, // |
> utter.S|
>  0x64, 0x75, 0x6d, 0x70, 0x28, 0x62, 0x29, 0x0d, //
> |dump(b).|
>  0x0a, 0x09, 0x74, 0x2e, 0x4c, 0x6f, 0x67, 0x28, //
> |..t.Log(|
>  0x64, 0x75, 0x6d, 0x70, 0x29, 0x0d, 0x0a, 0x09, //
> |dump)...|
>  0x69, 0x66, 0x20, 0x62, 0x79, 0x74, 0x65, 0x73, // |if
> bytes|
>  0x2e, 0x43, 0x6f, 0x6e, 0x74, 0x61, 0x69, 0x6e, //
> |.Contain|
>  0x73, 0x28, 0x62, 0x2c, 0x20, 0x5b, 0x5d, 0x62, // |s(b,
> []b|
>  0x79, 0x74, 0x65, 0x28, 0x22, 0x5c, 0x72, 0x5c, //
> |yte("\r\|
>  0x6e, 0x22, 0x29, 0x29, 0x20, 0x7b, 0x0d, 0x0a, // |n"))
> {..|
>  0x09, 0x09, 0x74, 0x2e, 0x45, 0x72, 0x72, 0x6f, //
> |..t.Erro|
>  0x72, 0x66, 0x28, 0x22, 0x75, 0x6e, 0x65, 0x78, //
> |rf("unex|
>  0x70, 0x65, 0x63, 0x74, 0x65, 0x64, 0x20, 0x43, // |pected
> C|
>  0x52, 0x4c, 0x46, 0x20, 0x69, 0x6e, 0x20, 0x75, 

Re: [go-nuts] Re: built-in alternative to bcrypt?

[Sam Whited]

On Mon, Apr 22, 2019, at 20:18, whitehexagon via golang-nuts wrote:
> Also good to know only what I'm using gets linked in, but then the
> size of 'hello world' is even more surprising.

That's because the runtime is being linked in. Go requires, among other
things, a garbage collector and goroutine scheduler. These things are
always linked in because you're always using them.

> The argon2 looks interesting, but it sounds like it could be very
> memory heavy. The code I'm porting is running on a PAAS/SAAS setup,
> and that might have cost implications exceeding the worth of my low
> value data. But I will also have a look then at the sha3 that was
> mentioned, now that I know the 'x' stuff is internally produced by the
> same team!

Being memory heavy is the point; you don't want a fast hash to protect
your users data or if the hashes ever get stolen it's much easier for an
attacker to brute force them. SHA3 is a great hash, but it is not
appropriate for password storage. Please don't put your users passwords
at risk just to lower your operating overhead.

> I get the impression from some of the info I'm going through, that
> since I'm running on hosted systems, which optionally also have
> encrypted file systems, that some of the brute force defense stuff
> might be less applicable?

This is not true. An encrypted filesystem only prevents your database
from being stolen by eg. someone coming into your datacenter and running
off with your hard disk. It is no substitute for storing passwords
correctly.

> ie unless the database is physically stolen from some nuclear bunker
> somewhere in the world, and decrypted, and my noddy system is deemed
> worth hacking, it's probably pretty safe already.

Please don't put your users passwords at risk because you think
something you've done is "good enough". Always follow password storage
best practices.

> So the main attack vector would be multiple login attempts, which I
> can detect fairly easily. for example, 5 failed logins and the account
> is locked...

That's one way, and you should be doing that. However, you are human and
will make mistakes so another attack vector is someone managing to dump
your database, or getting in some otherway and downloading it.

> I was also thinking in this case I could use a client side hash so
> that the backend system never see's a plain text password. I realise
> of course that the hash becomes the password, but at least the hosted
> environments would never see clear text before reaching my hosted hash
> stuff. ie clients that reuse 123456 for everything :)

This generally isn't necessary and probably doesn't add much since
you're not likely to have your passwords stolen out of memory. Just
follow industry standard best practices.

—Sam

-- 
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.

Re: [go-nuts] Re: built-in alternative to bcrypt?

[Tom Mitchell]

On Mon, Apr 22, 2019 at 1:18 PM whitehexagon via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks everyone, plenty more reading for me!
>


> The argon2 looks interesting, but it sounds like it could be very memory
> heavy.  The code I'm porting is running on a PAAS/SAAS setup, and that
> might have cost implications exceeding the worth of my low value data.
>

Try to not judge the value of your data as being low.
Store only hashed and salted passwords and data.
Passwords in the clear or stored in a lame or fragile manner is something
that gets negative and snarky press world wide.
Data at rest should be safe.
Revisions to update to a better solution might be hampered if you start out
thinking your data is low value and
success happens.

The size of a go program is likely darn close to the netsum memory
footprint of a C program and the resident set size
might be smaller with go.

Plan ahead.


-- 
   T o mM i t c h e l l

-- 
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.

[go-nuts] Is there a way to force to pass some function or error check when Debugging?

[hui zhang]

I am debugging a linux server program in local mac machine.
some code related to environment check , such as check mount point etc.

I want to pass this check ,   how ?

   - I try it set return error var to nil.  but it seems not working in 
   devel for now.
   - I imagine to mock function, but not sure how to do it when debugging.
   - I knew the convenient way is to change source code directly .   But 
   there is a lot of code to change .  I don't want to mess it up
   
any advice?

-- 
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.