[go-nuts] Go 1.21 Release Candidate 2 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.21rc2, a release candidate version of Go 1.21.
It is cut from release-branch.go1.21 at the revision tagged go1.21rc2.
(An earlier revision was tagged go1.21rc1, but a bug found
after tagging prevented its release process from completing.)

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://go.dev/issue/new

If you have Go installed already, an easy way to try go1.21rc2
is by using the go command:
$ go install golang.org/dl/go1.21rc2@latest
$ go1.21rc2 download

You can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.21rc2

To find out what has changed in Go 1.21, read the draft release notes:
https://tip.golang.org/doc/go1.21

Cheers,
Dmitri and Michael for 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-PGOBzbrGLvoSaeN_Ce71w5TyrDGiwz%3DaWXsjhAmNNUJCQ%40mail.gmail.com.

[go-nuts] Re: why no archive distribution for darwin 1.20.1?

[Dmitri Shuralyov]

The .tar.gz files are there as usual. They didn't show earlier up due to a 
caching bug on the download page (https://go.dev/issue/58527). Thanks for 
spotting this.

On Tuesday, February 14, 2023 at 1:51:57 PM UTC-5 m...@xoba.com wrote:

> on https://go.dev/dl/ i only see the packaged version this time: 
> go1.20.1.darwin-amd64.pkg
>
> whereas historically there have been targz versions as well, such as 
> go1.20.darwin-amd64.tar.gz last time.
>
> the targz's are useful to me for controlling and augmenting/customizing 
> the installation.
>
> 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/ce6bdc0f-9b27-4e97-b751-a7507f64caf5n%40googlegroups.com.

Re: [go-nuts] [security] Go 1.18.3 and Go 1.17.11 are released

[Dmitri Shuralyov]

Hi Jakob,

The go-gettable golang.org/dl/go1.18.3 command is published and might take 
a moment to propagate.
You can either try again in a short while, or do something like 'go install 
golang.org/dl/go1.18.3@HEAD'.
(The '@HEAD' suffix is one of the ways to explicitly request that 
particular git revision.)

For questions about the Docker images published 
at https://hub.docker.com/_/golang, you'll want to
contact their maintainers linked at the top of the quick reference section. 
It's reasonable to expect
they'll show up soon now that this Go release is published.

Thanks,
Dmitri

On Wednesday, June 1, 2022 at 5:12:53 PM UTC-4 ja...@kastelo.net wrote:

> On 1 Jun 2022, at 22:58, Dmitri Shuralyov  wrote:
>
>
> Hello gophers,
>
> We have just released Go versions 1.18.3 and 1.17.11, minor point releases.
>
> These minor releases include 4 security fixes following the security 
> policy <https://go.dev/security>:
>
>
> Hi Dmitry,
>
> Thanks for this and the notification. However, there does not appear to 
> exist a golang:1.18.3 Docker image, or a go-gettable 
> golang.org/dl/go1.18.3 yet. Are those part of the release, do you know 
> when they will be available?
>
> Best regards,
> Jakob
>
>

-- 
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/f9c9049a-b919-4d74-b943-8aa12332aab9n%40googlegroups.com.

[go-nuts] [security] Go 1.18.3 and Go 1.17.11 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.18.3 and 1.17.11, minor point releases.

These minor releases include 4 security fixes following the security policy
:

   - crypto/rand: rand.Read hangs with extremely large buffers

   On Windows, rand.Read will hang indefinitely if passed a buffer larger
   than 1 << 32 - 1 bytes.

   Thanks to Davis Goodin and Quim Muntal, working at Microsoft on the Go
   toolset, for reporting this issue.

   This is CVE-2022-30634 and Go issue https://go.dev/issue/52561.


   - crypto/tls: session tickets lack random ticket_age_add

   Session tickets generated by crypto/tls did not contain a randomly
   generated ticket_age_add. This allows an attacker that can observe TLS
   handshakes to correlate successive connections by comparing ticket ages
   during session resumption.

   Thanks to GitHub user @nervuri for reporting this.

   This is CVE-2022-30629 and Go issue https://go.dev/issue/52814.


   - os/exec: empty Cmd.Path can result in running unintended binary on
   Windows

   If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
   are executed when Cmd.Path is unset and, in the working directory, there
   are binaries named either "..com" or "..exe", they will be executed.

   Thanks to Chris Darroch (chrisd8...@github.com), brian m. carlson (
   bk2...@github.com), and Mikhail Shcherbakov (https://twitter.com/yu5k3)
   for reporting this.

   This is CVE-2022-30580 and Go issue https://go.dev/issue/52574.


   - path/filepath: Clean(`.\c:`) returns `c:` on Windows

   On Windows, the filepath.Clean function could convert an invalid path to
   a valid, absolute path. For example, Clean(`.\c:`) returned `c:`.

   Thanks to Unrud for reporting this issue.

   This is CVE-2022-29804 and Go issue https://go.dev/issue/52476.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.minor

You can download binary and source distributions from the Go web site:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.18.3" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri and Alex for 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-PGhdJhuxrZ_CBmmXyZQTtxZtAT6mV_pi9QMCU%2BNV%2B3zzA%40mail.gmail.com.

[go-nuts] [security] Go 1.18.1 and Go 1.17.9 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.18.1 and 1.17.9, minor point releases.

These minor releases include three security fixes following the security
policy:

   - encoding/pem: fix stack overflow in Decode

   A large (more than 5 MB) PEM input can cause a stack overflow in Decode,
   leading the program to crash.

   Thanks to Juho Nurminen of Mattermost who reported the error.

   This is CVE-2022-24675 and https://go.dev/issue/51853.


   - crypto/elliptic: tolerate all oversized scalars in generic P-256

   A crafted scalar input longer than 32 bytes can cause P256().ScalarMult
   or P256().ScalarBaseMult to panic. Indirect uses through crypto/ecdsa and
   crypto/tls are unaffected. amd64, arm64, ppc64le, and s390x are unaffected.

   This was discovered thanks to a Project Wycheproof test vector.

   This is CVE-2022-28327 and https://go.dev/issue/52075.


   - crypto/x509: non-compliant certificates can cause a panic in Verify on
   macOS in Go 1.18

   Verifying certificate chains containing certificates which are not
   compliant with RFC 5280 causes Certificate.Verify to panic on macOS.

   These chains can be delivered through TLS and can cause a crypto/tls or
   net/http client to crash.

   Thanks to Tailscale for doing weird things and finding this.

   This is CVE-2022-27536 and https://go.dev/issue/51759.


View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.minor

You can download binary and source distributions from the Go web site:
https://go.dev/dl/

macOS binary artifacts for Go 1.18.1 are not available at this time due to
an issue .
We are working on providing them as soon as possible. Sorry for the
inconvenience.

To compile from source using a Git clone, update to the release with
"git checkout go1.18.1" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri and Cherry for 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-PEbbu0NvmmE1-g5C_fV3rjaxiwCXyFf43i2eBYek2BoPg%40mail.gmail.com.

[go-nuts] Go 1.18 Release Candidate 1 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.18rc1, a release candidate version of Go 1.18.
It is cut from release-branch.go1.18 at the revision tagged go1.18rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://go.dev/issue/new

If you have Go installed already, the easiest way to try go1.18rc1
is by using the go command:
$ go install golang.org/dl/go1.18rc1@latest
$ go1.18rc1 download

You can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.18rc1

To find out what has changed in Go 1.18, read the draft release notes:
https://tip.golang.org/doc/go1.18

Cheers,
Dmitri and Heschi for 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-PGnK8H5rgbm3Z%3DAXqTHGa%3DMeDZt4exTTej7KjxRmFK4fA%40mail.gmail.com.

[go-nuts] [security] Go 1.16.6 and Go 1.15.14 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.16.6 and 1.15.14, minor point releases.

These minor releases include a security fix according to the new security
policy (#44918 ).

crypto/tls clients can panic when provided a certificate of the wrong type
for the negotiated parameters.
net/http clients performing HTTPS requests are also affected. The panic can
be triggered by an attacker
in a privileged network position without access to the server certificate's
private key, as long as a trusted
ECDSA or Ed25519 certificate for the server exists (or can be issued), or
the client is configured with
Config.InsecureSkipVerify. Clients that disable all TLS_RSA cipher suites
(that is, TLS 1.0–1.2 cipher
suites without ECDHE), as well as TLS 1.3-only clients, are unaffected.


This is issue #47143  and CVE-2021-34558.
Thanks to Imre Rad for reporting this issue.


View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.16.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.16.6" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri, Filippo, and Alex for 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-PEUzhZ_F6yWyoBt%2BBc_sVgZ3JqHOGTN%2B4Qv5y1DNKC6JQ%40mail.gmail.com.

[go-nuts] Go 1.17 Beta 1 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.17beta1, a beta version of Go 1.17.
It is cut from the master branch at the revision tagged go1.17beta1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.17beta1
is by using the go command:
$ go get golang.org/dl/go1.17beta1
$ go1.17beta1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.17beta1

To find out what has changed in Go 1.17, read the draft release notes:
https://tip.golang.org/doc/go1.17

Cheers,
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-PHvYWX9ftPvdERcuW9eYtXCTPw0jsGT8uKqdcHUwKY9Hg%40mail.gmail.com.

[go-nuts] Go 1.16.3 and Go 1.15.11 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.16.3 and 1.15.11, minor point releases.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.16.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.16.3" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Carlos, David, Dmitri and Alex for 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-PGLCU5Ln4QiosvNULh-MPejG_-B-pFPf-5pWVBGy1DLEA%40mail.gmail.com.

Re: [go-nuts] possible inconsistency in the embed package documentation

[Dmitri Shuralyov]

> Consider the case where example.com/m1/nested is not a separate module.
> Due to the rule of "Patterns must not contain ‘.’ or ‘..’ path elements", 
the nested package can not embed, as an example, the LICENSE file from the 
example.com/m1 package.
> The LICENSE file is not outside the nested package module, so I'm 
interested to know why it is not allowed, since this can prevent the 
sharing of files between packages in the same module.

That's a good question. I'm interested in knowing this too.

In 
https://go.googlesource.com/proposal/+/master/design/draft-embed.md#dot_dot_module-boundaries_and-file-name-restrictions,
 
it says:

> In order to build files embedded in a dependency, the raw files 
themselves must be included in module zip files. This implies that any 
embedded file must be in the module’s own file tree. It cannot be in a 
parent directory above the module root (like ../../../etc/passwd), it 
cannot be in a subdirectory that contains a different module, and it cannot 
be in a directory that would be left out of the module (like .git).

That paragraph doesn't mention files in a parent directory within the 
module root.

On Sunday, January 17, 2021 at 6:05:38 AM UTC-5 manlio@gmail.com wrote:

> Thanks for the clarification.  The goal was to understand the embedding 
> better.
>
> I have another question.
> Consider the case where example.com/m1/nested is not a separate module.
> Due to the rule of "Patterns must not contain ‘.’ or ‘..’ path elements", 
> the nested package can not embed, as an example, the LICENSE file from the 
> example.com/m1 package.
> The LICENSE file is not outside the nested package module, so I'm 
> interested to know why it is not allowed, since this can prevent the 
> sharing of files between packages in the same module.
>
> Was the alternate design of assuming embedded file paths relative to the 
> module root directory considered?
>
> Thanks
> Manlio
>
> Il giorno sabato 16 gennaio 2021 alle 21:45:26 UTC+1 dmit...@golang.org 
> ha scritto:
>
>> It gets pretty subtle. The ".git" directories aren't included in module 
>> zips by the go command (I don't know if this is documented anywhere, but 
>> it's very sensible behavior), but they aren't disallowed. A custom module 
>> zip may include a ".foo", "_foo", or even ".git" directory with files.
>>
>> In the the phrase you mentioned:
>>
>> > Patterns must not match files outside the package's module, such as 
>> ‘.git/*’ or symbolic links
>>
>> Symbolic links are neither included not allowed.
>> .git/* files aren't included by the go tool.
>>
>> As I understand, the "such as ‘.git/*’ or symbolic links" part is just an 
>> example of some common types of files that aren't included in modules. The 
>> important part of that phrase is "Patterns must not match files outside the 
>> package's module". For example, if you have this tree:
>>
>> $ tree .
>> .
>> ├── LICENSE
>> ├── go.mod // module example.com/m1
>> ├── p.go
>> ├── p_test.go
>> └── nested
>> ├── go.mod // example.com/m1/nested
>> ├── foo.txt
>> └── ...
>>
>> Then p.go can't embed "nested/foo.txt", because nested/foo.txt is going 
>> to be outside of the m1 module.
>>
>> If you're looking to improve package embed documentation, I suggest 
>> filing an issue . If your goal to 
>> understand this better for your own interests, I hope you find the nuanced 
>> details above interesting. :)
>> On Saturday, January 16, 2021 at 3:23:32 PM UTC-5 manlio@gmail.com 
>> wrote:
>>
>>> https://golang.org/ref/mod#zip-path-size-constraints prevents 
>>> directories that begin with a dot, but only because the directory is 
>>> interpreted as a package.
>>> It is not clear, to me, if `.git` is ignored by the `embed` directive 
>>> because it is the private directory of the VCS or because it starts with a 
>>> dot.
>>>
>>>
>>> Thanks
>>> Manlio Perillo
>>> Il giorno sabato 16 gennaio 2021 alle 21:09:08 UTC+1 
>>> axel.wa...@googlemail.com ha scritto:
>>>
 I think this is the best doc about what is included in a module:
 https://golang.org/ref/mod#zip-path-size-constraints
 Everything not in that list is "outside" that module.

 On Sat, Jan 16, 2021 at 9:02 PM Manlio Perillo  
 wrote:

> Thanks. I was only considering the parent of the  module's root 
> directory.
> Is the concept of "outside the module" defined somewhere? 
>
> Manlio Perillo
>
> Il giorno sabato 16 gennaio 2021 alle 19:30:05 UTC+1 
> axel.wa...@googlemail.com ha scritto:
>
>> To put it another way:
>>
>> The second phrase is a lexical requirement about the pattern. It must 
>> not contain a . or .. element - whether or not the result is included in 
>> the module (e.g. "foo/../foo/bar" is not allowed either, even though 
>> it's 
>> equivalent to "foo/bar").
>>
>> But, a lexical path *in* the module might still refer to a file not 
>> included in it it - 

Re: [go-nuts] possible inconsistency in the embed package documentation

[Dmitri Shuralyov]

It gets pretty subtle. The ".git" directories aren't included in module 
zips by the go command (I don't know if this is documented anywhere, but 
it's very sensible behavior), but they aren't disallowed. A custom module 
zip may include a ".foo", "_foo", or even ".git" directory with files.

In the the phrase you mentioned:

> Patterns must not match files outside the package's module, such as 
‘.git/*’ or symbolic links

Symbolic links are neither included not allowed.
.git/* files aren't included by the go tool.

As I understand, the "such as ‘.git/*’ or symbolic links" part is just an 
example of some common types of files that aren't included in modules. The 
important part of that phrase is "Patterns must not match files outside the 
package's module". For example, if you have this tree:

$ tree .
.
├── LICENSE
├── go.mod // module example.com/m1
├── p.go
├── p_test.go
└── nested
├── go.mod // example.com/m1/nested
├── foo.txt
└── ...

Then p.go can't embed "nested/foo.txt", because nested/foo.txt is going to 
be outside of the m1 module.

If you're looking to improve package embed documentation, I suggest filing 
an issue . If your goal to understand this 
better for your own interests, I hope you find the nuanced details above 
interesting. :)
On Saturday, January 16, 2021 at 3:23:32 PM UTC-5 manlio@gmail.com 
wrote:

> https://golang.org/ref/mod#zip-path-size-constraints prevents directories 
> that begin with a dot, but only because the directory is interpreted as a 
> package.
> It is not clear, to me, if `.git` is ignored by the `embed` directive 
> because it is the private directory of the VCS or because it starts with a 
> dot.
>
>
> Thanks
> Manlio Perillo
> Il giorno sabato 16 gennaio 2021 alle 21:09:08 UTC+1 
> axel.wa...@googlemail.com ha scritto:
>
>> I think this is the best doc about what is included in a module:
>> https://golang.org/ref/mod#zip-path-size-constraints
>> Everything not in that list is "outside" that module.
>>
>> On Sat, Jan 16, 2021 at 9:02 PM Manlio Perillo  
>> wrote:
>>
>>> Thanks. I was only considering the parent of the  module's root 
>>> directory.
>>> Is the concept of "outside the module" defined somewhere? 
>>>
>>> Manlio Perillo
>>>
>>> Il giorno sabato 16 gennaio 2021 alle 19:30:05 UTC+1 
>>> axel.wa...@googlemail.com ha scritto:
>>>
 To put it another way:

 The second phrase is a lexical requirement about the pattern. It must 
 not contain a . or .. element - whether or not the result is included in 
 the module (e.g. "foo/../foo/bar" is not allowed either, even though it's 
 equivalent to "foo/bar").

 But, a lexical path *in* the module might still refer to a file not 
 included in it it - either by a symlink, or by being in the .git directory 
 (and maybe other cases I'm unaware of). So, the first phrase excludes any 
 case where the file is not included the module, whether or not the name 
 you 
 refer it by lexically contains . or '..'.

 Both phrases are necessary.

 On Sat, Jan 16, 2021 at 7:24 PM Axel Wagner  
 wrote:

> I don't think they do. There are two examples in the first phrase, 
> which are not excluded by the second - the ".git" directory and a 
> symbolic 
> link (pointing outside of the module).
>
> On Sat, Jan 16, 2021 at 7:11 PM Manlio Perillo  
> wrote:
>
>> I'm reading the https://tip.golang.org/pkg/embed/ package 
>> documentation and I found a possible inconsistency.
>>
>> At the end of https://tip.golang.org/pkg/embed/#hdr-Directives:
>> "Patterns must not match files outside the package's module, such as 
>> ‘.git/*’ or symbolic links"
>> and
>> "Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a 
>> leading slash"
>>
>> It seems to me that the first phrase is not necessary, since the 
>> second phrase prevents matching files outside the package module.
>>
>>
>> Thanks
>> Manlio Perillo
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5e1d688e-cdb4-4b32-a06a-086a6b097064n%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> 

Re: [go-nuts] possible inconsistency in the embed package documentation

[Dmitri Shuralyov]

Directories named testdata are included in the module; they're needed for 
tests to run. The most important thing that's left out are subdirectories 
that contain a go.mod file, since the content of such directories is a 
different module.

Some good places to look for full details include 
https://golang.org/ref/mod#zip-path-size-constraints and 
https://pkg.go.dev/golang.org/x/mod/zip.

On Saturday, January 16, 2021 at 3:04:58 PM UTC-5 manlio@gmail.com 
wrote:

> As an example: is testdata outside the package's module?
>
> Thanks
> Manlio
> Il giorno sabato 16 gennaio 2021 alle 21:02:25 UTC+1 Manlio Perillo ha 
> scritto:
>
>> Thanks. I was only considering the parent of the  module's root directory.
>> Is the concept of "outside the module" defined somewhere? 
>>
>> Manlio Perillo
>>
>> Il giorno sabato 16 gennaio 2021 alle 19:30:05 UTC+1 
>> axel.wa...@googlemail.com ha scritto:
>>
>>> To put it another way:
>>>
>>> The second phrase is a lexical requirement about the pattern. It must 
>>> not contain a . or .. element - whether or not the result is included in 
>>> the module (e.g. "foo/../foo/bar" is not allowed either, even though it's 
>>> equivalent to "foo/bar").
>>>
>>> But, a lexical path *in* the module might still refer to a file not 
>>> included in it it - either by a symlink, or by being in the .git directory 
>>> (and maybe other cases I'm unaware of). So, the first phrase excludes any 
>>> case where the file is not included the module, whether or not the name you 
>>> refer it by lexically contains . or '..'.
>>>
>>> Both phrases are necessary.
>>>
>>> On Sat, Jan 16, 2021 at 7:24 PM Axel Wagner  
>>> wrote:
>>>
 I don't think they do. There are two examples in the first phrase, 
 which are not excluded by the second - the ".git" directory and a symbolic 
 link (pointing outside of the module).

 On Sat, Jan 16, 2021 at 7:11 PM Manlio Perillo  
 wrote:

> I'm reading the https://tip.golang.org/pkg/embed/ package 
> documentation and I found a possible inconsistency.
>
> At the end of https://tip.golang.org/pkg/embed/#hdr-Directives:
> "Patterns must not match files outside the package's module, such as 
> ‘.git/*’ or symbolic links"
> and
> "Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a 
> leading slash"
>
> It seems to me that the first phrase is not necessary, since the 
> second phrase prevents matching files outside the package module.
>
>
> Thanks
> Manlio Perillo
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5e1d688e-cdb4-4b32-a06a-086a6b097064n%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/9cb4c2fe-b5c4-4a92-ad17-473d951864d9n%40googlegroups.com.

[go-nuts] Re: possible inconsistency in the embed package documentation

[Dmitri Shuralyov]

I think both are needed, they don't overlap. Note that the second phrase 
says "must not contain '.' or '..' path *elements*", emphasis them being a 
complete path element. So "./git" is disallowed by the second phrase, but 
".git" is not.

On Saturday, January 16, 2021 at 1:10:47 PM UTC-5 manlio@gmail.com 
wrote:

> I'm reading the https://tip.golang.org/pkg/embed/ package documentation 
> and I found a possible inconsistency.
>
> At the end of https://tip.golang.org/pkg/embed/#hdr-Directives:
> "Patterns must not match files outside the package's module, such as 
> ‘.git/*’ or symbolic links"
> and
> "Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a 
> leading slash"
>
> It seems to me that the first phrase is not necessary, since the second 
> phrase prevents matching files outside the package module.
>
>
> Thanks
> Manlio Perillo
>

-- 
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/1d1d6449-da69-4600-9d40-ad35e8f4c17en%40googlegroups.com.

[go-nuts] Go 1.15.2 and Go 1.14.9 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.15.2 and 1.14.9, minor point releases.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.15.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.15.2" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri and Alex for 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-PGaP5Q_LsdRsHANqQaFFPYF1-Cjv5NYqAptMq4Vvvsd3Q%40mail.gmail.com.

[go-nuts] Go 1.14.4 and Go 1.13.12 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.14.4 and 1.13.12, minor point releases.

These releases include fixes to the go doc command, the runtime, and
the encoding/json, go/types, math/big, and os packages.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.14.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.14.4" and build as usual.

Thanks to everyone who contributed to the release.

Cheers,
Dmitri and Andy for 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-PG7Mp3oSXFPc_Bigf%3DD3JcF0jmJ_EqRkcGFR%2BSzpnUYWw%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14.1 and Go 1.13.9 are released

[Dmitri Shuralyov]

To add to what Ian said, I've edited the issue titles now, which makes them 
slightly shorter and easier to read.

Also see https://golang.org/doc/faq#go_or_golang. While the language is 
called "Go", the term "golang" still comes up occasionally in some contexts.


On Thursday, March 19, 2020 at 5:12:41 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Mar 19, 2020 at 1:58 PM Manlio Perillo  
> wrote: 
> > 
> > Thanks for the release. 
> > 
> > However I'm a bit sad that even the Go team is starting to use "golang" 
> instead of "go": 
> > https://github.com/golang/go/issues/37613 
> > golang 1.14.rc1 3-5% performance regression from golang 1.13 during 
> protobuf marshalling 
>
> Don't worry, we aren't.  That issue was created by gopherbot, and the 
> title came from https://golang.org/issue/37086, which was not written 
> by a member of the Go team.  All we've done here is not edit the issue 
> title (which we could have done but I guess nobody bothered). 
>
> Ian 
>
>
>
> > Now I see golang instead of go on blog articles, talks and commit 
> messages. 
> > 
> > Manlio 
> > 
> > On Thursday, March 19, 2020 at 9:48:28 PM UTC+1, Carlos Amedee wrote: 
> >> 
> >> Hello gophers, 
> >> 
> >> We have just released Go versions 1.14.1 and 1.13.9, minor point 
> releases. 
> >> 
> >> These releases include fixes to the go command, tools, the runtime, 
> >> the toolchain, and to the crypto/cypher package. 
> >> 
> >> View the release notes for more information: 
> >> https://golang.org/doc/devel/release.html#go1.14.minor 
> >> 
> >> You can download binary and source distributions from the Go web site: 
> >> https://golang.org/dl/ 
> >> 
> >> To compile from source using a Git clone, update to the release with 
> >> "git checkout go1.14.1" and build as usual. 
> >> 
> >> Thanks to everyone who contributed to the release. 
> >> 
> >> Cheers, 
> >> Carlos and Alex for 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/e541681f-df37-4181-bf4f-52b2d6193c60%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/c0d3c3bc-84a5-41b9-93e4-0752e54543e5%40googlegroups.com.

[go-nuts] Re: godoc.org - Internal server error

[Dmitri Shuralyov]

Thanks for reporting. There's a GitHub issue tracking this, see 
https://github.com/golang/go/issues/36642#issuecomment-576044533.


On Sunday, January 19, 2020 at 12:47:33 PM UTC-5, Steven Hartland wrote:
>
> Looks like somethings wrong with godoc.org atm, not sure who maintains 
> this as every page just errors for me ATM, hence reaching out here in 
> the hope someone who does reads this list. 
>
> An example is accessing: https://godoc.org/github.com/spf13/pflag 
> Internal server error. 
>

-- 
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/c2c6286a-3431-4f3d-99a1-a1de88ecf5c3%40googlegroups.com.

[go-nuts] godoc (golang.org/x/tools/cmd/godoc) has become module-aware

[Dmitri Shuralyov]

Hello gophers,

godoc , the local web server that
displays documentation for Go packages (not to be confused with
https://godoc.org, the website), has been updated with support for Go
modules. (This was issue 33655 .)

Module-aware mode is enabled whenever it would be enabled for the go
command. That is, module mode is enabled when a go.mod file
 is found in, or in a
parent of, the directory where you run the godoc command. Documentation is
displayed for packages in the build list
, which
includes the main module and its dependencies. Environment variables
 such as GO111MODULE,
GOPRIVATE, GOPROXY that control the behavior of the go command also affect
godoc.

As a reminder, the godoc command is no longer included in the binary
distribution as of Go 1.13 . You can
install the latest version from its source at golang.org/x/tools/cmd/godoc.

If you run into unexpected problems, please let us know by leaving a
comment on issue 33655 , filing a new issue
, or
replying to this thread.

Thanks,
Dmitri

-- 
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-PFnPJiuAkO0eNruWwu0-atG2%2B-VqQ%3DyXSR%2BO5bV2FdXFQ%40mail.gmail.com.

[go-nuts] Go 1.13 is released

[Dmitri Shuralyov]

Hello gophers,

We just released Go 1.13.

You can read the announcement blog post here:
https://blog.golang.org/go1.13

You can download binary and source distributions from our download page:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.13" and build as usual.

To find out what has changed in Go 1.13, read the release notes:
https://golang.org/doc/go1.13

Thanks to everyone who contributed to the release!

Cheers,
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-PFxvP7gvLqVkWoP-vpTE-TXwAaLEbxSsSyeGgDxB0vkPw%40mail.gmail.com.

[go-nuts] Go 1.12.9 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go version 1.12.9, a minor point release.

This release includes fixes to the linker, and the os and math/big packages.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.12.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.12.9" and build as usual.

Thanks to everyone who contributed to the release.

Cheers,
Dmitri for 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-PELTdkKY7FZ7TqrJr21m2o1mBkua_NLwki_xrHm2Kzq7A%40mail.gmail.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] Go 1.12.6 and Go 1.11.11 are released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go versions 1.12.6 and 1.11.11, minor point releases.

These releases include fixes to the compiler, the linker, the go command,
and the crypto/x509, net/http, and os packages.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.12.minor
https://golang.org/doc/devel/release.html#go1.11.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile Go 1.12.6 from source using a Git clone, update to the release
with "git checkout go1.12.6" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Dmitri for 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-PGiP8mGkym5nwXCT-o0LgzhWu1sc%3DpsDLAHXKwPSeybMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go 1.12 Beta 2 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.12beta2, a beta version of Go 1.12.
It is cut from the master branch at the revision tagged go1.12beta2.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.12beta2
is by using the go command:
$ go get golang.org/dl/go1.12beta2
$ go1.12beta2 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.12beta2

To find out what has changed in Go 1.12, read the draft release notes:
https://tip.golang.org/doc/go1.12

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

[go-nuts] [security] Go 1.11.3 and Go 1.10.6 are released

[Dmitri Shuralyov]

Hi gophers,

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

   - cmd/go: remote command execution during "go get -u"
   The issue is CVE-2018-16873 and Go issue golang.org/issue/29230. See the
   Go issue for details.
   Thanks to Etienne Stalmans from the Heroku platform security team for
   discovering and reporting this issue.


   - cmd/go: directory traversal in "go get" via curly braces in import
   paths
   The issue is CVE-2018-16874 and Go issue golang.org/issue/29231. See the
   Go issue for details.
   Thanks to ztz of Tencent Security Platform for discovering and reporting
   this issue.


   - crypto/x509: CPU denial of service in chain validation
   The issue is CVE-2018-16875 and Go issue golang.org/issue/29233. See the
   Go issue for details.
   Thanks to Netflix for discovering and reporting this issue.

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

We are aware of a functionality regression in "go get" when executed in
GOPATH mode on an import path pattern containing "..." (e.g., "go get
github.com/golang/pkg/..."), when downloading packages not already present
in the GOPATH workspace. This is issue golang.org/issue/29241. It will be
resolved in the next minor patch releases, Go 1.11.4 and Go 1.10.7, which
we plan to release soon. We apologize for any disruption.

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

[go-nuts] Re: [security] Go 1.11.3 and Go 1.10.6 pre-announcement

[Dmitri Shuralyov]

Hello gophers,

The release is still in progress. For today, we are now outside the time
window in which we are comfortable completing it.

No details of the security issue have been made public yet, so we are
rescheduling the release for tomorrow, Thursday, December 13 at
approximately 8 pm UTC (12 pm PST, 3 pm EST).

Thanks,
Dmitri on behalf of the Go team


On Fri, Dec 7, 2018 at 2:08 PM Dmitri Shuralyov  wrote:

> Hello gophers,
>
> We plan to issue Go 1.11.3 and Go 1.10.6 on Wednesday, December 12 at
> approximately 8 pm UTC (12 pm PST, 3 pm EST). These are minor releases to
> fix a security issue.
>
> Following our policy at https://golang.org/security, this is the
> pre-announcement of those releases.
>
> Thanks,
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [security] Go 1.11.3 and Go 1.10.6 pre-announcement

[Dmitri Shuralyov]

Hello gophers,

We plan to issue Go 1.11.3 and Go 1.10.6 on Wednesday, December 12 at
approximately 8 pm UTC (12 pm PST, 3 pm EST). These are minor releases to
fix a security issue.

Following our policy at https://golang.org/security, this is the
pre-announcement of those releases.

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

[go-nuts] Go 1.11 Beta 3 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.11beta3, a beta version of Go 1.11.
It is cut from the master branch at the revision tagged go1.11beta3.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.11beta3
is by using the go command:
$ go get golang.org/dl/go1.11beta3
$ go1.11beta3 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.11beta3

To find out what has changed in Go 1.11, read the draft release notes:
https://tip.golang.org/doc/go1.11

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

[go-nuts] Re: All the Go project history, live in RAM

[Dmitri Shuralyov]

Brad, another question.

I've read the documentation at 
https://godoc.org/golang.org/x/build/maintner/godata, but it doesn't make 
it clear: is it safe/supported to have more than 1 process on one machine 
call godata.Get and use returned maintner.Corpus at the same time?

I know each call uses the same underlying cache directory on disk. Or is it 
unsupported/will cause data corruption and other problems?

(Indirectly, I'm asking if it's safe to call 
maintner.NewNetworkMutationSource multiple times with the same cacheDir 
parameter.)


On Sunday, April 30, 2017 at 5:42:03 PM UTC-4, bradfitz wrote:
>
> Gophers,
>
> Want to analyze the Go project's Git, GitHub, and Gerrit history?
>
> Here a package to make it easy:
>
>  https://godoc.org/golang.org/x/build/maintner/godata
>
> See the example:
>
> 
> https://godoc.org/golang.org/x/build/maintner/godata#example-Get--NumComments
>
> If you run that, it'll download 350 MB (once) and then tell you there have 
> been 111228 GitHub comments on Go repos.
>
> Run it again a few seconds later and the number might increase.
>
> The data is generally under 1 second behind reality, thanks to the 
> webhook+incoming-SMTP server we run now at 
> https://pubsubhelper.golang.org/ to get updates from GitHub & Gerrit.
>
> gopherbot now uses this infrastructure. See 
> https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go 
> for some more examples.
>
> Thanks to Kevin Burke for all the help & code reviews.
>
> - Brad
>
>

-- 
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: yaml 1.1 release

[Dmitri Shuralyov]

Just as a heads up, this package (gopkg.in/yaml.v2) is now also affected by 
issue https://github.com/niemeyer/gopkg/issues/54. It wasn't one of the 
affected import paths a week ago.


On Friday, February 23, 2018 at 2:20:22 PM UTC-5, Roger Peppe wrote:
>
> Of course I mean 2.1. Version two. TWO is the version. 
>
>
> On 23 February 2018 at 19:17, roger peppe  > wrote: 
> > I'm happy to announce the release of goyaml 1.1. 
> > 
> > It includes the following improvements: 
> > 
> > - Add Encoder and Decoder types 
> > This allows encoding and decode multiple YAML documents in a stream. 
> > 
> > - Alternative timestamp support (e.g. 2015-01-01). Credit to 
> anthonybishopric. 
> > 
> > - If a value implements an IsZero method and omitempty is specified, 
> > the value will be omitted if IsZero returns true. This means 
> > that time.Time now works correctly with omitzero. 
> > 
> > - Strict mode now enforces key uniqueness (issue #284) 
> > 
> > - Plain scalars with colons in are now allowed in flow-style mappings 
> > and sequences. (issue #295) 
> > 
> > - Forward references to anchors are now disallowed. 
> > 
> > - Version is now tagged compatible with vgo (and there's even a go.mod 
> file!). 
> > 
> > Thanks to everyone for their issues and PRs, and for bearing with my 
> > very slow maintenance of this package... I hope to work on some more 
> > improvements soon! 
>

-- 
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: New to Go; Saying Hello !

[Dmitri Shuralyov]

Hello!

I can really relate to what you're describing. When I started programming 
in Go 5 years ago, I felt the same way, and I still do to this day! There 
are so many moments of joy and bliss that happen when working with it 
daily. :) Hope you continue to enjoy it too!


On Friday, February 23, 2018 at 9:26:42 AM UTC-5, Chris FractalBach wrote:
>
> So, I started programming in Go about a month ago.  I can't stop.
> I can't even describe why I am enjoying the language so much, except by 
> saying...
>
> It's fun to program in Go!
>
> I have now embarked on a mission to create an online game, using Go for 
> the server.
> I thought I should stop by here and say hello, since I have a feeling that 
> I will be
> programming a lot in this language =)
>
> I am certainly Golang-Nuts about 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] net/http: Redirect writes HTML for GET requests without setting Content-Type, how come?

[Dmitri Shuralyov]

Quick followup note here. The CL that resolves this issue has been merged, 
and should be a part of Go 1.10 release.


On Saturday, July 22, 2017 at 11:46:40 PM UTC-4, Dmitri Shuralyov wrote:
>
> Thanks Matt, that corroborates with my understanding too.
>
> I've sent a CL https://go-review.googlesource.com/c/50510 to fix it, it 
> can be reviewed after the tree unfreezes.
>
> > (perhaps only if it's not already set?)
>
> It's good to think this through, but I don't think it's worth checking for 
> that. http.Redirect is meant to be used to a fresh request, one that hasn't 
> been dealt with. We can't do much if the user misuses it. E.g., imagine if 
> they set a different content-type and write some text, then call 
> http.Redirect. It won't be able to set the correct status code, since the 
> status code gets written as soon as you write some bytes to the 
> http.ResponseWriter.
>
>
> On Saturday, July 22, 2017 at 11:27:43 PM UTC-4, Matt Harden wrote:
>>
>> That sounds like a bug. The whole reason for including a message is for 
>> older user-agents that don't understand redirects (must be *really* old! 
>> So the Content-Type should be set as if responding normally to a GET 
>> request. I think Redirect should be setting Content-Type (perhaps only if 
>> it's not already set?).
>>
>> On Tue, Jul 18, 2017 at 8:41 PM Dmitri Shuralyov <shur...@gmail.com> 
>> wrote:
>>
>>> I've written a little middleware to help catch instances where I write 
>>> some content in an HTTP handler, but forget to set the Content-Type header. 
>>> I prefer to always set it to avoid forcing the browser to guess. It feels 
>>> good and produces more predictable results.
>>>
>>> I've noticed some of my redirect responses being marked as not having 
>>> Content-Type header.
>>>
>>> This is because of the implementation of http.Redirect:
>>>
>>>
>>> https://github.com/golang/go/blob/83fb9c8d9f5511f5aca2a0eb9f7507e2527a76a9/src/net/http/server.go#L1961-L2022
>>>
>>> It includes the following snippet:
>>>
>>> // RFC 2616 recommends that a short note "SHOULD" be included in the
>>> // response because older user agents may not understand 301/307.
>>> // Shouldn't send the response for POST or HEAD; that leaves GET.
>>> if r.Method == "GET" {
>>> note := "" + statusText[code] + 
>>> ".\n"
>>> fmt.Fprintln(w, note)
>>> }
>>>
>>> So if the method is GET, it writes a note that looks like HTML... But it 
>>> doesn't set a Content-Type.
>>>
>>> Given my desire to be explicit about setting Content-Types, should I 
>>> always use http.Redirect as follows:
>>>
>>> if r.Method == "GET" {
>>> w.Header().Set("Content-Type", "text/html; charset=utf-8")
>>> }
>>> http.Redirect(w, req, targetURL, http.StatusSeeOther)
>>>
>>> Or is this something that http.Redirect should be doing itself?
>>>
>>> Or is it fine not to set Content-Type header in the case of a redirect 
>>> status code? If so, why is that?
>>>
>>> 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...@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] net/http: Redirect writes HTML for GET requests without setting Content-Type, how come?

[Dmitri Shuralyov]

Thanks Matt, that corroborates with my understanding too.

I've sent a CL https://go-review.googlesource.com/c/50510 to fix it, it can 
be reviewed after the tree unfreezes.

> (perhaps only if it's not already set?)

It's good to think this through, but I don't think it's worth checking for 
that. http.Redirect is meant to be used to a fresh request, one that hasn't 
been dealt with. We can't do much if the user misuses it. E.g., imagine if 
they set a different content-type and write some text, then call 
http.Redirect. It won't be able to set the correct status code, since the 
status code gets written as soon as you write some bytes to the 
http.ResponseWriter.


On Saturday, July 22, 2017 at 11:27:43 PM UTC-4, Matt Harden wrote:
>
> That sounds like a bug. The whole reason for including a message is for 
> older user-agents that don't understand redirects (must be *really* old! 
> So the Content-Type should be set as if responding normally to a GET 
> request. I think Redirect should be setting Content-Type (perhaps only if 
> it's not already set?).
>
> On Tue, Jul 18, 2017 at 8:41 PM Dmitri Shuralyov <shur...@gmail.com 
> > wrote:
>
>> I've written a little middleware to help catch instances where I write 
>> some content in an HTTP handler, but forget to set the Content-Type header. 
>> I prefer to always set it to avoid forcing the browser to guess. It feels 
>> good and produces more predictable results.
>>
>> I've noticed some of my redirect responses being marked as not having 
>> Content-Type header.
>>
>> This is because of the implementation of http.Redirect:
>>
>>
>> https://github.com/golang/go/blob/83fb9c8d9f5511f5aca2a0eb9f7507e2527a76a9/src/net/http/server.go#L1961-L2022
>>
>> It includes the following snippet:
>>
>> // RFC 2616 recommends that a short note "SHOULD" be included in the
>> // response because older user agents may not understand 301/307.
>> // Shouldn't send the response for POST or HEAD; that leaves GET.
>> if r.Method == "GET" {
>> note := "" + statusText[code] + 
>> ".\n"
>> fmt.Fprintln(w, note)
>> }
>>
>> So if the method is GET, it writes a note that looks like HTML... But it 
>> doesn't set a Content-Type.
>>
>> Given my desire to be explicit about setting Content-Types, should I 
>> always use http.Redirect as follows:
>>
>> if r.Method == "GET" {
>> w.Header().Set("Content-Type", "text/html; charset=utf-8")
>> }
>> http.Redirect(w, req, targetURL, http.StatusSeeOther)
>>
>> Or is this something that http.Redirect should be doing itself?
>>
>> Or is it fine not to set Content-Type header in the case of a redirect 
>> status code? If so, why is that?
>>
>> 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...@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] net/http: Redirect writes HTML for GET requests without setting Content-Type, how come?

[Dmitri Shuralyov]

I've written a little middleware to help catch instances where I write some 
content in an HTTP handler, but forget to set the Content-Type header. I 
prefer to always set it to avoid forcing the browser to guess. It feels 
good and produces more predictable results.

I've noticed some of my redirect responses being marked as not having 
Content-Type header.

This is because of the implementation of http.Redirect:

https://github.com/golang/go/blob/83fb9c8d9f5511f5aca2a0eb9f7507e2527a76a9/src/net/http/server.go#L1961-L2022

It includes the following snippet:

// RFC 2616 recommends that a short note "SHOULD" be included in the
// response because older user agents may not understand 301/307.
// Shouldn't send the response for POST or HEAD; that leaves GET.
if r.Method == "GET" {
note := "" + statusText[code] + 
".\n"
fmt.Fprintln(w, note)
}

So if the method is GET, it writes a note that looks like HTML... But it 
doesn't set a Content-Type.

Given my desire to be explicit about setting Content-Types, should I always 
use http.Redirect as follows:

if r.Method == "GET" {
w.Header().Set("Content-Type", "text/html; charset=utf-8")
}
http.Redirect(w, req, targetURL, http.StatusSeeOther)

Or is this something that http.Redirect should be doing itself?

Or is it fine not to set Content-Type header in the case of a redirect 
status code? If so, why is that?

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] Re: [ANN] githubql—a client library for accessing GitHub GraphQL API v4

[Dmitri Shuralyov]

Wow, it would probably help if I linked to the actual package (although it 
seems Google-able from the name alone):

https://github.com/shurcooL/githubql


On Wednesday, May 31, 2017 at 3:55:13 PM UTC-4, Dmitri Shuralyov wrote:
>
> This package is very new, I've just created it a few days ago after a week 
> of research and prototyping. Feedback is welcome.
>
> If you're interested in the details of its design evolution and the 
> various approaches I've considered, I wrote a lengthy comment at 
> https://github.com/google/go-github/issues/646#issuecomment-304499367.
>
> 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] [ANN] githubql—a client library for accessing GitHub GraphQL API v4

[Dmitri Shuralyov]

This package is very new, I've just created it a few days ago after a week 
of research and prototyping. Feedback is welcome.

If you're interested in the details of its design evolution and the various 
approaches I've considered, I wrote a lengthy comment at 
https://github.com/google/go-github/issues/646#issuecomment-304499367.

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] Re: go1.8 and json.NewDecoder(resp.Body)

[Dmitri Shuralyov]

Relevant: https://github.com/google/go-github/pull/317

See the discussion and the CLs to Go std lib that Brad sent out as a result.


On Tuesday, May 23, 2017 at 8:34:03 AM UTC-4, John Shahid wrote:
>
> Hi all,
>
> Some background, we (CloudFoundry) noticed some weird behavior after 
> upgrading from go1.7.4 to go1.8.1. An http client that was polling 260 
> servers started showing more timeouts after the upgrade. After 
> investigating the issue we realized that the following pattern combined 
> with tls connection is the culprit:
>
> resp, err := client.Get(url)
> if err != nil {
> panic(err)
> }
> defer resp.Body.Close()
> m := map[string]string{}
> err = json.NewDecoder(resp.Body).Decode()
> if err != nil {
> panic(err)
> }
>
> The reason for this change in behavior between go1.7.4 and go1.8.1 is the 
> fix for issue#17355 . The new 
> behavior of the chunkedReader is causing the above code to not read the 
> entire body, i.e. it falls short of reading the last zero length chunk. 
> This causes the connection not to be reused on subsequent requests.
>
> I created a small demo app . *note* 
> the demo app cannot be run on the playground since it listens and makes 
> network connections.
>
> I honestly don’t know what’s the right way to fix this issue. One one hand 
> it seems like the reader and json decoder are following the api contract, 
> i.e. it’s not really a bug. On the other hand, I think that many go users 
> use the above pattern which causes very unexpected behavior that is hard to 
> debug.
>
> The only way I can think of to fix this is either using 
> ioutil.ReadAll(resp.Body) combined with json.Unmarshal, or use 
> json.NewDecoder() followed by ioutil.ReadAll and discard the result.
>
> What do you all think ?
> ​
>

-- 
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: All the Go project history, live in RAM

[Dmitri Shuralyov]

Another small question.

https://godoc.org/golang.org/x/build/maintner#GerritProject.Server says:

> Server returns the Gerrit server, such as "go.googlesource.com".

I thought that go.googlesource.com was a Gitiles server, and 
go-review.googlesource.com 
is where the Gerrit server is (according to what it says on the footer). I 
just want to understand better, but what kind of server is go.googlesource.com 
then? Or is it multiple servers/protocols at same URL?

Thinking more about it, is it Gerrit that's doing the actual git repository 
hosting, and reviews at go-review.googlesource.com, but Gitilies is just an 
HTTP frontend to display (read-only) the underlying Gerrit git repo?

(I ask because the two may have different APIs, so I want to better 
understand what's available/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] Re: All the Go project history, live in RAM

[Dmitri Shuralyov]

>
> The data is generally under 1 second behind reality, thanks to the 
> webhook+incoming-SMTP server we run now at https://pubsubhelper.golang.org/ 
> to get updates from GitHub & Gerrit.
>

Just a quick implementation question related to that. I understand you use 
Webhooks to get data from GitHub, and incoming-SMTP server to get updates 
from Gerrit, is that right?

Are you aware of/have you considered/is it possible to use Gerrit's hooks 
to get updates from Gerrit? 
I.e., https://review.openstack.org/Documentation/config-hooks.html.

I'm not proposing/suggesting anything at this time, just inquiring.

-- 
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: Building with "go install" vs "go build"

[Dmitri Shuralyov]

>
> Are there more that I'm unaware of?
>

go get. It downloads source and follows it up with go install.

Are some preferred in certain circumstances
>

The three ways you listed are similar but not equivalent, they have subtle 
differences in behavior. Use whatever is a better fit for your needs. I use 
all of them depending on the situations.

Seems like an important thing to settle.


I'm not sure I understand what there is to settle.

>

-- 
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: $GOPTAH/bin and $PATH

[Dmitri Shuralyov]

Yes, it is.

As far as I know, everybody does it and/or expects you to. Unless you have 
some specific reason not to.


On Thursday, February 2, 2017 at 5:31:32 AM UTC-5, adrian...@hushmail.com 
wrote:
>
> Gophers, 
>
> Is it idiomatic to add $GOPTAH/bin to $PATH in order access a Go 
> executable across my filesystem?
>
> Aidy 
>

-- 
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: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

[Dmitri Shuralyov]

>
> Can someone please explain the thinking behind this design decision? Is it 
> more common on Linux to have a lot of path additions instead of symbolic 
> links to executables? Was this something that was discussed and decided 
> upon by the core team or just an arbitrary decision?


> I'd love to get a better understanding of why this choice. I have never 
> seen another software take this approach.


This is a great question and I'm curious to find out too from someone 
familiar with this design decision.

Not a complaint from me either, I am very happy with either behavior. Just 
curious.


On Tuesday, July 12, 2016 at 4:05:36 PM UTC-4, jsej...@gmail.com wrote:
>
> Don't read this as a complaint. I'm trying to get feedback from code 
> reviewers about the design decision regarding this behavior of the 
> installer.
>
> In my experience, most software for OS X that installs cli components 
> installs to /usr/local/ and then creates symbolic links to executables in 
> /usr/local/bin/, as not to modify my $PATH. However, the Go installer 
> differs in approach by creating a new entry in /etc/paths.d/ for 
> path_helper 
> 
>  
> to read and then modify my $PATH. Can someone please explain the thinking 
> behind this design decision? Is it more common on Linux to have a lot of 
> path additions instead of symbolic links to executables? Was this something 
> that was discussed and decided upon by the core team or just an arbitrary 
> decision?
>
> I'd love to get a better understanding of why this choice. I have never 
> seen another software take this approach.
>
>
> 
>
>

-- 
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: WebAssembly as a target

[Dmitri Shuralyov]

I would be very interested in this.

I think GopherJS has shown how compelling it can be to be able to write Go 
that can run in the browser. It serves as a great preview of that ability, 
enabling one to experiment and prototype things. But to really get the best 
performance, minimum file size, etc., WebAssembly is the ultimate way to 
achieve that IMO.


On Saturday, June 18, 2016 at 12:23:04 PM UTC-7, bourget@gmail.com 
wrote:
>
> After the Google I/O 2016 presentations where we saw WebAssembly in 
> action, are there any thought of having a WebAssembly target for the Go 
> compiler ?
>
> What are you thoughts on that and/or timeline ?
>
> Alexandre
>

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