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.

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

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 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).


-- Framtiden Ãr som en babianrÃv, fÃrggrann och full av skit. Arne Anka _______________________________________________ Support mailing list [EMAIL PROTECTED] Unsubscribe at Or mailto:[EMAIL PROTECTED]

Reply via email to