On Tue, Jun 9, 2015 at 6:32 AM, Chris McCormick chris@mccormick.cx wrote:
On 09/06/15 11:33, Jonathan Wilkes via Pd-list wrote:
How does what you're working on compare to apt?
It's a bit like a terrible, half-assed, buggy, GUI-only version of apt written in an ancient scripting language and missing 99% of the features. It's designed to download Pd externals, Pd GUI plugins, and Pd abstractions, but not other types of software.
On the up side it runs on the same platforms as Pd does and integrates tightly with the UI. Basically the same idea though.
IOhannes yesterday submitted some feature requests for us to integrate deken with apt. Vapourware: when users are on a Debian based platform the search should also return results from an apt search so that they can optionally install externals from Debian packages instead of puredata.info. He also kicked off the "intent to package" to get deken into Debian:
https://bugs.debian.org/788075
As an Ubuntu user myself I am pretty excited about both of those things!
[Also a bit nervous at the prospect of more humans being subjected to software I wrote.]
I'd really prefer a decentralized repo to match or exceed the security properties of apt.
That would be excellent. A pie in the sky idea is one that stores packages in some type of anonymous torrent-cloud. Patches welcome!
Probably I'm thinking of the word "frictionless" in a different way than you mean it. For example, if you make the external publishing system frictionless, you greatly decrease the cost of attack. Someone can try to upload an evil external, and if they fail, they can just try again later.
Additionally, you raise the value of a successful attack. For example, an evil external could rename your tcl procs and redirect requests for any subsequent externals to an evil mirror. (And even if you don't allow writing over the tcl plugin file, those evil externals can rename the procs on Pd startup every time the user loads one of them in a patch.)
Yes, that's true.
When you let users download and run binaries compiled by arbitrary people you open them up to danger. I have thought a lot about this with respect to deken and here are what I hope are mitigating factors with some bad excuses thrown in for good measure:
- There is a warning prominently displayed when you launch the
deken externals search interface: "Only install externals uploaded by people you trust."
- Uploaders have to have an account on puredata.info which provides a
level of community accountability. The search systems tells the user which username was used when uploading the package. We can tar, gzip, and feather anybody who uploads an NSA compromised binary. Get your pitchforks & flaming rags ready everybody.
- The uploaded packages are sha256-summed and the sum is uploaded with
the package. At the moment this information is not used but in future users can verify with the developer that the same version they have is the one the developer actually uploaded, if they want.
- Vapourware: there is a feature request for optional GPG signing of
the package files. This provides an additional level of trust and verifiability where you don't actually have to ask the developer, you can just check using their public key.
- At the end of the day of course, it is about trust between users and
developers. Users who download Pd binaries from Miller's site trust that he won't inject obscure-music-nerd-spying-software from the NSA into his binaries.
- Every other package management system also faces these same issues,
as does "I am going to download this random Windows executable and double click it with impunity what could possibly go wrong". We can try for best-practice (or better!).
Do you already know the git torrent protocol: https://code.google.com/p/gittorrent/ and http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentral...
I think the with this goals in mind git torrent is worths to give it a try.
cheers husk