Re: [go-nuts] Security issue in

[Lars Seipel]

On Fri, May 07, 2021 at 12:05:22AM -0700, christoph...@gmail.com wrote:

The issue for the security problem is here:
https://github.com/satori/go.uuid/issues/73


There is a CVE identifier for this security problem:
https://github.com/satori/go.uuid/issues/115
It is 3 years old and hasn't been resolved.


The latter statement appears to be incorrect. The bug in question is not
included in the latest tagged release as it was introduced at a later point.
In April 2018, commit 75cca53 ("Fix potential non-random UUIDs") fixed the bug
so master is not affected either.

--
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/YJXfRVnxMpFHXPXh%40horsthansen.slrz.net.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Lars Seipel]

On Sat, Nov 09, 2019 at 11:00:04AM -0600, Robert Engels wrote:

No. Because in the absence on a memory barrier the writes may not be flushed 
meaning you cannot reason about any value ever being changed.  atomics provide 
the memory barrier, but the mm still does not specify a “happens before” 
relationship (but without this they are fairly useless).


Visibility is implied by the definition of "no concurrent access".

This case is fully handled by the current memory model:

Also, if e1 does not happen before e2 and does not happen after e2, then 
we say that e1 and e2 happen concurrently.


[…]


That is, r is guaranteed to observe w if both of the following hold:

 1. w happens before r.
 2. Any other write to the shared variable v either happens before w or after r.

[https://golang.org/ref/mem#tmp_2]

--
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/20191110140757.GB83577%40horsthansen.slrz.net.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Lars Seipel]

On Fri, Nov 08, 2019 at 06:06:22AM -0600, Robert Engels wrote:

I think that is a bit unclear - even if they access different elements, if they 
ever access the same element even at different times , you need 
synchronization- it’s not only if the access the same element “concurrently”.


No, that seems wrong. If, for any two distinct accesses A and B, either 
A happens before B or B happens before A (i.e. there is no concurrent 
access), what would you need additional synchronization for? Access is 
already serialized.


-ls

--
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/20191109155103.GA83577%40horsthansen.slrz.net.

Re: [go-nuts] Re: Possible missing atomic load(s)/store(s) in runtime/chan.go?

[Lars Seipel]

On Sun, Aug 05, 2018 at 12:12:04PM -0700, Marvin Stenger wrote:
> And my point was, that a slow path protected with a lock surely can execute 
> concurrently with a fast path not protected by that lock. So for the fast 
> path implementation one has to know what one is doing and if reordering 
> issues are a concern or not or if there could even be real data races on 
> the shared resource if accessed non-atomically.

An additional piece of the puzzle is probably that this particular code
is distributed together with the compiler and thus is allowed to make
certain assumptions with regards to its behaviour.

Would it be correct for user code to do something similar and rely on it
to work across different Go implementations?

I don't think it's written down anywhere how atomic reads are supposed
to interact with non-atomic writes. But then, the same is true for
basically everything sync/atomic.

-- 
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] Please help me solve a bug with my licencing system!

[Lars Seipel]

On Thu, May 10, 2018 at 06:46:56PM -0700, ati...@mail.ccsf.edu wrote:
> Code: https://gist.github.com/seriousnerve/1830e77d3e2891b0a5b158c9fb02b37f

Are you sure you want to re-use the provided password as a salt value?
Sure, it's a software licensing system and no one expects it to be
super-secure but considering that the poor user's password is most
likely suffering from excessive re-use already, you might want to
rethink that choice.

-- 
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] How to fake os.Stdout in golang for testing?

[Lars Seipel]

On Sat, May 05, 2018 at 08:55:17AM -0700, mfriedenha...@gmail.com wrote:
> * Now in golang `os.Stdout` is an `*os.File` which is mostly a wrapper for 
> an OS specific file. 

You can always use os.Pipe to get an actual file descriptor to write to.

-- 
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: All Forms of Wishful Generics

[Lars Seipel]

On Sat, Feb 17, 2018 at 01:10:29AM -0800, dc0d wrote:
> There are other things too, that I would like to have in Go; like a faster 
> FFI/CGO, or safe packages by restricting features so that a Go package 
> cannot harm the hosting machine or application, like Safe Tcl 

