9 ms·

Go 1.15 Released

133 points by mapl 6y ago

xorcist 6y ago
Where are signatures for these binaries published?
- ladberg 6y ago
  Scroll down a bit, they're on that page.
- alias_neo 6y ago
  The sha256 sums are in the table, scroll across if you're on mobile. I don't recall ever seeing signatures though Would love to know if they're there and I've missed them.
- throwaway43234 6y ago
  I've always been a bit confused as to what the attack vector those protect against is for self-hosted packages (i.e. not torrents, third party hosting services, etc.). If the attacker is able to coerce the web server into sending a compromised package when you `GET https://dl.google.com/go/go1.15.src.tar.gz` https://dl.google.com/go/go1.15.src.tar.gz`, couldn't they just as easily send a compromised checksum when you `GET https://golang.org/dl/` https://golang.org/dl/`?
  - _wldu 6y ago
    They are for integrity checking, not security. PGP signatures are better for the scenario you are describing.
    - throwaway43234 6y ago
      Is it a common scenario nowadays to download a file and have it be corrupted? I don't think I've ever had that happen (Though perhaps I wouldn't know, because I don't use these checksums! Though if a package is corrupted and it doesn't noticeably degrade, is it really corrupted? Hm... philosophy of internet downloads)
  - TallGuyShort 6y ago
    With very large, very important downloads, I also appreciate a quick check that no corruption or loss was involved in the download for benign reasons either.
    - majewsky 6y ago
      Has this actually happened to someone in the last 10 years?
      - TallGuyShort 6y ago
        Yes, I've had it happen. Not in subtle ways - usually a size check would show that something is very wrong anyway, but I appreciate the peace of mind. I usually like to bake a check into automation and had that catch things like the binary being replaced by a 404 page, etc... When I update the version I pull, I also update the checksum.
      - justinclift 6y ago
        Yeah, I do remember having an unexpected broken download (via curl from memory) a few months ago. Didn't notice until trying to use the archive and things complained.
    - derefr 6y ago
      Apple's https://en.wikipedia.org/wiki/.XIP https://en.wikipedia.org/wiki/.XIP format is a pretty smart solution to this—it's an archive that embeds a cryptographic signature for its contents, where compliant extractors must verify that signature as they're doing the expanding, and must refuse to expand a corrupted archive. This also means that, if your OS certificate store trusts the cryptographic signer of the archive, then the archive can 1. be auto-expanded after download, in effect giving you the experience of "downloading a folder" (or in macOS, "downloading a bundle") directly; 2. the contents can skip having your OS's foreign-source / untrusted / quarantine xattr-of-choice applied to them; and 3. any disk images unpacked from the archive can have an xattr applied to them saying that they've been pre-integrity-checked and can skip any checksum verification they'd normally do on mount. Sadly, Apple's implementation of .XIP (which is, AFAIK, the only existing implementation of .XIP), which used to be happy to unpack arbitrary .xip file, switched in 10.13 to only expanding .xip files signed by Apple, treating anyone else's .xips as invalid. So .XIP itself is "broken"—since, even if it was adopted by other players, at least on one major OS the default handler would just say the archive is corrupt. But that doesn't mean that the concept behind .XIP is bad. Someone could totally create an open format that has equivalent extraction semantics to .XIP, but "for real." It's not like there's any patented tech here; it's just a format with metadata attached, that archivers have special logic for. We'd just need support for the same sort of verification—but against the actual OS cert store—in extractors like 7zip, The Unarchiver, and GNOME's Archive Manager. ----- Then again, maybe this would be a too-soon-obsolete technology anyway. Every OS's primary filesystem seems to trending toward a concept of subvolumes these days. In a world where all filesystems supported subvolumes, an ideal archive format would just be a CQRS event-stream representation of the construction process for the dirents+inodes+extents of a subvolume, in some vendor-neutral "abstract filesystem" format. Older/traditional systems could hold onto, and pass around, such an archive as a file (though, to operate on it, they'd have to effectively rebuild a regular disk-image-alike from it.) But, upon receipt by a modern consumer OS, the downloading program could ask the filesystem to not reserve a file for the download, but rather to reserve a subvolume for the download, and then feed in the download body as a "change stream" for that subvolume, ala `btrfs receive`. So you'd never actually write such an archive to disk in its packed state; you'd just unpack it as you receive it into its own isolated subvolume space. Like a streaming `tar x`, but without the decision of where to put the result. The new subvolume could even be a "non-root item" in the garbage collection sense; ref-counted by its firm-link references within your existing filesystems (where one such firm-link would be added from the beginning by the downloading program.) Such a subvolume-event-stream archive format could have the same sort of cryptographic integrity-checking as .XIP, where subvolume-streams signed by trusted sources would have different forced-mount-flag metadata set for the unpacked subvolume. Interestingly, this cryptographic integrity-checking could be applied by the filesystem driver as it constructs the subvolume from the stream, thus making it impossible for an application to screw up, and ensuring that the contents are never made available to userspace if they're corrupt, or signed by a blacklisted signer. As a bonus, you could have [signed] subvolume-event-stream archives that are incremental, and OS an app authors could use those for version updates, patching read-only subvolume "app-vN" or "OS-vN" with an update-stream to generate "app-vN+1" or "OS-vN+1." Like a cross between how CoreOS does OS updates, and Google Chrome's Courgette binary-diff updates.
  - dr_hooo 6y ago
    You can calculate the signature offline on your local machine against the public key - only the owner of the file can generate a valid signature
    - throwaway43234 6y ago
      These aren't signatures though? They're checksums, anyone could make them for any blob they want.
  - cesarb 6y ago
    Notice that, in your example, they are different servers. Not only that, but "dl.google.com" is most probably a cluster of servers spread all over the world. If an attacker somehow compromises one of the servers behind "dl.google.com", those unlucky to use that particular server could receive a malicious package; but if they compare the hash or signature with what "golang.org" says should be the correct one, they will notice that something's not right (and can warn others, and/or compare the malicious package with a legitimate one obtained elsewhere). The main server ("golang.org" in this case) is usually considered more trusted than the download mirrors (and is often in a single location, not mirrored all over the world).
