| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958393: Add Content-Security-Policy headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958393 | 07:49 | |
| @mhuin:matrix.org | Hi, I was about to ask when to expect the next Zuul release, any plans for that? | 08:41 |
|---|---|---|
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958393: Add Content-Security-Policy headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958393 | 14:07 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958393: Add Content-Security-Policy headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958393 | 14:11 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958267: Add Permissions Policy HTTP headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958267 | 14:20 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958267: Add Permissions Policy HTTP headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958267 | 14:21 | |
| @fajfer:reszka.org | Clark: fungi did you guys think about moving from the whole create-react-app thing? It's dead, I've asked frontend guys to have a look at it and they recommend me update Zuul dependencies and just migrate to vite or something | 14:32 |
| @fajfer:reszka.org | we gave it a go but there's lots of old dependencies that break once we tried migrating to vite | 14:33 |
| @fajfer:reszka.org | I got a bit desperate since I'm struggling with updating swagger to newer version:) | 14:33 |
| @jim:acmegating.com | mhu: i think you answered your own question with the quote ;). but it's on my list for this week. | 14:55 |
| @jim:acmegating.com | fajfer: "just migrate to vite" is a big project. we might consider just removing swagger-ui if it's a problem. it duplicates the documentation and is not critical for the way we expect people to use zuul. | 14:56 |
| @fajfer:reszka.org | just migrate to vite was a really general advice given what we use now | 14:56 |
| @fajfer:reszka.org | we need to eventually migrate to something | 14:57 |
| @fajfer:reszka.org | jangutter: on the other chat just send me https://devclass.com/2025/02/18/react-team-formally-deprecates-create-react-app-following-perfect-storm-of-incompatibility/ | 14:58 |
| @mhuin:matrix.org | thanks corvus I wasn't sure I understood the timeline, so by week's end if all goes well I guess? | 14:58 |
| @jim:acmegating.com | mhu: yep, i hope so | 15:00 |
| @jim:acmegating.com | fajfer: yes, it's been obsolete for a while, but also, due to the way it's used, doesn't strictly need to be replaced. ejection is also an option. | 15:02 |
| @fajfer:reszka.org | corvus: not sure if you're talking about swagger (yeah, removing it sounds fine tbf) or removing react | 15:35 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 957173: Add AsList to AWS driver https://review.opendev.org/c/zuul/zuul/+/957173 | 16:12 | |
| @fajfer:reszka.org | both of these changes look good to me - https://review.opendev.org/c/zuul/zuul/+/958393 https://review.opendev.org/c/zuul/zuul/+/958267 question to maintainers if we want to merge that | 18:19 |
| @fajfer:reszka.org | just some http headers that security folks are picky about | 18:20 |
| @jangutter:matrix.org | Hi folks, I'm considering writing a reporter plugin for Zuul to call a generic webhook. This is mostly motivated so that we can have an internal adapter to call some of our proprietary endpoints. I had the idea of using jinja2 templating in the webhook config to make it reasonably generic. | 18:27 |
| The alternative would be to set up MQTT and a receiver - if a reporter would cause blocking under load then I would understand why a workqueue would be beneficial. | ||
| @jangutter:matrix.org | Please don't hesitate to point out the obvious bits that I missed! | 18:28 |
| @clarkb:matrix.org | > <@fajfer:reszka.org> both of these changes look good to me - https://review.opendev.org/c/zuul/zuul/+/958393 https://review.opendev.org/c/zuul/zuul/+/958267 question to maintainers if we want to merge that | 18:34 |
| Looks like the two changes conflict with one another. Might want to stack them? Then I notice you don't allow clipboard writes. That seems like a problem as I copy uuids out of zuul web pages fairly often | ||
| @clarkb:matrix.org | Or is that only affecting what the js can do and my brother can still copy? | 18:34 |
| @clarkb:matrix.org | jangutter: why not have the job Ansible payload make the http request? | 18:35 |
| @jangutter:matrix.org | Clark: That's how our current system works but it emits a bunch of messages, one per job. I'm looking for something that will be run per buildset, not per build. | 18:36 |
| @clarkb:matrix.org | I'm not sure we want zuul running arbitrary jinja2 within the reporters | 18:37 |
| @jangutter:matrix.org | Even in a config repo? | 18:37 |
| @clarkb:matrix.org | I guess it would be configured by more trusted users if it is pipeline config. | 18:37 |
| @fajfer:reszka.org | it's just the js, scripts won't be allowed to manipulate your clipboard | 18:37 |
| @fajfer:reszka.org | I can stack them, it's not a problem. I just wasn't sure if any of these would be accepted or not so I didn't do it | 18:38 |
| @clarkb:matrix.org | fajfer @fajfer:reszka.org: I'm definitely not the one to make that decision. I just wanted to note what I saw | 18:38 |
| @fajfer:reszka.org | sure, I assumed it's a problem for my to fix if one of these would be eventually interesting | 18:39 |
| @fajfer:reszka.org | I was told to only do CSP headers but I also did PP headers | 18:39 |
| @clarkb:matrix.org | jangutter: and the problem is your various endpoints expect different payloads in their requests? This isn't a standard webhook like what GitHub et al emit and everyone else understands? | 18:40 |
| @jangutter:matrix.org | Clark: having a static reporter schema isn't the end of the world (it would still work) but my theory was that since this requires pipeline config privilege, _and_ someone to set up the connection in zuul.conf, it solves the fixed schema if it's operator configurable. | 18:40 |
| @jangutter:matrix.org | Clark: but yeah, once your config language is Turing complete, validating that it's correct becomes the Halting problem. | 18:41 |
| @jangutter:matrix.org | (Mostly this got triggered by a slow but steady re-evaluation of things we did over 5 years and what could be better). One of the problems is versioning - we might not be running, ahum, the latest version of something, and might, err.... depend on some "legacy" interfaces. | 18:45 |
| @jangutter:matrix.org | So having the interface defined in config is a plus for us. | 18:46 |
| @jim:acmegating.com | fajfer: the commit message doesn't have any rationale for those. i don't know why we would want to merge them. zuul doesn't use any of that, so they don't seem necessary. if you think there's a good reason, then i'd suggest including that in the commit message. but i'm skeptical. | 19:09 |
| @jim:acmegating.com | jangutter: typically the mqtt reporter is used for what you describe. i am considering an http reporter, but it's a different use case, and it's specifically one where blacking is needed. i'm working on getting more input about it before proceeding, so i think it's going to be a while. see commit message in https://review.opendev.org/957608. but regardless, i think jinja is a step too far and the schema should be static like the other reporters. the furthest i think we should go (if we go at all) would be python templating in the url, just like we template the mqtt topic. | 19:16 |
| @jim:acmegating.com | * jangutter: typically the mqtt reporter is used for what you describe. i am considering an http reporter, but it's a different use case, and it's specifically one where blocking is needed. i'm working on getting more input about it before proceeding, so i think it's going to be a while. see commit message in https://review.opendev.org/957608. but regardless, i think jinja is a step too far and the schema should be static like the other reporters. the furthest i think we should go (if we go at all) would be python templating in the url, just like we template the mqtt topic. | 19:18 |
| @jangutter:matrix.org | corvus: that would also work for our usecase. I'd be happy to start on a prototype in a few weeks from now, with the understanding that the entire design is experimental and may not be merged. | 19:23 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 19:58 | |
| - [zuul/zuul] 958470: Shutdown log stream socket instead of close https://review.opendev.org/c/zuul/zuul/+/958470 | ||
| - [zuul/zuul] 958471: Handle retries in zuul_stream https://review.opendev.org/c/zuul/zuul/+/958471 | ||
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958393: Add Content-Security-Policy headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958393 | 20:15 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958267: Add Permissions Policy HTTP headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958267 | 20:15 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958393: Add Content-Security-Policy headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958393 | 20:16 | |
| -@gerrit:opendev.org- Damian Fajfer proposed: [zuul/zuul] 958478: Add X-Frame-Options headers to CherryPy https://review.opendev.org/c/zuul/zuul/+/958478 | 20:37 | |
| @fajfer:reszka.org | I've written the explanations for the headers from https://developer.mozilla.org Zuul doesn't use certain things, that's why it could(should?) be explicitly said via security headers. We already have CORS security headers implemented, so should they be removed or is it ok to populate these? Security tools rate lack of these headers as application vulnerabilities | 21:00 |
| @jim:acmegating.com | we have cors headers because they are required. we will not be removing them. | 21:04 |
| @clarkb:matrix.org | it did occur to me that if someone were to host parts of zuul with a cdn or similar then these rules might break them? I'm not super concerned about that as I'm not aware of anyone doing that | 21:06 |
| @jim:acmegating.com | we're not going to add a bunch of stuff because a security scanner said so. if we change any of this stuff, we're going to need an analysis of how this actually applies to zuul and creates a vulnerability. i'm not seeing that. i don't think that we should need to set a header saying we don't use the microphone. that seems silly. | 21:08 |
| @fajfer:reszka.org | Permissions Policy is so stupid that I didn't even make a relation chain including it, but CSP/X-Frame-Options doesn't sound that bad | 21:09 |
| @jim:acmegating.com | why shouldn't someone be able to embed zuul in an iframe? | 21:09 |
| @fajfer:reszka.org | that's not something I'm going to die for, I'd be content if you gave me -2 and said that you wouldn't want security headers to be implemented. If someone needs them they can always look for my change and download a patch | 21:10 |
| @jim:acmegating.com | (or use a proxy to "add-header") | 21:11 |
| @jim:acmegating.com | fajfer: understood and i appreciate your stance. my feeling is i want to know all of the implications before making a change like that... maybe it's worth doing, maybe not. maybe it should be done under certain circumstances (like if authentication is enabled). but i don't want to make things less flexible without a good reason. i could very easily see someone embedding the status page in an operational display. so i don't want to prevent uses like that without a full understanding. so i'm somewhere between -1 and -2. my mind could be changed. | 21:14 |
| @fajfer:reszka.org | maybe I'm just more immature but honestly I'd do that just to hear about that very specific use case someone is doing | 21:16 |
| @jim:acmegating.com | not everyone would speak up for something like that; they might just stop doing it. | 21:17 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 957174: AWS: Add security-group-ids parameter https://review.opendev.org/c/zuul/zuul/+/957174 | 21:35 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 957175: AWS: Remove security-group-id https://review.opendev.org/c/zuul/zuul/+/957175 | 21:45 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!