2024-05-13 19:01:40 <@tstellar:fedora.im> !startmeeting FESCO (2024-05-13)
2024-05-13 19:01:43 <@meetbot:fedora.im> Meeting started at 2024-05-13 19:01:40 UTC
2024-05-13 19:01:44 <@meetbot:fedora.im> The Meeting name is 'FESCO (2024-05-13)'
2024-05-13 19:01:45 <@tstellar:fedora.im> !meetingname fesco
2024-05-13 19:01:52 <@tstellar:fedora.im> !topic Init Process
2024-05-13 19:01:59 <@mhayden:fedora.im> !hi
2024-05-13 19:02:00 <@zbyszek:fedora.im> !hi
2024-05-13 19:02:03 <@zodbot:fedora.im> Major Hayden (mhayden) - he / him / his
2024-05-13 19:02:04 <@jonathanspw:fedora.im> !hi
2024-05-13 19:02:05 <@zodbot:fedora.im> Zbigniew Jędrzejewski-Szmek (zbyszek)
2024-05-13 19:02:06 <@tstellar:fedora.im> !hi
2024-05-13 19:02:06 <@jistone:fedora.im> !hi
2024-05-13 19:02:08 <@zodbot:fedora.im> Jonathan Wright (jonathanspw)
2024-05-13 19:02:10 <@zodbot:fedora.im> Tom Stellard (tstellar)
2024-05-13 19:02:10 <@zodbot:fedora.im> Josh Stone (jistone) - he / him / his
2024-05-13 19:02:15 <@blackwell:fedora.im> !hi
2024-05-13 19:02:19 <@zodbot:fedora.im> Jason Blackwell (blackwell)
2024-05-13 19:02:19 <@mhayden:fedora.im> _needs to depart around 20-30 mins after the hour_ 😢
2024-05-13 19:02:29 <@humaton:fedora.im> !hi
2024-05-13 19:02:32 <@zodbot:fedora.im> Tomáš Hrčka (humaton) - he / him / his
2024-05-13 19:02:39 <@berrange:matrix.org> !hi
2024-05-13 19:02:42 <@zodbot:fedora.im> No Fedora Accounts users have the @berrange:matrix.org Matrix Account defined
2024-05-13 19:02:45 <@tstellar:fedora.im> OK, looks like we have quorum. 
2024-05-13 19:03:04 <@nirik:matrix.scrye.com> morning
2024-05-13 19:03:40 <@zbyszek:fedora.im> danpb: thanks for coming.
2024-05-13 19:04:00 <@tstellar:fedora.im> !topic 
#3205 Request exception to permit shipping pre-built, signed SGX enclave binaries in Fedora 
2024-05-13 19:04:15 <@tstellar:fedora.im> !fesco 3205
2024-05-13 19:04:19 <@zodbot:fedora.im> **fesco #3205** (https://pagure.io/fesco/issue/3205):**Request exception to permit shipping pre-built, signed SGX enclave binaries in Fedora**

