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!).