Hi folks!
Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote:
Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]].
Here is the full proposal again, with the new footnote included:
#####
=== Network requirements ===
Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking.
Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]].
==== VPN connections ====
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker.
#####
Any more thoughts, comments, adjustments etc? Thanks!
On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson adamwill@fedoraproject.org wrote:
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
I would add Wireguard too, plus a limitation that the criterion only applies if the desktop ships with support for these protocols.
Sounds good to me.
On Sat, 4 Jun 2022, 01:25 Michael Catanzaro, mcatanzaro@gnome.org wrote:
On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson adamwill@fedoraproject.org wrote:
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
I would add Wireguard too, plus a limitation that the criterion only applies if the desktop ships with support for these protocols.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Jun 4, 2022 at 1:36 AM Adam Williamson adamwill@fedoraproject.org wrote:
Any more thoughts, comments, adjustments etc? Thanks!
Which milestone is this supposed to block? It sounds fine (to my networking layman ears).
On Fri, Jun 03, 2022 at 04:35:41PM -0700, Adam Williamson wrote:
It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing.
I'd like to see clarification whether this is tested in IPv4-only, IPv6-only and dual stack environments. Ideally all 3 are tested but at least the environment should be specified.
Once upon a time, Ewoud Kohl van Wijngaarden ewoud+fedora@kohlvanwijngaarden.nl said:
On Fri, Jun 03, 2022 at 04:35:41PM -0700, Adam Williamson wrote:
It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing.
I'd like to see clarification whether this is tested in IPv4-only, IPv6-only and dual stack environments. Ideally all 3 are tested but at least the environment should be specified.
And, for IPv6, because of history, there are two dynamic-assignment systems (SLAAC and DHCPv6) that can be present alone or in combination. Ideally all 3 combinations (SLAAC, DHCPv6, SLAAC+DHCPv6) would be tested, but that's getting pretty specific.
I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications.
Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils.
Is that too much to ask?
On 04. 06. 22 1:35, Adam Williamson wrote:
Hi folks!
Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote:
Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]].
Here is the full proposal again, with the new footnote included:
#####
=== Network requirements ===
Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking.
Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]].
==== VPN connections ====
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker.
#####
Any more thoughts, comments, adjustments etc? Thanks!
On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote:
I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications.
Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils.
Is that too much to ask?
I would generally be hesitant to make anything that does not currently work a release criterion. That is effectively requesting development by the back door. It also seems to sort of go against reality - we are apparently fine shipping distributions where this doesn't work, because we've just done it, and there is not an outcry in the press or on social media (AFAICS) that this doesn't work. That tends to imply we don't need to block our releases on it.
Basically, if the implied request here is "make it so Fedora really cares whether dnssec works", I'd kinda suggest that should be a Change first. If it's accepted as a Change and gets implemented successfully, then we could maybe consider whether it's a sufficiently important feature to be release blocking. If we haven't even (as a project) decided it's a desirable feature and proved we can implement it (that's what the Change process is for), blocking the release on it seems rather premature...
Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started.
I will attempt to prepare a better working alternative for the next release or the one after it.
1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC 2. https://github.com/systemd/systemd/issues/4621
On 09. 06. 22 20:32, Adam Williamson wrote:
On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote:
I would propose also ability keep DNSSEC validation passthru. If infrastructure provides cryptographic records, they should be available also on the installed host. Without extra modifications.
Ie. if delv @$NS is validated for all network DNS servers, then delv should validate too. But that would rule out systemd-resolved in current configuration. delv is a command from bind-utils.
Is that too much to ask?
I would generally be hesitant to make anything that does not currently work a release criterion. That is effectively requesting development by the back door. It also seems to sort of go against reality - we are apparently fine shipping distributions where this doesn't work, because we've just done it, and there is not an outcry in the press or on social media (AFAICS) that this doesn't work. That tends to imply we don't need to block our releases on it.
Basically, if the implied request here is "make it so Fedora really cares whether dnssec works", I'd kinda suggest that should be a Change first. If it's accepted as a Change and gets implemented successfully, then we could maybe consider whether it's a sufficiently important feature to be release blocking. If we haven't even (as a project) decided it's a desirable feature and proved we can implement it (that's what the Change process is for), blocking the release on it seems rather premature...
On Sun, 2022-06-12 at 01:27 +0200, Petr Menšík wrote:
Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started.
I will attempt to prepare a better working alternative for the next release or the one after it.
Well, that's from quite some time ago. And you have an active thread about this on devel@ where systemd developers seem to be working with you to get your PRs merged.
On 6/11/22 19:27, Petr Menšík wrote:
Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started.
I will attempt to prepare a better working alternative for the next release or the one after it.
Is patching Fedora’s systemd-resolved an option?
Adam Williamson wrote:
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
Is "common" a rationale or a restriction? I.e., are all VPN types supported by OpenConnect automatically "common", or which ones are "common"?
(In particular, I care about ocserv.)
Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker.
So it is a case by case decision by the reviewer? Then why bother having written criteria at all?
Kevin Kofler
On Mon, 2022-06-13 at 03:09 +0200, Kevin Kofler via devel wrote:
Adam Williamson wrote:
Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations.
Is "common" a rationale or a restriction? I.e., are all VPN types supported by OpenConnect automatically "common", or which ones are "common"?
It's a restriction. I'm not sure we would actually want to block the release on absolutely every possible openconnect VPN configuration. I admit I'm not an expert on the details, which is why it's worded quite generally. If someone wants to try and write something more specific, that'd be great.
(In particular, I care about ocserv.)
DDG tells me that's an open source server intended to be compatible with openconnect clients, i.e. an open source alternative to the proprietary CISCO server. So in the case we had a bug that broke connections to ocserv servers but not connections to the official Cisco server, we'd have to try and figure out how widely ocserv is used, I guess.
Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker.
So it is a case by case decision by the reviewer? Then why bother having written criteria at all?
To at least clearly establish that bugs in this area *can* be blockers. Without this addition, on a strict reading of the criteria you have to be fairly creative to interpret them as allowing *any* kind of bug in VPN support to be release-blocking. And they really don't say anything specific about networking at all. In the past we've accepted complete networking fails as violations of things like the "browser must work" or "updates must work" criteria, but that feels quite a lot like a hack, and it's harder to keep a straight face when applying a hack like that to a bug which isn't as bad as "networking is completely busted for a lot of people".
As the guy who writes most of the criteria, what I'd really like to have is completely objective rules that remove the need for any kind of subjective evaluation. But experience suggests this is really hard to do without painting yourself into all sorts of weird corners. It's very hard (for me, anyway) to imagine every possible proposed blocker related to VPN or network functionality in general and, ahead of time, write rules that decide which ones are and are not blockers. But there's clearly a feeling that, in general, we should not be shipping Fedora with major bugs in VPN support. So, this is my best effort.
As I wrote above, if you or anyone else can draft some sufficiently detailed and comprehensive rules for this area which remove or reduce the need for subjective case-by-case evaluations, that'd be fantastic and I'd be all in favour. But this was as specific as I could get myself. It seems like in some areas we just have to go with this "criterion establishes broad principles / specific issues are evaluated case-by-case" approach.
Adam Williamson wrote:
DDG tells me that's an open source server intended to be compatible with openconnect clients, i.e. an open source alternative to the proprietary CISCO server.
It is also by far the easiest to set up Free Software VPN server.
It is configured through one configuration file, you do not have to manually set up TUN/TAP devices (ocserv does it for you even on the server side), you can easily use Let's Encrypt certificates and it does the right thing for them automatically (clients trust them if you leave the CA entry blank, while still distrusting invalid or self-signed certificates, the server does not trust Let's Encrypt certificates as client certificates – for authentication, you can either just use password authentication (sent over encrypted HTTPS) or set a different CA for the client certificates), etc.
And unlike "Open"VPN, it is also completely Free Software with no commercial proprietary version.
Kevin Kofler
On Fri, 2022-06-03 at 16:35 -0700, Adam Williamson wrote:
Hi folks!
Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote:
Hi once more folks. As overall response to the proposal has been positive and it doesn't seem to make sense to add dnssec requirements, I am going ahead and publishing this most recent draft into the Basic criteria today. We can move them later if Basic turns out to be too early.
Thanks everyone!
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Ahmed Almeleh -
Chris Adams -
Demi Marie Obenour -
Ewoud Kohl van Wijngaarden -
Kamil Paral -
Kevin Kofler -
Michael Catanzaro -
Petr Menšík