● **Opened:** 5 days ago by berrange
● **Last Updated:** 4 minutes ago
● **Assignee:** Not Assigned
2024-05-13 19:05:11 <@zbyszek:fedora.im> In general, I'm happy with the proposal as it stands.
2024-05-13 19:06:09 <@tstellar:fedora.im> The proposed solution, seems the best out of all of them.  My only concern is that it will be difficult to reproduce the buids bit for bit when there are updates.
2024-05-13 19:06:11 <@jistone:fedora.im> I'm not thrilled about entire custom toolchains
2024-05-13 19:07:30 <@jistone:fedora.im> the situation seems sort of similar to openh264 to me (though the reasons aren't the same)
2024-05-13 19:07:39 <@nirik:matrix.scrye.com> I'm not happy about the entire thing, but oh well. ;(
2024-05-13 19:07:44 <@jistone:fedora.im> what's so wrong with pointing to an external repo?
2024-05-13 19:08:17 <@nirik:matrix.scrye.com> Also, do we want to allow some community discussion of this? it just went to fesco via ticket... or is that unlikely to provide much additional input or ideas?
2024-05-13 19:08:30 <@sgallagh:fedora.im> .gi
2024-05-13 19:08:31 <@sgallagh:fedora.im> .hi
2024-05-13 19:08:40 <@sgallagh:fedora.im> (Sorry, got sidetracked and am late)
2024-05-13 19:08:43 <@sgallagh:fedora.im> !hi
2024-05-13 19:08:46 <@zodbot:fedora.im> Stephen Gallagher (sgallagh) - he / him / his
2024-05-13 19:09:21 <@sgallagh:fedora.im> So, I'm opposed to this as written. I agree with Josh; this looks like it should be solved similarly to H.264
2024-05-13 19:10:21 <@tstellar:fedora.im> Stephen Gallagher: What's the H.264 solution, third-party repository?
2024-05-13 19:11:13 <@nirik:matrix.scrye.com> we build it, but they distribute it. it's not exactly the same here tho.
2024-05-13 19:11:15 <@zbyszek:fedora.im> The reason we used an external repo for x264 was the were _not_ allowed to ship the code ourselves. The external repo was the only legal way it could be shipped, i.e. the only legal way we could make it easily available for our users.
2024-05-13 19:12:12 <@sgallagh:fedora.im> The thing that really bothers me about this is that it's an entire execution environment that we cannot validate or verify.
2024-05-13 19:12:44 <@sgallagh:fedora.im> Why would I trust that it's truly confidential if I can't validate that the binary matches the sources?
2024-05-13 19:12:46 <@zbyszek:fedora.im> But here the situation is different: first, we _can_ ship the code, and that means that we can make the packaging as good as we want it. Second, there is no external repo. Based on the description in the ticket, it seems Intel wants to do one build (in the way that they already have set up), and they have no desire to do packaging for us.
2024-05-13 19:12:49 <@berrange:matrix.org> what do you mean by that ?  what would you want to validate in respect of the hardware features ?
2024-05-13 19:12:57 <@sgallagh:fedora.im> Or rebuild it myself and add my own signing key?
2024-05-13 19:13:18 <@zbyszek:fedora.im> No, that's a complete misunderstanding.
2024-05-13 19:14:04 <@zbyszek:fedora.im> The whole complicated setup is so that we actually _do_ verify that the binary matches the sources.
2024-05-13 19:14:06 <@sgallagh:fedora.im> Sorry, coming back up to speed as quickly as I can. I read the ticket last week while I was away at a conference.
2024-05-13 19:14:24 <@jistone:fedora.im> Does Fedora Legal need to weigh in on this too?
2024-05-13 19:14:41 <@berrange:matrix.org> the proposal is that the we do a build in fedora koji and validate this is byte-for-byte identical to the pre-built binary signed by Intel, (minus the signature of course)
2024-05-13 19:15:06 <@zbyszek:fedora.im> You can do that, but that'd be completely useless, because the CPU firmware is not going to trust your key. And, unlike in SecureBoot, there is no mechanism to allow custom keys.
2024-05-13 19:16:01 <@zbyszek:fedora.im> Why do you think so? The license situation is very clear.
2024-05-13 19:16:06 <@sgallagh:fedora.im> OK, sorry. I just finished rereading the ticket and I see where I got tripped up.
2024-05-13 19:16:34 <@sgallagh:fedora.im> Why is "Require anyone who wants to run TDX CVMs to acquire the pre-built enclaves from Intel's GitHub download site. Possibly add a script to Fedora to download this automatically on boot or first use. I include this for completeness, as it is the fallback if all the other options above are rejected. I think it would be an unfriendly solution for Fedora's users though, so I'd like to avoid it." not the best option?
2024-05-13 19:16:53 <@jistone:fedora.im> In case the binary aspect needs approval - maybe it doesn't, I don't know
2024-05-13 19:17:15 <@tstellar:fedora.im> What is the license?
2024-05-13 19:17:18 <@sgallagh:fedora.im> Why is "Require anyone who wants to run TDX CVMs to acquire the pre-built enclaves from Intel's GitHub download site. Possibly add a script to Fedora to download this automatically on boot or first use." not the best option?
2024-05-13 19:17:43 <@berrange:matrix.org> it doesn't give a seemless out of the box experiance, and doesn't co-ordinate fedora software updates with the vendor's own updates schedule
2024-05-13 19:17:49 <@sgallagh:fedora.im> Tom Stellard: As long as it's freely distributable, I think we could make a reasonable argument that this is a "firmware blob"
2024-05-13 19:18:02 <@berrange:matrix.org> the code is under quite a variety of licenses, but all are approved for Fedora
2024-05-13 19:18:38 <@berrange:matrix.org> last i audited, i got   "BSD-3-Clause AND Apache-2.0 AND MIT AND OpenSSL AND ISC AND BSD-2-Clause AND GPL-2.0-only AND SMLNJ AND NCSA AND Apache-1.0 AND FSFAP AND BSD-4-Clause-UC AND FSFUL AND Zlib AND (Apache-2.0 OR GPL-2.0-or-later) AND EPL-1.0 AND MS-PL AND BSD-4-Clause AND MIT-0"
2024-05-13 19:19:19 <@sgallagh:fedora.im> danpb: I'm not sure I follow; if we just added a systemd unit file that checks for and updates the SGX blob as a `Before=libvirt.service`, how would the end-user notice or care?
2024-05-13 19:19:26 <@zbyszek:fedora.im> It's a binary that we have built in koji from sources that allow redistribution. It is true that we used a specific version of the compiler to build it, but we have many packages which use a specific version of the compiler to build (e.g. different llvm versions, or different java versions, etc, etc.). We don't make special provisions for code that is built with a non-default compiler or some compat versions of libraries. And at the technical level, this is exactly what is happening here.
2024-05-13 19:19:31 <@sgallagh:fedora.im> (I oversimplified that, but the gist is there)
2024-05-13 19:20:02 <@sgallagh:fedora.im> zbyszek: No, but we do require that those special versions of the compiler are, themselves, built in Fedora.
2024-05-13 19:20:12 <@tstellar:fedora.im> I agree with Josh Stone I think we we would need to have Fedora Legal review this if we end-up redistributing binaries.  Re-distributing binaries and building from sources are different.
2024-05-13 19:20:21 <@sgallagh:fedora.im> We have a chain of trust from code to binary that passes through the compiler and build-system
2024-05-13 19:20:23 <@berrange:matrix.org> a slight difference from firmware, is that this runs at normal userspace privilege level, as opposed to a higher privilege beneath the OS - a SGX enclave is merely a way of isolating trusted code from untrusted code
2024-05-13 19:20:52 <@zbyszek:fedora.im> It also requires a working network connection to the outside.
2024-05-13 19:21:18 <@sgallagh:fedora.im> zbyszek: True, and that's definitely a valid concern, particularly for air-gapped setups
2024-05-13 19:21:54 <@zbyszek:fedora.im> But we are distributing a binary that we built ourselves.
2024-05-13 19:22:06 <@blackwell:fedora.im> It could be packaged into the image for an airgapped setup 
2024-05-13 19:22:23 <@zbyszek:fedora.im> It happens to be the same as some other binary, but that's OK.
2024-05-13 19:22:27 <@jistone:fedora.im> This is kind of splitting hairs, but AIUI the koji build is building the source to ensure equivalence with the signed binaries. That's valuable, but not exactly the same as distributing what we build.
2024-05-13 19:23:15 <@berrange:matrix.org> this is kind of like the 'shim' model, except that we're using a fixed toolchain with byte-for-byte reproducibility, so when we send the binary off for signing, they can just give us back a binary they already had signed
2024-05-13 19:23:31 <@tstellar:fedora.im> zbyszek: Are we, I though in the end we were distributing the upstream binaires?
2024-05-13 19:23:56 <@berrange:matrix.org> the main difference from shim, is that while users can do custom builds, they can't practically use them
2024-05-13 19:24:14 <@sgallagh:fedora.im> That's another point: have we been able to ensure that we *can* get a byte-for-byte replica?
2024-05-13 19:24:36 <@berrange:matrix.org> i've got about 90% of the way there
2024-05-13 19:24:55 <@sgallagh:fedora.im> So only 90% to go? :)
2024-05-13 19:25:26 <@mhayden:fedora.im> _will be back in a half hour_
2024-05-13 19:26:38 <@zbyszek:fedora.im> You have a point, that'd we'd actually distribute the "upstream binaries". If that matters, we could change things to copy the original signature into "our" binaries. The result might as well be identical. I have no idea how much extra work that'd be.
2024-05-13 19:26:47 <@berrange:matrix.org> heh. i'm fairly confident i'll succeed, but obviously if i fail, then my proposal is void.   i wanted to at least get some feedback from FESCO on whether its worth investing more time in this approach... don't want todo the work if there's no chance of being accepted in fedora
2024-05-13 19:27:43 <@sgallagh:fedora.im> Yeah, that's wise. And I appreciate the hard work you're putting into this.
2024-05-13 19:28:18 <@sgallagh:fedora.im> Some of this is me being annoyed that there's no meaningful way for us to sign our own builds for this purpose.
2024-05-13 19:29:28 <@sgallagh:fedora.im> Among other things, I *really* don't like distributing "security" software that is reliant on an ancient build system that almost certainly has unpatched vulnerabilities in it
2024-05-13 19:29:36 <@tstellar:fedora.im> If in the end, if the RPMs include the binaries that we built in koji ourselves (and we aren't just copying the upstream binaries included as a 'source', then I think this part of it is fine.  The main concerns I have are: 1) If it's realistic to always be able to produce byte-for-byte results 2) We have no way to fix bugs/security issues ourselves. 3) The custom toolchain, which I think should be bundled with the SGX package.
2024-05-13 19:29:36 <@jistone:fedora.im> How much of the binary is actually checked by the signature? All of it? or just sections like .text/.data? There might also be other Fedora stuff like annobin that we'd want to keep in our build, if the signing allows.
2024-05-13 19:30:04 <@berrange:matrix.org> yeah, i'm annoyed at that myself too, as it does undermine one of the key benefits of OSS .... but if you take the view that this is like 'firmware', then its miles ahead that usual situation of completely opaque firmware blobs
2024-05-13 19:30:43 <@sgallagh:fedora.im> danpb: Curses! You've caught me by my own favorite adage about perfection vs. good enough.
2024-05-13 19:31:21 <@tstellar:fedora.im> Also what about code like x = dlopen("somelib.so"); if (x) { do_something();}  Binary compatibility does not necessarily mean it behaves the same always.
2024-05-13 19:31:28 <@berrange:matrix.org> i'm not 100% certain, but i think basically the entire of the elf binary is validated - eg even the .interp section is checked, despite that being irrelevant - i've got a todo to ask intel to remove the .interp section since its needlessly referencing a nixos path that doesn't need to exist
2024-05-13 19:32:46 <@sgallagh:fedora.im> Possibly a tangent, but is there an alternative being offered for similar behavior on non-x86 hosts? I can certainly see this being interesting for e.g. aarch64 systems in AWS
2024-05-13 19:32:49 <@berrange:matrix.org> while this is distributed as a ELF .so binary, AFAIK, its not something you can just dlopen() and execute from a regular Fedora program - they've just used ELF as a convenient binary format, and have a custom loader that extracts the code and loads it into the SGX enclave
2024-05-13 19:33:58 <@berrange:matrix.org> this is entirely Intel SGX/TDX x86 specific - other arches & vendors have their own completely different approach to confidential VMs, and most of them have all the code in opaque firmware.
2024-05-13 19:34:14 <@sgallagh:fedora.im> Ack
2024-05-13 19:35:22 <@zbyszek:fedora.im> > 1) If it's realistic to always be able to produce byte-for-byte results 

