On 6 Mar 2012, at 21:17, Donald Curtis wrote: I was talking in #emacs today and realized that because EmacsWIKI has no authentication method, anyone could put in some very bad elisp to one of the packages that we package from EmacsWIKI. Sure, for the most part we believe everyone is trustworthy, but there is no validation or verification from our end. So as a rule I am migrating some of the EL packages to personal git repositories with a small script to update them periodically. I feel like this is a better approach and something I hadn't thought about.
Yeah, that's indeed a potential concern. I've been through all the same loops, from el-get to a home-rolled periodic-downloading solution like yours, and finally figured I just wanted everything in ELPA packages. The installed code is just as risky, but I gain in terms of installation convenience. I doubt anyone expects an ELPA archive to vouch for the safety of every package it hosts.
Now, one approach would be to have a separate repo for emacswiki-sourced packages, and provide a disclaimer. But really, a developer audience is typically happiest with a low-friction loosely-authenticated repository of up-to-date libraries, such that each developer can either blindly take the latest code, or choose "known good" versions of libraries on his own.
Note that any code currently packaged for Marmalade could have been tampered with, because there's no guarantee that the initial uploader of a widely-used package is the author, nor that he even uploaded the original code.
At least in Melpa the emacswiki-sourced packages are guaranteed to have been built from the original upstream source, for which some auditable version history is available.
My personal approach would be to build Melpa's user community as quickly as possible, and trust that it will figure out how to effectively watch for - and even avoid - the problem of malicious code.
-Steve