16:00:30 <sgallagh> #startmeeting ELN SIG 2022-04-08
16:00:31 <zodbot> Meeting started Fri Apr  8 16:00:30 2022 UTC.
16:00:31 <zodbot> This meeting is logged and archived in a public location.
16:00:31 <zodbot> The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <zodbot> The meeting name has been set to 'eln_sig_2022-04-08'
16:00:35 <sgallagh> #meetingname eln
16:00:35 <zodbot> The meeting name has been set to 'eln'
16:00:40 <sgallagh> #topic Init Process
16:00:42 <sgallagh> .hi
16:00:42 <zodbot> sgallagh: Something blew up, please try again
16:00:45 <zodbot> sgallagh: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:01:06 <sgallagh> .hi
16:01:06 <zodbot> sgallagh: Something blew up, please try again
16:01:09 <zodbot> sgallagh: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:01:26 <cyberpear> .hello2
16:01:27 <zodbot> cyberpear: Something blew up, please try again
16:01:30 <zodbot> cyberpear: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:01:33 <salimma> .hi
16:01:34 <zodbot> salimma: Something blew up, please try again
16:01:35 <sgallagh> .hello sgallagh
16:01:36 <zodbot> salimma: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:01:39 <zodbot> sgallagh: Something blew up, please try again
16:01:42 <zodbot> sgallagh: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:01:42 <salimma> oh dear zodbot
16:01:49 <sgallagh> OK, zodbot is out of order.
16:01:56 <tdawson> Hello.  My name is Troy.  I am here.
16:02:03 <salimma> does it complain every time it's mention too? wow
16:02:17 <dcavalca> .hi
16:02:18 <salimma> Hello. My name is Michel. I think I'm here too.
16:02:19 <zodbot> dcavalca: Something blew up, please try again
16:02:22 <zodbot> dcavalca: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:02:31 <sgallagh> My name is Stephen Gallagher and I'm not all here.
16:02:31 <dcavalca> oh well
16:02:40 <asosedkin> Hello. My name is Alex. I am here.
16:02:50 <sgallagh> Thanks for joining us today, Alex
16:02:51 <neverpanic> Hi everyone, my name is Clemens Lang, I'm here too.
16:03:39 <asosedkin> ^ the openssl VIP
16:03:44 <SSmoogen> I think nirik or someone has to do something with fasjson and zodbot in situations like this
16:03:47 <sgallagh> Nice to see you Clemens
16:03:53 * nirik nods.
16:04:54 <nirik> zodbot: reload Fedora
16:04:54 <zodbot> nirik: Kneel before zod!
16:04:54 <sgallagh> Is it at least recording the meeting that it claims to have started?
16:04:54 <SSmoogen> you didn't kneel first
16:05:01 <SSmoogen> it should be.. it just didn't have the correct Fedora userlist
16:05:14 <sgallagh> ok
16:05:22 <nirik> sgallagh: yes, that issue only affects it querying fasjson...yeah, what SSmoogen said
16:05:35 <sgallagh> #topic crypto-policies
16:05:38 <nirik> should be fixed now, carry on. ;)
16:05:46 <sgallagh> Thank you
16:06:26 <sgallagh> I invited some of the crypto gurus here today to discuss getting Fedora ELN aligned with RHEL's crypto-policies.
16:06:46 <sgallagh> There are essentially two questions to answer here:
16:07:01 <salimma> .hi
16:07:02 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:07:18 <sgallagh> 1) Do we want ELN to diverge from Fedora Rawhide for this (I am emphatically "yes" on this)
16:07:18 <sgallagh> 2) What are the steps we need to take to get there?
16:07:27 <sgallagh> * 1. Do we want ELN to diverge from Fedora Rawhide for this? (I am emphatically "yes" on this)
16:07:27 <sgallagh> 2. What are the steps we need to take to get there?
16:07:37 <dcavalca> 1) yes, definitely
16:07:40 <asosedkin> 1 - sounds like a yes
16:07:57 <dcavalca> speaking as someone currently dealing with the sha1 fallout on my end, being able to use ELN to get a heads up that was coming would have been fantastic
16:08:31 <sgallagh> Yeah, I honestly didn't realize until this week that we weren't tracking the RHEL crypto here.
16:08:36 <asosedkin> 2 - likely what you've proposed in your MR with conditioning on different upstream tarballs (thank you for that)
16:08:42 <sgallagh> I completely missed that.
16:09:02 <sgallagh> I'm glad I could help there.
16:09:07 <tdawson> I agree with the others.  (1) is a yes.  Especially if RHEL 9 is already doing it.
16:09:18 <asosedkin> though it makes maintenance rather awkward, with fedora packaging having to track two upstream branches
16:09:38 <sgallagh> But neverpanic also raised some concerns regarding OpenSSL 3, if I understood correctly.
16:09:49 <sgallagh> So we should be tracking those as well.
16:10:02 <neverpanic> those should be fixed as soon as https://bugzilla.redhat.com/show_bug.cgi?id=2071615 is fixes
16:10:06 <asosedkin> I'm not really familiar with ELN, are there maybe better mechanisms to diverge than specfile conditionals?
16:10:14 <neverpanic> I merged the changes a few minutes ago
16:10:30 <sgallagh> asosedkin: We *can* split them into separate it into its own branch, but in general we vastly prefer to keep things in the Rawhide branch.
16:10:36 <salimma> maybe having the divergence be made obvious in the spec will also nudge Fedora into aligning its crypto policy
16:10:38 <sgallagh> Because then we don't miss anything when Fedora makes a change.
16:10:46 <jforbes> I am in favor of the crypto policy changes. The methods might get pushback if we require people to change specs
16:10:52 <asosedkin> salimma: no, Fedora has vastly different goals
16:11:07 <sgallagh> jforbes: Sorry, can you clarify the second half of that?
16:11:41 <jforbes> sgallagh: there are people in the community already rather opposed to having conditionals in the spec.
16:11:50 <asosedkin> sgallagh: could you elaborate on the downsides of having a separate branch?
16:12:08 <sgallagh> jforbes: They're not mandatory, merely strongly preferred.
16:12:16 <dcavalca> I personally prefer conditionals to a separate branch, but ultimately it's up the package maintainers
16:12:43 <dcavalca> asosedkin: separate branch usually meaning doing twice the work tracking and merging changes, and possibly forgetting to do so
16:12:53 <salimma> yeah... it can't be a uniform approach I suppose. I know package maintainers who are opposed to having EPEL-specific conditionals in rawhide, for instance
16:12:56 <sgallagh> asosedkin: Essentially that changes get merged to Rawhide and not to ELN because it's forgotten.
16:13:03 <asosedkin> I'm afraid not in the crypto-policies case =)
16:13:19 <sgallagh> asosedkin: Not what?
16:13:22 <salimma> if we have separate branches we need an automated rebase mechanism
16:13:37 <sgallagh> Michel Alexandre Salim 🎩: We don't need to solve the general case here.
16:13:47 <asosedkin> changes going into rawhide are 1. largely decoupled from changes going into RHEL
16:13:57 <asosedkin> 2. lag behind by several years
16:13:59 <sgallagh> But as dcavalca said, it's an increase in effort for the maintainer and also prone to being forgotten
16:14:12 <SSmoogen> ok who is the maintainer of the package?
16:14:17 <asosedkin> me
16:14:17 <SSmoogen> what do they want?
16:14:37 <asosedkin> ELN to magically follow CentOS 9 Stream and not Fedora =)
16:14:51 <sgallagh> ...
16:15:01 <sgallagh> That might actually be possible.
16:15:20 <SSmoogen> if you have a way to do that and keep yourself sane, then I would say 'it is something to be considered'
16:15:25 <neverpanic> We have the same question not only for crypto-policies, but for openssl as well. At the moment, the built-in default of OpenSSL without any config would allow SHA-1. If we also want to change that to the CentOS 9/RHEL 9 behavior, we'd also need a separate openssl in ELN.
16:15:28 <sgallagh> I hadn't thought of that previously, but I may be able to rig something up with DistroBuildSync
16:15:53 <dcavalca> sgallagh: that's an interesting idea
16:15:57 <asosedkin> neverpanic: this is unfortunate, but I'd say this is a rather static change
16:16:08 <neverpanic> Now, the built-in default really doesn't matter as long as people aren't running things with OPENSSL_CONF=/dev/null, so we may just ignore that corner case
16:16:16 <sgallagh> Actually... no. It would need both DistroBuildSync and DistroGitSync.
16:16:16 <dcavalca> it does result in divergence between Fedora and CentOS, which in general I don't think we'd want to encourage
16:16:21 <dcavalca> but it would help in cases like this
16:16:22 <sgallagh> Still doable, but harder.
16:16:35 <asosedkin> neverpanic: while with c-p we're talking every update I make
16:17:04 <sgallagh> My major concern there is that we would, by necessity, be moving the official location to work on an ELN package to CentOS Stream
16:17:27 <sgallagh> And we would have potential conflicts if someone accidentally merged changes directly to ELN.
16:17:42 <dcavalca> sgallagh: could we protect the eln branch somehow in that case?
16:18:04 <asosedkin> sgallagh: from my POV I'd call that a preferred case, because inheriting otherwise right is even harder
16:18:21 <asosedkin> (protected ELN branch tracking c9s branch)
16:18:26 <jforbes> We can remove packages from the autobuild, though it can be overridden in some circumstances
16:18:30 <sgallagh> dcavalca: Unfortunately, we don't have controls that granular (by branch)
16:18:54 <jforbes> In fact, I have explicitly used it to get around some issues that RHEL isn't designed to
16:19:36 <sgallagh> jforbes: The ELN autobuild? Yeah, we already exclude some things like the secure boot chain
16:19:46 <sgallagh> (Since the autobuild user doesn't have signing privileges)
16:19:58 <salimma> in the case of this package, we can just block direct push altogether, right?
16:20:12 <sgallagh> But my main concern is that if the git commit histories get out of sync, that's a harder issue to resolve.
16:20:27 <jforbes> sgallagh: Right, I just meant that it will prevent rawhide from overriding ELN most of the time, but if someone is determined, they can force through
16:20:35 <salimma> some packages already require PRs for everything (there's an unrelated issue that Pagure lets provenpackagers bypass that without even a warning)
16:20:35 <sgallagh> No, because asosedkin would still want push access to the Rawhide branch
16:20:56 <sgallagh> jforbes: I'm not worried about builds. We have easy fixes for that with tags.
16:21:00 <salimma> make asosedkin a provenpackager :)
16:21:05 <sgallagh> But breaking the git sync would be hard.
16:21:11 <sgallagh> Michel Alexandre Salim 🎩: I wouldn'
16:21:16 <sgallagh> t want to risk THAT either
16:21:31 <sgallagh> If we did this, I'd need to exclude this package from PP access too
16:21:34 <jforbes> Right, that requires manual intervention at the least, and possibly legal approval depending on how long it had been done
16:21:59 <dcavalca> this seems like a lot of work for a fairly narrow usecase tbh
16:22:11 <SSmoogen> ok are we trying to get the perfect answer in a meeting?
16:22:17 <sgallagh> OK, FTR I'm going to assume from the direction of this conversation that we are all agreed we WANT the RHEL policy in ELN.
16:22:43 <sgallagh> #agreed Fedora ELN should use the RHEL crypto-policies, rather than the Fedora ones. (Unanimous)
16:22:55 <sgallagh> Actually, another thought just occurred to me.
16:23:38 <sgallagh> We probably want to START from CentOS Stream 9, but going forward I would think we would want ELN's crypto-policies to be available as a testbed for RHEL 10 policy.
16:23:47 <jforbes> exactly
16:23:56 <sgallagh> And if that's the case, a non-manual sync doesn't make much sense.
16:24:33 <jforbes> At some point, it needs to break.  Even if RHEL 10 doesn't change, some release in the future will, and it needs to be used in ELN long before that is branched to CS
16:24:37 <asosedkin> hm, problem is, predicting RHEL-10 crypto-policy is out of the reach of my crystal ball
16:24:42 <sgallagh> asosedkin: FWIW, until they diverge, it's pretty easy to get it set up so that you can trivially pull from c9s to the ELN branch
16:25:08 <sgallagh> asosedkin: Sure, but as it gets closer, I'm guessing you'd want at least some tweaks before we hit CentOS Stream 10 launch
16:25:31 <sgallagh> I'd be happy to help you set that manual sync up.
16:25:34 <neverpanic> My concern with this decision is that unless ELN also uses openssl with the same patches as in c9s, this will mean ELN with the LEGACY crypto-policy will no longer be able to use SHA-1 in TLS.
16:25:40 <dcavalca> asosedkin: how/where do you normally develop crypto-policies for the N+1 release?
16:26:05 <sgallagh> neverpanic: So let's do the same thing for openssl
16:26:21 <sgallagh> Create an `eln` branch and manually keep it in sync with the c9s branch (for now)
16:26:26 <jforbes> neverpanic: How much of a patch is that? Can it be cased out?
16:26:28 <asosedkin> RHEL-9 crypto-policies aim to answer the question of "what cryptography is safe to use in 2035", I don't think we have a solid idea for RHEL-10
16:27:07 <neverpanic> I'd rather not have a branch, since it would mean we'd have one more branch to fix for all CVEs.
16:27:35 <asosedkin> dcavalca: RHEL-9 is very aggressive already, and by the time we'll have RHEL-10 plans I think there will be c10s already, so, in c10s
16:27:40 <neverpanic> jforbes: A few lines of diff, nothing that couldn't be done, especially considering we already have the patch on c9s.
16:27:46 <sgallagh> neverpanic: Fine, conditionalize it. I'm happy with that.
16:28:07 <asosedkin> +1 on conditionalizing openssl part
16:28:09 <jforbes> neverpanic: Right, but for kernel for instance, we have a bit in the specs that build a very different kernel, all based on if fedora conditionals
16:28:18 <sgallagh> asosedkin: OK, but the possibility exists, so I'd prefer not to close that avenue
16:28:56 <asosedkin> sgallagh: could you outline what's the closest flow available now that you have in mind?
16:29:10 <neverpanic> #action clang Conditionalize openssl in ELN to behave as C9S
16:29:11 <asosedkin> for when eln "tracks" c9s
16:30:19 <sgallagh> asosedkin: I can create the `eln` branch on Fedora, create a `centos_stream` remote and pull the history from `c9s` into `eln`.
16:30:54 <asosedkin> and then I do manual pushes there when I merge c9s MRs?
16:30:59 <sgallagh> Then subsequent pushes to `c9s` could also be trivially pulled and built for ELN. (Updating the tarballs in the lookaside cache when needed)
16:31:31 <sgallagh> Hmm, we might be able to set up a CI action in c9s to do that part for you...
16:31:48 <Eighth_Doctor> .hello ngompa
16:31:49 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:32:04 <asosedkin> ... so the biggest technical question is how to protect eln branch?
16:32:26 <sgallagh> asosedkin: I think we skip "protecting" the eln branch.
16:32:34 <Eighth_Doctor> ehhh, why do we need an eln branch for this?
16:32:46 <sgallagh> Because as long as they have a common history, we can always do a `git merge -s ours` to get them back in sync.
16:32:55 <sgallagh> (With the downside of a merge commit, of course)
16:33:08 <Eighth_Doctor> the crypto-policies package should be the same one in rawhide and we can tweak on the %rhel conditional
16:33:18 <sgallagh> Conan Kudo: They use different upstream source tarballs
16:33:24 <Eighth_Doctor> why?
16:33:34 <sgallagh> https://src.fedoraproject.org/rpms/crypto-policies/pull-request/10
16:33:50 <asosedkin> Eighth_Doctor: because the task of determining sane defaults for Fedora lifetime and RHEL lifetime leads to very different results
16:34:11 <asosedkin> with Fedora lagging behind RHEL
16:34:20 <Eighth_Doctor> that seems flawed for the purpose of ELN
16:34:31 <Eighth_Doctor> yeah, no, I think we've made a fundamental mistake here
16:34:43 <asosedkin> that is an objective necessity
16:34:50 <dcavalca> we _could_ use conditionals for the source tarball, at least in theory
16:35:04 <sgallagh> dcavalca: Right, see the link above to the MR I suggested initially.
16:35:25 <dcavalca> oh of course, yes that's exactly what I had in mind, thanks sgallagh
16:35:54 <Eighth_Doctor> here's my problem: using the same sources doesn't mean we can't have different configurations in those sources
16:35:55 <Eighth_Doctor> so why aren't we doing that?
16:36:05 <sgallagh> The tarball for crypto-policies is essentially ALL configuration
16:36:09 <sgallagh> (As I understand it)
16:36:32 <sgallagh> asosedkin: Is that an accurate assessment?
16:36:44 <Eighth_Doctor> yes, okay, so why isn't there a split in the sources itself (similar to how the kernel package works?)
16:36:54 <sgallagh> There is. RHEL and Fedora have separate branches.
16:37:07 <Eighth_Doctor> so that's what I'm getting at, they shouldn't be separate branches
16:37:26 <asosedkin> sgallagh: sans the docs and tests, the tarball for crypto-policies is either configuration files or what generates configuration files
16:37:47 <asosedkin> but yeah, the code is trivial, and the effective consumed output is configuration
16:37:49 <jforbes> The reason kernel can do the split that it does is because we started working on this long before ELN was even a thing.
16:38:05 <Eighth_Doctor> jforbes: that doesn't excuse fixing it now for crypto-policies
16:38:31 <sgallagh> Conan Kudo: May I suggest that we have a "perfect is the enemy of the good" situation here?
16:38:32 <Eighth_Doctor> doing ELN properly here means we should strive to unify sources, otherwise we're not actually testing Rawhide as RHEL
16:38:44 <Eighth_Doctor> Stephen Gallagher: I think your PR is a perfect starting point
16:38:49 <Eighth_Doctor> I'm saying that we should avoid the eln branch entirely
16:38:50 <sgallagh> It may be desirable to unify things in the long run, but right now we have the current reality to deal with.
16:38:56 <Eighth_Doctor> and instead work to fix this
16:39:13 <jforbes> Eighth_Doctor: given infinite resources sure, we don't exactly have that or I might actually get more sleep than I do
16:39:28 <asosedkin> Eighth_Doctor: I have no idea what "unifying things" could mean in crypto-policies case
16:39:43 <Eighth_Doctor> jforbes: we have two years between now and the next branching cycle, and sha-1 distrust is going to happen in fedora itself before rhel10 branch
16:39:43 <sgallagh> jforbes: You get to sleep? I figured they just hooked you up with a caffeine IV
16:40:00 <Eighth_Doctor> if we don't even make it a north star and try, it's never going to happen
16:40:06 <jforbes> asosedkin: So, for the kernel package, we have separate config directories for fedora and rhel, and both config files are generated and added to the ssrpm
16:40:29 <asosedkin> Eighth_Doctor: FTR, sha-1 distrust in Fedora has no timing dependency on RHEL
16:40:31 <Eighth_Doctor> if the whole point of ELN is to make it easier to make RHEL from Fedora, then we should take that approach to everything that's "brand/configuration"
16:40:33 <jforbes> Eighth_Doctor: you are assuming that sha-1 is the only issue
16:40:58 <Eighth_Doctor> I'm making a reasonable assumption that it is likely the headline driver for this in the first place
16:41:08 <Eighth_Doctor> because that's literally what all the list discussion has been about
16:41:13 <dcavalca> let's say we went with sgallagh PR -- what issues would that cause?
16:41:27 <sgallagh> .
16:41:38 <asosedkin> Eighth_Doctor: it is the most impactful planned change, but when it lands in Fedora bears no relationship to RHEL-10
16:41:58 <sgallagh> dcavalca: Well, if Fedora's c-p package is updated rarely, but RHEL's more frequently, it might lead to meaningless Fedora builds.
16:42:10 <Eighth_Doctor> meh
16:42:12 <dcavalca> that's probably fine
16:42:24 <asosedkin> what's the changelog gonna look like? =D
16:42:40 <Eighth_Doctor> whatever you want it to be :D
16:42:45 <dcavalca> same as it looks on the RHEL side, I'd assume
16:42:50 <Eighth_Doctor> it's still a curated changelog, so it should be easy enough
16:42:57 <dcavalca> but yeah, basically whatever you want
16:43:06 <dcavalca> this isn't using rpmautospec
16:43:34 <Eighth_Doctor> (thank goodness for that)
16:43:36 <asosedkin> so it's gonna grow two changelogs
16:43:43 <jforbes> We auto generate the kernel changelog, but it ignores a number of tagged entries
16:43:54 <sgallagh> * Some Guy (foo@bar.net) - 1.2.3-1
16:43:54 <sgallagh> - RHEL9: Drop support for SHA-1
16:43:54 <sgallagh> - Fedora: Re-enable support for ROT13
16:43:54 <Eighth_Doctor> nah, just one changelog, just has info on everything
16:44:03 <Eighth_Doctor> which is actually not a bad thing
16:44:08 <asosedkin> Eighth_Doctor: that'd be an UX nightmare IMO
16:44:19 <asosedkin> one changelog for two unrelated configs
16:44:38 <Eighth_Doctor> the point is that they will stop being unrelated eventually
16:44:45 <Eighth_Doctor> and if you need help doing that, well, that's what we're for
16:44:47 <sgallagh> Conan Kudo: I think that's probably wishful thinking
16:44:53 <asosedkin> Eighth_Doctor: wait
16:45:07 <dcavalca> asosedkin: if you use a consistent prefix, it's not too bad, as you could 'grep RHEL9' and get all the related content for example
16:45:19 <Eighth_Doctor> Stephen Gallagher: everything in Linux is wishful thinking
16:45:20 <asosedkin> Eighth_Doctor: I think there's some misunderstanding here, as I hold a very different view
16:45:25 <Eighth_Doctor> so nope, I don't care :P
16:45:36 <asosedkin> Eighth_Doctor: Fedora state of c-p will never match RHEL's state of c-p by definition
16:46:15 <Eighth_Doctor> uhh why?
16:46:32 <jforbes> Eighth_Doctor: because our lifecycle is 1 year and not 10.
16:46:33 <asosedkin> oversimplified, Fedora's state of c-p is "list the algorithms safe to use in two years", RHEL's state of c-p is "list the algorithms safe to use in ten years"
16:46:44 <asosedkin> can't converge that
16:47:21 <jforbes> asosedkin: until quantum makes enough advancement to where your list is empty for both
16:47:26 <salimma> sounds like you can have the Fedora list be a supplement to the EL list then
16:47:56 <salimma> when you remove an algo from the EL list, if it's still deemed safe for Fedora, add it to the Fedora list, if unsafe for both, then just yank it
16:48:00 <Eighth_Doctor> alternatively, those two configurations could live in the same branch under separate folder hierarchies, but yeah, I don't think it makes sense to say that there's no convergence point
16:48:10 <asosedkin> jforbes: `* dc7a8ce (main, rawhide) sorry folks, I give up` =D
16:48:13 <SSmoogen> ok we are coming up to the end of the meeting and was wondering if there had been anything else on the agenda
16:48:24 <asosedkin> SSmoogen: I have an addition to the agenda
16:49:04 <asosedkin> besides "what's the source of eln c-p" I'd like to add "how do we coordinate the earth-shattering kaboom that happens when we do"
16:49:05 <SSmoogen> so can we table this try to make something perfect in 50 minutes by talking at each other part?
16:49:14 <asosedkin> but, I guess, that's gonna be postponed =)
16:49:28 <sgallagh> Before we move on, I just want to get to one answer: how do we proceed TODAY?
16:49:43 <SSmoogen> mailing list discussion?
16:49:52 <sgallagh> asosedkin: Do you want to move forward with my proposed MR or use a branch?
16:50:00 <asosedkin> sgallagh: I guess we should discuss the proposed flows with you, not sure where
16:50:01 <sgallagh> If the latter, I'll whip something up for you ASAP.
16:50:12 <sgallagh> OK, we'll take it to #fedora-eln then
16:50:15 <asosedkin> sgallagh: I prefer a branch, but I'm open for arguments for both
16:50:20 <sgallagh> What was your other agenda item?
16:50:28 <asosedkin> landing the change
16:50:44 <asosedkin> distrusting SHA-1 signatures in DEFAULT is disruptive
16:50:54 <sgallagh> #action sgallagh and asosedkin to finalize the branch-vs-rawhide approach
16:51:07 <sgallagh> #topic Timeline for landing the SHA-1 removal
16:51:25 <jforbes> it would require a sidetag build
16:51:27 <asosedkin> so we need something side-tag-like for that
16:51:44 <sgallagh> We can do side-tag builds for ELN
16:51:45 <Eighth_Doctor> If we can get COPR, OBS, and our major third party repo configurations to work without SHA-1, then we can land it for F38
16:52:08 <Eighth_Doctor> and ELN now obviously
16:52:10 <sgallagh> Just `fedpkg request-side-tag --base-tag eln-build`
16:52:10 <Eighth_Doctor> OBS is already set, COPR needs work, and we haven't done any ISV outreach
16:53:04 <salimma> Conan Kudo: this basically affects ISVs that mostly produce desktop software, I take it? the ones that do server software, I'd hope, would already be preparing for EL9
16:53:14 <salimma> so the Zooms of the world
16:53:15 <Eighth_Doctor> Michel Alexandre Salim 🎩: the server people are worse off
16:53:32 <Eighth_Doctor> the desktop software actually tend to do better
16:53:45 <Eighth_Doctor> because support calls == cost
16:54:05 <asosedkin> oh, note that the change will affect openssl 3.0, and not openssl 1.1
16:54:08 <Eighth_Doctor> B2B software tends to be considerably further behind
16:54:10 <salimma> ugh. but yeah let's not derail this, we can commiserate about servers later
16:54:38 <asosedkin> so the Zooms of the world may only jump ship when we deprecate *and* remove openssl 1.1
16:54:45 <sgallagh> asosedkin: Presumably also NSS and gnutls?
16:54:47 <Eighth_Doctor> in any case, we are on OpenSSL 3.0 as of F36, so we're looking at the F38-ish window
16:55:04 <sgallagh> We still have the 1.1 compat lib in F36
16:55:05 <Eighth_Doctor> asosedkin: the main worry is actually package signatures, most everything else is fine
16:55:14 <asosedkin> sgallagh: NSS and gnutls are in better standing; not an NSS expert, but gnutls should already block SHA-1
16:55:22 <neverpanic> The biggest problem for 3rd parties is probably that their package signing GPG keys contain an encryption subkey that has a binding signature made with SHA-1, because that's what you used to get when creating a key with GPG
16:55:32 <Eighth_Doctor> yup
16:55:47 <neverpanic> Luckily most of those just don't use the encryption subkey at all, so that can be worked around by importing just the main (and signing) key
16:55:52 <Eighth_Doctor> I'm going through a lot of pain because of it right now
16:55:55 <asosedkin> Eighth_Doctor: I assume that all worries we identify now will be 30% of the total worries tops
16:56:07 * Eighth_Doctor shrugs
16:56:08 <asosedkin> 70% more we'll find only when we break it
16:56:16 <jforbes> git could be problematic
16:56:26 <Eighth_Doctor> unless you care about the new Russian CA that's sha-1, I think we're going to be mostly fine
16:56:31 <sgallagh> neverpanic: When did that default change?
16:56:35 <Eighth_Doctor> git doesn't use openssl, iirc?
16:56:35 <sgallagh> (GPG)
16:56:37 <asosedkin> lol, is it SHA-1?
16:56:47 <asosedkin> let's block SHA-1 =)
16:56:58 <Eighth_Doctor> huh, so it is
16:57:01 <Eighth_Doctor> that's... odd
16:57:05 <asosedkin> just joking, it's TLS and in TLS we already block SHA-1
16:57:09 <Eighth_Doctor> given Git's license
16:57:28 <neverpanic> sgallagh: A while ago, but don't have an exact version for you. Problem is, most people generated their keys a while ago, and even modern gpg will not change the signature type on existing keys afaik.
16:57:29 <salimma> asosedkin: it's a hilarious read https://koen.engineer/russias-certificate-authority-for-sanctioned-organizations-645d61af8ac6
16:57:56 <sgallagh> Mostly I was curious since I created a new key in 2020 :)
16:58:13 <neverpanic> Use pgpdump on it, it'll tell you.
16:58:17 <asosedkin> salimma: I even read the Russian propaganda coverage of it, but failed to notice it's SHA-1
16:58:25 <salimma> TL;DR not sha1, but the cert payload Yandex sends to its users is signed with SHA1
16:58:41 <salimma> and then they encrypt with AES256 but hardcode the key in the browser so anyone can decryp tit
16:59:08 <Eighth_Doctor> Stephen Gallagher: the key I created in 2018 was sha1 :/
16:59:14 <asosedkin> should I attend the next meeting as well?
16:59:17 <Eighth_Doctor> so if it changed, it would be very recent
16:59:29 <sgallagh> asosedkin: That would probably be helpful
16:59:36 <asosedkin> I have a feeling we should digest all of that and continue
16:59:50 <sgallagh> We can continue the discussion in #fedora-eln for now
16:59:54 <salimma> quick update before we dismiss
16:59:58 <sgallagh> As we are at the top of the hour (and I need lunch)
17:00:09 <salimma> follow up from last meeting, I have some pending docs for EPEL pointing to ELN Extras https://pagure.io/epel/pull-request/170
17:00:11 <asosedkin> even if we reach agreement in the meantime, we should protocol it, right?
17:00:18 <salimma> once that's approved I'll add a pointer to it from the ELN side
17:00:58 <dcavalca> also quick update: I have two new ELN Extras workflows merged, one for the CentOS Hyperscale SIG and one for stuff Meta cares about specifically
17:01:03 <sgallagh> asosedkin: Yeah, we'll bring it back to the group before we land any builds in ELN
17:01:09 <dcavalca> we'll keep extending these in the coming weeks/months/etc
17:01:10 <asosedkin> cool
17:01:13 <sgallagh> dcavalca++
17:01:13 <zodbot> sgallagh: Karma for dcavalca changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:17 <sgallagh> I saw that, thanks!
17:01:40 <Eighth_Doctor> Stephen Gallagher: I'm hoping to do the same for datto in the near future
17:01:49 <Eighth_Doctor> now that I know how to do it from Davide Cavalca
17:02:07 <sgallagh> Great!
17:02:12 <salimma> it's a really nice way to track who cares about a package, as opposed to who's the nominal maintainer
17:02:17 <sgallagh> Thanks for leading the way, Davide
17:02:20 <Eighth_Doctor> yup
17:02:29 <Eighth_Doctor> I just didn't have time so thankfully he figured it out :D
17:02:38 <Eighth_Doctor> now I can just steal his methodology :D
17:02:50 <salimma> Troy did it for KDE too :)
17:03:05 <dcavalca> btw, I wasn't sure how robust our yaml parser is, but I assume we can put comments in these?
17:03:12 <Eighth_Doctor> yes, but tdawson is a god-king
17:03:41 <sgallagh> Now now, don't go too far. He's barely a god-prince :-P
17:03:58 <tdawson> No no ... I think he's right.   God King is correct. :)
17:04:08 <sgallagh> dcavalca: I'm actually not sure what parser the Content Resolver is using, but I think it's just python-yaml
17:04:09 * salimma bows down
17:04:24 <dcavalca> that's probably fine then
17:04:45 <dcavalca> I might end up attaching some metadata in the comments for the Meta one down the road to make internal tracking easier on my end, but we'll see
17:05:16 <sgallagh> Makes sense
17:05:18 <salimma> if we decide it's sensitive we can always strip them in a preprocessor
17:05:33 <Eighth_Doctor> let's not make yaml more awful please
17:05:43 <sgallagh> Note that Content Resolver also has a container-based generator that you can try out on your YAML before submitting if you want to.
17:05:54 <tdawson> salimma: After I re-read them, your pull request on the document sounds right  ... I'll do a verification to make sure everything works.
17:05:55 <dcavalca> oh that's great to know
17:06:07 <salimma> tdawson: thanks
17:06:12 <sgallagh> It's... not fast. But it works,.
17:06:24 <salimma> oh one note on ELN Extras - the link to the result contains -- which gets mangled by antora
17:06:29 <sgallagh> OK, we're over time. I'm going to close out the meeting.
17:06:40 <dcavalca> thanks sgallagh
17:06:45 <salimma> I'll fix it when I'm on my x86, there's no aarch container and the previewer is suggesting I use npm, which... heck no
17:06:48 <dcavalca> salimma: file an issue so we don't forget?
17:06:50 <salimma> thanks Stephen Gallagher
17:07:05 <salimma> dcavalca: nah, I'll do a PR right after this :)
17:07:12 <dcavalca> even better :p
17:07:14 <salimma> it's on my todo note app
17:07:38 <sgallagh> #endmeeting