| 27 Nov 2024 |
 crertel | (and yes, I know that the "if you want to report..." does technically exist. never underestimate the ability of users to do the wrong thing when presented with something that isn't a flowchart with blinking lights and monosyllables. I include myself in that population.) | 02:00:44 |
 hexa | There is trade-offs in reporting. We support encrypted reports through GPG and we just won't manage a shared key. We could make more use of the security@ alias for everything else though. | 02:01:26 |
| crertel | I was thinking of a very specific workflow:
- Every incoming initial report goes to
security@
security@ forwards the messages to the currently active teamsecurity@ forwards the messages to an archive account (or indeed, perhaps could just be the archive account itself)- team reaches back out over normal channels, cc'ing security
I'm not sure how that would interact with the GPG thing, but I'm also not really sure that GPG is as important as a redundant and auditable comms.
| 02:05:02 |
| crertel | ("normal channels" here being GPG email or what have you) | 02:05:39 |
| hexa | I'm not sure that an audit trail is high on our list of priorities, and we generously cc reports between team members either way | 02:06:16 |
| hexa | it is how we track whether a thing was actually replied to | 02:07:20 |
| crertel | Wasn't one of the things from earlier this year folks not really knowing who was alerted when about 2.24 puckipedia thing? I don't have a lot of visibility into that, but audit logs of emails and touchpoints seem like they would've been helpful there when people were debugging later what went wrong.
The thing about manual cc'ing is that it makes it's a manual process, and any manual process will get goofed up eventually--so, a mailing list or some other automated system would probably help.
If I'm understanding you correctly, the biggest issue with a mailing list is the lack of PGP support for encrypted reports? Or did I misunderstand you? | 02:13:32 |
| crertel | * Wasn't one of the things from earlier this year folks not really knowing who was alerted when about 2.24 puckipedia thing? I don't have a lot of visibility into that, but audit logs of emails and touchpoints seem like they would've been helpful there when people were debugging later what went wrong.
The thing about manual cc'ing is that it makes ia manual process, and any manual process will get goofed up eventually--so, a mailing list or some other automated system would probably help.
If I'm understanding you correctly, the biggest issue with a mailing list is the lack of PGP support for encrypted reports? Or did I misunderstand you? | 02:13:57 |
| crertel | * Wasn't one of the things from earlier this year folks not really knowing who was alerted when about 2.24 puckipedia thing? I don't have a lot of visibility into that, but audit logs of emails and touchpoints seem like they would've been helpful there when people were debugging later what went wrong.
The thing about manual cc'ing is that it makes a manual process, and any manual process will get goofed up eventually--so, a mailing list or some other automated system would probably help.
If I'm understanding you correctly, the biggest issue with a mailing list is the lack of PGP support for encrypted reports? Or did I misunderstand you? | 02:14:05 |
| hexa | a list adds complexity, it can be done, but it is not a must | 02:15:13 |
| hexa | and if you asked puck she would probably tell you that these issues had nothing to do with the security team | 02:16:05 |
| hexa | * and if you asked puck she would probably tell you that these issues had nothing to do with this security team | 02:16:09 |
| crertel | ¯\_(ツ)_/¯ everybody sees a different part of the elephant lol | 02:17:00 |
| crertel | And then another question...looking at the github, I see a label for "status:wait-for-upstream"...is that for "there's nothing we as packagers can do on this except wait for the package to fix it"? | 02:17:06 |
| hexa | we did eventually package schleuder some time ago to look into an encrypted mailing list, but the priorities are just elsewhere right now | 02:17:19 |
| hexa | yes, means "nothing" we can do downstream | 02:17:46 |
| crertel | and schleuder would be...infra team, not security team, I'm guessing? | 02:18:08 |
| * hexa puts on his infra hat | 02:18:31 |
| crertel | lol | 02:18:44 |
| crertel | what're the current priorities re: infra? there's the ofborg decommissioning/move out of equinix, right? | 02:20:10 |
| hexa | replacing all that we loose at EOY to some degree | 02:21:34 |
| hexa | and long-term planning for a more sustainable future | 02:21:53 |
| hexa | upgrade hydra for more parallel build capacity | 02:22:15 |
| crertel | was there any progress/attempt at getting a little more time so y'all don't have to rush around the holidays? | 02:22:22 |
| hexa | and get the s3 bucket size and cost under control | 02:22:38 |
| crertel | (doing all this work with Christmas, New Years, and CCC coming up probably sucks and is stressful) | 02:22:49 |
| crertel | is there a deadline on the S3 thing, or is that just a known "we really need to fix this before it gets worse" sort of deal? | 02:23:25 |
| hexa | most of the work will be needed for ofborg either way, hydra's setup is just simple remote builders | 02:23:26 |
| crertel | ah, okay, so there's that at least! silver linings! | 02:23:42 |
| hexa | it costs money, do it sooner rather than later, before amazon stops sponsoring part of the bill | 02:24:01 |
