Fedora evicts WolfSSL

By Joe Brockmeier
September 16, 2024

The Fedora Engineering Steering Committee (FESCo) has voted to immediately remove the WolfSSL package from all of Fedora's repositories due to its maintainer failing to gain approval to package a new cryptography library for Fedora. WolfSSL's brief travels through Fedora's package system highlights gaps in documentation, as well as in the package‑review process. The good news is that this may stir Fedora to improve its documentation and revive a formal security team.

Fedora and cryptography

Fedora's packaging guidelines require that every application entering Fedora be checked for compliance with the policies on cryptography, but those policies could be written more clearly and are in need of an update. For example, the crypto policies say that new libraries "must comply with the crypto policies to enter Fedora" which seems oddly circular since the reader would likely think that is what they are reading. However, that is meant to be a reference to Fedora's crypto‑policies project, and that crypto libraries must have full integration with this system.

The crypto-policies project, maintained by Alexander Sosedkin, is an effort to unify the crypto policies for the whole distribution and also simplify the management of crypto applications and libraries. This means, in part, that Fedora has a limited set of approved crypto "back-ends" such as OpenSSL, GnuTLS, and Libreswan.

Fedora users can set system-wide crypto policies, such as a legacy policy when older encryption algorithms are needed for compatibility or the FIPS policy for conformance with FIPS 140 requirements. This system was adopted with the Fedora 21 release in 2014. The change proposal has a description of the system, and the crypto-policies man page describes the available policies and tools. A new crypto library would need to integrate with this system, but first it would have to be accepted in the first place.

Crypto libraries new to Fedora are required to get approval before being added, though the documentation does not do a great job of describing that process. Even though the packaging guidelines are a bit confusing, it should be clear enough that packagers need to consult with the Fedora security team, and then gain an exception from the Fedora packaging committee before being added to the repositories. There is one minor problem with this, though: the Fedora security team has been defunct for a while, and the policies have not been updated to reflect this.

WolfSSL

This posed difficulties for Andrew Bauer, who wanted to package WolfSSL, an SSL/TLS library written in C, as a dependency for another package he maintains, Netatalk. That software is an open-source implementation of the Apple Filing Protocol, which allows Linux (and other) systems to act as AppleShare file servers for new and old Apple systems. Really old, in fact—Netatalk version 2 supports systems as far back as the Apple II and version 3 supports Macs running Mac OS 7.5 (released in 1994) through today's Macs.

The Netatalk project had dropped OpenSSL in favor of WolfSSL with its 3.2.0 release in June because OpenSSL 3.0 had deprecated encryption algorithms that it needed to use for authentication with ancient Mac OS clients. This meant that Bauer could no longer rely on OpenSSL to fill the needs of the Netatalk package in Fedora, and needed to package WolfSSL. However, WolfSSL would need special approval to enter Fedora beyond simple package approval.

With Netatalk requiring WolfSSL, Bauer created a package and filed a review request on August 3. As part of the request, he included the rpmlint output that had flagged the package as non-compliant with Fedora's packaging policy. Bauer said:

Grepping the source code, one can see that wolfssl calls wolfSSL_CTX_set_cipher_list() rather than SSL_CTX_set_cipher_list(). Thus, this is a false positive and can be ignored.

And ignore it he did. So did Felix Wang, who reviewed the package and approved it on August 17. It might have helped if the error had been more explicit, or if it were listed among the common rpmlint issues in the package documentation. An issue was opened about the lack of description in 2023. The error is meant to alert the user that the application may not be using the system-wide crypto policy. FESCo member Fabio Valentini replied to the WolfSSL review‑request ticket to say that it would require further review and pointed to the crypto policies.

Security team snafu

So, Bauer sought help via the fedora‑devel list on August 18 to figure out how to contact the non-existent Fedora security team per the packaging guidelines. Neal Gompa responded that the "formal security team disbanded many years ago". He suggested that Bauer visit the Fedora security team room on Matrix, which Bauer did. (Note that link and several others require logging into a Matrix server. It is possible to log in without creating an account, click "Continue", select the Element client, and then click "Continue in your browser".)

