conan: [bug] conan.bintray.com has invalid/no certificate and fails in redirection loop

Hey @memsharded, there is a problem with the way this deprecation is being handled, here are a few key points:

• The remotes docs page, and the “bintray is sunsetting” page doesn’t specify how to update to the correct configuration and host.
• A fresh install of conan 1.35 doesn’t sets the right conan remote by default (or not by default for that matter)

My company’s CI processes just broke out of the blue, and fixing this issue doesn’t seem to be trivial as it should be.

Can you suggest a hotfix?

Thanks

conan remote update conan-center https://api.bintray.com/conan/conan/conan-center worked for me.

So after may 1st we still will be able to use remote repository? or is there something i’m missing?

Please, do not make this change as the bintray repository will be sunset shortly and stop working. We are handling the redirection/certificate issue on https://conan.bintray.com as this will continue to work after Bintray is gone.

So, again, switching to https://api.bintray.com/conan/conan/conan-center is not recommended as it will just delay the issue. Please be patient as https://conan.bintray.com will be back as soon as possible. Thank you

Please, are there any updates? https://status.bintray.com/ still says only the scheduled brown-out is taking place, no mention of conan-center being also down.

Sorry to ask for that in github issue, I’m not sure what would be more appropriate channel to contact bintray/conan-center maintainers.

@blackliner

Is this “scheduled brown out” on purpose, just to prove a point? Everyone using conan-center through https://conan.bintray.com will not be affected by the May 1st change, but they have to suffer? I don’t get it…

The problems in ConanCenter were not expected. The plan was that ConanCenter transition was as smooth as possible, and it was aligned with Bintray brownouts, precisely to not be disrupted by such brownout. But things at this scale are always complicated and we failed to transition to the new infrastructure. Something went really wrong with DNS, certificates and redirects. Things have been reverted now, and hopefully when DNS propagate again, we can get things back to normal. We will be writing a post-mortem soon.

URL https://conan.bintray.com will keep working as usual. Besides these DNS-related issues and some maintenance windows during April, everything will be working the same. Default conan-center repository is still https://conan.bintray.com.

➡️ URL https://conan.bintray.com will be redirected to a better repository infrastructure. No action will be needed.

I am trying to help migrate a part of my companies’ team to CMake and Conan. This BS does not provide a good first impression.

So just to be clear: After the DNS changes take effect, we should still use https://conan.bintray.com as the default remote? From what I understand in the JFrog & Conan blog posts, the bintray remote is getting deprecated. So what’s the default remote we should be using ???

@keysight-matthew-giassa Yes, @SSE4 suggested same thing few hours ago. I could be added as a new feature. Thank you for sharing your idea too.

Nice! Thanks for maintaining this free infra BTW!

@aegis-dev

so the question is where is the main repository right now? I am wondering if I have to update dependency package list. For instance, ‘boost/1.71.0@conan/stable’. I found boost package indexed https://conan.io/center/boost?version=1.71.0. Where this package stored? Will I have to update it’s reference to just boost/1.71.0?

I am asking questions because whole infrastructure halted and I apparently can’t test it myself right now.

If I understand correctly, there is no alternative. We just have to sit tight and wait for a fix for conan.bintray.com… There are internal changes that the jfrog guys are working on on this server.

If your systems are mission critical and can’t handle an outage for that long, then you should definitely look into a commercial Artifactory solution.

I would say you could even use the community edition for free. So far, we haven’t had any real setbacks because our Artifactory has cached everything we’re currently using. Having a local server speeds things up, lets you store your built packages if they vary from the ones CCI makes by default, and bridges over network and server hiccups.

(@memsharded posted while I was typing…but I’ll let my end-user experience stand)

So, you’re saying, we should all abandon *NIX in our work and switch to Windows? Or, better yet, write our own operating systems? what kind of a BS argument is this?

I am saying that if you are not paying for a commercial support contract, but are using the CCI service for free, then perhaps you should be patient and cut them some slack. As mentioned up-thread, this was a planned outage for a period of eight hours. If your systems are mission critical and can’t handle an outage for that long, then you should definitely look into a commercial Artifactory solution.

I am trying to help migrate a part of my companies’ team to CMake and Conan. This BS does not provide a good first impression.

We are doing the same thing this week. We have very little trust now that anything is being handled competently. Other internal teams now cannot build or run CI, and it is going on 12 hours since this issue was opened. What repo should I point conan at and expect it to work today and 6 months from now? If it is conan.bintray.com, why can I not use that repo for several hours now?

