[Pkg-cups-devel] Bug#427559: Bug#427559: cupsd "run as user" changes in 1.2.11-2 breaks existing installations (no printing)

[Kurt Pfeifle]

Martin-Éric Racine wrote:
> On 6/5/07, Kurt Pfeifle <kurt.pfeifle at infotec.com> wrote:
>> Martin-Éric Racine wrote:
>> > On 6/5/07, Kurt Pfeifle <kurt.pfeifle at infotec.com> wrote:
>> >> Package: cupsys
>> >> Version: 1.2.11-2
>> >>
>> >> I'm reporting on behalf of
>> >> a customer who called me today because important functions on his test
>> >> printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2;
>> >
>> >> He can not use that system any more for now, until he pays money to
>> >> someone to fix everything (if that is at all possible; otherwise to
>> >> migrate it to a non-Debian distro).
>> >
> 
>> > that I have serious issues with your report on one specific
>> > aspect:
>> >
>> > Your customer is running Testing on a production server that he needs
>> > to depend upon for everyday work.
>>
>> No, you didn't read (or exactly memorize) what I wrote. I said it was his
>> *test* print server. Please check.
> 
> You said test server 

I'm glad that everyone who cares can read for himself if I wrote
"test printserver" or else.

> and yet you report on how this latest upgrade
> alarmingly broke everything he is running on that.  That makes it
> pretty clear that he depends upon that server for everyday life.

Whatever.

What I indeed did want to make pretty clear are these current facts:

 * your current way of upgrading to CUPS 1.2.11-2 from a previous
   CUPS 1.2.x version breaks currently working installations

 * if you do not change $whatever (code, documentation, buildtime
   configure, startup script, postinstall-script, $wildcard) by the
   time this upgrade happens in next stable, your users may be hit
   quite unprepared by some printing b0rkenness

Please stop discussing your theories about how this customer may be
relying on a Debian Unstable for a production print server. This
theory's validity is completely irrelevant to the above two points.

>>  * it is totally legal and valid to report bugs and submit wishlist items
>>    against a Sid/unstable system irrespective of the fact whether these
>>    were acquired on a "production" system
> 
> That "you guys broke our system and it's gonna cost us a fortune to
> get it fixed" moaning won't help their case, at any rate. 

OK, please forget this part of my mail. It was also irrelevant to
my important points.

> It also
> proves that they actually rely upon that server for everyday use.
> 
>>  * some people run "Testing" and "Unstable" *now* on their test and
>>    "pilot" systems because they have a long term plan to migrate hundreds
>>    of servers and 10s of thousands of workstations to Linux, away from a
>>    proprietary system (and by the time of the migration they hope to use
>>    a "Stable" or "Testing" version)
> 
> In which case it's just a test server, not a system running a number
> of  scripts and filters they noticably depend upon.

They do not yet depend on these scripts and filters; but they will,
once they migrate to Linux. And their decision to migrate will heavily
depend on how well the current tests and pilots work.

And current tests and pilots are being run in order to find out any
problems now, and to help iron out what can be ironed out...

Is that comprehensible?

>> I didn't see you participate in any of the detailed discussions that
>> took place on the upstream mailing lists about that particular topic;
>> not once on many occasions over the last 2-3 years when they happened;
>> therefore I do not deem you competent in uttering a verdict about
>> upstream having a "patently broken security model".
> 
> I have been following the issue for longer than that, but whatever.
> It has become clear to me that you only came here to bicker and to
> push these maintainers into reverting every change that disagrees with
> how you would maintain this package.
> 
> However, I have an even better proposal for you: become the CUPS
> maintainer in Debian, yourself, right now.

I'm clearly not qualified to be a package maintainer, because I just
know too little about building, packaging and Debian policies.

My qualification lies elsewhere. One field is what you call "bickering",
yes.

> Start by triaging the bugs currently open against the package.

In case you did not notice: I *did* already start. Last night. Even
before I sent my first reply to you in this thread. And I suggested
to close the bug in question (Bug #259774).

> Then submit patches that show what changes you would like to see in
> CUPS for Debian (and keep in mind our stated goal to keep differences
> between the Debian and Ubuntu packages minimal).

I'd like to see as little changes compared to upstream pristine sources
as possible. Especially, if they are undocumented for the end user.
Especially if they change some fundamental behaviour of the software.
Especially if they do not explain how to get back the original behaviour.
Especially if they disallow to get back the original behaviour.

> If you do a good job at it, we'll gladly let Your Expertness take over
> the package's maintenance and, yes we mean it. :)

I even trust you on this. Be assured, My Expertness is much more lowly
educated than it may appear. However, if we switched roles, I'm sure
you or someone else would start screaming "Uh -- he's running the thing
as root! Uh, he's opening up glaring security holes!! Uh -- he's
providing huge attack vectors for free!!!"

Which would automatically disqualify me from "doing a good job at it".

So let's keep our current role distribution.    ;-)

I'm asking only for this regarding this last change, and I repeat it
once more:

  -- either return to the same setup as upstream CUPS sources

  -- or do re-enable the "RunAsUser No" option in cupsd.conf
     (compatibility in behaviour for third party add-ons [filters,
     backends])

  -- and please do at least make it un-mistakenly clear in the CUPS
     docu at localhost:631/help what you changed and how the user can
     return to upstream's CUPS behavior for its scheduler and backends.


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Fon/Fax: +49-711-4017-5677/-2303  ...........  Mobile: +49-172-715.7017
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany 
---
Infotec Deutschland GmbH
Hedelfingerstrasse 58
D-70327 Stuttgart
Telefon +49 711 4017-0, Fax +49 711 4017-5752
www.infotec.com
Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen
Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398

Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen.
Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung.
This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of this communication, in whole or in part, is not permitted. Any views or opinions presented are those of the author and (unless otherwise specifically stated) do not represent those of Infotec Deutschland GmbH or their directors or officers; none of whom are responsible for any reliance placed on the information contained herein. Although reasonable precautions have been taken to ensure that no viruses are present, all liability is excluded for any loss or damage arising from the use of this email or attachments.
For further information please see our website at www.infotec.com or refer to any Infotec office.