Package verification

[iandunn]

I think wpackagist.org is a great idea, but I'm leery of implementing it in any of my projects because, as far as I can tell, there's no way to verify that the packages checked out via Composer are identical to the canonical versions in the WordPress.org repositories.

If I were an attacker, I think wpackagist.org would be a tempting target, because it's popular among developers, but probably doesn't have as many resources dedicated to keeping it secure.

Do you have any thoughts on this problem, or possible solutions?

[iandunn]

@Rarst, @swalkinshaw: I'm curious if you have any thoughts on this. Am I being overly paranoid here, or missing something that is giving you enough confidence to use this?

[Rarst]

Repo itself had security issues in the past and is much more lucrative target than wpackagist will ever be. Some people consider whole Composer model to be "insecure". Nothing is completely secure, unless it's disconnected from network, turned off, and locked in a safe.

I find risk acceptable for practical use myself, that's all. :)

PS Composer is quite explicit that it is still developers' responsibility to verify what the heck they are putting in their production, it helps us but it doesn't think for us.

[iandunn]

Repo itself had security issues in the past

All systems have security bugs, that's unavoidable. The thing that gives me more confidence in the wp.org repo infrastructure is the amount of resources and experts dedicated to keeping it secure. I'm guessing that WPackagist is a side-project for Outlandish, rather than something they spend a lot of time hardening, monitoring, etc.

Repo [...] is much more lucrative target than wpackagist will ever be.

I agree with that, but that doesn't mean that WPackagist isn't still a target. It may even be a more attractive target in certain conditions, like a targeted attack.

Nothing is completely secure, unless it's disconnected from network, turned off, and locked in a safe.

That's true, but just because you can't be 100% secure doesn't mean you accept any and all risks.

Composer is quite explicit that it is still developers' responsibility to verify what the heck they are putting in their production

Are you referring to the whole replace debate? If so, I think that's a different kind of situation than this. But even with replace, they eventually fixed the vulnerability. That was also only an issue if it was being used incorrectly (automated composer install tasks instead of composer update)

I guess from my perspective, I feel like I should be able to trust my tools. If I ask for package x, I should have a reasonable level of confidence that I'm going to get x, without having to manually verify that it's doing its job correctly.

I do really like the idea of WPackagist, but If I have to manually verify that it's not installing malicious code, then it's easier to just use different tools where I don't have that burden, like WP-CLI combined with custom Bash scripts.

I find risk acceptable for practical use myself, that's all. :)

Fair enough :)

I still feel uncomfortable with the risk, but I can definitely see your perspective too.

[Rarst]

Are you referring to the whole replace debate?

No, I mean that Composer overall is quite aware of level of risk in such relatively open system. In other words the level of risk you are pointing out is acknowledged as inherent in Composer ecosystem design.

Clearly for many people and purposes it's acceptable level of, but if you would prefer something more locked down sure. :)

I also want to point out wpackagist isn't necessary to use Composer with WP repos, it just automates away a lot of menial work maintaining package records.

[iandunn]

wpackagist isn't necessary to use Composer with WP repos

Yeah, I've been considering just defining custom repositories in composer.json. I may end up doing that instead of WP-CLI + Bash.

[khromov]

@iandunn You can verify that WPackagist sends you the correct URL:s by checking composer.lock file. All dist url entries should start with https://downloads.wordpress.org. If you are really paranoid you can easily parse the lockfile (it's JSON) and verify this.

[khromov]

@iandunn There is now a discussion regarding adding checksums to plugins and themes, which we could piggyback on top of once it's in place. (Composer already supports package validation, so it would just need to be integrated.)

https://make.wordpress.org/cli/2017/09/26/wordpress-plugin-and-theme-checksums-project-announcement/

[NoelLH]

I've moved this to (new) Discussions for now because I'm not completely clear what the specific proposal for Wpackagist is – though I like the idea of adding an extra level of protection against package corruption as defence in depth against any possible Wpackagist security bug.

It looks like wp checksum {type} is now implemented and so we could consider a PR that uses it to check a package contains what it's meant to.

The main thing I'd like to clarify for an enhancement issue is whether the concern / suggestion is:

• interference in Wpackagist's retrieval processes -> we should validate checksums before persisting any package data in the Wpackagist DB; or
• interference in the download process -> perhaps some separate Composer plugin should offer a tie in with the checksum command to allow devs using Wpackagist to locally validate what they ultimately received and saved in their local projects