Live data from Hacker News

Bitwarden compatible server written in Rust

github.com

61–70 of 116 posts

Re: Bitwarden compatible server written in Rust

#61
post #52
post #37

Earlier quoted context omitted.

Once I got used to writing in Rust, I found it really hard to mess up. I sort of like it for applications, although some idioms can be a bit verbose and hard to parse visually and mentally. First, thanks to default immutability of variables and the borrow checker, I trust that I'm far less likely to accidentally mutate something and cause an action-at-a-distance bug. Second, I absolutely love idiomatic Rust error han…

> "Once I got used to writing in Rust..." How long did that take and what resources did you use to learn?

I started off with standard materials like "Rust By Example". I also tried to use Rust for simple stuff like command line utilities.

Then I started working on a personal project, which motivated me to bull through lots of difficult problems. (This personal project happens to have been bindings for Apple Core Audio, but the point is to pick something you care about enough to motivate yourself.)

Finally, I've found users.rust-lang.org invaluable.

The first major challenge for me was the error handling ("WTF is `Box`? What is `Box`? What is `dyn`?"). It got in the way as soon as I even tried to write command line utilities. Once you learn it, it's amazing, but out of the gate I continually stumbled and fell flat on my face.

The second challenge was harder: coming from OOP languages, I was accustomed to structuring everything as large mutable heap-allocated classes with private fields, accessors, and an emphasis on opaque data structures and encapsulation. That is not idiomatic Rust, so I had to unlearn it and discover architectural alternatives.

I don't know exactly how long it took before I felt comfortable, since I was learning in disconnected spurts rather than immersively all at once. It wasn't quick, though.

Re: Bitwarden compatible server written in Rust

#62
post #50

Earlier quoted context omitted.

I‘m on Mobile right now, but in that case you’d wrap your db in a Arc > (or Rc if you don’t need concurrency.). Then, anytime you need to access the DB, you’d try to lock the RwLock’s Writer or reader.

But isn't this imposing a runtime cost on safety? Isn't rust all about safety and performance?

In Rust, abstractions tend to be zero-cost, but things that actually impact runtime are as fast as you write them.

Concurrency problems don't magically disappear because your language can check for them. You still need to use memory-safe patterns, but the compiler will force your hand and prevent you from doing unsafe things accidentally.

In the end, this makes it far easier to build correct, concurrent applications. If you decide to try some fancy new pattern that doesn't require locking, the compiler can guarantee the memory safety of your new implementation.

Re: Bitwarden compatible server written in Rust

#63
post #50

Earlier quoted context omitted.

I‘m on Mobile right now, but in that case you’d wrap your db in a Arc > (or Rc if you don’t need concurrency.). Then, anytime you need to access the DB, you’d try to lock the RwLock’s Writer or reader.

But isn't this imposing a runtime cost on safety? Isn't rust all about safety and performance?

It is a matter of tradeoffs and requirements. Arc is a solid solution for most use cases. If the requirement is (just making up an unlikely extreme scenario) to have a huge amount of threads which constantly lock the RwLock a better solution might be to just open multiple connections per database, each per thread. SQLite, for example, is build with this in mind.

For a reasonable amount of locking, The Arc / RwLock dance offers good performance (other languages, like Swift, use something like Arc for every property access (although the compiler tries to optimise it away)).

