| hestenet (he/him) | Tim from the DA :wave::skin-tone-3: |
| tedbow | Ted at Acquia in finally warm Ithaca, NY |
| dts | I'm checking the backlog now. 🙂 |
| ergonlogic | Christopher, from Consensus, is checking-in regularly |
| dww | :wave: Derek |
| xjm | xjm, catching up on Wednesday |
| hestenet (he/him) | Per @ergonlogic - there are a number of updates in the issue above. |
| hestenet (he/him) | The repo can generate the bin names and hash prefixes, as well as generate the base metadata and write the files.At this point, we've introduced a bins.json that delegates to each of the bin_n.json metadata. The next step is to delegate from targets.json to bins.json. then work out adding each target to the proper bin_n.json and get the signing worked out between themI'd say we're at ~50% done |
| hestenet (he/him) | Hoping to be done by Friday April 14th |
| hestenet (he/him) | A few quick wins added as well: A flag to clean up target files from the repo, since it is redundant storage for d.o |
| hestenet (he/him) | @drumm has been managing this. It will be updated when the hashed bin support is ready per: https://drupal.slack.com/archives/C7QJNEY3E/p1680627795643089I don't believe there are other changes needed here in the meantime, for testing purposes - unless @phenaproxima you have something else besides the hashed bin support you need right now. |
| phenaproxima | I don’t need anything else right now. We’re in the middle of trying to get us up-to-date on the TUF spec, which itself is sending me into a rabbit hole of refactoring shitty tests |
| xjm | @phenaproxima I feels ya |
| hestenet (he/him) | @nnewton is taking this on, and can maybe summarize what it will entail. |
| nnewton | Rebasing on UBIConverting to OCI standard filesAdding skaffold support to the tree to ease local development/helm testingRemoving root assumtionsAdding gitlab-ci integration for rebuilding/updating buildsAdding scripts to the skaffold setup to ease first launch, fixing some dir expectations that will cause issues for other teams otherwise.Generally, making it so we can more easily maintain these images and automatically update them. |
| ergonlogic | @nnewton I'd be happy to accept MRs in Rugged for anything that'd make all that easier |
| hestenet (he/him) | Note also this thread about what is in scope for the security audit: https://drupal.slack.com/archives/C7QJNEY3E/p1680631388784879 |
| hestenet (he/him) | https://x41-dsec.de/ was the partner for CNCF for auditing Python-TufThis is the report they produced: https://theupdateframework.io/audits/x41-python-tuf-audit-2022-09-09.pdf |
| xjm | Have we asked the TUF folks about their experience? If they have positive things to say, +1 for going with a known quantity |
| hestenet (he/him) | Yeah, they're the folks I'm talking to primarily. They all recommended OSTIF.org who in turn recommended x41 for one of the prior audits. |
| hestenet (he/him) | @drumm’s current plan is to use Satis to create a new composer repository to mirror these core packages so we can sign them.We should create an issue. |
| ergonlogic | This seems sound to me. We use Satis to generate Composer repos for the Rugged tests, and it's pretty simple and reliable |
| hestenet (he/him) | Made a stub issue: #3352216: Securely sign Drupal core packages, even though they are hosted on GitHub/packagist directly |
| hestenet (he/him) | :clock11: It's that time again! |
| hestenet (he/him) | I'm guessing @tedbow can speak to this one? |
| phenaproxima | I like how it’s “the” Package Manager =P |
| tedbow | We have the Package Manager core merge request up with a fleshed out summary [#3346707]This automatically converted on ongoing bases from the version in the 3.0.x branch of the Automatic Updates contrib module |
| tedbow | Project Browser has been update to work with the 3.0.x branch Update to Package Manager 3.xBut I know that thye have hit at least 1 problem as we continuing working on 3.0.x Adjust for Package Manager requiring TranslatableMarkup for ValidationResult |
| hestenet (he/him) | per @phenaproxima |
| phenaproxima | Well, we’re closer than we were. We’re on 1.0.29 right now, on the way to 1.0.30. Said version has a behavior change that, while subtle, rather breaks our tests in annoying ways. It’s a battle but I’m fighting it. |
| phenaproxima | Once that’s done, though, 1.0.31 is a breeze. |
| hestenet (he/him) | Excellent. |
| phenaproxima | And that is the latest version of the spec. |
| ergonlogic | FYI, last week I updated Rugged to python-tuf v2.0.1, which supports 1.0.31. |
| hestenet (he/him) | Re: 5.1 - I can understand that position. I wish we had been able to get closer to the finish line on our side sooner than all this :tired_face: |
| tedbow | Y’all had a lot going on. Just raising this here because it is hard to keep up, a lot conversations are spread out around slack threads. So wanted 1 place for clarity |
| hestenet (he/him) | Appreciate it |
| hestenet (he/him) | I feel like @dts probably has opinions on: #3351190: [policy, no patch] Should Package Manager require Composer HTTPS? |
| dts | I do have opinions on it, but I'm mostly sitting on them at this point because there's a ratified Security Team decision for this that I am not going to muddy. |
| hestenet (he/him) | Gotcha |
| xjm | For point 2 re: HTTPS, I think I misunderstood last week. Thought it was about contrib. For core I think we can't have the hard requirement, but should make HTTPS the default behavior with a warning if any of the aforementioned HTTPS options are not used. Plus a handbook page documenting what catch learned on the issue. |
| xjm | For update manager we had the default behavior as HTTP, deprecated that in a minor, and now default to HTTPS but you can opt out. However, since autoupdates and co. are new code, I think we can have the more secure default behavior. |
| tedbow | ok. I can update that issue. @xjm thanks for clarification |
| xjm | That is just my initial reaction BTW, haven't discussed with the other RMs |
| tedbow | k |
| hestenet (he/him) | These are competing for @drumm’s time (though since @ergonlogic is doing hashed bin support and @nnewton is doing containers it's not blocking all progress)The first 2 may be things we can hand off to @fjgarlin to help on when he is back on Thursday, if we don't have them figured out by then. |
| fjgarlin | it seems like the tugboat one is sorted and we still have the salesforce one ongoing. will keep reading slack messages to try to be up to date on the current situation |
| hestenet (he/him) | Question for: @ergonlogic, @dts, @tedbow, @phenaproxima mostly, I think. |
| phenaproxima | On the face of it, I don’t object |
| tedbow | That seems good to me. I won’t want surprise @xjm or @catch or I don’t know who else from core governance so should probably get opinions or least let them know (edited) |
| hestenet (he/him) | Good point |
| ergonlogic | I think this makes more sense for php-tuf (setting aside governance concerns) than for Rugged. The TUF org already has implementations of TUF in Python, JS, Go and Rust. |
| ergonlogic | Don't get me wrong, I'd be open to it. But I doubt they'd be interested in an opinionated server that only implements a part of the spec |
| hestenet (he/him) | Fair |
| catch | That seems potentially very good to me if it means it gets more usage/support other than from us. |
| dts | I think, in general, it would be a huge win. |
| catch | One issue is that we'd ideally want php-tuf support to be inline with core release cycles - like security support for a major or minor version for x amount of time until Drupal 10 is EOL. It's not like where the API is exposed to Drupal contrib modules though so less of an issue than some other dependencies. |
| xjm | If they are interested it is definitely worth exploring, although we'd... what catch said |
| dww | To be clear, that would mean php-tuf would fall under whatever the upstream tuf namespace's governance model is, and it would no longer be adopted/maintained/supported/controlled by Drupal Core governance, right? |
| hestenet (he/him) | I don't have the full details, but as I understand the individual implementations underneath the /tuf namespace do have some of their own governance standards and different contributors, they just agree to follow some rules from the top level. |
| hestenet (he/him) | And the folks who are currently maintainers now would continue to be maintainers. |
| dww | So "we" would still be maintaining and controlling it, it'd still become a "part of core" (sort of), just lives in a different Git repo, etc? |
| dts | It may attract more community maintenance support |
| hestenet (he/him) | That would be the hope, yes, which is more or less what it is now as php-tuf/php-tuf --- the hope all along is that other communities could use it as well. |
| dts | More official == more user == more interested parties |
| dww | Of course. I'm all in favor of the move. Just wondering about the governance / maintenance implications. |
| dww | Sorry if it wasn't clear I :100: support doing this. |
| hestenet (he/him) | Yeah - we would have to examine that much more closely before finalizing, you are right @dww |
| hestenet (he/him) | This thread was an initial gut check. |
| hestenet (he/him) | cc @xjm @catch @mlhess @tedbow @effulgentsiaIt currently proposes 4 essential components to receive review, but also outlines additional ones we could include in scope. |
| ergonlogic | FYI I tagged (and followed) that issue, since I'm not otherwise regularly involved w/ the core, security and infra queues |
| ergonlogic | Let me know if/how I can help with that |
Comments
Comment #11
hestenet