Bug#4332: Vulnerability in the Xt library (fwd)
On Thu, 29 Aug 1996, Marek Michalkiewicz wrote: > Package: xlib > Version: 3.1.2-7 > > It seems there is a buffer overrun in libXt, which may be a security > hole (some programs using libXt, such as xterm, are setuid root). > I haven't tried to exploit it, but xterm -fg very_long_string > segfaults, so it might be exploitable (stack overwrite). See the > attached message (which appeared on the bugtraq list) for a patch. I'm currently trying to clear some of Steve Early's backlog of X package bugs; this'll be among them (though it may be a while longer before the packages get converted to the new source format.) (S)
Re: shlibdeps
In article <[EMAIL PROTECTED]> you write: >Are we supposed to use dpkg-shlibdeps for all dependecies upon shared libs? I believe so, yes. >Or is it just for the three (or so) installed in /etc/dpkg/shlibs.default? Ian will correct me if I'm wrong, but I think (under the New Scheme of Things) packages which provide shared libraries should have a debian/shlibs file detailing the appropriate dependency information. Until all packages which provide shared libraries are converted to provide this file, we could: (1) Have all the shlibs information in /etc/dpkg/shlibs.default. (This happened with the X libraries.) or (2) Temporarily put the appropriate information in debian/shlibs.local in the package with the dependency on the shared library. IMO neither of these is wonderful; thoughts? (S)
Re: PGP depends.
In article <[EMAIL PROTECTED]> you write: >I bit the bullet today and decided to install and implement pgp. Searching >the packages files did not turn it up, but I was able to deduce that it >was therefore, in non-free. However the search turned up this information: > >dchanges - recommends: pgp With the new source format obsoleting it, dchanges should be removed as soon as possible. (In case anyone tries to use it!) (S)
Bug#4350: Self-contradictory help message for dpkg-buildpackage
Package: dpkg Version: 1.3.12 sfere:/home/ftp/pub/debian/binary/base$ dpkg-buildpackage -h [...] Usage: dpkg-buildpackage [options] Options: -r [...] -si (default) src includes orig for rev. 0 or 1} genchanges -sa uploaded src includes orig (default) } Clearly one or the other of these is the default, but not both! (S)
Bug#4349: dpkg-source has misleading warning message
Package: dpkg Version: 1.3.9 sfere:~$ dpkg-source -b procmeter-2.0 procmeter-2.0.orig.tar.gz dpkg-source: warning: .orig.tar.gz name procmeter-2.0.orig.tar.gz is not -.orig.tar.gz (wanted procmeter_2.0.orig.tar.gz) This should read `... is not _.orig.tar.gz ...' (S)
Re: Bug#4269: xosview has only XOSView as application resource file
In article <[EMAIL PROTECTED]> you write: >> "jw" == joost witteveen <[EMAIL PROTECTED]> wrote: > >jw> do you want me to >jw> 1 move xosview to 'contrib', and stop maintaining it >jw> 2 just go on maintaining a broken xosview? > >IMHO, you should stick with 1. There are other things that may do the >same thing xosview is supposed to do. > >>>From sunsite.unc.edu:/pub/Linux/INDEX.whole: > >/pub/Linux/X11/xutils/status >procmeter-1.1.tgzdisplays a set of graphs with system stats >xsysinfo-1.5.tar.gz provides a graphical representation of system > state Debian has packages for both, I believe. (In fact, I'm told that both I and someone else have packaged procmeter recently, so we'll see which one gets into the distribution :-) ) (S)
Re: Do we ever retire packages?
In article <[EMAIL PROTECTED]> you write: >[EMAIL PROTECTED] writes: >> May I humbly suggest that we establish some sort of policy regarding packages >> that obsolete and can be retired? > >Yes, please! > >> I have argued before that a2ps and a2gs are effectively replaced by >> genscript, and that we should remove them. I think a similar case could be >> made for xosview as we now have procmeter. >> >> Opinions? > >Remove them. I'm not so convinced; while I may agree that xosview is a complete mess, I think the user should still have the choice as to whether to use it or procmeter. (S)
Bug#4269: xosview has only XOSView as application resource file
On Mon, 26 Aug 1996, joost witteveen wrote: > > Xosview only reads the file XOSView (and ~/.Xdefaults) when evaluating > > its X resources. It does this by doing all the reading by foot (calling > > XrmGetFileDatabase() etc.). > > This is IMO the wrong way to do it; the application should use > > XtGetApplicationResources() (as xsysinfo does it). > > You're absolutely right. > > The upstream maintainer disagrees (well, he agrees, but doesn't want > to change it, AFAIK). > > do you want me to > 1 move xosview to 'contrib', and stop maintaining it > 2 just go on maintaining a broken xosview? > > Sometimes, I really don't know what to do. In general, unless you particularly want to do something about the problem yourself, I'd vote for (2). Note that there's now a procmeter package which displays the same information as xosview and more... (S)