In general, Debian and Arch have 80-90% reproducibility for all packages. For compiled packages, the expectation in general is 100% reproducibility. At least in Fedora, for many compiled packages we got full reproducibility very early.
2024-05-13 19:35:31 <@sgallagh:fedora.im> The rebuilds we'd be doing to compare for byte-for-byte match: they're prebuilt binaries of the compiler/linker?
2024-05-13 19:35:47 <@sgallagh:fedora.im> Or we will have those rebuilt in our infrastructure as well?
2024-05-13 19:36:03 <@zbyszek:fedora.im> Or maybe to put in a different way: for a package where some effort is put into reproducibility, it is expected to get full reproducibility without problem.
2024-05-13 19:36:21 <@jistone:fedora.im> What's your packaging plan for the custom toolchain? Can we ensure that nothing else uses it? Or do you have to use it when building your own SGX code using these runtimes?
2024-05-13 19:36:40 <@berrange:matrix.org> I would have to create toolchains in koji in the normal way, eg a 'sgx-gcc' and 'sgx-binutils' packages, which uses a specific required version
2024-05-13 19:37:21 <@sgallagh:fedora.im> OK, but they would be built, not just copied from upstream. I'm okay with that.
2024-05-13 19:37:47 <@berrange:matrix.org> those would install a /usr/bin/x86-64-intel-sgx-gcc    binary for example - i'm thinking of this as a 'x86_64-intel-sgx'  build target - and so its obvious these builds are not for general use
2024-05-13 19:37:50 <@zbyszek:fedora.im> > 2) We have no way to fix bugs/security issues ourselves. 

