Matt Silverlock

`sync.Pool` automatically GC's objects, which may not be what you want. I wrote a short piece on the differences: http://blog.questionable.services/article/using-buffer-pools-with-go/#postscript There are also a number of issues about `sync.Pool` that...

Although this is a very old issue, you could potentially tackle it by using template tags - e.g.: - The public gopkg.in matches on `gopkg.in/{{github.username}}/{{repository}}.{{rev}}` or `gopkg.in/go-{{repository}}/{{repository}}` - Self-hosted instances...

Will tag the new release after I fix the tests to run in CI via #47

Partially. The PRs have been non-critical from my perspective - I’ve been “triaging” most projects in this way.

(Also IIRC I didn't have admin rights to fix the CI problem - I'd just port it to CircleCI as per all of the other Gorilla repos)

This won't work as intended, as setting a MaxAge of 0 means that the backing Redis store will try to call `SETEX` with a TTL of `0`, which is invalid...

Can you detail the “issues” - ? I’d also like to understand the `+incompatible` syntax - it’s not documented anywhere in the modules docs.

Ah - that makes sense. The official docs don't detail this appendix (yet?), hence the confusion.

Most of the solutions there don't solve the problem: - Salted MD5 is still a very, very bad choice (esp. using application-wide salts) - Salted SHA-1 or SHA-2 (i.e. SHA-256)...

Further - https://github.com/astaxie/build-web-application-with-golang/blob/master/en/eBook/09.6.md#base64-encryption-and-decryption - is not _encryption_ and provides _no data security at all_. base64 is an _encoding_ type, not an _encryption_ method. There are no secrets, no keys. I...