- From: Stefan Winter <stefan.winter AT restena.lu>
- To: "cat-users AT lists.geant.org" <cat-users AT lists.geant.org>, cat-announce AT lists.geant.org
- Subject: Re: [[cat-announce]] CAT 2.0.4 released and to be deployed on cat.eduroam.org tomorrow
- Date: Thu, 25 Feb 2021 08:28:28 +0100
Good morning!
After belatedly (list issues...) seeing
the thread triggered by the mention of geteduroam, I would like to
provide some background on that app, our choices, etc.
First of all, the only thing that is
going to change with our deployment is the advice which app to
download from Play Store. That's a sentence of prose in the
product configuration, not a code change. This means we could
easily not do the change and continue pointing to the eduroamCAT
app as usual, if we think that that is the better idea.
I do not think that that is the better
idea.
First, some background.
Android has undergone a rather drastic
change of its Wi-Fi configuration APIs. The eduroamCAT app has
only ever supported what is now the old-style, deprecated
WifiEnterprise API. That API became fully usable from Android 4.3
(hence the minimum OS required to run the app is just that) until
Android 9. On Android 10, it exists, but is deprecated. With
Android 11, it's gone. I have had to deal with support questions
of the eduroamCAT app on multiple devices with Android 10 where it
already didn't work properly.
I understand the confusion around
geteduroam, as the term is used for two largely independent
things. The part we care about here is "geteduroam the Android
app". It is a full-featured replacement for all things eduroamCAT
has been doing, with a nice UI, and with awareness of the API
changes. Yes, it supports all EAP types. No, you do not have to
abandon CAT or change anything in the configuration. It is simply
a drop-in replacement for the old app. It supports only Android
versions from 8 upwards, including 11 and future versions.
("geteduroam" is also the term used for
a system that provisions EAP-TLS based 'pseudo-credentials' to
users logging into a portal with their SAML/OIDC credentials, with
the aim that eduroam logins are decoupled from SSO
usernames/passwords. When using that system it also uses the same
geteduroam app to configure /those/ credentials, but that does not
mean the app requires this pseudo-credentialing in any way; nor
that app support is limited to EAP-TLS. This conflict in naming is
unfortunate and I'm very sorry if that led to confusion over the
purpose or workflow of the app. In fact, during the design of the
geteduroam app it was given substantial attention to the
requirement that it integrates and supports "normal" CAT and
password-based EAP types just as well as the "special"
credentials; it also uses the CAT APIs for institution and profile
listing, etc.)
Now, what to do.
The history of API levels and app
support above alludes to why the download button consolidation for
Android Tomasz wrote about yielded three distinct buttons:
- Android <8 - only eduroamCAT
supports these API levels. The only support option is to suggest
users to install the eduroamCAT app. That is what the button does
(and its per-version predecessor buttons did)
- Android 11 - only geteduroam supports
these API levels. The only support option is to suggest users to
install the geteduroam app. That is what the new Android 11+
button does, and there are no alternatives.
- Android 8 to 10 - this is the only
space where there is leeway of decision. We can point to any of
the two apps, and both should work. Since I know cases where
Android 10 with eduroamCAT does not work (and all of those
resolved successfully when suggesting the use of geteduroam
instead), I believe pointing to geteduroam is the better choice.
I use geteduroam myself since earlier
days and don't see drastic problems with it that (in my personal
opinion) warrant sticking to eduroamCAT for Android 8-10. If
people think we should anyway, then it is certainly a possibility.
But when thinking about this, keep in mind that geteduroam is not
a question of "yes" or "no". The options are "now" or "soon" - it
will gain momentum all by itself as Android versions advance, and
the old app experiences more breakages over time with OS updates
that potentially treat the old APIs as a step child.
Greetings,
Stefan Winter
Am 24.02.21 um 16:56 schrieb Stefan
Winter:
Hello!
It's been little while since our last update of eduroam CAT. A
number of small bug fixes accumulated over time, and there are a
few "mini" features that deserve cutting a release 2.0.4.
The notable features are:
- [FEATURE #1] The system now sends out notification/alert
mails if a significantly security relevant parameter was
changed. The mails go to the NRO admin. Significant changes
are:
- change of institution name
- addition of a new root CA (with more prominent WARNING if
the new CA has the same DN as an existing one)
- addition of a new acceptable server name
- [FEATURE #2] support negotiation of TLS versions higher than
1.0 while still rejecting SSL2 and SSL3
- [FEATURE #3] realm reachability checks now produce a WARNING
level message if the EAP server does not support TLS1.2 or
higher
- [FEATURE #4] check whether SRV-discovered hostname and
certificate hostname match
Also, we are happy to add a new translated language: welcome, Română (Romanian).
You can find the tarball on GitHub as usual ( https://github.com/GEANT/CAT/releases/download/v2.0.4/CAT-2.0.4.tar.bz2
) but for most of you the most interesting question is probably
when the new code will be deployed on https://cat.eduroam.org.
We have reserved a maintenance slot for that tomorrow, 1300
CET. The expected downtime is in the seconds range, so you would
be particularly unlucky to notice at all.
As usual, if you notice new buggy behaviour of any sorts after
the update, please let us know.
Greetings,
Stefan Winter
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
Archive powered by MHonArc 2.6.19.