- Foxboron 6y ago
  Source tarball: https://storage.googleapis.com/golang/go1.15.src.tar.gz https://storage.googleapis.com/golang/go1.15.src.tar.gz Signature: https://storage.googleapis.com/golang/go1.15.src.tar.gz.asc https://storage.googleapis.com/golang/go1.15.src.tar.gz.asc Signed with `EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796` which is the Google Linux Packages Signing Authority. EDIT: I realized you wanted the binaries. You can fetch them from "https://dl.google.com/go/go1.15.linux-amd64.tar.gz.asc" https://dl.google.com/go/go1.15.linux-amd64.tar.gz.asc", append `.asc` to the binary I reckon. Signed with the same key as the source release.
  - xorcist 6y ago
    Thanks! Strange decision not to link them from the download page.
    - Foxboron 6y ago
      Yes, I recently discovered there are signatures for the tarballs. I believe they where not added to the Arch Linux package because they are hidden.
chocolatkey 6y ago
It seems it hasn't received a blog post/entry in the release history yet
- deleted 6y ago
  [deleted]
- ra7 6y ago
  Will be similar to what's in the tip: https://tip.golang.org/doc/go1.15 https://tip.golang.org/doc/go1.15
  - chocolatkey 6y ago
    Thanks, I was not aware of that subdomain
quicklime 6y ago
Anyone know why https://go.dev https://go.dev still has a download link for "1.14.6", and there's no mention of it over at golang.org?
- ainar-g 6y ago
  That website is updated separately, if I recall correctly. It will probably be updated later today.
benhoyt 6y ago
I think the link should be changed to the 1.15 release notes (now published): https://golang.org/doc/go1.15 https://golang.org/doc/go1.15 -- these are much more interesting and useful.
- gautamcgoel 6y ago
  Yes, I agree. No point on linking to the download page, most people use their package manager to update their Go installation.
  - jaytaylor 6y ago
    I'm curious which package managers / repositories allow you to update to the latest version of go as soon as it's released * ? * In any remotely trustable and reliable way; random PPAs relying on somebody's free time don't count, IMHO. I've noticed Ubuntu, Debian, Centos, and Oracle Enterprise Linux are always trailing by quite a clip. Often years. The strategy I've been using is to just manually install it on the machines where I need it. The production go versions only get updated as required.
    - Foxboron 6y ago
      > I'm curious which package managers / repositories allow you to update to the latest version of go as soon as it's released * ? Arch Linux. I just saw the release when I was checking for updated versions of packages I maintain, and built it before users started bugging me about outdated go binaries. https://www.archlinux.org/packages/community/x86_64/go/ https://www.archlinux.org/packages/community/x86_64/go/
      - jagger27 6y ago
        Alpine is very fast too.
      - snazz 6y ago
        I continue to love how this works out with security updates too. I usually get new browser and kernel versions after particularly bad CVEs within a few hours from the upstream release.
