Open Source

[robd003]

Could you open source connect? I'd feel a lot better running it in my production cluster if I could audit the code.

[edif2008]

Hey @robd003,

We are not planning on open sourcing Connect at this time. However, we've made note of your request.

When building Connect we've taken a great deal in care in making sure to provide you with the same level of security that you have come to expect with 1Password. However, please let me know if there are any specific aspects that you're concerned about Connect. I'm more than happy to help out and try to alleviate your concerns! 😊

[baryluk]

I would also like connect to be open sourced.

This is rather concerning to run code like this.

It is not even clear right now what kind of license Connect has.

Some of the reasons for open sourcing:

• Higher trust in what the code is doing, and ensuring it is not doing anything shady on internal network, or sending out unnecessary data
• Ability to test pre-release code easily
• Ability to easily scan for dependent packages vulnerabilities, or update them quickly ourselves if maintainers are busy or unavailable
• Visibility of what is the health of the project, and how quickly critical bugs are fixed (This is not a jab at you, rather something that is important for transparency and prioritization).
• Ability to debug / instrument code, either for ongoing monitoring, or for troubleshooting (i.e. memory leaks, crashes, etc)
• More eyes == higher chance of finding obscure issues
• Ability to change architecture by contributors, i.e. how horizontal scaling is done, or how api and sync discover each other, what backend DB is used, etc
• Repackaging for different architectures, compiler versions, running outside of docker / k8s, using static linking, different optimization modes, etc
• Ability to safely do load testing (right now there is basically no way to do it safely, without potentially overloading 1password servers)
• Various other improvements, and prototyping, which might not be usable by everyone, or 1pass team not willing to implement, but some others might want. Examples:
• Providing other RPC protocol than JSON, identifying scaling issues (i.e. caches, inefficient locking, memory allocations, etc)
• Improving monitoring, logging, ... (there are Prometheus metrics which is awesome, but not sure if there is easy way to configure ports or authentication, or where is documentation of metrics, and from the look it provide just basics of request count and latency info, but there is so many other things to measure)
• Using different authentication schemas, i.e. client TLS, oauth, etc
• Ability to build container images based on other base layer. (I am perfectly find with Debian, but using Alpine is another option, I also like having some extra packages sometimes in containers, which are not present in connect image, things like less, ps, top, editor. Granted these can be done by extending existing image to some extent)
• There is number of somehow bizarre content in the binary, if you inspect it.
• There is number of undocumented features, i.e. backend DB has an audit table, logging all client requests. How it can be accessed, how it is garbage collected, how to opt out, etc. etc.
• Configuration via environment variables is not something I like too much, I prefer to use flags (and maybe use file for sensitive keys only). But I am stuck with what it is.
• Provide container has no init process (like tini), so running shell inside container (for troubleshooting, backup, etc) is problematic, as orphan processes could linger as zombies.
• etc.
• etc.

[worm-emoji]

Please do consider open-sourcing Connect. Scratching my head at why this repo even exists.

[philmillman]

+1 for this

[jewettg]

+1