6:35 p.m.
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!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:25 p.m.
On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson
<adamwill(a)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.
3:18 a.m.
Sounds good to me.
On Sat, 4 Jun 2022, 01:25 Michael Catanzaro, <mcatanzaro(a)gnome.org> wrote:
On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson
<adamwill(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
8:22 a.m.
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.
8:26 a.m.
Once upon a time, Ewoud Kohl van Wijngaarden <ewoud+fedora(a)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.
--
Chris Adams <linux(a)cmadams.net>
12:50 p.m.
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!
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
1:32 p.m.
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...
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
6:27 p.m.
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...
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
6:36 p.m.
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.
1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC
2. https://github.com/systemd/systemd/issues/4621
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:18 p.m.
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.
1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC
2. https://github.com/systemd/systemd/issues/4621
Is patching Fedora’s systemd-resolved an option?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
8:09 p.m.
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
2:16 p.m.
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
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
5:36 a.m.
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
5:06 p.m.
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!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
696
days inactive
741
days old
14 comments
9 participants
participants (9)
-
Adam Williamson -
Ahmed Almeleh -
Chris Adams -
Demi Marie Obenour -
Ewoud Kohl van Wijngaarden -
Kamil Paral -
Kevin Kofler -
Michael Catanzaro -
Petr Menšík