Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to ensure proprietary packages are not pushed to a possibly public S3 bucket? #108

Open
hasufell opened this issue Mar 3, 2020 · 4 comments

Comments

@hasufell
Copy link
Member

hasufell commented Mar 3, 2020

Afais there is no explicit check or option for this. Implicitly it seems that cabal-cache ignores all local packages, which, IMO, might actually be a bug that has gone unnoticed?

https://github.com/haskell-works/cabal-cache/blob/1241aaeabab514df473cfa50d1e47baf5db16d4a/src/App/Commands/SyncToArchive.hs#L125

This will return False for local packages, because their storepath points to something like ghc-8.6.5/foo-inplace-3.0.conf (but that exists inside dist-newstyle). The function then appends this path to the store path (not dist-newstyle) and there it doesn't exist.

So two questions:

  1. Is this expected or a bug?
  2. How to ensure only hackage available deps are ever pushed?

Edit: afais, Package.style is set to "local" for local packages: https://github.com/haskell-works/cabal-cache/blob/master/src/HaskellWorks/CabalCache/Types.hs#L27
Maybe this should be used for distinguishing?

@AlexeyRaga
Copy link
Contributor

As far as I remember we do ignore local packages and do not archive them intentionally.
The intent of cabal-cache is to preserve/reuse the "global" cache, that is usually in ~/.cabal/store.
dist-newstyle is considered a "project business", when you do cabal v2-clean it is all gone, etc.

@hasufell
Copy link
Member Author

cabal-3.4.0.0 won't treat things defined in source-repository-package as local anymore, so this has to be re-evaluated and tested. (ghcup has cabal-3.4.0.0-rc1 if you want to try it out)

@newhoggy
Copy link
Collaborator

I haven't had much experience with private packages.

Do you know of a good way to tell private and public packages apart.

The local/hackage package distinction is a not good way to tell if a package should be excluded from the cache because it's fairly common to local packages public projects too.

@newhoggy
Copy link
Collaborator

We handle proprietary code by using a private S3 bucket and avoid syncing to public buckets from private builds.

It is possible to sync down from multiple buckets so you can sync down both public and private S3 buckets in the same build.

Admittedly there is no way to prevent accidental syncing, so it would be good to have a solution for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants