Conan: Choosing Desired Package From Right publisher

[solvingj]

This is fairly alarming:

https://www.conan.io/search?q=poco

Please consider the following....

If someone is interested in a library (such as PocoProject for example), they are likely to visit the library author's website:
https://pocoproject.org/download/

There, they might learn that the package is available on conan.io... GREAT!

Next, they might find that the actual information posted on the author's page has a mistake. For example, in this case, the author's page says:

The POCO C++ Libraries are also available via the Conan C/C++ Package Manager:
conan install Poco/1.7.6@lasote/stable -s compiler=gcc -s compiler.version=4.9

In fact, this command points to a package that does not exist:

It seems that lasote published several versions which were heavily used, but hasn't kept up with the latest one.

A person might then search the repository for the target library, and find the numerous available options from numerous "conan publishers" (as shown in my first screenshot). They might want the latest version of the library (the version suggested by the actual library author). They might then see that someone has published this latest version of 1.7.6, and select it for their project. The fact that it's been downloaded a number of times indicates it's likely a safe package.

In this case, the person would have ended up using this library:
https://www.conan.io/source/Poco/1.7.6/anonymouz/stable
http://github.com/anonymouzz/conan-poco

As I said, this is alarming. Here we have a package published by a dubious username "anonymouzz", linked to a GitHub fork of the same name. The fact that it's been downloaded by over 20 people adds to the severity of the concern. At this time, evaluating the trustworthiness of conan.io packages seems to be analogous to evaluating the trustworthiness of torrents. In fact it's worse, as conan doesn't even have badges.

I am very excited for conan.io and will continue to use it, just with extreme caution. However, I truly hope that JFrog institutes a fundamental change with publishing and identity, similar to that of Bintray and JCenter. I don't want to have to fear my package manager.

This issue is also relates to the first item mentioned specifically by Microsoft in this post:
https://github.com/Microsoft/vcpkg/blob/master/docs/FAQ.md#why-not-conan
I also hope this project considers Microsoft's points, and can now afford the time to address them with the help of JFrog. Beyond the security issue, and chaos of many versions of popular packages, I feel their other comments have merit as well.

[memsharded]

Hi @solvingJ ,

Yes, this is a legitimate concern. Regarding this we already started addressing it with the conan manifest validation utilities, but we are doing more:

• We are planning for the next release "package signing". We might not meet the deadline, because it can be a difficult task, but at least we will start working on it. This will allow to install only trusted packages from trusted sources.

• We agree that the trust of binaries from unknown users is analogous to torrents, or basically as any other source: recently even sourceforge had terrible problems with their hosted binaries containing malware/adware. You could even download pre-built releases from github that can contain malware, especially if the project is not very popular and thus not frequently reviewed.

• But we don't feel that making more difficult to contribute packages to conan.io would be the way to go, so we still allow to any user to upload contents.

• We also like the idea and probably go for it, about implementing "verified users". So users will be able to distinguish package recipes in conan.io that comes from verified users and those who come from non-verified ones. The client might also provide functionality to warn or to block packages from non-verified users.

With those things, conan will be much safer. In any case, please remember that we haven't prioritized those features yet, because actually the heavy usage of conan is in-house. Most users in production they don't use conan.io, but their own conan_server. With that approach, all those security concerns are not an issue.

Thanks very much for your feedback, I think it is very useful. Now, I'd prefer that we open specific issues for specific solutions, and start addressing them one by one:

• Package signing: https://github.com/conan-io/conan/issues/773
• Verified users: I think it would be basically this one (https://github.com/conan-io/conan/issues/780), though I might rename it to "Verified users in conan.io"

[solvingj]

That's all really great to hear! Good luck and thanks again for all your hard work on the project. Just want to re-iterate once more than JFrog's Bintray and JCenter() (for Java) service has proven to be a VERY effective model for secure OSS-integrated binary hosting. The way they link developers, organizations, and projects has been a dream for me and everyone I know so far. I recommend you leverage their model and wisdom in the future. That way you can focus on improving the handling of complexities native to C++ binaries, not trying to re-invent secure-package-publishing, which is very well solved already by JFrog.

[sourcedelica]

I'm hoping that as Conan becomes more popular, that maintainers of popular packages will upload "official" versions of their packages to Conan.io. One of the issues that @SolvingJ is concerned with with confusion about which package to choose. The way Dockerhub approaches it is by indicating "Official" packages prominently and ranking Official packages ahead of others in search results. I think "verified" is a good idea but may be orthogonal to "official".

[memsharded]

Thanks @solvingJ and @sourcedelica for the feedback:

• Yes, the Bintray and JCenter models are awesome, and certainly conan will converge towards them, maybe even fully integrate. Just we are prioritizing the integration with Artifactory which is much more requested by the users right now.

• The thing with "official" vs "verified" in conan.io packages is a matter of target. Maintaining "official" packages, let`s say for Boost, Poco, and other libraries is not something that conan should address, but they should be maintained by the community, the best would be by the original developers. In the same way the github repos are maintained by them. The way libraries evolve is much different on how OS distros evolve, and then the model would be different from the dockerhub one. The best we could do, is to "verify" that the conan account/username "boostorg" is actually owned by the Boost project, so users will get a green check for "Boost/1.63@boostorg/stable". Does this make sense?

[sourcedelica]

Yes - If it's obvious from the UI that the boostorg/stable package is the one that I should choose then that sounds good to me.

[p-groarke]

I'd also like to see "certified" packages before using this system. I'd like to use those by default, and probably have to accept manually if a package isn't trusted from a certified user. I understand you want to get as many libs on the service as possible (and fast), but I feel this is quite important.

[memsharded]

@Socapex agree. There are differents views about it, like "certified" = "account verified", or "certified" = "moderated/reviewed for quality and maintenance package". We are considering both, keep tuned.

[memsharded]

bintray conan-center addresses this issue, now conan-center will be the reference place to get "official" or at least "verified" packages. I think we can close this issue, and if something specific for the new model is needed, open a new issue. Thanks!

[p-groarke]

I wanted to congratulate you on the launch of conan-center! I think this will propel conan at the forefront of C/C++ package management. Good times :)

[memsharded]

Many thanks!