some ideas about rooster HOT 9 CLOSED

Hi @qmx,

Thanks a lot for your comment !

As can be seen in the updated README.md, the sha256 KDF will soon be replaced with something more solid like scrypt.

Other people have suggested using sqlite3 too. And it does sound interesting. I like that we could have access to database level constraints. We'd still need to document the schema and specify migrations if the schema changes.

I plan to address these 2 issues (better KDF and file format) soon. Including a way to easily change the schema as Rooster evolves, without the need for the end user to know about that.

Feel free to post a link to your project. I'd be happy to see what's in there 😃

Best regards,
Conrad

from rooster.

I plan to address these 2 issues (better KDF and file format) soon. Including a way to easily change the schema as Rooster evolves, without the need for the end user to know about that.

For schema changes, one of the things that could be done was to actually expose the schema version in a plain JSON fashion, like this:

{
  "version":1,
  "another plain text data":"like salt",
  "passwords": "AAAAAAAAAAA" //cyphertext
}

This would make it easier for us to actually migrate data from a schema to another, and would solve the first problem I'm facing trying to implement the key derivation part: since you're marshalling the data straight to the opaque file, I can't peek for the schema version without trying to unmarshall it and let it fail :)

Thoughts?

from rooster.

Yes. Having the file version available without the need to decrypt would be good indeed.

And that is the plan for the next file format.

From there on, I was thinking of keeping compatibility with the current file format for like 2 months and then just drop it, so people can upgrade easily for 2 months. And after 2 months, we could document a 2-step upgrade path in the README.md and the Rooster website for people that haven't yet upgraded. They'll be asked to download an older version of Rooster followed by a newer one so as to upgrade from the current file format to the versioned one first, and then from the versioned one to the very latest one.

What do you think ?

from rooster.

From there on, I was thinking of keeping compatibility with the current file format for like 2 months and then just drop it, so people can upgrade easily for 2 months.

This can be automated, can't it? I mean, we could just convert it on the first load and it will be immediately saved with the new format.. That way all data format upgrades can be transparent to users.

TL;DR if there's no version header exposed assume "the big encrypted blob"

from rooster.

Yes. It could be. And it will be.

I'd like to not keep this in the code forever if possible though. It should definitely be automated at the start, so that's what I'll start with.

from rooster.

Hello @qmx,

I just published a new release of Rooster, which uses scrypt for key derivation.

If you want to install it, please make sure you backup your existing Rooster file first. I tested as well as possible, but I do write bugs sometimes.

The upgrade path from v1 should be straightforward: install Rooster v2 and just start using it.

Best regards and a happy new year,
Conrad

from rooster.

@qmx I almost forgot: about using SQLite. It does indeed sound interesting. I didn't get it into this release: I'm sorry for this, I did not have much time to spend on Rooster. But I suppose we could easily add it to an upcoming release, given that Rooster now has some code that helps upgrading file versions.

What would be the benefits of using SQLite for Rooster ?

from rooster.

I'll mark this as closed but please feel free to respond and/or open a new issue regarding a migration to sqlite 😃

from rooster.

@conradkleinespel yay! going to check it soon

from rooster.