This meeting:
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Tuesday at 1700 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: #3170174: Automatic Updates Initiative meeting on September 22nd
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.

:one: Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion.

Comments

hestenet created an issue. See original summary.

hestenet credited Mixologic.

hestenet credited drumm.

hestenet credited dts.

hestenet credited dww.

hestenet credited eiriksm.

hestenet credited xjm.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented
Status: Active » Fixed

Meeting minutes

0️⃣ Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.

hestenet (he/him) Tim with the DA, here in Portland, OR - acting as one of the initiative coordinators.
eiriksm howdy. Eirik from Norway. Following out of interest in keeping up to date
xjm :wave:  Here although I'll be AFK on my phone a bit to get breakfast
dts waves
dts Here from SF.
dww Derek from the US. Following along.

1️⃣ Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion.

xjm Ted, David, and I joined the TUF community meeting --  we could recap that briefly. I nominate @dts. :slightly_smiling_face:
xjm Also, the PSA issue is RTBC and just awaiting final review :tada:  Worth a thread.

2️⃣  :calendar: November 10-14 we are planning another contribution week for PHP-TUF - If you have not received an invite and would like one - please comment here and I'll add you to the calendar!

3️⃣ Recap of the TUF Community meeting!

hestenet (he/him) @xjm proposed this one - and has nominated @dts to provide a summary for us :stuck_out_tongue:
dts I see that I've been nominated.
dts The agenda and minutes are available here: https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw
dts In general, the meeting covered cross-project concerns: specification modularity, integration of TUF with PIP (Python's package manager client), and how decisions in TUF for aspects like signing (e.g. requiring canonical JSON) reverberate through various implementations in Python, Rust, and PHP.
xjm They're also going to plan another meeting in a month, probably at 11:00a ET this time rather than noon
dts Overall, I'm super happy to be part of this growing community. I think TUF has great engineering behind it, and it cares about the use cases and varied implementation targets (beyond Python) in ways that suit Drupal's needs quite well. (edited)
hestenet (he/him) Any revelations or tidbits that are particularly relevant to our php implementation - or is our approach still on the right track?
dts I think we're very much on the right track. Rust is apparently taking the same approach of having externally injected data (like the sense of "now"), and the Python devs aren't all that happy with the current Python code structure of the client -- validating our decision to work from the spec instead of porting the current reference implementation. (edited)
dts They're also looking at dropping the need to canonicalize or parse JSON, which would help us.
hestenet (he/him) That's great.
dts Well, "dropping" in the sense of allowing a mode of operation with a different signature scheme that doesn't leverage cJSON.
dts Our biggest risk with TUF continues to be, IMO, that it's more than Drupal needs -- but I still prefer a well-specified approach that's excessive over continuing to roll our own a la PHP-Signify.

4️⃣ The issue to move the PSA feed into core is now RTBC! (thanks to some hard work by @tedbow!) #3041885: Display relevant Security Advisories data for Drupal (edited) 

hestenet (he/him) @xjm raised this for celebration :slightly_smiling_face: Good chance for any final reviews.
dts Woohoo!
xjm I'd especially like to know if @drumm has any final thoughts and I might also have Ted internally demo it for Emilie who's joining our team this quarter :slightly_smiling_face: But my own review might be delayed due to the alpha. Still might consider it as an alpha backport to have it in 9.1 potentially.
hestenet (he/him) (Yay Em!)
drumm I think it should be in a good place based on various Slack chats. I should see if I can read through the patch.
drumm Looks good as far as I can tell.

Yeah, this feels a lot like composer itself needs this security built into it

dts Yeah, I'm not a fan of the arbitrary code stuff in Composer.
dts We've gradually been moving away from it in Fedora.
dts (Most arbitrary RPM scripting is gradually being replaced by high-level directives.)
mixologic composer or arbitrary code?
dts Arbitrary code
xjm @mixologic Oh yes. We've asked lots of times for various security features in Composer and been shut down.
xjm Apparently the arbitrary code only runs for the top level, though, which is something.
xjm Can't remember who corrected that for me after one of my my sessions last year
dts I wish I understood a bit better how Drupal leverages that code and how other Composer packages tend to.
mixologic yeah, plugins have to be a root requirement IIRC
mixologic for drupal its scaffolding, vendor hardening, and the ‘project message’ thing
mixologic (out of the box), in reality, cweagans/composer-patches is a big one a lot of people rely on.
dts I mean less how Drupal leverages in terms of what it does and more in terms of how it plugs into Composer.
dts Presumably, we must add some plug-ins as part of composer create project?
mixologic Composer emits events, the plugins subscribe to them and act in response to specific ones.
mixologic Our templates have the basic plugins
dts Is it possible for arbitrary packages to require plug-ins as part of installation/dependency resolution?
dts Or, perhaps any other path for arbitrary code?
mixologic https://getcomposer.org/doc/faqs/how-to-install-untrusted-packages-safel...
dts So, untrusted packages can request/require a plug-in, which you can disable -- at the risk of breaking the package's expectations.
mixologic Im pretty sure that arbitrary packages cant depend on plugins
mixologic but that might not be true. Ambiguous when it saysPlugin packages are automatically loaded as soon as they are installed and will be loaded when composer starts up if they are found in the current project's list of installed packages.
dts Why would I need to disable plugins while installing an untrusted package, then? Is the concern that another, existing plugin might allow the untrusted code to run?
mixologic depends on ‘current projects list of installed packages’ means all, or just the root requirements
mixologic Yeah, it must be that an untrusted package can come with untrusted plugins/scripts that will get executed
dts In any case, whatever we would need to do to relax HTTPS expectations in Composer would be the same places we could provide alternative verification mechanisms. So, I think it's easier (or at least more elegant) to just make Composer be able to run on TUF than to gut Composer's existing security and shore it up elsewhere.
dts Plus, it creates less risk around inadvertently using a "Composer without HTTPS or TUF" as if it's safe.
mixologic one handy thing is that we’d be running composer from within drupal (i.e. as a dependency, and not as the phar file), so, potentially could extend/override classes.In that case, we’ll need to sign the metadata on the infra when we generate it.
dts Correct. I think figuring out how to TUF-enable Composer is one of our biggest challenges. We've experimented enough to verify that we have access to the right mechanisms to do it without literally hacking Composer, though.
mixologic i.e. extending/overriding/implementing interfaces etc?
dts Correct, mostly for the appropriate repository client and package download classes.
dts I think it's possible to handle entirely with a plugin.

Participants:

hestenet, eiriksm, xjm, dts, dww, drumm, Mixologic

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Component: Code » Meetings