1password-linux-to-bitwarden VS gvisor

They have been doing some pretty unfriendly moves towards their long-term customers, like making sure the new 1Password cannot be used without 'the cloud' like the old one could be.

I have no doubt raising more VC money will only accelerate such trends.

In fact I've decided to move off of 1Password to BitWarden, since at least one can realistically self-host it. That being said, it's not exactly easy to migrate from the latest 1Password so I wrote my own little utility to do it[1].

I think we need more competition to VC backed products in general, just imagine what would happen if the building blocks of say a GNU/Linux system we take for granted today would've been built with the mindset that investors are going to want a return on their investment.

I am not saying there's anything wrong with that in principle, but am not sure I want to surrender my passwords to these kinds of incentives.

1 - https://github.com/MatejLach/1password-linux-to-bitwarden

By looking at the decoder of the tool linked in this post, it's just a zip that contains .data files, which are JSON. Still, hiding known file formats (.zip, .json) behind some obscure names (.1pux and .data) does look like a shady pattern to me.

There are compiled version available: 1.0 - initial binary release

Isn't gVisor kind of this as well?

"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."

https://github.com/google/gvisor

This sort of feels like seeing someone riding a bike and saying: why don’t they just get a car? The simple fact is that containers and VMs are quite different. Whether something uses VMX and friends or not is also a red herring, as gVisor also “rolls it own VMM” [1].

[1] https://github.com/google/gvisor/tree/master/pkg/sentry/plat...

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

It uses gVisor to create a TCP/IP stack in userspace, and starts a wireguard interface on it, which the HTTP server from http.Serve listens on. The library will print a URL after startup, where you can access your server. You can create multiple listeners in one binary.

The playground compiles the program with GOOS=linux, GOARCH=amd64 and runs the program with gVisor. Detailed documentation is available at the gVisor site.

You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).