Go already has a NaCl backend which might fit the bill. See
misc/nacl/README for how to set it up. It links to a design document
(https://golang.org/s/go13nacl) with some background.

-- 
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: Web Framework for Beginners

[Lars Seipel]

On Sun, Jan 28, 2018 at 01:08:57AM -0800, Florin Pățan wrote:
> And to prove how flawed your analogy with the Hello World vs extending a 
> distributed database is... When you start programming you barely understand 
> what fmt.Println() is, how would you expect someone that doesn't understand 
> that well to understand what net/http.ServeMux is, what it does, what an 
> URL path is, how those parameters in the URLs come in to play, why 
> something is in the path of the request and not in the query string, what's 
> a query string, how HTTP works, what's the web server response and so on. 
> For a newbie the following are questions that come up when facing with the 
> "Hello world": what's a function call, what's a package, why we have main, 
> what's the "entrypoint point" of an application and why we need on, what's 
> the exit code of an application, what does it mean to print on a screen, 
> what's a string, what do you mean by IO (because eventually someone slips 
> that into the explanation of "printing on the screen"), etc.

I don't expect them to understand it. That's kind of my point. A web
framework would have even more weird stuff on top of it to understand.
That's why you start small and try to become confident with that
"Hello, world!" first.

There's a reason most CS curricula have you take some basic operating
systems course before making you write concurrent network servers.

-- 
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: Web Framework for Beginners

[Lars Seipel]

On Thu, Jan 25, 2018 at 01:26:00PM -0800, Florin Pățan wrote:
> I'm not saying that we should be against recommending the standard library, 
> by all means, it's one of the best assets of the language. But maybe it's 
> time we should think about saying: Start with this framework, insert 
> framework name here, and then, as you gain more Go knowledge, or you are 
> curious about how it's done, look into these packages, insert collection of 
> packages here, and finally, do not discount the standard library, as it is 
> very powerful and it can do a lot out of the box without introducing 
> further dependencies into your code. 

We're talking about a beginning Go programmer that has yet to learn how
some of the more advanced parts of the language fit together properly.
Now, assuming that actually understanding your program is a goal (in
contrast to just bashing things together until they appear to do what
you want), importing a huge and complex framework doesn't seem very
helpful to me, for the same reasons you start learning programming with
"Hello, world!" and not by extending a distributed database engine.

-- 
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] Dangers of package renaming

[Lars Seipel]

On Sat, Dec 02, 2017 at 07:33:05AM -0800, Jonathan Hall wrote:
> I maintain an open-source Go package with a few dozen followers.  
> (github.com/flimzy/kivik)
> 
> I'm planning to transfer/rename the package to a new organization (new 
> package name to be: github.com/go-kivik/kivik).
> 
> I understand that GitHub will maintain a redirect from the old location to 
> the new one, so in theory, old imports will continue working.

This can be very intrusive for users of your package. Problems are wont
to occur as soon as there is code importing the package under different
names (actually turning them into distinct packages). This also applies
to code living in the same repo such as the "sub-packages" you mention.

If those are imported by another package in the same repo (using the new
name) and directly by users of your library as well (using the old
name), you'll end up with distinct packages and thus incompatible types,
a distinct set of package-level variables and so on.

You might be able to prevent some of that pain with a different
approach, by keeping the existing package alive but turning it into a
forwarder to the new package. Use type aliases for re-exporting types.

This is approximately what was done for the x/net/context package when
context was imported into the standard library. It only started to work
well once type aliases were available in Go.

-- 
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] what is x.exe in golang 1.9.1 sdk for windows? antiviruses complain

[Lars Seipel]

On Sat, Oct 14, 2017 at 12:36:42AM -0700, Igor Maznitsa wrote:
> the version for Linux, so the question what is the file? the Totalscan site 
> shows terrible result of scanning of the file for i386 

I especially like the "unsafe" and "malicious_confidence_100%" labels
these scanners give to trivial hello-world-style binaries you upload
there.

I have no idea how their heuristics work but they could drastically
improve on their false positive rate by replacing them with a coin toss.

-- 
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 2 suggestion - what dependencies included in a build?

