[parley]

> Client code will be open source.

On the link you provided I found the following:

"Parts of the programm relevant for security and networking actions will be open source."

"Parts of the program" might not do it for everyone (me included). Will anyone be able to audit the full source code of the client and compile it themselves, like e.g. tarsnap? Otherwise I fear the usual trust issues arise.

If I missed some information at your linked site which says the entire client will be open source, then please correct me.

[mariusblaesing]

You can still tell what exactly happens. Two separate processes might be used: one for crypto + network which is open source, the one manages synchronisation (which is the secret sauce of all cloud-sync services, if it works really good).

Updated the FAQ: https://boldshare.com/?lang=en#faq

[parley]

I think there's plenty of room for the larger discussion about how much we actually (ought to) trust a lot of our closed source software that runs free and non-jailed on our computers day in and day out - and recent events haven't affected that viewpoint very much in either direction. However, data synchronization software gets tougher love from everyone these days for apparent reasons.

I read the updated FAQ and saw the note about blocking network I/O for the closed source process. If the closed source process in your client were locked down in such a way that it was only ever invoked from the open source process and had no way of doing any I/O whatsoever (network or otherwise) except with the open source process (where what goes in and comes out can be audited), then I'd agree this sounds quite interesting.

I'll be waiting as well, and sincerely hope you deliver something nice!

[StavrosK]

You won't know if the other process is transmitting your key, though.

[mariusblaesing]

Communication between open and closed source processes runs via IPC. Since all the IPC functions are declared in the open source part, you can exactly check what data is exchanged between the processes -> You can see that keys are not transmitted.

[StavrosK]

How can you check that the closed-source process won't ever read the key from the disk without elaborate contortions?

[mariusblaesing]

What should it do with it? It can't send it anywhere: Block network access for that process if you don't trust it.

Key won't be accessible on disk anyway, only in RAM during crypto and will be destroyed immediately afterwards.

[StavrosK]

You can make it so that it will only store the key in RAM, but then you'd have to enter the key every time it launches, making automatic backups impossible.

Although, I agree, if you only allow the open source network access, AND can ensure that the key won't somehow be smuggled in the data the closed source process sends, you're probably fine.

[StavrosK]

Hmm, yeah, part of the program might as well be none of it. Ideally, I'd want to be able to compile it myself and use the resulting binary, or have the client be in Python or something like that.