ainar-g 6y ago
Announcement E-Mail: https://groups.google.com/forum/#!topic/golang-announce/Z-cY6ZdGdEU https://groups.google.com/forum/#!topic/golang-announce/Z-cY.... Official blog post: https://blog.golang.org/go1.15 https://blog.golang.org/go1.15. Some fixes already planned for Go 1.15.1: https://github.com/golang/go/milestone/162 https://github.com/golang/go/milestone/162.
Konohamaru 6y ago
"There are no changes to the language." Rob Pike is the ultimate troll.
- ainar-g 6y ago
  What do you mean? Go has been known for its philosophy of “Boring is Good”. Lots of releases these days come with either no changes to the language or some very minor ones.
  - Konohamaru 6y ago
    His "I don't give a hoot" attitude to the people screaming "GO IS EVIL IT DOESN'T HAVE GENERICS" in the face of a decade of non-stop screaming is a testimony to how big his balls are.
  - meddlepal 6y ago
    > Boring is good. Until you reach channels and realize that mantra apparently went out the window at some point.
    - ainar-g 6y ago
      Can you elaborate? I'm asking because I've almost never had any issues with channels.
mholt 6y ago
Caddy binaries on Linux shrink by ~2.5 MB with Go 1.15! (~33 MB down to ~31 MB) 3 MB savings on Mac, and 2 MB on Windows: https://github.com/caddyserver/caddy/pull/3642#issuecomment-669929674 https://github.com/caddyserver/caddy/pull/3642#issuecomment-... So about 8-10% reduction.
- sagichmal 6y ago
  I'm so confused by this. Given the context that Go primarily targets, which is daemon services running on server class machines, binary size, so long as it's not totally absurd, is almost completely irrelevant. Is it like a code golf thing? Why do you care?
  - taywrobel 6y ago
    Given that modern systems include containerization and dozens or hundreds of instances of applications bouncing continually as changes are made or network conditions change, deployment has gotten a lot more “chatty” than tossing a binary on a server and running it. Reducing binary size makes a difference when the app is deployed to remote servers thousands of times under normal operation. Storage and bandwidth is cheap, yes, but it adds up.
    - closeparen 6y ago
      My company runs Go and Java programs that locally compile in seconds to binaries / JARs that weigh tens of megabytes. But for production, we insist on spending tens of minutes building and copying around Docker containers that weigh gigabytes.
  - mholt 6y ago
    You're right. But, leaner binaries are a good sign of a mature compiler & linker.
  - ainar-g 6y ago
    You forgot that another common use for Go is command-line utilities. And there the file size can be important.
piinbinary 6y ago
> Changing the -timeout flag now invalidates cached test results. A cached result for a test run with a long timeout will no longer count as passing when go test is re-invoked with a short one. I'm glad this is fixed! That will make life that one bit less annoying.
edflsafoiewq 6y ago
> The compiler's -json optimization logging now reports large (>= 128 byte) copies and includes explanations of escape analysis decisions. This sounds interesting.
- kristianp 6y ago
  I haven't found any more info about this feature. Anyone have better search skills than me?
  - clktmr 6y ago
    As far as I understand, it's only about including more information in the compilers json output. But that information was already available in non-json output in previos Go versions. To get explanations on the optimization decisions by the compiler build your package with: go build -gcflags="-m -m" See also: go tool compile -h go doc cmd/compile
    - kristianp 6y ago
      Thanks.
FiloSottile 6y ago
Release notes -> [ https://golang.org/doc/go1.15 https://golang.org/doc/go1.15 ] <- Blog post -> [ https://blog.golang.org/go1.15 https://blog.golang.org/go1.15 ] <- So much good stuff in this release, COVID notwithstanding, including an extremely improved linker and smaller binaries. Definitely the best Go release ever :) Here's some details on the changes in the corner of it that Katie and I take care of. The long deprecated Common Name field on X.509 certificates is now ignored, reducing complexity and removing a gnarly conflict with Name constraints. Public CAs are unaffected, the only major service that broke was AWS RDS, and they've been awesome and fixed it in time for the release (but customers need to regenerate certificates). I honestly did not expect this change to make it and I am thrilled about it and what it means for keeping the Go X.509 ecosystem modern and secure. https://github.com/golang/go/issues/39568#issuecomment-671424481 https://github.com/golang/go/issues/39568#issuecomment-67142... crypto/tls Configs now have a spiffy VerifyConnection callback that runs for all connections (which is easier to think about than VerifyPeerCertificate) and that gets passed a ConnectionState. This was Katie's idea to make the callback have access to SCTs and stapled OCSP (which makes it possible to write verifying callbacks for those, although we are working on built-in suppport!) but I also love how it delivers the parsed certificates and makes it trivial to customize verification. https://golang.org/pkg/crypto/tls/#example_Config_verifyConnection https://golang.org/pkg/crypto/tls/#example_Config_verifyConn... https://golang.org/cl/229122 https://golang.org/cl/229122 What I should have started with: session ticket keys and session tickets are now rotated automatically without any impact on the application :sparkles:, greatly mitigating the main weak link in the forward security chain of TLS 1.2. :happydance: This is a. big. deal. https://blog.filippo.io/we-need-to-talk-about-session-tickets/ https://blog.filippo.io/we-need-to-talk-about-session-ticket... https://golang.org/cl/231317 https://golang.org/cl/231317 https://golang.org/cl/230679 https://golang.org/cl/230679 Besides deprecating Common Name, X.509 verification also now has a consistent story on how to handle invalid hostnames: they are matched case-insensitively 1:1 to certificate fields without wildcard or trailing dot processing. There is no spec that says what to do with them, so we had to come with a policy that is predictable, doesn't break applications, but can be implemented securely. It was amazingly difficult. https://golang.org/cl/231378 https://golang.org/cl/231378 https://golang.org/cl/231380 https://golang.org/cl/231380 https://golang.org/cl/231381 https://golang.org/cl/231381 crypto/ecdsa now has SignASN1 and VerifyASN1 functions that do what Sign and Verify should have done all along and operate on byte slices instead of big.Ints. https://golang.org/cl/217940 https://golang.org/cl/217940 There is now a function to make RFC 5280-compliant X.509 v2 Certificate Revocation Lists. https://golang.org/cl/217298 https://golang.org/cl/217298 Public and private key types now have an Equal method that works with go-cmp, and lets you make your own non-empty PublicKey interface. https://golang.org/cl/231417 https://golang.org/cl/231417 crypto/elliptic now has functions to marshal and unmarshal compressed elliptic curve points. Too many people had to implement this one! https://golang.org/cl/202819 https://golang.org/cl/202819 math/big.Int now has a method that makes me extremely happy. FillBytes takes a fixed size buffer and puts the value in it, which is both more performant, and saves annoying padding steps in most crypto applications. If you ever had a bug that only happened 1/256 of the times because you were not adding the padding zero at the beginning if the value happened to be small, this is for you. You know who you are, remember that the support group this week meets on Wednesday not Thursday. https://golang.org/cl/230397 https://golang.org/cl/230397 Finally, Cthulhu. On macOS we now use the system root store even if there's no cgo, by calling straight into Security.framework with... there's assembly involved, that is all. This code is my nemesis, so it was all worth it. https://golang.org/cl/227037 https://golang.org/cl/227037 And more! Check out the release notes. I also plan to write in details about the changes on my newsletter, like I did for Go 1.14. https://buttondown.email/cryptography-dispatches?tag=hn https://buttondown.email/cryptography-dispatches?tag=hn
pansa2 6y ago
> There are no changes to the language. Are there other mainstream languages that are as conservative as Go when it comes to adding new features? I don't love Go as a language, but coming from C++ and Python, both of which have non-stop accumulation of features (and complexity), Go's philosophy is a breath of fresh air.
- mdasen 6y ago
  Possibly Scheme or Racket? S-expression, functional languages don't seem to accumulate language features at an incredible rate (but I don't use them frequently so someone might correctly contradict me). I too like Go's restraint. It really doesn't want to give you a tool to make a one-liner that is easy to conceal a bug. For example, Go's increment (eg, i++) is a statement, not an expression. You can't do list[++i] or anything. There are parts of Go that I'm less a fan of, but they keep a nice eye toward making sure that the code is understandable and reviewable.
- psanford 6y ago
  The Go 1.x compatibility promise is one of Go's best features.
  - naikrovek 6y ago
    Yes. Though, I wonder how much more the language could be improved if it weren't tied down to the bad decisions of the past. Those must all continue in perpetuity while the compatibility promise is kept.
    - psanford 6y ago
      Not in perpetuity. Go 2 does not promise to be backward compatible.
      - tapirl 6y ago
        The current Go 2 drafts do.
- 6y ago
maxioatic 6y ago
> When the flag package sees -h or -help, and those flags are not defined, it now prints a usage message. If the FlagSet was created with ExitOnError, FlagSet.Parse would then exit with a status of 2. In this release, the exit status for -h or -help has been changed to 0. This is nice. I basically only write small CLIs with Go and don't explicitly define help flags. I always wondered why it returned an exit code of 2.