[Lars Seipel]

On Thu, Aug 17, 2017 at 09:54:43AM -0700, Eric Johnson wrote:
> The compiler, at least, knows which packages were used to compile the
> source. Even absent additional metadata from something like Gopkg.lock, the
> compiler could still include info about the packages compiled into a
> binary. Knowing that something might be vulnerable - but not knowing the
> version from the executable - is still better than not knowing at all.

If the set of packages as described by their import paths is useful to
you, you already get that today by calling nm (or 'go tool nm') on the
binary.

The printed list of symbols should give you a pretty good idea about the
contents of a particular binary, just without explicit version
information.

-- 
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 2 suggestion - what dependencies included in a build?

[Lars Seipel]

On Tue, Aug 15, 2017 at 04:58:00PM -0700, 'Eric Johnson' via golang-nuts wrote:
> As I scan reports of vulnerable software, I'm concerned that it is 
> impossible to tell, from a Go binary, what was used to build that binary. 

A lot of projects are already doing this, if somewhat indirectly: they
put a git commit hash into the binary that includes their (in-repo)
vendor directory.

Should vendor fall out of fashion at some point, one can surely come up
with a different scheme. I don't see why this should be tied to a
possible Go 2, though. It's pretty much independent from the language.

Might be more appropriate to work on it in the context of dep. Could be
as simple as making sure that dep can emit the required information for
people to pick up during their build.

-- 
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] does Go memory model guarantee this program always prints 1?

[Lars Seipel]

On Thu, Jul 06, 2017 at 12:19:05PM -0700, T L wrote:
> 
> package main
> 
> import "fmt"
> import "sync/atomic"
> 
> func main() {
> var x int32
> atomic.AddInt32(&x, 1)
> fmt.Println(atomic.LoadInt32(&x))
> }

Sure.

> Within a single goroutine, the happens-before order is the order
> expressed by the program.
- https://golang.org/ref/mem

-- 
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] Errors from Gob

[Lars Seipel]

On Thu, Apr 27, 2017 at 08:55:36AM -0700, Chris Hopkins wrote:
> What's the current thinking on this sort of error handling? It's hard to 
> say "Handle errors properly" when the standard library is butchering the 
> original error message.

This most likely *is* the original error, as returned by your system.
It corresponds to the EHOSTDOWN error code and was apparently
encountered during a write system call.

The system call interface on Unix just doesn't give you any more than
this. You need to look up the conditions under which your system might
return that particular error code.

If you really think the message is bogus, you might want to compare the
errno-to-errstr mapping in package syscall against your local system
headers. This is going to depend on OS and arch, of course.

-- 
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: Feedback on naming issue when interface vs main code struct

[Lars Seipel]

On Sat, Mar 04, 2017 at 03:57:48PM -0800, mlg wrote:
> according to your rationale, I believe the case I'm referring to is when 
> the interface represents a domain object (e.g. Consumer). In such case, if 
> you don't plan on exporting your interface (therefore naming it 
> `consumer`), how would you name the implementing struct and why? If 
> possible, define a general rule. That's my question. Sorry if I wasn't 
> clear before.

Well, what is the defining characteristic that makes this type different
from other implementations of the same interface? That's how you should
approach the naming.

Example: you're dealing with some kind of data-shoveling pipe (interface
name: pipe). The networked variant is called netPipe while you use
memPipe for the in-memory version used in testing.

-- 
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] How to idiomatically display chained errors?

[Lars Seipel]

On Sat, Feb 04, 2017 at 12:08:20AM -0800, so.qu...@gmail.com wrote:
> The following would print out "ERROR: Foo() ERROR: Bar() ERROR: 
> stdlib.Func() something went wrong with this standard function call", which 
> feels obviously wrong.

Leave out the "ERROR" string as well as the gratuitous parens and you
get something like "foo: bar: open: file does not exist" which looks
almost reasonable.

-- 
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] About 64bits alignment

[Lars Seipel]

On Sat, Feb 04, 2017 at 01:30:49AM -0800, T L wrote:
> Get it. This is quite bug prone to write programs on 64bit OSes and the 
> programs are expected to run on 32bit OSes too.