Yeah, that's certainly annoying. But considering that the whole idea is to not trust the underlying host, i.e. in particular the distro installed by the vendor, there doesn't seem to be any way around this. The only solution is Intel releases fixed versions quickly.
2024-05-13 19:37:50 <@sgallagh:fedora.im> (I assume they'd bootstrap and be used to build themselves as the regular ones do)
2024-05-13 19:37:51 <@tstellar:fedora.im> My opinion is that the toolchains should be bundled and not distributed.
2024-05-13 19:38:33 <@sgallagh:fedora.im> Tom Stellard: I agree with "not distributed"
2024-05-13 19:38:37 <@nirik:matrix.scrye.com> less chance of anyone else trying to use them that way
2024-05-13 19:38:50 <@jistone:fedora.im> I wouldn't think so, they're still running on the normal host, like a cross compiler.
2024-05-13 19:38:54 <@berrange:matrix.org> so you mean build the required gcc/inbutils as part of the 'sgx'  rpm build, and not package them as their own rpms  ?
2024-05-13 19:38:54 <@sgallagh:fedora.im> We could probably exclude them from composes and keep them only in the buildroot for a special side-tag?
2024-05-13 19:39:01 <@zbyszek:fedora.im> That'd be very painful for the sgx package, because each build would take forever.
2024-05-13 19:39:43 <@tstellar:fedora.im> danpb: Right.
2024-05-13 19:39:45 <@zbyszek:fedora.im> We have a general rule that it's OK to package compat versions of packages. I think we should treat this as any other case, and maybe even use the normal compat-package-naming scheme.
2024-05-13 19:40:11 <@sgallagh:fedora.im> Josh Stone: I meant something different, but the specifics are a tangent we could discuss later.
2024-05-13 19:40:39 <@nirik:matrix.scrye.com> This seems like a long way to go for a pretty small user base, but I guess they might really like that someone did
2024-05-13 19:40:41 <@tstellar:fedora.im> zbyszek: Is this something that would be updated a lot?
2024-05-13 19:40:52 <@zbyszek:fedora.im> Frankly, I don't understand why you'd want that. It'd require a monstrous spec file with many unrelated parts that'd be ineffective and hard to maintain. 
2024-05-13 19:41:14 <@sgallagh:fedora.im> danpb: Does Intel rev the build chain concurrently with the sgx binaries?
2024-05-13 19:41:43 <@berrange:matrix.org> intel do perhaps 3-4 releases a year of the SGX bits.... but the toolchain they use doesn't change very  often...hence why it is on an annoyingly old gcc/binutils
2024-05-13 19:41:45 <@sgallagh:fedora.im> If so, maybe it makes sense to bundle them. If the build chain is largely static, we should probably keep it separate so sgx builds don't take literal days.
2024-05-13 19:42:15 <@tstellar:fedora.im> I don't think bundling gcc would take days.
2024-05-13 19:42:34 <@berrange:matrix.org> i get the impression they're pretty paranoid about the code that's generated, especially wrt to spectre related side channel mitigations, so uninclined to change toolchain versions often
2024-05-13 19:43:37 <@tstellar:fedora.im> Also, there are ways to speed it up, e.g. removing unneeded language support, and not doing a 3-stage build.
2024-05-13 19:44:24 <@zbyszek:fedora.im> Anyway, I'm not particularly oppposed to bundling it, but I don't think we should mandate this either way. I'd leave it to the maitainers of the package to make the decision. Possibly with different choices for different parts of the stack (gcc, binutils, some libraries, etc.)
2024-05-13 19:44:36 <@tstellar:fedora.im> I don't think we should be packaging custom toolchains.  This is not the same as just packaging an old version of gcc.  Their toolchain could be patches or have other modifications in it.
2024-05-13 19:44:47 <@tstellar:fedora.im> I don't think we should be packaging custom toolchains.  This is not the same as just packaging an old version of gcc.  Their toolchain could be patched or have other modifications in it.
2024-05-13 19:45:03 <@berrange:matrix.org> i guess packaging of toolchain is more of a minor detail we can debate if this is actually approved as a concept... i'm not too fussed on choices on that side personally
2024-05-13 19:45:38 <@sgallagh:fedora.im> Tom Stellard: If we don't do that, we default to either shipping their signed binary untested or not shipping SGX at all. Are those preferable?
2024-05-13 19:45:48 <@berrange:matrix.org> it is unpatched by intel at least - its a a standard NixOS package, and from what i see there's no patches - i've been using unmodified upstream tarballs for testnig thus far
2024-05-13 19:45:49 <@tstellar:fedora.im> We've been discussing for 45 minutes now.  Do we have a proposal or something to vote on?
2024-05-13 19:46:01 <@sgallagh:fedora.im> s/untested/unvalidated/
2024-05-13 19:46:27 <@sgallagh:fedora.im> I'll make a proposal
2024-05-13 19:46:44 <@tstellar:fedora.im> What do you mean?  We can still build our own identical copy of the SGX bits even if we don't distribute the custom toolchain.
2024-05-13 19:47:14 <@jistone:fedora.im> (i.e. %build-only bundling)
2024-05-13 19:47:34 <@sgallagh:fedora.im> Tom Stellard: Were you using "package" as a synonym for "distribute"?
2024-05-13 19:47:35 <@tstellar:fedora.im> Yeah, maybe I should be calling it something other than bundling.
2024-05-13 19:47:56 <@sgallagh:fedora.im> OK, I think that was the disconnect.
2024-05-13 19:48:01 <@tstellar:fedora.im> Yes.
2024-05-13 19:48:22 <@sgallagh:fedora.im> If you mean "we just don't distribute the custom toolchain", that's a huge difference from "we don't package it".
2024-05-13 19:48:26 <@sgallagh:fedora.im> Got it
2024-05-13 19:48:56 <@tstellar:fedora.im> Stephen Gallagher: You mean we could build RPMs for it, but keep it in the buildroot?
2024-05-13 19:49:03 <@sgallagh:fedora.im> Yes
2024-05-13 19:49:26 <@sgallagh:fedora.im> Like what we used to do for `glibc32` (not that I particularly like that idea, but it's possible and has precedent)
2024-05-13 19:50:00 <@nirik:matrix.scrye.com> others could still use it if it's in the buildroot
2024-05-13 19:51:05 <@tstellar:fedora.im> Stephen Gallagher: That makes sense from a technical perspective, but I'm really hesitant to go down that path, so we don't end up with a buildroot full of ibm-clang, intel-clang, amd-clang, swift-clang, pytorch-clang, etc.
2024-05-13 19:51:13 <@sgallagh:fedora.im> Proposal: Approved as long as we can produce binaries that match the signed ones from upstream using a toolchain built entirely in Fedora infrastructure. In this case, the upstream signed binary may be distributed via the Fedora repositories.
2024-05-13 19:51:44 <@zbyszek:fedora.im> +1 
2024-05-13 19:51:52 <@sgallagh:fedora.im> (I am intentionally leaving the implementation of "a toolchain built entirely in Fedora infra" as an open question
2024-05-13 19:51:57 <@sgallagh:fedora.im> (I am intentionally leaving the implementation of "a toolchain built entirely in Fedora infra" as an open question)
2024-05-13 19:52:31 <@tstellar:fedora.im> I don't want to give blanket approval without knowing all the details about the toolchain, I think we should revisit, once there is a complete implementation.
2024-05-13 19:52:47 <@tstellar:fedora.im> Also the fact that we can't fix CVEs is concerning to me.
2024-05-13 19:53:04 <@sgallagh:fedora.im> Tom Stellard: Shall we take that as a -1 vote?
2024-05-13 19:53:34 <@berrange:matrix.org> fwiw, i'd expect to submit a Fedora Change proposal once we come to actually integrate this in Fedora
2024-05-13 19:53:54 <@tstellar:fedora.im> Yeah -1.  I think the process of building byte identical binaries and distributing those should be allowed for this, but I have concerns about some of the other details.
2024-05-13 19:54:03 <@sgallagh:fedora.im> I'm personally willing to trust danpb to approach this in a manner that matches with Fedora's mission.
2024-05-13 19:54:04 <@nirik:matrix.scrye.com> I've not had the time to think about this in depth. I'd vote -1 or 0 today...
2024-05-13 19:54:57 <@sgallagh:fedora.im> Tom Stellard: I agree with your concerns, particularly around CVEs, but I don't know that we have any better options at this time.
2024-05-13 19:55:10 <@jistone:fedora.im> Can we require the future Change as part of the proposal we're voting on? That will also open up community discussion as mentioned earlier.
2024-05-13 19:56:09 <@sgallagh:fedora.im> I'd like to at least provide the virt folks with some assurance that if they go and do all this work, it won't be wasted.
2024-05-13 19:56:19 <@nirik:matrix.scrye.com> but if we approve it today, aren't we just approving the change before it exists?
2024-05-13 19:56:21 <@zbyszek:fedora.im> That is a good concern, but the way the whole concept is implemented in hardware  and the policy that is built around that means that CVEs can only be fixed by the CPU vendor. So if you want to block on that, then that's essentially equivalent to never allowing this to be distributed in Fedora.
2024-05-13 19:56:54 <@jistone:fedora.im> or it means allowing it on the same terms as other firmware
2024-05-13 19:57:34 <@tstellar:fedora.im> zbyszek: I'm not saying I'll block on this, but this is the kind of thing that should be addressed in a change proposal with at least an explanation about the risks and the history if any of CVE response from upstream.
2024-05-13 19:58:22 <@berrange:matrix.org> i'd point out that Intel have a vested interest in promptly fixing CVEs in their enclaves, since this is the base of their root of trust, and any flaws are visible to all in the source that's open
2024-05-13 19:58:30 <@tstellar:fedora.im> I think this is a good goal.
2024-05-13 19:59:20 <@berrange:matrix.org> this meeting has already given me more confidence, since you didn't immediately dismiss the concept as I feared might happen.
2024-05-13 19:59:26 <@tstellar:fedora.im> So far we have (+2,0,-2) any other votes.  We are almost at the one hour mark.
2024-05-13 19:59:50 <@blackwell:fedora.im> +1 
2024-05-13 20:00:05 <@humaton:fedora.im> I was just reading on it bit more
2024-05-13 20:00:36 <@sgallagh:fedora.im> danpb: I'm not saying I love the idea, but so far it seems like the approach that best aligns with our mission AND provides assurance that we're not distributing something untrusted.
2024-05-13 20:00:38 <@zbyszek:fedora.im> There was actually only one -1 vote so far.
2024-05-13 20:00:53 <@tstellar:fedora.im> I'm going to wait 2 more minutes and then close the voting, we need to move on, since we are out of time.
2024-05-13 20:01:01 <@humaton:fedora.im> +1
2024-05-13 20:01:01 <@sgallagh:fedora.im> Jason Blackwell: Only FESCo members get a counted vote, but thank you for your participation :)
2024-05-13 20:01:20 <@tstellar:fedora.im> zbyszek: OK, I see nirik didn't actually vote.
2024-05-13 20:01:39 <@tstellar:fedora.im> (+3,0,-1) right now.
2024-05-13 20:01:41 <@jistone:fedora.im> 0 - I don't think we should approve it now, but keep exploring and go for the Change
2024-05-13 20:01:44 <@sgallagh:fedora.im> zbyszek: Kevin had "-1 or 0" 
2024-05-13 20:02:25 <@tstellar:fedora.im> (+3,1,-1) does anyone else want to vote?
2024-05-13 20:02:44 <@sgallagh:fedora.im> Does that include my implicit +1?
2024-05-13 20:03:03 <@sgallagh:fedora.im> (Looks like yes by my count)
2024-05-13 20:03:14 <@tstellar:fedora.im> Stephen Gallagher: jednorozec zbyszek with +1
2024-05-13 20:03:46 <@sgallagh:fedora.im> OK, we don't have anything approaching a consensus, so let's call that Proposal failed for now.
2024-05-13 20:04:01 <@sgallagh:fedora.im> danpb: Would you be willing to file a Change Proposal?
2024-05-13 20:04:07 <@sgallagh:fedora.im> I think that's probably the best next step
2024-05-13 20:05:09 <@berrange:matrix.org> yes, i'm happy enough  to carry on working to provide a fully functional PoC of reproducibility and a Change proposal
2024-05-13 20:05:23 <@zodbot:fedora.im> No Fedora Accounts users have the @berrange:matrix.org Matrix Account defined
2024-05-13 20:05:29 <@zodbot:fedora.im> No Fedora Accounts users have the @berrange:matrix.org Matrix Account defined
2024-05-13 20:05:42 <@zodbot:fedora.im> No Fedora Accounts users have the @berrange:matrix.org Matrix Account defined
2024-05-13 20:05:53 <@tstellar:fedora.im> Do we need to record an official decision?  It's not technically rejected, since not everyone voted, I think.
2024-05-13 20:05:59 <@jistone:fedora.im> look at all that karma floating away...
2024-05-13 20:06:33 <@sgallagh:fedora.im> Tom Stellard: A vote that doesn't pass maintains the status quo
2024-05-13 20:06:49 <@zbyszek:fedora.im> Tom Stellard: I think it was a valid decision. 5 people voted.
2024-05-13 20:07:15 <@tstellar:fedora.im> zbyszek: I think normally in this case,we would continue the vote in the ticket.
2024-05-13 20:07:16 <@sgallagh:fedora.im> Think of it as "The motion fails"
2024-05-13 20:07:49 <@tstellar:fedora.im> e.g. if this was an actual change proposal, then we couldn't reject it outright with these votes.
2024-05-13 20:07:55 <@sgallagh:fedora.im> Tom Stellard: Yeah, I think that's our usual policy, but I'm going to formally withdraw the proposal to make things easier :)
2024-05-13 20:08:04 <@tstellar:fedora.im> OK, let's move on.
2024-05-13 20:08:09 <@tstellar:fedora.im> !topic #3206 Nonresponsive maintainer: Lubomir Rintel lkundrak 
2024-05-13 20:08:13 <@zbyszek:fedora.im> !action danpb to carry on working to provide a fully functional PoC of reproducibility and a Change proposal
2024-05-13 20:08:19 <@tstellar:fedora.im> !fesco 3206
2024-05-13 20:08:20 <@berrange:matrix.org> thank you all for your time and useful debate
2024-05-13 20:08:22 <@zodbot:fedora.im> **fesco #3206** (https://pagure.io/fesco/issue/3206):**Nonresponsive maintainer: Lubomir Rintel lkundrak**

● **Opened:** 5 days ago by lihis
● **Last Updated:** Never
● **Assignee:** Not Assigned
2024-05-13 20:08:34 <@tstellar:fedora.im> This was raised on the list.  Quickly, what action do we need to take here?
2024-05-13 20:08:55 <@sgallagh:fedora.im> Why is this on the agenda? It hasn't been a week and no one proposed it with the `meeting` tag.
2024-05-13 20:09:12 <@sgallagh:fedora.im> NRM tickets are usually handled async.
2024-05-13 20:09:45 <@tstellar:fedora.im> Someone replied on the devel list to the agenda and asked about this.  If there is nothing to do, we can move on.
2024-05-13 20:10:01 <@zbyszek:fedora.im> Proposal: Give the two packages to lihis.
2024-05-13 20:10:09 <@jistone:fedora.im> I don't see that -- did they reply privately?
2024-05-13 20:10:29 <@tstellar:fedora.im> Oh yeah, it was a private reply, sorry.
2024-05-13 20:10:56 <@tstellar:fedora.im> Ok, let's have this just be a reminder to review the ticket and vote, then.
2024-05-13 20:10:59 <@zbyszek:fedora.im> Withdrawn.
2024-05-13 20:11:05 <@sgallagh:fedora.im> ack
2024-05-13 20:11:07 <@tstellar:fedora.im> !topic Next week's chair
2024-05-13 20:11:22 <@sgallagh:fedora.im> I'll pick it up; I missed my last turn
2024-05-13 20:11:33 <@tstellar:fedora.im> Stephen Gallagher: Thank you!
2024-05-13 20:11:45 <@tstellar:fedora.im> !action Stephen Gallagher will chair next meeting
2024-05-13 20:11:52 <@tstellar:fedora.im> !topic Open Floor
2024-05-13 20:12:04 <@tstellar:fedora.im> Any other topics for discussion?  
2024-05-13 20:13:46 <@tstellar:fedora.im> I'll close the meeting in 2 minutes if nothing else.
2024-05-13 20:14:40 <@zbyszek:fedora.im> Tom Stellard: thanks for chairing.
2024-05-13 20:15:00 <@sgallagh:fedora.im> Thanks for chairing, Tom Stellard . It was one of the more involved sessions.
2024-05-13 20:16:06 <@zodbot:fedora.im> sgallagh gave a cookie to tstellar. They now have 19 cookies, 4 of which were obtained in the Fedora 40 release cycle
2024-05-13 20:16:29 <@tstellar:fedora.im> !endmeeting