Posts by composite

1) Message boards : Application Code Discussion : milkyway released under GPLv3 (Message 52471) Posted 14 Jan 2012 by composite Post: just recompute the result's signature with the public key in the validator A less secure way... That was a tad hastily written, now I have to correct myself. Nothing can stop a patched BOINC client from falsely reporting the identity of an application. -- ill composed is well disposed
2) Message boards : Application Code Discussion : milkyway released under GPLv3 (Message 52470) Posted 14 Jan 2012 by composite Post: So, GPL doesn't seem to align well w/ volunteer optimizing on the scale necessary for multi processors and platforms to support a community. Of course we all know there's also another approach akin to the saying "If a tree falls in the woods & no one hears it....." (Not endorsing this option, just acknowledging reality) It's the project admin's responsibility to listen for falling trees. http://boinc.berkeley.edu/trac/wiki/CodeSigning BOINC's code signing procedure prevents unauthorized binaries from doing work, at least when the BOINC client isn't being fooled. A volunteer assumes the risk of joining a reputable project (not secretly producing Bitcoin for the project admin, for example). But even projects exploiting volunteers for profit should be concerned about resources being misappropriated by unauthorized clients. This URL mentions server hacking, however botnets pose another risk for subverting BOINC clients. As a volunteer, I expect a project's admin to sign code to protect my interests. My concern is that the cycles I volunteer actually benefit the projects to which I subscribe. I would find out if my BOINC credit rate drops without explanation, which is what should happen when a machine's computational power is taken over by an unauthorized client, whether I've been duped into installing an application that claims to produce credit faster, or the machine has been subverted by a zero-day exploit. So admins, don't just complain about code getting out of your control, take charge and sign your binaries. Developers who want to increase credit production in a fair manner will be motivated to cooperate and contribute back their useful improvements. On the flip side, BOINC doesn't seem to have made code signing mandatory, or it isn't being enforced in an effective way if a rogue client can simply install it's own signature file on a volunteer's machine. http://boinc.berkeley.edu/trac/wiki/AppVersionNew Does the BOINC client sign completed results with the application's signature so the server can verify authenticity of the application? Then a project server can simply ignore a returned result if it isn't signed with the project's public key. No need to use the private key for verification, just recompute the result's signature with the public key in the validator. This will impact throughput of the project server, but that's the price to pay for security. A less secure way would be to sign results before sending them to a client and have the client verify the application, but this does not protect from a patched BOINC client and it saves no work at the server.