Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And what would having the source code change?

Unless you host the data yourself, if you don't trust Wuala there is no guarantee the binaries you use are built from the source code you have.



You can see the client code and confirm that it actually encrypts all of the data and use your own copy rather than their binaries.

Technically if the client is not sending not encrypted data and encrypts without a foul, then nothing they can do on the server-side can cause leaking your data.


Just two ideas on top of my head:

Through auto updates you can make sure that you get the backdoored version or you can have an exploit within the software to allow "silent" remote updates (good luck finding that).

So well... Either you do it end to end, or you trust the third party.


Nobody sane wants software to auto-update, especially not security-relevant software. This is in particular true if you reviewed the source code of the software at one point in time.

Furthermore, for the software to be able to even auto-update, it would have to be able to change its own binary. I don’t know how this particular piece of software works, but it is possible to run FUSE ‘drivers’ as a user on Linux, with the binary safely sitting in /usr/bin, hence removing any possibility to auto-update (if you don’t do shady tricks like placing an ‘updated’ binary somewhere and changing the user’s PATH – and even that could – in theory – be avoided by mounting all user-writeable things noexec).


From http://www.wuala.com/en/download/linux:

> The package installs Wuala and registers our repository for further updates.

This is even more harmful that it sounds, as someone who has repo access (be it some evil staff member or, more possibly, inturder) may push not only malicious Wuala build, but any package with higher version number than in other repos (say, a linux-image-999.999 with a bundled rootkit) and if user was incautious it will be installed on system update.


That is not really auto-update (only if you enabled it system-wide) – and after reviewing the source code, which is necessary anyhow to make sure it is actually ‘secure’, you would then remove the file in /etc/apt/sources.list.d and be happy :-)


Use apt pinning


If there were a weakness in the client, it would be more likely to do with key management --- leaking a portion of the key (as Lotus Notes did once upon a time), generating keys from a non-obviously restricted set (viz. the infamous Debian "weak random generator" bug[1]), or possibly something more subtle. The presence of these behaviors might not be obvious from casual, or even careful, attention to the source code; the Debian thing was, by all accounts, just a bug, which nevertheless persisted for quite some time.

[1] http://www.debian.org/security/2008/dsa-1571




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: