[erlang-questions] Right direction ?
Thu Sep 29 16:29:15 CEST 2011
On Thu, Sep 29, 2011 at 3:30 PM, David Goehrig <dave@REDACTED> wrote:
> On Thu, Sep 29, 2011 at 3:19 AM, Joe Armstrong <erlang@REDACTED> wrote:
>> The level of protection that interests me is:
>> a) - protection against shooting yourself in the foot
>> (ie non-malevolent mistakes) - such as rsyncing the
>> wrong version of the code
>> b) - protection against simple malevolent attacks (password guessing,
>> exposing plain text passwords etc.)
> a.) also requires that it be EASY for developers to support it. Requiring a
> $1000 CA cert just to publish some open source code is a sure way to shoot
> yourself in the foot. For a.) to work we need:
> * A way for a developer to easily publish a SIGNATURE so that all people
> everywhere can download and verify the code against it
> * A way for a user to easily verify that a particular bit of code matches
> the SIGNATURE from the location where it was acquired
> Both of these typically are done by sticking a MD5 sum or SHA1 has in the
> directory in a file along side the original file, so that you can verify
> that the file has not been modified from the version at that location. The
> problem here is that if both the package and the signature are tampered
> with, you don't necessarily know.
You could sign the MD5 sum of the beam with (say) an RSA private key
and this could then be validated by anybody who has your public key.
Then you only have to distribute your public key :-)
> For these sorts of problems, DNS seems like a good idea in so far as it is a
> distributed database that is publicly accessible, and there exist tools for
> detecting when someone is messing with it. A dets table with a set of SHA1
> hashes of every module loaded that simply refuses to load the module if the
> signature changes can be useful. A process that periodically checks DNS for
> 3rd party modules to notify you of changes can be really useful, as it
> becomes a way for a developer to notify you of security patches, bug fixes,
> deprecations, and all sorts of other maintenance issues that will threaten
> your project over time.
> I'm almost done with a proof of concept of such a service. Maybe next week
> I'll release a public beta.
> -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
More information about the erlang-questions