Assessment of the iteration that has ended

The goal for the previous iteration was:

The goal for this iteration is to implement a reasonable obnam init, which reads a passphrase from the user, and derives two keys from it, and stores them into ~/.config/obnam/secrets.yaml, with file-system permissions of 0400 (or -r------ in ls notation). It is not part of the goal to actually use those keys in any way.

That goal was reached.

Unfortunately, Lars was busy with life and things and did not have time to prepare a new iteration. Thus, there was an week between the iteration ending and the next iteration.

Discussion

The new init subcommand

The obnam init functionality is probably too simplistic for most use cases that care about security. That's OK, it's a step towards something good. Issue obnam#104 collects ideas for how to do that well. For a good long time, the current way will do, and lets us start work on actually encrypting data and verifying the data is intact when downloading it.

Code review

One thing that Lars noticed while doing the init work is that after creating the merge request, he immediately merged it himself. There was no code review. In fact, that is basically what happens with every change to Obnam. On the one hand, this is natural, as Lars is currently the only one working on the code; this also allows Lars to move quickly, which is important for keeping his motivation up. On the other hand, it's a self-sustaining situation, since nobody else currently even has a chance to review, since the time between pushing a change to the git server and it getting merged tends to be on the order of seconds. Something needs to change about the process.

Lars is thus proposing a change to how Obnam code review will work:

• Lars will push changes, and for each change set a value for N, which may be different for each change.
• Lars will wait for N days for comments, and if nothing has been raised that would prevent a merge, and if discussion isn't continuing, Lars will merge.
• Comments on merge requests on gitlab.com will be open: anyone will be able to comment.
• Lars may update the MR based on feedback, applying his best judgment.

Typical values for N will be:

• 0 for typo fixes and similar low-impact changes, or fixes to urgent high-impact issues (immediate self-merge)
• 1 for other urgent changes
• 3 for most changes – this will be the default
• 5 for changes likely to be controversial or affecting security related code

Lars will advertise the merge requests via various channels. The hope is that this will eventually attract people to do reviews. As time goes by, and trust is built, some of those people will get the "approve" or "merge" privilege. The "approve" privilege allows marking a merge request as "approved", allowing someone else to merge. The "merge" one will allow telling GitLab to actually merge the change, closing the merge request.

Merge requests by others will follow the same process. If nobody else reviews a change, Lars will do that.

This workflow should at least open the door to code review without slowing down development too much.

Iteration length

Obnam has been using two-week iterations so far. However, this turns out to be quite a long time, and many things happen in two weeks, internally and externally. It's also such a long time that there's either a tendency to take on too much work for the iteration and not being able to do it all, or doing other things for most of the iteration and then cram right before the iteration ends. Neither is good.

Lars thus proposes that Obnam will experiment with one-week iterations. Since Lars is the only one who currently has any decision-making power, the motion carries with extraordinary unanimity.

Governance

When the project starts having other regular contributors, some form of formal governance will be needed. But it's too early to decide on that. Lars tends to prefer ordered discussion, democracy, and voting.

Goals

Goal for 1.0 (not changed this iteration)

The goal for version 1.0 is for Obnam to be an utterly boring backup solution for Linux command line users. It should just work, be performant, secure, and well-documented.

It is not a goal for version 1.0 to have been ported to other operating systems, but if there are volunteers to do that, and to commit to supporting their port, ports will be welcome.

Other user interfaces is likely to happen only after 1.0.

The server component will support multiple clients in a way that doesn’t let them see each other’s data. It is not a goal for clients to be able to share data, even if the clients trust each other.

Goal for the next few iterations (not changed for this iteration)

The goal for next few iterations is to have Obnam support encryption well. This will involve having a documented threat model, which has been reviewed by all stakeholders participating in the project, and Obnam defending against all the modeled threats.

Goal for the iteration that is starting

The main goal of this iteration is to add at least rudimentary encryption of chunks, before they're uploaded to the server, and decryption and validation after they're downloaded. This should use the encryption keys stored by obnam init. This is done only if the client configuration says encryption is turned on, to allow an opt-in approach to encryption for now. Later on, encryption won't be optional.

At the same time, work needs to start on using more concurrency in the client, and that means that Lars needs to learn more about Rust, specifically async Rust.

Additionally, some smaller issues will be worked on, to tackle the back log of open issues.

Commitments for this iteration

New milestone 8 represents this iteration on GitLab.

This is a one-week iteration, which is short, so commitments need to not be overly ambitious. For Lars, that means a time budget of 8 hours this iteration. Lars is committed to resolving the following issues:

• obnam#28 - large vectors should be iterators (1h)
• obnam#102 - need to have tilde expansion in config file (0.25h)
• obnam#108 - some unhelpful error messages (1h)
• obnam#109 - need to make a release (0.25h)
• obnam#110 - chunks aren't encrypted (1h)
• learn about async Rust, start planning how to use concurrency in client (4h)

That is a total of about 7.5 hours, rough estimate.

Alexander Batischev commits to working on obnam#78.

Meeting participants

• Alexander Batischev
• Lars Wirzenius