Well, there's a reason the sync/atomic package docs have this statement
right at the top:

> These functions require great care to be used correctly. Except for special,
> low-level applications, synchronization is better done with channels or the
> facilities of the sync package.

-- 
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] package containing standard CA roots?

[Lars Seipel]

On Thu, Dec 15, 2016 at 04:35:09PM +, Alex Flint wrote:
> Does anyone know of a golang package that embeds (go-bindata or similar) a
> reasonable standard set of CA roots?

No, but the common approach is to rely on the root CA set maintained by
Mozilla.

This should correspond to the latest Firefox release:
https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt

You might want to check with your trusted distribution packager for some
scripts to convert this into a format that's nicer to work with.

See e.g. certdata2pem.py from Fedora or MAca-bundle.pl.in from
FreeBSD ports.

https://src.fedoraproject.org/cgit/rpms/ca-certificates.git/tree/
https://svnweb.freebsd.org/ports/head/security/ca_root_nss/files/

Or just use the ones from the binary packages and put them in the
appropriate places within the file system so that the standard library
will pick them up.

Of course, the usual things apply, like that you if you ship it
you're responsible for maintaining it, too. Regularly syncing with
Mozilla upstream should be enough in this case.

-- 
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] Working with characters in strings

[Lars Seipel]

On Mon, Oct 31, 2016 at 06:06:23PM +, 'Thomas Bushnell, BSG' via 
golang-nuts wrote:
> Strings are specified to be UTF8, so if you cast a string to []byte you
> will see its UTF8 representation.

They are not. A Go string may contain arbitrary bytes. Features like
for..range or conversions to rune slices won't be very useful then
(though still well-defined) but that's about it.

Go source text and thus string literals are UTF-8. You might be thinking
of those?

-ls

-- 
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: How to initialize all members of a slice

[Lars Seipel]

On Mon, Oct 03, 2016 at 04:19:34PM -0700, C Banning wrote:
> Lot's of people will jump up and down that this is "unsafe," but if you're 
> building a utility and have complete control of the code something like 
> this might work: https://play.golang.org/p/eDPoI83C0u

Not necessarily unsafe, just utterly pointless:
https://play.golang.org/p/s74gMIEyWZ

-- 
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] help with bazil.org/fuse

[Lars Seipel]

On Mon, Sep 05, 2016 at 12:47:51PM +0930, Dan Kortschak wrote:
> func (f *RW) Write(ctx context.Context, req *fuse.WriteRequest, resp 
> *fuse.WriteResponse) error {
>   f.mu.Lock()
>   defer f.mu.Unlock()
> 
>   f.mtime = f.fs.now()
> 
>   var err error
>   if req.FileFlags&fuse.OpenTruncate != 0 {
>   err = f.dev.Truncate(req.Offset)
>   if err != nil {
>   return err
>   }
>   }

These are just the flags passed to open. If you want to act on the
truncate flag, do it once within open, not on every single subsequent
call to write.

-- 
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: Is there a standard lib function which will return the count of characters in a string?

[Lars Seipel]

On Sat, Jul 23, 2016 at 08:36:03AM -0700, Tamás Gulácsi wrote:
> Yes, you have to normalize your String to be able to count the runes, and 
> have that be the count of characters.

That would only work if there was a precomposed form for every possible
combining character sequence, which is not the case.

There are more issues. I would just give up on the concept of a
"character count". It's unlikely to be what you need anyway.

-- 
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] Linking C dynamic library non-standard location

[Lars Seipel]

On Sat, Jul 16, 2016 at 02:10:38PM -0700, dan...@basereality.com wrote:
> Do you know if it's possible to set this option in an environment variable, 
> so that it isn't needed to be passed on each command line operation?

Ian mentioned another way to achieve your goal: add the directory to the
list of paths the runtime linker is looking for libraries. On CentOS
(and most other Linux systems, too) there's a directory
/etc/ld.so.conf.d where you can drop a snippet listing your path on a
single line. Alternatively, you can put it in the LD_LIBRARY_PATH
environment variable.

Note that these are knobs for controlling runtime behaviour. They need
to be in place when you run the program, not when compiling.

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