default   Racket Bugs
Main PageQuick QueryStandard QueryAdvanced QueryHelp
Log in

View Problem Report: 10756

send email to interested parties or send email followup to audit-trail
Reporter's email: jamessan at debian dot org
Number: 10756
Category: misc
Synopsis: Link plot collect against system zlib
Class: change-request
Responsible: eli
Notify-List:
Severity: non-critical
Priority: medium
State: closed
Confidential: no
Arrival-Date: Wed Feb 10 17:28:01 -0500 2010
Closed-Date: Fri Sep 30 06:01:47 -0400 2011
Last-Modified: Fri Sep 30 06:01:47 -0400 2011
Originator: James Vega
Organization: plt
Submitter-Id: unknown
Release: 4.2.4
Environment: Linux i686 / Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.1 (KHTML, like Gecko) Chrome/5.0.321.0 Safari/533.1
Description: Currently, the plot collect embeds a copy of the zlib source which it builds against.  I can work around this by removing those files and adding a "-lz" to the proper portion of collects/plot/pre-installer.ss, but this seems a bit drastic.  Would it be possible to support linking against the system zlib if it exists and fallback to the embedded copy otherwise?
File Attachments:
How-To-Repeat:
Fix:
Release-Note:
Unformatted:

send email to interested parties or send email followup to audit-trail

Audit Trail:

From: Eli Barzilay <eli at barzilay.org>
To: jamessan at debian.org, bugs at plt-scheme.org
Cc: 
Subject: Re: [plt-bug] all/10756: Link plot collect against system zlib
Date: Wed, 10 Feb 2010 17:32:07 -0500

 On Feb 10, jamessan at debian.org wrote:
 > Currently, the plot collect embeds a copy of the zlib source which
 > it builds against.
 
 Is there any problem with that?
 
 -- 
           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                     http://barzilay.org/                   Maze is Life!
From: James Vega <jamessan at debian.org>
To: Eli Barzilay <eli at barzilay.org>
Cc: bugs at plt-scheme.org
Subject: Re: [plt-bug] all/10756: Link plot collect against system zlib
Date: Wed, 10 Feb 2010 18:45:43 -0500

 On Wed, Feb 10, 2010 at 05:32:07PM -0500, Eli Barzilay wrote:
 > On Feb 10, jamessan at debian.org wrote:
 > > Currently, the plot collect embeds a copy of the zlib source which
 > > it builds against.
 > 
 > Is there any problem with that?
 
 To counter, is there any problem with using the system's library?
 
 The biggest problem, from a distributor's perspective, with not using
 the system library is that plt doesn't benefit from updates to zlib
 which fix important bugs.  From a quick look, the version that's being
 used in plt (1.1.4) has an almost 6 year old vulnerability[0].
 
 Although I'd suggest not shipping an embedded version, it doesn't
 particularly matter to me as long as I can avoid using it.
 
 [0]: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0107
 -- 
 James
 GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
From: Eli Barzilay <eli at barzilay.org>
To: James Vega <jamessan at debian.org>
Cc: bugs at plt-scheme.org
Subject: Re: [plt-bug] all/10756: Link plot collect against system zlib
Date: Wed, 10 Feb 2010 20:18:57 -0500

 On Feb 10, James Vega wrote:
 > On Wed, Feb 10, 2010 at 05:32:07PM -0500, Eli Barzilay wrote:
 > > On Feb 10, jamessan at debian.org wrote:
 > > > Currently, the plot collect embeds a copy of the zlib source which
 > > > it builds against.
 > > 
 > > Is there any problem with that?
 > 
 > To counter, is there any problem with using the system's library?
 > [...]
 
 Let me clarify the status of that code.  The plot collection in PLT
 was made as an interface around the plplot library -- and this was
 done by just grabbing the source for that and dumping it more or less
 as-is into the plt tree.  That in itself is pretty bad, but it's even
 worse in the sense that it's only used to draw plots -- and that's
 functionality that we already have in PLT itself.  Even worse, the
 plplot code itself dragged in that zlib code...
 
 So the sad state of things is that our gui libraries are rich enough
 to produce better graphs natively (better because we use cairo, and
 natively in the sense that there's no need to use foreign code or use
 external files).  But when you use the plot collection, each graph is
 done by this library, which is made to dump an output png in a
 temporary file, which is then read back in.
 
 At some point I hope that this whole thing would be replaced by scheme
 code to create the graphs -- which will be a much better solution on
 several levels.  Until then, I'd like to avoid fiddling with it since
 I don't know much about it.  (To clarify, I'm the designated
 maintainer for it by inheritance, but I can't provide any real support
 -- and therefore my view is that it would be easier to just redo it in
 scheme.)
 
 As for the security issue, I don't think that there's a problem with
 that since it's used exclusively as part of the plplot code to draw
 plots.  We don't use it in any other way.
 
 -- 
           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                     http://barzilay.org/                   Maze is Life!
From: James Vega <jamessan at debian.org>
To: Eli Barzilay <eli at barzilay.org>
Cc: bugs at plt-scheme.org
Subject: Re: [plt-bug] all/10756: Link plot collect against system zlib
Date: Thu, 11 Feb 2010 00:23:27 -0500

 On Wed, Feb 10, 2010 at 08:18:57PM -0500, Eli Barzilay wrote:
 > On Feb 10, James Vega wrote:
 > > On Wed, Feb 10, 2010 at 05:32:07PM -0500, Eli Barzilay wrote:
 > > > On Feb 10, jamessan at debian.org wrote:
 > > > > Currently, the plot collect embeds a copy of the zlib source which
 > > > > it builds against.
 > > > 
 > > > Is there any problem with that?
 > > 
 > > To counter, is there any problem with using the system's library?
 > > [...]
 > 
 > [history]
 
 Thanks for the explanation.
 
 > At some point I hope that this whole thing would be replaced by scheme
 > code to create the graphs -- which will be a much better solution on
 > several levels.  Until then, I'd like to avoid fiddling with it since
 > I don't know much about it.  (To clarify, I'm the designated
 > maintainer for it by inheritance, but I can't provide any real support
 > -- and therefore my view is that it would be easier to just redo it in
 > scheme.)
 
 Ok, I can see that.  In that case, I'll leave it as is and just apply my
 patch locally in the unlikely event I get feedback about having an
 embedded copy of zlib in the package.
 
 -- 
 James
 GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>

Responsible changed from "nobody" to "eli" by ryanc at Tue, 10 May 2011 19:55:59 -0400
Reason>>> plot


State changed from "open" to "closed" by eli at Fri, 30 Sep 2011 06:01:47 -0400
Reason>>> The zlib code is no longer there.