| hestenet (he/him) |
Via @Harald Leithner |
| dts |
:fb-wow: That's awesome. I didn't know one was happening. (I was also travelling last meeting.) |
| xjm |
Also very excited to hear about this! |
| Harald Leithner |
We at Joomla had our in person code sprint with 9 people attending in germany.We split the people in to 2 teams continuing the work started on the Hackthon in march.Small team continue the work our docker container for signing based on php-go because it's simpler then the python implementation (your rugged) container and fits our use case for the moment. This works really great including creating new key/signatures and signing releases and of course timestamps. You can find this container at https://github.com/joomla-projects/docker-images/tree/updater . We are also able to sign keys and releases which is mandatory for our workflow.The other team reworked our code changes done to php-tuf can be found at https://github.com/joomla-projects/php-tuf it combines our changes to the php-tuf upstream package where we created pull requests already and have a version which works for us. We removed the hard dependency on guzzle and replaced it with the guzzle promise so it would stay compatible with your implementation but could be used with other FileFetchers. This is needed by us to use our own http transport and don't pull the unnecessary dependency into our cms. So it would be good if this get mergedOther PRs have filed to be more SPEC complaint or relaxingOn the Joomla topic we implemented our adapter to support async file transfer for the php-tuf file fetcher. And prepared the integration of the metadata store into the cms. This Works as expected.We also re-implemented our constrain checkers into the php-tuf workflow which is currently done against our update server which provides XML files. Our constrains are filtering the provided update files based on the installed Joomla,PHP,MySQL,... versionAs bigger discussion point we have to reconsider how we handle 3rd party extensions (or even our own). At the moment we only implementing the Joomla core update to work with TUF but of course at some point we want to sign/trust our extensions too.Our possibilities are limited, we have to a couple of solutions but only 2 relevant at the first glance.Signing the root keys of an extension developer for his/her own TUF repo.Having one TUF repo with delegating trust to the 3rd party developer for there extension namespace. For this we have to understand more our delegation works in TUF and if the php-tuf client already supports it.if you have questions please ask. |
| phenaproxima |
We removed the hard dependency on guzzle and replaced it with the guzzle promise so it would stay compatible with your implementation but could be used with other FileFetchers. This is needed by us to use our own http transport and don’t pull the unnecessary dependency into our cms. So it would be good if this get mergedThis was always the intent, we just used guzzlehttp/guzzle for temporary convenience. But the only real dependency is the promise library |
| phenaproxima |
(Beyond the file fetcher, anyway) |
| xjm |
Thanks @Harald Leithner for the update! Are there any specific PR links the TUF composer package maintainers should take a look at yet? |
| Harald Leithner |
Thanks @Harald Leithner for the update! Are there any specific PR links the TUF composer package maintainers should take a look at yet?No we don't touched the composer implementation |
| xjm |
@Harald Leithner Sorry I meant any of the GH TUF packages we have in the PHP-TUF org :slightly_smiling_face: |
| xjm |
For example for the guzzle thing |
| Harald Leithner |
@phenaproxima it would be good if you have a look at https://github.com/php-tuf/php-tuf/pull/264 and merge it if it fits |
| xjm |
@tedbow @phenaproxima ^ |
| Harald Leithner |
The pull requests from us on https://github.com/php-tuf/php-tuf/pulls are #264 #259 #258 #257 |
| tedbow |
@Harald Leithner ok thanks for the update and the PRs. will try to look soon |
| hestenet (he/him) |
Raised by @xjm |
| xjm |
So the issue at the center of this is #3198340: Strict constraints in drupal/core-recommended make it harder for Composer-managed sites to apply their own security updates when a core update is not available -- it has already been committed to 9.5 and we are discussing backporting it before 9.4.0 tomorrow |
| xjm |
In a nutshell: Drupal 8.8+ sites with drupal/core-recommended pin you to exact versions of your dependencies, but 9.4+ will allow patch-level updates with Composer even without changes to core. |
| xjm |
This allows the sec team to stop handling so many releases and SAs for upstream updates. Going forward, SAs and same-day sec or patch releases will only be issued if core is known to be exploitable. |
| xjm |
And we are going to gradually move away from babysitting tarball sites' packaged vendor so much, because tarball sites are not recommended and the workaround of using Composer is available |
| xjm |
The main impact for autoupdates though is that there will be fewer core "insecure" releases and/or security advisories for update.module to respond to, and Composer STILL does not flag insecure versions the way yarn/npm/d.o/etc. do |
| xjm |
We are, or were, planning to provide signing for the "last mile" of third-party updates. In a perfect world, site owners would receive automatic updates for dependencies too. But the ecosystem is not there in terms of Composer/Packagist support. We don't have dependabot for Drupal because we are not on GitHub, and all vulnerability listings are opt-in. Scanners exist but they are the site owner's responsibility/choice. |
| dts |
Is it possible for us to leverage the data source that Dependabot uses for Composer security updates? Or does Dependabot also not know what's a security update? |
| xjm |
So I think dependabot knows if GitHub knows, if people use the GH security feature |
| xjm |
But only projects on GH would have that. No idea if we can use it or not TBH. |
| xjm |
I get "Known security vulnerabilities detected" from dependabot all the time, mostly for pipfile.lock issues with our TUF tests :joy: |
| Mile23 |
there are things like this, but then we depend on how up to date they are: https://packagist.org/packages/roave/security-advisories |
| Mile23 |
“This package extracts information about existing security issues in various composer projects from the FriendsOfPHP/security-advisories repository and the GitHub Advisory Database.” |
| xjm |
Yeah, those things are all manual PRs and optional opt in membership and so forth, sadly |
| xjm |
Maybe we could also consider advocating for native composer fixes again. The last time we did they were all "why on earth would we ever want that?" But that was many years ago and they have been more responsive to feature requests in more recent years. |
| xjm |
And now we could say "yarn has this; NPM has this; python has this; can PHP PLEASE have it?" We might be able to work with OpenSSF to create some advocacy for this as well since they are currently going through an initiative about best practices for package managers and I am sure that security releases should be one of those things. (edited) |
| Mile23 |
I wonder how it works, specifically, with the other managers. |
| tedbow |
So before this change if there was known Security release for a direct vendor dependency then there would have been a corresponding Drupal core update but now there will not be correct?So now the Contrib AutoUpdates would not have release to update to so site owners would have to update via Composer directly. |
| tedbow |
@xjm or is :upvote: not right because there would still be a Drupal security release if Drupal core was know to be affected? |
| xjm |
So the best way to talk about this is to look at our SA history |
| xjm |
None of these three advisories would have existed if this policy had been in place before:https://www.drupal.org/sa-core-2022-006https://www.drupal.org/sa-core-20... |
| xjm |
However, this advisory would still ahve been issued: https://www.drupal.org/sa-core-2021-001 |
| Mile23 |
so basically we hear there’s a guzzle issue so we say composer update drupal/core-recommended -W , but if there’s a non-composery solution we get a new release? |
| xjm |
In the future, those first three SAs would instead be released more like https://www.drupal.org/project/drupal/releases/9.2.10, on a timeline of a few days to a few weeks, instead of with a security release and an SA on the same day. |
| xjm |
(With Symfony, bless them, we always have the time to actually validate for sure what our risk is, versus having to panic and release an advisory "in case" as we do now for all this Guzzle stuff) |
| xjm |
So in the future there won't be "just in case" or "because of XYZ contrib making outgoing HTTP requests" SAs for core anymore. (edited) |
| tedbow |
so in the Guzzle examples above would there still be post on drupal.org instead of a release or nothing from Drupal.org until a release a few days or weeks later? |
| xjm |
And yep, also what @Mile23 said. If core IS vulnerable -- especially if core itself needs code changes -- or if it's like CKEditor or something else outside composer that's committed to HEAD, there will still be a core SA. |
| xjm |
@tedbow What do you mean "post"? |
| xjm |
The updates would be in the next patch release basically. And the next patch release would contain more than just that fix, and might be either off-schedule or on the regular schedule depending on how bad it is for contrib etc. (edited) |
| Mile23 |
will everone have to start subscribing to the guzzle security email list to find out, or will there be DO security announcements? |
| tedbow |
@xjm was wondering if there would be PSA like this https://www.drupal.org/psa-2019-09-04 |
| xjm |
It is already outside our policy to provide security advisories if core is not vulnerable. We have just been doing it anyway basically. |
| tedbow |
k |
| xjm |
Refer to https://www.drupal.org/psa-2011-002 for the official sec team policy on third-party code. The key thing was that in Ye Olden D7 Days, third-party code was code the site owner downloaded themselves, manually. Versus D8 core downloads it for you and you don't get a choice. |
| xjm |
So we've had to evolve over time about what we handle in Drupal.org's package manager, versus what we tell people to just use the native package manager (Composer) for. |
| xjm |
Just the native package manager in this case has a serious hole where a feature should be for security info. |
| tedbow |
well expect with AutoUpdates we are telling some people not use the native package manager directly or least less often. but I guess if the exploits are not known in core maybe that is fine |
| xjm |
The thing is that contrib might still be exploitable. A separate topic is whether contrib should be getting SAs instead, but the security team definitely does not have the capacity to essentially re-issue every CVE in the PHP ecosystem. |
| xjm |
So we should think about how we can get to a place where the CVE itself is the source of truth for autoupdates' purposes (via Composer or dependabot or something else), rather than the d.o SA only. |
| xjm |
I don't think this needs to block the initial core release or anything, but we do need to address it in the long-term somehow. |
| tedbow |
sounds good |
| xjm |
It's also about potential exploits in custom code. All of these guzzle advisories could affect your site if you are making custom outgoing HTTP requests especially, even if no code from drupal.org had any vulnerability as downloaded. (edited) |
| dts |
It's also about potential exploits in custom code.This is a really good point -- the kind of thinking I'm always glad to have xjm around for. :slightly_smiling_face: |
| David Burns |
:wave: |
hestenet, Harald Leithner, dts, xjm, eiriksm, Christopher Gervais, phenaproxima, tedbow, Mile23, David Burns
Comments
Comment #10
hestenet