He said that "a question was asked whether this package requires approval from Fedora Security". He got a quick suggestion from Demi Marie Obenour about compilation options that did not address the question of approval directly. He thanked Obenour, and seems to have left the channel before he received messages about Fedora's crypto policies or suggesting that new crypto libraries would require a change request. Bauer plunged ahead and updated the review ticket to report he'd been given advice on building WolfSSL, and was requesting a package repository now. The WolfSSL package entered the testing repositories for EPEL 9, Fedora 39, 40, 41 (which is still in development), and rawhide on August 20.

Valentini replied to Bauer's email on fedora-devel saying that the question of whether WolfSSL complies with system crypto libraries had not been answered. He was unhappy that it had already been imported into Fedora. Daniel P. Berrangé wrote that it seemed non-compliant and that a Fedora packaging committee (FPC) exception is required.

More than two weeks later, Valentini followed up in the review ticket and said it looked like Bauer had ignored his earlier comment about crypto compliance completely. The two went back and forth a bit. Bauer again complained the documentation was unclear and said: "Once we identify the source of authority, looks like that's Felix, I'll be glad to [work] through this."

Retirement

Instead of debating further with Bauer, Valentini opened a ticket with FESCo about the matter. He noted that "the reviewer of the package (not the submitter)" had filed a request with the packaging committee to approve the package, but it had already made its way into Fedora's stable repositories.

Stephen Gallagher said that he'd spoken with the crypto-policies maintainer and members of Red Hat's security team. Their opinion was that WolfSSL should not be permitted in Fedora without honoring crypto-policies. Gallagher proposed that FESCo vote on the following:

WolfSSL is immediately retired from Fedora. The maintainers may file a new package review request when WolfSSL respects the crypto system policy. This review request must be presented to the FPC, who must approve it before it is added back to the repositories.

On September 10, Valentini wrote that Gallagher's proposal had been discussed, voted on, and approved by FESCo. Five votes were in favor of the proposal, none against or abstaining.

Typically, packages are only retired from rawhide or branched versions of rawhide that are in the process of becoming the next stable Fedora release but have not entered final freeze. Retiring packages from stable versions of Fedora is a rare step, and usually only undertaken when a package has licensing problems. Once the package is retired, it is removed from subsequent composes and will be removed from the archives. It will not be removed from systems it was installed on unless it is also added to the fedora-obsolete-packages package. That has not been done in this case. As of this writing, the package is still installable, but it should be disappearing soon.

Aftermath

There are several points when Bauer clearly should have slowed down and gotten the message that he needed to consult Fedora's packaging committee. If nothing else, Valentini was waving a caution flag that Bauer should have heeded.

Still, he is not wrong that the documentation leaves much to be desired in terms of clarity and completeness. And, as Matthew Miller noted in the FESCo ticket, the security team is in a "disordered state" and it may be time to "reorganize and re-formalize the security team". Michel Lind commented that he had been sounding out frequent posters in the Matrix security room about improving things, so the project may be gathering steam to put a real team in place, once again, to avoid a recurrence of non-packagers giving random advice that is taken as official. It might also behoove Fedora to consider whether a chat room is a real substitute for an email list that does not emphasize real-time communication or require a special client to use.

Fedora's policies may also need some updating to take into account use cases that require special consideration for compatibility with obsolete hardware and software. It is a net good that Fedora users can use software like Netatalk to connect with classic computers, and it would be a shame if Fedora's policies blocked such software permanently. In the end, no real harm has been done, and Bauer's over-eagerness has helped the Fedora project identify a few real problems to address.

to post comments

Legacy crypto

