; generates it inside the proto's directory with a directory structure like:
>
Have you tried using an option like: --go_opt=paths=source_relative
Matthew Walster
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from th
to suggestions for alternative ways of preventing that connection
from being DoSed.
Matthew Walster
--
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
5) instead, but
considering that GRPC (via MTLS) gives me all the authentication I need for
the data, that seems overkill and prone to opaque issues. I'm essentially
only worried about spoofed packets coming in trying to reset the TCP
connection.
Open to any suggestions, many thanks in advance!
Matthew Walste
eous regex? Is that something
that's possible with the template package that I haven't discovered?
Matthew Walster
--
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 e
Whoops, yes, there is a feature flag there I missed "supportsAES" etc. It
appears to be gated on that instruction being present, at which time the
operation becomes roughly constant time.
M
On Fri, 3 Dec 2021, 08:53 Matthew Walster, wrote:
> Sure, it's enabled in a bui
Sure, it's enabled in a build constraint:
https://cs.opensource.google/go/go/+/refs/tags/go1.17.3:src/crypto/aes/cipher_asm.go
It's not an exact science, there's no testing for the instruction afaict,
it's just that anything running the amd64 architecture has the aesni
instructions. I assume
On Wed, 9 Feb 2022 at 23:36, E Z wrote:
> I noticed a phenomenon while maintaining my golang application, the local
> timezone of the application always keep the value when it starts, the local
> timezone will not change even though I change the system timezone. It looks
> like the golang time
