Re: Signing Packages.gz

[Nicolás Lichtmaier]

> I partly concur. Even if the developer->user channel was completely
> secured by signatures et al, we would still have the problem of an
> attacker gaining very much by breaking into a single developer's
> machine. You're netbase package is a good example: it contains a
> couple of programs usually started as root. If your developing machine
> is compromised, and your copy of the source modified, the evil guy may
> gain entry into a large number of Debian boxen.

 All packages can run things as root. Even the most simple game.

Re: END Key in Emacs (only in Xterm)

[Branden Robinson]

On Sun, Apr 02, 2000 at 07:50:31PM -0300, Rodrigo Castro wrote:
> Hello Branden,
> 
> On Sun, Apr 02, 2000 at 05:07:11PM -0400, Branden Robinson wrote:
> > On Sun, Apr 02, 2000 at 10:48:24AM -0300, Rodrigo Castro wrote:
> > >   Sorry for sending this message again and sorry for sending to
> > > devel (I don't know if I should). I really need your help, I tried
> > > everything I know and I can't make my Emacs work with END key, when it
> > > is in Xterm.
> > 
> > If you're using xterm 3.3.6-6, please be sure and read the Debian X FAQ.
> > There is a section about debugging key binding problems.
> > 
> > 
> 
>   I had already read it. If I change TERM variable to linux, it
> works. Look at what is returned by these commands (xev reports
> everything fine):

"infocmp xterm linux" reveals that kend is defined the same for both
terminal types, and the default xterm Xresources file explicitly binds the
End key to ESC [ 4 ~.  If xemacs can't handle that I suggest you contact
its package maintainer.

-- 
G. Branden Robinson|Somewhere, there is a .sig so funny that
Debian GNU/Linux   |reading it will cause an aneurysm.  This
[EMAIL PROTECTED] |is not that .sig.
roger.ecn.purdue.edu/~branden/ |


pgpOotbmTGGvO.pgp
Description: PGP signature

Re: Ian Jackson, please get me the hell off your blacklist.

[Ian Jackson]

Branden Robinson writes ("Re: Ian Jackson, please get me the hell off your 
blacklist."):
> I see no reason not to reply [...]

I think you are being hypocritical.  You complain when other people
post their opinions and discussions of this topic with you, yet you
post your own diatribes here.  Since your request to keep the
discussion to private email seems insincere I shall answer you here.

Also, I object to your misleading characterisations of my position and
highly tendentious phrasings in your complaints.  They are not helpful
for constructive debate and I respectfully suggest that you tone it
down.  As I said in private email, I understand that you're angry, but
please stop acting out.


There are two issues here.  One is the general question about mail
handling, spam blocking, etc.  The other is the specific issue with
respect to your complaint about my mail system.


On the general question:

I think it's completely unhelpful when people on both sides of this
argument start to talk about how it's their `right' to send mail
freely in any way they like and have it accepted, or their `right' to
block mail in any way they choose.

I don't want to get into the existence or otherwise of these `rights'
for communications on the net in general.  That's just asking for an
enormous and pointless flamewar.

However, it's clear that for us to work successfully together we must
be able to communicate.  Every pair of developers might need to talk
to each other.  It's therefore not OK if due to people's exercise of
these `rights' they can't communicate.  This obviously means that
developers have to have at least some shared ideas of what can be
expected from the sending and receiving ends of a mail transfer.

The problem is caused by the existence of spam, because it means that
there are people who are trying to send mail to us whose mail we
definitely want to exclude - and these exclusions are essentially
political rather than technical and sometimes have false positives or
mean that certain kinds of apparently harmless behaviour end up
forbidden.  This leads to the kinds of heated debates we've seen here.

The upshot is that there will have to be some agreement about what is
and is not acceptable, both as behaviour on the part of the sender, or
as policy on the part of the recipient.  There will have to be some
minimum standards (even if they're not written down) which everyone
agrees to abide by.

It seems obvious to me that we should try to balance the negative
effects of spam (and other kinds of abusive or broken mail) and the
inconvenience of people having to change mail configuration or
whatever to make the mail get through.

We can't take this whole issue as a lump and say I HAVE MY RIGHT TO DO
WHATEVER I WANT AND FUCK YOU YOU'RE ALL A BUNCH OF ARSEHOLES.

Instead, we should argue each issue on merits in a constructive way,
in terms of its costs, benefits etc.


Several kinds of these issues have been raised: MAPS RBL, MAPS RSS,
ORBS, DUL (and the like), and various similar things.  I think we
should take them each individually.

It seems to me that the case for the MAPS RBL and the MAPS RSS are
pretty well established; they have very low false positive rates, and
are generally careful about who they include.  With the RBL, of
course, you could even say that it's unethical to financially support
a spam-haven ISP.  It's true that being (or mailing via) an open relay
- the criterion for RSS - is not necessarily evil in itself, but it
makes it very hard to distinguish legitimate from spam mail, and in
general we are all I think agreed that in today's Internet open relays
are a problem which needs to be removed.

With respect to the ORBS: I respect what they're trying to do, but it
seems to me that they're too quick to list entire networks because
they allegedly blocked the automatic tester, and too slow to remove
them.  This means that a sender can effectively end up with no good
solution, merely because someone on a neighbouring IP address once
blocked the ORBS tester.

I won't go into the DUL here, because that's a very contentious issue
and would be too much to talk about in this one message.  I'll send
another message with my view on the DUL.


On the specific issue:

Branden's complaint is about the fact that for the first three hours
after seeing a particular IP address (or for the first hour after
seeing a new envelope sender), my MTA will not accept mail from it.
Instead it sends a `450' response to RCPT; this is a temporary failure
code which indicates to the sending end that it should try later.

Before I go into the details, I would like to point out to anyone else
who is reading this thread that Branden did not receive a bounce.
Indeed, this strategy by my MTA is invisible to the sender of the
mail, though of course it can be visible to their system administrator
in logfiles and mail queues.  Branden discovered this SMTP interaction
by looking at his sendmail logs (NB, not due to an error report 

DUL (was Re: RBL report..)

[Ian Jackson]

I've just sent another, long, message about mail acceptance,
blacklisting, and this whole flamewar.  Please read that message
first; it explains the context of this mail, and without it you might
misinterpret this one.

This message is about my opinion of the DUL, which I support and use.
In fact my software will not usually accept mail from dynamic dialups
anyway - even those not on the DUL.

It does seem that some people do find it beneficial to send mail
direct from their dialups (static or dynamic).  I don't understand why
they think this is a good idea, and I think it has a number of
technical problems.  However, I don't think that it's reasonable to
effectively forbid people from doing this solely for those reasons,
provided they're willing to accept the consequences - which will
include excessive retransmissions over their modem, long connect
times, and/or extended delays to the delivery of mail.

*But*, there is a definite problem with people using _dynamically
assigned_ dialup.  This is because a dynamic dialup address cannot
effectively be blacklisted, and mail sent direct from such an address
cannot be monitored or controlled by the connectivity provider.  Since
much of the net's current spam-fighting infrastructure is based on
blacklists of IP addresses and proactivity by ISPs, this is a big
problem.

That mail direct from dynamic dialups is a problem is recognised
throughout the community.  Not only did Paul Vixie, the author of
BIND, and other leading lights of the Internet, decide to host,
support, etc, the DUL.  Many ISPs prevent you from doing direct SMTP
by having their routers block outgoing SMTP or transparently redirect
it to their own mailservers.  I think that this is going to become
much more common.  Use of the DUL is becoming more common too - for
example, Cambridge University no longer accept DUL mail.  Sites that
use DUL blocking report that it has very low false-positive rates -
some claim even lower than the MAPS RBL.

Now, I agree that for those people who want to do direct SMTP from
dynamic addresses it is inconvenient for them to have to change, but I
don't think this inconvenience is very great.  Furthermore, the number
of people inconvenienced in this way is very low, and all the people
who are doing this are technically competent and have quite reasonable
alternative ways of having their mail delivered.

(IMO doing direct SMTP from a dialup accidentally or `by default'
almost certainly reflects a bug in the software or documentation or a
mistake by the user.)

It's clear, though, that the project will have to come to a common
decision about this.  It's not just about what the project's
mailservers will accept.  As I said in my other mail, since we all
need to communicate with each other, either every developer must be
forbidden from using the DUL, or every developer must either not send
mail direct from their dynamic dialup, or must be prepared to send it
differently if there is a problem.

Until a common decision can be arrived (if only by vigorous ranting
here until one side feels they can't win), this issue will keep
raising its head.  We can't punt on it.

If we decide that developers are allowed to reject DUL mail then the
listmanagers should be allowed to do so too on the central systems.

Ian.

Re: Release-critical Bugreport for March 31, 2000

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
> Bug stamp-out list for Mar 31 03:06 (CST)

> Package: bind (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61129  base: bind upgrade leaves two named's running

I see how this can happen in some odd cases.  Should have a fix uploaded in 
a day or two.

> Package: inn2 (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61077  inn2: apparently all sorts of directory permissions are trash in inn2

> Package: inn2-inews (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61409  inn2-inews: rnews permissions break mail2news gateway setup

I apparently did something moderately stupid in a recent version that broke
a variety of permissions in the inn2 packages.  Should have them fixed and a
new upload in a day or two.

> Package: ntpdate (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
>   61333  ntpdate should replace xntp3

Easy fix, upload tomorrow.

Bdale

ITP: gtans (Games/Puzzles)

[JM Bourdaret]

Hello

I've just packaged gtans, a tangram (chinese puzzle) game written
with GTK. As i'm not a developer yet, Rafael <[EMAIL PROTECTED]>
agreed to sponsors me :) . In fact, the package is near completion.

package and source are at www.wiktor.dk/~yip/debian/ (apt-get ok)
upstream author page is at altern.org/bwt/


Source: gtans
Section: games
Priority: optional
Maintainer: JM Bourdaret <[EMAIL PROTECTED]>
Standards-Version: 1.1-1

Package: gtans
Architecture: any
Depends: ${shlibs:Depends}
Description: Tangram (puzzle) game using GTK+
 The Tangram is a chinese puzzle. The object is to put seven geometric
 shapes together so as to form a given ouline. All the pieces must be used
 and are laid next to one another. The pieces are five triangles, a square
 and a parallelogram. gtans contains about 290 figures to play with.It
 use the mouse to control pieces. gtans is highly customizable using the
 interface.


don't hesitate to mail me for info

Jean marc

[EMAIL PROTECTED]

Re: ITP: lirc, devfsd

[Ben Collins]

> Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
> This one still needs a couple of problems ironing out first.

No offense, but I hope you realize the amount of effort that will be
needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
the amount of policy and technical bugs will be tremendous (permissions,
adding support for default compatibility devices, etc..).

I just don't want to see anyone go lightly into packaging devfsd. If you
aren't prepared to take on the responsiblity of what will most likely
become a base and essential package, leave it for some one else to do.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
` [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED] '
 `---=--===-=-=-=-===-==---=--=---'

Re: ITP: lirc, devfsd

[Ethan Benson]

On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote:
> > Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
> > This one still needs a couple of problems ironing out first.
> 
> No offense, but I hope you realize the amount of effort that will be
> needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
> the amount of policy and technical bugs will be tremendous (permissions,
> adding support for default compatibility devices, etc..).
> 
> I just don't want to see anyone go lightly into packaging devfsd. If you
> aren't prepared to take on the responsiblity of what will most likely
> become a base and essential package, leave it for some one else to do.

I hope debian is not planning on `forcing' [0] the use of devfs with 2.4,
last i checked it was still a compile time option (and experimental at
that) there are some of us who don't care for devfs and do not wish to
use it.

[0] read making it exceedingly inconvenient to forgo or disable devfs
in 2.4 kernels, for example neglecting to maintain or provide a real
(non-devfs) working /dev directory.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpIttMdLg8tg.pgp
Description: PGP signature

Re: ITP: lirc, devfsd

[Ben Collins]

On Sun, Apr 02, 2000 at 06:42:59PM -0800, Ethan Benson wrote:
> On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote:
> > > Similarly, I have packaged devfsd 
> > > (http://www.atnf.csiro.au/~rgooch/linux/).
> > > This one still needs a couple of problems ironing out first.
> > 
> > No offense, but I hope you realize the amount of effort that will be
> > needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
> > the amount of policy and technical bugs will be tremendous (permissions,
> > adding support for default compatibility devices, etc..).
> > 
> > I just don't want to see anyone go lightly into packaging devfsd. If you
> > aren't prepared to take on the responsiblity of what will most likely
> > become a base and essential package, leave it for some one else to do.
> 
> I hope debian is not planning on `forcing' [0] the use of devfs with 2.4,
> last i checked it was still a compile time option (and experimental at
> that) there are some of us who don't care for devfs and do not wish to
> use it.
> 
> [0] read making it exceedingly inconvenient to forgo or disable devfs
> in 2.4 kernels, for example neglecting to maintain or provide a real
> (non-devfs) working /dev directory.

No this is not an option. There will remain a real /dev for (an I presume
and support this particular viewpoint, but it has not been set in stone as
of yet, and wont be until potato is out of the way, and 2.4 is in woody)
atleast woody, and most likely the release after that. I would hope that
we can have a completely devfs system for the release after woody, simply
because it is the way that everything is going, and it is the Right Way.

Note that makedev can create all of the base devices with one simple
command. This makes it quite simple to get rid of devfs, even in the
future if we ever do decide not to provide it by default on later
distributions (in fact this can probably be scripted, so that if the
system boots without devfs enabled, makedev will create everything needed
on the fly).

However, people will want to use devfs, and therefore devfsd will be
needed in order to support the transition (without it, most programs will
fail to find the new device locations). I am pretty sure that devfs will
be used extensively in boot-floppies. The main reasons being that the
rootdisks will be smaller without having to contain hardcoded device
nodes. Secondly, it is easy to parse out what the available hardware is
since the device nodes are only created when a driver actually finds the
device and enables it (i.e. /dev/cdroms/cdrom0 wont exist unless there is
actually a cdrom device). Since the boot-floppies are self contained, it
wont even need devfsd for the installation program, since all the device
paths can be made to work with devfs' setup.

Again, these are my opinions alone, and nothing has been decided, but
devfs will come of age, and we need to support it, and that will mean some
work for the devfsd maintainer, whoever that may be.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
` [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED] '
 `---=--===-=-=-=-===-==---=--=---'

Re: Signing Packages.gz

[Anthony Towns]

On Sun, Apr 02, 2000 at 02:57:06PM +0200, Marcus Brinkmann wrote:
> > > As dinstall verifies the keys on the packages (which already exist, btw,
> > > they are just not propagated), it puts itself in the middle of the chain:
> > Well, as Jason points out, they are propogated: by the -devel-changes
> > list.
> They are not delivered to the user when he is downloading a deb, with no
> dselect method, and not with apt, and espcially not when downloading the
> package manually.

But they could be, with minimal changes. Stick the latest .changes files
in debian/changes somewhere and add some code to apt to get it.

I'd be interested in seeing some code for this. You keep throwing around the
word `easy', as though it *is* just as plausible to implement this method.
Please, at least write some pseudocode for it.

Make sure you consider the necessity of keeping debian-keyring up-to-date
in case of compromised keys. Make sure you either explicitly do use a
`single key' that's easy to verify, or not. If you do, make sure you allow
some way of coping with James' key being updated, or James retiring and
someone else taking over the job; and make sure you cope with upgrades
that possibly skip the generation where this happens.

>> I'm sorry, but that's a matter of opinion. If you're really *hugely* worried
>> about the security of master, then please, show us your scripts that you've
>> already had to write to cope with the fact that master's so insecure it's
>> probably already compromised.
> If you compare the security of PGP with the security of any linux machine,
> you will easily see the difference. 

Right. Now compare the security of one particular linux machine, namely
master, with the security of the weakest machine used by a developer. You
ought to be able to see the difference there, too.

> > Yes, it's a problem, but one you seem to be vastly overrating.
> Are we talking about security, or are we talking about belief?

If we're talking about trust, which we are, then we're immediately talking
about belief. Belief is quite fundamental to security analysis, it's the
fundamental unit in BAN logic, eg.

> I am very irritated that people who want to propose and implement a security
> measure for Debian packages are building on likeliness and probablility, and
> on the fact that "master is quite secure".

We've got a choice: do we trust master, or do we trust that mirrors won't be
compromised by developers? How do we choose? Liklihood, probability, how
easy the weakest choices can be compromised.

> What about all the packages on other systems? Third party packages? Packages
> I build locally? There is a solution which covers individual debs even,
> where I don't know any more where they come from.

Packages you build locally? Huh? If someone's already compromised your local
machine, what security is adding signatures going to give you?

For third party packages, you have a point. Most third party packages are
distributed in an apt-able way these days, though, in which case most of
them have a Packages file that can be signed. If you want Apt to verify
and trust the signature, you'll probably have to move the appropriate public
key into an apt configuration file somewhere first, though.

Jason: I'm thinking, probably, something like:

Gpg::KeyRing {"/etc/apt/apt-keys.gpg";}
Gpg::Origin
{
Name {"Debian";};
KeyID {"0x12345678";};
}
Gpg::Origin
{
Name {"IPv6-staging";};
KeyID {"0xabcd9876";};
}

where the Gpg::Origin::Name's match the Origin field in the Release files.

I'm not quite comforable with the `KeyID' stuff. It's very easy to make a
key with the same KeyID as another, so as identifying information, that's
pretty weak. OTOH, to actually get it installed, you'd have to overwrite
the Apt keyring, so anyone whose going to compromise your system has to
have already compromised it, which isn't too bad, I guess. I wonder, though
if it mightn't be better to also specify a fingerprint, which apt can
check for itself.

This is also somewhat difficult to verify if you want to allow updates.
You could probably do it if you had a different .gpg directory (with
separate gpg keyrings and separate trustdbs) for each Origin. That'd
be pretty ugly though. Possibly a `--check-trusted-by  '
option needs to be added to gpg, so you can check that whatever key was
used to sign a Packages.gz file from Debian is at least certified by the
key you verified by hand yourself. Alternatively, you could just say
"Aieee! The Debian/unstable key has changed again! Please verify this
by hand and update your apt.conf!" which could get tiresome.

Marcus: How would dpkg with debian-keyring handle all this?
 
> > >signed packages --> dinstall
> > >  \  1
> > >   \--> user
> > > 1
> > 
> > Really, what we have is:
> > 
> >  maintainers -3-.
> > 

Re: Signing Packages.gz

[Anthony Towns]

On Sun, Apr 02, 2000 at 01:00:56PM +0200, Bart Schuller wrote:
> On Sun, Apr 02, 2000 at 02:46:30PM +1000, Anthony Towns wrote:
> > PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a
> > secret (albeit symmetric, rather than public/private keypair) IDEA key
> > everytime you try to encrpt a message. It encrypts the message with this
> > key, then encrypts the key with the recipients public key, and (and here's
> > the bit I was referring to) *sends that secret IDEA key across the net*.
> But you might emphasize that this secret key is used exactly once, just
> for this message. Intercepting it won't allow you to sign other stuff as
> someone else.

Intercepting the IDEA key will let you do one class of bad things
(reading a supposedly confidential message), intercepting the security-key
will let you do another class of bad things (impersonating the security
team). Intercepting one key isn't particularly easier or harder than
intercepting the other.

The point is that in both cases intercepting the key is a Bad Thing. The
point is that in both cases, any possibility of intercepting the key
has to be avoided for any security to exist at all. And the point is
that in both cases on-the-wire interception of the key is avoidable by
the simple expediency of encrypting the key before sending it.

Why do people seem to think signing stuff is some black art, and wave
chickens legs about and act all superstitiously when talking about
sending things over the net, or putting things on a semi-public computer?
There's nothing to be superstitious about. There are valid risks to
consider and then avoid, but that's *it*.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpzIKxqiVyHr.pgp
Description: PGP signature

Re: Signing Packages.gz

[Anthony Towns]

On Sun, Apr 02, 2000 at 07:44:56PM +0200, Robert Bihlmeyer wrote:
> Note that *any* keys that your agent holds can be snarfed by the
> admin(s) of any hosts where you ssh-in with agent forwarding enabled.

As I understand it, you can't actually *obtain* the keys, you can just
*use* them. Often though, this is just as good.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpGxvKFGrPN7.pgp
Description: PGP signature

Re: Signing Packages.gz

[Anthony Towns]

On Sun, Apr 02, 2000 at 06:52:37PM +0200, Robert Bihlmeyer wrote:
> > It's currently the case, yes, but it *could* be changed. You could,
> > for example setup dinstall so that it wouldn't accept NMUs of certain
> > important packages (such as gnupg).
> A good idea. Still: with package-granularity, this decision is made by
> the users, not the Debian administrators.

Users don't have enough information to make such a decision, however.
How do they know if James allowed a particular NMU to be made, because
not only did he not have time to make the upload himself, but because
there was a huge nefarious vulnerability there that made gpg accidently
distribute the user's private key along with every signed message?

Debian *can* make this decision, because we know each other. Most users
can only go `James who?'.

> > And, equally, a deliberately compromised package would probably get a
> > fair bit of coverage too. It'd be nice not have to rely on staying up to
> > date with slashdot and the mailing lists and IRC before doing an apt-get
> > dist-upgrade though.
> If you trust the debian-keyring maintainer, there is no problem for
> you: your keyring will get updated (to a version w/o the bad guy's
> key) and then any other packages get upgraded. People will probably
> also quickly updated packages compromised by this guy with fixed
> versions.

And if he's already compromised your local mirror, and decides that no
one needs an updated debian-keyring, or any of those irritating bugfree
packages?

To reiterate: signed .debs don't cope with any of the following attacks:

* Past/current developers doing nefarious things, especially if
  they also manage to compromise your local link in the distribution
  network.

* Vandalism against Packages files

* Maliciously distributing the worst possible selection of valid
  packages

These attacks are all based on the fact that sometimes it's Debian as a whole
acting in concert that you trust, not any and all particular developers.

Signed Packages.gz don't cope with master being compromised, or similar.
That is, if you trust Debian as a whole, that's a single point of
vulnerability.

Note that signed .debs also don't cope easily with Debian being
compromised for new users, who don't have an existing copy of James key
or the entire keyring to check against. Sometimes it *is* Debian that
you trust, not arbitrary maintainers.

> If there is consensus that the maintainer put a backdoor in on
> purpose, he will get kicked, a new version of debian-keyring will be
> produced, and the situation is repaired.

And if he's doing this on purpose, he'll likely go and compromise some
other systems, like, say, some downstream mirrors.

> > And if a developer gets kicked out? You can't revoke a signature (PGP
> > signatures are designed to certify identity, not trustworthyness),
> GPG can revoke signatures, so your conclusions do not apply.

Huh, so it can. Having x signatures on every maintainer key, where x-1 of
them have been revoked still seems thoroughly inelegant, however.

> > And again you have the usual problems if someone compromises one of the
> > machines with this `super key' on it.
> Indeed. But this machine could be made more secure than the debian
> main machines could ever get (there's no need for people other than
> the signer being root, etc.)

Hmmm? The `signer' in this case is `Debian'. There should really be
no need for non-Debian people to have root on master. To some extent
sponsors are Debian people, too.

> > Again, all these complicated distributed methods are great and all, but
> > they *aren't* actually particularly more secure, and nor are they more
> > convenient.
> I don't think it would more complicated for developers. Perhaps one
> additional entering of their passphrase, while building the .changes
> file, but that's it.

Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload.
(each .deb has to be signed separately, no matter which way you do it)

> Users could choose their paranoia level. From trusting (same as now)
> to paranoid (only trust packages signed by a key which is signed by my
> own key). 

This is very cliquey. Not everyone knows everyone else, even within Debian,
let alone thinking about people who've never met a Debian developer in
their lives.

So afaics, users can really only choose exactly one paranoia level:
allow everything in every package to be uploaded by anyone. I'm yet to
see a reasonable method of restricting even uploads of debian-keyring
that also allows James to resign.

> > In some vague academic sense, they're harder to compromise
> > *completely*, but I don't think that makes any particular exploits any
> > harder to perform, practically speaking.
> I partly concur. Even if the developer->user channel was completely
> secured by signatures et al, we would still have the problem of an
> attacker gaining very much by breaking into a single developer's
> m

Re: DUL (was Re: RBL report..)

[Branden Robinson]

On Mon, Apr 03, 2000 at 12:56:05AM +0100, Ian Jackson wrote:
> That mail direct from dynamic dialups is a problem is recognised
> throughout the community.  Not only did Paul Vixie, the author of
> BIND, and other leading lights of the Internet, decide to host,
> support, etc, the DUL.  Many ISPs prevent you from doing direct SMTP
> by having their routers block outgoing SMTP or transparently redirect
> it to their own mailservers.  I think that this is going to become
> much more common.  Use of the DUL is becoming more common too - for
> example, Cambridge University no longer accept DUL mail.  Sites that
> use DUL blocking report that it has very low false-positive rates -
> some claim even lower than the MAPS RBL.

You appeal to authority, call for bandwagon jumping, and rely upon
anecdotal accounts, but have yet to point to an RFC that forbids or
discourages the establishment of outbound SMTP connections from dialup
machines, whether they have dynamically assigned IP's or not.

The best way to force people like myself to do what you want is to get your
personal preferences on the standards track.  If they as widely shared as
you assert, this shouldn't be an insuperable problem.

Once you have done that, you won't have to shore up your position with
invalid inferences.

-- 
G. Branden Robinson|A celibate clergy is an especially good
Debian GNU/Linux   |idea, because it tends to suppress any
[EMAIL PROTECTED] |hereditary propensity toward fanaticism.
roger.ecn.purdue.edu/~branden/ |-- Carl Sagan


pgpGPGWELM81K.pgp
Description: PGP signature

Re: Ian Jackson, please get me the hell off your blacklist.

[Branden Robinson]

On Mon, Apr 03, 2000 at 12:56:11AM +0100, Ian Jackson wrote:
> I think you are being hypocritical.  You complain when other people
> post their opinions and discussions of this topic with you, yet you
> post your own diatribes here.  Since your request to keep the
> discussion to private email seems insincere I shall answer you here.

I've explained why I posted the first message in this thread -- I wasn't
sure I could successfully send mail to your machine.

Since then, I have merely followed up other people's remarks, if I felt
they misunderstood my position.

It is you who felt compelled to CC our argument to the submitter of every
bug I closed, an act I consider more intrusive than CC'ing a mailing list.

The people who submitted those bugs needed to know why I closed them.

They did not particularly need to hear you lecture me about your mail
system.

> Also, I object to your misleading characterisations of my position and

I don't recall that I have done so; please cite a reference.

> highly tendentious phrasings in your complaints.  They are not helpful

Perhaps "tendentious" bears a connotation of which I am not aware, but I do
not see how making remarks that are consistent with my perspective are
particularly problematic.

> for constructive debate and I respectfully suggest that you tone it
> down.  As I said in private email, I understand that you're angry, but
> please stop acting out.

I'm less angry about SAUCE being sassy with my mail now then I was before,
but since you continue to resort to logical fallacies to proclaim the value
of the DUL, I can't say that I'm distinctly less upset.

To wit:

"Paul Vixie approves of the DUL" is not a valid reason for adopting it.
Last I checked, Paul Vixie handled the MAPS project generally but delegated
management of DUL to Gordon Fecyk (IIRC).  We can presume that Paul Vixie
approves of DUL on principle, but because someone may be an expert in cron
and name service doesn't necessarily translate to a similar level of
expertise in good mail transport practice.

"Lots of other people use DUL" is not a valid reason for adopting it,
unless DUL's value is derived *solely* from the fact that other people
uses, and thus promotes interoperability.  In fact, DUL is designed to
reduce spam, not to be popular, and it actually has detrimental effects on
some hosts that follow various RFC's regarding SMTP connections.

"Statistics show that DUL generates few false positives" is not a valid
reason for adopting it unless these statistics are available for analysis
and critique, and we know that the data were gathered under well-controlled
conditions.  Jason Gunthorpe's statistics for the Debian mailing lists --
while I don't know how well they were controlled -- seemed to indicate that
the number of false positives was indeed signifcant.  So it is possible to
make statistical conclusions that cut both ways with respect to the
efficacy of DUL -- and that means that we either need better statistics, or
must abandon quantitative analysis as a means of determining the value of
DUL.

For an explanation of why the above are invalid logical arguments, I refer
the reader to any introductory level book on rhetoric or critical thinking.

> The problem is caused by the existence of spam, because it means that
> there are people who are trying to send mail to us whose mail we
> definitely want to exclude - and these exclusions are essentially
> political rather than technical and sometimes have false positives or
> mean that certain kinds of apparently harmless behaviour end up
> forbidden.  This leads to the kinds of heated debates we've seen here.

I don't understand why you feel the need to qualify "harmless" with
"apparently".  Is it your position that the sending of non-spam mail from a
dialup host is in fact harmful?  If so, please support that position with
an argument that doesn't refer to DUL (to do so would be circular
reasoning).

> It seems obvious to me that we should try to balance the negative
> effects of spam (and other kinds of abusive or broken mail) and the
> inconvenience of people having to change mail configuration or
> whatever to make the mail get through.

To achieve a "balance" acceptable to the corpus of the project is likely
going to require some kind of democratic approach, and involve compromise.
I have seen no evidence that DUL advocates are willing to compromise.

There might not be much in the way of middle ground to reach on this issue;
there are people who believe it is acceptable to deliberately impede the
transmission of e-mail that isn't spam, and there are those who don't.

It is well and good for each person to make this decision for his or her
own mailbox -- but blacklists are typically configured at the MTA level,
which means that people can unwittingly become subject to blacklists that
they wouldn't otherwise employ.

> Instead, we should argue each issue on merits in a constructive way,
> in terms of its costs, benefits etc.

Keep in 

Re: NMU of debianutils (was: Re: (Bug horizon) Problem bugs)

[Rainer Clasen]

On Sun, Apr 02, 2000 at 02:13:42PM -0500, Steve Greenland wrote:
> http://www.debian.org/~stevegr/debutils/debianutils_1.13.3_i386.deb

> Raphael and Ingo, if you get a chance, can you confirm I didn't screw
> this up? Rainer, I think this fixes your bug too (#57464). Guy, if you
> don't object by ~22:00 Tuesday, April 4th (CDT), I'm going to go ahead
> and upload it to Incoming.

I've installed it. Lets see how it behaves. More to come tommorow.


Rainer

-- 
KeyID=58341901 fingerprint=A5 57 04 B3 69 88 A1 FB  78 1D B5 64 E0 BF 72 EB

Re: ITP: lirc, devfsd

[Rainer Clasen]

On Sun, Apr 02, 2000 at 10:16:42PM +0100, Tom Lees wrote:
> LIRC is Linux Infra-red Remote Control support, see
> http://fsinfo.cs.uni-sb.de/~columbus/lirc/index.html

Ist it compiled for only one certain receiver type + port? Or were you able
to make it configurable?



Rainer

-- 
KeyID=58341901 fingerprint=A5 57 04 B3 69 88 A1 FB  78 1D B5 64 E0 BF 72 EB

Re: ITP: gnome-db

[Andreas Tille]

On Fri, 31 Mar 2000, Dan White wrote:

> gnome-db (http://www.gnome.org/gnome-db) is "a framework for creating 
> database applications. It provides a common API with pluggable back ends 
> to different database sources as well as various specialized widgets for 
> handling many database tasks." It's also part of gnome office 
> (http://www.gnome.org/gnome-office).
> 
> It's licensed under the GPL.
> 
> While I'm not a developer, Ed Boraas ([EMAIL PROTECTED]) has graciously 
> volunteered to sponsor this package.
> 
> Please let me know if this conflicts with anyone's efforts.
Please go for it!

I'd need this package very much.  I considered it to package it
myself and tried to contact the author but he didn't answer to my
e-mail since 1 month :-(.  Did you told him your plan?

Unfortunately I can't help you packaging it because I didn't start
working on it but I hope very much that you get the package soon.

I hope that FreeTDS 0.51 will come soon which provides an ODBC driver
to MSSQL server and will hopefully work with gnome-db.

Kind regard

Andreas.

Re: Release-critical Bugreport for March 31, 2000

[Goswin Brederlow]

Ben Collins <[EMAIL PROTECTED]> writes:

> On Sat, Apr 01, 2000 at 10:13:38AM -0800, esoR ocsirF wrote:
> > Caution, IANAD. Just tring to help
> > 
> > Package: cricket (debian/main)
> > Maintainer: Matt Zimmerman <[EMAIL PROTECTED]>
> >   56948  cricket depends on non-existant package
> > 
> > Package: ftp.debian.org (pseudo)
> > Maintainer: Guy Maor <[EMAIL PROTECTED]>
> >   60707  cricket depends on a nonexistent package
> > 
> > Shouldn't these be merged?
> 
> No, you can only merge bugs on the same package. One is against the
> pacakge itself, the other is for ftp.debian.org to remove that package.

Shouldn`t it be reassigned to the same package and merged?

If its realy a bug of ftp.de.debian.org I could submit a lot of such bug
reports for non-i386 packages, many of them violating their license.

May the Source be with you.
Goswin

Re: DUL (was Re: RBL report..)

[Manoj Srivastava]

Hi,

I don't like getting spam. I dislike the fact that I am
 inconvenienced.  I have not yet decided to give in, though. And, in
 my opinion, bouncing mail from people innocent of sending spam is
 giving in to spammers.

I ifnd this phenomena remniscent of may people in the trhoes
 of a war: they become obsessed by the enemy; and collateral damage is
 increasingly acceptable in the pursuit of the war. 

I have not yet gotten that numbed out.

The problem with DUL is that they don't care if the people
 blocked ever sent any spam. The have the wrong color ski^H^H^H^H^H^H^H^H^H
 type of connection, and must be the enemy.

Frankly, it is an arbitrary criteria to reject mail, based on
 an assumption that people from those kind of net neighborhoodsare
 more likely to commit crimes, since criminals in them there
 neighborhoods are less likely to be caught and punished. The Net
 version of racial profiling. 

Personally, if I get a bounce from anywhere telling me they
 have blacklisted me, I return the favour.

It's all going to end in heat death anyway.

manoj
-- 
 Perhaps the most widespread illusion is that if we were in power we
 would behave very differently from those who now hold it -- when, in
 truth, in order to get power we would have to become very much like
 them.  (Lenin's fatal mistake, both in theory and in practice.)
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: DUL (was Re: RBL report..)

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 02:38:24AM -0500, Manoj Srivastava wrote:
> It's all going to end in heat death anyway.

Of course, so we might as well turn off the computers right now.


Cheers
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Obsolete packages

[Petr Cech]

On Fri, Mar 31, 2000 at 09:41:29AM +0200 , Michael Meskes wrote:
> After upgrading my machine I found some obsolete packages. Before purging
> them I'd like to know if there are replacements:
> lde

yes. it had RC, and it is still in mess due to some strange gcc header
interactions :(

> manpages-net

this package appeared only for a short time (and yes, I have it installed
too). I think it was in Incoming only.

> gtkbrowser

woody

Petr Čech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

Re: DUL (was Re: RBL report..)

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 12:00:52AM -0400, Branden Robinson wrote:
> You appeal to authority, call for bandwagon jumping, and rely upon
> anecdotal accounts, but have yet to point to an RFC that forbids or
> discourages the establishment of outbound SMTP connections from dialup
> machines, whether they have dynamically assigned IP's or not.

RFCs do not forbid or discourage spam either, yet most people
do not consider it to be a good idea.

> Once you have done that, you won't have to shore up your position with
> invalid inferences.

Nor will you.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


pgpR9F392AgPg.pgp
Description: PGP signature

Re: Signing Packages.gz

[Robert Bihlmeyer]

Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:

>  All packages can run things as root. Even the most simple game.

Doing clandestine things in a install-script is harder than in a
binary.

-- 
Robbe

Re: Pgcc in Deb

[Eray Ozkural]

On Sun, 02 Apr 2000 20:28:41 David Starner wrote:

> Um, that's not what I've heard. Since optimizing for the Pentium
> will sometimes pessimize the Pentium (Pro, II, III), and the
> speedup from most programs is not that great, and anything that
> needs it can be recompiled locally, it wasn't worth the archive
> space or the manpower or extra trouble.

I disagree. From experience, I know that up to %50 speedup can be gained
in number crunching stuff. I'd suspect %20 could be pretty normal for
most CPU hungry apps, and the overall speedup would be significant.


__
exa
Eray Ozkural,
CS Dept, Bilkent Univ.

Re: DUL (was Re: RBL report..)

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 02:38:24AM -0500, Manoj Srivastava wrote:
> The problem with DUL is that they don't care if the people
>  blocked ever sent any spam. The have the wrong color ski^H^H^H^H^H^H^H^H^H
>  type of connection, and must be the enemy.

The analogy is flawed. Solutions have been offered several
times owner for DUL-listed or potentially DUL-listed users.
All of which should not be too difficult to set up for
a Debian developer.

You see, DUL users don't reject mail from particular people,
just from particular addresses. You just have to route
your email to me through a trusted mail server. It's a bit
like the no junk mail sticker on my letter box; you're
not welcome to drop things in my mailbox directly, but if
you post them they'll arrive just fine.


hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Re: How to hide/show cursor without Ncurses ?

[lorenzo . zampese]

I asked to list :

"How to hide/show cursor without Ncurses libraries..."

and you answered me, Dos programmers were weenie because they...,
...it is evil consider a generic terminal...
That's a yours suggestion/opinion/idea, but you didn't answered me really.
Please read the question carefully!

A possible answer could be :

->#include 
->
->void hide_cursor(...){
->  tcgetattr(...);
->  ...
->  tcsetattr(...);
->}
->..
->..
->NOTE: but you should use the "ncurses libraries" because doesn't exists a
generic
->type of terminal, and then ...bla bla bla...

or

->Read documentation on "www.xyz.org"

The point is: an exact question needs an exact answer.
Comments and suggestions are another thing, though they are welcome,
OK ?

Anyway I think you don't know the answer, really.

   -- Memo - Header ---

To:   Lorenzo Zampese/Electrolux Professional S.P.A./Italy/Electrolux
  Group

cc:

From: Craig Sanders <[EMAIL PROTECTED]>

Date: 03/04/2000 08:34:15 GMT
  03/04/2000 10:34:53

Subject:  Re: Re: How to hide/show cursor without Ncurses ?

- Memo - Message --




On Mon, Apr 03, 2000 at 09:12:30AM +0100,
[EMAIL PROTECTED] wrote:
> Yuors is a good non-answer !

wrong. it was the right answer. it's not my problem that you don't like
the answer.

craig

--
craig sanders

Re: DUL

[Robert Bihlmeyer]

First I'd like to know what "dialup" includes means for you.

Ian Jackson <[EMAIL PROTECTED]> writes:

> It does seem that some people do find it beneficial to send mail
> direct from their dialups (static or dynamic).  I don't understand why
> they think this is a good idea,

There are apparently a number of ISPs that do well in providing an IP
pipe, but suck big rocks when it comes to administering a mail server.

This number will certainly grow as more and more infrastructure
(phone, cable, electricity) providers will jump on the service
provider bandwagon.

> and I think it has a number of technical problems.

What are the problems for static IP dialups?

> It's clear, though, that the project will have to come to a common
> decision about this.  It's not just about what the project's
> mailservers will accept.  As I said in my other mail, since we all
> need to communicate with each other, either every developer must be
> forbidden from using the DUL, or every developer must either not send
> mail direct from their dynamic dialup, or must be prepared to send it
> differently if there is a problem.

You must not forget the users. If Debian comes to the consensus that
DUL is a Good Thing, this affects users, too. All MTA packages should
probably come with a big fat warning that you should use a relay if
your IP is dynamic.

-- 
Robbe

Re: Signing Packages.gz

[Marcus Brinkmann]

On Mon, Apr 03, 2000 at 01:01:30PM +1000, Anthony Towns wrote:
> On Sun, Apr 02, 2000 at 02:57:06PM +0200, Marcus Brinkmann wrote:
> > > > As dinstall verifies the keys on the packages (which already exist, btw,
> > > > they are just not propagated), it puts itself in the middle of the 
> > > > chain:
> > > Well, as Jason points out, they are propogated: by the -devel-changes
> > > list.
> > They are not delivered to the user when he is downloading a deb, with no
> > dselect method, and not with apt, and espcially not when downloading the
> > package manually.
> 
> But they could be, with minimal changes. Stick the latest .changes files
> in debian/changes somewhere and add some code to apt to get it.

The changes file would be sufficient, but it is not ideal, because it
always signs a group of packages. Much better would be to stick the signature 
inside the deb.

> I'd be interested in seeing some code for this. You keep throwing around the
> word `easy', as though it *is* just as plausible to implement this method.
> Please, at least write some pseudocode for it.

before making the ar, run pgp/gpg on a list of md5sums of all files contained
in the ar. Add this signature to the ar.

When extracting a deb, verify the md5sums and the signature.

> Make sure you consider the necessity of keeping debian-keyring up-to-date
> in case of compromised keys. Make sure you either explicitly do use a
> `single key' that's easy to verify, or not. If you do, make sure you allow
> some way of coping with James' key being updated, or James retiring and
> someone else taking over the job; and make sure you cope with upgrades
> that possibly skip the generation where this happens.

Of course. This all is not different from the dinstall keyring, and should
be solved in exactly the same ways.

[snip]
> Marcus: How would dpkg with debian-keyring handle all this?
>  

Well, the default should be to use the installed debian-keyring.
This will work well for Debian native packages. Of course, care has to
be taken when updating it (and this should be done manually, IMHO).

For third party packages, we can allow a seperate key-ring,
where root can add public keys from third parties he trusts.
There could be a default /etc/debian/third-parties-keyring.pgp or
it could be specified at the command line. The origin of the package
should be displayed at installation time, of course, if verificable.

> And note that saying `This distribution is Debian' is different to
> saying `This distribution is made up of stuff put together by Debian
> maintainers.'  The latter could be put together for a special series of
> `When Packages Attack!' and include all the best security holes ever
> distributed by Debian.

So dinstall (ha!) or lets say the admin team is doing a security check on
all packages before adding them to the archive and to the Packages file?
They are auditing the source and recompiling the binary packages before
making a release?

What Debian ships IS "the distribution is made up of stuff put together
by Debian maintainers."

And this, I think, is the critical point. The signed debs case integrates well
with a distributed system like Debian is, where there is no central
authority to decide what's good and bad. And this is the way Debian should be.

If you are claiming that what Debian ships is something different than what
the maintainer put together, I shall neglect all responsibility for all my
packages from now on.

I read the rest of your mail, but I don't think there is much else I would
answer differently than I did before, and it is preferable to keep the reply
short, to focus on the new things.

Thanks,
Marcus

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Apr 03, 2000 at 10:24:02AM +0200, Robert Bihlmeyer wrote:
> Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> >  All packages can run things as root. Even the most simple game.
> Doing clandestine things in a install-script is harder than in a
> binary.

#!/bin/sh
/usr/games/mygame --update-score-file-format

...with the malicious code in the game source itself seems pretty
clandestine.

Self-modifying postinsts are probably possible too, with some care.

Cheers,
aj, thinking like a criminal since 1978

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpnCfAos9jDc.pgp
Description: PGP signature

Re: DUL

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 12:01:22PM +0200, Robert Bihlmeyer wrote:
> There are apparently a number of ISPs that do well in providing an IP
> pipe, but suck big rocks when it comes to administering a mail server.
> 
> This number will certainly grow as more and more infrastructure
> (phone, cable, electricity) providers will jump on the service
> provider bandwagon.

Then there is a market for relay providers.

> You must not forget the users. If Debian comes to the consensus that
> DUL is a Good Thing, this affects users, too. All MTA packages should
> probably come with a big fat warning that you should use a relay if
> your IP is dynamic.

Well, eximconfig already says

 (2) Internet site using smarthost: You receive Internet mail on this
 machine, either directly by SMTP or by running a utility such as
 fetchmail. Outgoing mail is sent using a smarthost. optionally with
 addresses rewritten. This is probably what you want for a dialup
 system.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sun, Apr 02, 2000 at 08:11:15PM +0200, Torsten Landschoff wrote:
> 
> We might want to revoke the old key. If James leaves we can't revoke his key
> because it is HIS key. We can however revoke the dinstall key because it 
> is by definition Debian's key. But this is nitpicking.

Who is Debian? Where is the safe where the secret key will be stored
(as the keys from Microsoft are)? Who will be responsible for all this, and
what makes you belief that those will be more careful about the key
than James?

The central authority doesn't mix extremely well with the distributed
organization Debian is.

Note that a signed Packages file works extremely well for a single cooperation
who produces a Debian based distribution, or an individual.

People keep forgetting about Debians nature, and this keeps bothering me.

> You have started the child game. We want to make a simple change to apt as
> dinstall and you keep telling us that it won't make things better. Now you
> said that making things better but not perfect is not the Debian way of 
> doing things.

Yes. Because the Debian installation tool is dpkg, and not apt.

This is the second main point that I disagree with (aside of the security
discussion, which is complicated and by now covered well). A solution
for Debian should serve all people, those who use apt, those who use dpkg
and downloaded files, those who use other methods (dselect etc).

Thanks,
Marcus

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sun, Apr 02, 2000 at 02:30:12PM -0600, Jason Gunthorpe wrote:
> On Sun, 2 Apr 2000, Marcus Brinkmann wrote:
> 
> > This is a seperate problem. I agree that this should not be the case, but it
> > has no place in this discussion. If individual developer keys are
> > compromised, we have a problem no matter what. Developers should not store
> > secret keys on net connected machines, point.
> > 
> > However, this only affects the developers packages, not the whole archive.
>   ^
>  
> GAH!? Don't you see that isn't true?? Look, a hack attempt would go like
> this.
> 
>   1) Break root on master
>   2) Use that to break user account on developer victum (any will do)
>  (Hint: I have already shown that torsten at least could be 
>   attacked quite easially)
>   3) Steal PGP key
>   4) Use stolen PGP to form new glibc package with trojan, sneak into
>  archive using #1

And it wouldn't be strange that random Joe is uploading a pgp package?
And random joe or the real glibc maintainer will not speak up if this
really happens?

But you have a point, and I add this case: 
This only affects the developers packages and NMUs.
(one could vaguely interpret a NMU as the developers package, as it is
carrying his signature, but I admit that I didn't have NMUs in mind when
writing this.)

Thanks,
Marcus

Re: DUL (was Re: RBL report..)

[Branden Robinson]

On Mon, Apr 03, 2000 at 06:09:41PM +1000, Hamish Moffatt wrote:
> On Mon, Apr 03, 2000 at 12:00:52AM -0400, Branden Robinson wrote:
> > You appeal to authority, call for bandwagon jumping, and rely upon
> > anecdotal accounts, but have yet to point to an RFC that forbids or
> > discourages the establishment of outbound SMTP connections from dialup
> > machines, whether they have dynamically assigned IP's or not.
> 
> RFCs do not forbid or discourage spam either, yet most people
> do not consider it to be a good idea.

Weak analogy.  Specification of a set of circumstances under which Internet
hosts are expected to initiate (or accept) SMTP connections is a technical
issue well within the scope of the existing RFC's.

I'd imagine RFC's don't forbid spam (if in fact they don't -- I don't know)
because it is difficult to identify what is spam and what is not based on
criteria easily evaluated by alogorithmic processes amenable to
computation.

Furthermore, that any issue is unspecified in an RFC does not mean that the
RFC's already address all issues that need to be addressed.

If any DUL users feel that the specification within a standards-track RFC
of a set of circumstances under which Internet hosts are expected to
initiate (or accept) SMTP connections is an undesirable end, I'd certainly
like to hear the reasons why.

> > Once you have done that, you won't have to shore up your position with
> > invalid inferences.
> 
> Nor will you.

You have asserted, but offer no evidence.  Please identify the fallacious
reasoning or false premise you claim to perceive.

-- 
G. Branden Robinson| Yesterday upon the stair,
Debian GNU/Linux   | I met a man who wasn't there.
[EMAIL PROTECTED] | He wasn't there again today,
roger.ecn.purdue.edu/~branden/ | I think he's from the CIA.


pgpERoAb1dLiO.pgp
Description: PGP signature

Re: DUL (was Re: RBL report..)

[Branden Robinson]

On Mon, Apr 03, 2000 at 06:58:18PM +1000, Hamish Moffatt wrote:
> On Mon, Apr 03, 2000 at 02:38:24AM -0500, Manoj Srivastava wrote:
> > The problem with DUL is that they don't care if the people
> >  blocked ever sent any spam. The have the wrong color ski^H^H^H^H^H^H^H^H^H
> >  type of connection, and must be the enemy.
> 
> The analogy is flawed. Solutions have been offered several
> times owner for DUL-listed or potentially DUL-listed users.
> All of which should not be too difficult to set up for
> a Debian developer.

You demonstrate limited facility to construe the analogy.

The "solutions" that have been offered effectively result in concealing the
fact that the ultimate origin of the mail is a dynamic IP, therefore this
is like asking people with the "wrong color skin" to paint it an
"acceptable" color.

What mechanism do you propose that people on dynamic IP's use to identify
their mails as non-spam while still making direct SMTP connections to the
MX host of the destination domain?

-- 
G. Branden Robinson| The first thing the communists do when
Debian GNU/Linux   | they take over a country is to outlaw
[EMAIL PROTECTED] | cockfighting.
roger.ecn.purdue.edu/~branden/ | -- Oklahoma State Senator John Monks


pgpcK5XZjFL6K.pgp
Description: PGP signature

Re: Signing Packages.gz

[Robert Bihlmeyer]

Anthony Towns  writes:

> On Sun, Apr 02, 2000 at 07:44:56PM +0200, Robert Bihlmeyer wrote:
> > Note that *any* keys that your agent holds can be snarfed by the
> > admin(s) of any hosts where you ssh-in with agent forwarding enabled.
> 
> As I understand it, you can't actually *obtain* the keys, you can just
> *use* them. Often though, this is just as good.

Yes. "Snarf" was the wrong word. Just being able to use them while the
user is connected restricts your time to find the hosts this key
unlocks.

-- 
Robbe

Problem with bug system

[Michael Meskes]

Is this a known problem?

Michael

- Forwarded message from Debian Bug Tracking System <[EMAIL PROTECTED]> 
-

Date: 3 Apr 2000 06:03:23 -
From: [EMAIL PROTECTED] (Debian Bug Tracking System)
To: Michael Meskes <[EMAIL PROTECTED]>
Subject: Processed: Re: Processed:

Processing commands for [EMAIL PROTECTED]:

> send 61515
Error getting logs for Bug#61515 (code 65280 ):

lynx: Can't access startfile 
file://localhost/var/lib/debbugs/www/db/61/61515.html


> send 61573
Error getting logs for Bug#61573 (code 65280 ):

lynx: Can't access startfile 
file://localhost/var/lib/debbugs/www/db/61/61573.html


>
End of message, stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)

- End forwarded message -

-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De   | Use PostgreSQL!

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Apr 03, 2000 at 12:02:29PM +0200, Marcus Brinkmann wrote:
> > But they could be, with minimal changes. Stick the latest .changes files
> > in debian/changes somewhere and add some code to apt to get it.
> The changes file would be sufficient, but it is not ideal, because it
> always signs a group of packages. Much better would be to stick the signature 
> inside the deb.

Agreed. But if we want to get anywhere, this seems like an easy way to
start prototyping.

I know I'm coming across a bit as `your way sucks, and you're lame and
stuff' but I don't actually mean it. If we can move this discussion to
actually getting some code done, I'm more than happy.

> > I'd be interested in seeing some code for this. You keep throwing around the
> > word `easy', as though it *is* just as plausible to implement this method.
> > Please, at least write some pseudocode for it.
> before making the ar, run pgp/gpg on a list of md5sums of all files contained
> in the ar. Add this signature to the ar.
> When extracting a deb, verify the md5sums and the signature.

Verify the signature against what, exactly? .../debian-keyring.{pgp,gpg} ? 
What about packages made up by Storm, or Corel, or third parties?

Should any .deb be allowed to happily overwrite the keyring file? [0]

How do you check that the keyring is only updated by James?

I'd particularly like you to make a decision on using James' key or
not. Either way has problems, which we're not going to ever solve if you
just keep changing your mind on whether you have a source-of-all-trust
or not, depending on which works better in a given paragraph.

> > Make sure you consider the necessity of keeping debian-keyring up-to-date
> > in case of compromised keys. Make sure you either explicitly do use a
> > `single key' that's easy to verify, or not. If you do, make sure you allow
> > some way of coping with James' key being updated, or James retiring and
> > someone else taking over the job; and make sure you cope with upgrades
> > that possibly skip the generation where this happens.
> Of course. This all is not different from the dinstall keyring, and should
> be solved in exactly the same ways.

The key itself can be updated (without verifying it) during an apt-get
update. This key can be signed by *all* past dinstall keys. Similarly
for the security key. You check that it's either the same as your
current keys, or that its signed by your current keys, and use it if
so. Reasonably easy.

This doesn't work so well if your source-of-all-trust is James' key:
signatures by his key probably just certify that he's seen your passport,
not that you should be trusted by every Debian user ever. If James quits
the project, he's not going to give us his personal key so we can use it
to sign each of the subsequent dinstall maintainers keys, and he might
not want to be bothered doing this himself, either.

Oh, another problem. What to do about a maintainer's existing packages
when he retires? Presumably his key is pulled from the keyring, but then
how does someone go about installing one of his packages? Do -qa have to
pointlessly go through and recompile all his packages? If they're going
to be putting their name to them, are they going to be comfortable with
just blithely signing packages they don't have time to carefully audit?

> > Marcus: How would dpkg with debian-keyring handle all this?
> Well, the default should be to use the installed debian-keyring.
> This will work well for Debian native packages. Of course, care has to
> be taken when updating it (and this should be done manually, IMHO).

If it has to be done manually, most people will forget to do it. If
they're keyrings aren't uptodate, much of their security goes out
the window.

> > And note that saying `This distribution is Debian' is different to
> > saying `This distribution is made up of stuff put together by Debian
> > maintainers.'  The latter could be put together for a special series of
> > `When Packages Attack!' and include all the best security holes ever
> > distributed by Debian.
> So dinstall (ha!) or lets say the admin team is doing a security check on
> all packages before adding them to the archive and to the Packages file?

No, obviously. But as things turn out, at any one time, Debian doesn't
have all that many (known) security bugs. If you don't have to choose any
/one/ time though, and can select the worst instance of netbase, and the
worst instance of make, and the worst instance of mh, and so on, you can
come up with security holes or grave bugs in a lot of packages. (There
are 166 packages with urgency=high uploads on my system, for example)

> What Debian ships IS "the distribution is made up of stuff put together
> by Debian maintainers."

Yes. But not every collection of stuff put together by Debian maintainers is
something Debian ships.

Mixing up things from experimental and bo and woody would be `made up
of stuff put together by Debian maintainers', but it'd probably be as
buggy and

Re: Pgcc in Deb

[Joseph Carter]

On Mon, Apr 03, 2000 at 01:40:51AM +0200, Romain Chantereau wrote:
> > So the original question remains: is there a simple pgcc available
> > somewhere?
> 
> Yes !  is there a simple pgcc available somewhere?

There may or may not be, however I highly recommend avoiding pgcc.  There
are exactly two braindead compilers that are guaranteed to screw up
something in QuakeForge: vc++ and pgcc.

We all know how screwed up the former is.  The latter has (and has had for
some time) several very obnoxious bugs which result in bad code on certain
non-trivial applications.  Those patches and improvements found in pgcc
get added to egcs as soon as they are known not to do stupid things anyway
so it's worthwhile simply to stick with egcs and use the optimizations it
provides.

In almost all cases you will not be seeing any noticable difference in
execution speed.

-- 
Joseph Carter <[EMAIL PROTECTED]>   GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

 netgod: My calculator has more registers than the x86, and
 -thats- sad

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Apr 03, 2000 at 12:10:27PM +0200, Marcus Brinkmann wrote:
> > We might want to revoke the old key. If James leaves we can't revoke his key
> > because it is HIS key. We can however revoke the dinstall key because it 
> > is by definition Debian's key. But this is nitpicking.
> Who is Debian?

Look around you. Look in a mirror even. You know the answer to this.

> Where is the safe where the secret key will be stored
> (as the keys from Microsoft are)? Who will be responsible for all this, and
> what makes you belief that those will be more careful about the key
> than James?

master.debian.org; debian-admin and the ftp people; and mu. We've been over
this.

> The central authority doesn't mix extremely well with the distributed
> organization Debian is.

This isn't a central authority, and it does actually mix well with Debian.
It doesn't create a choke point, it's easy to implement, it doesn't add
any authority to anyone, or extra control to anyone.

This argument, coming from you, actually makes a hell of a lot more
sense to me than some of the others made in this thread. But I don't
*think* it's actually a problem: it formalises the group yes, which can
definitely be dangerous, but it doesn't centralise it, or distort it,
or restrict it, or anything, as far as I can see. (This is in contrast
to the constitution, eg, which does centralise some things, and does
distort others. General resolutions are a distortion of the regular
cut-and-thrust of consensus building, eg)

> > You have started the child game. We want to make a simple change to apt as
> > dinstall and you keep telling us that it won't make things better. Now you
> > said that making things better but not perfect is not the Debian way of 
> > doing things.
> Yes. Because the Debian installation tool is dpkg, and not apt.

dinstall is a part of dpkg, and Apt is now the main dinstall method. That
makes apt pretty central to Debian. That's the first point.

The second point is that signed Packages are incredibly easy to verify
manually. You run ``gunzip Packages.gz; gpg --verify Packages.gpg
Packages''

ie, people who don't want to use apt can quite happily make use of these
signatures, in their favourite dselect method.

If you want to verify a particular package, you can (hypothetically) do:

gunzip Packages.gz
gpg --verify Packages.gpg Packages
# check to see that it's signed by the right key, as well as
# that it's a valid signature
MD5a=`grep-dctrl -F 'Package' -s MD5sum '^telnetd' Packages |
 cut -d\  -f2`
MD5b=`md5sum telnetd.deb | cut -d\  -f1`
if [ "$MD5a" = "$MD5b" ]; then
echo "MD5sum match"
else
echo "MD5sum mismatch :("
fi

As far as ease-of-use and good-use-of-bandwidth-and-time go, I think
signing Packages.gz is optimising for the right case (ie the common one).

> This is the second main point that I disagree with (aside of the security
> discussion, which is complicated and by now covered well). A solution
> for Debian should serve all people, those who use apt, those who use dpkg
> and downloaded files, those who use other methods (dselect etc).

Is this satisfied too, now, then? Well, perhaps not satisfied, but at
least somewhat alleviated? (For people who download by hand and just
use dpkg, clearly dpkg --check-deb-sig is obviously much more convenient)

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgptI2OzyzXt1.pgp
Description: PGP signature

Re: Signing Packages.gz

[Anthony Towns]

On Mon, Apr 03, 2000 at 12:49:24PM +0200, Robert Bihlmeyer wrote:
> > As I understand it, you can't actually *obtain* the keys, you can just
> > *use* them. Often though, this is just as good.
> Yes. "Snarf" was the wrong word. Just being able to use them while the
> user is connected restricts your time to find the hosts this key
> unlocks.

And it might be worth mentioning that `ssh -v' from your local host, will
let you see which machines are getting your ssh-agent to do stuff. This
can get a bit ugly, but it's probably worthwhile.

An exercise for someone interested: hack ssh-agent so it pops up a window
which you can use to say `yes' or `no' to requests from non-localhosts for
secret key operations. Usual provisos about making this an option, and not
breaking things for people who don't use X, and so on.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpJLxPY5x8WP.pgp
Description: PGP signature

Re: Signing Packages.gz

[Marcus Brinkmann]

On Mon, Apr 03, 2000 at 01:36:01PM +1000, Anthony Towns wrote:
> 
> Debian *can* make this decision, because we know each other. Most users
> can only go `James who?'.

This is easily identified as a play with names. Who is this "Debian" person
you refer to anyway? After all, behind every action is a developer.

> And if he's already compromised your local mirror, and decides that no
> one needs an updated debian-keyring, or any of those irritating bugfree
> packages?

This is free software after all. You can already make a mirror that only
carries out of date packages. What sort of an attack is that supposed to be?

> To reiterate: signed .debs don't cope with any of the following attacks:
> 
>   * Past/current developers doing nefarious things, especially if
> they also manage to compromise your local link in the distribution
> network.

I still disagree (the details are spread over several mails of course).

>   * Vandalism against Packages files

Can you explain this attack to us?

>   * Maliciously distributing the worst possible selection of valid
> packages

See above. Seems to be a "Free Software" attack to me.
Maybe you should file a bug report against the GPL.
(You didn't laugh? Sorry, but it was supposed to be funny :)

> These attacks are all based on the fact that sometimes it's Debian as a whole
> acting in concert that you trust, not any and all particular developers.

A Debian as a whole does not exist. There exists an abstract incorporation,
but that's it. The rest is a bunch of developers. I don't see the difference
in trusting the key of James or some other Debian admin. I see a difference
between a personal key and a key which is lying around on some net-connected
machine.

You are attempting to abuse the public key (PGP) protocol to verify a group
as the ownership of something. This can't work, because it was not designed
to cope with such a situation. You would need to use an entirely different
cryptoprotocol to solve this. All problems I see (and you keep to sweep under
the table) are a direct result from this.

Instead, with signed debs, the PGP protocol is used exactly for what it was
designed: A signature from an individual, not from a group.

(Of course, you *can* have a key that is accessable to several people, for
example for organizations, as Microsoft. However, those people have to
share the location, and thus act like one abstract individual. That the
same can't be true for Debian is obvious: We don't have a headquarter).

One note: Of course this is not the case if the Packages file is signed
locally by an indivual. But in this case, the analogy to the debian-keyring
key is complete (only the technical details are different, and individual
 debs can't be checkd of course. )
 

> Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload.
> (each .deb has to be signed separately, no matter which way you do it)

There are solutions to this. (Read the pgp/gpg manuals). You can pass the
phrase from other programs or the environment.

As a side note, realize that the secret dinstall key can't be protected 
efficiently by a passphrase, because the phrase itself had to be stored
and readable by dinstall.

> Securing the way Debian distributes its software is a *long* way from
> making it impossible for an attacker to compromise huge numbers of
> Debian boxen.

And is of course an orthogonal issue.

Thanks,
Marcus

PS: I would like to meet this Debian person, he must be
terrible shizophrene. ;)

Re: Signing Packages.gz

[Robert Bihlmeyer]

Anthony Towns  writes:

> Users don't have enough information to make such a decision, however.
> How do they know if James allowed a particular NMU to be made, [...]

It would probably be better to let this essential package be
maintained by a small team. Three or four people would suffice to
lower the probability of all of them being busy at the same time. An
upload of any of these would be "valid" for Debian as a whole (but
individual users could still choose to mistrust some of them).

> Debian *can* make this decision, because we know each other. Most users
> can only go `James who?'.

Those users will have to trust Debian, in the incarnation of the
Debian website, or official CDs. Both of these would list the keys of
the keyring team at least.

> And if he's already compromised your local mirror, and decides that no
> one needs an updated debian-keyring, or any of those irritating bugfree
> packages?

This is a problem, that is not solved by a signed Packages.gz. If
some package has an exploit (through malice or because of the usual
oversight), somebody controlling a mirror can always prevent updates
from filtering down.

People usually read security-news-services to get around this.

> To reiterate: signed .debs don't cope with any of the following attacks:
> 
>   * Past/current developers doing nefarious things, especially if
> they also manage to compromise your local link in the distribution
> network.

Not true for past developers. With regard to current developers, it's
the same with signed Packages.gz.

>   * Vandalism against Packages files

My solution was to sign the metadata (possibly, *only* the metadata,
since it includes an md5 of the package proper, anyway).

>   * Maliciously distributing the worst possible selection of valid
> packages

I think that packages having security bugs should be fixed/removed
with haste. Then this degenerates to the "preventing updates" problem.

> > GPG can revoke signatures, so your conclusions do not apply.
> 
> Huh, so it can. Having x signatures on every maintainer key, where x-1 of
> them have been revoked still seems thoroughly inelegant, however.

I don't see why you think this is necessary. This does *not* involve
changes to the master-key or any other maintainer's key. The new
keyring just includes a new version of the kicked maintainer's key
with one additional revocation-signature. This new signature tells
that this key is no longer trusted. Example:

$ gpg --check-sigs testkey
pub  1024D/36FF3F58 1999-07-24 Robert Bihlmeyer (Testkey - do not use)
rev!   E6583EFB 2000-03-31  Robert Bihlmeyer <[EMAIL PROTECTED]>
sig!   36FF3F58 1999-07-24  Robert Bihlmeyer (Testkey - do not use)
sig!   E6583EFB 2000-03-31  Robert Bihlmeyer <[EMAIL PROTECTED]>

This key is self-signed, signed by E6583EFB, and there's a revocation
by E6583EFB on it, invalidating all signatures by E6583EFB.

Yes, you can distribute a keyring package that is stripped of this
revocation-signature, but you can't distribute a signed package of it.

> > Indeed. But this machine could be made more secure than the debian
> > main machines could ever get (there's no need for people other than
> > the signer being root, etc.)
> 
> Hmmm? The `signer' in this case is `Debian'. There should really be
> no need for non-Debian people to have root on master. To some extent
> sponsors are Debian people, too.

The maximum security that the key can have on master is much less then
what it can have on an individual's machine. Do you contest that?

> Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload.
> (each .deb has to be signed separately, no matter which way you do it)

Use a piece of software that holds the passphrase (or unencrypted key)
in memory for as long as the signing of all packages takes. I have
exactly such a program in use, here.

FWIW, I already stated that I'd rather have parts of Packages.gz
signed by the responsible developers. Then, if one uploads 10 packages
at once, one could just have this added to Packages.gz:

-BEGIN xxx SIGNED MESSAGE-
Package: foo1
[...]
Package: foo2
[...]
Package: foo10
[...]
-BEGIN xxx SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE46IGV2sjtWDb/P1gRAuwvAKCFCLndF/PRfotCA+XHtht7GvQV2gCeO1iZ
MfwN8JDj/vKOOCaUFNO0pPQ=
=T8re
-END xxx SIGNATURE-

(s/PGP/xxx/ to protect MUAs that grep for these strings)

> This is very cliquey. Not everyone knows everyone else, even within Debian,
> let alone thinking about people who've never met a Debian developer in
> their lives.

It would be an alternative, not a requirement. People can still go on
as before.

> I probably should add a rider that it's already quite difficult to do
> this; developers machines aren't your regular `let's install RedHat
> 5.0 and leave all the default servers running', nor are most mirrors,
> and certainly most popular mirrors.

Of course. The mirror I u

Re: DUL (was Re: RBL report..)

[Herbert Xu]

Branden Robinson <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2000 at 06:58:18PM +1000, Hamish Moffatt wrote:
>>
>> The analogy is flawed. Solutions have been offered several
>> times owner for DUL-listed or potentially DUL-listed users.
>> All of which should not be too difficult to set up for
>> a Debian developer.

> You demonstrate limited facility to construe the analogy.

> The "solutions" that have been offered effectively result in concealing the
> fact that the ultimate origin of the mail is a dynamic IP, therefore this

And that is the whole point of the DUL.  When a dynamic IP site is relaying
through someone else, the relaying host will be responsible if and when the
dynamic IP site misbehaves.

If they're sending directly, then no one needs to claim responsbility as the
receiver cannot block the sending address easily due to its dynamic nature.
OTOH, if a relay doesn't do something about a spammer, it can easily be
blocked, thus giving a relay's admin a very strong incentive to act.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Pgcc in Deb

[Mark Brown]

On Mon, Apr 03, 2000 at 04:17:51AM -0700, Joseph Carter wrote:

> We all know how screwed up the former is.  The latter has (and has had for
> some time) several very obnoxious bugs which result in bad code on certain

Definately - pgcc should be approached with some caution.  It's also
been known to play up with XFree86 and Mesa.

> non-trivial applications.  Those patches and improvements found in pgcc
> get added to egcs as soon as they are known not to do stupid things anyway

That's not entirely true - some of the stuff in pgcc isn't in mainline
gcc because there is no copyright assignment on file and no likelyhood
of getting one.  Other bits are probably stable enough on Intel but need 
work to avoid pessimising or bugs on other architectures.

> so it's worthwhile simply to stick with egcs and use the optimizations it
> provides.

> In almost all cases you will not be seeing any noticable difference in
> execution speed.

Depends on the program, of course.  For all the effort it takes, it's
often worth trying a pgcc build of compute-intensive programs, although
you should be able to check that it is correctly optimized - not to
mention do some benchmarking to verify that you're actually getting
something worthwhile from the exercise.

Most programs aren't that compute-intensive, and gcc is more reliable -
just blindly using pgcc is probably not a good idea.

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/

Re: Release-critical Bugreport for March 31, 2000

[Siggy Brentrup]

BugScan reporter <[EMAIL PROTECTED]> writes:


[...]

> Package: at (debian/main)
> Maintainer: Siggy Brentrup <[EMAIL PROTECTED]>
>   61295  at depends on libelfg0

This bug is fixed in at 3.1.8-10.

Since I still can't upload to master, would some kind soul please
do it for me. The files are at http://matti.winnegan.de/debian/upl/

Thanks
  Siggy

-- 
Siggy Brentrup - [EMAIL PROTECTED] - http://www.winnegan.de/
  [EMAIL PROTECTED] - http://www.north.de/~bsb/
** ceterum censeo javascriptum esse restrictam ***

Re: Obsolete packages

[Michael Meskes]

On Mon, Apr 03, 2000 at 10:08:13AM +0200, Petr Cech wrote:
> > manpages-net
> 
> this package appeared only for a short time (and yes, I have it installed
> too). I think it was in Incoming only.

How about re-creating it?

Michael
-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De   | Use PostgreSQL!

Re: DUL (was Re: RBL report..)

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 06:42:21AM -0400, Branden Robinson wrote:
> Furthermore, that any issue is unspecified in an RFC does not mean that the
> RFC's already address all issues that need to be addressed.

Yes, exactly. Therefore ommission of any comment about dialup users
making direct SMTP connections for mail delivery does not indicate
that the RFCs think it is a good idea. They simply do not comment.
You are taking this omission as support of your case where it is not.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: DUL (was Re: RBL report..)

[Hamish Moffatt]

On Mon, Apr 03, 2000 at 06:49:17AM -0400, Branden Robinson wrote:
> What mechanism do you propose that people on dynamic IP's use to identify
> their mails as non-spam while still making direct SMTP connections to the
> MX host of the destination domain?

None, it is not necessary.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: How to hide/show cursor without Ncurses ?

[Michael Alan Dorman]

[EMAIL PROTECTED] writes:
> The point is: an exact question needs an exact answer.

Except for Craig's understandable but unfortunate need to take shots
at old DOS programmers, he gave you the right answer---and to the
extent that "exactness" matters, it is also exact.

You asked, more or less, "How do I do terminal handling in Unix just
like I did in DOS".

Craig answered, more or less, "Unix is not DOS, and the way things are
done in Unix are not the same as how they are done in DOS."

If you don't like that answer, that's fine, but you shouldn't cast
aspersions on Craig for giving the correct answer to a question that
probably shouldn't have been asked here in the first place---this is
not a Unix Programming class.

Mike.

Re: Pgcc in Deb

[David Starner]

On Mon, Apr 03, 2000 at 11:35:08AM +0300, Eray Ozkural wrote:
> On Sun, 02 Apr 2000 20:28:41 David Starner wrote:
> 
> > Um, that's not what I've heard. Since optimizing for the Pentium
> > will sometimes pessimize the Pentium (Pro, II, III), and the
> > speedup from most programs is not that great, and anything that
> > needs it can be recompiled locally, it wasn't worth the archive
> > space or the manpower or extra trouble.
> 
> I disagree. From experience, I know that up to %50 speedup can be gained
> in number crunching stuff. I'd suspect %20 could be pretty normal for
> most CPU hungry apps, and the overall speedup would be significant.

Compared to gcc 2.95 with -march=i686 (or i586, as the case may be)? That
sounds a lot higher from what I've heard, even from those who would boost
it (the Intel engineers, for instance.)

Be that as it may, you didn't answer the rest of my claims, or the arguments
that's too unstable to be used. Nobody's going to complain if someone puts
together a pgcc deb, but a pgcc/i686 distribution is going to take up manpower
and archive space that the developers* don't want to support.

* Or "from the general trend on debian-devel, it can be 
summised that most of . . ."

-- 
David Starner - [EMAIL PROTECTED]
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

[PROPOSAL] update-binfmts - manages the binfmt_misc kernel module

[Kristoffer . Rose]

Dear Colin,

I have some comments on your `update-binfmts' proposal.

1. I like it :)

2. It should be a separate package because we don't want any way that the
   standard dpkg package depends on a kernel option that may be compiled
   out of a custom kernel.

   It could be named binfmt-support and modeled after the mime-support
   package that it resembles a lot.

3. In fact your proposal suggests a more general useful extension:
   integration of the kernel options in the package system!

   One could imagine a (virtual?) package for each module in the kernel
   that would be seen as installed or uninstalled depending on whether a
   certain option is compiled into the kernel.  This way packages could
   depend on kernel modules being installed in a way that would interact
   well with recompilation of kernels and even permit effective selection
   of just the needed modules for a given installation.

   But then again this may be overloading the package system since there
   are quite a few kernel modules...

Best regards,
Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <[EMAIL PROTECTED]>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <[EMAIL PROTECTED],tug}.org>

Re: [PROPOSAL] update-binfmts - manages the binfmt_misc kernel module

[Peter Makholm]

[EMAIL PROTECTED] writes:

>But then again this may be overloading the package system since there
>are quite a few kernel modules...

But it would be nice with some standard way to specify a "depend" on a
kernel-option and a "provide" of options for kernel patches. I don't
know any way to check for it but just a field saying "You need this"
would be good.

-- 
They say that the Lost Tomb is a bad place to die. 

Re: Bug#61674: Courier-IMAP is not usable with Netscape or Mozilla

[Steve Haslam]

On Mon, Apr 03, 2000 at 11:59:22AM +0200, root wrote:
> There are bugs in the IMAP implementation of Netscape and Mozilla. All
> the other IMAP servers have workaround to allow fetching from Netscape.
> 
> Courier-IMAP has now a workaround, if it is compiled with
> --enable-workarounds-for-imap-client-bugs when configuring it.
> 
> This option is only available in the new upstream version (0.30.x).
> 
> I think there should be an upgrade/update in potato to correct this
> important problem.

I have a courier-imap 0.30.31pre1-1 deb ready. But I am not sanguine
about putting in a new upstream release at this point in the freeze-
opinions please.

SRH
-- 
Steve Haslam, Production Engineer, Excite UK [EMAIL PROTECTED]
   i sit and stare at the gun pointed at my head
   and think about all the possibilities


pgpJOyKOnXzNs.pgp
Description: PGP signature

New shmfs and Debian

[Grendel]

Hi *,

  The new version of the Linux kernel will introduce a new file system
called shmfs. It has to be mounted for the applications to use the shared
memory features. The standard mountpoint for the shmfs is /var/shm. Maybe it
would be wise to add the directory to the base-files package as well as
create a suitable script to add the appropriate entry to /etc/fstab? I'm
sure than at some point, after potato is released, people will try to use
2.4.x and some of them can face problems when their applications won't be
able to use the shared memory.

regards,
marek


pgphukwxctYaL.pgp
Description: PGP signature

Re: eximconfig: Option 4, Local delivery only

[Paul Slootman]

On Fri 31 Mar 2000, Jose Marin wrote:
> 
> I was wondering if eximconfig is doing the right thing for this option. I
> have machines which are connected on a network, and I want to have a MTA
> but only for the benefit of apps like cron or debconf which need to send
> local mail.
> 
> I expected that Option 4 of eximconfig (Local delivery only) would block
> any TCP/IP conections to exim, but it doesn't; I'm still able to send
> e-mail from a different machine successfully.  Shouldn't eximconfig warn
> about this?  Or am I missing something?  (very likely)
> 
> Anyway, what's the best way to achieve what I want?  Run exim from inetd
> via tcp wrappers and protect it in hosts.deny?  Run exim as a daemon and
> give it an option to not listen to port 25, or not use SMTP transport at
> all?  All I want is local mail.

IMHO configure it to not use SMTP at all, that should be the default
(again, IMHO) if you choose option 4. I don't think that any daemons
etc. try to deliver to a local user via SMTP.


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]   http://www.isdn4linux.de/

Alternate LILO package?

[Jordi Mallach]

Some time ago, someone (I think it was Vincent) asked about the possibility
of including the new LILO with LBA support in frozen, but IIRC this idea was
discarded because there are some issues with this new version.

Today I was wondering if it would be possible to add a new "lilo-lba"
package with this new version, enclosed in many warnings about possible
problems with this lilo version or whatever. I know we're at -20ºC in the
freeze now, but. (Ok, I've been naughty).

Just a thought...

-- 
Jordi Mallach Pérez || [EMAIL PROTECTED]   || Rediscovering Freedom,
ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux

http://sindominio.net  GnuPG public information:  pub  1024D/917A225E 
telnet pusa.uv.es 23   73ED 4244 FD43 5886 20AC  2644 2584 94BA 917A 225E


pgpMjvkKXmFm7.pgp
Description: PGP signature