2024-05-20 19:00:09 <@sgallagh:fedora.im> !startmeeting FESCO (2024-05-20)
!meetingname fesco
Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @mhayden:fedora.im, @tstellar:fedora.im
!topic Init Process
2024-05-20 19:00:12 <@meetbot:fedora.im> Meeting started at 2024-05-20 19:00:09 UTC
2024-05-20 19:00:12 <@meetbot:fedora.im> The Meeting name is 'FESCO (2024-05-20) !meetingname fesco Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @mhayden:fedora.im, @tstellar:fedora.im !topic Init Process'
2024-05-20 19:00:18 <@sgallagh:fedora.im> !hi
2024-05-20 19:00:21 <@zodbot:fedora.im> Stephen Gallagher (sgallagh) - he / him / his
2024-05-20 19:00:26 <@jistone:fedora.im> !hi
2024-05-20 19:00:28 <@zodbot:fedora.im> Josh Stone (jistone) - he / him / his
2024-05-20 19:00:34 <@blackwell:fedora.im> !hi
2024-05-20 19:00:37 <@zodbot:fedora.im> Jason Blackwell (blackwell)
2024-05-20 19:00:53 <@zbyszek:fedora.im> !hi
2024-05-20 19:00:57 <@zodbot:fedora.im> Zbigniew Jędrzejewski-Szmek (zbyszek)
2024-05-20 19:00:59 <@nirik:matrix.scrye.com> morning (as usual, I am going to be in 2 meetings, so ping if I am needed and not answering. ;)
2024-05-20 19:01:05 <@humaton:fedora.im> !hi
2024-05-20 19:01:09 <@zodbot:fedora.im> Tomáš Hrčka (humaton) - he / him / his
2024-05-20 19:01:58 <@davide:cavalca.name> !hi
2024-05-20 19:02:04 <@zodbot:fedora.im> Davide Cavalca (dcavalca) - he / him / his
2024-05-20 19:02:07 <@mhayden:fedora.im> !hi
2024-05-20 19:02:12 <@zodbot:fedora.im> Major Hayden (mhayden) - he / him / his
2024-05-20 19:02:35 <@zodbot:fedora.im> mhayden gave a cookie to kevin. They now have 668 cookies, 9 of which were obtained in the Fedora 40 release cycle
2024-05-20 19:02:43 <@zodbot:fedora.im> mhayden gave a cookie to dcavalca. They now have 22 cookies, 1 of which were obtained in the Fedora 40 release cycle
2024-05-20 19:02:48 <@zodbot:fedora.im> mhayden has already given cookies to humaton during the F40 timeframe
2024-05-20 19:02:55 <@zodbot:fedora.im> mhayden gave a cookie to blackwell. They now have 2 cookies, 2 of which were obtained in the Fedora 40 release cycle
2024-05-20 19:03:46 <@nirik:matrix.scrye.com> shows how old I am. ;)
2024-05-20 19:03:52 <@sgallagh:fedora.im> Alright, I think we should get started. Today's agenda is packed
2024-05-20 19:04:27 <@sgallagh:fedora.im> We have three topics, all of which are likely to be controversial:
2024-05-20 19:04:51 <@sgallagh:fedora.im> * Redis -> Valkey
* SGX
* MacOS pre-built binaries
2024-05-20 19:05:15 <@sgallagh:fedora.im> I think it very likely we won't be able to get to all three today, so let me ask this: are any of these time-sensitive?
2024-05-20 19:05:28 <@nirik:matrix.scrye.com> no, I don't think so...
2024-05-20 19:06:02 <@jistone:fedora.im> maybe MacOS should be first since that's new?
2024-05-20 19:06:32 <@nirik:matrix.scrye.com> I thought we talked about the SGX thing last week and decided that they could persue a change for it? or was there more to decide?
2024-05-20 19:06:41 <@zbyszek:fedora.im> The situation with Redis hasn't changed since the last time we discussed this, so I don't think it makes much sense to discuss this here. I think we should wait until there's more clarity about where things stand. 
2024-05-20 19:07:16 <@zbyszek:fedora.im> Yeah. I don't think there's much point in discussing this here until we have an update (and ideally a Change Proposal).
2024-05-20 19:07:18 <@conan_kudo:matrix.org> !hi
2024-05-20 19:07:22 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2024-05-20 19:07:36 <@sgallagh:fedora.im> nirik: I kept SGX on the agenda because newer perspectives were brought up around whether it was acceptable for Fedora at all
2024-05-20 19:07:58 <@sgallagh:fedora.im> But if we want to put that one on the back-burner for today, that's fine
2024-05-20 19:08:32 <@sgallagh:fedora.im> (Honestly, I'm somewhat inclined to make SGX a Council problem before we come back to it)
2024-05-20 19:08:55 <@conan_kudo:matrix.org> Council will just punt it back to us
2024-05-20 19:09:25 <@sgallagh:fedora.im> Conan Kudo: Council sets policy; if they determine it's not sufficiently open-source for Fedora, that eliminates the need for us to figure out *how*
2024-05-20 19:09:38 <@conan_kudo:matrix.org> fair
2024-05-20 19:09:43 <@zbyszek:fedora.im> I think this is a deeply technical matter, so I don't think it makes sense to ask council for a decision. At least not until we actually know the details.
2024-05-20 19:09:54 <@sgallagh:fedora.im> But it sounds like the topic most in need of discussion today is probably the MacOS prebuilt binaries topic.
2024-05-20 19:10:01 <@sgallagh:fedora.im> So let's start there and see where we get
2024-05-20 19:10:02 <@conan_kudo:matrix.org> yeah
2024-05-20 19:10:39 <@berrange:matrix.org> so is that SGX off the agenda ?  i just want to know if i need to stick around ?
2024-05-20 19:10:54 <@conan_kudo:matrix.org> danpb: it's not off the agenda, it's just not first
2024-05-20 19:11:13 <@sgallagh:fedora.im> danpb: I can make sure to @mention you when we get to it.
2024-05-20 19:11:21 <@tstellar:fedora.im> !hi
2024-05-20 19:11:26 <@zodbot:fedora.im> Tom Stellard (tstellar)
2024-05-20 19:11:58 <@sgallagh:fedora.im> !topic Exception request to ship prebuilt macOS binaries in asahi-installer
2024-05-20 19:12:03 <@sgallagh:fedora.im> !fesco 3212
2024-05-20 19:12:07 <@zodbot:fedora.im> **fesco #3212** (https://pagure.io/fesco/issue/3212):**Exception request to ship prebuilt macOS binaries in asahi-installer**

● **Opened:** 5 days ago by dcavalca
● **Last Updated:** 4 days ago
● **Assignee:** Not Assigned
2024-05-20 19:12:17 <@conan_kudo:matrix.org> ping Davide Cavalca
2024-05-20 19:12:33 <@davide:cavalca.name> I'm here and happy to answer questions as needed
2024-05-20 19:13:04 <@davide:cavalca.name> (on mobile, so hopefully element cooperates)
2024-05-20 19:13:25 <@jistone:fedora.im> This is not a Fedora package at all, right? I'm not familiar with how we build/ship other installation artifacts.
2024-05-20 19:13:55 <@sgallagh:fedora.im> Davide Cavalca: One thing I'm confused about is why it's being packaged at all?
2024-05-20 19:14:16 <@sgallagh:fedora.im> It sounds like asahi-installer only ever runs on MacOS, so I'm not sure what the purpose is of building it as an RPM
2024-05-20 19:14:49 <@davide:cavalca.name> Asahi Installer is a Fedora package. We already package it for the runtime firmware logic. This ticket is about packaging the actual installer part which runs on macos
2024-05-20 19:15:30 <@sgallagh:fedora.im> I can understand needing a firmware loader on an installed Fedora system, but I'm unclear why you need the other part
2024-05-20 19:15:32 <@davide:cavalca.name> We'd like this packaged so it can be built in a trusted environment from a known spec, and so that we can use a  fedora built stage1 for the m1n1 bootloader 
2024-05-20 19:15:37 <@nirik:matrix.scrye.com> so is the eventual goal here to not have a remix and have everything in fedora?
2024-05-20 19:15:42 <@sgallagh:fedora.im> I can understand needing a firmware loader on an installed Fedora system, but I'm unclear on why you need the other part
2024-05-20 19:15:54 <@davide:cavalca.name> nirik: long term, yes
2024-05-20 19:16:12 <@davide:cavalca.name> We're trying to have as many pieces in Fedora proper as possible 
2024-05-20 19:16:56 <@sgallagh:fedora.im> Davide Cavalca: You're telling us the proximate reason, but not the goal. I think that's what nirik is getting at here.
2024-05-20 19:17:12 <@jistone:fedora.im> how do we handle things like Fedora Media Writer for other OSes?
2024-05-20 19:17:23 <@sgallagh:fedora.im> Josh Stone: Poorly :-(
2024-05-20 19:17:56 <@humaton:fedora.im> FMW is build in koji using clang
2024-05-20 19:18:41 <@nirik:matrix.scrye.com> FMW is a... larger topic
2024-05-20 19:19:11 <@davide:cavalca.name> The immediate goal is shipping a stage1 that comes from Fedora. A requirement for that is shipping an installer, as stage1 is installed by and bundled in the installer.
2024-05-20 19:19:32 <@jistone:fedora.im> I'm just looking for the status quo of MacOS builds
2024-05-20 19:19:42 <@davide:cavalca.name> The long term goal is enabling full support for Apple Silicon in upsteam fedora
2024-05-20 19:19:54 <@jistone:fedora.im> and hopefully we apply a consistent standard for these things
2024-05-20 19:19:58 <@davide:cavalca.name> And having a fedora shipped installer is a requirement for that 
2024-05-20 19:20:14 <@jonathanspw:fedora.im> !hi
2024-05-20 19:20:18 <@zodbot:fedora.im> Jonathan Wright (jonathanspw)
2024-05-20 19:20:28 <@davide:cavalca.name> Josh Stone: my understanding is that all existing toolchains for targeting macos rely on xcode
2024-05-20 19:20:49 <@davide:cavalca.name> I skimmed the xcode eula and it doesn't strike me as something we can use in fedora
2024-05-20 19:21:18 <@jistone:fedora.im> the koji `mediawriter` appears to only be the native app
2024-05-20 19:21:50 <@conan_kudo:matrix.org> we have a mingw-mediawriter for Windows
2024-05-20 19:22:09 <@conan_kudo:matrix.org> and macOS has a mediawriter binary built... elsewhere, and then submitted to releng to be notarized
2024-05-20 19:22:42 <@jistone:fedora.im> ok, thanks
2024-05-20 19:22:51 <@conan_kudo:matrix.org> we do not yet have a toolchain for building for macOS in Fedora
2024-05-20 19:22:57 <@nirik:matrix.scrye.com> right... well, it was... mediawriter folks have very few cycles to do anything and the signing stuff all changed and broke the releng building part
2024-05-20 19:23:03 <@tstellar:fedora.im> Can someone do a quick walk through of how the installer is used by a Fedora user?
2024-05-20 19:23:06 <@conan_kudo:matrix.org> it's not that it isn't possible, it has not been figured out
2024-05-20 19:23:18 <@humaton:fedora.im> even the mingw package is not the same thing we ship from get.fedora.oeg
2024-05-20 19:23:21 <@conan_kudo:matrix.org> in a way that doesn't trip over EULAs
2024-05-20 19:24:05 <@davide:cavalca.name> The user runs a curl | bash from macos to grab the installer bootstrap script and run it
2024-05-20 19:24:16 <@sgallagh:fedora.im> Tom Stellard: An application is run from within MacOS that does some tweaking of the OS, adjusts the partitions and queues things up to install to the disk after a reboot.
2024-05-20 19:24:27 <@davide:cavalca.name> The bootstrap script downloads the installer package (what the rpm would build) and runs it
2024-05-20 19:24:42 <@davide:cavalca.name> It then guides the user to perform the actual installation 
2024-05-20 19:25:11 <@sgallagh:fedora.im> Davide Cavalca: Ah, and we want the exact binary it downloads to be the one we've built in our infra, hence this request.
2024-05-20 19:25:12 <@zbyszek:fedora.im> Can we do the same for libffi and python? I.e. take the appropriate version of python and libffi from dist-git, build that "elsewhere", and submit for packaging as rpm?
2024-05-20 19:25:12 <@davide:cavalca.name> If you've ever used one of those "install linux alongside windows" things the UX is not too dissimilar 
2024-05-20 19:25:35 <@conan_kudo:matrix.org> Probably?
2024-05-20 19:25:56 <@tstellar:fedora.im> So the the goal is that  user can do something like curl `https://rpm-from-koji.url && rpm2cpio installer.rpm | cpio -idv | bash installer.sh` ?
2024-05-20 19:26:00 <@davide:cavalca.name> Theoretically, but Python in particular is non trivial to build
2024-05-20 19:26:14 <@tstellar:fedora.im> So the the goal is that  user can do something like curl `https://rpm-from-koji.url && rpm2cpio installer.rpm | cpio -idv && bash installer.sh` ?
2024-05-20 19:26:19 <@conan_kudo:matrix.org> It's something that would probably be worth working toward regardless.
2024-05-20 19:26:25 <@davide:cavalca.name> Franky I trust a lot more a signed upsteam build than one I'd do by hand on some random macos system 
2024-05-20 19:27:08 <@zbyszek:fedora.im> The upstream build is also done by hand on some random macos system.
2024-05-20 19:27:15 <@davide:cavalca.name> The bootstrap script would do that, the user would just curl|bash the bootstrap script. But yes, that's the gist
2024-05-20 19:27:23 <@tstellar:fedora.im> So the the goal is that  user can do something like `curl https://rpm-from-koji.url && rpm2cpio installer.rpm | cpio -idv && bash installer.sh` ?
2024-05-20 19:27:47 <@sgallagh:fedora.im> Davide Cavalca: My (admittedly brief) searches seem to suggest that XCode is unavoidable if you want to do anything related to a GUI, but for a purely terminal-based application, cross-compilation might be feasible
2024-05-20 19:29:12 <@davide:cavalca.name> This is purely terminal based, but whether Python is actually buildable with a purely terminal based toolchain I don't know. It's also unclear to me how one would build such a toolchain, but I'm happy to look at options if y'all have pointers 
2024-05-20 19:29:13 <@farchord:matrix.org> I think Xcode is also required for some terminal stuff... that's why it's a requirement when you install brew
2024-05-20 19:29:44 <@sgallagh:fedora.im> ugh
2024-05-20 19:29:56 <@conan_kudo:matrix.org> the macOS toolchain is very weird
2024-05-20 19:29:58 <@berrange:matrix.org> XCode is a decades old problem ....back when we introduced mingw to Fedora, we wanted to do the same for macOS, but there's no equivalent "clean"  impl of macOS headers like mingw provides, so the cross-compile option was not viable
2024-05-20 19:30:19 <@conan_kudo:matrix.org> This has gradually started improving thanks to Darling.
2024-05-20 19:30:27 <@conan_kudo:matrix.org> And prior to that PureDarwin.
2024-05-20 19:30:32 <@conan_kudo:matrix.org> and GNUStep
2024-05-20 19:31:11 <@davide:cavalca.name> I did look at darling fwiw but it didn't seem to be usable for this. It also bundles about fifty different forked things so packaging it would be... Interesting 
2024-05-20 19:31:28 <@sgallagh:fedora.im> I guess my concern is that if we can't realistically control the build-system, I'm not sure what packaging it gains us.
2024-05-20 19:31:50 <@tstellar:fedora.im> Davide Cavalca: And this is the only possible way to install Fedora on Mac hardware?
2024-05-20 19:32:14 <@davide:cavalca.name> Yes, this is the only way short of doing it completely by hand 
2024-05-20 19:32:21 <@jistone:fedora.im> going back to this goal -- can we build stage1 in Fedora and still do our own bundling "elsewhere"?
2024-05-20 19:32:26 <@sgallagh:fedora.im> Tom Stellard: Aside from VMs? I'm not aware of anyone coming up with another approach, no
2024-05-20 19:33:07 <@sgallagh:fedora.im> Josh Stone: Bundling of what in that sentence?
2024-05-20 19:33:58 <@davide:cavalca.name> My thinking here was that by having the installer in fedora we go from the installer being a random untrusted blob to it being a trusted package that relies on two smaller blobs (python and libffi)
2024-05-20 19:34:21 <@jistone:fedora.im> Stephen Gallagher: bundling macOS python and the script that will install everything, including our "stage1"
2024-05-20 19:35:06 <@farchord:matrix.org> Davide Cavalca: Just a thought, and stop me if this seems like a bad idea. Couldn't it be possible for us to build this, but for Homebrew?
2024-05-20 19:35:14 <@farchord:matrix.org> aka 'brew'?
2024-05-20 19:35:29 <@tstellar:fedora.im> I'm sorry if I missed this in the proposal, but where will these binaries be built?
2024-05-20 19:35:32 <@davide:cavalca.name> We could build the installer in copr I suppose, but that would still bundle python and libffi and not really improve things IMO.
2024-05-20 19:36:14 <@davide:cavalca.name> This is possible, I guess, but I don't see what it would gain us?
2024-05-20 19:36:47 <@davide:cavalca.name> Right now the PR I put in the ticket uses Python from upsteam python and libffi from Homebrew
2024-05-20 19:37:06 <@farchord:matrix.org> Bundling python owould no longer be necessary, as faras I understand it
2024-05-20 19:37:24 <@tstellar:fedora.im> Davide Cavalca: I mean, who's infrastructure will build this?
2024-05-20 19:37:27 <@davide:cavalca.name> And it builds the installer in koji as part of the asahi-installer package
2024-05-20 19:38:03 <@zbyszek:fedora.im> Can we cross-compile libffi in our own infrastracture?
2024-05-20 19:38:04 <@davide:cavalca.name> https://src.fedoraproject.org/rpms/asahi-installer/pull-request/2
2024-05-20 19:38:24 <@davide:cavalca.name> Same problem, we need a macos toolchain
2024-05-20 19:38:55 <@jistone:fedora.im> does "build the installer" actually compile anything? or is it just packaging-level activity?
2024-05-20 19:39:21 <@nirik:matrix.scrye.com> could the installer just say: hey, go install python/libffi from homebrew? or even offer to do so?
2024-05-20 19:39:41 <@tstellar:fedora.im> Oh I see, so the 'pre-built' binaries are libffi and python.
2024-05-20 19:40:17 <@davide:cavalca.name> https://github.com/AsahiLinux/asahi-installer/blob/main/build.sh is the build script. In Fedora we'd reuse the stage1 from m1n1-stage1 instead of building it here.
2024-05-20 19:40:25 <@tstellar:fedora.im> Would a macOS koji builder be possible? 
2024-05-20 19:41:06 <@sgallagh:fedora.im> Tom Stellard: I'm not sure that's useful without actually having a way to build the toolchain that such a builder would use
2024-05-20 19:41:09 <@davide:cavalca.name> This won't work, as we need the deps in the installer package itself, because it needs to run from the standalone recovery environment for stage2
2024-05-20 19:41:29 <@conan_kudo:matrix.org> the main piece to port for macOS would be mock
2024-05-20 19:41:48 <@conan_kudo:matrix.org> years ago, I built out an rpm package management stack on macOS, but I never got around to mock itself
2024-05-20 19:42:23 <@nirik:matrix.scrye.com> Davide Cavalca: ah, so the user runs it, it reboots into recovery for the install?
2024-05-20 19:42:24 <@conan_kudo:matrix.org> that's the only thing missing to make koji work
2024-05-20 19:42:29 <@davide:cavalca.name> I'm not a lawyer but I can tell you virtualizing macos is... problematic. I suppose you could maybe use an aws instance?
2024-05-20 19:43:11 <@tstellar:fedora.im> Davide Cavalca: There are several services that provide cloud based macOS machines.
2024-05-20 19:43:26 <@zbyszek:fedora.im> I was quite opposed initially to the proposal, but I'm now leaning towards a more positive view. In a way, this is similar to the firmware case, where we have some code which will not run on a Fedora system, but on a Mac system with MacOS. Using the binaries built upstream seems like the least bad solution. We're not experts at building stuff for MacOS, so replicating the builds that are already done doesn't gain us much. It's likely that it could introduce additional problems and bugs. And since that code is never going to be executed on a Linux system, it's like firmware, i.e. something that we accept for pragmatic reasons.
2024-05-20 19:43:29 <@davide:cavalca.name> Yes, step 1 is repartitioning and installing, step 2 is going in recovery to replace the stub macos install kernel with m1n1 stage1.
2024-05-20 19:43:42 <@davide:cavalca.name> (yes, the boot chain is somewhat entertaining)
2024-05-20 19:44:29 <@sgallagh:fedora.im> Davide Cavalca: "Entertaining" is a very nice euphemism for "shitshow" :-P 
2024-05-20 19:44:38 <@tstellar:fedora.im> We could use the Mac System toolchain.
2024-05-20 19:44:58 <@nirik:matrix.scrye.com> you could possibly copy those from the homebrew installed ones before going to recovery?
2024-05-20 19:45:01 <@davide:cavalca.name> Hey at least there's no emulated punch cards here 😛
2024-05-20 19:45:08 <@sgallagh:fedora.im> Tom Stellard: And what is that gaining us? If we haven't built the toolchain, we can't fully trust it.
2024-05-20 19:45:57 <@davide:cavalca.name> I don't know but I suspect it would be tricky. Also it would introduce a hard dependency on brew. Not everyone can/wants to use brew
2024-05-20 19:46:06 <@nirik:matrix.scrye.com> (that might give you version problems tho)
2024-05-20 19:46:30 <@nirik:matrix.scrye.com> well, or download the apple one(s)
2024-05-20 19:46:35 <@tstellar:fedora.im> Stephen Gallagher: At least then we can modify the binaries we ship.  It's better than the proposal to ship binaries from upstream.
2024-05-20 19:46:51 <@sgallagh:fedora.im> Davide Cavalca: What does the cross-section between "people who would install Fedora on a Mac" and "people who would install Homebrew" look like?
2024-05-20 19:47:05 <@sgallagh:fedora.im> I suspect the Venn Diagram looks much like a circle :-)
2024-05-20 19:47:26 <@davide:cavalca.name> I can tell you I personally dislike homebrew and avoid using it.
2024-05-20 19:47:31 <@sgallagh:fedora.im> Tom Stellard: Fair enough; it's an improvement certainly. I'm just not sure if it's enough of one to justify the work.
2024-05-20 19:47:32 <@conan_kudo:matrix.org> likewise
2024-05-20 19:47:42 <@conan_kudo:matrix.org> I avoid homebrew on my Macs
2024-05-20 19:47:48 <@davide:cavalca.name> Some people use nix for a similar usecase to brew.
2024-05-20 19:47:52 <@blackwell:fedora.im> Is our version of the installer going to support installing other distros? 
2024-05-20 19:47:58 <@humaton:fedora.im> I am one of those people I got mac only because of asahi, I have no idea how to do anything on mac
2024-05-20 19:47:58 <@tstellar:fedora.im> Also depending on what the definition of 'toolchain' is, I don't think it would be that hard to get a custom one for Mac.
2024-05-20 19:48:47 <@davide:cavalca.name> The installer itself can install anything. The manifest as shipped in fedora would only include fedora.
2024-05-20 19:48:49 <@sgallagh:fedora.im> Tom Stellard: From the earlier conversation, it sounds like the only viable toolchain is XCode
2024-05-20 19:48:53 <@conan_kudo:matrix.org> there's not really another definition from the perspective of building python: working compiler and standard library for the operating system are basic requirements, nevermind the other libraries that need to be built
2024-05-20 19:49:40 <@tstellar:fedora.im> Conan Kudo: I think the question is would we need to build our own standard libary too or can we use the system one?  If we just need to build the compiler, than that is not that difficult.
2024-05-20 19:49:48 <@nirik:matrix.scrye.com> so how about the idea then of downloading those in the installer? I guess its more error prone and subject to network problems...
2024-05-20 19:50:06 <@nirik:matrix.scrye.com> (but I guess there's validation of them... )
2024-05-20 19:50:13 <@davide:cavalca.name> The installer is written in python. It can't run without python.
2024-05-20 19:50:20 <@sgallagh:fedora.im> OK, we've been on this topic for 50 minutes
2024-05-20 19:50:22 <@tstellar:fedora.im> Stephen Gallagher: Isn't xcode is just clang + framework headers and libraries.
2024-05-20 19:50:26 <@conan_kudo:matrix.org> macOS only exposes the loader and syscall interface through its standard library, so applications cannot load without linking to it
2024-05-20 19:50:44 <@conan_kudo:matrix.org> you cannot swap standard libraries in macOS like you can on Linux
2024-05-20 19:50:49 <@davide:cavalca.name> "framework headers and libraries" are not open source 
2024-05-20 19:50:53 <@conan_kudo:matrix.org> the Go people found out the hard way
2024-05-20 19:51:02 <@davide:cavalca.name> Or at least not that I can find 
2024-05-20 19:51:03 <@zbyszek:fedora.im> Yeah. And even if we _could_ get a build with some custom toolchain, I don't think it'd really be a benefit. Would we be able to trust those builds better than the upstream ones that presumably get some QA and are fairly widely used? I don't think so. So this would be asking for a lot of effort from our contributors for little gain.
2024-05-20 19:51:35 <@conan_kudo:matrix.org> if we had the ability to have a compatible toolchain, there's independent value in that, but we don't right now
2024-05-20 19:51:47 <@tstellar:fedora.im> Davide Cavalca: I know, but how much does that matter?  The proposed python libraries we are shipping also link against those closed source headers and libraries.
2024-05-20 19:51:55 <@sgallagh:fedora.im> OK, so does anyone want to make a formal proposal here? At least to see where we're coming down on this?
2024-05-20 19:52:05 <@conan_kudo:matrix.org> there are reimplementations that are sufficiently compatible, but I do not know if they've been ABI verified yet beyond in Darling
2024-05-20 19:52:21 <@sgallagh:fedora.im> I guess I'll propose the original request, just to see where it lands.
2024-05-20 19:52:55 <@tstellar:fedora.im> Can't you make this same argument about everything we package, though?  I mean upstream binaries are always going to get better QA.
2024-05-20 19:53:09 <@davide:cavalca.name> There's a big difference between distribution of something compiled with a proprietary toolchain (almost always ok as otherwise the toolchain is kinda useless) and distribution of the toolchain itself (not ok, at least from my read of the eula)
2024-05-20 19:53:14 <@conan_kudo:matrix.org> No. Actually in general I would probably say the QA levels of upstream are similar or worse than us.
2024-05-20 19:53:16 <@sgallagh:fedora.im> Proposal: FESCo will permit the inclusion of binaries provided by upstream Python and FFI exclusively for the purposes of loading the installer on MacOS since we have no reasonable way to cross-compile for that platform at this time.
2024-05-20 19:53:30 <@conan_kudo:matrix.org> Stephen Gallagher: +1
2024-05-20 19:53:57 <@nirik:matrix.scrye.com> I'm -1 right now, I'd like to look at the chain of things here...
2024-05-20 19:54:37 <@jistone:fedora.im> -1
2024-05-20 19:54:37 <@tstellar:fedora.im> I'm still -1 on this.  I don't koji is the right place to distribute these.
2024-05-20 19:54:56 <@dcantrell:fedora.im> well for some reason I had my calendar off by one hour
2024-05-20 19:55:00 <@dcantrell:fedora.im> am I too late today?
2024-05-20 19:55:20 <@zbyszek:fedora.im> No, certainly not. We do better builds than most upstreams and actually test that software in Fedora. There are some exceptions, but they are fairly rare. The crucial difference is that we're talking about software for macos. We are not able to test this at all, and we don't have any expertise about macos. We don't care about macos. But for packages built for Linux, we care, we are experts, and we do a huge amount of testing _with everything else that we package_.
2024-05-20 19:55:25 <@nirik:matrix.scrye.com> you are never too late, you arrive exactly when you do. ;)
2024-05-20 19:55:31 <@sgallagh:fedora.im> dcantrell: We're discussing the MacOS installer topic
2024-05-20 19:55:58 <@dcantrell:fedora.im> ahh
2024-05-20 19:56:11 <@zbyszek:fedora.im> Stephen Gallagher: +1
2024-05-20 19:56:27 <@humaton:fedora.im> Stephen Gallagher: +1
2024-05-20 19:56:41 <@dcantrell:fedora.im> reading back here
2024-05-20 19:56:46 <@dcantrell:fedora.im> I read the ticket too
2024-05-20 19:56:54 <@dcantrell:fedora.im> ah, there's the proposal
2024-05-20 19:57:04 <@sgallagh:fedora.im> Right now, I count (+4, 0, -3)
2024-05-20 19:57:28 <@dcantrell:fedora.im> from what I've read now, consider me -1 as well
2024-05-20 19:57:42 <@sgallagh:fedora.im> OK, (+4, 0, -4)
2024-05-20 19:58:04 <@sgallagh:fedora.im> Only mhayden has not voted.
2024-05-20 19:59:02 <@tstellar:fedora.im> mhayden: No pressure ;)
2024-05-20 19:59:20 <@mhayden:fedora.im> I'm leaning +1 here, but more like a +0.5 that got rounded up to +1 :)
2024-05-20 19:59:54 <@nirik:matrix.scrye.com> I think theres no reason to be in a rush...
2024-05-20 19:59:58 <@mhayden:fedora.im> There's a ton of value in Asahi, so that makes me +1 on the limited scope proposed by Stephen Gallagher 
2024-05-20 20:00:03 <@nirik:matrix.scrye.com> but perhaps thats just me
2024-05-20 20:00:04 <@sgallagh:fedora.im> To be clear, I'd like for us to have a better solution in the future, but this discussion leads me to believe that this will be the work of many months, possibly years
2024-05-20 20:00:18 <@conan_kudo:matrix.org> to be clear, I'd hope that one day we'd have a macOS toolchain to be able to eliminate this and use our own sources to build our own binaries
2024-05-20 20:00:19 <@sgallagh:fedora.im> So I'd like to not make the Asahi folks block on this.
2024-05-20 20:00:44 <@conan_kudo:matrix.org> we're just... not there
2024-05-20 20:01:05 <@davide:cavalca.name> Yeah in case it wasn't clear I think everyone sees this as a stopgap, and as soon as a better option becomes available we'd switch to that
2024-05-20 20:01:08 <@sgallagh:fedora.im> !agreed FESCo will permit the inclusion of binaries provided by upstream Python and FFI exclusively for the purposes of loading the installer on MacOS since we have no reasonable way to cross-compile for that platform at this time. (+5, 0, -4)
2024-05-20 20:01:26 <@sgallagh:fedora.im> That's the most contentious vote I've seen in a while
2024-05-20 20:01:42 <@conan_kudo:matrix.org> it went reasonably okay as far as discussions go
2024-05-20 20:01:49 <@conan_kudo:matrix.org> not even an ugly vote
2024-05-20 20:01:56 <@conan_kudo:matrix.org> just split
2024-05-20 20:02:23 <@sgallagh:fedora.im> !topic Request exception to permit shipping pre-built, signed SGX
2024-05-20 20:02:29 <@sgallagh:fedora.im> !fesco 3205
2024-05-20 20:02:32 <@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:** a week ago by berrange
● **Last Updated:** 2 hours ago
● **Assignee:** Not Assigned
2024-05-20 20:02:38 <@sgallagh:fedora.im> danpb: I promised to ping you when we got here.
2024-05-20 20:03:03 <@zbyszek:fedora.im> I don't think anything has changed here. Should we just wait for the updated proposal?
2024-05-20 20:03:19 <@sgallagh:fedora.im> I put this back on the agenda because the discussion we had last week was lacking in one critical component.
2024-05-20 20:04:03 <@sgallagh:fedora.im> We skipped past deciding consciously whether this mechanism is something we actually want in Fedora and spent our time figuring out HOW to do it instead.
2024-05-20 20:04:42 <@sgallagh:fedora.im> Several folks raised concerns in the FESCo ticket about whether SGX enclaves would be in opposition to Fedora's mission
2024-05-20 20:04:44 <@jistone:fedora.im> the entire "secure enclave" mechanism?
2024-05-20 20:05:16 <@sgallagh:fedora.im> Specifically, whether enabling it constitutes revoking control of the running system from the users.
2024-05-20 20:05:36 <@sgallagh:fedora.im> (I'm not sure I subscribe to that view, but it has been raised and should be discussed)
2024-05-20 20:05:56 <@berrange:matrix.org> IMHO that's mis characterizing what SGX does 
2024-05-20 20:05:57 <@jistone:fedora.im> I only see that if the user is forced to run such enclaves somehow
2024-05-20 20:06:19 <@conan_kudo:matrix.org> for what it's worth, even though FPC elected to punt it to FESCo, the FPC wasn't particularly enthused about this either
2024-05-20 20:06:43 <@tstellar:fedora.im> I think the real question is can we ship binaries for sources that we can't modify.
2024-05-20 20:06:46 <@berrange:matrix.org> the user chooses what apps they want to run, and if there's an app restricts where it will run, that app would not be in Fedora, and users could choose not to run it
2024-05-20 20:06:55 <@humaton:fedora.im> I have to step away for 10 minutes to herd the ducks into the coop
2024-05-20 20:07:02 <@conan_kudo:matrix.org> ... ducks?
2024-05-20 20:07:05 <@zbyszek:fedora.im> Hmm, I think it's the opposite. It's about allowing users to have to not trust the cloud vendor. I.e. instead of trusting the CPU manufacturer _and_ the Cloud operator, users only have to trust the CPU manufacturer. Maybe that's not something that most people care about, but some people do, and enabling that doesn't seem to be against any Fedora principles.
2024-05-20 20:07:07 <@conan_kudo:matrix.org> I need pictures
2024-05-20 20:07:18 <@conan_kudo:matrix.org> anyway
2024-05-20 20:07:54 <@sgallagh:fedora.im> jednorozec: So, no change in activity for you, then?
2024-05-20 20:07:55 <@berrange:matrix.org> in the context of TDX,   SGX is providing the owner of the machine, a way to prove to the guest VM, that their VM is secure... which is a totally reasonable thing a Fedora user running a virt host might want todo
2024-05-20 20:07:56 <@nirik:matrix.scrye.com> side question: how often do the enclaves update?
2024-05-20 20:08:05 <@jistone:fedora.im> depends on who you're calling the "user"... the cloud operator loses control in this situation, but that's a service they choose to provide.
2024-05-20 20:08:10 <@conan_kudo:matrix.org> as I stated in the ticket, my perspective is that shipping software that runs in the host environment (even if it's cordoned off by the CPU) but cannot be built and maintained by Fedora is effectively out of scope for Fedora
2024-05-20 20:08:27 <@conan_kudo:matrix.org> it runs in a Fedora environment but can't actually be maintained by Fedora is pretty bad
2024-05-20 20:08:38 <@berrange:matrix.org> intel releases SGX software stadck multiple times a year and that includes the enclaves
2024-05-20 20:08:39 <@conan_kudo:matrix.org> which means we accept all the risks and responsibility without any power to fix anything
2024-05-20 20:09:09 <@conan_kudo:matrix.org> we also effectively cannot operate as a check on Intel, nor can we reasonably prove that their published code works because we cannot run it
2024-05-20 20:09:44 <@tstellar:fedora.im> Yeah, this is the main issue I see.  I don't think the SGX technology itself is an issue.
2024-05-20 20:09:45 <@conan_kudo:matrix.org> if we build it ourselves, that is
2024-05-20 20:10:18 <@conan_kudo:matrix.org> this makes SGX enclaves completely undesirable
2024-05-20 20:10:19 <@sgallagh:fedora.im> danpb: Let me ask the question from a different angle: If we (Fedora) don't ship this stack, is there another way for users to take advantage of it, or does it require deep plumbing in the OS?
2024-05-20 20:10:21 <@berrange:matrix.org> i don't get that claim - we can show it working
2024-05-20 20:10:39 <@jistone:fedora.im> I don't understand this "check" angle, when the proposal includes rebuilding to make sure we have corresponding source
2024-05-20 20:10:40 <@zbyszek:fedora.im> I don't think we accept any responsibility. At least no more than we accept responsibility when we ship a µcode update for the CPU.
2024-05-20 20:11:00 <@jistone:fedora.im> I do agree that it's bad that we can't modify that source
2024-05-20 20:11:08 <@conan_kudo:matrix.org> no, we can't use our binaries either
2024-05-20 20:11:17 <@conan_kudo:matrix.org> that means I have no way of reasonably knowing if it works
2024-05-20 20:11:27 <@berrange:matrix.org> as a bit of context, other confidential VM technology has similar signature chaining schemes, but the difference is that they do it 100% in closed source firmware so its completely opaque
2024-05-20 20:11:34 <@tstellar:fedora.im> Why can't we use our binaries?  I thought we agreed last time we could.
2024-05-20 20:11:45 <@conan_kudo:matrix.org> we cannot, because Intel will not sign them to run
2024-05-20 20:11:45 <@zbyszek:fedora.im> Sorry, but that doesn't make any sense. We run it, and it either works or it doesn't.
2024-05-20 20:12:05 <@conan_kudo:matrix.org> it requires digital signing similar to what we have to do for UEFI
2024-05-20 20:12:10 <@sgallagh:fedora.im> Tom Stellard: We can use binaries whose signed hash matches the ones we built, but not our actual binaries
2024-05-20 20:12:20 <@berrange:matrix.org> Intel TDX is actually more OSS friendly that all the other CVM technology...which would get a free pass in Fedora since its all just in firmware where we can't see it
2024-05-20 20:12:26 <@tstellar:fedora.im> My take away was that if they were byte-for-byte identical, then we could use our own binaries.
2024-05-20 20:12:40 <@conan_kudo:matrix.org> They cannot be identical because we cannot get them signed
2024-05-20 20:12:43 <@jistone:fedora.im> in principle, if we've achieved a reproducible build, we can transfer the signature to our binary
2024-05-20 20:13:31 <@tstellar:fedora.im> That was not my understanding.  danpb Can you confirm this?
2024-05-20 20:13:45 <@conan_kudo:matrix.org> yes we do, we accept the compliance risk and responsibility for all code we are aware of...
2024-05-20 20:13:52 <@dcantrell:fedora.im> I've gotta go if I am going to make my train, talk to everyone later
2024-05-20 20:13:58 <@sgallagh:fedora.im> zbyszek: He means we cannot load our built binaries because without the signature, they won't actually be loadable in the hardware
2024-05-20 20:14:11 <@zbyszek:fedora.im> Says who?
2024-05-20 20:14:19 <@conan_kudo:matrix.org> says Council, Legal, etc.
2024-05-20 20:14:26 <@berrange:matrix.org> consider you build a binary in Fedora, using the requisite reprodicible toolchain.... we send that binary off to Intel for signing... and they send us back a binary...    the thing we would get back is indistinguishable from the pre-built binary Intel will ship
2024-05-20 20:15:26 <@berrange:matrix.org> in terms of legal risk, there's issues around licenses and patents for crypto.... but we can verify the licenses in the normal manner since this is 100% OSS, and we can audit their crypto usage likewise
2024-05-20 20:15:36 <@conan_kudo:matrix.org> but we can't change anything
2024-05-20 20:15:41 <@conan_kudo:matrix.org> we can't fix anything
2024-05-20 20:15:50 <@conan_kudo:matrix.org> we're just stuck holding the wet paper bag
2024-05-20 20:15:50 <@berrange:matrix.org> if we found a CVE, we can't fix it ourselves... we have to wait for Intel to issue a fix
2024-05-20 20:15:58 <@conan_kudo:matrix.org> that's not okay at all
2024-05-20 20:16:24 <@conan_kudo:matrix.org> because at that point, we should just merge the nvidia driver into the Fedora repos, because we're at essentially the same situation
2024-05-20 20:16:32 <@sgallagh:fedora.im> Conan Kudo: He's arguing that it's effectively like we've gotten a firmware blob that we have to load. Except we ALSO got the source with it so we can at least verify that the binary matches the sources (which can be reviewed, even if not changed)
2024-05-20 20:16:35 <@sgallagh:fedora.im> Do I have that right?
2024-05-20 20:16:36 <@conan_kudo:matrix.org> we have plenty of examples of things we've excluded because of things like this
2024-05-20 20:16:37 <@berrange:matrix.org> but bear in mind that a CVE in the enclaves is a *critical* show stopper from Intel's pov - as this is the root of trust for their whole ecosystem
2024-05-20 20:16:52 <@zbyszek:fedora.im> The original quote was "we have no way of knowing if it works". This is … just plain false. The versions that we'd ship would be the versions with the original signature, and we certainly can it and have a confirmation that it works.
2024-05-20 20:17:01 <@berrange:matrix.org> the idea that we'll find a CVE ourselves, have a fix, and be sitting around waiting a long time for intel to ship a fix just doesn't  feel like a likely scenario
2024-05-20 20:17:11 <@conan_kudo:matrix.org> sure it does
2024-05-20 20:17:20 <@davide:cavalca.name> If you can't run it's fundamentally not OSS, at least by some definitions of OSS
2024-05-20 20:17:24 <@conan_kudo:matrix.org> you cannot assume they'd actually respond quickly or slowly, they are both valid outcomes
2024-05-20 20:17:45 <@conan_kudo:matrix.org> and thus you have to account for both
2024-05-20 20:18:36 <@davide:cavalca.name> > <@berrange:matrix.org> in terms of legal risk, there's issues around licenses and patents for crypto.... but we can verify the licenses in the normal manner since this is 100% OSS, and we can audit their crypto usage likewise

If you can't run modifed versions it's fundamentally not OSS, at least by some definitions of OSS
2024-05-20 20:18:44 <@conan_kudo:matrix.org> I have no reason to believe they'd be slow, but I equally no reason to believe they'd be quick either
2024-05-20 20:18:48 <@berrange:matrix.org> well its compliant with the terms of the licenses used - i accept some people have preferences for what a license /should/ require but that's a philosophical issue
2024-05-20 20:19:10 <@conan_kudo:matrix.org> I have no reason to believe they'd be slow, but I equally see no reason to believe they'd be quick either
2024-05-20 20:19:34 <@zbyszek:fedora.im> This situation is actually similar to the case of python for macosx. We have no control over the builds there, but based on past behaviour and reasonable expectations, we assume that a fixed build will be provided if appropriate.
2024-05-20 20:19:39 <@nirik:matrix.scrye.com> o we should tell intel: thanks, but could you close source this and redo it as a binary blob so we could could ship it?
2024-05-20 20:19:55 <@conan_kudo:matrix.org> well, we don't support any of the alternative enclaves either
2024-05-20 20:20:16 <@berrange:matrix.org> what do you mean by alternative enclaves here ?
2024-05-20 20:20:43 <@conan_kudo:matrix.org> but bluntly, the only reason this is an issue is that Intel does not offer a program for our builds to be signed without following their exact stuff
2024-05-20 20:20:54 <@davide:cavalca.name> IMO saying "this is firmware with source" is fine (because it's effectively what it is). Then point becomes: are we ok distributing this as firmware?
2024-05-20 20:21:05 <@conan_kudo:matrix.org> which is even more restrictive than what shim does
2024-05-20 20:21:23 <@conan_kudo:matrix.org> and shim is already an unhappy situation for us
2024-05-20 20:21:36 <@davide:cavalca.name> With the caveat that this "firmware" isn't necessary for core hardware enablement, but for a specific usecase/component.
2024-05-20 20:22:02 <@berrange:matrix.org> but our users would be more unhappy if we had refused to have shim in fedora
2024-05-20 20:22:38 <@berrange:matrix.org> it was a case of taking the least worst option in a undesirable situation
2024-05-20 20:22:45 <@conan_kudo:matrix.org> we aren't disallowed from having our own builds of shim though
2024-05-20 20:22:52 <@conan_kudo:matrix.org> we just have to wait forever for MSFT to process them
2024-05-20 20:23:28 <@conan_kudo:matrix.org> that is still better than being told we can't make any modifications at all
2024-05-20 20:23:48 <@zbyszek:fedora.im> Yeah. Effectively this is a very bad situation. At least in this regard, just having Intel do the builds would most likely be better, with the turnaround time much smaller.
2024-05-20 20:23:49 <@sgallagh:fedora.im> In theory, we don't NEED a signed shim because users could install their own keys in the EFI
2024-05-20 20:23:54 <@sgallagh:fedora.im> But in practice that's a nightmare
2024-05-20 20:24:15 <@sgallagh:fedora.im> It DOES allow testing of shim without needing it to be signed by a third party though
2024-05-20 20:24:29 <@conan_kudo:matrix.org> right, and we can't do that with the way this is done for SGX
2024-05-20 20:24:32 <@davide:cavalca.name> Can users install their own key for the enclave for dev/testing/etc or is intel the sole gatekeeper?
2024-05-20 20:24:48 <@berrange:matrix.org> well there is a way to test SGX enclaves using what intel call "simulator" mode
2024-05-20 20:25:15 <@conan_kudo:matrix.org> that sounds like it doesn't access the real secure element
2024-05-20 20:25:20 <@berrange:matrix.org> which is basically a pure software alternative runtime  that you build and run your enclave against
2024-05-20 20:25:28 <@nirik:matrix.scrye.com> the shim case is different tho because shim is something we develop... in this case the thing is something they develop... so it should be faster for them to sign because they would vet it as they built it.
2024-05-20 20:26:02 <@berrange:matrix.org> it doesn't give you all the security guarantees of the real hardware - its just a dummy runtime that's supposed to be enough for purposes of testing 
2024-05-20 20:26:44 <@sgallagh:fedora.im> danpb: OK, that's interesting. So some degree of testing IS possible then
2024-05-20 20:27:00 <@davide:cavalca.name> Ok so there's no way to run binaries one has built from source on the actual hardware without intel signing them. You can run them in the simulator but that's not the actual hardware. Is this a fair characterization?
2024-05-20 20:27:35 <@jistone:fedora.im> (much like any signed firmware)
2024-05-20 20:27:51 <@berrange:matrix.org> there's one part of this i'm not 100% clear on too, which is exaclty how the intel signature on the enclave actually ends up being part of the root of trust  for signatures that are given back tot he guest
2024-05-20 20:29:10 <@zbyszek:fedora.im> I thought that the CPU just refuses to run the code if it doesn't accept the signature?
2024-05-20 20:29:13 <@berrange:matrix.org> it is possible to load an enclave with a custom signing cert...but i've never been able to verify the signatures the guest gets back... so i'm not sure if this is fundamentally impossible, or i'm missing some key nugget of info
2024-05-20 20:29:32 <@zbyszek:fedora.im> Oh, OK.
2024-05-20 20:29:35 <@berrange:matrix.org> that was my previous impression, and indeed early versions of sgx would refuse to load
2024-05-20 20:30:24 <@berrange:matrix.org> but current versions of SGX aren't restricted in that way - indeed linux kernel just tells SGX to allow anything
2024-05-20 20:30:45 <@berrange:matrix.org> but there's some kind of private key derivation process that uses the enclave signer as an input
2024-05-20 20:31:24 <@berrange:matrix.org> so while you can load anything, functionally the signatures can't be verified as tools expect
2024-05-20 20:31:25 <@sgallagh:fedora.im> I'm not sure how to parse that.
2024-05-20 20:31:42 <@sgallagh:fedora.im> Are you saying that it will just silently NOT protect memory if the key doesn't work?
2024-05-20 20:31:50 <@tstellar:fedora.im> Where are we going with this discussion?  We are way over time.
2024-05-20 20:32:06 <@berrange:matrix.org> no, no, this is just about attestation - memory is always protected
2024-05-20 20:32:24 <@sgallagh:fedora.im> Tom Stellard: Technically, we aren't. The FESCo meeting is blocked out for two hours. But yeah, it's getting very late for Europe
2024-05-20 20:32:57 <@tstellar:fedora.im> Stephen Gallagher: Oh it's 2 hours, I thought it was 1 for some reason.
2024-05-20 20:33:21 <@zbyszek:fedora.im> Technically, it's was already quite late when we started. But I don't disagree that it's even later now. But if we continue for a while, it'll be early :)
2024-05-20 20:33:23 <@sgallagh:fedora.im> We TRY to keep it short, but we knew going in that today was going to be a long one 
2024-05-20 20:33:52 <@sgallagh:fedora.im> zbyszek: Oh, well that's alright then!
2024-05-20 20:34:41 <@sgallagh:fedora.im> But to Tom Stellard 's point: we should take a moment to figure out if this conversation is leading to a decision
2024-05-20 20:35:40 <@sgallagh:fedora.im> I'll try a proposal, just to see where it goes:
2024-05-20 20:36:33 <@sgallagh:fedora.im> Proposal: FESCo considers the SGX enablement bits to be effectively firmware, albeit firmware whose source we can read and build for confirmation. As such, we'll allow it under the firmware provisions.
2024-05-20 20:36:56 <@conan_kudo:matrix.org> Stephen Gallagher: -1
2024-05-20 20:37:10 <@conan_kudo:matrix.org> it can't be considered firmware since it runs in the main operating environment
2024-05-20 20:37:54 <@tstellar:fedora.im> Where is our firmware policy documented?
2024-05-20 20:38:10 <@zbyszek:fedora.im> Hmm, this goes very quite far. I would very much prefer to get the full Change proposal with all the details, and approve that. In particular, as worded, this would allow just distributing the Intel binaries as they are. I think the proposal with the rebuilt binaries in our infra via reproducible builds is a much nicer alternative.
2024-05-20 20:38:11 <@nirik:matrix.scrye.com> I'm not comfortable voting yes on this right now, but I think it's worth further investigation/a change proposal our community can discuss further and we can then decide on.
2024-05-20 20:38:32 <@conan_kudo:matrix.org> https://docs.fedoraproject.org/en-US/legal/license-approval/#_licenses_allowed_for_firmware
2024-05-20 20:39:07 <@berrange:matrix.org> we don't seem to actually define /what/   "firmware" means though, unless I missed it ?
2024-05-20 20:39:41 <@sgallagh:fedora.im> danpb: See the link Conan Kudo just posted
2024-05-20 20:40:03 <@conan_kudo:matrix.org> it's the second subheading about technical firmware requirements
2024-05-20 20:40:10 <@tstellar:fedora.im> Does it meet this criteria: `The files must be standalone, not embedded in executable or library code (within the Fedora Linux context)` ?
2024-05-20 20:40:25 <@berrange:matrix.org> ok, that's a pretty loose definition, that SGX enclaves would satisfy IMHO
2024-05-20 20:40:25 <@jistone:fedora.im> > While these technical requirements for firmware have nothing to do with licensing, they are included here for convenience.

is there a primary location for these requirements?
2024-05-20 20:41:19 <@berrange:matrix.org> the SGX enclaves are standalone files - they are in ELF format, like normal library code, but they are not loaded by the normal ld.so loader
2024-05-20 20:41:23 <@nirik:matrix.scrye.com> used to be on the wiki, probibly got lost in the docs migration?
2024-05-20 20:42:51 <@sgallagh:fedora.im> OK, do we want to just request that danpb files it as a Change with as much detail as possible and take it to that process?
2024-05-20 20:43:39 <@nirik:matrix.scrye.com> yeah, I thought thats what we decided last week. :)
2024-05-20 20:43:48 <@zbyszek:fedora.im> Me too.
2024-05-20 20:46:23 <@sgallagh:fedora.im> My batteries are running dry. Does anyone want to continue this or shall we call it a day?
2024-05-20 20:47:21 <@zbyszek:fedora.im> Proposal: we'll wait for a Change proposal will all the details.
2024-05-20 20:47:47 <@sgallagh:fedora.im> zbyszek: I don't think we want to vote on a proposal of "let's wait to vote" P)
2024-05-20 20:47:51 <@sgallagh:fedora.im> zbyszek: I don't think we want to vote on a proposal of "let's wait to vote" :)
2024-05-20 20:48:49 <@berrange:matrix.org> just FYI, a change proposal would not be until F42 timeframe, since kernel pieces aren't  likely to merge in time for F41 schedule
2024-05-20 20:49:47 <@jistone:fedora.im> I'm fine with waiting, but I think we're going to really have to nail down "is this firmware?"
2024-05-20 20:49:49 <@zbyszek:fedora.im> OK, a different proposal?
2024-05-20 20:51:07 <@sgallagh:fedora.im> danpb: It's not too early to file an F42 Change :)
2024-05-20 20:52:22 <@sgallagh:fedora.im> Alright, I'm going to move on to the closing bits.
2024-05-20 20:52:32 <@sgallagh:fedora.im> !topic Next Week's Chair
2024-05-20 20:53:20 <@zbyszek:fedora.im> I can do it.
2024-05-20 20:53:26 <@sgallagh:fedora.im> Thanks
2024-05-20 20:53:42 <@sgallagh:fedora.im> !action zbyszek to chair the 2024-05-27 meeting
2024-05-20 20:53:48 <@sgallagh:fedora.im> !topic Open Floor
2024-05-20 20:54:06 <@sgallagh:fedora.im> Does anyone have anything for Open Floor? (Please say "no")
2024-05-20 20:54:21 <@zbyszek:fedora.im> The floor is lava. Don't say anything.
2024-05-20 20:54:33 <@conan_kudo:matrix.org> 🔥
2024-05-20 20:54:45 <@conan_kudo:matrix.org> also, I still want pictures of the ducks from jednorozec 
2024-05-20 20:54:53 <@sgallagh:fedora.im> OK, thanks folks.
2024-05-20 20:55:06 <@conan_kudo:matrix.org> also, I still want pictures of the ducks from jednorozec :P
2024-05-20 20:55:24 <@zbyszek:fedora.im> Stephen Gallagher: thanks for chairing.
2024-05-20 20:55:24 <@jistone:fedora.im> next week is US memorial day
2024-05-20 20:55:34 <@conan_kudo:matrix.org> yeah, I'm not planning on being here
2024-05-20 20:55:38 <@sgallagh:fedora.im> Oh, right. Yeah, I won't be around.
2024-05-20 20:56:09 <@sgallagh:fedora.im> If we don't have quorum, who can chair on June 3rd?
2024-05-20 20:57:05 <@zbyszek:fedora.im> I can.
2024-05-20 20:57:12 <@sgallagh:fedora.im> Alright, thanks
2024-05-20 20:57:16 <@sgallagh:fedora.im> !endmeeting