Shrug. I never really knew much about Negotiate auth.
I have no memory of that 11-year-old discussion.
But certainly some things have changed in the last decade and the arguments we made then may no longer apply.
should update the docs for errors
here too
More context: https://bugzilla.gnome.org/show_bug.cgi?id=753260#c12
(That comment is slightly vague, but the problem was that we were computing peer-certificate-errors
based on trying to validate every property of every certificate that the server sent to us, even if the server sent us extra certificates that didn't form part of the validation chain. The fix I implemented was just "don't do that then".)
to ensure there aren’t any legitimate uses of those two properties.
There were supposed to be legitimate uses (eg, "I don't care about certificate expiration") but as Michael says, given the current semantics, there is no way to use them as anything other than booleans.
(So, release-note this well, and expect confused users on forums anyway)
So presumably most apps that are still using the old session subclasses after all this time are also still using the old non-GError
-based APIs, so the only information they're going to get is SOUP_STATUS_SSL_FAILED
, which they may or may not then present to the user in a useful way...
For projects that hit this regression the correct fixes might be:
- Use a cert signed by a common CA
- Install a custom CA that your cert used
- In libsoup set SoupSession*:tls-database to your private database
"Projects" don't hit any regression. The users do. You're mixing up "things the app developers can do", "things the users can do", and "things administrators who might not even know about the app can do (for their users who use the app)".
Hopefully, most users of affected apps will not notice this change at all.
For users who are broken by it, the possible fixes are:
For system administrators who provide a service whose users have been broken by this, the possible fixes are:
For developers of apps whose users have been broken by this, the possible fixes are:
ssl-use-system-ca-file
off again. (Note that this will probably eventually result in someone filing a CVE against your app.)GTlsDatabaseFile
and set it as SoupSession:tls-database
This isn't too different from ciphers being phased out
I'm not sure your mental model here is accurate. The kind of breakage I was talking about having wanted to avoid before is, eg, a Red Hat employee running Evolution on Fedora and using CardDAV to store their contacts on mail.corp.redhat.com, where switching from ssl-use-system-ca-file=false
to ssl-use-system-ca-file=true
would break them because mail.corp.redhat.com uses a certificate signed by the private RH CA, which does not appear in the Fedora system CA db, and cannot easily be added to it.
The problem is not that the server is insecure, and it can't easily be worked around by the sysadmins (who presumably have their reasons for using a private CA).
But again, those historical objections are less relevant now. Evolution was long ago ported to the new SoupSession
, so it's not affected by this change, and if it was, then I think there's some easy way to add your own CAs to the system CA db these days, so users could work around it. (And with the combination of LetsEncrypt and migration to cloud/hosted services, there are a lot fewer people using private CAs now anyway.)
The argument against changing the default, back in the day, was:
Each of these is less true than it used to be, I think. Additionally, "more important" apps are more likely to have been ported to the new SoupSession API a long time ago (hopefully?) so even if we do break people, we're just breaking their DAAP sharing, not their email.
And also, maybe we don't care at this point, and should just break people.
I did not find a discussion why to avoid compilation of the code which uses both libsoup-2.4 and libsoup3
GType does not have any sort of "symbol versioning", so libsoup-2.4 and libsoup3 can't each define their own GObject called SoupSession
. The only way you could make it work is if you renamed all the objects in libsoup3 (eg, make the prefix be Soup3
instead of Soup
. Or just rename the library itself and then rename everything in it to match.)
Yes, if nss-mdns4_minimal or nss-resolve is configured. If not, you don't want mDNS anyway. So I think this should be closed. @danw?
I don't remember if I had any specific use cases in mind when I originally filed this, but it seems like either way this issue is probably not doing anything useful any more.
@danw
Link to original bug (#660167)
GResolver ought to do mDNS. This probably means turning it into an extension point and using avahi from glib-networking.