How secure is conda-forge? Can public BINSTAR_TOKEN be used by third party to upload malicios package?

[kiwi0fruit]

This.

[isuruf]

Can public BINSTAR_TOKEN be used by third party to upload malicios package?

This is encrypted, but conda-forge maintainers have access to it. We are relying on the conda-forge maintainers to not abuse it. We asked for a per package token from anaconda, inc folks, but they don't have anyone working on it atm. cc @msarahan, @jjhelmus

[kiwi0fruit]

This is encrypted, but conda-forge maintainers have access to it.

Do you mean any recipe maintainers? If so then anyone who uploaded a package to the conda-forge and added themself to recipe maintainers could sabotage other packages? Or not? And they can only sabotage their own packages?

[kiwi0fruit]

As far as I can imagine the real passwords that are used for uploading to binstar should be set only in CI web interfaces by small number of trusted people. Do CI services allow this? Build scripts should never echo or log them (even on error). And recipes can only contain some references to that stored "passwords" so that CI service would know what to pick up from it's private settings.

That's what I could guess how it may work (I'm not knowledgeable in this area). How far is my guess from reality?

[isuruf]

If so then anyone who uploaded a package to the conda-forge and added themself to recipe maintainers could sabotage other packages?

Yes, we'd like to have per package tokens, but anaconda.org doesn't support that.

Build scripts should never echo or log them (even on error).

A PR author can't echo them. A recipe maintainer could echo them if they push to master.

[kiwi0fruit]

Looks like there are at least two options to fix this:

• have per recipe password.
• change the way conda-forge works: like recipe maintainers are no longer allowed to commit to recipe repos. They can only ping some moderators when they fixed and adapted PR for the recipe they are subscribed to. In order to lessen the amount of code to review for these moderators only commits to ./recipe/ and ./conda-forge.yml are allowed. For example the maintainer fixes the repo as a whole, updates via conda-smithy. Then when everything works fine they call something like @conda-forge-admin, please clean up and only meaningful part of the commit is left and reviewed. Then moderator locks PR for commits (is it possible?) and asks @conda-forge-admin, please rerender or manually rerenders with conda smithy.

UPD: If to implement the second option then bot autoupdater should write about changes in conda-forge workings.

[kiwi0fruit]

And by the way: is there a way to add some kind of antivirus check for built packages? Like checking on VirusTotal or something?

[kiwi0fruit]

@isuruf There is a better way to solve this issue (presumably): what if to make conda-forge-admin more smart: when user listed in maintainers says @conda-forge-admin please merge then the robot merges. In this scenario only the robot has access to the binstar password.

What do you think?

[scopatz]

Thanks for bringing this up @kiwi0fruit. I think that this discussion extends beyond conda-smithy specifically, though. Any objections to moving it to https://github.com/conda-forge/conda-forge.github.io?

[kiwi0fruit]

As discussion goes the best place for this issue would be repo with conda-forge-admin bot code. Where is it?

[kiwi0fruit]

Any progress on this?

[kiwi0fruit]

@msarahan, @jjhelmus please take a look here.

[scopatz]

The admin bot just runs conda-smithy.

[msarahan]

We are aware of this issue and are working to empower conda-forge to help fix this part of anaconda.org. There is a PR that a past maintainer had up to implement this, but no one has enough experience (nor time to gain experience) sufficient to be comfortable merging it and dealing with any potential fallout.

[isuruf]

One other option is to have a server in the middle between CI and anaconda.org which would authenticate a per feedstock token and upload to anaconda.org.

[mattwigway]

Is this issue solved, now that according to the minutes, CFEP 13 is resolved (see also conda-forge/conda-forge.github.io#993)?

[beckermr]

no security issue is ever solved, but we no longer have our token in the public. We now verify feedstock uploads have the correct shas and are only for the packages assigned to that feedstock. We also only let maintainers with the correct token do uploads.

I am closing this for now, but there is a lot that could be improved.