Go 1.15 Released

133 points by mapl 6y ago

xorcist 6y ago

Where are signatures for these binaries published?

ladberg 6y ago
Scroll down a bit, they're on that page.
alias_neo 6y ago
The sha256 sums are in the table, scroll across if you're on mobile. I don't recall ever seeing signatures though Would love to know if they're there and I've missed them.
throwaway43234 6y ago
I've always been a bit confused as to what the attack vector those protect against is for self-hosted packages (i.e. not torrents, third party hosting services, etc.). If the attacker is able to coerce the web server into sending a compromised package when you `GET https://dl.google.com/go/go1.15.src.tar.gz` https://dl.google.com/go/go1.15.src.tar.gz`, couldn't they just as easily send a compromised checksum when you `GET https://golang.org/dl/` https://golang.org/dl/`?
- _wldu 6y ago
  They are for integrity checking, not security. PGP signatures are better for the scenario you are describing.
  - throwaway43234 6y ago
    Is it a common scenario nowadays to download a file and have it be corrupted? I don't think I've ever had that happen (Though perhaps I wouldn't know, because I don't use these checksums! Though if a package is corrupted and it doesn't noticeably degrade, is it really corrupted? Hm... philosophy of internet downloads)
- TallGuyShort 6y ago
  With very large, very important downloads, I also appreciate a quick check that no corruption or loss was involved in the download for benign reasons either.
  - majewsky 6y ago
    Has this actually happened to someone in the last 10 years?
    - TallGuyShort 6y ago
      Yes, I've had it happen. Not in subtle ways - usually a size check would show that something is very wrong anyway, but I appreciate the peace of mind. I usually like to bake a check into automation and had that catch things like the binary being replaced by a 404 page, etc... When I update the version I pull, I also update the checksum.
    - justinclift 6y ago
      Yeah, I do remember having an unexpected broken download (via curl from memory) a few months ago. Didn't notice until trying to use the archive and things complained.
  - derefr 6y ago
    Apple's https://en.wikipedia.org/wiki/.XIP https://en.wikipedia.org/wiki/.XIP format is a pretty smart solution to this—it's an archive that embeds a cryptographic signature for its contents, where compliant extractors must verify that signature as they're doing the expanding, and must refuse to expand a corrupted archive. This also means that, if your OS certificate store trusts the cryptographic signer of the archive, then the archive can 1. be auto-expanded after download, in effect giving you the experience of "downloading a folder" (or in macOS, "downloading a bundle") directly; 2. the contents can skip having your OS's foreign-source / untrusted / quarantine xattr-of-choice applied to them; and 3. any disk images unpacked from the archive can have an xattr applied to them saying that they've been pre-integrity-checked and can skip any checksum verification they'd normally do on mount. Sadly, Apple's implementation of .XIP (which is, AFAIK, the only existing implementation of .XIP), which used to be happy to unpack arbitrary .xip file, switched in 10.13 to only expanding .xip files signed by Apple, treating anyone else's .xips as invalid. So .XIP itself is "broken"—since, even if it was adopted by other players, at least on one major OS the default handler would just say the archive is corrupt. But that doesn't mean that the concept behind .XIP is bad. Someone could totally create an open format that has equivalent extraction semantics to .XIP, but "for real." It's not like there's any patented tech here; it's just a format with metadata attached, that archivers have special logic for. We'd just need support for the same sort of verification—but against the actual OS cert store—in extractors like 7zip, The Unarchiver, and GNOME's Archive Manager. ----- Then again, maybe this would be a too-soon-obsolete technology anyway. Every OS's primary filesystem seems to trending toward a concept of subvolumes these days. In a world where all filesystems supported subvolumes, an ideal archive format would just be a CQRS event-stream representation of the construction process for the dirents+inodes+extents of a subvolume, in some vendor-neutral "abstract filesystem" format. Older/traditional systems could hold onto, and pass around, such an archive as a file (though, to operate on it, they'd have to effectively rebuild a regular disk-image-alike from it.) But, upon receipt by a modern consumer OS, the downloading program could ask the filesystem to not reserve a file for the download, but rather to reserve a subvolume for the download, and then feed in the download body as a "change stream" for that subvolume, ala `btrfs receive`. So you'd never actually write such an archive to disk in its packed state; you'd just unpack it as you receive it into its own isolated subvolume space. Like a streaming `tar x`, but without the decision of where to put the result. The new subvolume could even be a "non-root item" in the garbage collection sense; ref-counted by its firm-link references within your existing filesystems (where one such firm-link would be added from the beginning by the downloading program.) Such a subvolume-event-stream archive format could have the same sort of cryptographic integrity-checking as .XIP, where subvolume-streams signed by trusted sources would have different forced-mount-flag metadata set for the unpacked subvolume. Interestingly, this cryptographic integrity-checking could be applied by the filesystem driver as it constructs the subvolume from the stream, thus making it impossible for an application to screw up, and ensuring that the contents are never made available to userspace if they're corrupt, or signed by a blacklisted signer. As a bonus, you could have [signed] subvolume-event-stream archives that are incremental, and OS an app authors could use those for version updates, patching read-only subvolume "app-vN" or "OS-vN" with an update-stream to generate "app-vN+1" or "OS-vN+1." Like a cross between how CoreOS does OS updates, and Google Chrome's Courgette binary-diff updates.
