GNOME Bugzilla – Bug 451070
Broken CUPS SSL printing in gtk 2.10.13
Last modified: 2018-04-15 00:35:37 UTC
Please describe the problem: When using a cups printserver requiring SSL, the client does not properly upgrade the connection to SSL when requested by the server, and will continuously re-query, only to be rejected by the server for not using SSL. Steps to reproduce: Set your printserver in /etc/cups/client.conf to a cups print server requiring SSL. Actual results: No printers show up in dialog Expected results: Printers show up in dialog Does this happen every time? Yes Other information:
Created attachment 90640 [details] [review] Simpe fix This patch removes the #ifdef HAVE_SSL lines, and the mention of an unfinished TODO of enabling them from the configure script.
Created attachment 90778 [details] [review] Re-set state when encrypted connection required Another patch I need to connect properly and get a list of available printers.
hmm, seems the second patch has the #ifdef HAVE_SSL lines in context that the first one is removing ?
Whoops, those shouldn't be there.
Created attachment 90842 [details] [review] Working patch Latest patch which works better for me, but is still quite slow. It runs into the hard-coded 10 second waits in libcups quite frequently. It's also amazingly ugly, and there's got to be a better way to do it.
> It's also amazingly ugly, and there's got to be a better way to do it. Yeah, I don't think this is the way to go. If we want to do connection sharing like this, it should probably be done in the backend. I'd like to treat that separately from your first two patches which were only about making SSL work at all.
I've committed the first two changes now.
Created attachment 91328 [details] [review] (better) working patch This patch works perfectly for me. I wasn't sure if it was OK to use the gtk mutex API, should I switch to that? Any other changes I should add to make it acceptable for upstream?
Created attachment 91517 [details] [review] Even better patch This just cleans up the last patch a bit.
Created attachment 91562 [details] [review] Keep shared http connection on reconnect I haven't had this problem yet, but on code inspection, a failure on one http connection would kill other requests sharing the same connection.
Created attachment 91564 [details] [review] All patches in one, against gtk+ 2.0.13
Hi Vince? Is any of this still valid? Or is it working in newer GTK?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new