Re: Concerns about Security of packages in Debain OS and the Operating system itself.
> they get one and only one chance to do something that stupid. So the answer is that we have no way of preventing a developer from intentionally sabotaging a package in any / as many ways as they choose and the only risk to them is losing their uploader access after the fact? >the response is swift: there was a debian developer wrongfully arrested for running a TOR exit node. their key was revoked immediately. How was this incident detected? On Mon, May 23, 2022 at 12:07 PM lkcl wrote: > On Mon, May 23, 2022 at 7:59 PM Adam McKenna wrote: > > You are talking about a deterrent though. I think the question is, > > what if someone cares more about their political cause than > > retaining their uploader access? > > they get one and only one chance to do something that stupid. > > > What if someone's keys are compromised > > the response is swift: there was a debian developer wrongfully > arrested for running a TOR exit node. their key was revoked > immediately. > > l. >
Re: Concerns about Security of packages in Debain OS and the Operating system itself.
> anyone stupid enough to abuse their position may only do so once, at which point their GPG key is revoked. You are talking about a deterrent though. I think the question is, what if someone cares more about their political cause than retaining their uploader access? What if someone's keys are compromised and an attacker uploads a compromised package? Do we have ways of detecting these breaches or do we rely solely on user reports? On Mon, May 23, 2022 at 11:22 AM lkcl wrote: > On Mon, May 23, 2022 at 6:28 PM Adam McKenna wrote: > > > > > i believe the answer is in the question. debian is based on > distributed trust. i did the analysis (took 3 weeks): it is literally the > only distro in the world with an inviolate chain of trust from a large > keyring dating back 20 years that is itself GPG-signed as a package, with a > package distribution chain from source where all components within the > chain up to release are unbroken and inviolate. > > > > This is not an answer to the question though, OP was asking how we > prevent abuse of that trust. > > reputation, and potentially criminal and civil proceedings. > > all identities are known, and inviolate-known [through the > above-described chain]. > anyone stupid enough to abuse their position may only do so once, at which > point their GPG key is revoked. > > given that GPG key-signing parties require people's real-world identities > to be known, it is easy to track down who signed whose key (it's right > there in the keyring-archive], and request that the signer provide > assistance > to the relevant authorities in proving that real-world identity. > > this will sufficiently piss off those people that trusted them that they > will > be unlikely to work with them ever again [reputation] > > in addition there is the Debian Trademark which if brought into disrepute > through abuse could be utilised to seek damages against the perpetrator. > > bottom line is that it would be a spectacularly stupid thing to do to > violate > the trust and responsibility of being a Debian Maintainer, and the really > interesting bit to me is that this all works in an entirely distributed > manner > and can all entirely be done entirely without a single centralised > authority, > i.e. *not* having to trust f*g google or f*g github with anyone's > real-world identity in any way shape or form. > > l. >
Re: Concerns about Security of packages in Debain OS and the Operating system itself.
> i believe the answer is in the question. debian is based on distributed trust. i did the analysis (took 3 weeks): it is literally the only distro in the world with an inviolate chain of trust from a large keyring dating back 20 years that is itself GPG-signed as a package, with a package distribution chain from source where all components within the chain up to release are unbroken and inviolate. This is not an answer to the question though, OP was asking how we prevent abuse of that trust. On Sun, Apr 17, 2022 at 12:42 PM lkcl wrote: > > > On 17/04/2022 19:26, Satvik Sinha wrote: > > > abusing your OS's reputation? > > i believe the answer is in the question. debian is based on distributed > trust. i did the analysis (took 3 weeks): it is literally the only distro > in the world with an inviolate chain of trust from a large keyring dating > back 20 years that is itself GPG-signed as a package, with a package > distribution chain from source where all components within the chain up to > release are unbroken and inviolate. > > take ubuntu for example: whilst it has the exact same technology the size > of the developer pool, comprising the web of trust, is both much smaller > and also controlled by one Corporation: Canonical. Canonical says "jump", > the developers ask "how high". > > take Suse, Fedora etc: their RPM packages break the chain of trust by > failing to properly include a GPG Signature of the Release (i do not recall > the exact details, i did the analysis 4 years ago) > > take Archlinux: their community is vulnerable to unverified github > repositories being abandoned, a hacker re-registering them, and a trojan > uploaded and distributed automatically. > > i won't even bother going into the absolute moronic practice of "trusting" > HTTPS: node, pypi, etc should be blindingly obviously untrustworthy, with > the website being a prime hacking target if nothing else. > > even GNU packages are hopelessly inadequately secure as far as social > engineering and hacking are concerned. > > debian is not a single centralised repository, it is controlled by no-one. > you have to compromise hundreds of independent developers before you make > any headway, and as a result it was trusted by e.g. the Venezuelan > Government as the basis for their own distro, many years ago. > > there is not even a centralised dependency on a website: packages may be > securely distributed by Carrier Pigeon or printed out on paper and OCR > scanned if you really want to because there is a full GPG Chain and > Checksums, right back to the source code. > > and that (GPG Chains) basically, is the key. anyone stupid enough to do > something stupid is going to be throwing away their reputation, not just > within the debian project as a maintainer, but for life. > > you abuse your position as a maintainer by putting in trojan code, because > that trojan package had to be GPG Signed, you have to make a *public and > irreversible declaration* which will remain in historical archives for the > rest of your life and beyond. > > this would result in catastrophic consequences for not just their > involvement in debian (which would be terminated with prejudice), but > because their GPG Signature on the trojan package is public, inviolate and > irrevocable, it would also have catastrophic consequences for their career > in IT because nobody would ever trust them in a position of responsibility, > ever again. they'd be flipping burgers for the rest of their life. > > fundamentally, then, you are assuming that there is "one controller of > debian", which is false. there are literally hundreds of *independent* > developers, all of whom know their responsibility, all of whom know that > they have all other independent developers keeping an eye on them. > > this makes debian pretty much the only distro that could be trusted to > remain true to humanity and to its principles and its charter. even when > some of them (you know who you are) are when it comes down to it not very > nice people, they can at least be trusted to do the right thing. > > l. > > > >
Re: Non-DD's in debian-legal
On Thu, Jun 15, 2006 at 10:27:08AM +1000, Anthony Towns wrote: > it's also possible to raise a variety of invalid concerns > in ways that require responses > their comments are only influential in so far as they persuade developers. These statements apply to both DD's and non-DD's. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
On Tue, Jun 13, 2006 at 03:11:42PM -0700, Adam McKenna wrote: > Likewise, there are plenty of DD's whose S/N ratio is pretty high, and are (pretty low, that is..) --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
On Thu, Jun 08, 2006 at 03:02:03PM +1000, Anthony Towns wrote: > Personally, I think non-DDs participating is great; the only problem > comes when that starts becoming a way for people who aren't members > of the project to block development; which can happen either by people > spending time arguing with non-DDs unnecessarily or by people thinking > that people speak for the project when disagreeing, though they don't. If people who aren't members are raising valid concerns that need to be addressed before development can proceed, we shouldn't reject that input on the basis of membership and call it "blocking development". Likewise, there are plenty of DD's whose S/N ratio is pretty high, and are guilty of what you are accusing non-DD's of doing. Both DD's and non-DD's troll, create flamewars, and otherwise cause issues that block development. Putting it in terms of DD's versus non-DD's is just prejudice and elitism at its worst. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys
On Thu, May 25, 2006 at 11:46:11AM -0500, Manoj Srivastava wrote: > But a number of people were taken in by this social > engineering crack and failed to ask for the real ID. How is it a 'crack' if the information on the ID was all accurate? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: Please reject to rule on the ndiswrapper question
On Sat, Mar 04, 2006 at 04:47:17PM -0800, Steve Langasek wrote: > Well, I agree with you that overruling the foundation documents is out of > scope for the technical committee; except the tech ctte has not been asked to > interpret or overrule the foundation documents. The Social Contract > mandates that the Debian system not require the use of non-free components, > but it doesn't go into any detail -- the distinction between "main", > "contrib", and "non-free" is only specified in Debian's technical policy. > It is this latter that we have been asked to rule on -- to "interpret the > interpretation", so to speak. IMHO, the Policy text is crystal clear. If that has undesirable implications, then it should be changed to say what it really means. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reject to rule on the ndiswrapper question
On Wed, Mar 01, 2006 at 01:03:56AM -0300, Henrique de Moraes Holschuh wrote: > They can consider it, obviously. They cannot overrule ftp-masters on this > matter, however. OTOH, ftp-masters may decide to listen to whatever the > ctte recommends, but they don't *have* to. They can consider it individually, or even jointly, and make individual recommendations to ftpmaster like any other developers. It would be inappropriate for them to make an official statement about it. I tried, poorly, to make this point in the other thread. Thanks for elucidating. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Wed, Mar 01, 2006 at 12:06:51AM +0100, Eduard Bloch wrote: > However, some people like to define "Debian" just as "main" and use the > main section as the single acceptable set of free software. Which > is, of course, wrong, because requirements for contrib are defined by > DFSG, exactly as for main. According to the SC, contrib is not part of Debian. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote: > One point that nobody raised so far: _reliable_ working on ndiswrapper > depends on the 16k-stack patch that is not available in Debian AFAIK. > Without that patch, drivers requiring ndiswrapper (being free or not) > only work by pure chance. So whatever the Depends: line says, > ndiswrapper for any practical purposes depends on software that is not > in main. I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have never heard of the '16k-stack patch'. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote: > But I don't know; everyone seems to be dancing around the actual > question: are there any free drivers for which ndiswrapper is useful? > CIPE has been mentioned, but it has also been said that ndiswrapper > was not useful in this particular case. [EMAIL PROTECTED] --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:03:25PM -0800, Thomas Bushnell BSG wrote: > The definition of "contrib" is that it is for a package which is a > wrapper for non-free-software. [EMAIL PROTECTED] --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 04:25:01PM -0800, Thomas Bushnell BSG wrote: > So I'm still at a loss; the only use of ndiswrapper, on a > free-software-only system, seems to be CIPE. Is that correct, or is > there some other? There are plenty of others to be dreamed up. AFAIK, nobody is compiling evidence that any of those others are actually being done, however, the ndiswrapper-in-main proponents (including myself) are arguing that that is beside the point. Packages are not required to be useful in order to be in Debian. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: > I guess I think the right test is: "Is this package useful in a system > with only free software on it?" Useful is a pragmatic question; if > every proposed use has a better solution already ready and > implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote: > This lists several signs that a package requires another package, but > it is not presented as an exhaustive list. If you use a broad > definition of "require", it is reasonable to exclude ndiswrapper from > main on the grounds that there are no NDIS drivers in main. I don't think this is a valid argument, the requirement is that it "must not" depend on software outside of main, not that it "must" have software in main on which to depend. There are in fact free NDIS drivers available. There have been various, uncompelling arguments offered so far as to why these free NDIS drivers do not "count" for satisfying policy. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote: > The tech-ctte is there to address technical disputes. This isn't a technical dispute, it's an ideological one. The technical details very clearly support keeping ndiswrapper in main. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: > The question is not whether there is such a dependency declared; the > question is whether the software is useful without the use of non-free > software. All right, who pushed the 'thread reset' button? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: > Let's see, maybe you didn't read the paragraph where I said: I did. > Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote: > Adam McKenna <[EMAIL PROTECTED]> writes: > > > The question is not what problems it would cause. The problems are side > > effects. It should stay in main because it is free software that is able to > > be used by at least some subset of our users, without any non-free software. > > Ok, this seems to be a simple factual question, and I have been unable > to see the answer despite careful reading of the thread and the bug > log. > > What is the subset of our users which would find ndiswrapper useful, > without the use of free software? I have heard some say that there > are no free drivers around for ndiswrapper to wrap. If that's true, > then wouldn't that make the subset in question the empty set? Or is > there some use to ndiswrapper without a driver to wrap with it? You read the thread so closely that you missed all the references to CIPE? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:14:54PM -0800, Thomas Bushnell BSG wrote: > So I said "why not put it in contrib" and you said "because then it > can't be used by the installer". Now you are saying that even if this > wasn't a problem, it still shouldn't be in contrib. Correct. > Why? I'm flabbergasted that it matters at all. What does it matter? > If it were put in contrib (by accident, say), how would this cause a > problem, assuming that the installer problem was fixed? What specific > problems are you concerned about? The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. In addition, there are other potential issues with having it in contrib, one of which is inaccessibility to the installer. The overall effect is decreased utility for our users. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote: > Ok, then we could put selected packages from contrib on the first CD, > provided they are DFSG-free, without causing any problems. Since > ndiswrapper certainly is DFSG-free, why not do this? Because ndiswrapper belongs in main. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: > It seems to me that there is no reason ndiswrapper can't be available > to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote: > On Feb 27, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > Better we spend our time actually supporting the hardware with free > > software. > There is almost none. At most you can choose if you want to get your > proprietary firmware on board or not. Not only that, there are obviously other considerations when buying a laptop than whether the wireless card has free drivers or not. Things such as price, combination of features, etc. Our users shouldn't be forced to buy a GNU anointed laptop (if such a thing even exists) in order to get support for their devices. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 10:33:47AM -0800, Thomas Bushnell BSG wrote: > Adam McKenna <[EMAIL PROTECTED]> writes: > > > Taking it out of main moves us in the wrong direction if our goal is to > > give our users a *usable* operating system, as opposed to some kind of > > 'proof of concept' OS that some people here seem to want to create, but > > that the majority of our users will not want to use. > > How does putting ndiswrapper in contrib make Debian less usable? Do you actually read entire threads for context when you reply, or do you just pick particular posts to nitpick and needle people over? Don't answer that, it's rhetorical. As I said earlier, it prevents us from integrating ndiswrapper-supported devices into the installer so that users can enable their wireless devices during install. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 27, 2006 at 03:33:51PM +0100, Gabor Gombas wrote: > I simply can not understand why you all are making such a big fuss about > ndiswrapper being in contrib or in main. Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Fri, Feb 24, 2006 at 09:56:46AM -0800, Thomas Bushnell BSG wrote: > I think this is clearly incorrect. The DFSG and the SC do not say > anything about the requirements for main that I can see. > > And it is the *job* of the tech-ctte to resolve disputes. I don't enjoy speaking with you, and I'm going to stop now. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote: > Help me out then. You seemed to suggest that not putting ndiswrapper > in main would be to "ignore rules that are very clearly laid out in > the SC and DFSG." I suggested that the CTTE overriding the developer's judgement in this instance would be an abuse of power, since the DFSG and SC (not to mention policy) clearly spell out the requirements for main, and ndiswrapper clearly meets them. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Wed, Feb 22, 2006 at 05:55:01PM -0800, Thomas Bushnell BSG wrote: > Adam McKenna <[EMAIL PROTECTED]> writes: > > > As far as the second statement being the reason that most of us want > > ndiswrapper in main, that may be true, but it is no excuse to ignore rules > > that are very clearly laid out in the SC and DFSG. > > I'm a little confused here. Not surprising. > How does putting ndiswrapper in contrib violate the SC or the DFSG? Who said that it did? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 05:01:21PM -0800, Steve Langasek wrote: > Well, aside from not believing that anyone is going to use CIPE under > ndiswrapper (without someone stepping forward and testifying that this is > the case for them), I see a distinction between "wine is necessary in order > for you to run app $foo on Debian" and "ndiswrapper is necessary in order > for you to run Debian on hardware $foo". That is a very fine distinction, if it's a distinction at all, considering that the latter statement can easily be rewritten "ndiswrapper is necessary in order for you to load drivers for hardware $foo", which is almost identical to the former. Also, the latter statement isn't really 100% valid, since Debian will still run without the ndiswrapper driver. It just won't be able to connect to wireless networks. As far as the second statement being the reason that most of us want ndiswrapper in main, that may be true, but it is no excuse to ignore rules that are very clearly laid out in the SC and DFSG. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:20:47AM -0800, Adam McKenna wrote: > On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: > > Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the > > latter of which is considering a resolution to move it right now. I'm > > not sure why you'd rather continue making bald assertions I've already > > indicated I don't accept, than actually talk about it properly? > > Because you're wrong. And I should add that these arguments have already been fairly soundly refuted and rejected by others who actually took them seriously, including other members of ctte. You don't appear to want to be convinced. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: > Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the > latter of which is considering a resolution to move it right now. I'm > not sure why you'd rather continue making bald assertions I've already > indicated I don't accept, than actually talk about it properly? Because you're wrong. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: > Whether CIPE and Windows driver development "count" isn't a fact, it's > an opinion. Since they're both thoroughly pointless, I don't think they do. The fact is it doesn't matter whether they 'count'. They exist, and that is enough to fulfill the requirement. If you have a problem with that, you are free to try to change the rules. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: > > So give a reference or Message-ID of (what you consider) a sound argument > > that is not similar to "CIPE, and Windows driver developers who want to test > > on Linux don't count." > > And that's what I mean -- there's nothing unsound about saying those cases > don't > count; you just disagree with it. The facts disagree with it. *That* is what makes it unsound, not what I think. The reality is that we can't imagine all the uses our users might have for this software, and since it unambiguously fulfills the requirements, it should stay in main. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 20, 2006 at 05:43:59PM +0100, Robert Millan wrote: > On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: > > > Please also stop insulting ndiswrapper users and developers by calling > > > it a "warez wrapper". > > Actualy, since such "ndis drivers" are often provided with very restrictive > licensing, or with no licensing at all, I have my doubts that inserting them > into Linux kernel is a legal activity. > > This is of no concern to Debian though, but makes the name "warez" very > appropiate. "warez" is a slang term for software that has been copied illegally. It does not refer to non-free software that has been copied or obtained legally. Please get a clue. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 07:04:27PM +1000, Anthony Towns wrote: > > In this case, even in the absence of free NDIS > > drivers, one could argue that the utility of having ndiswrapper in main > > (especially if it is integrated into the install) outweighs any potential > > drawbacks (and since the only drawback I can see is pissing off > > zealots/fundamentalists, I'd be all for it.) > > One could argue many things, but since we're trying to make a free > operating system, maybe we could resist that temptation. I assume, > btw, you count me as one of the zealots/fundamentalists you're eager to > piss off. Don't assume things, it can cloud your judgement. Our goal is to make a free *and useful* operating system. If you believe that keeping a piece of completely free software out of main that would allow our users to enable their wireless ethernet cards during installation is the right thing to do, even though the package is completely usable without any non-free code, that makes you sound pretty backwards to me. > > What is relevant is that ndiswrapper technically meets all requirements for > > inclusion into main. Did I miss a solid argument refuting that assertion? > > I doubt it; I think you're just confusing "argument that I disagree with" > with "argument that is unsound or irrational". So give a reference or Message-ID of (what you consider) a sound argument that is not similar to "CIPE, and Windows driver developers who want to test on Linux don't count." --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 03:36:16PM +1000, Anthony Towns wrote: > On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote: > > IMHO, the main purpose of contrib is to avoid shipping things on CD that > > depend on programs in non-free. It is not a section that we put programs in > > in order to 'punish' them for depending on non-free code. > > That's a mistaken view; the purpose of contrib is to give us a place > to ship free software that we can't ship in Debian proper (ie, main) > because it would violate "We will never make the system require the use > of a non-free component" or, historically, "... we will never make the > system depend on an item of non-free software". Practically, it's to avoid shipping things on our CDs that depend on stuff that's not on our CDs. In this case, even in the absence of free NDIS drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) Thankfully, there is no need to make that argument, since at least one free NDIS driver exists (the aforementioned CIPE). > > ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, > > The "Depends:" field isn't really that relevant. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 20, 2006 at 09:13:15PM -0800, Adam McKenna wrote: > The driver should stay in main and hooks should be written into the s/driver/package.. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote: > And for fuck's sake, stop filling up my inbox w/ this crap. I'm not > doing a thing unless either a) you people come to a consensus on the > issue (which you have not in the past threads, and probably never will), > or b) a governing body like the ctte tells me that it should be in > contrib. Otherwise, it's staying right where it is. Honestly, I could > care less whether it's in contrib or main, but it was a decision that > was made long ago, and I see no reason to make the change. The driver should stay in main and hooks should be written into the installer so that our users can easily enable their wireless cards during installation. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: > > Because it's free software that processes asm input, and there is a > significant > amount of useful, free i386 asm that makes nasm necessary ? > > I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If > it > isn't, show me a free, non-toy, non-POC driver that would prove otherwise. This is beside the point. IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, so there's no reason it can't go in main. In fact, since it would be tremendously useful to be able to activate wireless ethernet devices with non-free drivers (from floppy/cd) during the install process, I'd say that it makes even more sense for ndiswrapper to go into main (and maybe even into base). --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, Feb 13, 2006 at 03:54:23PM +0100, Sven Luther wrote: > No, like chosing ati over nvidia for graphic cards, or silicon image over > others for SATA cards. Wait a minute, did I miss a memo? ATI isn't the devil anymore? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Fri, Feb 10, 2006 at 12:22:34PM +, Roger Leigh wrote: > Several folks seem to wish to re-ignite the debate of whether or not > the changes were "editorial" or not. Whether it was or was not, it's > now over and done with. This GR is a separate, albeit related, issue. The changes could only have been referred to as 'editorial' if wide consensus and understanding had already been reached about their effects. I think it's fair to say that this was not the case at the time. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing default ping
On Tue, Oct 25, 2005 at 09:44:40PM +0200, Marco d'Itri wrote: > On Oct 25, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > >> Even if you only want to support Linux, it's *STILL* wrong to include > > >> the kernel headers right in the package. > > > It's not. > > What if they are *wrong* then? > This is not supposed to happen. Famous last words... --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bruce Perens hosts party at OSCON Wednesday night
On Tue, Aug 02, 2005 at 06:32:44PM -0500, Adam Heath wrote: > Unsolicited Commercial Email. Please pay the standard $2000 fee for > advertisments on Debian mailing lists. It appears as though this fee is no longer policy[1].. Looks like you're going to have to block Bruce from posting and/or report him to the relevant authorities if you want satisfaction. --Adam [1] http://www.debian.org/MailingLists/#ads -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installation process
On Wed, Aug 03, 2005 at 02:18:01PM +0200, Lionel Elie Mamane wrote: > > - > > Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger > > Téléchargez le ici ! > > Non merci, je ne suis pas intéressé. Par contre, Debian est assez > opposé à ce que l'on utilise ses listes de diffusion pour de la > publicité: http://www.nl.debian.org/MailingLists/index.fr.html#ads > (D'autant plus pour un programme non libre.) Si vous pouvez l'éviter, > ça nous rendrait plus content. Merci d'avance. That signature is appended by Yahoo mail, he can't do anything about it. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Thu, Jun 16, 2005 at 01:00:17PM -0400, Eric Dorland wrote: > > But I don't think it's good for our users for Debian to have rights > that the user don't have. We are only concerned with the rights that apply to the software, not the name. The users have all of the same rights to the software that Debian has. How many times does this need to be said? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
On Wed, May 18, 2005 at 03:38:33AM -0400, Glenn Maynard wrote: > This just seems like change for the sake of change, with trivial benefits, > if any. I agree, and I admit to not having read this whole thread, but has anyone made a serious argument as to why we need yet another directory for non-user executables? It seems to me that /usr/sbin would serve just fine for this. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
removing ipfwadm
I am not sure whether the ipfwadm package should be removed. Kernels up to 2.4 still have support for ipfwadm filtering rules, so theoretically people could still be using it with current kernels. cc'ing debian-devel. If the consensus there is that the package should be removed, I'll request its removal. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Thu, Mar 24, 2005 at 12:48:14PM -0600, Adam Majer wrote:
> Andreas Barth wrote:
>
> > Actually, I believe the Debian project as whole _wants_ to getting
> >
> >software released. That was at least the decision in all GRs where
> >people didn't hide the intents ("editorial changes").
>
> Indeed. These types of changes are akin to changing a country's
> constitution and calling these "editorial changes" bill. But then again
> we can always change it back and call the change "editorial changes" as
> well.
No matter how you feel about the term "editorial changes", it seems to me
that if these changes were really so bad, and the majority of the project is
now against them, they should be easy enough to roll back.
All we need is another GR. Stop bitching and propose one.
--Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 01:25:59PM -0800, Brian Nelson wrote: > Can we *please* ban Ingo from d-d? He's been a huge pain in the ass on > this list for months now, has absolutely nothing constructive to > contribute, and is actively trying to subvert the project. How do you propose to 'ban' someone from d-d? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux Core Consortium
On Fri, Dec 17, 2004 at 10:05:00AM +0100, Wouter Verhelst wrote: > Op do, 16-12-2004 te 17:07 -0800, schreef Adam McKenna: > > On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: > > > I think Wouter is only asking for reciprocity here. If they don't care > > > about his concerns why should he care about theirs ? Or alternatively > > > "not caring" is a freedom. > > > > We care because our priorities are our users and free software. Just > > because > > someone works for an ISV or develops on/for proprietary software does not > > make them a second class user. > > > > That said, I am not arguing for or against LCC, I just didn't like the tone > > of Wouter's e-mail, or the sentiment implied in it. > > I did not intend that sentiment; I explained what I meant to say in a > new thread. I apologize for misinterpreting your sentiment. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Linux Core Consortium
On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: > I think Wouter is only asking for reciprocity here. If they don't care > about his concerns why should he care about theirs ? Or alternatively > "not caring" is a freedom. We care because our priorities are our users and free software. Just because someone works for an ISV or develops on/for proprietary software does not make them a second class user. That said, I am not arguing for or against LCC, I just didn't like the tone of Wouter's e-mail, or the sentiment implied in it. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 09:25:38PM +0100, Wouter Verhelst wrote: > Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock: > > We've heard > > directly from the biggest ISVs that nothing short of a common > > binary core will be viable from their point of view. > > Well, frankly, I don't care what they think is 'viable'. > > 'ISV' is just another name for 'Software Hoarder'. I thought Debian was > about Freedom, not about "how can we make the life of proprietary > software developers easy?" Regardless of how you feel about proprietary software, it is someone else's work and they are free to sell or license it as they see fit. I don't see how someone advocating "freedom" can in the same (virtual) breath presume to dictate what other people do with their work. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Quote: Debian and Democracy at Advocato.org
On Wed, Oct 08, 2003 at 10:13:53PM +0200, Peter Makholm wrote: > And if you want to discusse anyway then please do it on > debian-projects og maybe rather debian-couriosa where it belongs. I > has nothing to do with developing Debian (the distribution). Why even waste debian bandwidth on it? Advogato has discussion boards. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: > > Because it is the only thing I could find that reflects Debian's > > take on security fixes: feature backports are to be avoided. > > That's because it's the position of the *Security Team*, and is > certainly not binding on other developers who are making changes to > packages in *unstable*. I don't see how the package being in unstable affects any part of this argument. Will the feature backport be less desirable when the kernel-source package is released in a stable revision of Debian? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Timeout of ITP's
On Thu, Sep 25, 2003 at 08:38:53PM +0200, Søren Boll Overgaard wrote: > Hi, > > An ITP[1] on thunderbird[2] was originally submitted to the BTA back in > June. Since then, for various reasons, no package has been uploaded, and > someone other then the original submitter of the ITP has committed to > uploading a package. However, nothing has happened for nearly a month > now, and the ping I sent just over a week ago has gone unanswered. > > So, my question is, how long should an ITP be allowed to just sit there > before someone else (in this case myself or anyone else who would be > interested) can go ahead and "hijack" it? I couldn't seem to find any > relevant information regarding this in the developers reference, the > policy manual or on google. Thunderbird is too important a package for us not to be distributing. I think a month is more than generous. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: MEI Whitelist Autoresponse
On Fri, Aug 29, 2003 at 09:20:53AM +1000, Russell Coker wrote: > The comparison to mailing list software makes no sense. Maybe not in the context of viruses, but for the "Joe Job" problem it does. Viruses can and should be filtered out before they reach the C-R system. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: > the point that you keep on missing is that TMDA and similar programs send > "confirmation" emails to innocent third-parties who did *NOT* send an email. Really? > TMDA and all C-R systems are broken-by-design, just as many stupid end-user > "autoresponders" and AV-scanners that send notifications back to the forged > sender address are broken-by-design. Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 12:12:58PM +1000, Russell Coker wrote: > On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: > > When the next address-spoofing virus hits, if I need to update my filters > > again, I'll make a better effort to do it ASAP instead of letting it go for > > several days. > > Why not make your tmda package depend on amavis-new and clamav-freshclam? If > they are installed and correctly configured then virus filters should get > updated as fast as is possible. Does Amavis automatically configure itself for whatever MTA is installed and start scanning mail immediately? If not, then I don't see how a Depends: would help. I would consider adding a Suggests: or Recommends:. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 09:20:49PM +0100, Karsten M. Self wrote: > on Thu, Aug 28, 2003 at 01:03:37AM -0700, Adam McKenna ([EMAIL PROTECTED]) > wrote: > > > Also, I don't have any hard data to support this, but it's obvious to > > me that the volume of mail generated by virus scanners in response to > > Sobig.f eclipses the volume of TMDA challenges by at least a factor of > > 10. So far, I haven't received *one* TMDA challenge that was due to > > Sobig, but I've received *hundreds* of messages from virus scanners > > all over the net. > > > > So, I guess we should add virus scanners to the list of verboten > > software. > > My own inbox supports this statement. 140 responses to Sobig.F mails, > of which 43 are virus or other content-based autoresponders, and 97 > being delivery failure messages or other autoresponders (e.g.: ISP help > desk). How many were challenges from mailing list software? Yes, another class of software that automatically issues challenges (specifically, to new subscriptions and to non-list members if the list is closed). So I guess you should also file bugs against majordomo, mailman, ezmlm-src, and any other mailing list managers that do this. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 02:46:48AM +0200, Tore Anderson wrote: > Earlier, you've stated that your time is precious. Well, so is mine. > How dare you assume that the time I spent reviewing *your* callenge mail > and deciding it was junk is less precious than the time you (could have) > spent reviewing the mail that spurred the challenge in the first place? > > I admit my first email was written in hot blood, but if TMDA actually > endorses this selfish behaviour, I still feel it is something that do > not belong in Debian. On the other hand, if the junk mail in my > inbox was a result of a misconfiguration on your part, then I'm > sorry for yelling so loud. Errare humanum est. I've already stated that I've modified my incoming mail filters so that these viruses will no longer hit TMDA. I feel bad that others were affected due to my misconfiguration, but it was user error (or laziness in this case) that caused this, not a fundamental problem with the software. When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 10:27:43AM -0700, Rick Moen wrote: > Quoting Adam McKenna ([EMAIL PROTECTED]): > > > I suggest you take these suggestions to the TMDA worker's mailing list at > > tmda.net, and file wishlist bugs against TMDA for each desired feature. > > This is an attempt to change the subject: The issue at hand is the > cited maintenance (and acceptance) issues concerning the Debian package. > > If on the other hand the above was just a novel way to say "No" and dig > in your heels, there are more direct (and concise) ways to do it, ja? I don't intend to implement Karsten's requests myself, so it makes sense that he take his beef upstream. I am happy to forward his wishlist bugs upstream, but since I do not have as fervent a desire to see them implemented, Karsten will probably be a better advocate. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 05:10:07PM +0100, Mark Brown wrote: > On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: > > On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: > > > > - TMDA should carry a warning to the user about possible consequences > > > of activating the C-R mechanism, including sending spam, risking > > > Sorry, but no. I will not do this. The user presumably knows what he is > > installing. > > It's entirely reasonable to ask that the documentation be improved to > cover the problems that may arise from using the package. Saying that > the user already knows what the package does isn't entirely helpful > since the user may be looking at the package trying to see if it's > something worth investigating rather than already being an expert user. I've already stated that I am more than willing to add documentation. What I will not do is put in some sort of scary warning that makes people change their mind about using the software. They can go look at Karsten's website if they want that. And no, I'm not putting in a link. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: > #2, Misplaced burden, is the reason for the 'grave' severity. People have a right to ask that unkown people that e-mail them confirm the e-mail. I'm sorry you don't agree with this, but your opinion is hardly justification for a grave bug. > - TMDA should carry a warning to the user about possible consequences > of activating the C-R mechanism, including sending spam, risking > blacklisting or registration in spam-reduction services such as > SpamCop, and a likelihood that some, and perhaps a majority of > challenges will not be responded to. The warning should require the > user to assume full responsibility for doing so. Sorry, but no. I will not do this. The user presumably knows what he is installing. > - Configuration templates for C-R challenges _must_ incorporate virus > and spam filtering, _prior_ to issuing a C-R challenge. Preferably, > tests against obvious header spoofing, if possible, should be > performed. Debian tmda packages _must_ depend on corresponding spam > and virus filters, if this functionality isn't built into TMDA. > > - Additional strong validation mechanisms, including RFC 2015 PGP > signed mail and S/MIME signatures, _must_ be used to validate > sender, including use of web of trust to identify a reasonable > probability of trusted user status. > > - If possible, TMDA should be moved to SMTP-time filtering, so that > mail rejection occurs at SMTP time. As SMTP doesn't offer a > protocol for challenge-response, this introduces interesting > challenges for TMDA's developers. > > - TMDA's performance _must_ be independently validated and the target > maximum of 2% challenges to spoofed addresses be confirmed. > > > > I'm not going to pretend that these are easy fixes. I'm not a user of > this package. I _am_ negatively impacted by it, however, and if it > continues to display similarly poor consideration of security, abuse, > and adverse side effects, I fear for Debian, SPI, and the generosity of > our sponsors. I do feel the remedies are necessary and advised. They > should be communicated upstream, naturally. I suggest you take these suggestions to the TMDA worker's mailing list at tmda.net, and file wishlist bugs against TMDA for each desired feature. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 08:20:52AM +0200, Marc Haber wrote: > On Wed, 27 Aug 2003 21:39:43 -0700, Adam McKenna <[EMAIL PROTECTED]> > wrote: > >Yes, it does present a very good example of poorly written C-R software. > >Paul should switch to TMDA. > > In which way would have TMDA avoided sending a challenge to the > header-from: of a sobig.f instance? TMDA doesn't send challenges to From: addresses, it sends them to the envelope sender (Return-Path) address. But to answer your question, it is trivial to create a filter that drops such messages instead of sending challenges. I have updated my personal filters to make sure this doesn't happen again, and other users of TMDA should do the same. Also, I don't have any hard data to support this, but it's obvious to me that the volume of mail generated by virus scanners in response to Sobig.f eclipses the volume of TMDA challenges by at least a factor of 10. So far, I haven't received *one* TMDA challenge that was due to Sobig, but I've received *hundreds* of messages from virus scanners all over the net. So, I guess we should add virus scanners to the list of verboten software. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: MEI Whitelist Autoresponse
On Wed, Aug 27, 2003 at 09:26:34PM -0700, Aaron Lehmann wrote: > On Wed, Aug 27, 2003 at 08:30:05AM -0400, [EMAIL PROTECTED] wrote: > > Your message to [EMAIL PROTECTED] has been quarantined! > > > > You only need to do this once, but this time, you must verify > > that you are a human. > > I almost wonder if someone sent this intentionally in light of the > TDMA bug thread. > > Either way, it presents a convincing argument. Yes, it does present a very good example of poorly written C-R software. Paul should switch to TMDA. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 05:40:46PM -0700, Don Armstrong wrote: > On Wed, 27 Aug 2003, Adam McKenna wrote: > > TMDA does not ship with any defaults, except a couple of customizable > > text files (templates). It is entirely up to the user to create a > > TMDA configuration along with his own whitelist and filter > > directives. > > If possible, perhaps you could consider whitelisting common debian.org > address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], etc.] When I said "there are no defaults", I meant it. There is no system-wide TMDA configuration. Installing TMDA is analagous to installing procmail, or maildrop, or any other mail filtering software. In order to utilize it, you must configure your MTA to deliver mail to it, and set up several configuration files (e.g. .procmailrc in procmail's case or .mailfilter in maildrop's case). The whitelist is just a list of e-mail addresses. I could include a "sample whitelist", but listing the "recommended addresses to whitelist" in README.Debian should be equivalent or better. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 03:02:33PM -0400, Stephen Gran wrote: > I think that either a large warning on bugs.d.o about the use of C-R > systems in corrspondence, or a similar warning in the description of > TMDA would suffice. I am not familiar with TMDA, so I may be wrong, but > couldn't it be shipped with a default of not issuing a C-R, and have a > note in README.Debian about how to do enable it, with the caveat that > using C-R for BTS correspondence will likely result in ignored bug > reports and problems for the project? Stephen, TMDA does not ship with any defaults, except a couple of customizable text files (templates). It is entirely up to the user to create a TMDA configuration along with his own whitelist and filter directives. TMDA is actually not just a C-R system. C-R is only part of the system. It is also has a very powerful and configurable mail filter, and it is also a Mail Delivery Agent. You can read about the features of TMDA at http://tmda.net/features.html I don't have a problem with adding documentation, in fact I had already planned on adding a note to README.Debian on the next release listing the addresses that the user should be sure to whitelist if he expects to be able to communicate with the BTS. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 07:49:27PM +0100, Colin Watson wrote: > On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: > > Adam McKenna wrote: > > > The arguments are facile and specious, I do not intend to waste my > > > precious time responding to them. > > That's a shame. I don't believe Karsten to be in the habit of putting > forward specious arguments. Well, let's see, I'll try to be brief: #0, #1, #2 and #11 are basically opinion and rhetoric. Karsten has stated that he has a 'religious' objection to CR, and I'm not willing to have a debate about it. I've already noted some of the places that Karsten can go if he wants a debate. #3 blames CR for actions taken by an ISP (IOW, user configuration error). #4 claims that CR is less effective without giving any empirical data to back up that claim. #5 claims a high false positive rate without giving any empirical data to back up that claim. #6 singles out CR for a DOS attack that all autoresponders and vacation programs, as well as some MTA's are vulnerable to. In addition, the effect of such an attack would still identify the original sending machine through the headers of the quoted message, so it would basically be equivalent to mailbombing someone from your own machine. #7 does not apply to TMDA #8 does not really make any sense at all. It seems like he is saying that spammers might start to send out fake confirmation requests in order to harvest e-mail addresses. This seems far-fetched at best. #9 just sounds like a threat. #10 blames CR for user configuration errors (failing to set up a proper whitelist) --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 12:37:36PM +0100, Colin Watson wrote: > Perhaps some compromise could be found here to improve the package's > description. Adam, I also think it would be helpful if you could respond > to at least some points from the original bug report. I do believe that > Karsten has thought about this in some thoroughness and is not simply > trying to antagonize you. The arguments are facile and specious, I do not intend to waste my precious time responding to them. There is no reason for me to remove TMDA from Debian, and therefore I will not do so. If Karsten or anyone else wants to have a debate about which of these arguments apply to TMDA, and why, then I suggest he take his complaints to the upstream mailing lists @tmda.net. I will not debate this in the BTS or on any debian list. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: NM non-process
On Fri, Aug 08, 2003 at 12:55:14AM +0100, Colin Watson wrote: > On Thu, Aug 07, 2003 at 02:41:44PM -0700, Adam McKenna wrote: > > On Thu, Aug 07, 2003 at 11:25:58PM +0200, Marcelo E. Magallon wrote: > > > Trivialities such as people refusing to disclose their real names > > > jump to mind. > > > > This strikes me as one of the *best* reasons to deny someone. If > > someone is unwilling even to trust Debian with their real name, then > > why should Debian (and Debian's users) trust them? > > I think you missed the sarcasm in Marcelo's post. At least, that's how I > read it. Doh.. Sorry, I must learn to read one of these days. --Adam
Re: NM non-process
On Thu, Aug 07, 2003 at 11:25:58PM +0200, Marcelo E. Magallon wrote: > Trivialities such as people > refusing to disclose their real names jump to mind. This strikes me as one of the *best* reasons to deny someone. If someone is unwilling even to trust Debian with their real name, then why should Debian (and Debian's users) trust them? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Debian conference in the US?
On Fri, May 23, 2003 at 10:03:38AM -0700, John H. Robinson, IV wrote: > that north america contains not one, but three countries: Candada, USA, > and Mexico Candada? Is that near Canadia? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Thu, Dec 05, 2002 at 09:20:47AM +1100, Brian May wrote: > On Wed, Dec 04, 2002 at 12:48:14AM +, Darren Salt wrote: > > see if you still don't have a problem. Or try giving the server a local (to > > it) address after MAIL FROM: the server should complain unless you're on a > > network which it considers to be local. > > Tried that with both qmail and postfix, and it still accepts it. > > (ie. telnet to remote server, entered "MAIL FROM: $remoteaddress", > and the server still accepts it even though it considers it a > local address). This is the correct behavior. I don't know what Darren is talking about but I've never seen a mail server that refused to accept e-mails with a local envelope sender from remote hosts. It should be obvious why this wouldn't be a good idea. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Wed, Dec 04, 2002 at 09:22:35AM +0100, Andreas Fuchs wrote: > On 2002-12-03, Adam McKenna <[EMAIL PROTECTED]> wrote: > >> Please enlighten me, anyway: Why is bouncing the full body of the > >> mail you received from a person who claims to be Adam back to Adam a > >> good idea? > > > > This is an implementation issue, not a philosophical issue. > > This is correct. The system still needs to have the sender acknowledge > that the message she sent is the one she is replying to, which requires > at sending at least a little of the message back; pieces of which can > be spam sent from a malicious user. TMDA source says so, too, in the > comment to AUTORESPONSE_INCLUDE_SENDER_COPY. Yes, but this can be set to include only the headers, or none of the sender's message, if the user desires. It still, at most, includes all of the information that would be contained in a normal bounce message. Have you read DJB's modest proposal regarding SMTP traffic? > > Since I only use TMDA I can't speak for others but TMDA has a > > CONFIRM_MAX_MESSAGE_SIZE configuration variable, which will exclude > > the body of the message from the confirmation request if its size > > exceeds the defined value. The default is 50k. > > Right, and in TMDA there is also MAX_AUTORESPONSES_PER_DAY, which only > seems to consider messages per sender. I'm not quite convinced that such > a setup can not be abused as a spam reflector, useless as it may be (it > bounces the full headers), other than annoying a lot of people. (-: Any autoresponder can be used as a spam "reflector", so that still doesn't condemn this particular class of software. There is no amplification effect. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 11:52:38PM +0100, Andreas Fuchs wrote: > Today, Adam McKenna <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 02, 2002 at 11:49:09PM +0100, Andreas Fuchs wrote: > >> Right. I just thought up a scheme to exploit this, based on the fake > >> source-IP address approach you find in descriptions of ping-floods. > > > > Wow, you're pretty smart. Nobody has thought of this before, > > especially not the authors of said programs. > > *makes a mental note never to use the term "I just thought up" again* > > Please enlighten me, anyway: Why is bouncing the full body of the mail > you received from a person who claims to be Adam back to Adam a good > idea? This is an implementation issue, not a philosophical issue. Since I only use TMDA I can't speak for others but TMDA has a CONFIRM_MAX_MESSAGE_SIZE configuration variable, which will exclude the body of the message from the confirmation request if its size exceeds the defined value. The default is 50k. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Wed, Dec 04, 2002 at 09:58:28AM +1100, Brian May wrote: > On Tue, Dec 03, 2002 at 09:55:34AM -0800, Adam McKenna wrote: > > The key issue here is that the mail isn't blocked. It's simply held in > > another place until confirmed. It doesn't become a "false positive" until > > it > > is deleted without being read. > > It depends how you define the SPAM checking process. > > If you define the SPAM checking process as "an automatic process which > classifies mail as either SPAM or non SPAM", then your statement is > incorrect, it is a false postive as soon as it has been automatically > classified in the wrong group. Not really, because the class of programs we're talking about don't make a distinction between spam and non-spam, they only make a distinction between confirmed and unconfirmed messages from unknown addresses. > However, you seem to be defining the SPAM checking process as "a series > of automatic and manual processes that automatically delete all SPAM > and nothing else from your mail folder". > > Which is interesting, the first definition doesn't take into account the > human reading the mail, the second does. > > However, as far as I am concerned, my ideal (as unrealistic as it may > be) is not to have to look at SPAM at all, which means that I use the > first definition. But to be sure you're not getting any false positives, you cruise through your "spam" mailbox every now and then, right? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Wed, Dec 04, 2002 at 09:47:05AM +1100, Brian May wrote: > On Tue, Dec 03, 2002 at 11:09:02AM +0100, Gerrit Pape wrote: > > Autoresponders, bouncers, and other mail handling programs use the > > envelope sender address, not an address found in any header of the mail. > > I doubt that any abuse@ address replies to a bounce message. This is no > > problem. > > You seem to imply that the envelope sender address is harder to forge? > > Yet my experience has been that I can telnet to port 25 on any mail > server, and give it any envelope sender I want. > > Are there suppost to be some sort of checks placed on this address? He's talking about the envelope sender address on the confirmation messages, which is empty (<>), the same as for bounce messages. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 06:16:48PM +, Colin Watson wrote: > On Tue, Dec 03, 2002 at 09:55:34AM -0800, Adam McKenna wrote: > > BTW, anyone who e-mails you and then asks you to confirm your reply is > > either using broken software, or doesn't have their outgoing mail > > headers set up properly. > > So people who e-mail [EMAIL PROTECTED] and then ask for > confirmation from [EMAIL PROTECTED] must be using broken software > too, I guess. Similarly, people don't always use one of my canonical > addresses. Yes, that's correct. People using such systems should be sending from tagged addresses that do not require confirmation. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Wed, Dec 04, 2002 at 03:40:53AM +1000, Anthony Towns wrote: > On Tue, Dec 03, 2002 at 09:26:34AM -0800, Adam McKenna wrote: > > > It's easy to be effective if you don't care about false positives. > > Yes, and unless you consider people who either: > > 1) are too lazy to confirm > > 2) have a philosophical objection to confirming > > false positives, then there are no false positives with confirmation > > systems. > > Any mail you want to read that gets blocked by a spam filter is a > false positive, whoever it may be from. Why're you trying to cloud the > issue with inane word games? There are already sensible definitions for > these words. The key issue here is that the mail isn't blocked. It's simply held in another place until confirmed. It doesn't become a "false positive" until it is deleted without being read. > Note that, conversely, "Hi, I'm a program and I don't know who you are, > and don't trust you, please spend some of your valuable time to overcome > my paranoia" can quite reasonably be classed as "mail you don't want to > read", especially if it's on behalf of someone who's asking you a favour. Yes, and people are perfectly within their right to drop such messages (or any messages, for that matter) into the bit bucket, just like they're within their right to drop bounce messages. But they shouldn't be surprised when their original message is either dropped, or read weeks late. BTW, anyone who e-mails you and then asks you to confirm your reply is either using broken software, or doesn't have their outgoing mail headers set up properly. As a side note, I am pretty amused by the people in this thread who say "don't use these systems, they're antisocial", and then follow that up with "I'm going to blacklist anyone who uses these systems".. I guess their definition of antisocial is different than mine. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 05:13:42PM +, Colin Watson wrote: > On Tue, Dec 03, 2002 at 08:56:10AM -0800, Adam McKenna wrote: > > On Mon, Dec 02, 2002 at 11:49:09PM +0100, Andreas Fuchs wrote: > > > Thus, my conclusion: These things are evil. Don't use them or somebody > > > might use them against you, eventually. > > > > This sounds vaguely like religion -- you haven't even taken the time to see > > how these filters work yet you are decrying them as "evil". > > > > They happen to be the most effective filtering solution at present, > > /dev/null is the most effective filtering solution at present, and these > days happens to be equivalent to these filters when applied to mail from > me. > > It's easy to be effective if you don't care about false positives. Yes, and unless you consider people who either: 1) are too lazy to confirm 2) have a philosophical objection to confirming false positives, then there are no false positives with confirmation systems. You're also assuming that the users of such systems don't periodically check out their pending queue to make sure there isn't any legitimate mail in there before purging it. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 11:49:09PM +0100, Andreas Fuchs wrote: > Right. I just thought up a scheme to exploit this, based on the fake > source-IP address approach you find in descriptions of ping-floods. Wow, you're pretty smart. Nobody has thought of this before, especially not the authors of said programs. > a) Spammer finds an autoresponder > b) Spammer sends many mails with Reply-To: header chosen from a >know-to-work address list > c) Reply-To:ed people receive the bounced mail and are annoyed. d) Andreas Fuchs figures out how the programs he is bashing actually work. > Thus, my conclusion: These things are evil. Don't use them or somebody > might use them against you, eventually. This sounds vaguely like religion -- you haven't even taken the time to see how these filters work yet you are decrying them as "evil". They happen to be the most effective filtering solution at present, and they definitely beat the "everyone registers their SMTP server" solution that's currently being pushed in certain technical forums. Someday this type of software may be rendered ineffective by some new spammer invention, and at that time it will be easy enough to just turn it off and use something else. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Discussion - non-free software removal
On Mon, Nov 25, 2002 at 07:20:39PM -0600, John Goerzen wrote: > On Mon, Nov 25, 2002 at 01:42:39PM -0800, Adam McKenna wrote: > > Perhaps some of us feel that "The Way Things Are Now" is consistent with > > our > > Social Contract and our list of committments, and changing that would be > > violating that Contract and those committments. > > That's a recursive definition. "The way things are now" is our current > social contract, so you are saying "The way things are now is consistent > with the way things are now." I suppose that could be taken as an axiom, > but I don't see any useful benefit to it :-) I'm aware that the definition is somewhat tautological. But my opinion remains that our users are currently better served by the status quo than what you are proposing. But, as someone else said, this discussion is getting old. I was away for about a week so I didn't get a chance to participate in the tail end of it. I'd rather just let the matter rest and let it go to vote. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Why do system users have shells?
On Mon, Nov 25, 2002 at 04:34:52PM -0500, H. S. Teoh wrote: > wu-ftpd HEH. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Discussion - non-free software removal
On Mon, Nov 25, 2002 at 04:19:45PM -0500, Branden Robinson wrote: > On Mon, Nov 25, 2002 at 11:22:42AM -0800, Adam McKenna wrote: > > On Mon, Nov 25, 2002 at 12:56:05PM -0500, Branden Robinson wrote: > > > On Mon, Nov 25, 2002 at 01:56:46AM -0800, Adam McKenna wrote: > > > > Why does the "GR-opposition party" need to stand "for" anything, other > > > > than > > > > preserving the status quo? > > > > > > Thanks for clarifying that. > > > > Your wit is razor sharp as usual, Branden. > > I guess you're being sarcastic, because I was being sincere. > > > What you seem to be implying is that there is something wrong with the > > desire to preserve the way things are now (regardless of the > > motivation). Is this your position? > > There is not necessarily anything wrong with it. However, I cannot find > "Preserve the Way Things Are Now" in Debian's list of committments in > its Social Contract with the Free Software Community. Perhaps some of us feel that "The Way Things Are Now" is consistent with our Social Contract and our list of committments, and changing that would be violating that Contract and those committments. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Discussion - non-free software removal
On Mon, Nov 25, 2002 at 12:56:05PM -0500, Branden Robinson wrote: > On Mon, Nov 25, 2002 at 01:56:46AM -0800, Adam McKenna wrote: > > Why does the "GR-opposition party" need to stand "for" anything, other than > > preserving the status quo? > > Thanks for clarifying that. Your wit is razor sharp as usual, Branden. What you seem to be implying is that there is something wrong with the desire to preserve the way things are now (regardless of the motivation). Is this your position? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Discussion - non-free software removal
On Wed, Nov 20, 2002 at 09:34:44AM -0500, Branden Robinson wrote: > On Wed, Nov 20, 2002 at 02:09:59PM +0200, Michelle Konzack wrote: > > But I do not use contrib or non-free. Nobody had ask for non-free > > and contrib if I burn CD's for some one... > > An important data point, I'd think... Yes, someone write that down. Michelle in Strabourg doesn't need non-free. Anecdotal evidence is so much more compelling when it supports your cause, eh? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Discussion - non-free software removal
On Sun, Nov 17, 2002 at 06:22:36PM -0500, Branden Robinson wrote: > On Sun, Nov 17, 2002 at 12:30:31PM +0200, Richard Braakman wrote: > > On Fri, Nov 15, 2002 at 05:47:39PM -0500, Branden Robinson wrote: > > > This certainly flies in the face of the common argument that Free > > > Software only "chases taillights". > > > > Careful. That's a *Microsoft* argument. > > I didn't say I agreed with it. I'm simply trying to figure out what the > "GR-opposition party" stands for. Why does the "GR-opposition party" need to stand "for" anything, other than preserving the status quo? _YOU_ (the "GR-proponent" party) are the ones who want change; it is up to _YOU_ to convince the rest of us why the change is beneficial. --Adam
Re: XFree 4.2.0 - again
ObPleaseDon'tFeedTheTroll --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#141345: ITP: sextractor -- Builds a catalogue of objects from an astronomical image.
On Sat, Apr 06, 2002 at 02:59:32AM +0200, Russell Coker wrote: > What does a sex tractor have to do with astronomy? Well, if you were having sex on a tractor, you'd probably be outside, looking up at the stars. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: neat mutt bug.
On Sun, Sep 16, 2001 at 12:34:22PM +0200, Martin F Krafft wrote: > also sprach Adam McKenna (on Sun, 16 Sep 2001 03:17:37AM -0700): > > Interesting highlighting bug in mutt -- could confuse an unsuspecting person > > into thinking Branden actually signed this. > > oooh. this is ugly. reported it to bugtraq? if not bugtraq, then at > least michael elkins should know... I just sent a copy to [EMAIL PROTECTED], hopefully that list accepts submissions from non-members. I personally don't think it's bugtraq worthy, since careful checking will reveal a bad date, but still, it's important because the casual reader will most likely believe the data was signed. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
neat mutt bug.
[-- PGP output follows (current time: Sun Sep 16 03:12:37 2001) --] gpg: Signature made Thu Sep 13 20:30:20 2001 PDT using DSA key ID 2B46A27C gpg: Good signature from "Branden Robinson <[EMAIL PROTECTED]>" gpg: aka "Branden Robinson <[EMAIL PROTECTED]>" gpg: Fingerprint: 1573 D544 73C3 988F 0096 3E4F EA4C 661F 2B46 A27C [-- End of PGP output --] [-- The following data is signed --] Interesting highlighting bug in mutt -- could confuse an unsuspecting person into thinking Branden actually signed this. [-- End of signed data --] --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: reopening ECN bugreport/netbase
On Wed, Sep 05, 2001 at 03:19:01PM -0800, Ethan Benson wrote: > On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote: > > So since netbase does not want to be the proper place, a better > > fix/workaround (I'm sincerely trying hard not to be ironic!) would be to > > use debconf with a default value of "0" and to inform/ask the user about > > it when installing a new kernel. > > and store/implement it where? /etc/sysctl.conf is unacceptable as its > a conffile belonging to procps. > > and personally i don't want /etc/sysctl.conf to become another debconf > [mis]managed config file. I agree -- sysctl.conf should never be touched by the distribution -- it is for local settings, specific to each machine, and there should never be a chance that it could possibly be overwritten automatically, as that could result in major breakage on some systems. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: why dig ? I wanna use nslookup !
On Wed, May 02, 2001 at 09:52:04PM +0200, Gerrit Pape wrote: > Not having real djbdns (+co) packages in debian is a pity. As the maintainer of the djbdns-installer package, I feel obliged to mention that there are quite a few people using this package and they are quite happy with it. It requires no extra development knowledge to install, and the end effect is exactly what one would obtain by downloading djbdns.tar.gz, setting conf-home to /usr, and compiling and installing. The part where the "pity" comes in is that his license isn't free enough for any binary package of his software to be included in main. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
404's
It seems like an easy way to prevent the following would be to update the Packages.gz file LAST, after syncing up the other files, IE: rsync --exclude "Packages*" debian/pool rsync --delete debian/pool (If old packages are even deleted) --Adam [EMAIL PROTECTED]:~$ sudo apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back dnsutils sysklogd 96 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded. Need to get 24.4MB/57.0MB of archives. After unpacking 1949kB will be used. Do you want to continue? [Y/n] Err http://http.us.debian.org unstable/main rpm 4.0.2-6 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main libpopt0 1.6.2-5 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main lilo 1:21.7.1-4 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main modutils 2.4.5-1 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main libmysqlclient10 3.23.37-3 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main librpm0 4.0.2-6 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main libxaw6 4.0.3-1 404 Not Found [IP: 192.25.206.10 80] Err http://http.us.debian.org unstable/main libxaw7 4.0.3-1 404 Not Found [IP: 192.25.206.10 80] -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 09:23:23PM -0900, Ethan Benson wrote: > On Thu, Jan 04, 2001 at 01:18:40AM -0500, Adam McKenna wrote: > > > if this is the case the solution is fixing broken mailers, many of > > > them are Free software so why have patches to support M-F-To not been > > > made? > > > > I'd like to see someone convince that M-F-To fix Pine. But I doubt you'll > > have an easy time getting Crispin to apply a patch. He won't even > > implement > > maildir, for christ sake, and patches for that have been around for over 2 > > years now. > > pine is a lost cause anyway. i was thinking of GNUs which seems to be > the other big offender of ignorage of M-F-To. (i am not sure if it > respects Mail-Copies-To: never i just started adding that.) Actually, I'm pretty sure that Gnus respects M-F-To. The biggest offenders in that arena seem to be PINE and the GUI MUA's. > btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ? i have > seen both which is correct? (assuming any MUA actually pays any > attention to this header anyway) Don't know, I don't use it. --Adam
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 09:07:27PM -0900, Ethan Benson wrote: > > have been added to Mail-Followup-To by other Mutt users, and I don't use > > the > > lists command at all. > > in that case there would be something funny going on, here is my > theory: > > you post to list, you M-F-To: is set to only the list > > someone (Mr-Broken) with broken mailer uses reply-to-all which CCs you > anyway ignoring M-F-To. > > mutt user uses list-reply to Mr-Broken's post, mutt sees you were CCed > and assumes you should be included since there is no M-F-To header. > mutt then sets the M-F-To header to include you for the benifit of > later list-replies. Sounds like a reasonable scenario. > if this is the case the solution is fixing broken mailers, many of > them are Free software so why have patches to support M-F-To not been > made? I'd like to see someone convince that M-F-To fix Pine. But I doubt you'll have an easy time getting Crispin to apply a patch. He won't even implement maildir, for christ sake, and patches for that have been around for over 2 years now. --Adam
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 08:36:54PM -0900, Ethan Benson wrote: > > listed in Mail-Followup-To. The thing that bugs me about this is that mutt > > often adds other list-readers' e-mail addresses to Mail-Followup-To, > > effectively rendering this feature useless. > > try reading the FM. in mutt 1.2 and later (also some 1.1 versions) > the lists command causes both your address and the lists address to > the Mail-Followup-To. the subscribe command on the other hand ONLY > includes the list's address and NOT your own. I did read the FM and I'm well aware of the difference between the lists command and the subscribe command. That's not what I'm talking about. > as for including other's in the Mail-Followup-To mutt only does this > if those users had used `lists' instead of `subscribe' indicating they > WANT to be CCed. There must be a bug in it somewhere, then, because I often see people getting added to Mail-Followup-To that shouldn't be there. In fact, I personally have been added to Mail-Followup-To by other Mutt users, and I don't use the lists command at all. --Adam
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 08:41:06PM -0500, Branden Robinson wrote: > On Wed, Jan 03, 2001 at 11:38:13PM +0100, Peter Palfrader wrote: > > and respect my Mail-Followup-To header next time. > > I'd sooner killfile you than respect a lame Mail-Followup-To like this: > > Mail-Followup-To: Peter Palfrader <[EMAIL PROTECTED]>, > debian-devel@lists.debian.org > > If I'm already replying to a list, I'm not going to waste bandwidth by > mailing you personally as well. So what you're saying is that you're purposely ignoring people's Mail-Followup-To when it suits you, while insisting that others abide by yours? That sounds kind of ridiculous to me. --Adam
Re: maybe ITP rsync mirror script for pools
On Wed, Jan 03, 2001 at 11:57:07PM +0100, Marco d'Itri wrote: > On Jan 02, Goswin Brederlow <[EMAIL PROTECTED]> wrote: > > >So would there be intrest in a deb of the script coming with a debconf > >interface for configuration, cronjob or ip-up support and whatever else > >is needed to keep an uptodate mirror. > Please don't encourage private mirrors! Debian itself encourages private mirrors. Personally, I'd rather just download a new ISO every 3 months or so as new versions come out but the cdimage.debian.org pages steer people heavily toward mirroring and producing their own CD images with the debian-cd package. --Adam -- Adam McKenna <[EMAIL PROTECTED]> | "No matter how much it changes, http://flounder.net/publickey.html | technology's just a bunch of wires GPG: 17A4 11F7 5E7E C2E7 08AA| connected to a bunch of other wires." 38B0 05D0 8BF7 2C6D 110A| Joe Rogan, _NewsRadio_ 6:12pm up 207 days, 16:29, 8 users, load average: 0.01, 0.04, 0.07
