KeepassC – Curses based keepass written in Rust | Hacker News Reader

KeepassC – Curses based keepass written in Rust

raymontag.github.io

96 pointsImmortalin40 comments

> [Rust] allows me to realize my vision of a secure password manager which is not possible with Python.

Not trying to debunk this or anything, but could anyone expand on this (eg. what does secure mean in this context)? Has the author written somewhere about his decision (I couldn't find anything)?

I love Rust, but it's important to understand what it promises and what it doesn't.

While Rust is considered a "safe" language, I think the term is a little misleading. I prefer "memory-safe." There are plenty of ways to mess up something like a password manager that don't involve failures of memory safety.

Additionally, Rust is only memory-safe to the extent that you do not use unsafe code and that includes the libraries that your project depends on.

That said, I am not qualified to evaluate the security of this project. It may very well be that this password manager is very secure.

In this context, it's also typesafe. A lot of bugs in python can come from mixing up types in cold paths or nulls. Rust doesn't have these issues.

> Additionally, Rust is only memory-safe to the extent that you do not use unsafe code and that includes the libraries that your project depends on.

In much the same way other languages are only memory-safe to the extent that you don't use an FFI (or make sure you're using theme safely). You can trivially segfault CPython with ctypes.

Though unsafe code is probably more common in Rust than native code is in Ruby or Python owing to it being in closer reach and not requiring language switch and great complexity increase in distribution.

  > probably more common

It depends. The idea with unsafe is to wrap it up inside of a library, and expose a safe interface, keeping the surface area as small as possible. So libraries will sometimes use unsafe code, but application code generally doesn't. Cargo, for example, has no unsafe in it. Regex, currently at the top of the benchmarks game, has no unsafe in it, even as a library.

I am not the author, so I don't speak for him, but I feel that I could write much more secure code in Rust than in Python mainly because in Python the onus of making sure everything is okay falls 100% on me. In Rust, the compiler with the type checker and the borrow checker can take a lot of load off my mind.

I am also curious, because this makes very little sense to me. Is the author worried that he'll get pwned when opening random Keepass files he found on the internet?

More likely a page getting swapped out and password remaining somewhere. Indeed, Python doesn't have builtin[1] means to do, say, mlock(2) on str objects, or assure their contents will be zeroed after variable's not used anymore.

[1] upd: besides ctypes, but not sure if we can consider this builtin or not...

My guesses:

- ability to reliably erase memory that held passwords/keys with assurance it wasn't copied accidentally. AFAIK Python doesn't guarantee zeroing of freed memory.

- type safety, error handling enforced by the type system, and race-condition-free concurrency might be an extra assurance.

Can you reliably erase memory? You can't even do that in pure C in a cross platform way currently. I'd be surprised if rust offered this...

http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buf...

Hey,

I'm the author of KeePassC and yes these are the main reasons to write KeePassC new in Rust. I had a private repo with a C implementation, however after a friend pointed me to Rust I decided to give it a try and was immediately fascinated. The reason for the rewrite in Rust is _not_ that I'm unconvinced with the original project.

There are some problems though, as stated in another post, especially with this write_bytes-thing. But I'm working on this.

What makes you think there's a reliable way to zero memory in Rust?