Posted Sep 16, 2024 19:23 UTC (Mon) by geofft (subscriber, #59789) [Link] (14 responses)

I feel like I'm missing something basic here: OpenSSL deprecated, but did not remove, the algorithms in question, right? I understand the desire to not have e.g. 1DES available _by default_ in a way where someone might end up negotiating it for what they expected to be a modern SSL connection. But OpenSSL has a "legacy provider" - a loadable module that you can choose to use if you need it or choose to not even have installed if you want to be safe.

And the crypto-policies README also talks about legacy support.

Why isn't it sufficient for Fedora netatalk to use OpenSSL with an error message telling the user how to switch the system crypto policy to permit legacy libraries?

The Fedora package review request for wolfSSL mentions that upstream netatalk doesn't require it yet, but intends to require it in the future. Why is upstream doing this / why can't they indefinitely support OpenSSL with a non-default configuration?

Legacy crypto

Posted Sep 16, 2024 20:39 UTC (Mon) by jkingweb (subscriber, #113039) [Link] (9 responses)

> Why is upstream doing this / why can't they indefinitely support OpenSSL with a non-default configuration?

Or alternatively use OpenSSL with default configuration and fail when trying to talk with old peers? I can understand (and applaud) the desire to maintain backwards compatibility, but it seems a bit odd to me not to make a best effort with what is available on the system, especially if it can be foreseen to grow increasingly common a configuration in the future.

Legacy crypto

Posted Sep 16, 2024 21:10 UTC (Mon) by geofft (subscriber, #59789) [Link] (8 responses)

Well, I think I understand that - the whole point of netatalk is to communicate with old Apple systems that only support AFP, or somewhat-old Apple systems that happen to still be serving AFP instead of something else. Modern Apple systems (like the one I'm typing on) run a normal UNIX that speaks normal internet protocols and layers normal security protocols like TLS 1.3 on top. Apple themselves seems to have dropped AFP server support in 2020, so while client support is still around, you couldn't use AFP to connect two up-to-date Macs - you'd use SMB or SFTP or something. Those protocols are already well-supported on the Linux side and run up-to-date crypto. (And I don't think there's much of a good reason to run netatalk between two Linux machines.)

So the average netatalk user is trying to communicate with a machine running something like Mac OS 7.5, which is literally older than SSL and AES.

Legacy crypto

Posted Sep 16, 2024 23:27 UTC (Mon) by jkingweb (subscriber, #113039) [Link]

I see. That makes sense, then.

Legacy crypto

Posted Sep 17, 2024 3:49 UTC (Tue) by lambda (subscriber, #40735) [Link]

Up until about 2018 or 2019 or so, AFP was still faster than SMB on macOS; I worked on high performance NAS systems for video editing, and if possible we would recommend that customers use AFP rather than SMB when on macOS.

Eventually, Apple brought their SMB client up to date and SMB became competitive, but in the pro video world, customers would very frequently stick with the same hardware/software combo for years as once you have a working workflow changing it was always disruptive, so even today there could be value in running Netatalk talking to only 5-10 year old machines.

Legacy crypto

Posted Sep 17, 2024 6:01 UTC (Tue) by epa (subscriber, #39769) [Link] (5 responses)

Perhaps truly ancient protocols need to stop being considered "crypto". It is just some odd transformation of the data that makes no claim to being crytographically secure, but is required to talk to some museum-piece systems. If you cared about security you wouldn't use a classic Macintosh, not on the network anyway. It doesn't serve any purpose to apply the same bureaucracy to enforce key length, allowed ciphers and public key infrastructure. After all there is no central authority stopping you from using the original NFS or other protocols that have no encryption at all.

I once patched openssh to add a "none" cipher where the data was sent unencrypted. That let it run with reasonable performance on a 386SX at 16MHz. (I didn't want to run the ancient rsh instead because the ssh code is higher quality in other ways, not just crypto.) Obviously, completely insecure over the public Internet, but a necessary expedient for connecting over a trusted local network to a machine that, even back then, was of hobbyist interest only.

Legacy crypto

Posted Sep 17, 2024 15:52 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (4 responses)

The obvious alternative is end users manually disabling the system policies in order to make netatalk work, and thereby reducing the security of the system as a whole. Users care about security right up until it causes problems for their use case, and then it goes out the window.

So yes, this probably should be exempt, but I'm not sure how you get there from here given what the article describes.

Legacy crypto

Posted Sep 17, 2024 19:44 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

Another possibility would be something like a Flatpack that lets you distributed the whole thing, with all its specialized dependencies, as a unit. It seems like an increasingly common approach for programs that want to use deprecated dependencies, like anything that still depends on Python 2.

Legacy crypto

Posted Sep 19, 2024 3:47 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

My point is not that there's no good solution. My point is that end users do not look for the best solution. They look for the first solution. "Disable the system policy" is (presumably) one command or config file away. "Compile a flatpak" is not. So they're going to disable the system policy and move on with their lives. The only way to avoid this outcome is to make the whole thing work out of the box, exactly as packaged, with no additional fiddling whatsoever.

Legacy crypto

Posted Sep 19, 2024 5:19 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

(And yes, I get that "make it work out of the box" is the whole point of Flatpaks. I'm talking about whatever the user gets from dnf, not some third-party Flatpak that they may or may not be willing to go find.)

Legacy crypto

Posted Oct 7, 2024 9:47 UTC (Mon) by ssokolow (guest, #94568) [Link]

As a matter of fact, they already do have something in that vein:

https://hub.docker.com/r/netatalk/netatalk
https://hub.docker.com/r/netatalk/netatalk2

Flatpak isn't really intended for network services.

Legacy crypto

Posted Sep 17, 2024 11:59 UTC (Tue) by neverpanic (subscriber, #99747) [Link]

netatalk could create a new OSSL_LIB_CTX using OSSL_LIB_CTX_new, load the legacy provider using OSSL_PROVIDER_load(libctx, "legacy") and use 1DES from there. This would also mean they wouldn't be affected by crypto-policies not actually allowing 1DES (AFAIK, haven't tested this — this is a comment, not a knowledge base article).

Why they chose to go for wolfSSL instead, I don't know. I feels excessive to me to have yet another crypto library in Fedora for a protocol people should really stop using, or are maybe using for some hardware and network protocol archeology.

Legacy crypto

Posted Sep 17, 2024 20:03 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

> The Fedora package review request for wolfSSL mentions that upstream netatalk doesn't require it yet, but intends to require it in the future. Why is upstream doing this / why can't they indefinitely support OpenSSL with a non-default configuration?

Is it not assuming that openSSL itself will indefinitely support the "legacy provider" ?

Legacy crypto

Posted Sep 18, 2024 7:44 UTC (Wed) by neverpanic (subscriber, #99747) [Link]

> Is it not assuming that openSSL itself will indefinitely support the "legacy provider" ?

How is that any different from assuming that wolfSSL will indefinitely support single-DES?

Getting 1DES on current crypto libs: GnuTLS

Posted Sep 18, 2024 9:55 UTC (Wed) by abartlet (subscriber, #3928) [Link]

Just a note that Samba needs single DES for NTLMv1 and other places, and uses the DES CBC mode to uncover a single DES implementation by using an all-zero IV.

We do this with GnuTLS to link against a supported crypto lib (and so no longer ship DES in Samba).

A matter of perspective on clients

Posted Sep 17, 2024 4:56 UTC (Tue) by lunaryorn (subscriber, #111088) [Link] (10 responses)

It might also behoove Fedora to consider whether a chat room is a real substitute for an email list that does not [...] require a special client to use.

I find this a bit odd. Email, and particularly a mailing list, also requires a "special client", doesn't it?

A matter of perspective on clients

Posted Sep 17, 2024 6:03 UTC (Tue) by sagi (subscriber, #64671) [Link]

I had exactly the same thought. I wonder if the comment was inspired by some other property that a matrix room was felt to be lacking?

A matter of perspective on clients

Posted Sep 17, 2024 7:03 UTC (Tue) by willy (subscriber, #9762) [Link] (3 responses)

You've never telnetted to port 25 and said HELO? Admittedly I've never said EHLO ...

A matter of perspective on clients

Posted Sep 17, 2024 9:18 UTC (Tue) by lunaryorn (subscriber, #111088) [Link] (2 responses)

If you do your mailing list mails like this, have my utmost respect ;)

A matter of perspective on clients

Posted Sep 17, 2024 12:23 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (1 responses)

A very long time ago (1996-1997) I used to connect to the net using a 2400 bps modem. I can assure you that by then that was the way to read mailing lists efficiently. You'd log into the POP server, list messages, retrieve the 10 first lines of the ones that appeared interesting, retrieve the interesting ones completely and delete them:

$ telnet pop.$domain.$tld 110
USER foo
PASS bar
LIST
TOP 12
TOP 15
RETR 15
DELE 15
etc.

I could spend 15 minutes with the modem connected retrieving a few tens of messages, then consult them offline calmly. For those who never experienced 2400 bps, you definitely see characters draw from left to right on each line (2.5s per line). I'm pretty sure there was something to delete a range but I don't remember the commands, it was almost 30 years ago... Fun times, to some extents, but that I don't miss :-)

A matter of perspective on clients

Posted Sep 17, 2024 15:21 UTC (Tue) by jak90 (subscriber, #123821) [Link]

I sure did that quite a lot up into the 56K era, but more out of curiosity (the lack of spam filters in mail hosters and primitive mail clients such as MS Outlook Express had opened up a market for mail checkers that scanned your mailbox and threw out any obvious spam before you launched your "real" mail client) than for any practical use. At the very least it was definitely worth automating the download of mail headers rather than typing in everything.

A matter of perspective on clients

Posted Sep 17, 2024 12:21 UTC (Tue) by aragilar (subscriber, #122569) [Link] (2 responses)

I would presume this refers to for a mailing list you could serve out an archive over HTTP (and due to the structure of email a page per email is easy to archive/search/etc.), or simply scrape exported mbox files, whereas matrix as far as I know has no equivalent tooling (even irc has loggers and can produce an archive)? This means next time someone wants to introduce a new TLS library (of which I can think of at least one which will cause flamewars if it gets brought up...), the process will remain only discoverable by searching the right matrix room (assuming that its existence is known), and so there will be another LWN article lamenting this same issue.

I'm vaguely aware zulip (which is another one of the new chat systems) has a "web archive" feature, it's possible that this feature would solve the issue around discovery and searchability, and maybe something similar should be created for matrix to solve this?

A matter of perspective on clients

Posted Sep 17, 2024 13:40 UTC (Tue) by jzb (editor, #7867) [Link] (1 responses)

More or less. I was a bit less precise than I suppose I could've been. The move to Matrix means that users have to deal with Yet Another System whereas most folks already have an email address and as aragilar suggests, email lists are archived in a way that users can go back and refer to previous discussions and are asynchronous.

A matter of perspective on clients

Posted Sep 17, 2024 20:04 UTC (Tue) by mattdm (subscriber, #18) [Link]

Yeah. People really do like real-time conversations. We do have Discourse at https://discussion.fedoraproject.org, which is a much better place for big discussions and decisions.

A matter of perspective on clients

Posted Sep 18, 2024 9:06 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

With email you have your choice of client and your choice of user interface, and you can also handle it programmatically if you choose. A web forum forces one particular user interface, which is usually hard to automate without fragile “scraping”.

A matter of perspective on clients

Posted Sep 18, 2024 9:10 UTC (Wed) by intelfx (subscriber, #130118) [Link]

> A web forum forces one particular user interface, which is usually hard to automate without fragile “scraping”.

That's certainly not true for Matrix though. And I think Discourse also has an assortment of APIs if I'm not mistaken (as well as actual email integration).

A bit heavy-handed, maybe?

Posted Sep 17, 2024 7:50 UTC (Tue) by smurf (subscriber, #17840) [Link] (5 responses)

So there was a communications snafu and an over-eager maintainer, and a package that's required for some other package.

… and FESCo has no better idea than to kick the package out, despite their own role in the matter and a requirement that appears to be rather difficult to fulfill given the "non-existent Fedora security team"? Seems like that could have been handled a whole lot better.

Given a choice between situations like this on one hand and Debian's endless discussions on the other, I think I'd prefer the latter. :-P

A bit heavy-handed, maybe?

Posted Sep 17, 2024 11:20 UTC (Tue) by hkario (subscriber, #94864) [Link] (4 responses)

What's needed is to update WolfSSL package (and likely crypto-policies package) to take the system policy into account when it's running. Neither part really needs a "functional security team" to happen.

A bit heavy-handed, maybe?

Posted Sep 17, 2024 12:47 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (1 responses)

And then the system crypto policy will promptly blacklist the ancient cyphers supported by AFP. Which is the point of system crypto policies, crack down on components that use insecure cyphers via obscure local configurations.

Not sure a lot of people would accept a security downgrade just to accommodate AFP.

A bit heavy-handed, maybe?

Posted Sep 17, 2024 16:23 UTC (Tue) by smurf (subscriber, #17840) [Link]

Umm, what security downgrade? No other component would link to WolfSSL in the first place, and AFP doesn't support anything that's deemed "secure enough" by today's standards in the first place.

A bit heavy-handed, maybe?

Posted Sep 17, 2024 13:01 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> What's needed is to update WolfSSL package (and likely crypto-policies package) to take the system policy into account when it's running. Neither part really needs a "functional security team" to happen.

...Or just do what all the cool kids are doing these days and just vendor all of WolfSSL or libtomcrypt (or whatever minimal "legacy" subset is needed) into Netatalk...

A bit heavy-handed, maybe?

Posted Oct 7, 2024 9:53 UTC (Mon) by ssokolow (guest, #94568) [Link]

I remember hearing that it's vendored and it's not on the list of dependencies in their INSTALL.md.

I'm assuming this is the usual "distros un-vendor vendored dependencies when packaging things" situation.

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 17, 2024 12:08 UTC (Tue) by neverpanic (subscriber, #99747) [Link] (5 responses)

I fixed the link to Fedora's defunct security team and replaced it with a link to the mailing list for the Fedora crypto team (which is essentially equivalent to RHEL's crypto team), so that part should be fixed now.

The other reason why introducing new cryptography into Fedora isn't trivial is that Red Hat's lawyers like to keep an eye on the cryptography that's shipped, for various reasons I'm not going to discuss in detail.

If you look around the packages already in Fedora, you'll notice that none of them provide elliptic curves over binary fields, and until recently didn't ship Brainpool curves, either. See also https://fedoraproject.org/wiki/Legal:ECC. The review by the security^Wcrypto team is also in place to make sure that this happens. I haven't checked wolfSSL, but I'd expect it to contain code for binary fields, which would make it problematic for Fedora.

I don't think this effort is warranted for a single package implementing an outdated protocol that could with some additional effort use OpenSSL instead.

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 17, 2024 14:27 UTC (Tue) by intelfx (subscriber, #130118) [Link] (4 responses)

> you'll notice that none of them provide elliptic curves over binary fields, and until recently didn't ship Brainpool curves, either

What's wrong with elliptic curves over binary fields or Brainpool curves?

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 17, 2024 14:36 UTC (Tue) by neverpanic (subscriber, #99747) [Link] (2 responses)

> What's wrong with elliptic curves over binary fields or Brainpool curves?

It was obvious somebody was going to ask the question, but for legal reasons, I'm not going to discuss it.
Lawyers, always fun to work with, right?

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 18, 2024 9:12 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

Why even say something in a public forum if you know beforehand that you are going to categorically deny without explanation any further discussion of it? Perhaps it's just me, but it feels not exactly polite to do so.

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 19, 2024 7:03 UTC (Thu) by gasche (subscriber, #74946) [Link]

It feels reasonable to me to give some information, and then politely decline to discuss the details. It's better than not giving the information in the first place, and I felt it was done gracefully. Knowing which crypto protocols should be avoided in Fedora packages could be very helpful to prospective packagers, even if there is no clear justification besides "lawyers".

Link was fixed, but crypto-policies compliance isn't the only thing to consider

Posted Sep 17, 2024 14:51 UTC (Tue) by ballombe (subscriber, #9523) [Link]

Outside the fact that they are a patent minefield, elliptic curves over binary fields are a bad idea security-wise anyway.

crypto-policies are for defaults

Posted Sep 17, 2024 20:05 UTC (Tue) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

> Fedora's policies may also need some updating to take into account use cases that require special consideration for compatibility with obsolete hardware and software. It is a net good that Fedora users can use software like Netatalk to connect with classic computers, and it would be a shame if Fedora's policies blocked such software permanently.

The intent of crypto-policies is to set *defaults* that applications must follow unless (a) user configures otherwise, or (b) the application has a domain-specific reason for deviating from the defaults. (My rule (b) applies in practice, but I don't see it actually documented at https://docs.fedoraproject.org/en-US/packaging-guidelines... so it might be a rule I just made up, but to do otherwise would not be pragmatic.)

OK: Application uses system crypto policy as a starting point, but changes a few things

Not OK: WolfSSL totally ignores system crypto policy (this is the status quo)

crypto-policies could easily be an upstream project since it would be useful on all Linux distros, but unfortunately it is effectively Fedora-specific, so upstream projects generally don't care and downstream patching is going to be required. If it was treated more like an upstream software project and adopted by more Linux operating systems, hopefully crypto library upstreams would take it more seriously.

crypto-policies are for defaults

Posted Sep 18, 2024 0:13 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

Crypto-policies (the project) is used by both Fedora and openSUSE. It is not currently being used by Ubuntu (the other distribution that needs to handle crypto policies).

crypto-policies are for defaults

Posted Sep 18, 2024 7:47 UTC (Wed) by neverpanic (subscriber, #99747) [Link] (1 responses)

In fact, Canonical has recently started building its own thing to solve the same problem.
Why do they not just use crypto-policies? I have no idea.

crypto-policies are for defaults

Posted Sep 18, 2024 8:11 UTC (Wed) by smurf (subscriber, #17840) [Link]

Yet another case of NIH syndrome? not the first time Canonical gets inflicted by that particular malady.

Import?

Posted Sep 24, 2024 8:54 UTC (Tue) by jsakkine (subscriber, #80603) [Link] (2 responses)

Why not just plain import those ciphers to netatalk codebase and call it a day?

Import?

Posted Oct 7, 2024 9:55 UTC (Mon) by ssokolow (guest, #94568) [Link] (1 responses)

Judging by the absense of WolfSSL in the list of external dependencies in their INSTALL.md, that's what they tried to do.

Import?

Posted Oct 7, 2024 10:41 UTC (Mon) by knewt (subscriber, #32124) [Link]

Looking through the release notes it was indeed bundled, yes. I say "was", because funnily enough as of the 4.0.0 release just last week:

> Dependency Changes
>
> Libgcrypt
>
> Netatalk now requires only Libgcrypt for all user authentication. Dependencies on OpenSSL, LibreSSL, and wolfSSL have been completely removed.

Mind you, worth noting that.....
> This release constitutes major changes over Netatalk 3.2, and is recommended for early adopters. We strongly suggest that you take a backup of your production environment before attempting to upgrade an existing Netatalk deployment to 4.0.0.