[erlang-questions] Right direction ?

[David Goehrig]

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.

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.

Dave

-- 
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110929/683e186f/attachment.htm>