pass-import VS goprotobuf

> I always tell these people to just sign up for a password manager and they always resist and say no. I must be missing something obvious.

Maybe they don't want to be relying on a random third-party for all their passwords?

Rather than getting them to sign up for a password manager, what about getting them to install a password manager? I use https://www.passwordstore.org/ - it encrypts your passwords with GPG, and shares the storage via a Git repository for synchronisation between different machines.

That way you can delegate the password handling to another program, e.g. a password manager like pass(1) (https://www.passwordstore.org/) or some interactive graphical prompt.

I want to move to something compatible with https://www.passwordstore.org/ - an open standard for keeping your passwords in a folder encrypted with OpenPGP.

The problem is that I'm nervous to give an unknown Android app and browser plugin total control of my passwords and access to my github account when I don't have time to review it's code properly. I have a bit more trust ing the command line tools, but I'd like to be sure that more people are looking at the code before I trust my life to it.

> Create a system or pattern based on url or brand and mentally hash it into a password.

Doesn't sound very secure. Also when you realize that you anyway have to trust cryptography, I believe it starts making a lot of sense to have an actual cryptographic key and encrypt it with one good random password you learn by heart.

I use pass https://www.passwordstore.org/, which encrypts my passwords with my GPG key, which comes from my Yubikey, which I unlock with a password. That means that I only need to remember one password, and it feels a lot more secure than your pattern based on url or brand.

i use pass and keep my database on a local git repo. it encrypts your passwords with gpg and is a really simple command line program

If you want portability and simplicity, there's a project called simply pass that uses standard *nix utilities (and git, I believe) to manage passwords from CLI.

0. Pass is just text files encrypted with gpg. I needed just one password on one work computer, where I had my gpg key, but not all my passwords. Decrypted the file and that was it.

1. There are plugins and web clients: https://www.passwordstore.org/#extensions

I've been incredibly happy with https://www.passwordstore.org/ for years. The data store is a file hierarchy, with the files themselves encrypted with GPG. Sync is via git. TOTP support with a plugin.

Now let’s take a look at the source code of the protoc-gen-go plugin:

Wait, you say, in Go you can embed a struct with default method implementations to "inherit" them in your composed struct... sure, except any methods called by those methods are early-bound in the original struct, completely ignoring your wrapper, so the best you can do is "not implemented" rather than actually implement something. It is at least a way to prevent semver-major breakage, which the gRPC generator uses, but that's about as far as it gets you.

The classic answer is protobufs. You can serialize out to binary format.

Seems like go is pretty middle of the road. I can only guess as to why but it probably has to do with heavy usage of pointers and reflection which are much slower than other implementations. Gogo/protobuf (RIP) solved this performance with code generation, but the the official go protobuf implementation has essentially eschewed it. I do wonder how the benchmark would look using the new vitess proto library for Go (which has many of the benefits of gogo but with active development and an API built on top of the Google one)

Maybe I'm missing something, but my read of [golang/protobuf#364](https://github.com/golang/protobuf/issues/364) was that the re-organization in protobuf-go v2 was allow for optimizations like gogoprotobuf to be developed without requiring a complete fork. I totally understand that the authors of gogoprotobuf do not have the time to re-architect their library to use these hooks, but best I can figure this generator does not use these hooks either. Instead it defines additional member functions, and wrappers that look for those specialized functions and fallback to the generic ones if not found.

I am thinking about stuff like the [ProtoMethods](https://pkg.go.dev/google.golang.org/[email protected]/reflec...) API.

I wonder why not? Did the authors of the vtprotobuf extension not want to bite off that much work? Is the new API not sufficient to do what they want (thus failing some of the goals expressed in golang/protobuf#364?

In this case try approach with line by line generation. Very much like what protoc-gen-go does for Go code: https://github.com/golang/protobuf/blob/ae97035608a719c7a1c1c41bed0ae0744bdb0c6f/protoc-gen-go/grpc/grpc.go#L142, need to implement this kind of generator yourself.

Something like this: https://github.com/golang/protobuf/blob/master/internal/gengogrpc/grpc.go