On 3/11/19 10:52 PM, Chris Murphy wrote: > On Thu, Feb 28, 2019 at 2:56 PM Stephen Gallagher <sgall...@redhat.com> wrote: > >> * Printing must work on at least one printer available to Fedora QA. >> "Work" is defined as the output from the device matching a preview >> shown on the GNOME print preview display. (Note that non-ridiculous >> differences in color reproduction are not considered "non-working". In >> general, we'll apply the "last blocker at Go/No-Go" principle here >> when deciding whether a print glitch is truly blocking.) >> >> and this to Final for Fedora 30+: >> * Printing must work (as defined above) on at least one printer using >> each of the following drivers: >> - The built-in print-to-PDF driver >> - The generic IPP driver >> * For each blocking desktop, it must be possible to print: >> - A test page from the desktop environment's built-in "test page" >> feature, if such a feature exists. >> - A simple text document of at least 100 words (lorem ipsum) from >> the standard basic text editor accompanying that desktop. >> >> This does not mean that all printers need to function properly that >> use the IPP driver, just that at least one does (so we >> know that printing as a whole is unbroken). We won't specify any >> particular hardware makes or models that must work. > I think "generic IPP driver" needs to be more specifically stated. > > There's IPP protocol versions 1.1, 2.0, 2.1 and 2.2. The "driverless" > specification is IPP Everywhere, which uses IPP protocol versions 2.0 > or higher, along with additional requirements to support driverless > device discovery and printing of text and images. There isn't strictly > speaking a generic IPP driver, although PCL and PostScript are common. IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled printer, since 'generic IPP driver' does not exist. > > What supports IPP Everywhere out of the box? > > Any computer running CUPS 1.5 or later I beg to differ that it is not entirely correct. Yes, there are some features for driverless support in <2.1.0 (approximately), but since it was not so widely used at that time, some features were still missing or needed some more tweaks for make it right. > Mobile devices running Android 4.4 and later > > Proposal for Fedora 30: If anyone is able to, with reasonable effort, > successfully run the agreed test cases to any printer supporting IPP > 2.0 or higher, using whatever driver is required, then we don't block.
I would go with 'if printing works on IPP everywhere printer available for Fedora QA' (hooray, we have one :) ) 'then do not block'. But it seems as technicality... IMHO blocking the release if 'whatever' IPP everywhere printer does not work seems like a trap to me - you basically believe that every printer vendor implemented their IPP server and used HTTP server (IPP is transfered by HTTP protocol) into printers firmware correctly - which is not true till now. > Proposal for Fedora 31: If anyone is able to, with reasonable effort, > successfully run the agreed test cases to any IPP Everywhere printer, > then we don't block. > > Something I need to dig into deeper is how to create a virtual IPP > Everywhere printer (a service); which would be useful for testing, in > particular automated testing such that the virtual printer itself says > "yes this is a valid print job". ippsample project does that, you can find it in that github link you posted, together with sample of ippserver, which should become 'server solution' for CUPS (the idea is to use CUPS only as client app, and any infrastructure servers will run only IPP server, which will present printers to other machines). > But also it might be possible to > bridge the virtual IPP Everywhere printer with a conventional > CUPS+gimp/foomatic driver based printer. This idea is similar to which Mike Sweet presented on PWG meetup last year - printer applications - combination of IPP server(not CUPS)+specific printer driver provider. I created a report from that PWG meetup, please see that. I plan to add all these projects into Fedora to have fully IPP everywhere solution (ippusbx, ipp-selfcert, ippsample), but not so much time to do it yet... > If so, I'm thinking Fedora > IoT on a Raspberry Pi Zero W, using a static containerized approach, > that once working, should be a reliable indicator that any failures > coinciding with print pipeline changes in the client, are in fact > client bugs. But we'll see about that. > > This might be useful: > IPP Everywhere mini-tutorial > https://github.com/apple/cups/wiki/IPP-(Everywhere)-Mini-Tutorial > > Other references: > IPP Everywhere FAQ: > https://www.pwg.org/ipp/evefaq.html > > IPP Everywhere self-certified printers list: > https://www.pwg.org/dynamo/eveprinters.php > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C
PWG plenary =========== - more meet-ups in aug, november - pwg membership - redhat doesn't have - PWG group - chair Smith Kennedy, vice chair Alan Sukert - ipp everywhere self certification tool - for checking if printer is compatible 206 printers certififed! mostly HP - PWG on github - ippsample - reference implement of ipp infrastructure, ippeveselfcert e.g Image Device Security group --------------------------- - now focusing on common criteria and standards for security on printing and scanning devices IPP group ---------- - maintain IPP, support new clients, net archs (cloud), - 3D - extensions 1.1, safe g-code subset - IPP everywhere 1.1 - IPP system service - meetings in IPP mailing list (pwg.org/mailman/listinfo/ipp) Liaison groups status ------------------------ - trusted computing group - trusted mobility solutions (telcom, mobiles), mobile platform (mobiles, PDA, eBOOk readers) - recent specs : TCG docs, www.trustedcomputinggroup.org/resources - internet engineering task force - IETF - came out with RFC - new version of TLS - 1.3, security automation and continuous monitoring, concise binary object representation (CBOR), Constrained RESTful Env (CORE), Crypto forum research group (CFRG) - future algorithms - mopria - scanning tool for Android - possible cooperation with ISO and IEEE about standardization of 3D printing 3D printing =========== - status - no products right now - defined safe subset of G-code (code for CNC machines) to use with IPP - linear moves, (move the tool and extrude material for printing), dwell (pause), set position, move to origin, set absolute position etc., set relative position, set units to mm, set tool, set abs extrusion, set relative extrusion - IPP shared infrastructure extension - PWG5100.18 - safe subset of g-code can use MIME format - application/vnd.pwg-safe-gcode - rapid/controlled linear moves - safe subset of g-code can be generated by ipp clients, and infra printers by values of Printer Description attrs - but some of these attrs aren't in IPP 3D 1.0 - added in 1.1 - printing - attrs for job in Job template attrs, if some of them undefined, default values are used - printer-specific attrs can be defined, but there's no guarantee for IPP clients and infra printers to support it IPP 3D printing extension 1.1 ----------------------------- - support of entry-level 3d printer and slicing services - 3d printing based on traditional printing service, with nearly same operations and attributes (except for not applicable ones) - printers with slicing needs to support document format model/3mf and possibly applications/pdf format - new attrs - material-col, print-accuracy, platform-temperature, material-type Openprinting plenary ==================== 2017 ---- - driverless printing, automatic queue setup by cups-browsed, rastertoxxx - understands CUPS/Apple Raster/ PWG , braille support, printer driver repo, - ipp-over-usbxd support - uses IPP on usb printers, runs on http://localhost:60000 - distro independent drivers by Snappy - IPP system service support -> full driverless for MFD ans scanners - google summer of code with openprinting - Qt common printing dialog 2018 ---- - cups browsed - support for other driverless printing standards, daemon now owns temporary queues for remote cups/ipp printers - filters - added PCLm - ippusbx - general improvement Future ------ - cups browsed - taking IPP printers and remote CUPS queues as same, restarts on kill -HUP - GSoC - PDF api for cups-filters (poppler or qpdf), enhancement of ipptool (new ops and attrs), new tool ippdoclint for checking Pwg raster structure and reporting errors - collaboration of OP and PWG - IPP everywhere 1.0, common print dialog, IPP infra extensions, IPP faxout, IPP scan, IPP system service, IPP 3D printing CUPS plenary ============ 2.2.x ---- - GPL2/LGPL2 with exception, security fixes and important fixes from 2.3 will be backported (file the github issue), - API changes and new functions - updated cupsGetDests, cupsCreateJob - IPP everywhere changes - color support, print quailty and other attrs - scheduler changes - avahi related crashes, substitution of default values for invalid values in relaxed confromance mode - security changes - new options of SSLOptions directive - MinTLS, MaxTLS, DenyCBC - and TLS negotiation timeouts, updated HTTP basic and digest support to current RFCs, support of multiple authentication (more schemes in one WWW-authenticate header, delimited by comma, or several concatenated www-authenticate headers) 2.3.x ------ - scheduled June/July 2018 - still working on license - generally Apache 2.0 - IPP everywhere - localization of attrs and values, IPP job presets support, IPP finishing-template support - print accounting - cups now tracks total number of media sheets and logs only once when job is completed - scheduler - support printer-id attrs - API - new encoding f cupsEncodeOption(), improved media selection support with cupsAddDestMediaOptions(), -D_IPP_PRIVATE_STRUCTURES=1 don't work, use ippGetxxx and ippSetxxx from cups-1.6. (ipp_t, ipp_attribute_t in http-private.h all now), -D_PPD_DEPRECATED don't work Deprecations ------------ - they announce in advance, then there is warning functionality - deprecated CUPS API (such as CUPS PPD API) will never be fully removed from shared libraries to preserve binary compatibility - dropped or moved because of security: - dropped interface script - cups browsing - moving several directives to cups-files.conf - deprecating raw queues (cups-2.2.7): - raw queues causes problems for SELinux, apparmor and sandboxes apps, they are pointing to label device - require apps to provide printer specific UI and print data, they dont work with file: device queues - deprecate printer drivers (cups-2.3) - they'll continue to work - why? most printers since 2010 support IPP, Apple/PWG raster and JPEG, many support PDF - we can move to IPP model, for others we will need printer applications - blocks us for better UX, security and distribution nightmare - printer application - serves as IPP printer endpoint, standalonbe replacement for drivers, support setup, configuration, operation functions - CUPS contains everything needed to create lightweight IPP everywhere printer, can accept PDF/JPEGor PWG raster print files and send them to print client, can support any number of client Future ------ - to be more mobile, needs to work on power usage, discovery, security, simplification - power usage - when job processing - optimize filter paths with standalone filters, not sequencing filters - idle wait - start cups only on memory/resource need - mobile - dramatic impact on networking - several interfaces etc. - answer can lie in PostSocket API by IETF, because BSD socket are insufficient - ship lesser project - e.g. mobiles don't need web ui etc - work on printer profiles - can point ot one or more servers/printers, systemwide/peruser, don't depend on dns/sd, LDAP or other infras - enhance DNS-SD/bonjour - now only works on public printers - security - scheduler running as root(and bind to port 631 and needed to run as other user for kerberos support - solution - launchd, systemd, upstart can binding and running cupsd instances per user, stop support of LPD), printer drivers (because of selinux, sand boxing), web interface attacks (OAuth 2.0 - possible replacement for kerberos, possible solution for preventing web interface attacks) Modular printing system ------------------------ - has two levels - user-level and system-level - all modules (user applications, cups commands, cups local server, cups sharing server, printer applications) works above CUPS library - user apps - use cups library directly or through GUI toolkit (gtk,qt) - cups commands - lpadmin, lp, lpr - communicates with local server cups or can be pointed directly to cups sharing server - cups local server - run in user session, access through user-specific domain socket on demand, has credentials for printing, provides basic print conversion (plain text, JPEG or PDF), no persistent print queues - Dns-sd, ldap, conf profiles populate list of printers - cups sharing server - system service which runs as lp user or some other system role, dns-sd+ldap support for sharing to the client/local spoolers, does AAA, print policies, has shared infras extensions support, administraive commands - cupsaccept, cupsdisable etc., web interface - printer applications - not in cups - two ways: 1) create dedicated service or app with tight integration - ippserver+gutenprint combo (reasoning - now gutenprint will not be limited by cups driver interface and can provide better config and status UI), see ippserver (needs to provide generic drivers for legacy printers) 2) service based on current CUPS, which implements filter chain and provides JPEG/PDF to Postscript/Raster conversion - but same limitations as CUPS-2.x CUPS-Filters and IPPUSBXD ========================= cups-filters ------------ - took all what cups didn't want in 2011 + cups-browsed for removed functionality for CUPS broadcast/browsing - now autocreates queues for IPP network printers and IPP over USB printers - mobile support (auto shutdown, driverless printing), load balancing - supports legacy CUPS browsing and broadcasting - why need of cups-browsed? clustering, filtering of printers, new driverless printing techs, legacy tech support (no cupsEnumDests, support of cups<1.5, IPP 1.x printers) - new features: configurable clustering, all driverless printing standards, for printer applications it has option to have create only local queues for IPP printers on localhost (printer app is ippusbxd too) - ppd file generator - keep up functionality with cups ppd generator - robustness of queues against user error - overwritten queues are released from cups-browsed and recreated with new name, deleted qeues are recreated - filters changes - pdftoopvp and pdftoijs deprecated, support of PCLm, flattening of interactive PDF forms (filled form content can lost during the printing -> needs to convert to static PDF. Now solved by poppler or ghostscript as fallback, qpdf can be used in the future) - project moved to github - future - make cups-browsed restartable in-process - re-read configs and restart on kill -HUP - don't use CUPS PPD API - do not download PPDs from remote cups printers - treat IPP printer and remote cups queues as equal - remove dependency on poppler - qpdf based solutions for bannertopdf and form flattening - provide infra for Printer apps - translate PPDs into languages supported by cups translations tables - choose a printer based on job and selected settings by user ippusbxd ---------- - major changes in communication - now claims all USB interafces to avoid bad effects when releasing one, while other is communicating, no HTTP stream parsing, support of PCLm, default port 600000 on localhost, now faster - needs to support services on localhost - for ippusbxd and printer apps in general - printer apps framework: - printer app - can be daemon like ippusbxd, emulating driverless IPP printer, run input data through driver for printer's PDL and to printer vie IPP, socket, usb - wrap legacy drivers - gutenprint, hplip, foomatic or foo2zjs - into printer app -> universal cups driver wrapper printer app - backends will be library functions for printer apps - there should be needed changes in avahi for printer apps GSoC 2018 ========= - completed projects - common print dialog, PCLm filter, flattening nonstatic PDF content - upcoming - port filters all to poppler standard API or to qpdf, enhancement of ipptool (new ops and attrs for IPP everywhere), ippdoclint (tool for checking correctness of incoming document in PWG raster format), common print dialog project (dbus interface), automatic selection of printer from cluster by given options, enhancing ippserver, qt print dialog completion IPP WG ======== Specifications in development ---------------------------- - pwg specs in dev - IPP 3d extensions 1.1, ipp everywhere (eve) 1.1, ipp self cert manual 1.1, ipp system service 1.0 - best pracites in dev - safe subset of g-code Specifications approved ----------------------- - ipp wg approved docs - ipp presets, ipp privacy attrs, supportiung multi purpose trays, ipp get-user-printer-attrs - pwg approved docs - pwg 3d ticket and associated capabilities, PWG 5100.1-2017 - ipp finishings 2.1 and pwg 5100.21-2017 ipp 3d extensions 1.1, updated RFC for ipp - 8010 and 8011 What going on -------------- - obsoleting access-x509-certificate attr - originally for IPP scan and TLS client auth, but it cannot be done securely - providing private key to the printer is against best practises for TLS - ippsample code (code on github) - areas - ipp eve, - ipp 3d (required part implemented, currently only single extruder printer support, work in progress) - ipp shared infra extension (only registered-output-device is missing), - ipp system service(almost complete) - AAA, gateway for legacy doc format (HP PCL, safe g-code) IPP sample example ------------------ - start ippserver, where printers are, then start ipp proxy to ippserver and then send job to ippserver by ipptool - pcl printer can be created by ipptool, then enabled and started IPP system service ================= - ipp system service is about ipp objects, ops and attrs to support management and status monitoring multifunction devices - combines and implements IPP binding of abstract semantic model 2.0 services and objects - system object and system control service, network resources service and cloud imaging requirements and model - ipp infra printer is ipp printer -> must already exists for proxy - system service supports creation of printer - directly through Create-printer op, and inderctly through register-output-device op (this allows printer discovery through proxy ops as update-output-devices-attrs) - several notes when prototyping the system service - new attrs and keywords are needed, clarification of meaning system-state attrs, create-printer op can't require printer-xri-supported, because it is set by System - discussion about several attributes - if they are needed, what they should contain - e.g. xxx-owner-col attrs IPP encrypted jobs and documents ================================ - this is new specification, currently as working draft - it defines new encrypted IPP message format for end-to-end encryption of job template attrs, document template attrs and docs data - currently combines openpgp ans s/mime message formats - client submits data in application/ipp+pgp-encrypted or application/ipp+pkcs7-encrypted format - then printer needs to merge attrs in encrypted message with attrs in unencrypted part of message, then validate them and decide whether continue or abort - based on asymetric crypthography - printer has private and public key, user uses public key to encrypt attrs and data, adds passcode and send it to printer - it decrypts message by private key and passcode - printer needs to provide certificate for each supported encrypted message formats - infra printers don't do any validation and just pass message to the ipp proxy - if ipp proxy is used, it provides infra printer with certs by update-output-device-attributes op, do not share private keys with infra printer - public key is shipped as printer description attr IPP Job reprint password ========================= - new specification (in internim state) for new operation attribute - job-reprint-password - for password protection of reprinting saved jobs. - info if job reprint password is supported in printer is carried in printer description attr job-reprint-password-supported - existing job-password operation attr doesn't last after job completion -> for security of reprinting, job reprint password is introduced IPP Everywhere 1.1 ================== - ipp eve was introduced because of mobile devices - current printer driver solution (vendors created specific PDL -> need of printer specific driver) isn't acceptable for mobile devices - ipp eve throws away printer driver solution and supports printing through IPP, standard document formats (PWG raster, JPEG, PDF), discovery protocols (MDNS) and schemas without printer specific drivers - printer and scheduler needs to support IPP v2.0 at least - ipp eve 1.1 is working draft - changes - dropped support of WS discovery, SSDP, OpenXPS because of lack of implementation, JPEG is conditionaly required for color printers, ipp finishings 2.1 and finishings-col is now recommended attrs - ippeveselfcert - certification tool for printers - user runs tests on printer and if they are successful, printer is IPP everywhere ready. Imaging device security ====================== - current status of hardcoded devices protection profiles (PP) - certified by Jap. scheme, approved by US and Japanese schemes - protection profile - document about threats, security objectives, assumptions , security functional requirements SFR, security assurance requirements SAR and rationales - hardcode device - system producizing or utilizing a physical embodiment of electronic document or image - printers, faxes, scanners, MFD etc - upcoming new specification HCD PP 1.1 - minor corrections - decisions on HCD PP 1.0 (mostly moved to HCD cPP) - prevention of audit data loss is mandatory, - TOE security functions (TSF) shall be able to store generated audit data to target of evaluation (TOE), - SFR for IPsec and TLS, remove SFR for TLSv1, - optional SFR - cryptokeys management of TSF data (TSF should restrict access to crypthograhic keys), - TSF should store authentication passwords in nonplain text - minor modification of SFR about key wrapping, key management description How to use Internet printing protocol ====================================== - new book about IPP, it is in pwg github as ippguide - ipp - secure application level protocol - used by clients to inquire capabilities of printers or their status, submit print jobs or make inquiries about jobs - ipp replaces legacy network protocols like port 9100 printing or LPD - ipp uses http as transport protocol - every request and response is in HTTP POST - can be encrypted by TLS or by default with HTTPS - uses binary encoding of message - printer has URI, starting with ipp or ipps scheme: ipp://printer.example.com:631/ipp/print ipp/print part is non stanradized, look into your printer specification for what is needed to be here (especially with older IPP printers) Message encoding ---------------- - first IPP version, operation code (request) or status code(response), request number and list of attrs - attrs types - enum, integer, collection, keyword, mimeMediatype, name, text, uri - attrs group - operation attrs for operation request/response, job attrs - attributes in message - first two are attributes-charset (defines character set for name and text strings in message) and attributes-natural-language(defines default language) for strings. Then comes printer uri (if request is targeting a job, then job-id). There can be name of user who submits request - requesting-user-name. Request for printing file contains MIME media type for the file - document-format - text/plain for text files, image/jpeg for image and application/pdf for pdf etc. - operations - most commonly used - get-printer-attributes, create-job, print-job, send-document, get-jobs, get-job-attributes, cancel-job... - two abstract objects in IPP model - printers and jobs Printers -------- - represent output device - printer, virtual printer - types of attrs - status (status of printer), capabilities (if it supports duplex etc.) and general info description (printer location) - have print queue of jobs and job history - status attrs are printer-state (3 - idle, 4 - processing, 5 - stopped) and printer-state-reasons (none, media-needed, toner-low etc.) - may have suffix -report, -warning or -error to tell if reason is blocking printing a job - description attrs are printer-uri-supported, printer-info, printer-location etc. - capability attrs are ipp-features-supported, operations-supported, charset-supported, document-format-supported (file formats that can be printed), media-supported (paper size and types which are supported), sides-supported etc. - attrs can be get by get-printer-attributes request Print jobs ---------- - work done by printer - attrs types - status, description, job ticket (print options) and job receipt (what print options were used, how many pages were printer etc.), job template - can contain 0-N documents to print - job status attrs: - job-state (3 - queued and pending, 4 - job is held because user wanted it or waits for passcode, 5 - processing, 6 - stopped (out of paper etc, 7 - cancelled by user, 8 - aborted by printer, 9 - completed successfully)), - job-state-reasons (none, document-format-error (cannot print because of error in file format), document-unprintable-error (cannot be printed because of out of memory or too complex file)), - job-impressions-completed (number of sides/images that were printed) - job-media-sheets-completed (number of sheets that were printed) - job-pages-completed (number of document pages that were processed) - job description attrs: - job-name - job-impressions, job-media-sheets, job-pages - job template attrs: - tells how document needs to be printed - common attrs - media, copies, sides, print-color-mode etc. Documents and job submiting --------------------------- - printer reports which document format support in printer capability attr document-format - mostly support JPEG, PDF and PWG raster, but many have support of old postscript format, HP PCL format and vendor-specific formats - application/octet-stream format tells the printer to detect correct format automatically - submitting a job - by print-job request (creating job and sending doc in one operation, but it cannot be canceled promptly) or by create-job+send-document requests (first is sent create-job request with job template attrs, server returns job-id, which will be used in send-document request with file, or in cancel-job request) IPP authentication methods ========================== - currently none, http basic, http digest, http bearer (oauth2.0), http negotiate (kerberos), auth with x.509 certificate via TLS, maybe http mutualauth in the future - none - not recommended, user acts as anonymous -> at least provide requesting-user-name attr - requesting-user-name - better than none, but still no authentication if user is really who is claims to be - basic, digest - http server returns 401 unauthorized response - client finds out by www-authenticated header in response and asks user for credentials - if they will be correct, request is sent to ipp printer from http server Next steps ========== - progress with IPP system service specification, IPP eve and selfcert 1.1, IPP 3d, safe g-code, IPP encrypted job and docs - book "How to use IPP"
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