The fact that a systems programming language must have a way to do this, and Rust sort-of has: (it'd be better if it was a stable API though)

https://doc.rust-lang.org/core/intrinsics/fn.volatile_set_me...

I know it's very tricky in presence of an optimizer. The current implementation in KeePassC uses the pointer after memset in Drop, so it might be just lucky (https://github.com/raymontag/rust-keepass/issues/4).

I think you could just use black_box to get around the optimizer:

http://doc.rust-lang.org/1.1.0/test/fn.black_box.html

I've never actually tried it outside of tests, so I don't know if it applies here.

There is no such way in _C_.

C only promises the behavior of the C abstract machine. Data will randomly get spilled from registers into random places on the stack where you may be completely unable to reach them to zeroize them.

All you can do is best effort, in C-- I wouldn't expect rust to be better here.

note http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-i... too though?

Is this such a thing:

https://github.com/raymontag/rust-keepass/blob/2b7b701b69541...

    unsafe { ptr::write_bytes(self.encrypted_string.as_ptr() as *mut c_void, 0u8, self.encrypted_string.len()) };

?

Python has ctypes, which allows one to access (almost) any OS-specific API for secured memory storage, like gcry_malloc_secure or CryptProtectMemory.

I love this.

I'm a bit surprised that there isn't currently a Linux distro that focuses on curses/ncurses apps. And if anyone is looking for the gap in the curses market there's no word processors. (Plenty of text editors though.)

> I'm a bit surprised that there isn't currently a Linux distro that focuses on curses/ncurses apps.

Is there a need for one? You can use all distributions without a graphical UI.

> And if anyone is looking for the gap in the curses market there's no word processors

Yeah, I've been wondering about that. People (including not-so-casual writers like GRRM) still swoon about programs like Wordstar, but it seems all Linux terminal users are content with using vim/emacs/nano/… with TeX (or lately Markdown).

I think that the reason nobody's built a curses word processor is that if you're not getting a WYSIWYG editing experience, you may as well go all the way to a full markup language.

I don't know. I used to think WordPerfect 5.1 was pretty great back in the day.

Such programs being successful was initially due to more graphical options not being available, and later due to the graphical ones being impractical if you had older hardware (and of course because you were used to the text based app and hadn't found time to learn an alternative).

I doubt the niche for rich-UI text based apps like that and it's ilk (Lotus 123 anyone?) exists for enough people to make writing/maintaining one worth while - you'd either be happy with less (markdown and a post processor) or end up wanting more than such a UI could practically provide, I expect.

Though I'm sure you'll find a WordPerfect mode for emacs somewhere, if you are feeling nostagic!

Maybe this is due to a lack of proper widget toolkits. Curses is a real pain to program, and creating sophisticated UIs with it is borderline impossible. Things like dialog are not very flexible, and TurboVision (the best looking CUI ever) never took off, probably because of the lame C port.

Termbox is an "alternative", but it's, while easier to use, even more low-level. It's a shame there's no decent, modern high-level UI toolkit for terminals.

The screenshot here https://en.wikipedia.org/wiki/Ncurses looks pretty nifty. But reading I see it has forms but no mention of widgets.

And here I was thinking that the ease of programming was the main reason for ncurses to be as popular as it is. Oh well...

http://cowlark.com/wordgrinder/ looks like a pretty cool word processor

Slackware's base configuration tools are largely (n)curses-based, plus its highly vanilla unpatched nature with manual, guided package management means you can assemble something like that easily.

Why does the headline say "written in Rust" when the linked page says it's written in Python 3 (and the repository is full of Python and no Rust)?

There is a different repo for Rust implementation: https://github.com/raymontag/rust-keepass

I guess, OP posted the link to the blog post to highlight some reasoning behind the switch, not the code itself.

> My main focus has switched to reimplement this project in Rust as it allows me to realize my vision of a secure password manager which is not possible with Python.

The "reimplement" links to the Rust repository in question.

Does anyone here use www.passwordstore.org? I read through the source and I simply love how simple things are... therefore I wonder why something like keepass is preferred over passwordstore?

It seems that passwords are stored in files with plain text names that identify the website, service, etc. that the password is used for. Most other password managers don't expose this kind of information.

I haven't looked at those 3rd party clients mentioned on their website but I would say a console based command isn't an option for most people when there are password managers that come with a simple management gui and a convenient keyboard shortcut that insert the right account and password information directly into html login forms in your browser.

I also use it here. I miss not being able to autocomplete browser forms when I switched over from 1password, but it isn't really that big of a deal.

As others mention, I wish there was a built in way of protecting the meta-data. I guess it wouldn't be that hard to just encrypt/decrypt the entire directory myself.

I use it, it's pretty good. As simple as it can be, easily integrates with everything.

Last I tried keepassc (about a month ago, definitely the python3 version), I couldn't find a way to make it load my .kdbx file which I routinely open/edit with keepassx. I tried renaming it to <something>.kdb and that didn't do it either. I didn't look that much into it but here goes: is my use case actually unsupported?

.kdb and .kdbx are two totally different formats. .kdb is used by KeePass and KeePassX, .kdbx is used by KeePass 2 and KeePassX 2.0 (currently Beta).

what is the meaning of: curses-based password manager

Not to be glib, but:

https://en.wikipedia.org/wiki/Curses_(programming_library)

https://en.wikipedia.org/wiki/Password_manager

Reply on news.ycombinator.com