Future security problem (was Re: be careful with Replaces, please)
Greg Stark writes: We've got be be a little more careful with the Replaces header. I just installed the libc6 version of comerr, and dpkg helpfully deinstalled e2fsprogs. I can see a security problem with this. Lets jump ahead several months when we have deity working. A user points deity to several sites, some providing a bunch of debs that they have created but don't want to be part of the main distribution. Now they upload a new package, call it libc6-big version number that replaces all kinds of packages, and whatever else they want to do. Most of you will dismiss this as they deserved what they got at this point, but I think we should start worrying about these possibilities. How about prompting the user before deleting a package because it was replaced (of course we need to think about non-interactive installations too). I'd also be interested in some kind of verification, so I can accept all packages put together by some maintainer, and the maintainers on the debian keyring, but no one else. We have time to think about this, but the sooner the better in my opinion. Thanks, Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Trovalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
Brandon Mitchell [EMAIL PROTECTED] wrote: I can see a security problem with this. Absolutely: pre/post inst/rm scripts run as root, this is the security problem to dwarf all other security problems. Our defense is a wide audience. The more people we have looking at the system, the better our chances are of noticing something untoward. Basicaly, it's an application of you can't fool all the people all of the time, and real security is a social problem more than a technical problem. Also, it's a given that the closer you are to the cutting edge, the less security you have. We'd do better here if some security-concious folks were auditting our packages in controlled burn-in environments as well as in wide-open gauntlets. However, this is a job for someone with the need and the resources (e.g. governments -- the more the merrier). We'd also need some way of keeping the security folks from squelching future development... All of this smells like phd-thesis or research material, to me. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
On 30 Nov 1997, Greg Stark wrote: I know i should install a new e2fsprogs, obviously. I was just suggesting we should find some way to avoid the default action being to deinstall packages that aren't really being completely replaced. I'm not sure what better to do though. In this particular case, e2fslibsg recommends e2fsprogsg would probably be nice, though I know it's not always that simple; I imagine the general case would be messy, like, e2fslibsg would have to recommend e2fsprogsg if and only if e2fsprogs was previously installed. I suppose it's philisophically bad for a library to know what uses it. (I'll duck out of this now since I'm over my head.) Incidentally, the g suffix on packages indicates they're a libc6 package. I think I got confused by xlib6g. Usually it's only needed on libraries since you might want both libc6 based and libc5 based libraries installed at the same time. This I understand, I'm still using sLirp compiled for libc4. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Deb 2.0 testing process
Brandon Mitchell [EMAIL PROTECTED] writes: The testers are starting to think about how to organized the 2.0 testing effort. One idea that the testers seemed to like is to create a checklist for checking each package. [details snipped] Excellent! If this comes off, I think it will probably work very well; certainly, it seems to be the way to go. Apart from anything else, having such a checklist will hopefully encourage the developers to check their packages against it before they release them! OTOH, if you make this too simplistic, then I fear you're going to miss most of the problems: I'm sure the majority of developers do test their packages at least a little bit before releasing them. I certainly do. But one of the things Debian has been bad at in the past is getting a distribution which is consistent within itself, and that is something that these checklists won't address. That little niggle aside -- and I'm sure you will be doing other things than just this -- the testing made a big difference to Bo, and it sounds like it's going to be even better for Hamm. Keep it up! Andy -- Andy Mortimer, [EMAIL PROTECTED] http://www.poboxes.com/andy.mortimer PGP public key available on key servers -- I found myself alone, alone above a raging sea That stole the only girl I loved and drowned her deep inside of me. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT
Congratulations on a good decision, Bruce. :) DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT The Debian GNU/Linux Distribution is getting enough donations now that we can support the development of free software. We use most donations for our own work, but some outside projects are worth funding. Debian is awarding $1000 to the GNOME project (see www.gnome.org). They are building a GUI desktop for Linux and Unix systems. In addition, we have granted GNOME use of Debian's servers so that they need not spend any of the $1000 on internet services. We chose the GNOME project because: 1. They are using 100% free software. 2. They have an excellent design and have shown rapid progress. 3. They are doing the right thing, and that should be rewarded. This won't be the last Debian grant. To qualify for support, all of the software used by a project must conform to Debian's Free Software Guidelines. These assure that the software is free for use by _anyone_, not just Debian. If you're not familiar with Debian GNU/Linux, check out our web site http://www.debian.org/ . Many Thanks Bruce Perens Debian Project Leader . QUIT -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . - Paul J Thompson --- A raccoon tangled with a 23,000 volt line today. The results blacked out 1400 homes and, of course, one raccoon. -- Steel City News -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT
Oops, I left an SMTP command at the end of that message. Did you see it? Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Deb 2.0 testing process
In article [EMAIL PROTECTED] you wrote: : This list can be added to by anyone. What I'd like to ask for now is any : comments on this. A checklist like this is a good idea, particularly if it eventually provides the list of things that initially need to be part of a regression suite for the package. The downer is that if you don't get working on a regression suite for each package, testing a couple thousand packages against non-null checklists seems like it could take a wickedly long time... particularly if, as I suspect, many packages need to get revisioned during the testing interval to fix bugs. Bdale -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT
On 1 Dec 1997 [EMAIL PROTECTED] wrote: Oops, I left an SMTP command at the end of that message. Did you see it? Yes. Will -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | | http://www.cis.udel.edu/~lowe/ | -- | You and I and George went strolling through the park one day | | and then you held my hand as if to say, I love you. | | Then we passed a brook, and George fell in and drowned himself| | and floated out to sea, leaving you alone with me. | || | -- As sung by Red Kelly, on | | Stan Kenton/Live at the Las Vegas Tropicana | -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT
At 04:27 AM 1/12/97 -, [EMAIL PROTECTED] wrote: Oops, I left an SMTP command at the end of that message. Did you see it? Yes, we did :-) I hate these me too messages. I wonder how many people will reply with yes, we did now grin. You shouldn't have said anything, Bruce :-) Regards -- This message is Copyright (C) 1997 by Karl Ferguson Tower Networking Pty Ltd Tel: +61 8 9456 [EMAIL PROTECTED] t/a STAR Online Services Fax: +61 8 9455 2776 ICQ UIN: 2287428 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Fakeroot error (was Re: Unidentified subject!)
FAKEROOT: after stat, failing?: known=0, stat=d:i=(2051:196739), mode=0100664, nlink=1, I've seen this too (on an x86 hamm system) but I forget if I filed it. Running fakeroot alien on a .tar.gz file triggered it; the .tar.gz file happenned to have pathnames longer than dpkg can handle [grumble grumble bug that never dies grumble grumble] but I don't know that that was actually related... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bugs...
Send it to [EMAIL PROTECTED], with a package: and version: line in the body, just like the website says (somewhere.) seems to be at fault. My /usr/include/X11 was empty, so the cp failed Any idea how it *got* that way? Were you upgrading (from what) or installing fresh? [you can look at /var/lib/dpkg/status.yesterday.* for hints, if you don't remember...] I've seen a couple of problems with packages that have the wrong install directory causing directories that *should* be symlinks to get created, if they get unpacked before xbase does -- so you might look for what *other* packages you have (try dpkg -S /usr/include/X11 and see if it says something other than xbase, for example.) The bug, in that case, is in the other package, but we still need to find it... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
perl module packages: why do they exist?
I don't understand why the debian developers are undertaking to maintain debianified version of Perl modules when the CPAN module and its mechanisms are so much more native to Perl, are well-supported by the Perl community, etc? Besides, Perl already has it's own automated upgrade system (CPAN), it's own configuration mgmt system (Config), and it's own automated compilation and installation system (MakeMaker). It seems like making work for no good reason. Let all the Perl modules be installed by way of CPAN. You could even have simple scripts driving installation. I really feel we'd have a better and more supported Perl product that way. .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Notice of intent to package...
-BEGIN PGP SIGNED MESSAGE- I am working on the following packages: Orphaned packages: macutils mcvert opie New packages: hfs-fs (Macintosh HFS kernel module) zile (Emacs clone) For the time being, the packages (except for hfs-fs) are only available at: ftp://ftp.espy.org/pub/debian/. - -- Joel Espy Klecker mailto:[EMAIL PROTECTED]http://www.espy.org/ Apple Flavored Unix (http://www.espy.org/apple-flavored-unix/): A meta-index of unix-like OSes for macs and mac clones. -BEGIN PGP SIGNATURE- Version: PGP for Personal Privacy 5.5 iQCVAwUBNIJbfAoYIlYX1XaBAQFV6gP6ArZz1BJhKSAhc5Gz/NZtpcb/0KxVoJkR M7lH8ZXWQn9C/DfhlJtXq9lr/f4ZCf5X44E1bdizxw/Di52cdlN8AfHM+QsowIws 62HGlokponLQJRDOyrHjw8VWemzvJZC4y/pylNBXOkufTgdAku7ZS9lfhcvqOq2y xMSZCn6q1IY= =zJyN -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
Yann Dirson wrote: Greg Stark writes: We've got be be a little more careful with the Replaces header. I just installed the libc6 version of comerr, and dpkg helpfully deinstalled e2fsprogs. That's perfectly normal if you previously had e2fsprogs = 1.10-6, which does contain libcom_err ! Package: comerr2g Version: 1.10-8 Replaces: e2fsprogs, comerr2 (= 1.10-7) Depends: libc6 Conflicts: e2fsprogs, comerr2 (= 1.10-7) You should probably install e2fsprogsg to replace e2fsprogs. The behaviour you're wanting is provided by Replaces _without_ Conflits. Having listed e2fsprogs in the Conflicts, you're removing automatically it without forcing the install of the new e2fsprogsg. If you must Conflict with e2fsprogs, then you should add e2fsprogsg to the Depends to force installation of it (if it conflicts with its libc5 version, you don't need to Conflict with it). Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: perl module packages: why do they exist?
Hi, Adam == Adam P Harris [EMAIL PROTECTED] writes: Adam I don't understand why the debian developers are undertaking to Adam maintain debianified version of Perl modules when the CPAN Adam module and its mechanisms are so much more native to Perl, are Adam well-supported by the Perl community, etc? Besides, Perl Adam already has it's own automated upgrade system (CPAN), it's own Adam configuration mgmt system (Config), and it's own automated Adam compilation and installation system (MakeMaker). Adam It seems like making work for no good reason. Let all the Perl Adam modules be installed by way of CPAN. You could even have simple Adam scripts driving installation. I really feel we'd have a better Adam and more supported Perl product that way. How do I remove packages using cpan? Can I downgrade to a lower version? make sure that all modules I have installed are upgraded? Ensure that the perl modules that are available for auto handling have been looked over by an expert, *for the Debian system* specifically? Can other packages, that need modules, determine that they have been installed on my machine? Can I hold a module to a the current version, even if new versions are available, while updating the rest? I think you underestimate the work a systems integrator does. I am planning on creating a make-ppkg package that shall create perl packages just like make-kpkg creates kernel-image packages, but I'm still recovering from a disk crash, and I have other commitments at the moment. manoj -- After winning the decathlon, Jim Thorpe was told by the King of Sweden, You are the world's greatest athlete. Thorpe replied, Thanks, King. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: perl module packages: why do they exist?
Adam I don't understand why the debian developers are undertaking to Adam maintain debianified version of Perl modules when the CPAN Adam module and its mechanisms are so much more native to Perl, are Adam well-supported by the Perl community, etc? [Manoj Srivastava [EMAIL PROTECTED]] How do I remove packages using cpan? Can I downgrade to a lower version? I'm not sure but I don't think so. Probably, if you can think of some cases why you need this functionality, you could ask the CPAN maintainer to update these. make sure that all modules I have installed are upgraded? install r in CPAN Ensure that the perl modules that are available for auto handling have been looked over by an expert, *for the Debian system* specifically? Well, no, but what I was saying is that you could easily have package installing either custom debian bundles or individual modules as seen fit. Can other packages, that need modules, determine that they have been installed on my machine? Sure, although not with dpkg's standard method. It's pretty trivial to determine from Perl availability and the current version. As I'm sure you know. Can I hold a module to a the current version, even if new versions are available, while updating the rest? Sure. Just as easily using a perl native installer like CPAN as you'll have doing it by hand. And once you've got it going, it'll be a lot easier to maintain. In fact, you wouldn't have to maintain it at all, let the Perl maintainers maintain it. I think you underestimate the work a systems integrator does. No, I'm just trying to minimize the work a debian package maintainer has to do. I am planning on creating a make-ppkg package that shall create perl packages just like make-kpkg creates kernel-image packages, but I'm still recovering from a disk crash, and I have other commitments at the moment. Well that will help, but again, when you have CPAN and bundles and all that, why bother? Manoj, I just think you should talk to perl-porters about your issues and concerns and see what they have to recommend. IMHO, it's pretty rare that I need to hold on a Perl module version, or that I'm hitting serious configuration mgmt issues with the modules. And since MakeMaker already has it's own dependancy and x-platform building system, it seems wasteful to replicate that. And I know as a user that the version lag impose by debian can be annoying. .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: not a first amendment question
On 30 Nov 1997 02:13:23 -, [EMAIL PROTECTED] said: bruce Good healthy sex is fine. The stuff I objected to had nothing bruce to do with sex, it concerned acts only a mentaly ill person bruce would carry out. Ummm... careful with those generalisations. I've gone through some incarnation of the purity test with some friends (on paper) and I don't recall anything *that* weird in it. I remember we had fun filling it out, though :-) What I do find frightening is that you people are censoring an *optional* package that is, in addition, extremely small in size. Why? Because is has a big, humorous sex quiz in it. We can't have that, now can we. Sigh, someday I'll probably understand the American mentality when it comes to sex (and equating it with violence on the ooo, bad stuff scale). //Petri -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: purity package
On no-time-field?, 30 Nov 1997, Kai Henningsen wrote: Sorry. Quake or Doom are silly and stupid; they certainly aren't fun. Normally it's silly to assume your own experience is everyone else's. In a case like this, when it is blatantly obvious that a very large number of people find both games fun, it's absurd. -- David/Kirsty 'Gotterdammerung' Damerell. [EMAIL PROTECTED] CUWoCS President. http://www.chiark.greenend.org.uk/~damerell/ Hail Eris! |___| So you think you can stone me and spit in my eye? So you think |___| | | | you can love me and leave me to die? Queen: Bohemian Rhapsody. | | | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEBIAN ANNOUNCES $1000 GRANT TO GNOME PROJECT
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Oops, I left an SMTP command at the end of that message. Did you see it? Yep I was tempted to answer with just :wq quit EXIT ^] ^C eat flaming death :) Mike. -- Miquel van Smoorenburg | Studying to be a technomage * [EMAIL PROTECTED] | May you live in interesting times -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
debian-private archives
Hi, as my email is still not added to debian-private (I don't want to bug anyone) and it's election time I would like to ask some kind soul to send me the archives of the last two months of debian-private (need some background material for voting :-) If possible please in the next couple of days so I can read before Friday. Thanks in advance. Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: perl module packages: why do they exist?
Manoj Srivastava [EMAIL PROTECTED] wrote: How do I remove packages using cpan? Can I downgrade to a lower version? Adam P. Harris [EMAIL PROTECTED] wrote: I'm not sure but I don't think so. Probably, if you can think of some cases why you need this functionality, you could ask the CPAN maintainer to update these. About two months ago, I upgraded a CPAN bundle on a production server. Two interesting things happened: (1) perl itself got upgraded, and (2) wais got upgraded. That perl got upgraded would be a problem for any extensions that link with a specific perl version which is NOT integrated with the CPAN stuff. That wais got upgraded was a serious problem, as the upgraded wais did NOT work on this system, and (what with all the other changes) it took about 16 hours to isolate and revert the change. This on a system hosting several dozen vanity web servers (about 8 of which used wais). Not a good way to make people happy. Also, there are CPAN modules whose installation has a step which says something to the effect of you must read the README. The DBD stuff that Tim Bunce wrote comes to mind. We can do a lot better. On the other hand, I have one production bo system (not the wais server mentioned earlier -- that was a sparc running solaris) which is running on a CPAN installed perl and cpan modules for everything. On this system, I've got perl on hold and I've documented that perl upgrades must occur through CPAN. Incidentally, because the perl configuration info isn't tracked adequately for CPAN, I had to completely erase the perl installation partway through installation of the bundle to get the new perl stuff to work. Essentially, if you use CPAN, you're always working with UNSTABLE. But this is a real problem (what if you must have a package that's only available through CPAN), and I'd like to see Debian and CPAN interoperate better. The ppkg stuff I saw proposed here may just do the trick (especially if there's options equivalent to each thing on the CPAN command line). -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian / GNU Linux logo?
Hi! Just a little note on the chosen new logo: It says Debian / GNU Linux. Isn't the project called Debian GNU/Linux? Just wondering... Otherwise, the logo is very nice. -- Simon Kågedal [EMAIL PROTECTED] - Homepage: http://www.sdf.se/~simon/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
sed and electric fence
Okay, I goofed up somewhat with sed by releasing a package which pre-depended on eletric fence. Sorry about that. But please: STOP reporting bugreports on this! I've fixed it and the new package has already been installed on the FTP site. Thanks, Wichert. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Signing PGP key
I am planning to become a developer in the near future. To do so, I will require my PGP key to be signed by at least one developer, but I am unsure of the procedure to do this. Is it necessary to physically meet the signqing developer? If so, I would like to hear from developers who would be willing to sign my key who are located reasonably near me. I live in Palm City, FL, which is just outside of Stuart, which, in turn, is about 30 miles north of West Palm Beach Bob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New package proposal: xpilot-extra
In the debian distribution, I miss a collection of xpilot utilities, apart from the game itself. Therefore I have the ambition to create a debian package, collecting several such programs into a complementary xpilot-extra package. My main concern is, should I create one package for each utility (they are pretty small) or should I go on and collect them into one package? Regards, Pontus -- Pontus Lidman, [EMAIL PROTECTED], http://www.ctrl-c.liu.se/~pontus Computer Science Engineering student, Implementor on tyme.envy.com 6969 Java: the elegant simplicity of C++ and the blazing speed of Smalltalk _ Unsolicited commercial email is subject to an archival fee of $400. See http://www.ctrl-c.liu.se/~pontus/mail.html for more info. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Signing PGP key
It is always best to install the xearth package to find Debian developers close to you. Of hand, some developers do live in Florida: I live in Palm Beach, there is one in Miami, and a redneck in Hee Haw junction who spends the night outside 7-11, buying lottery tickets while searching for black helicopters (an inside Debian joke). There may be more developers in Florida. We could arrange for signing pgp keys, if you like. -- Ioannis Tambouras [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
Brandon Mitchell wrote: I can see a security problem with this. Lets jump ahead several months when we have deity working. A user points deity to several sites, some providing a bunch of debs that they have created but don't want to be part of the main distribution. Now they upload a new package, call it libc6-big version number that replaces all kinds of packages, and whatever else they want to do. Most of you will dismiss this as they deserved what they got at this point, but I think we should start worrying about these possibilities. How about prompting the user before deleting a package because it was replaced (of course we need to think about non-interactive installations too). I'd also be interested in some kind of verification, so I can accept all packages put together by some maintainer, and the maintainers on the debian keyring, but no one else. This is indeed a problem! You will find that the deity design already addresses this problem in the following ways 1) One option the user has is to display (most of) the package's headers (Replaces being one of them) in a tabbed window on the selection screen. If the user cares to, they can see what the package will replace if installed. 2) More importantly, deity has a verification phase where all packages to be installed/deleted/replaced/whatever, are shown to the user. The user has a chance to see what exactly is going to happen before they press the OK button. Is that sufficient? Behan (UI designer for the Deity project) -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Deb 2.0 testing process
Andy Mortimer [EMAIL PROTECTED] wrote: OTOH, if you make this too simplistic, then I fear you're going to miss most of the problems: I'm sure the majority of developers do test their packages at least a little bit before releasing them. I certainly do. But one of the things Debian has been bad at in the past is getting a distribution which is consistent within itself, and that is something that these checklists won't address. This can be dealt with by creating a check list based on the policy manual (the first think to check in *any* package should be its compliance with the current policy). Such a check list would be very useful even for developers, since people like me, that are not completely aware of the last policy discussions may very well miss some policy aspects when releasing a package. Regards, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[OFF-TOPIC] Re: not a first amendment question
Petri Wessman wrote: Sigh, someday I'll probably understand the American mentality when it comes to sex (and equating it with violence on the ooo, bad stuff scale). When you do, let me know (and I live there - thought I'm not one) :) Stephen --- Normality is a statistical illusion. -- me -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
On Sun, 30 Nov 1997, Brandon Mitchell wrote: I'd also be interested in some kind of verification, so I can accept all packages put together by some maintainer, and the maintainers on the debian keyring, but no one else. I had exactly the same idea in the previous KDE/virtual package discussion on debian-private. I suggest that we add a new control field to our packages called Origin: (or similar). This could either be set to SPI or Debian, for example. Then, all Debian packages should be signed with some PGP key (either only one key for the whole system or by the maintainer's key). dpkg could have its own keyring. Whenever dpkg installs a package, it checks the key against its keyring. If the key is not found in the keyring, dpkg stops installing (this can be overriden by some --force option). The default keyring would probably be the developers keyring. The sysadmin could then add new keys of persons/organziations which he/she trusts to that keyring. In addition, the origin tag could be used for special dependencies. For example, the Debian KDE packages can conflict with KDE's KDE packages (which happen to have the same package names). Comments? Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
perl module packages: why do they exist?
[You ([EMAIL PROTECTED])] About two months ago, I upgraded a CPAN bundle on a production server. Two interesting things happened: (1) perl itself got upgraded, and (2) wais got upgraded. Huh??? Perl itself? I don't think this is possible. [...] Also, there are CPAN modules whose installation has a step which says something to the effect of you must read the README. The DBD stuff that Tim Bunce wrote comes to mind. We can do a lot better. [...] Essentially, if you use CPAN, you're always working with UNSTABLE. Well, of course, I've maintained perl manually on 2 production servers for more than 2 years now, and have never had a problem. I just wait until s/w is a couple of weeks old before upgrading them. I can see your point and I can see the reason for having official packages and blessed versions of perl modules and all that. I guess it's kinda a moot issue since if I feel like it I can always maintain my modules outside of pacakage control, say, using CPAN. One thing is gonna burn me is if a package wants, say, perl lwp installed, and I did it in /usr/local/lib/perl/site_perl (i.e., w/ CPAN), the package won't know about that and I'd have to force it to install. Don't know if there's any solution to that. [Manoj said] I am planning on creating a make-ppkg package that shall create perl packages just like make-kpkg creates kernel-image packages, but I'm still recovering from a disk crash, and I have other commitments at the moment Seems to me it'd be better to mess with MakeMaker so you could make debian packages right outta the module w/o additional help. Should be doable. BTW, is anyone working on any Debian-specific Perl modules? .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bugs...
Quoting Mark W. Eichin ([EMAIL PROTECTED]): seems to be at fault. My /usr/include/X11 was empty, so the cp failed Any idea how it *got* that way? Were you upgrading (from what) or installing fresh? [you can look at /var/lib/dpkg/status.yesterday.* for hints, if you don't remember...] Actually, I have no idea how it got like that. It first ran into problems when I tried to go to 3.3.1-1 (same symptoms, crashed on the cp.) My best guess is that it might have gotten partway through and failed for some reason, leaving the system in an intermediate state. But it happened a couple of weeks? ago, so I don't know exactly. Since everything was still working, it was on the back burner. There obviously aren't any status logs from that far back. I did notice something else last night that might be related... nedit installed its files to /usr/X11/bin, which didn't previously exist. I can't remember if there was supposed to be a symlink from /usr/X11 into the X11R6 tree. The result is a /usr/X11/bin which contains two files, and a /usr/X11 that's owned by nedit. Is this related? Unfortunately, this is the only debian machine that I run that has X installed so I can't compare with another system. I've seen a couple of problems with packages that have the wrong install directory causing directories that *should* be symlinks to get created, if they get unpacked before xbase does -- so you might look for what *other* packages you have (try dpkg -S /usr/include/X11 and see if it says something other than xbase, for example.) The bug, in that case, is in the other package, but we still need to find it... It looks like /usr/include/X11 is owned by xlib6g-dev. Weird. If I had to guess, I might venture that this got out of wack during the transition from bo to hamm (there were a lot of conflicts between the existing libraries, especially X, and the new libs.) This might have been cleaned up in the past two months. Mike Stone -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: perl module packages: why do they exist?
Raul Miller [EMAIL PROTECTED] wrote: About two months ago, I upgraded a CPAN bundle on a production server. Two interesting things happened: (1) perl itself got upgraded, and (2) wais got upgraded. Adam P. Harris [EMAIL PROTECTED] wrote: Huh??? Perl itself? I don't think this is possible. Take a look at TIMB/perl5.004_04.tar.gz It is automatically brought in when you install something in CPAN that requires a more recent perl version that what you have. Of course, you can bail out of the install at that point, but that's not the issue here. In my opinion, once we've evolved a good cpan-debian packager, we should integrate it with the CPAN module so that it uses this mechanism to build, test and install cpan modules. Presumably, it should also archive the installed package somewhere (at least as an option), and manage minor revision numbers automatically. Further, it's going to be essential that we get dependencies *right* for the part of the system which can be managed via CPAN. This is going to be tricky -- since dependency information in cpan is embedded in makefile rules, we'll probably have to implement a shared database so that as people use the system we accumulate such information. [This might also be a fertile ground for people to get together when thrashing out problems with fringe packages.] CPAN is just too big, and too useful, to ignore. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: purity package
[EMAIL PROTECTED] wrote on 30.11.97 in [EMAIL PROTECTED]: On Sun, Nov 30, 1997 at 02:07:00PM +0200, Kai Henningsen wrote: .. There are some valid arguments why showing violence is bad. No there ain't. There are some valid arguments why people who can't control their violent tendencies/sexual urges should be taken out and shot. (sorry, couldn't resist) I didn't say I agreed with these arguments. (Well, with some of them, maybe.) I also didn't say they were enough to ban something. I'm not convinced they are. It's about freedom, and I used to think Debian was free too. Metoo. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
On Mon, 1 Dec 1997, Christian Schwarz wrote: The default keyring would probably be the developers keyring. The sysadmin could then add new keys of persons/organziations which he/she trusts to that keyring. Comments? Err... yes. Am I the only one seeing a bit of a problem here? (Or am I missing something I should know?) That is, PGP is non-US. To be able to put PGP in the main distribution, the master FTP site has to be moved off the US. I don't have a problem with that, as I don't live in the US, but I understand this can be quite an annoyance for many people. Unless of course, the code that *checks* the PGP signatures can be put into the main distribution, which I think is possible, since what funny US laws forbid is the export of encryption technologies -- or something like that -- and PGP signature *checking* doesn't fall into this category, AFAIK. As an aftertought... I realized this problem existed a few months ago when I almost trashed a system I was trying to build a package on... basically, I did something really stupid in a preinst script, and in fact, that's the reason I'm using deb-make now. It protects me from myself ;-) (no, really, I want to learn package building, and it's easier to figure out the not-so-obvious-right-now problems this way) Marcelo Magallón -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
searching Orn E. Hansen
does anyone know where i can contact Orn E. Hansen. he was the developer of dialdcost, which i would like to take over. his email-adress [EMAIL PROTECTED] unfortunately bounces. thanks, jjm -- Juergen Menden at work: [EMAIL PROTECTED] tel: +49 (89) 289 - 22387 private: [EMAIL PROTECTED] tel: +49 (89) 89 712 743 Support the anti-Spam amendment. Join at http://www.cauce.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
X11 and FDD
I use Debian 1.3.1 and was wondering, which package in the msdos-i386 directory is X11. Also, how do I get access to my floppy drive in the text-shell? Please respond. Thank you. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: purity package
Why do we need to take out the offensive part of the package when we already have an example of how to package offensive material. The fortune and fortune-mod package asks during installation if the offensive material should be removed. Why can't we just follow the policy set forward by fortune. Alex -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[Mailer-Daemon@ods.com: Returned mail: Local configuration error]
Anyone know what's up with David Engle's email address? - The following addresses had delivery problems - [EMAIL PROTECTED] (unrecoverable error) - Transcript of session follows - 553 icarus.ods.com config error: mail loops back to myself 554 [EMAIL PROTECTED]... Local configuration error -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: purity package
[EMAIL PROTECTED] (David Damerell) wrote on 01.12.97 in [EMAIL PROTECTED]: On no-time-field?, 30 Nov 1997, Kai Henningsen wrote: Sorry. Quake or Doom are silly and stupid; they certainly aren't fun. Normally it's silly to assume your own experience is everyone else's. In a case like this, when it is blatantly obvious that a very large number of people find both games fun, it's absurd. You might think about the mail I was replying to in that context. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: perl module packages: why do they exist?
[EMAIL PROTECTED] (Adam P. Harris) wrote on 01.12.97 in [EMAIL PROTECTED]: [You ([EMAIL PROTECTED])] About two months ago, I upgraded a CPAN bundle on a production server. Two interesting things happened: (1) perl itself got upgraded, and (2) wais got upgraded. Huh??? Perl itself? I don't think this is possible. I decided recently to test CPAN.pm. It suggested updating CPAN. Sure, thinks I, go ahead. It then proceeds to pull down a completely new perl and tries to build it (fails pretty spectacularly, also asks me all sorts of weird questions in the process). And each time I start CPAN.pm, it annoys me with info about the newer version. This is _bad_. BTW, is anyone working on any Debian-specific Perl modules? We have dpkg-perl, don't we? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
Christian Schwarz wrote: I suggest that we add a new control field to our packages called Origin: (or similar). This could either be set to SPI or Debian, for example. Then, all Debian packages should be signed with some PGP key (either only one key for the whole system or by the maintainer's key). dpkg could have its own keyring. Whenever dpkg installs a package, it checks the key against its keyring. If the key is not found in the keyring, dpkg stops installing (this can be overriden by some --force option). The default keyring would probably be the developers keyring. The sysadmin could then add new keys of persons/organziations which he/she trusts to that keyring. Comments? Just to repeat what we already said on a different list, with the actual scheme we have m packages signed by n developer's keys, but only one sign per package. On average, the number of keys to be revoked each year depends on the number of developers. Considering that users are installing from CD that are usually 3/4 months old (but this time we have a 6 month delay), so you can see how one developer key, which is privately handled by the developer, can be kept active as a trusted key because of all the packages signed with that key that are on all the CDs, even if the developer has leaved the project, maybe after a nasty flame (you see how this could easyly happen). He can maybe start signing his own packages with the same key he used on debian, and putting them on sunsite. Developers keys should be used only to make sure that the upload came from the developer in that very moment of the upload itself. To trust packages on a CD we need a scheme that woudn't be seriously affected by normal accidents in the life of the distribution. I proposed that a number of highly trusted people (senior developers, for example) create a certain number of _new_ keys that they will use (one per person) only to create detached certificates to distribute close to the packages. Three to five certificates per package would be enough. (detached because this way the certificates can be done in parallel, on different machines, and _not_ on some public host.) Then dpkg must check all the certificates of each package that it installs, and accept only those who have some level of trust (for example at least 3 out of five, or two out of three) maybe displaying warnings for different levels of trust (all user definible). Users then should be able to add keys from other people, but the keyring we supply should also contain some sort or keys-to-be-rejected, so we can add to that list the keys that we discover have been used to build trojan horses or such things. With this scheme the need to urgently revoke one key would have low possibility to happen, as dpkg could trust packages even when one key is compromised, because the possibility that _all_ keys from different _expert_ people (wo is more likely to follow all the rules for correct handling of private keys) would be compromised at the same time is quite close to zero. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
On Mon, 1 Dec 1997, Marcelo E. Magallon wrote: Am I the only one seeing a bit of a problem here? (Or am I missing something I should know?) That is, PGP is non-US. To be able to put PGP in the main distribution, the master FTP site has to be moved off the US. I don't have a problem with that, as I don't live in the US, but I understand this can be quite an annoyance for many people. We can make it optional. Or just make a version of pgp that always succeeds and prints a warning that it really isn't pgp and that the package has not been checked. The idea is to allow those that can and want to be more secure that ability. Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Logo Page updated
Hi folks! I'm really happy that we finally have a logo for Debian GNU/Linux! I've just updated the Debian logo pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ The pages include all new submittions that I've received since the last logo page, the old logo pages and their feedback pages, a statistic page, and an overview page. The logo development process started in Sep 96. Since then, 66 authors submitted 289 (!) logos, that makes 4.3 logos per author! I received 3496 comments through the feedback pages! Thanks a lot to all the logo authors and to all people that gave us feedback! Cheers, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
