Build artifacts will be removed by extraneous file purging

[sebmck]

Dunno how to solve this.

[sebmck]

One way will be before/after we run install scripts to diff the file system, and populate a file with a list of build artifacts. We can even cache these somewhere.

[sebmck]

cc @chenglou

[chenglou]

@jordwalke @yunxing

[yunxing]

what do you mean by "extraneous file purging" ?

[sebmck]

Basically when we're doing package linking and we find files that shouldn't be there then we remove them, this basically includes anything not in a package tarball.

[bestander]

A crazy idea: can we do scripts execution on .kpm folder before linking?

On Friday, 19 August 2016, Sebastian McKenzie [email protected]
wrote:

Basically when we're doing package linking and we find files that
shouldn't be there then we remove them, this basically includes anything
not in a package tarball.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#231 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWMo4OUWU-KVN4e8tXLK9ffvp-8fSks5qhiYjgaJpZM4Joq9T
.

[sebmck]

@bestander We'd have to setup a node_modules for the modules in the .kpm cache. My idea is to diff the file system to work out what files are build artifacts and then copy them into our global cache, subsequent kpm installs will then pull them in and it should work seamlessly.

[yunxing]

@kittens Interesting idea. It would be better if the cache are transferable (we can even copy a cache over to a CI machine). Dealing with non-relocatable binaries would be fun, though. We could provide a way for package owners to "opt-out" the cache.

Another way is each package can provide a list of "cache-able" artifacts after installation. Packages can choose to auto-generate the artifacts on the fly by a fs diffing tool we provide.

[yunxing]

A crazier idea, but are used in other package management systems I've seen before is that to allow users to specify the provider of the cache. it defaults to be local fs cache. But we can even implement a CDN, or a memcache cloud as the cache provider.

This way, if we are deploying a package to thousands of machines, we can still leverage the shared cache.

[sebmck]

How would that work from a security perspective? How would we verify the integrity of build artifacts?

[yunxing]

Depends on the implementation of the cache provider. I can imagine a trusted cache publisher (possibly the package owner, or a central build server) will have to sign on the artifacts, or at least the top level hash of those artifacts.