Yeah, its duplicated there because internally, the VPN connection objects provide the same D-Bus interface as the ActiveConnection objects.  I don't think dbus-glib can attach more than one object info to the same GObject; thus we can't attach *both* the processed data from nm-active-connection.xml and nm-vpn-connection.xml to NMVPNConnection objects internally using dbus_g_object_type_install_info().  Not entirely sure what to do here; I assume this is an issue in the NM D-Bus spec?

ugh, I guess I could have guessed it would be dbus-glib's fault :-P

this comes up because I wrote a dbus-introspection-to-javascript converter for gjs dbus bindings, and it spits out the active connection interface twice, which makes the javascript code throw at runtime.

I worked around it for now by just editing nm-vpn-connection.xml locally ... I could hack it in the dbus2js script, but it's a little tricky from the script to know which active connection xml is the good one and which is the extra one. (The extra one is missing PropertiesChanged and the state enum, so you have to use the one in nm-active-connection.xml to get working bindings.)

Anyway it sounds like we should move the bug to dbus-glib, I don't really have any ideas for how NetworkManager can fix this without a fix there.

Fixed, finally:

bc6fc7b910435aae00ef54db972a3e8359700d09 (master)
af4bcf3ee9dd40ac5b5b5dbe9160ffd821380e50 (0.8.x)