Re: sash
Michael Neuffer <[EMAIL PROTECTED]> writes: > * Raul Miller ([EMAIL PROTECTED]) [990923 16:15]: > > On Thu, Sep 23, 1999 at 07:32:50AM -0500, Ashley Clark wrote: > > > Couldn't sash include a PAM module that would change the password to > > > match root's password whenever it was changed? Or am I oversimplifying > > > things? > > > > I don't have enough confidence in Debian's pam, yet, to insist that > > everyone that wants to use sash must implement pam support before > > using sash. > > Depending on PAM would be a fatal mistake. > sash is for situations when your system is FUBARed, > therefore you can not assume that you will still have > a working PAM subsystem either. > > It must be completely standalone without needing any external > libraries. This is _not_ about the sash executable itself using PAM. It was a proposal to use the PAM functionality to ensure that the root and sashroot passwords remain in sync, i.e., whenever root's password is changed, change the sashroot password as well. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Conference! - around the world with Debian
Ben Pfaff <[EMAIL PROTECTED]> writes: > Peter Makholm <[EMAIL PROTECTED]> writes: > >Russell Coker <[EMAIL PROTECTED]> writes: > >> For those of us who attend in multiple countries we could book plane > flights >> together (hopefully get a good deal), play network Quake in the plane, > etc. > >Then we need a sponsor with a big wallet. > > ...or a battery-powered hub :-) Have people forgotten about coax? :-) - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Re^2: strange behavior of dh_dhelp
[EMAIL PROTECTED] (Marco Budde) writes: > Am 24.09.99 schrieb joey # kitenet.net ... > > Moin Joey! > > JH> > dh_installdocs uses doc-base, which in turn registers documents for > JH> > dwww and dhelp. Thous it is a superset and should be used, no? > > I would recommend using dwww and dhelp directly. dhelp#s parser is written > in C and uses a database. So it#s a lot of faster than using doc-base, > which is written in perl. Especially on "old" 486/586 CPUs using dhelp > directly speeds up the installation process of packages dramatically. > > dhelp comes with a dhelp -> dwww converter. So it#s no problem to support > both system. > > JH> Yes. > > Why? What is the advantage of using doc-base? Because if in the future we get another documentation system in addition to dhelp and dwww, it will be automatically supported by every package using doc-base. Why do we have two Debian documentation systems in the first place? NIHS? - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Re^2: strange behavior of dh_dhelp
[EMAIL PROTECTED] (Marco Budde) writes: > PSG> I could see http://localhost/doc/HTML/, but all new docs visible > PSG> as file:/usr/share/doc/HTML/index.html could not be seen under > PSG> the http://localhost interface to dhelp. Is `fhs' supposed to be > PSG> a new Alias? > > localhost/doc/ should point to /usr/share/doc. Please submit a bug report > for your http daemon. It should point to /usr/doc/ as a result of the technical committee decision. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Re^2: strange behavior of dh_dhelp
upport /usr/doc with one problem: > > No. We need a decision: which one is the *main* doc directory. Which one > should the user use. At the moment I would suggest /usr/share/doc. At the moment (at least for the potato release) it is /usr/doc/ as decided by the tech ctte. > RR> the doc-base and .dhelp files point > RR> to the real location in /usr/share/doc, > > .dhelp does not point to this directory. Here you see one advantage of my > format: dhelp uses relative file names. In fact you could add the same > .dhelp file to both: /usr/doc and /usr/share/doc. > > RR> while the files are also > RR> accessible via the symlink as /usr/doc/. There needs to be > > One again: they are *not* accessible via these symlinks! This may work > sometimes but not always -> hack. A good configured http daemon will not > follow these symlinks. Why not? A well-configured http daemon can be configured so that symlinks from /usr/doc will be allowed but not from other locations. > RR> some work around for this, but this should be possible with some Perl > RR> or Shell knowledge. > > dhelp is a offline system. dhelp doesn#t convert things during runtime > like dwww does. > > RR> No problem when you see /usr/doc as the one and only directory for > RR> accessing the files. > > ??? But we use /usr/share/doc. Read the policy. READ THE FSCKING TECH CTTE DECISION. > RR> The documentation of every package should be > RR> available as /usr/doc/ in potato (this will change in the far > RR> future, but now we are working on potato). > > Great and the next Debian release will have the same or even more > problems. I don#t like such hacks. In fact I don#t understand why we > should not simply move our documentation to the new directory. Then read the debian-policy archives and the tech ctte decision. Surely if it would be that simple, why was there such an amount of discussion about it. > RR> decision. Maybe you noticed, that newer versions of debhelper and > RR> lintian already support this way to handle this. > > I don#t use debhelper. Good for you. > RR> That's not true. At least apache supports following symlinks when you > RR> activate this with "Options FollowSymLinks" in access.conf for the > RR> /usr/doc directory. Other web servers will support this in a similar > RR> way. > > Will apache follow symlinks in /usr/doc or symlinks to all possible files? > Using this feature could course real security problems. And of course > there#re other http daemons than apache. One last request. Can you please use the ASCII character set in your messages? Those # (hash marks) instead of apostrophes do not help the readability of your messages. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org | http://weer.moonblade.net
Re: Intent to give away: gradio, troffcvt
[EMAIL PROTECTED] (Ben Pfaff) writes:
> gradio is a simple program suitable for a newbie maintainer,
> though I suppose we don't have any newbie maintainers given that
> we don't have any new maintainers.
Even though I am not a newbie maintainer, I am willing to take this
package, if noone else volunteers. I've got a TV/radio card and use
this package myself.
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: procps trying to overwrite /bin/kill
Mirek Kwasniak <[EMAIL PROTECTED]> writes: > On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote: > > Package: procps > > Version: 1:2.0.3-3 > > > > Preparing to replace procps 1:2.0.3-3 (using > > .../procps_1%3a2.0.3-4_i386.deb) .. > > . > > Unpacking replacement procps ... > > dpkg: error processing /var/cache/apt/archives/procps_1%3a2.0.3-4_i386.deb > > (--un > > pack): > > trying to overwrite `/bin/kill', which is also in package bsdutils > > dpkg-deb: subprocess paste killed by signal (Broken pipe) > > > > This seems to be seriously broken. > > No, news bsdutils package is without kill. Then there should be a proper conflicts or replaces header in the procps package. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: permission denied on owned files
Dale Scheetz <[EMAIL PROTECTED]> writes:
> Something else strange just happened during an autobuild pass. All of the
> subdirectories in my build tree have suddenly become inaccessable to the
> build user, who owns all the files and directories. Here is what I get:
> $ cd sbuild
> sh: cd: sbuild: Permission denied
> $ ls -l
> total 9
> drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild
>
> So, where do I look to figure out why I am not allowed access to these
> files/directories?
In order to access a directory you must have execute permission (the
x-bit) on it.
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: bootpd/tftpd bug
Eduardo Marcel Macan <[EMAIL PROTECTED]> writes: > I have only noticed it on a slink machine, I ask someone who has > potatoes to test it too... > > I am configuring one machine as a boot server in order to install > Debian in a PowerPC (IBM 43P) I have here, but one strange thing is happening. > > bootpd gets the request and sends the machine an IP number ok, and > tells it that the file to get is "/rescue2200prep.bin" (notice the slash). > but when it asks tftp to send "/rescue2200prep.bin" it gets an "access > violation", if I manually invoke a tftp session and ask for > "rescue2200prep.bin" it comes right. > > The problem is that there is no way of preventing bootpd from adding > the slash to the bootfile name, neither making tftpd accept the slash (it > does not accept it for security reasons I think). > > I looked at the bug database and it seems that noone reported > such thing before, maybe it can be in potato too. If so, I can file > a bug report (against netstd). By default, tftpd is set up to serve only files from /boot, which is also the default directory if a relative path is specified (this is documented in the manual page tftpd(8)). You can change this behaviour by editing the tftpd line in /etc/inetd.conf: change the occurrence of /boot to / . If bootpd silently translates a relative path into an absolute one, that sounds like a bug against bootpd. Please use the bug reporting system to file a bug, then. As a workaround, you could configure bootpd to send the path "/boot/rescue2200prep.bin" to the client, which will be allowed by the tftpd server. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Permission policy
Radovan Garabik <[EMAIL PROTECTED]> writes: > On Thu, Mar 16, 2000 at 01:43:22AM +0100, Bernd Eckenfels wrote: > > BTW: there is a idea for settig groups for console access to devices > > like cdrom, floppy, sound, mic, cam... so each user who logs into the > > sonsole will get added to that groups, then your program does not need to be > > sgid anyrthing, which is bad anyway since everybody even on networked > > terminal could start it. > > I am by setting all linux installations this way: > I add this line to /etc/security/group.conf: > login;tty?|tty??&!ttyp*;*;Al-2400;floppy, audio > and configure pam to use it. This has a trivial "attack". Once someone logs in to the console, he is a member of the floppy group, therefore he can do the following: cp /bin/sh ~ chgrp floppy ~/sh chmod g+s ~/sh And later when he logs in through the network, he simply runs ~/sh to regain access to the floppy group. (of course, this attack can be prevented using mount options to disable setgid executables on all filesystems where users have write access) - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: WNPP
Brian Almeida <[EMAIL PROTECTED]> writes:
> ...or maybe not. It's got cryptographic hashing algos (tiger, sha1, etc), so
> I probably can't package it due to wonderful US laws. Drat.
So dpkg must be moved to non-us because it contains an implementation
of a cryptographic hashing algorithm (MD5)?
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Mozilla PSM (https support)
Joseph Carter <[EMAIL PROTECTED]> writes:
> Note that Netscape 4.75 is in main.
Since when?
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package JDE (Emacs Java Development Environment)
Hello Debian developers and WNPP maintainer, I intend to package the Emacs Java Development Environment (JDE) which is an elisp package that interfaces to the Java Development Kit, and makes Java programming a little more comfortable. JDE is currently listed in the "Programs that aren't available yet in Debian" section of the WNPP. More information can be found at http://sunsite.auc.dk/jde/ Package: jde Status: install ok installed Installed-Size: 423 Maintainer: Ruud de Rooij <[EMAIL PROTECTED]> Version: 2.0.1-1 Depends: emacs20 | xemacs20-bin Recommends: jdk1.1-dev Suggests: jdk1.1-docdemo Description: Java Development Environment for Emacs or XEmacs The Java Development Environment (JDE) is an Emacs Lisp package that interfaces Emacs to third-party Java application development tools, such as those provided by JavaSoft's Java Development Kit (JDK). The result is an integrated development environment (IDE) comparable in power to many commercial Java IDEs. Features include: * source code editing with syntax highlighting and auto indendation * compilation with automatic jump from error messages to responsible line in the source code. * run Java application in an interactive (comint) Emacs buffer * integrated debugging with interactive debug command buffer and automatic display of current source file/line when stepping through code * browse JDK doc, using the browser of your choice * browse your source code, using the Emacs etags facility or a tree-structured speedbar. * supports latest version of JavaSoft's Java Development Kit * runs on any platform supported by Emacs and Sun's Java SDK (e.g., Win95/NT and Solaris) * easily and infinitely customizable * works with FSF Emacs and XEmacs -- Ruud de Rooij [EMAIL PROTECTED] http://sepc.twi.tudelft.nl/~derooij/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package JDE (Emacs Java Development Environment)
On 1998/06/19, James Troup wrote:
> [EMAIL PROTECTED] (Ruud de Rooij) writes:
>
> > Package: jde
>
> [...]
>
> > Depends: emacs20 | xemacs20-bin
>^^
>
> Why? We run JDE on Emacs 19.34 here in the department just fine.
According to the requirements as listed on http://sunsite.auc.dk/jde/, to
get JDE to work with [x]emacs 19.x, requires additional and updated elisp
packages, but JDE works out-of-the-box for [x]emacs 20.x.
> > Recommends: jdk1.1-dev
> \begin{just checking}You realise, of course, this puts it in
> contrib?\end{just checking}
Yes, I do realize that. I think a Suggests type dependency is too weak
here since a significant amount of the funcationality of JDE would be lost
if jdk1.1-dev wouldn't be installed.
Greetings,
Ruud.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
--
Ruud de Rooij
[EMAIL PROTECTED]
http://sepc.twi.tudelft.nl/~derooij/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PGP in the US (Re: formal documents)
On 1998/10/04, [EMAIL PROTECTED] wrote: > Kikutani Makoto writes: > > Yes, my PGP is an international version which was built in Japan, and I > > brought it in my laptop. > > The international version infringes the RSA patent and so the owner of the > patent (PKP?) could theoretically sue you for using it in the US. All they > could get is an injunction ordering you to stop, though. There is no real > chance that they would bother. If you are feeling paranoid, delete your > international version and install the US one. > > > But of course I can't prove it. > > There is no reason why you would need to do so. The munitions export laws > (unrelated to the patent issue) forbid the export of strong pgp from the > US, regardless of its origin. You are safe from those as long as you stay > in the US. Theoretically, you should delete pgp from your laptop before > you take it home. I seem to recall that transfer of cryptographic software to a non-US citizen is already considered export in the US. IANAL. - Ruud de Rooij. -- Ruud de Rooij [EMAIL PROTECTED] http://sepc.twi.tudelft.nl/~derooij/
Re: Call for mascot! :-)
On 1999/01/28, Anderson MacKay wrote: > On Thu, 28 Jan 1999, Chris Waters wrote: > > 1. Dragon (well-liked choice on IRC) > > 2. Octopus (my own suggestion) > > 3. Monkey > > 4. Ant > > 5. Bee > > Ants and Bees are probably the easiest to do cool 3d raytracings with, if > that's any thing. I'd have to take ants. Lots of little creatures doing > their own thing, but cooperatively building something really cool as a > result. Hmmm, that sounds familiar. :) In that case, we should name our releases after characters from "a Bug's Life" :-) - Ruud de Rooij. -- Ruud de Rooij [EMAIL PROTECTED] http://sepc.twi.tudelft.nl/~derooij/
Re: jdk1.1 grave bug (Was: List of bugs that *must* be fixed before releasing Slink
On 1999/02/01, Stephane Bortzmeyer wrote: > On Monday 1 February 1999, at 10 h 54, the keyboard of > [EMAIL PROTECTED] (Dale E. Martin) wrote: > > java was not found in /usr/lib/jdk1.1/bin/../bin/i686/green_threads/java > ... > > The binary is somehow actually missing, and I've not done anything weird as > > far as I know. The other folks who are saying is doesn't work have the > Sam's message indicates that the i686 directory is used. Since the name inclu > des a ".." could it be a symbolic link problem? Sam, any symlink in /usr/lib/ > jdk1.1/bin? Any chance when deinstalling jdk and reinstalling? > > It works for me (tm): The binaries disappear if you upgrade from an older version of the JDK. Previously, they were installed in .../i586/ and i686 was a symlink to that. Currently, they are installed in .../i686/ and i586 is the symlink. dpkg does not handle that case very well (i.e., not at all) Something similar happened to X as well during the hamm freeze, IIRC. A purge and reinstall will fix this problem, though. - Ruud de Rooij. -- Ruud de Rooij [EMAIL PROTECTED] http://sepc.twi.tudelft.nl/~derooij/
Re: Move proftpd to contrib
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Thu, Sep 16, 1999 at 10:42:36PM -0500, John Goerzen wrote:
> > This package has been a major source of serious security bugs and
> > indicatiosn are that it will remain as such. Our Policy states that
> > packages that are not sufficiently free of bugs to meet our standards
> > should not be in main and should be moved to contrib. I therefore
>
> I don't think policy says that contrib is a dumping ground for
> crap packages. Can you point out which part to me please?
2.1.3. The contrib section
--
Every package in "contrib" must comply with the DFSG.
Examples of packages which would be included in "contrib" are
* free packages which require "contrib", "non-free", or "non-US"
packages or packages which are not in our archive at all for
compilation or execution,
* wrapper packages or other sorts of free accessories for non-free
programs,
--->* packages which we don't want to support because they are too
---> buggy, and
* packages which fail to meet some other policy requirements in a
serious way.
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: emacs and anacron on slink
Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes: > Since I removed emacs 19 anacron sends me mail every day > in which it says : > File /usr/lib/emacs/19.34/i386-debian-linux/movemail registered but not > installed > > and since I removed all emacses from my computer there is > another line in everyday mail : > File /usr/lib/emacs/20.3/i386-debian-linux-gnu/movemail registered but not > installed > > I think this is a bug in emacs uninstalation script Indeed. Please remove the offending lines from /etc/suid.conf yourself. > I also think no editor should be privileged anyhow by debian > Everyones favorite editor is very intimate matter and > forcing anyone to use particular is breaking of users privacy Why do you think Debian is forcing you to use one specific editor? - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Which gcc builds potato?
Dale Scheetz <[EMAIL PROTECTED]> writes:
> So, what, if anything, is being built with egcs?
Nothing, since egcs does not exist in the distribution anymore.
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: gnome-utils in slink
Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
> gpenguin should fly so CENTER of penguin1.png is
> at the mouse pointer not UPPER-LEFT corner
>
> gw gives me :
> ** WARNING **: Could not open help topics file NULL
Please use the bug tracking system (see http://bugs.debian.org) to
report bugs instead of sending them to the developers discussion
mailing list.
- Ruud de Rooij.
--
ruud de rooij | [EMAIL PROTECTED] | http://ruud.org | http://weer.moonblade.net