- dr_hooo 6y ago
  You can calculate the signature offline on your local machine against the public key - only the owner of the file can generate a valid signature
  - throwaway43234 6y ago
    These aren't signatures though? They're checksums, anyone could make them for any blob they want.
- cesarb 6y ago
  Notice that, in your example, they are different servers. Not only that, but "dl.google.com" is most probably a cluster of servers spread all over the world. If an attacker somehow compromises one of the servers behind "dl.google.com", those unlucky to use that particular server could receive a malicious package; but if they compare the hash or signature with what "golang.org" says should be the correct one, they will notice that something's not right (and can warn others, and/or compare the malicious package with a legitimate one obtained elsewhere). The main server ("golang.org" in this case) is usually considered more trusted than the download mirrors (and is often in a single location, not mirrored all over the world).
Foxboron 6y ago
Source tarball: https://storage.googleapis.com/golang/go1.15.src.tar.gz https://storage.googleapis.com/golang/go1.15.src.tar.gz Signature: https://storage.googleapis.com/golang/go1.15.src.tar.gz.asc https://storage.googleapis.com/golang/go1.15.src.tar.gz.asc Signed with `EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796` which is the Google Linux Packages Signing Authority. EDIT: I realized you wanted the binaries. You can fetch them from "https://dl.google.com/go/go1.15.linux-amd64.tar.gz.asc" https://dl.google.com/go/go1.15.linux-amd64.tar.gz.asc", append `.asc` to the binary I reckon. Signed with the same key as the source release.
- xorcist 6y ago
  Thanks! Strange decision not to link them from the download page.
  - Foxboron 6y ago
    Yes, I recently discovered there are signatures for the tarballs. I believe they where not added to the Arch Linux package because they are hidden.

chocolatkey 6y ago

It seems it hasn't received a blog post/entry in the release history yet

deleted 6y ago
[deleted]
ra7 6y ago
Will be similar to what's in the tip: https://tip.golang.org/doc/go1.15 https://tip.golang.org/doc/go1.15
- chocolatkey 6y ago
  Thanks, I was not aware of that subdomain

quicklime 6y ago

Anyone know why https://go.dev https://go.dev still has a download link for "1.14.6", and there's no mention of it over at golang.org?

ainar-g 6y ago
That website is updated separately, if I recall correctly. It will probably be updated later today.

benhoyt 6y ago

I think the link should be changed to the 1.15 release notes (now published): https://golang.org/doc/go1.15 https://golang.org/doc/go1.15 -- these are much more interesting and useful.

gautamcgoel 6y ago
Yes, I agree. No point on linking to the download page, most people use their package manager to update their Go installation.
- jaytaylor 6y ago
  I'm curious which package managers / repositories allow you to update to the latest version of go as soon as it's released * ? * In any remotely trustable and reliable way; random PPAs relying on somebody's free time don't count, IMHO. I've noticed Ubuntu, Debian, Centos, and Oracle Enterprise Linux are always trailing by quite a clip. Often years. The strategy I've been using is to just manually install it on the machines where I need it. The production go versions only get updated as required.
  - Foxboron 6y ago
    > I'm curious which package managers / repositories allow you to update to the latest version of go as soon as it's released * ? Arch Linux. I just saw the release when I was checking for updated versions of packages I maintain, and built it before users started bugging me about outdated go binaries. https://www.archlinux.org/packages/community/x86_64/go/ https://www.archlinux.org/packages/community/x86_64/go/
    - jagger27 6y ago
      Alpine is very fast too.
    - snazz 6y ago
      I continue to love how this works out with security updates too. I usually get new browser and kernel versions after particularly bad CVEs within a few hours from the upstream release.

ainar-g 6y ago