What a mess. Anyway, it seems working now.

Please read our recent blog too: https://blog.conan.io/2021/03/31/Bintray-sunset-timeline.html

It was also announced in our blog some time ago: https://blog.conan.io/2021/02/05/JFrog-announces-sunset-bintray.html, and shared in social channels and mailing lists.

For me the issue is fixed at the moment. I like the idea with the server message in the CLI.

Thanks to @jgsogo and @memsharded (and all others) for your investigations in this problem.

By the way I recommend everyone to use a cached repository at least for your CI pipelines. If your build nodes are in the same network you will save traffic, gain speed and you can trust your pipeline in case of internet problems. Everything else is not reliable and trustworthy for me.

Btw, things seems to start getting back to normal. It seems I can install packages here again (this might be different depending on location, and DNS propagation).

@jadamwilson2 No. It’s under investigation. Please be patient.

What a mess. Anyway, it seems working now.

I’m going to wait until the 2pm PDT window closes. Some packages are available, but specific versions of other packages are not, so, at least in my own case, not everything is 100% “up” yet.

URL https://conan.bintray.com will keep working as usual. Besides these DNS-related issues and some maintenance windows during April, everything will be working the same. Default conan-center repository is still https://conan.bintray.com.

Having some search timeouts, for instance:

Hi! This is a long-standing issue (https://github.com/conan-io/conan/issues/7573, https://github.com/conan-io/conan/issues/8398) not related to the ones we’ve faced today. After moving away from Bintray this will be one of the things we will start to work on in ConanCenter (it requires changes on the server-side that we cannot implement in Bintray).

Any updates? https://conan.bintray.com seems to be redirecting to (itself?) https://conan.bintray.com

conan remote update conan-center https://api.bintray.com/conan/conan/conan-center worked for me.

Confirmation, it works. Thanks, @saukijan.

conan remote update conan-center https://api.bintray.com/conan/conan/conan-center worked for me.

So after may 1st we still will be able to use remote repository? or is there something i’m missing?

Ok, thank you, I’ll try your workaround.

I logged this too: https://github.com/conan-io/conan/issues/8908

@snailcatcher we have our own artifactory with conan-center (conan.bintray.com) as a remote but it’s not well documented how you get a particular artifact into the cache.

Can you (or anyone else for that matter) provide some insight on how to go about this?

We use a couple of strategies.

1. Let conan take care of this for you. Do

conan upload <my_package> --remote <my_remote> --all

And the cache will be uploaded to your remote. List your remote first in ${CONAN_USER_HOME}/remotes.json and conan will look there before CCI. One disadvantage of this approach is you will not get updated recipes from CCI, so I recommend periodically refreshing the recipes from CCI (say once per release cycle) and re-caching them.

1. Use the json manifest feature and lockfiles to do manual caching. We do this on CI to cache all of our dependencies in an Azure blob. It’s a bit convoluted, and we’ll probably be deprecating this approach shortly as soon as we get our on-site artifactory sorted out.

@snailcatcher we have our own artifactory with conan-center (conan.bintray.com) as a remote but it’s not well documented how you get a particular artifact into the cache.

In the Jfrog doc it suggests: access "http://<host>:<port>/artifactory/<remote-repository-name>/<artifact-path>" and the artifact will be auto-magically cached. However there does not seems to be a way to discover the <artifact-path> in conan-center.

Can you (or anyone else for that matter) provide some insight on how to go about this?

Would it be reasonable to have a feature added to the CLI tools to dump notices like this (i.e. pipe it to STDERR)? I think some Atlassian tools do this for web UI and CLI tools, and it’s pretty awesome to have. Might be helpful with respect to broadening the audience of specific noticed (e.g. planned maintenance, deprecation notices and EoL announcements, etc.).

@keysight-matthew-giassa that might be temporary hopefully, just tried again and here, it is working normally. Anyone else still experiencing issues with bintray asking for log-in?

10 minutes later and issue is no longer present (and conan CLI commands now working as they did previously).

+1 to on-prem caching BTW (i.e. local, Artifactory, etc.), as another individual noted above.

@keysight-matthew-giassa that might be temporary hopefully, just tried again and here, it is working normally. Anyone else still experiencing issues with bintray asking for log-in?

Is this “scheduled brown out” on purpose, just to prove a point? Everyone using conan-center through https://conan.bintray.com will not be affected by the May 1st change, but they have to suffer? I don’t get it…