Bug 1332491

Seeing the same problem here on F24 Beta

$ rpm -qa|grep openconnect
openconnect-7.06-4.fc24.x86_64
NetworkManager-openconnect-1.2.2-1.fc24.x86_64

Going to blame NM itself for this. Will strip the stored username from my own config (it was there before I upgraded) and attempt to reproduce...

Note: NM-openconnect "makes up" secrets as it goes, to remember the authentication form entries (the 'input' ones, not the 'password' ones which end up being stored via libsecret.

So at the first *authentication*, because the server offers a form named 'main' which has a 'username' field, I end up with the auth-dialog spitting out an extra secret that was never previously known, which (in F23 and previously at least) resulted in:

# grep form: /etc/NetworkManager/system-connections/Intel\ AnyConnect\ VPN 
form:main:password-flags=1
form:main:username=david.woodhouse

The problem still exists in final Fedora 24.

Is there a workaround?

https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/openconnect-secrets-rh1332491

>> setting-vpn: get the flags property name only up to the first ":" in secret 

According to example from comment 3,

  form:main:password-flags=1
  form:main:username=david.woodhouse

it seems the secret name would be "form:main:username". Wouldn't the patch then lookup for "form-main-flags"? How does that fit with "form:main:password-flags"?
Surely the patch does it right, but the commit message does not explain the meaning of the ':'. It should show concrete examples of what openconnect does, and why we would truncate secret names at a colon.


It seems to me, that NMSettingVpn:get_secret_flags() should instead allow for a missing flags entry, but also consider whether there is an entry in the secrets.

Having a password in the @secrets hash, but no flags in @data, might anyway be considered in inconsistent state. I think, NMSettingVpn should treat "name" as secret if at least one of the following is true:

  - @secrets hash has an entry "name".
  - @data hash has an entry "name" + "-flags".

If the flags entry is missing, it should assume "0".


Above would make sense to me, regardless of any openconnect hacks. Wouldn't that fix the openconnect issue?

(In reply to Thomas Haller from comment #6)
> It seems to me, that NMSettingVpn:get_secret_flags() should instead allow
> for a missing flags entry, but also consider whether there is an entry in
> the secrets.

...

> Above would make sense to me, regardless of any openconnect hacks. Wouldn't
> that fix the openconnect issue?

As far as I was aware, that was how it always worked.

Ah, I had missed the fact that this was known to have been broken in https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1424f249e

An alternative suggestion... let us return *data* from the auth-dialog to be stored for future connections, not just secrets. I can set the flags explicitly then.

(In reply to Robert de Rooy from comment #1)

Seeing the same problem here with the released F24 (Workstation)

openconnect-7.06-4.fc24.x86_64
NetworkManager-openconnect-1.2.2-1.fc24.x86_64
NetworkManager-1.2.2-2.fc24.x86_64

This is what was merged to essentially restore the old behavior: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9b96bfaa722f3cccf0df3a3bca6e8f227643f94f

While extending the auth helper protocol certainly makes sense, it also takes more work to do and a change in the VPN client as well. We could do that in future, but for now this is probably sufficient.

Released in https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364 (1.2.4-2.fc24)

I faced the same problem on Fedora 24 Workstation

Name        : openconnect
Arch        : x86_64
Epoch       : 0
Version     : 7.07
Release     : 2.fc24

Name        : NetworkManager
Arch        : x86_64
Epoch       : 1
Version     : 1.2.4


Name        : NetworkManager-openconnect
Arch        : x86_64
Epoch       : 0
Version     : 1.2.2
Release     : 1.fc24

This still isn't working for me with NetworkManager-1.2.4-2.fc24

I provision a network with nmcli, and the 'save_passwords' secret is never set even though the auth-dialog returns it.

If I manually add save_passwords-flags=0 to the vpn.data when provisioning, it does get saved.

9b96bfaa722f3cccf0df3a3bca6e8f227643f94f was never backported to nm-1-2 branch, and is thus not in any libnm-1.2.* up to now.

I cherry-picked the patch upstream: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=bb45adeda0bf427ada23b09daf970b0757e82d60

NetworkManager-1.2.4-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9317b4b65b

Thanks a log David and Thomas, it works with NetworkManager-1.2.4-3.fc24 !

NetworkManager-1.2.4-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

According to https://bugs.launchpad.net/bugs/1609700 this bug has reoccurred in f30.

*** Bug 1705711 has been marked as a duplicate of this bug. ***

I wonder if this regression is caused by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=009f7560867e939 ?

Please test the Fedora 30 build with that commit reverted, at https://koji.fedoraproject.org/koji/taskinfo?taskID=36857342

That build seems not to fix it. I tried to build locally to bisect, but can't seem to get the local build to work at all. May have to leave this to the NM maintainers.

Just wanted to mention that this 'bug/issue' is also present in the current Fedora 31 beta with the following packages:

NetworkManager-openconnect-gnome-1.2.6-2.fc31.x86_64
NetworkManager-openconnect-1.2.6-2.fc31.x86_64
NetworkManager-1.20.4-1.fc31.x86_64

This is happening to me with F31 and some Anyconnect VPNs

NetworkManager-openconnect-gnome-1.2.6-2.fc31.x86_64
NetworkManager-openconnect-1.2.6-2.fc31.x86_64
NetworkManager-1.20.6-1.fc31.x86_64

My workaround:
nmcli con mod VPNNAME vpn.secrets 'form:main:group_list=GROUPNAME','form:main:username=USERNAME','save_passwords=yes'

This is happening to me with F30 with the latest updates as of date.

NetworkManager-openconnect-1.2.6-2.fc30.x86_64

I don't think it's helpful to reopen bugs that were closed for years.

The original issue was identified and confirmed to be fixed.

It's unlikely that the new symptoms have the same cause as the original one. But even so, it would require information to understand the new symptoms better. 

Let's discuss this on https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/328.

Now https://gitlab.gnome.org/GNOME/gnome-shell/issues/2105

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I can confirm that this issue still persists with Fedora 32. The symptoms are exactly the same as the previous one and this issue was never fixed for me. Everything mentioned in the original post holds.

$ rpm -qa|grep openconnect
openconnect-8.10-1.fc32.x86_64
NetworkManager-openconnect-1.2.6-3.fc32.x86_64
NetworkManager-openconnect-gnome-1.2.6-3.fc32.x86_64

This has been fixed in gnome-shell: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1535. The fix should be available in 3.38.3 which is planned to be released on January 9th.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.