The safety is actually better because you're forced to think about the failure case. I don't have good memories of Objective-C where some Foundation calls don't throw (in they don't have an error parameter), but just throw random undocumented exceptions. (Not saying that some Rust calls don't panic, but knowing that something can go wrong is much better than learning about it in production).

Re: Bitwarden compatible server written in Rust

#64
post #37
post #11

Earlier quoted context omitted.

I know this is off-topic but isn't Rust meant to be more of a systems-level language? It seems to me that Go would be a better choice for server-side API (assuming .NET 5 and 6 are too bloated and slow for your tastes). Or is Rust finding a niche in userpace apps even though it was designed for systems level use? I am not saying apps shouldn't be written in Rust, I just don't understand the appeal. What am I missing?

Once I got used to writing in Rust, I found it really hard to mess up. I sort of like it for applications, although some idioms can be a bit verbose and hard to parse visually and mentally. First, thanks to default immutability of variables and the borrow checker, I trust that I'm far less likely to accidentally mutate something and cause an action-at-a-distance bug. Second, I absolutely love idiomatic Rust error han…

> Unlike C# or Python or Java or C++, I don't have to worry that any code could throw an exception at any time. (Rust code can panic, but panics generally represent unrecoverable errors — see http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-are... )

I just don't understand this logic. Exceptions are the same (C++ exceptions use the very same unwinding mechanism than panics in Rust as far as I can see), why would you forbid yourself to catch_unwind ? It's just making your software worse for no reason, users always will be happier with an app that shows a small "warning: internal error. Document backup saved in . $software will now shutdown", than seeing macOS or Windows's crash dialog.

Re: Bitwarden compatible server written in Rust

#65
post #58

When Lastpass began charging for multi-device access, I sought out free alternatives that could be self-hosted, because I figured I wanted to own my passwords, even if they're encrypted at-rest, and I didn't want to have my life held hostage by a company that has a change of heart regarding the cost of password availability. I had heard of Bitwarden before, and looked into it. The stack struck me as incredible for a…

I've tried pass and briefly flirted with running bitwarden rs but finally settled in keepass xc

I take care of the sync (syncthing) but anything would work.

I've never had issues with keepass's auto type so i wonder why it isn't as popular

Mobile used to be aam issue earlier but there's now a top notch implementation keepassdx that's on f droid

Re: Bitwarden compatible server written in Rust

#66

Earlier quoted context omitted.

Assuming you're correct, the parent question is still valid. I think you'd at least want to have some redundant backups to protect against loss (not compromise).

Like anything, you just need to backup, I backup from the ui in vaultwarden intermittently onto a USB stick

The apps also work as a backup to some extent (and still let you export even if the server is down)

Re: Bitwarden compatible server written in Rust

#67
post #37

Earlier quoted context omitted.

Once I got used to writing in Rust, I found it really hard to mess up. I sort of like it for applications, although some idioms can be a bit verbose and hard to parse visually and mentally. First, thanks to default immutability of variables and the borrow checker, I trust that I'm far less likely to accidentally mutate something and cause an action-at-a-distance bug. Second, I absolutely love idiomatic Rust error han…

> Unlike C# or Python or Java or C++, I don't have to worry that any code could throw an exception at any time. (Rust code can panic, but panics generally represent unrecoverable errors — see http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-are ... ) I just don't understand this logic. Exceptions are the same (C++ exceptions use the very same unwinding mechanism than panics in Rust as far as I can see), why w…

For application code, you can change the behavior of Rust panics. Although I haven't verified this myself, I fully expect that you can achieve saving a document and exiting gracefully.

The distinction is that panicking should (almost) never be used for recoverable errors. You can, but that's not idiomatic and would only be appropriate within the confines of your own application. Recoverable errors in Rust should be handled by return values, typically via either Result or Option.

This is unlike all the other options I listed (except Go, and C++ with exceptions disabled), where it is idiomatic to use exceptions to handle recoverable errors.

In theory, (strictly) checked exceptions are equivalent (isomorphic) to error codes as an error handling mechanism. But as soon as unchecked exceptions are allowed, it all falls apart and you must contend with the problem of "invisible control flow". Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.

The Joe Duffy blog post I linked to earlier compares various error handling methods, including checked exceptions. It's very long, but interacting deeply with this blog post helped me to level up my understanding of error handling. FWIW I did a presentation on Duffy's article for the San Diego chapter of Papers We Love: https://www.youtube.com/watch?v=GwPBC4mWfFQ

Re: Bitwarden compatible server written in Rust

#68
post #51
post #4

As cool as a native code back-end for Bitwarden would be I would be more interested in seeing vendor native mobile apps (Swift/Xcode, Kotlin/Android Studio) and putting the Xamarin code out to pasture. Would also like to see an improvement in the desktop Electron app as well or at least get it to feature parity with the web vault. All of that said Bitwarden is a fantastic product and I recommend that over every other…

> All of that said Bitwarden is a fantastic product and I recommend that over every other server-based password manager out there. Do you want to share what makes you think Bitwarden is superior to other selfhosted, open-source solutions (e. g. Passbolt, Passwork, Psono)?

So far, Bitwarden has an Android app (two of those didn't), has been security audited (I didn't see anything for those other ones), and the biggest thing is Bitwarden has a much better pricing structure around non business users. It has a free tier and plans for families/non business users, as well as business use. Those others had nothing comparable that I could see except for a limited free tier.

Feature wise (ignoring the mobile apps), some of those seem to have some comparable features like emergency access, sharing, folders, etc, but locked behind a pricing structure that makes them less useful.

So from a look at those other ones, Bitwarden is the superior product for non business/security conscious family use at least. And for business use I don't see how those other ones are better anyway.

Re: Bitwarden compatible server written in Rust

#69
post #51
post #4

As cool as a native code back-end for Bitwarden would be I would be more interested in seeing vendor native mobile apps (Swift/Xcode, Kotlin/Android Studio) and putting the Xamarin code out to pasture. Would also like to see an improvement in the desktop Electron app as well or at least get it to feature parity with the web vault. All of that said Bitwarden is a fantastic product and I recommend that over every other…

> All of that said Bitwarden is a fantastic product and I recommend that over every other server-based password manager out there. Do you want to share what makes you think Bitwarden is superior to other selfhosted, open-source solutions (e. g. Passbolt, Passwork, Psono)?

For me, it's that you don't have to self-host it if you don't want to. You can seamlessly switch between self- and cloud-hosted.

Re: Bitwarden compatible server written in Rust

#70
post #25

Earlier quoted context omitted.

I'm not very opinionated on Rust's comparison to other languages, but to me it does seem like rewriting things in rust (which now even has its own acronym RIIR) has become trendy. Trendy enough that the very fact that rust tools happen to be written in that language is used as a main selling point.

This is true for basically every budding community. "Rustaceans" writing tools for writing rust, in rust, seems like a gimmick, but every language goes through this period. JavaScript is probably the single biggest offender I can think of, but other examples include rewriting Vim plugins in Lua even though neovim supports vimscript, rewriting literally anything in Go, rewriting python libraries in Julia, etc.

I don't think the example of rewriting python in Julia is the same. Most python libraries get re-written (or implemented) in a faster language. If your choice is rewriting in C++/Fortran, or writing rewriting in Julia, The Julia version will be way nicer to use, and will probably be faster than calling the low level library from python.
Post reply on HN