JanZerebecki added a comment. Copy of the etherpad:
(missing start of talk, a minute or so) Step 4: CI job that automatically triggers after changes to core or ext * run composer update and push changes Step 5: Update BC from steps 3-4 Are these sufficient examples? Can people imagine difficulties? * If files are added to vendor, how do we deal with this in code review/security patches? ** Deployed as a security patch * We would keep this strategy, no automatic composer run Questions about the RfC in general? * Bryan: one of the issues we got to when discussing this last was which use case is being optimized * Relying on GPG tags for repos doesn't cover many vendor things ** System that Jan is proposing is a Debian style web of trust to composer usage where we rely on GPG hashes to authenticate code ** For composer things that aren't in that web of trust there would need to be a legacy system. Maybe run mirrors. Is that least sane? ** There's an inherent problem with trust if you're downloading vendor packages (?) If we want to make sure we're only using code we intended to, we need to sign it * Is there an open upstream issue for this? ** Basic sentiment is that composer is not designed to support ** all issues regarding verification/authentication of packages are lumped together *** a lot of ideas and no direction *** Some like Jan have given a proof of concept but it went nowhere ** Not a lot of interest upstream There are components already that are signed * e.g. phpunit We would need to sign some vendor components but most are ours already Can we just run some proxy for upstream components? * Same problems with verification What do you do now? * I don't update vendor. Main driver use case is WikiData/WikiBase * double code review problems Problem with moving to composer components is the overhead of more work * much easier to develop a new MW ext than to create a component * making this easier is key to adopting new conventions Counter-proposal was drop GPG * From security perspective would be insufficient. Jan wouldn't want to advertise this solution Was proposal to start doing tag signing? What? * Automate vendor updates using signed git tags, modifying composer ** control of keys etc. * Would it bea Jenkins job? Yes, updates to core or anything that has composer.json ** Possibly before BC deployment There are packages we don't control and fundamental rewrite of composer * It's not a total rewrite. There are a few places to change to support this (around finishing of download; introduce verification) ** There are problems current with the implementation of verification in composer (succeeds when it shouldn't) Getting support into composer is hardest part but signing should be easier * Signing might be easier for repos we control but not 3rd parties * We can trust 3rd party keys or make clone (mirror) of repos and add signing following security review * e.g., phpunit ** on WMF servers we'd maintain clone of source repo ** sign it ourselves (after review?) ** in MW vendors composer.json use stanza for copying it from our mirror We could package? ** When debian packager packages something (e.g. phpunit), where do they get the code form? *** Disconnect. You can verify at the point of installation once or have to verify it every time. Verifying every time has more potential for man-in-the-middle attacks We have these same problems for NPM modules in *oids * You find crazy things like libssl in vendor Python/pip as well. * Verification isn't required unless you tell it In packaging (Debian for example) * Every package you install has been verified ** Biggest problems are that packages are old, or don't exist Jan is trying to solve WMF specific problem * What does he need? ** Someone to build it. From security perspective, what are you solving? * Attack vector? * Requiring HTTPS and checking validity of cert is a start * Verifying packages is a step further. Requires more work in signing * Starting with a patched version of composer that requires HTTPS Tags are a terrible thing to trust. Trust only SHA1s For everything you're going to pull in from composer, fork/mirror TASK DETAIL https://phabricator.wikimedia.org/T105638 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki Cc: MoritzMuehlenhoff, dduvall, Tgr, mobrovac, GWicke, Addshore, Qgil, Spage, greg, tstarling, aude, hoo, daniel, zeljkofilipin, thcipriani, mmodell, bd808, csteipp, Legoktm, Krinkle, hashar, JanZerebecki, Aklapper, Lynhg, Wikidata-bugs, Malyacko, jayvdb, Mbch331, Jay8g, Ltrlg, Krenair _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
