'uri-security-supported' hardcoded to 'none'

[lbschenkel]

This is a resubmission of apple/cups#5779, since https://github.com/apple/cups seems to be abandoned at the moment.

---

I use the Mopria print service for printing to CUPS from an Android device. This works perfectly on CUPS 2.2.10 (Debian buster). When I upgrade to CUPS 2.3.1 (Debian bullseye), the app can no longer print.

I managed to get in touch with the development team at HP. I provided wireshark traces for both versions. It ended up being narrowed down to the following:

The wireshark-cups-2.3.1 trace shows a printer response to Get-Printer-Attributes which includes:

       printer-uri-supported (uri): 'ipps://CUPS:631/printers/PRINTER'
           name: printer-uri-supported
           uri value: 'ipps://CUPS:631/printers/PRINTER'
       uri-authentication-supported (keyword): 'requesting-user-name'
           name: uri-authentication-supported
           keyword value: 'requesting-user-name'
       uri-security-supported (keyword): 'none'
           name: uri-security-supported
           keyword value: 'none'

But https://tools.ietf.org/html/rfc8011#section-5.4.3 indicates that if TLS is supported for the corresponding uri, the printer must return a 'uri-security-supported' keyword of 'tls'.

Of course, MPS should not send an empty printer-uri. But it seems to have been confused
by the earlier response which is out of spec.

Conclusion: uri-security-supported seems to be harcoded to none, which violates RFC 8011, section 5.4.3 when printer-uri-supported is a ipps:// URL. I searched a bit but I wasn't able to find any conversation explaining the reason for why this attribute is hardcoded in this way. The commit is from 15 years ago.

Another interesting difference is that in CUPS 2.2.20, the response to Get-Printer-Attributes was a printer-uri-supported value containing an ipp:// URL, even though the client was using IPPS:

Frame 79: 675 bytes on wire (5400 bits), 675 bytes captured (5400 bits) on interface 0
Ethernet II, REDACTED
Internet Protocol Version 4, Src: APP, Dst: CUPS
Transmission Control Protocol, Src Port: 37209, Dst Port: 631, Seq: 2407, Ack: 1183, Len: 609
Secure Sockets Layer
Hypertext Transfer Protocol
Internet Printing Protocol
    version: 2.0
    operation-id: Get-Printer-Attributes (0x000b)
    request-id: 144
    operation-attributes-tag
        printer-uri (uri): 'ipps://CUPS:631/printers/PRINTER'
            name: printer-uri
            uri value: 'ipps://CUPS:631/printers/PRINTER'

Frame 86: 5549 bytes on wire (44392 bits), 5549 bytes captured (44392 bits) on interface 0
Ethernet II, REDACTED
Internet Protocol Version 4, Src: CUPS, Dst: APP
Transmission Control Protocol, Src Port: 631, Dst Port: 37209, Seq: 8044, Ack: 3016, Len: 5483
Secure Sockets Layer
Hypertext Transfer Protocol
Internet Printing Protocol
    [Request In: 79]
    [Response Time: 0.003729117 seconds]
    version: 2.0
    status-code: Successful (successful-ok)
    request-id: 144
    operation-attributes-tag
    printer-attributes-tag
        printer-uri-supported (uri): 'ipp://CUPS:631/printers/PRINTER'
            name: printer-uri-supported
            uri value: 'ipp://CUPS:631/printers/PRINTER'

While on CUPS 2.3.1, the response is:

Frame 117: 675 bytes on wire (5400 bits), 675 bytes captured (5400 bits) on interface 0
Ethernet II, REDACTED
Internet Protocol Version 4, Src: APP, Dst: CUPS
Transmission Control Protocol, Src Port: 49170, Dst Port: 631, Seq: 2407, Ack: 1183, Len: 609
Secure Sockets Layer
Hypertext Transfer Protocol
Internet Printing Protocol
    version: 2.0
    operation-id: Get-Printer-Attributes (0x000b)
    request-id: 78
    operation-attributes-tag
        printer-uri (uri): 'ipps://CUPS:631/printers/PRINTER'
            name: printer-uri
            uri value: 'ipps://CUPS:631/printers/PRINTER'

Since I can't change uri-security-supported without recompiling CUPS, I also tried disabling TLS to force the use of a ipp:// URL but that didn't work: TLS is still enabled. This seems to be the same issue reported in apple/cups#5769.

[michaelrsweet]

This looks like an oversight - printer-uri-supported is now generated dynamically based on the Host: header, but uri-security-supported was not.

[master 26e085b] Fix the "uri-security-supported" value to be based on the current connection (Issue #42)