Toad wrote:
The fundamental issues revolve around changes to source code.
Only in theory. In practice, the source code only affects your reputation. The binary code affects the users. If you only protect the source code (which is also what might get reviewed at some point or other), you will only be protecting those users who are really careful and compile from source and don't really need protection. Protecting the binaries is much more crucial.
Of course I don't mean that protecting the source is unimportant. I have the impression - from nowhere - that freenet is developed by a small and rather tight team. If that is so, then commits can be based on personal trust. If, on the contrary, source can be committed by not fully trusted people, then there is no end to the auditing requirements before you can call the resulting binaries safe.
They're
not easy to deal with. Specifically, no matter how deeply you secure the
server, you can't certify every single build as free from unexpected
code.
It is human to err and, as builds 5085-5087 prove, errors will happen. However, as long as the developers are well-willing but imperfect friends, we can trust that there will be no spycode sending extensive reports to nsa.gov. There is a fundamental difference between bugs and malicious code. I am willing to take the risk of accidentally introduced security flaws, but not the guaranteed-to-work intentional security breach that an outsider would put in freenet if he could.
Hence the need to ensure that for example mails get sent out EVERY time a CVS commit occurs, and if they bounce it will keep trying to send them forever. How can we achieve this?
As far as I know how mail servers work, you can't. Then again, why would you need to? Really, how many people have commit permissions? As long as they are fewer than three dozen or so, you can have a cryptographically secured system of notification acknowledgements which leads to phone calls for missing acknowledgments after a certain threshold. The problem is not some notifications not reaching their destination, but rather commits happening without anyone at all being notified.
I think that what you are really saying is that you ned to ensure that nothing can be committed without at least some notifications going out. If the cvs server gets hacked, you can't. One way around this is what I wrote about remotely stored md5sums of all files. The way cvs works sabotages this though (existing file unchanged, newer file present but not md5summed to begin with).
Z
-- Framtiden Ãr som en babianrÃv, fÃrggrann och full av skit. Arne Anka _______________________________________________ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
