The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft: Security Alert Announce#1 Debian/GNU Linux

In article <3278ECBC.32CF@hydra.acs.uci.edu> Dan Stromberg <strombrg@hydra.acs.uci.edu> writes:

> LPRng compatibility issues (not necessarily exhaustive, not necessarily
> show-stoppers) :
> 
> 1) LPRng's printcap.5 page indicates that ":bk:" is required for strict
> RFC conformance.  I am aware of only one RFC related to the BSD
> printsystem, which defines the TCP/IP used, and (as I recall) nothing
> about what happens on a host once the network is no longer involved. 
> From this I conclude that LPRng's ":bk:" option impacts only LPRng's
> network behavior.

Sounds correct.

>  I found that an RFC-conformant printsystem I wrote
> (which I do not really recommend for this purpose, tho it -seems- highly
> secure) could not send a job to an LPRng queue until I added the ":bk:"
> option into the LPRng /etc/printcap, for the relevant queue.  Amusingly,
> the ":bk:" option seems to reverse the cf/df order; without ":bk:" LPRng
> seems to be broken with respect to the RFC in the same sense that Ultrix
> is broken - this was determined empirically, not be study of the
> sources.  BTW, it is not at all difficult (in a well structured print
> system) to make a printsystem handle both the RFC-order, and the
> ultrix-order.

AFAIK :bk: must be used when you print from LPRng to a BSD-lpd
printer, this is reverse to above case.

> 2) LPRng's printcap.5 page indicates that ":bkf:" is required to "use
> Berkeley filter options".  This may help with the "of=" issue.  Also,
> there is seldom any use for "of=" filters - everything can be done
> nicely thru an "if=".

I wasn't aware of this ...

> 3) If LPRng truly has no root-owned component, then it will have a
> difficult time allocating a reserved port, from which to send jobs to
> existing printsystems.

It binds to the port, and changes then to user lp.

> My preferred approach to the situation:
> 
> 	1) I think someone who follows the LPRng/plp list, should ask
>            there about migration issues.  Folks there such have a
> 	   fairly complete notion, and will hopefully be willing and
> 	   able to articulate it

Ok. I follow the list, and I will ask there.

> 	2) I would want someone (I could perhaps donate some
> 	   time during off hours) to track down the OpenBSD fix, and
>            merge that into into the debian lpr.  Was the debian lpr
> 	   done as patches against the upstream stuff, or is it "a
> 	   thing unto itself" now?

The debian lpr is a very old version. I'm sure it missed some other
fixes too. The only option is to start from a fresh BSD lpd
(e.g. OpenBSD's).

> I believe we should Consider (I won't push for this, but I do want it
> tossed up for discussion) compiling a version of LPRng that uses the
> ":bk:" and ":bkf:" (and whatever else) behaviors -by-default-.

AFAIK there were real reasons for changing the default behaviour. I'll
ask.

	Sven
-- 
Sven Rudolph <sr1@inf.tu-dresden.de> ; WWW : http://www.sax.de/~sr1/

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com