Announcement E-Mail: https://groups.google.com/forum/#!topic/golang-announce/Z-cY6ZdGdEU https://groups.google.com/forum/#!topic/golang-announce/Z-cY.... Official blog post: https://blog.golang.org/go1.15 https://blog.golang.org/go1.15. Some fixes already planned for Go 1.15.1: https://github.com/golang/go/milestone/162 https://github.com/golang/go/milestone/162.

Konohamaru 6y ago

"There are no changes to the language." Rob Pike is the ultimate troll.

ainar-g 6y ago
What do you mean? Go has been known for its philosophy of “Boring is Good”. Lots of releases these days come with either no changes to the language or some very minor ones.
- Konohamaru 6y ago
  His "I don't give a hoot" attitude to the people screaming "GO IS EVIL IT DOESN'T HAVE GENERICS" in the face of a decade of non-stop screaming is a testimony to how big his balls are.
- meddlepal 6y ago
  > Boring is good. Until you reach channels and realize that mantra apparently went out the window at some point.
  - ainar-g 6y ago
    Can you elaborate? I'm asking because I've almost never had any issues with channels.

mholt 6y ago

Caddy binaries on Linux shrink by ~2.5 MB with Go 1.15! (~33 MB down to ~31 MB) 3 MB savings on Mac, and 2 MB on Windows: https://github.com/caddyserver/caddy/pull/3642#issuecomment-669929674 https://github.com/caddyserver/caddy/pull/3642#issuecomment-... So about 8-10% reduction.

sagichmal 6y ago
I'm so confused by this. Given the context that Go primarily targets, which is daemon services running on server class machines, binary size, so long as it's not totally absurd, is almost completely irrelevant. Is it like a code golf thing? Why do you care?
- taywrobel 6y ago
  Given that modern systems include containerization and dozens or hundreds of instances of applications bouncing continually as changes are made or network conditions change, deployment has gotten a lot more “chatty” than tossing a binary on a server and running it. Reducing binary size makes a difference when the app is deployed to remote servers thousands of times under normal operation. Storage and bandwidth is cheap, yes, but it adds up.
  - closeparen 6y ago
    My company runs Go and Java programs that locally compile in seconds to binaries / JARs that weigh tens of megabytes. But for production, we insist on spending tens of minutes building and copying around Docker containers that weigh gigabytes.
- mholt 6y ago
  You're right. But, leaner binaries are a good sign of a mature compiler & linker.
- ainar-g 6y ago
  You forgot that another common use for Go is command-line utilities. And there the file size can be important.

piinbinary 6y ago

> Changing the -timeout flag now invalidates cached test results. A cached result for a test run with a long timeout will no longer count as passing when go test is re-invoked with a short one. I'm glad this is fixed! That will make life that one bit less annoying.

edflsafoiewq 6y ago

> The compiler's -json optimization logging now reports large (>= 128 byte) copies and includes explanations of escape analysis decisions. This sounds interesting.

kristianp 6y ago
I haven't found any more info about this feature. Anyone have better search skills than me?
- clktmr 6y ago
  As far as I understand, it's only about including more information in the compilers json output. But that information was already available in non-json output in previos Go versions. To get explanations on the optimization decisions by the compiler build your package with: go build -gcflags="-m -m" See also: go tool compile -h go doc cmd/compile
  - kristianp 6y ago
    Thanks.

FiloSottile 6y ago

