That's what it's used for in a major application I use on a daily basis. The entire config for the application is saved off in a pickle binary file and then loaded at whim. Makes it super easy to backup and transfer configs to compatible systems rather than saving everything to a database. One time we were trying to get the system to do something it was not designed for but was probably capable of. Eventually someone got it working on one of the two identical systems we have through a lot of trial and error. Rather than two people sitting on the phone all day comparing hundreds of settings, we just grabbed the pickle file and emailed it over and had it instantly working.
The original quotes are deeply profound. They point to something that is beyond understanding. I also found the attempt to invert them to be off-putting.
"Do not belabor wisdom to examine it;"
- Niutou Farong
I'm saying that when I import something, "foo/bar" "bar/baz" etc, The way I access the exposed functions and types in that package usually corresponds to the basename. e.g. bar.* for the first example, and baz.* for the second example. Is your criticism of Go that it is technically not required for this to be the case?
> "Unused vars are warnings" is not a possible opinion for go, period. It's also not a possible opinion for go tooling like 3rd party linters.
Right, but that doesn't mean that Go doesn't have an opinion about unused variables. Go's opinion is that they are compiler errors.
> my point is that it's not a design choice but a side effect of choosing "we don't have compiler warnings".
What makes you think that? I don't think "we don't have compiler warnings" was behind the choice to make unused variables a compiler error. It seems like a deliberate design decision on the part of the Go team.
> Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.
> There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (Conversely, if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
So I comment out a line or move around some code and want to quickly run it, or run the tests, whatever. This results in a cascade of either removing more and more lines and imports, or not only renaming to _ but also changing := to =.
This is of course the usual golang gaslighting. "It was easier to implement" becomes a "deliberate design decision".
There are tons of things that linters warn about (today), that should have been errors too by their logic.
Do you protect against bruteforcing the TOTP code? I.e. via rate-limiting or a set amount of retries? I took a quick glance at the code and couldn't find anything to this effect.
The scenario I'm imagining is: someone opens the TOTP entry UI in their browser, opens devtools, and starts to loop through all possible TOTP codes.
Yep! I do indeed have protections against bruteforcing TOTP codes, effectively each authentication has a number of "attempts" a user can make before their account gets locked, and an admin is then required to unlock it.
Specifically to force people to have a bit of a think as to why their device is trying to force auth to begin with, as it indicates an endpoint compromise.
I can't speak to the specifics of this particular implementation but usually if someone has the login (username + password) to get to totp that user has already been compromised..
If a user keeps their credentials in a notebook and it got stolen, the TOTP check can be the difference between the attacker getting in, and the user being notified and changing their password
Me too, but my day job means I handle a bit of secops, password managers are rolled out as security tools to users operating in enterprises where things like mandating people don't keep their passwords on a sticky note on their monitor is usually step one...
To my knowledge this is only a problem if the model is serialized/de-serialized via pickle[0].
[0]: https://huggingface.co/docs/hub/en/security-pickle