Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Thu, 2008-01-10 at 23:37 -0500, Noah Meyerhans wrote: > On Thu, Jan 10, 2008 at 11:25:07PM -0500, Thomas Bushnell BSG wrote: > > > Except that the security flaw is in the fileserver, which does not > > > involve the kernel module at all and runs fine even without it > > > installed. > > > > Surely. But then the security update shouldn't mention unaffected > > packages! > > All binary packages built from a given source package are updated > together. Yes, this is inefficient when many binary packages are built > from a single source packages. We mention all the binary packages in > the advisory because they're the versions that are going to be installed > by apt* and people are going to want checksums, file sizes, etc. We > don't have any sane mechanism for updating a subset of a source > package's binary packages. Until we do (don't hold your breath) we will > continue to provide all the information we're currently providing. > > Surely you must have wondered in the past why a DSA for xfree86 required > you to install new fonts... No, I was happy to think as you describe: that the assumption is that all binary packages are updated together. But I was just told that this is not actually the point. See, I noted that the posted instructions would *fail* to actually update all the binary packages together, and was told that this is not actually the point. Perhaps instead of defensiveness, the real issue is this: installing upgraded debian packages is not sufficient, in the presence of kernel module source packages, to effect the necessary upgrades. Security announcements should make this clear, and contain correct complete instructions for whichever packages are mentioned. If a security bug were found in the afs client-side package, which is implemented as a kernel module, would the announcement not look just like the one we saw for DSA 1458-1? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Thu, 2008-01-10 at 17:30 -0500, Noah Meyerhans wrote: > On Thu, Jan 10, 2008 at 05:29:18PM -0500, Thomas Bushnell BSG wrote: > > This is not sufficient advice for how to upgrade. Merely installing a > > new version of openafs-modules-source will not build it. Some form of > > m-a invocation as well will be necessary. > > Except that the security flaw is in the fileserver, which does not > involve the kernel module at all and runs fine even without it > installed. Surely. But then the security update shouldn't mention unaffected packages! Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
This is not sufficient advice for how to upgrade. Merely installing a new version of openafs-modules-source will not build it. Some form of m-a invocation as well will be necessary. Thomas On Thu, 2008-01-10 at 21:47 +0100, Noah Meyerhans wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - > Debian Security Advisory DSA-1458-1[EMAIL PROTECTED] > http://www.debian.org/security/ Noah Meyerhans > January 10, 2008http://www.debian.org/security/faq > - > > Package: openafs > Vulnerability : programming error > Problem type : remote > Debian-specific: no > CVE Id(s) : CVE-2007-6599 > BugTraq ID : 27132 > > A race condition in the OpenAFS fileserver allows remote attackers to > cause a denial of service (daemon crash) by simultaneously acquiring and > giving back file callbacks, which causes the handler for the > GiveUpAllCallBacks RPC to perform linked-list operations without the > host_glock lock. > > For the stable distribution (etch), this problem has been fixed in > version 1.4.2-6etch1 > > For the old stable distribution (sarge), this problem has been fixed in > version 1.3.81-3sarge3 > > We recommend that you upgrade your openafs packages. > > Upgrade instructions > - > > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > If you are using the apt-get package manager, use the line for > sources.list as given below: > > apt-get update > will update the internal database > apt-get upgrade > will install corrected packages > > You may use an automated update by adding the resources from the > footer to the proper configuration. > > > Debian 3.1 (oldstable) > - -- > > Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, > m68k, mips, mipsel, powerpc, s390 and sparc. > > Source archives: > > > http://security.debian.org/pool/updates/main/o/openafs/openafs_1.3.81-3sarge3.dsc > Size/MD5 checksum: 851 e976cc846cb191828237473b1d0e4983 > > http://security.debian.org/pool/updates/main/o/openafs/openafs_1.3.81.orig.tar.gz > Size/MD5 checksum: 13455346 d754e92f7a0cd9824991c850e001884c > > http://security.debian.org/pool/updates/main/o/openafs/openafs_1.3.81-3sarge3.diff.gz > Size/MD5 checksum: 261881 e28ed82f25816569ae6f1e74c7cd651b > > Architecture independent packages: > > > http://security.debian.org/pool/updates/main/o/openafs/openafs-modules-source_1.3.81-3sarge3_all.deb > Size/MD5 checksum: 4616288 3e229a9fe2d2b561a71622feac362a0a > > alpha architecture (DEC Alpha) > > > http://security.debian.org/pool/updates/main/o/openafs/openafs-fileserver_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 526 3c76348f4a27d5cda9aaa689ae9b1e11 > > http://security.debian.org/pool/updates/main/o/openafs/libpam-openafs-kaserver_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 271230 33707e0d7ad8bb2b2ed152e5d92ae1fb > > http://security.debian.org/pool/updates/main/o/openafs/openafs-dbserver_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 693318 8977f1b81728d32a2f58fc7adaba7a49 > > http://security.debian.org/pool/updates/main/o/openafs/openafs-kpasswd_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 306556 c68d43f0a515c3ef40c26a69c3fa5267 > > http://security.debian.org/pool/updates/main/o/openafs/openafs-client_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 2228482 4df236f17ca09f966381191bc744738c > > http://security.debian.org/pool/updates/main/o/openafs/libopenafs-dev_1.3.81-3sarge3_alpha.deb > Size/MD5 checksum: 189 47914dd9a679b3e5ef7073d2c9b992f9 > > amd64 architecture (AMD x86_64 (AMD64)) > > > http://security.debian.org/pool/updates/main/o/openafs/libopenafs-dev_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 1442304 440380aae37ad9570d3488b2b94c1f20 > > http://security.debian.org/pool/updates/main/o/openafs/openafs-dbserver_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 555860 3d5eeca465e786c8e3aeaa0f3a33c237 > > http://security.debian.org/pool/updates/main/o/openafs/openafs-kpasswd_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 246504 a1f8f9151ddf5d8b2223ccc9011262ea > > http://security.debian.org/pool/updates/main/o/openafs/libpam-openafs-kaserver_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 229864 b17737eccca71f36bc1d2353979a8c5f > > http://security.debian.org/pool/updates/main/o/openafs/openafs-client_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 1833444 365d0d014c6328440fcab8c9f8a7b290 > > http://security.debian.org/pool/updates/main/o/openafs/openafs-fileserver_1.3.81-3sarge3_amd64.deb > Size/MD5 checksum: 884294 72860be9817d2a76f7dee14f133e55c3 > > hppa architecture (HP PA RISC) > > > http
Re: [SECURITY] [DSA 1304-1] New Linux kernel 2.6.8 packages fix several vulnerabilities
This release was quite confusing, because it applies only to sarge, and yet doesn't say so at all (except in the package names), and even says that the new packages will "probably be moved into the stable distribution" which is surely false. Thomas On Sat, 2007-06-16 at 04:57 -0600, dann frazier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - -- > Debian Security Advisory DSA 1304-1[EMAIL PROTECTED] > http://www.debian.org/security/ Dann Frazier > June 16th, 2007 http://www.debian.org/security/faq > - -- > > Package: kernel-source-2.6.8 > Vulnerability : several > Problem-Type : local/remote > Debian-specific: no > CVE ID : CVE-2005-4811 CVE-2006-4814 CVE-2006-4623 CVE-2006-5753 > CVE-2006-5754 CVE-2006-5757 CVE-2006-6053 CVE-2006-6056 > CVE-2006-6060 CVE-2006-6106 CVE-2006-6535 CVE-2007-0958 > CVE-2007-1357 CVE-2007-1592 > > Several local and remote vulnerabilities have been discovered in the Linux > kernel that may lead to a denial of service or the execution of arbitrary > code. > > This update also fixes a regression in the smbfs subsystem which was > introduced > in DSA-1233 which caused symlinks to be interpreted as regular files. > > The Common Vulnerabilities and Exposures project identifies the > following problems: > > CVE-2005-4811 > > David Gibson reported an issue in the hugepage code which could permit > a local DoS (system crash) on appropriately configured systems. > > CVE-2006-4814 > > Doug Chapman discovered a potential local DoS (deadlock) in the mincore > function caused by improper lock handling. > > CVE-2006-4623 > > Ang Way Chuang reported a remote DoS (crash) in the dvb driver which > can be triggered by a ULE package with an SNDU length of 0. > > CVE-2006-5753 > > Eric Sandeen provided a fix for a local memory corruption vulnerability > resulting from a misinterpretation of return values when operating on > inodes which have been marked bad. > > CVE-2006-5754 > > Darrick Wong discovered a local DoS (crash) vulnerability resulting from > the incorrect initialization of "nr_pages" in aio_setup_ring(). > > CVE-2006-5757 > > LMH reported a potential local DoS which could be exploited by a malicious > user with the privileges to mount and read a corrupted iso9660 filesystem. > > CVE-2006-6053 > > LMH reported a potential local DoS which could be exploited by a malicious > user with the privileges to mount and read a corrupted ext3 filesystem. > > CVE-2006-6056 > > LMH reported a potential local DoS which could be exploited by a malicious > user with the privileges to mount and read a corrupted hfs filesystem on > systems with SELinux hooks enabled (Debian does not enable SELinux by > default). > > CVE-2006-6060 > > LMH reported a potential local DoS (infinie loop) which could be exploited > by a malicious user with the privileges to mount and read a corrupted NTFS > filesystem. > > CVE-2006-6106 > > Marcel Holtman discovered multiple buffer overflows in the Bluetooth > subsystem which can be used to trigger a remote DoS (crash) and > potentially > execute arbitray code. > > CVE-2006-6535 > > Kostantin Khorenko discovered an invalid error path in dev_queue_xmit() > which could be exploited by a local user to cause data corruption. > > CVE-2007-0958 > > Santosh Eraniose reported a vulnerability that allows local users to read > otherwise unreadable files by triggering a core dump while using > PT_INTERP. > This is related to CVE-2004-1073. > > CVE-2007-1357 > > Jean Delvare reported a vulnerability in the appletalk subsystem. > Systems with the appletalk module loaded can be triggered to crash > by other systems on the local network via a malformed frame. > > CVE-2007-1592 > > Masayuki Nakagawa discovered that flow labels were inadvertently > being shared between listening sockets and child sockets. This defect > can be exploited by local users to cause a DoS (Oops). > > The following matrix explains which kernel version for which architecture > fix the problems mentioned above: > > Debian 3.1 (sarge) > Source 2.6.8-16sarge7 > Alpha architecture 2.6.8-16sarge7 > AMD64 architecture 2.6.8-16sarge7 > HP Precision architecture 2.6.8-6sarge7 > Intel IA-32 architecture2.6.8-16sarge7 > Intel IA-64 architecture2.6.8-14sarge7 > Motorola 680x0 architecture 2.6.8-4sarge7 > PowerPC architecture2.6.8-12sarge7 > IBM S/390 architecture 2.6.8-5sarge7 > Sun Sparc architecture 2.
Re: What is a security bug?
Florian Weimer <[EMAIL PROTECTED]> writes: > * Thomas Bushnell: > >> Florian Weimer <[EMAIL PROTECTED]> writes: >> >>> Suppose that the web browser always crashes when confronted with >>> certain input, losing all of its state. With tabbed browsing, >>> multiple browser opened by the same process etc., this means that >>> potentially important work is lost. >> >> In the case of galeon, for example, there is no bug, because it can >> restart with the old state. > > I would still consider it a bug, but clearly a less severe one. I meant not that there is no bug, but it no longer has the same security implications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is a security bug?
Dale Amon <[EMAIL PROTECTED]> writes: > On Wed, Nov 23, 2005 at 11:10:25PM -0800, Thomas Bushnell BSG wrote: >> It seems it does not save form entries (which was not mentioned >> explicitly in Florian's post above), but it certainly does save the >> tabs and multiple windows information and such. > > Galeon and firefox have *always* had this sort of > crash problem. It is especially apparent when printing > ps to file. There are some **major** sites which will > reliably crash your browser. You write this as if it contradicts something I've said. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is a security bug?
Marc Haber <[EMAIL PROTECTED]> writes: > On Wed, Nov 23, 2005 at 10:53:46PM -0800, Thomas Bushnell BSG wrote: >> Florian Weimer <[EMAIL PROTECTED]> writes: >> > Suppose that the web browser always crashes when confronted with >> > certain input, losing all of its state. With tabbed browsing, >> > multiple browser opened by the same process etc., this means that >> > potentially important work is lost. >> >> In the case of galeon, for example, there is no bug, because it can >> restart with the old state. > > And galeon saves current state, including form entries done by the > user, before it segfaults? It seems it does not save form entries (which was not mentioned explicitly in Florian's post above), but it certainly does save the tabs and multiple windows information and such. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is a security bug?
Florian Weimer <[EMAIL PROTECTED]> writes: > Suppose that the web browser always crashes when confronted with > certain input, losing all of its state. With tabbed browsing, > multiple browser opened by the same process etc., this means that > potentially important work is lost. In the case of galeon, for example, there is no bug, because it can restart with the old state. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Now, please explain to me why a changelog that has had detail added to past > entries so that information that belongs to a given uploaded version IS in > the entry for that version, is worse than one that lacks this information, > OR has that information elsewhere? Because it omits information, crucially, when a particular fact was learned. Why obscure information deliberately? > That is my whole point of contention. Not that I'd advocate going over the > changelog to add and update CAN and CVE data, as the security team already > said they don't really need it, but I want to know exactly what kind of > damage one would be doing by updating the changelog like that. So far, I > have not been convinced that we should be *against* someone doing it, if he > has the inclination to do so. If you add it with the actual date, saying "this was fixed by version such-and-such" or whatever, then you are maintaining a more accurate record. Why deliberately create a less accurate record? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Joey Hess <[EMAIL PROTECTED]> writes: > One thing that this bug illustrates pretty well that is quite annoying > when trying to determine what version of a package actually fixed a > security hole, is new upstream releases that are listed in the changelog > as fixing a particular CVE, when the hole was actually fixed in a > previous debian revision of the old upstream version. That's a case > where clarity is very useful in the changelog. (So is proper use of the > new version tracking features of the BTS.) Seems to me that the right thing to do is: close the bug with the right version using -done; add a *new* changelog entry (not altering the old one), saying "bug such-and-such was fixed in such-and-such old version." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Frans Pop <[EMAIL PROTECTED]> writes: > On Thursday 27 October 2005 23:34, Henrique de Moraes Holschuh wrote: >> To me it is a technical matter, as the changelogs are a tool for a >> technical job. > > To me, changelogs are primarily a way of informing the user of changes in > a package. Including references to fixed security issues is definitely a > part of that. No, this is only one thing. changelogs are also a record of changes made for the sake of the maintainer, and his successors, and other members of the project. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > When dealing with Debian matters of a technical nature, yes. When dealing > with matters outside Debian, or of a non-technical nature, I may decide to > not take such an instance. And frankly, as long as it is a rule of mine, > applied to myself, what business is it of yours? Um, we're talking about a shared resource here which is designed to help many people work together. changelogs are not some private notations of the developer. It is certainly reasonable to expect that they be maintained by different developers in a consistent way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Parse error: "... that one?" I am sorry, I am not sure I understood what > you mean. IF I got it right, my reply is simple: I will not change my mind > about a technical matter backed by technical reasons, because of the beliefs > of someone else. Give me technical reasons, and I will listen and I could > be convinced that I am wrong. Great. Now you have a rule: "I will only listen to technical reasons." Where did that rule come from? Was that rule itself backed by technical reasons? No. I sense an inconsistency. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CAN to CVE: changing changelogs?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > But at least we know that this subthread can end right here, right now. It > is useless to discuss beliefs that exist without a technical backing, and I > won't waste my time with it. Do you have a technical backing for your view that it is useless to discuss beliefs that one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Frans Pop <[EMAIL PROTECTED]> writes: > On Thursday 04 August 2005 00:39, Thomas Bushnell BSG wrote: >> Frans Pop <[EMAIL PROTECTED]> writes: >> > On Thursday 04 August 2005 00:25, Thomas Bushnell BSG wrote: >> >> What is wrong with volatile? It's for exactly this case. >> > >> > No it is not. volatile-sloppy [1] may be (if that's implemented). >> >> I read that, and I read more importantly volatile.debian.net, and I >> don't see any indication there of why gaim upgrades (or mozilla ones) >> are not allowed in volatile. > > From volatile.debian.net: > volatile is not "just another place" for backports, but should only > contain changes to stable programs that are necessary to keep them > ^^ > functional; > > Changes to stable programs <> new upstream versions (in principle). I'm not sure I understand this. In the case of gaim, it's in fact specifically necessary to "keep it functional": you can't connect to yahoo IM once the protocol's been changed. This is even worse than the virus scanner problem, where at least you can continue to detect old viruses with the old definitions. > As a rule, only changes to data files are accepted. Packaging changes are > also not acceptable in principle. Nothing about the documentation suggests this, and when I advocated for volatile.debian.org, it was not with such tight restrictions. At least the documentation should describe the *actual* criteria. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Frans Pop <[EMAIL PROTECTED]> writes: > On Thursday 04 August 2005 00:25, Thomas Bushnell BSG wrote: >> What is wrong with volatile? It's for exactly this case. > > No it is not. volatile-sloppy [1] may be (if that's implemented). > > [1] http://lists.debian.org/debian-devel-announce/2005/05/msg00016.html I read that, and I read more importantly volatile.debian.net, and I don't see any indication there of why gaim upgrades (or mozilla ones) are not allowed in volatile. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Mathieu JANIN <[EMAIL PROTECTED]> writes: > I was thinking about a policy for managing packages built around "never > patched" softwares like Moz/FireFox. > Volatile and Security repositories do not fit for that, everybody agrees > with that. What is wrong with volatile? It's for exactly this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Adeodato Simó <[EMAIL PROTECTED]> writes: > * Thomas Bushnell BSG [Tue, 02 Aug 2005 16:07:08 -0700]: > >> It would be very nice if Mozilla would publish to distributions like >> ours a description of the security problem, and then a separate patch >> for that specific problem. > > "Publish to distributions" is effectively the same as making it > completely public, so they won't. See [1]. > > [1] http://lists.debian.org/debian-security/2005/08/msg00032.html It was asked what we would like them to do. Everyone else seems to manage just fine with an embargo method. It works quite well for a jillion other upstreams.
Re: On Mozilla-* updates
John Hardcastle <[EMAIL PROTECTED]> writes: > I agree with David's suggestion to just put the latest releases from > Mozilla into Debian Stable. This is what volatile is for. Indeed, it was the very first and best example of why we want volatile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Alexander Sack <[EMAIL PROTECTED]> writes: > Matt Zimmerman wrote: >> >> I'm guessing that you're not going to volunteer on the manpower side, and I >> don't think that it would be a good way to spend resources even if we had >> them. You're welcome to attempt to convince the Mozilla project to change >> the way that they work for the benefit of distribution security teams. > > How should mozilla change the way they work? It would be very nice if Mozilla would publish to distributions like ours a description of the security problem, and then a separate patch for that specific problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Willi Mann <[EMAIL PROTECTED]> writes: > [Thomas, I'm not sure if you are on the debian-security list, so I'm CCing > you] > >> Are you prepared to make sure all the packages that depend on mozilla >> will have packages ready to enter at once? > > This would only be necessary in case of an API/ABI change, right? The > mozilla people have shown to care about the API. See the warnings > about the 1.0.5 release, the issues were soon after corrected by 1.0.6. Even when there is no ABI/API change, packages that depend on Mozilla generally depend on exact version numbers. I do not know on which side the bug lies, but if you are saying that a new galeon package is not necessary when a compatible mozilla shows up, my experience is that this is very often not true. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Noah Meyerhans <[EMAIL PROTECTED]> writes: > On Mon, Aug 01, 2005 at 04:57:31PM -0700, Thomas Bushnell BSG wrote: >> > IMHO, sloopy security support (by uploading new upstream versions) is >> > better than no security support. >> >> Are you prepared to make sure all the packages that depend on mozilla >> will have packages ready to enter at once? > > Are you prepared to kick all packages that depend on mozilla out of > Debian completely? How about actually maintaining them? > That's the choice we've got. Moving them to > backports.org or volatile, which are not carried by the mirror network, > not included in the default apt sources.list, and not getting DSA > announcements, IMHO, counts as "kicking them out of Debian". Oh, I see. I think the whole point of volatile is that it is *part* of Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Willi Mann <[EMAIL PROTECTED]> writes: > IMHO, sloopy security support (by uploading new upstream versions) is > better than no security support. Are you prepared to make sure all the packages that depend on mozilla will have packages ready to enter at once? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for example tripwire policy files for "/var"
Declan Mullen <[EMAIL PROTECTED]> writes: > I need to develop appropriate tripwire policy rules for the files and > directories under "/var/" on Sarge. Being new to Debian, I would > appreciate receiving any example policy rules/files that I could learn > from, many thanks. Um, it sounds as if you've decided what you need without knowing whether you need it or not, or without knowing what you need it for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rm files owned by root?
Florian Weimer <[EMAIL PROTECTED]> writes: > * Ulrich FÃrst: > > > Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > >> This is a Unix FAQ. You can delete any file if you have write access > >> to the directory. Actually you dont delete the file, you remove the > >> "link" to the > > > > So if my /home/ is 775 and root.users and I'm in the group users I can > > delete everybody's home directory? > > Only if it's empty. You could rename it to /tmp on most > installations, where it would be deleted after the next reboot. Both wrong. Removing a directory requires write permission on the directory itself, because you have to delete the "." and ".." links inside the directory. Renaming a directory requires write permission on the directory if its parent changes, because you have to rewrite the ".." link. Thomas
Re: Rebuilding packages on *all* architectures
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > The binary is needed because otherwise the -all packages would be > missing and there would be no deb package in the archive holding the > source in. The first problem is solved by having one of the arch's autobuilders also be responsible for the Arch: all packages--presumably which ever keeps up the most with its queue would be the best choice. The second problem is solved by changing the way the archive management works. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
martin f krafft <[EMAIL PROTECTED]> writes: > > The logical conclusion from your arguments is that we should > > actually remove the ssh package from Debian! > > How so? If we shouldn't sign and check signatures because there are still ways of subverting one's ssh binary, then we shouldn't even distribute ssh binaries. Doesn't such distribution cause a false sense of security? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
martin f krafft <[EMAIL PROTECTED]> writes: > > > I think, adding package signatures will actually make Debian less > > > secure than it was before, although it's doubtful that the average > > > user will notice or care. > > > > How can it make it less secure? > > It gives the users a false sense of security. Having the package > verify suggests that it is authentic, when in fact it only says that > it has been uploaded by someone with control over any of the Debian > developer GPG keys. But how does this "false sense" cause a problem? For example, if users regularly scanned all the source code on their system, and this would cause them to stop doing so, then the false sense would be a problem! In other words, what makes a false sense of security dangerous is when it leads someone to stop being careful about things that they otherwise would be. But right now, what care is anyone actually taking to make sure that the ssh binaries they get from Debian aren't compromised? > I see that this goes both ways and does also raise security. But > do you also see my point? I do see how it could create a false sense of security. I do not see what the damage that false sense is causing in this case. > Good point. And also: uploading once every six months does not > ensure that the developer otherwise treats his/her key safely. Thus, > it does not really address the issue. Please don't speak of "the issue". There are many issues, and why I object to your "do nothing" proposal, as that it seems to me that you are saying we should solve any of these issues until we can solve them all. This attitude is facilitated by treating it as "the issue", which isn't solved (in your mind) unless it is solved in its entirety. Instead, think about it as many different issues. We can solve one of them, and thus make progress, without necessarily having solved every one. The logical conclusion from your arguments is that we should actually remove the ssh package from Debian! Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
Russell Coker <[EMAIL PROTECTED]> writes: > Removing from active status seems appropriate to me. But that's a totally different subject. If you want to remove Debian developers from the list of developers, because they haven't uploaded in six months (what about packages that don't have bugs?!) then that's a different topic. Please don't tie it to the security thing, which doesn't require removing them as developers. > If we are afraid of compromised packages then we can't have an automated > method of changing status back to active. I didn't suggest that. I suggested some kind of checking to see if they are really the person. That would involve a person doing a little effort. There is no effort-free procedure here. My point is that if they have been idle, then an upload requires some kind of human revalidation--but NOT a complete NMU procedure, or removing them as a developer, or dropping their ability to vote, or things like that. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
Russell Coker <[EMAIL PROTECTED]> writes: > Removing developers who don't meet certain criteria (EG no package > uploads for 6 months) from active status makes a lot of sense. > Anyone care to propose a GR? Careful about terminology here. I wouldn't say "remove", just we drop them from the list of signatures. They are still Debian developers. When a developer uploads who has been dropped from the list, maybe some kind of active authentication process can take place. That is, this is the point for human intervention. Also, we don't need a GR. This is technical! :) It's a matter, ultimately, for the apt team, in theory, but really, some sort of general agreement including the security team, technical committee, and the DPL is what I would suggest. A GR is not needed. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
martin f krafft <[EMAIL PROTECTED]> writes: > So I guess this email isn't about APT 0.6, which does what it should > and does so well. It's more about the dangers of having 1000 keys > allowing write access to the archive, and noone capable of > playing sheriff with the size of the project anymore. I think this is a real problem. I would quibble with your estimate of its likelihood, but that doesn't really matter. (And I don't know what "incredulously high" means--check your dictionary--"incredulous" is not a synonym of "incredible".) Start off with the assumption that we can trust real developers. If we cannot, then all bets are off. So the problem reduces to: how do we catch the case where an inactive or inattentive developer's key is snagged to do trojan uploads? You are right that it is possible to sneak in NMUs in such a way that the maintainer doesn't see them. But *someone* sees them. It seems entirely reasonable to me to track maintainer changes and NMUs, and when they occur, to do some things to make sure that they come to the attention of someone known to be reasonable. I have some ideas about how this could be done. > I think, adding package signatures will actually make Debian less > secure than it was before, although it's doubtful that the average > user will notice or care. How can it make it less secure? The package signatures raise the bar for an attacker. They do not eliminate all problems, but they close off one whole area of compromises. And--I would suggest--they do not create false security, because they close off the easier attacks. So all the people who can accomplish the easy attack but not the hard one are successfully stopped by package signature checking. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: root's home world readable
Christian Hammers <[EMAIL PROTECTED]> writes: > The password for the mysql root user is not property of the system wide > configuration as I can't force the user to change a file in /etc > every time they change the users password and, due to mysqls default to > use the mysql user of the same name as the system user you are logged in > it would be unconvinient for the user to have to log into mysql as > something other. The "users password", or the system-wide password? Your English weakness is making it very hard to communicate, please try and be really carefuly. You are supposed to "force" the *administrator* to edit files in /etc to change system-wide things. Whether the password is system-wide or not has nothing to do with the details of how the package is set up, and everything to do with the details and facts of how its used. This sounds *exactly* like the sort of configuration option that belongs in /etc. But it's still a little unclear to me exactly what this password is for. > With "functionality" I not only meant log rotating but also shutting down > the server at upgrades and deinstalles as I don't want to just kill the > processes although last time I checked the code was the same. Right. All that sort of thing is a system-wide configuration thing, and should be controlled through files in /etc. > So I end up with a debian specific user with shutdown/reload privileges > that's created with a random (saved) password at installtime as the best > solution, or? Nope. Probably the user should need to be root (or some other generic user), but the files that are manipulated to accomplish shutdown/reload and so forth should all be in /etc.
Re: [d-security] Re: root's home world readable
Christian Hammers <[EMAIL PROTECTED]> writes: > On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: > > > There is at least one package in Debian that requires you to put > > > sensitive information in /root. The mysql server package needs you to > > > have a .my.cnf in the /root if you want the logs to rotate. The > > > my.cnf contains the clear text version of the root password to the > > > database. > > > > This is a bug. The file should be in /etc (if, as it sounds like, > > it's a system-wide configuration file). > It is not (a system wide configuration file) but at least in recent > versions you can archive the needed functionality by creating a "debian" > system user with sufficent privileges. This is planned but I though I > implement it after the next freeze (well err, that's what I though half a > year ago, probably the main freeze is far enough away to change it before > testing will be released) What? If it's a way to get "the logs" to rotate, that sure sounds like a system-wide option. If it's a root password to a system-wide database, then that's also a system-wide option. I don't know what "archive the needed functionality" means. If these are system-wide options, they belong in /etc. They do not belong in ~root, and they do not belong in ~debian.
Re: root's home world readable
Chris Francy <[EMAIL PROTECTED]> writes: > There is at least one package in Debian that requires you to put > sensitive information in /root. The mysql server package needs you to > have a .my.cnf in the /root if you want the logs to rotate. The > my.cnf contains the clear text version of the root password to the > database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file).
Re: [d-security] Re: root's home world readable
Christian Hammers <[EMAIL PROTECTED]> writes: > The password for the mysql root user is not property of the system wide > configuration as I can't force the user to change a file in /etc > every time they change the users password and, due to mysqls default to > use the mysql user of the same name as the system user you are logged in > it would be unconvinient for the user to have to log into mysql as > something other. The "users password", or the system-wide password? Your English weakness is making it very hard to communicate, please try and be really carefuly. You are supposed to "force" the *administrator* to edit files in /etc to change system-wide things. Whether the password is system-wide or not has nothing to do with the details of how the package is set up, and everything to do with the details and facts of how its used. This sounds *exactly* like the sort of configuration option that belongs in /etc. But it's still a little unclear to me exactly what this password is for. > With "functionality" I not only meant log rotating but also shutting down > the server at upgrades and deinstalles as I don't want to just kill the > processes although last time I checked the code was the same. Right. All that sort of thing is a system-wide configuration thing, and should be controlled through files in /etc. > So I end up with a debian specific user with shutdown/reload privileges > that's created with a random (saved) password at installtime as the best > solution, or? Nope. Probably the user should need to be root (or some other generic user), but the files that are manipulated to accomplish shutdown/reload and so forth should all be in /etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: root's home world readable
Christian Hammers <[EMAIL PROTECTED]> writes: > On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: > > > There is at least one package in Debian that requires you to put > > > sensitive information in /root. The mysql server package needs you to > > > have a .my.cnf in the /root if you want the logs to rotate. The > > > my.cnf contains the clear text version of the root password to the > > > database. > > > > This is a bug. The file should be in /etc (if, as it sounds like, > > it's a system-wide configuration file). > It is not (a system wide configuration file) but at least in recent > versions you can archive the needed functionality by creating a "debian" > system user with sufficent privileges. This is planned but I though I > implement it after the next freeze (well err, that's what I though half a > year ago, probably the main freeze is far enough away to change it before > testing will be released) What? If it's a way to get "the logs" to rotate, that sure sounds like a system-wide option. If it's a root password to a system-wide database, then that's also a system-wide option. I don't know what "archive the needed functionality" means. If these are system-wide options, they belong in /etc. They do not belong in ~root, and they do not belong in ~debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
Chris Francy <[EMAIL PROTECTED]> writes: > There is at least one package in Debian that requires you to put > sensitive information in /root. The mysql server package needs you to > have a .my.cnf in the /root if you want the logs to rotate. The > my.cnf contains the clear text version of the root password to the > database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More security for screensavers
Benoît Sibaud <[EMAIL PROTECTED]> writes: > For now, the xscreensaver maintainer disagrees. > "I disagree. It is NOT a security issue, it has been discussed the last > 3 times it was brought up, and it's easy enough to change if it bothers > you. Neither your bug or the discussion you pointed to adds anything to > the debate that's been carried on several times before." I agree with the maintainer. Most workstations are not in public places where this is a problem. Nor is it a security issue, actually. When I worked for MIT athena, we simply went through and disabled all the hacks that dependend on previous screen text and turned them off; perhaps a *wishlist* item could be added to make this easy to toggle from the gnome (or other) capplets.
Re: More security for screensavers
Benoît Sibaud <[EMAIL PROTECTED]> writes: > For now, the xscreensaver maintainer disagrees. > "I disagree. It is NOT a security issue, it has been discussed the last > 3 times it was brought up, and it's easy enough to change if it bothers > you. Neither your bug or the discussion you pointed to adds anything to > the debate that's been carried on several times before." I agree with the maintainer. Most workstations are not in public places where this is a problem. Nor is it a security issue, actually. When I worked for MIT athena, we simply went through and disabled all the hacks that dependend on previous screen text and turned them off; perhaps a *wishlist* item could be added to make this easy to toggle from the gnome (or other) capplets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mounting /tmp noexec
David Wright <[EMAIL PROTECTED]> writes: > Quoting Thomas Bushnell, BSG ([EMAIL PROTECTED]): > > Ian <[EMAIL PROTECTED]> writes: > > > so surely, if nothing needs to be executed, it is better to mount > > > noexec? > > > > noexec has no good purpose, really. But it's intention was for > > networked filesystems in certain environments, not a generalized > > security tool. > > It's very useful for mounting filesystems like vfat, where otherwise > all the files are marked executable which makes mc a PITA to use for > examining archive files (mc tries to execute them!). Ah, interesting. ;) Of course, that isn't a security related reason. It would probably be better if vfat had a more clever way of marking them executable: perhaps it should look at the file to see whether the kernel *could* conceivable execute it.
Re: mounting /tmp noexec
David Wright <[EMAIL PROTECTED]> writes: > Quoting Thomas Bushnell, BSG ([EMAIL PROTECTED]): > > Ian <[EMAIL PROTECTED]> writes: > > > so surely, if nothing needs to be executed, it is better to mount > > > noexec? > > > > noexec has no good purpose, really. But it's intention was for > > networked filesystems in certain environments, not a generalized > > security tool. > > It's very useful for mounting filesystems like vfat, where otherwise > all the files are marked executable which makes mc a PITA to use for > examining archive files (mc tries to execute them!). Ah, interesting. ;) Of course, that isn't a security related reason. It would probably be better if vfat had a more clever way of marking them executable: perhaps it should look at the file to see whether the kernel *could* conceivable execute it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mounting /tmp noexec (was: Campus Computers)
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > Posix requires a /tmp directory which arbitrary programs can write to, > > and Posix knows nothing of noexec; a valid program of any sort could > > well decide to use that feature, and Debian shouldn't bother trying to > > work around it, IMHO. > > On the other, it's completely trivial to work around it and I don't > see any reason not to go above and beyond what POSIX specifies. It depends on the program. It's perfectly clear that many programs cannot work around it, because the only place they know where they can write a file is /tmp. You might as well say that it's easy to work around a non-writeable /tmp too. Indeed it is, but that's not the point.
Re: mounting /tmp noexec (was: Campus Computers)
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > What sort of insecure cgi script are you thinking of? > > Trivial protection against stupid rootkits. > > > In any case, it's part of the normal conventions of all Unix-based > > systems that /tmp is accessible to every user, for writing files and > > for executing them. > > debconf seems to be the only thing relying on it, I've been using > a nonexec /tmp for a while now without noticing any other problems. Posix requires a /tmp directory which arbitrary programs can write to, and Posix knows nothing of noexec; a valid program of any sort could well decide to use that feature, and Debian shouldn't bother trying to work around it, IMHO.
Re: mounting /tmp noexec (was: Campus Computers)
Ian <[EMAIL PROTECTED]> writes: > for example, an insecure cgi script could allow a user to write to /tmp > and get the web server to execute the script. By mounting /tmp noexec, > this problem is potentially prevented (aside from the insecure script). What sort of insecure cgi script are you thinking of? If it's being coerced into letting the user write a file and execute it, it can presumably be coerced to just directly execute whatever it wants without the rigamarole. > so surely, if nothing needs to be executed, it is better to mount > noexec? noexec has no good purpose, really. But it's intention was for networked filesystems in certain environments, not a generalized security tool. In any case, it's part of the normal conventions of all Unix-based systems that /tmp is accessible to every user, for writing files and for executing them.
Re: Campus Computers
Ian <[EMAIL PROTECTED]> writes: > Well, I mount /tmp (and anything else I can get away with) as noexec. > What is the policy here - should package maintainers not try and exec > out of /tmp, or should I allow exec on that partition? There is really no particular reason to mount local partitions noexec.
Re: mounting /tmp noexec (was: Campus Computers)
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > Posix requires a /tmp directory which arbitrary programs can write to, > > and Posix knows nothing of noexec; a valid program of any sort could > > well decide to use that feature, and Debian shouldn't bother trying to > > work around it, IMHO. > > On the other, it's completely trivial to work around it and I don't > see any reason not to go above and beyond what POSIX specifies. It depends on the program. It's perfectly clear that many programs cannot work around it, because the only place they know where they can write a file is /tmp. You might as well say that it's easy to work around a non-writeable /tmp too. Indeed it is, but that's not the point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mounting /tmp noexec (was: Campus Computers)
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Thomas Bushnell, BSG wrote: > > What sort of insecure cgi script are you thinking of? > > Trivial protection against stupid rootkits. > > > In any case, it's part of the normal conventions of all Unix-based > > systems that /tmp is accessible to every user, for writing files and > > for executing them. > > debconf seems to be the only thing relying on it, I've been using > a nonexec /tmp for a while now without noticing any other problems. Posix requires a /tmp directory which arbitrary programs can write to, and Posix knows nothing of noexec; a valid program of any sort could well decide to use that feature, and Debian shouldn't bother trying to work around it, IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mounting /tmp noexec (was: Campus Computers)
Ian <[EMAIL PROTECTED]> writes: > for example, an insecure cgi script could allow a user to write to /tmp > and get the web server to execute the script. By mounting /tmp noexec, > this problem is potentially prevented (aside from the insecure script). What sort of insecure cgi script are you thinking of? If it's being coerced into letting the user write a file and execute it, it can presumably be coerced to just directly execute whatever it wants without the rigamarole. > so surely, if nothing needs to be executed, it is better to mount > noexec? noexec has no good purpose, really. But it's intention was for networked filesystems in certain environments, not a generalized security tool. In any case, it's part of the normal conventions of all Unix-based systems that /tmp is accessible to every user, for writing files and for executing them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Campus Computers
Ian <[EMAIL PROTECTED]> writes: > Well, I mount /tmp (and anything else I can get away with) as noexec. > What is the policy here - should package maintainers not try and exec > out of /tmp, or should I allow exec on that partition? There is really no particular reason to mount local partitions noexec. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I disable (close) ports?
Ralf Dreibrodt <[EMAIL PROTECTED]> writes: > well, there are daemons which don't know on which port they should > run. they look in /etc/services for a special name and want to run > on the specific port. if they don't find the special name in > /etc/services they abort with an error message. Yeah, but that's really a bug. Demons should be more graceful and include a default port number to use in case /etc/services is broken.
Re: How do I disable (close) ports?
"J. Paul Bruns-Bielkowicz" <[EMAIL PROTECTED]> writes: > > You're not going to become a good Linux-administrator before you realize > > that you should UNDERSTAND what you do instead of just guessing and be > > happy because it worked. > > Becoming a good administrator is making it work and keeping it working. It > seems there is an official way of closing the ports and an unofficial > (wrong?) way of doing it. Understanding is gained, among others through > experience, and this is quite an experience judging by quantity of replies Your method wil not keep it work. The "unofficial" way will actually fail to work if the demons in question are written correctly.
Re: How do I disable (close) ports?
Ralf Dreibrodt <[EMAIL PROTECTED]> writes: > well, there are daemons which don't know on which port they should > run. they look in /etc/services for a special name and want to run > on the specific port. if they don't find the special name in > /etc/services they abort with an error message. Yeah, but that's really a bug. Demons should be more graceful and include a default port number to use in case /etc/services is broken. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I disable (close) ports?
"J. Paul Bruns-Bielkowicz" <[EMAIL PROTECTED]> writes: > > You're not going to become a good Linux-administrator before you realize > > that you should UNDERSTAND what you do instead of just guessing and be > > happy because it worked. > > Becoming a good administrator is making it work and keeping it working. It > seems there is an official way of closing the ports and an unofficial > (wrong?) way of doing it. Understanding is gained, among others through > experience, and this is quite an experience judging by quantity of replies Your method wil not keep it work. The "unofficial" way will actually fail to work if the demons in question are written correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I disable (close) ports?
Alexander Clouter <[EMAIL PROTECTED]> writes: > ermdon't diasble them in /etc/services, this normally doesn't work (as > far as I'm aware). /etc/services is more a 'lookup' service then a 'whether > I should actually work' service. Ditto. > according to /etc/serices 111 is 'portmapper', darned if I know what it > actually does however you may find it lurking in your /etc/(x)inetd.conf or > even /etc/init.d/. Type > "/etc/init.d/ stop" and then do another netstat and see if that > helps. Portmapper is an essential server for SunRPC services, including NFS, mountd, nfsd, etc. > As for the 859 I cannot see where you got it from, no reference to it at all, > from what you have given us. However you probably find it in the same way as > you did 'nuke' portmapper.
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > It's been an option on traditional Unix systems for a long time. When > kernel runs the interpreter listed on the #! line, it does so with > suid/sgid access enabled. It's not really any more difficult than > launching binaries. However, there is an unavoidable security hole if you have any setuid #! scripts, at least, as they are traditionally implemented. If you adjust the semantics slightly, it can be fixed, but even then, it's not usually judged to be that important.
Re: How do I disable (close) ports?
Alexander Clouter <[EMAIL PROTECTED]> writes: > ermdon't diasble them in /etc/services, this normally doesn't work (as > far as I'm aware). /etc/services is more a 'lookup' service then a 'whether > I should actually work' service. Ditto. > according to /etc/serices 111 is 'portmapper', darned if I know what it > actually does however you may find it lurking in your /etc/(x)inetd.conf or > even /etc/init.d/. Type > "/etc/init.d/ stop" and then do another netstat and see if that > helps. Portmapper is an essential server for SunRPC services, including NFS, mountd, nfsd, etc. > As for the 859 I cannot see where you got it from, no reference to it at all, > from what you have given us. However you probably find it in the same way as > you did 'nuke' portmapper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
[EMAIL PROTECTED] (William R. Ward) writes: > It's been an option on traditional Unix systems for a long time. When > kernel runs the interpreter listed on the #! line, it does so with > suid/sgid access enabled. It's not really any more difficult than > launching binaries. However, there is an unavoidable security hole if you have any setuid #! scripts, at least, as they are traditionally implemented. If you adjust the semantics slightly, it can be fixed, but even then, it's not usually judged to be that important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WAY OT (Re: In Praise of Dos (RE: Mutt & tmp files))
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Vineet Kumar wrote: > > > So are "please" and "thank you," but it's generally considered polite. > > Also using Mail-Followup-To is standard and expected behaviour on > debian lists. That's a reasonable requirement only when Debian adds support for Mail-Followup-To in all the MUA's that it supports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WAY OT (Re: In Praise of Dos (RE: Mutt & tmp files))
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Vineet Kumar wrote: > > > So are "please" and "thank you," but it's generally considered polite. > > Also using Mail-Followup-To is standard and expected behaviour on > debian lists. That's a reasonable requirement only when Debian adds support for Mail-Followup-To in all the MUA's that it supports.
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > The whole problem here is they DIDN'T ask you. You threw in your two > cents worth without a corresponding pledge of support. It's a public mailing list, and I was simply contributing my suggestion. You decided it should be a big Federal case. I'll make you a deal. When you rudely say "shut up", I'll pay attention if you return the favor when I say shut up to you. > No, but you DO make yourself a hypocrite for calling ME obstructionist... > Compared to you, I'm a piker in this context apparently. I'm not trying to obstruct anything.
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > They aren't reasonable things to add at the last minute. The search > happened, AFAICT there is a candidate, yet you had to object now. If it > was so reasonable, why didn't you mention it when it came up? > Reasonableness cannot be applied to concepts that are brought up at the > last minute: the very fact that they were shoved in at the last minute > makes them unreasonable. Now do as I asked and shut up. Actually, the security team was operating all the time under the expectation that the person should be a developer, despite the public statement on the list (as has already been said). Nor for that matter is it unreasonable for me to make a suggestion late in the day; it is for the appropriate people to decide whether or not they want to take the suggestion--where that is the security team--and I'm happy to let them take whatever suggestions I might offer and do with them what they think fit. As for why I didn't bring it up sooner: I simply hadn't noticed it sooner. I don't therefore void my right to bring it up, though the security team would be well within its rights to decide that it's too late to change things. Thomas
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > On 22 Oct 2001, Thomas Bushnell, BSG wrote: > > >John Galt <[EMAIL PROTECTED]> writes: > > > >> I take it then that you volunteer. If not, shut up. Throwing artifical > >> barriers at this office isn't going to add volunteers. > > > >How is it a barrier? > > It's an extra qualification. It's one that until you objected, didn't > exist. My point still stands: if you want to add qualifications, add them > by "raising the bar" and volunteering yourself. I think it's an entirely appropriate qualification. But it's no barrier: it simply requires that we know who the person is and that they share our commitments. I think those are reasonable things to expect. Thomas
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > The whole problem here is they DIDN'T ask you. You threw in your two > cents worth without a corresponding pledge of support. It's a public mailing list, and I was simply contributing my suggestion. You decided it should be a big Federal case. I'll make you a deal. When you rudely say "shut up", I'll pay attention if you return the favor when I say shut up to you. > No, but you DO make yourself a hypocrite for calling ME obstructionist... > Compared to you, I'm a piker in this context apparently. I'm not trying to obstruct anything. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > They aren't reasonable things to add at the last minute. The search > happened, AFAICT there is a candidate, yet you had to object now. If it > was so reasonable, why didn't you mention it when it came up? > Reasonableness cannot be applied to concepts that are brought up at the > last minute: the very fact that they were shoved in at the last minute > makes them unreasonable. Now do as I asked and shut up. Actually, the security team was operating all the time under the expectation that the person should be a developer, despite the public statement on the list (as has already been said). Nor for that matter is it unreasonable for me to make a suggestion late in the day; it is for the appropriate people to decide whether or not they want to take the suggestion--where that is the security team--and I'm happy to let them take whatever suggestions I might offer and do with them what they think fit. As for why I didn't bring it up sooner: I simply hadn't noticed it sooner. I don't therefore void my right to bring it up, though the security team would be well within its rights to decide that it's too late to change things. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > On 22 Oct 2001, Thomas Bushnell, BSG wrote: > > >John Galt <[EMAIL PROTECTED]> writes: > > > >> I take it then that you volunteer. If not, shut up. Throwing artifical > >> barriers at this office isn't going to add volunteers. > > > >How is it a barrier? > > It's an extra qualification. It's one that until you objected, didn't > exist. My point still stands: if you want to add qualifications, add them > by "raising the bar" and volunteering yourself. I think it's an entirely appropriate qualification. But it's no barrier: it simply requires that we know who the person is and that they share our commitments. I think those are reasonable things to expect. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > I take it then that you volunteer. If not, shut up. Throwing artifical > barriers at this office isn't going to add volunteers. How is it a barrier?
Re: Questions regarding the Security Secretary Position
John Galt <[EMAIL PROTECTED]> writes: > I take it then that you volunteer. If not, shut up. Throwing artifical > barriers at this office isn't going to add volunteers. How is it a barrier? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions regarding the Security Secretary Position
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Sun, Oct 21, 2001 at 09:23:03AM -0700, Thomas Bushnell, BSG wrote: > > > Martin Schulze <[EMAIL PROTECTED]> writes: > > > > > Q: Is a requirement being a Debian developer? > > > > > >No. It is my understanding that it would be good to have "fresh > > >blood" in the team. Working on security can cost a lot of time, > > >thus it could even be helpful not being a Debian developer since > > >that implies active package maintenance as well. However, > > >similar knowledge is very helpful, and may be required when > > >working on issues. > > > > I think the security secretary, if we have one, should be a Debian > > developer. > > We have two of them, and they are both card-carrying developers. Sorry; I was referring to the Q&A, not the present incumbents.
Re: Questions regarding the Security Secretary Position
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Sun, Oct 21, 2001 at 09:23:03AM -0700, Thomas Bushnell, BSG wrote: > > > Martin Schulze <[EMAIL PROTECTED]> writes: > > > > > Q: Is a requirement being a Debian developer? > > > > > >No. It is my understanding that it would be good to have "fresh > > >blood" in the team. Working on security can cost a lot of time, > > >thus it could even be helpful not being a Debian developer since > > >that implies active package maintenance as well. However, > > >similar knowledge is very helpful, and may be required when > > >working on issues. > > > > I think the security secretary, if we have one, should be a Debian > > developer. > > We have two of them, and they are both card-carrying developers. Sorry; I was referring to the Q&A, not the present incumbents. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: URGENT RESPONSE!
"Scott Henson" <[EMAIL PROTECTED]> writes: > Just out of curiosity, but isnt this comercicial spam and subject to > Debian's Spam policy... I dont know.. maybe debian should go to collect its > money from this person. It's not commercial, for the simple reason that it's a serious crime. If they're willing to try and steal thousands of dollars by such fraud, I think it's pretty unlikely they'll pay Debian anything.
Re: Questions regarding the Security Secretary Position
Martin Schulze <[EMAIL PROTECTED]> writes: > Q: Is a requirement being a Debian developer? > >No. It is my understanding that it would be good to have "fresh >blood" in the team. Working on security can cost a lot of time, >thus it could even be helpful not being a Debian developer since >that implies active package maintenance as well. However, similar >knowledge is very helpful, and may be required when working on >issues. I think the security secretary, if we have one, should be a Debian developer. But it doesn't have to be someone who is already a Debian developer, and I have no objection to fast-tracking their application.
Re: URGENT RESPONSE!
"Scott Henson" <[EMAIL PROTECTED]> writes: > Just out of curiosity, but isnt this comercicial spam and subject to > Debian's Spam policy... I dont know.. maybe debian should go to collect its > money from this person. It's not commercial, for the simple reason that it's a serious crime. If they're willing to try and steal thousands of dollars by such fraud, I think it's pretty unlikely they'll pay Debian anything. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions regarding the Security Secretary Position
Martin Schulze <[EMAIL PROTECTED]> writes: > Q: Is a requirement being a Debian developer? > >No. It is my understanding that it would be good to have "fresh >blood" in the team. Working on security can cost a lot of time, >thus it could even be helpful not being a Debian developer since >that implies active package maintenance as well. However, similar >knowledge is very helpful, and may be required when working on >issues. I think the security secretary, if we have one, should be a Debian developer. But it doesn't have to be someone who is already a Debian developer, and I have no objection to fast-tracking their application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HARASS ME MORE.........
"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes: > Please don't do that. That's an incredibly rude practice. The people > never asked for your opinion on operating systems or Microsoft. What > about those who use a Windows mailer at their job and have no choice to > do otherwise. (and please don't suggest changing jobs, that's not > necessarily realistic) Sorry, changing jobs is realistic. People are *responsible* for what they do, and the defense of "but it's only my job" does not aquit. Instead, it says "not only do I do bad things, but I am also bribable". Thomas
Re: HARASS ME MORE.........
"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes: > Please don't do that. That's an incredibly rude practice. The people > never asked for your opinion on operating systems or Microsoft. What > about those who use a Windows mailer at their job and have no choice to > do otherwise. (and please don't suggest changing jobs, that's not > necessarily realistic) Sorry, changing jobs is realistic. People are *responsible* for what they do, and the defense of "but it's only my job" does not aquit. Instead, it says "not only do I do bad things, but I am also bribable". Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Juha Jäykkä <[EMAIL PROTECTED]> writes: > Any other ideas? Or is it really safe to allow root logins to sshd? > It is just an old rule of thumb that root must never log on over the > wire but that may be old news from times of telnet - never had any > need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does.
Re: shared root account
Juha Jäykkä <[EMAIL PROTECTED]> writes: > Any other ideas? Or is it really safe to allow root logins to sshd? > It is just an old rule of thumb that root must never log on over the > wire but that may be old news from times of telnet - never had any > need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Robert Mognet <[EMAIL PROTECTED]> writes: > Mailcrypt isn't part of Debian, so it's not the responciblity of the > security team. However, it *ought* to be part of Debian, and indeed, it now is IIUC.
Re: gnupg problem
Robert Mognet <[EMAIL PROTECTED]> writes: > Mailcrypt isn't part of Debian, so it's not the responciblity of the > security team. However, it *ought* to be part of Debian, and indeed, it now is IIUC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Hubert Chan <[EMAIL PROTECTED]> writes: > But for the situation we are talking about, they would need to have the > same interface, since a PGP front end needs to interact with the PGP > program. So in the PGP front end depends on the "pgp implementation" > virtual package, but the PGP program doesn't have an interface that > works with that front end, you get a broken distribution. No, you're wrong. The mailcrypt front end, for example, works with both. And that's the case we are talking about.
Re: gnupg problem
Florian Weimer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > > > It's clear to me we need a virtual package for "pgp implementation" > > that both pgp and gnupg can provide. > > Uh, this doesn't work. Even the PGP releases aren't completely > compatible among themselves, and GnuPG has got a completely different > command line interface. > > This makes as much sense as a virutal package "scripting language" > which is provided by Python, Perle, Guile, and others. In order to have a virtual package, there is absolutely no need that the various packages that provide it have compatible or even remotely similar interfaces. Consider, for example, the "editor" virtual package.
Re: gnupg problem
Hubert Chan <[EMAIL PROTECTED]> writes: > But for the situation we are talking about, they would need to have the > same interface, since a PGP front end needs to interact with the PGP > program. So in the PGP front end depends on the "pgp implementation" > virtual package, but the PGP program doesn't have an interface that > works with that front end, you get a broken distribution. No, you're wrong. The mailcrypt front end, for example, works with both. And that's the case we are talking about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Florian Weimer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > > > It's clear to me we need a virtual package for "pgp implementation" > > that both pgp and gnupg can provide. > > Uh, this doesn't work. Even the PGP releases aren't completely > compatible among themselves, and GnuPG has got a completely different > command line interface. > > This makes as much sense as a virutal package "scripting language" > which is provided by Python, Perle, Guile, and others. In order to have a virtual package, there is absolutely no need that the various packages that provide it have compatible or even remotely similar interfaces. Consider, for example, the "editor" virtual package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Christian Kurz <[EMAIL PROTECTED]> writes: > Would you please check the next time either your box running unstable or > packages.debian.org? If you had done this before, you would have > noticed, that mailcrypt from stable also offered an interface to PGP > (pgp-i, pgp-us and pgp5i are the matching debian packages, which have > been in non-free and maybe still are there). But this has been changed > since quite some time, so that that mailcrypt from testing or unstable > only support GnuPG. Therefor the package has been moved into non-us/main > and is residing there. Thanks for clarifing your facts before. As should be obvious, I'm talking about *potato*. We're talking here about security maintenance on *potato*, not some later system.
Re: gnupg problem
Christian Kurz <[EMAIL PROTECTED]> writes: > Would you please check the next time either your box running unstable or > packages.debian.org? If you had done this before, you would have > noticed, that mailcrypt from stable also offered an interface to PGP > (pgp-i, pgp-us and pgp5i are the matching debian packages, which have > been in non-free and maybe still are there). But this has been changed > since quite some time, so that that mailcrypt from testing or unstable > only support GnuPG. Therefor the package has been moved into non-us/main > and is residing there. Thanks for clarifing your facts before. As should be obvious, I'm talking about *potato*. We're talking here about security maintenance on *potato*, not some later system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Philipp Schulte <[EMAIL PROTECTED]> writes: > deb http://ftp.debian.org/debian dists/proposed-updates/ Thanks. What is the corresponding deb-src line? I tried deb-src http://ftp.debian.org/debian dists/proposed-updates/ but that blew big chunks. Thomas
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > it belongs in non-US/main since that is where gnupg lives. but since > its not there its not part of debian. also for it to go into > non-US/main it must remove its dependency on non-free pgp, and > exclusivly depend on gnupg. It's clear to me we need a virtual package for "pgp implementation" that both pgp and gnupg can provide.
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > nobody ever said anything else. fixed mailcrypt is in proposed-updates, so I > don't see the problem. maybe it was not at the exact time, as gnupg fix ... Perhaps I'm confused. Please tell me what sources.list line I should use to get proposed updates.
Re: gnupg problem
Philipp Schulte <[EMAIL PROTECTED]> writes: > deb http://ftp.debian.org/debian dists/proposed-updates/ Thanks. What is the corresponding deb-src line? I tried deb-src http://ftp.debian.org/debian dists/proposed-updates/ but that blew big chunks. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > it belongs in non-US/main since that is where gnupg lives. but since > its not there its not part of debian. also for it to go into > non-US/main it must remove its dependency on non-free pgp, and > exclusivly depend on gnupg. It's clear to me we need a virtual package for "pgp implementation" that both pgp and gnupg can provide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > nobody ever said anything else. fixed mailcrypt is in proposed-updates, so I > don't see the problem. maybe it was not at the exact time, as gnupg fix ... Perhaps I'm confused. Please tell me what sources.list line I should use to get proposed updates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 02:30:19PM -0700, Thomas Bushnell, BSG wrote: > > > you know, what I've ment. Debian *distribution* is main and non-US/main > > > > Thene where are the security releases? > > security.debian.org > > mailcrypt is not in debian, its in contrib. niether contrib or > non-free are part of debian. > > if gnupg broke deps on a another package in main i think you would > have a point, but it broke something outside the distribution which is > beyond the concerns of the security team, they only need to care about > the distribution which is main and non-US/main. I think we have a point here too... I mean, let's actually do the best we can, instead of doing as little as possible. In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main.
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 02:30:19PM -0700, Thomas Bushnell, BSG wrote: > > > you know, what I've ment. Debian *distribution* is main and non-US/main > > > > Thene where are the security releases? > > security.debian.org > > mailcrypt is not in debian, its in contrib. niether contrib or > non-free are part of debian. > > if gnupg broke deps on a another package in main i think you would > have a point, but it broke something outside the distribution which is > beyond the concerns of the security team, they only need to care about > the distribution which is main and non-US/main. I think we have a point here too... I mean, let's actually do the best we can, instead of doing as little as possible. In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 12:11:39PM -0700 , Thomas Bushnell, BSG wrote: > > Petr Cech <[EMAIL PROTECTED]> writes: > > > > > On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: > > > > Debian is about a *distribution* and not a random assemblage of > > > > > > OK, distribution. That's dists/potato/main/binary-/Packages > > > > If that's the *only* thing that counts as the Debian distribution, > > then we have no security team at all! > > you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases?
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: > > Debian is about a *distribution* and not a random assemblage of > > OK, distribution. That's dists/potato/main/binary-/Packages If that's the *only* thing that counts as the Debian distribution, then we have no security team at all! Debian ought to offer security updates for the stable distribution, but it doesn't. Instead, it is only offering security updates for the packages in the stable distribution. That's an understandable oversight, but it is an oversight, and I think it should be corrected. We are not just about packages, we are about the way they work together to form a coherent whole.
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 12:11:39PM -0700 , Thomas Bushnell, BSG wrote: > > Petr Cech <[EMAIL PROTECTED]> writes: > > > > > On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: > > > > Debian is about a *distribution* and not a random assemblage of > > > > > > OK, distribution. That's dists/potato/main/binary-/Packages > > > > If that's the *only* thing that counts as the Debian distribution, > > then we have no security team at all! > > you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > gnupg is installable, if you remove mailcrypt. ;-) As explained in my previous mail, that is only adequate if the security team exists to support security in packages, but not the distribution as a whole.
Re: gnupg problem
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Installing mailcrypt on security.debian.org would immediately suggest > that mailcrypt itself has a security problem, which is not true. > It's a bit of a catch 22. Well, this is a general problem then, which the security team should think about. The fact that mailcrypt is in contrib means it's a little less important in this particular case, but nontheless, it's a real problem. Debian is about a *distribution* and not a random assemblage of .deb's. The security team exists to support the rapid response to security needs for the *distribution*, and not just one package. So my premise is that a user who tracks stable and security should benefit from security fixes. When the security team does what was done with gnupg, the *distribution* has not gotten decent security support, even if one package has. Perhaps one solution is to split the security archive into two pieces; one for the actual packages that have security holes, and another for other packages that must be installed on a stable system in order to take advantage or otherwise use fully the former. Thomas
Re: gnupg problem
Petr Cech <[EMAIL PROTECTED]> writes: > On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: > > Debian is about a *distribution* and not a random assemblage of > > OK, distribution. That's dists/potato/main/binary-/Packages If that's the *only* thing that counts as the Debian distribution, then we have no security team at all! Debian ought to offer security updates for the stable distribution, but it doesn't. Instead, it is only offering security updates for the packages in the stable distribution. That's an understandable oversight, but it is an oversight, and I think it should be corrected. We are not just about packages, we are about the way they work together to form a coherent whole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Ethan Benson <[EMAIL PROTECTED]> writes: > gnupg is installable, if you remove mailcrypt. ;-) As explained in my previous mail, that is only adequate if the security team exists to support security in packages, but not the distribution as a whole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