Release notes -> [ https://golang.org/doc/go1.15 https://golang.org/doc/go1.15 ] <- Blog post -> [ https://blog.golang.org/go1.15 https://blog.golang.org/go1.15 ] <- So much good stuff in this release, COVID notwithstanding, including an extremely improved linker and smaller binaries. Definitely the best Go release ever :) Here's some details on the changes in the corner of it that Katie and I take care of. The long deprecated Common Name field on X.509 certificates is now ignored, reducing complexity and removing a gnarly conflict with Name constraints. Public CAs are unaffected, the only major service that broke was AWS RDS, and they've been awesome and fixed it in time for the release (but customers need to regenerate certificates). I honestly did not expect this change to make it and I am thrilled about it and what it means for keeping the Go X.509 ecosystem modern and secure. https://github.com/golang/go/issues/39568#issuecomment-671424481 https://github.com/golang/go/issues/39568#issuecomment-67142... crypto/tls Configs now have a spiffy VerifyConnection callback that runs for all connections (which is easier to think about than VerifyPeerCertificate) and that gets passed a ConnectionState. This was Katie's idea to make the callback have access to SCTs and stapled OCSP (which makes it possible to write verifying callbacks for those, although we are working on built-in suppport!) but I also love how it delivers the parsed certificates and makes it trivial to customize verification. https://golang.org/pkg/crypto/tls/#example_Config_verifyConnection https://golang.org/pkg/crypto/tls/#example_Config_verifyConn... https://golang.org/cl/229122 https://golang.org/cl/229122 What I should have started with: session ticket keys and session tickets are now rotated automatically without any impact on the application :sparkles:, greatly mitigating the main weak link in the forward security chain of TLS 1.2. :happydance: This is a. big. deal. https://blog.filippo.io/we-need-to-talk-about-session-tickets/ https://blog.filippo.io/we-need-to-talk-about-session-ticket... https://golang.org/cl/231317 https://golang.org/cl/231317 https://golang.org/cl/230679 https://golang.org/cl/230679 Besides deprecating Common Name, X.509 verification also now has a consistent story on how to handle invalid hostnames: they are matched case-insensitively 1:1 to certificate fields without wildcard or trailing dot processing. There is no spec that says what to do with them, so we had to come with a policy that is predictable, doesn't break applications, but can be implemented securely. It was amazingly difficult. https://golang.org/cl/231378 https://golang.org/cl/231378 https://golang.org/cl/231380 https://golang.org/cl/231380 https://golang.org/cl/231381 https://golang.org/cl/231381 crypto/ecdsa now has SignASN1 and VerifyASN1 functions that do what Sign and Verify should have done all along and operate on byte slices instead of big.Ints. https://golang.org/cl/217940 https://golang.org/cl/217940 There is now a function to make RFC 5280-compliant X.509 v2 Certificate Revocation Lists. https://golang.org/cl/217298 https://golang.org/cl/217298 Public and private key types now have an Equal method that works with go-cmp, and lets you make your own non-empty PublicKey interface. https://golang.org/cl/231417 https://golang.org/cl/231417 crypto/elliptic now has functions to marshal and unmarshal compressed elliptic curve points. Too many people had to implement this one! https://golang.org/cl/202819 https://golang.org/cl/202819 math/big.Int now has a method that makes me extremely happy. FillBytes takes a fixed size buffer and puts the value in it, which is both more performant, and saves annoying padding steps in most crypto applications. If you ever had a bug that only happened 1/256 of the times because you were not adding the padding zero at the beginning if the value happened to be small, this is for you. You know who you are, remember that the support group this week meets on Wednesday not Thursday. https://golang.org/cl/230397 https://golang.org/cl/230397 Finally, Cthulhu. On macOS we now use the system root store even if there's no cgo, by calling straight into Security.framework with... there's assembly involved, that is all. This code is my nemesis, so it was all worth it. https://golang.org/cl/227037 https://golang.org/cl/227037 And more! Check out the release notes. I also plan to write in details about the changes on my newsletter, like I did for Go 1.14. https://buttondown.email/cryptography-dispatches?tag=hn https://buttondown.email/cryptography-dispatches?tag=hn

pansa2 6y ago

> There are no changes to the language. Are there other mainstream languages that are as conservative as Go when it comes to adding new features? I don't love Go as a language, but coming from C++ and Python, both of which have non-stop accumulation of features (and complexity), Go's philosophy is a breath of fresh air.

mdasen 6y ago
Possibly Scheme or Racket? S-expression, functional languages don't seem to accumulate language features at an incredible rate (but I don't use them frequently so someone might correctly contradict me). I too like Go's restraint. It really doesn't want to give you a tool to make a one-liner that is easy to conceal a bug. For example, Go's increment (eg, i++) is a statement, not an expression. You can't do list[++i] or anything. There are parts of Go that I'm less a fan of, but they keep a nice eye toward making sure that the code is understandable and reviewable.
psanford 6y ago
The Go 1.x compatibility promise is one of Go's best features.
- naikrovek 6y ago
  Yes. Though, I wonder how much more the language could be improved if it weren't tied down to the bad decisions of the past. Those must all continue in perpetuity while the compatibility promise is kept.
  - psanford 6y ago
    Not in perpetuity. Go 2 does not promise to be backward compatible.
    - tapirl 6y ago
      The current Go 2 drafts do.
6y ago

maxioatic 6y ago

> When the flag package sees -h or -help, and those flags are not defined, it now prints a usage message. If the FlagSet was created with ExitOnError, FlagSet.Parse would then exit with a status of 2. In this release, the exit status for -h or -help has been changed to 0. This is nice. I basically only write small CLIs with Go and don't explicitly define help flags. I always wondered why it returned an exit code of 2.