Re: Signing Packages.gz

[Jason Gunthorpe]

On Sun, 2 Apr 2000, Julian Gilbey wrote:

> On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote:
> > How many people
> > foward ssh agents and put that key in their home .ssh/authorized_keys?
> 
> What does that mean?  It could easily be that I am doing something
> wrong without even realising it

If you can ssh into your machine using RSA authentication and the key you
use for that is in your ssh agent and you forward your agent then you can
ssh from master back to your home machine without a password - and thus so
can root. 
 
Jason

Re: ATTN: pjw@edmc.net

[Hamish Moffatt]

On Fri, Mar 31, 2000 at 11:19:40PM -0500, Branden Robinson wrote:
> Blacklisters may have the right to speak and *say* what they think I should
> do, but they have no right to be heard.

Your post only rated a 1.5 on my trollometer. Please try harder.


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

Re: Release-critical Bugreport for March 31, 2000

[Ben Collins]

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.

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

Re: [Election Results] Official and Final

[Craig Sanders]

On Sat, Apr 01, 2000 at 10:14:47AM +0200, Josip Rodin wrote:
> On Fri, Mar 31, 2000 at 02:43:19PM -0800, Seth R Arnold wrote:
> > > > The ballots came from:
> > > 
> > > 216 people, if I counted right (wc(1) :). So much for the `300 active
> > > developers' vaporware, even if you include dissidents et al...
> > 
> > Wouldn't this be more properly FUD? 
> > 
> > :)
> 
> What?

it doesn't matter. the secret debian cabal forced everyone at gunpoint
to vote the right way, and then (through skilled use of drugs, hypnosis
and alien mind-control devices) made us all forget the torture session.

craig

ps: there is no cabal.

--
craig sanders

Re: Signing Packages.gz

[Anthony Towns]

On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote:
> On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote:
> > But unfortunately that's not quite the choice I have either, since for
> > some reason that I can't fathom, people seem to think that a dinstall
> > key would be an abomination to man and God and I'd probably be summarily
> > kicked out of the project as soon as I tried sending a patch somewhere.
> > Or at least it'd never get applied.
> It seems you feel personally insulted. 

Not insulted, just frustrated.

> I am sorry for this, but
> unfortunately it doesn't change the situation that the signed packages case
> adds a further point of weakness to the chain of trust.

And this is one of the reasons. It *leaves* a point of weakness in the
chain of trust, it doesn't add any.

> 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're not very /convenient/, though. I was figuring to make them convenient
enough to automate, you'd need to tack them on inside the .deb, like has
been proposed in the past. You're welcome to correct this assumption, if
you like.

> signed packages --> dinstall --> user
>  12
>
> Now link 2. It is currently absent. What you seem to suggest is to add a key
> (dinstall-key) here, so the user can verify the archive. This adds a point
> of weakness. As the dinstall key can't be used automatically and kept 
> "truly"[1]
> secret (it directly depends on the security of master), this weakness is 
> rather
> huge. This problem is avoided if the link 1 is propagated to the users:

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.

Yes, it's a problem, but one you seem to be vastly overrating.

>signed packages --> dinstall
>  \  1
>   \--> user
> 1

Really, what we have is:

 maintainers -3-.
 |  V
 1users
 |  ^
 `->debian--2---'

The first link is already checked completely. Debian knows that all the
packages it distributes are created by developers.

Link 2, which could be accurately implemented by signing Packages files
and nothing more (and is hence really easy to do, really easy to automate
and adds next to no overhead at all), allows a user to confidently say
"This distribution is Debian's." Hence, if Debian (ie, all our servers,
some of our important people, whatever) gets compromised, they're stuffed,
yes.

Do think about that though: Debian gets compromised. That's not some J.
Random Event that happens every day, every month, or every year. It's not
something you can just blithely work around, either. People installing
for the first time might be willing to trust www.debian.org to be controlled
by Debian, but they're not going to have any other way of verifying the
whole debian-keyring. If www.debian.org is compromised, there's no reason
for them not to accept some bizarrely wrong keyring as gospel.

Link 3, allows you to verify for yourself who built a particular package
that Debian distributes. Or at least, allows you to verify the key
they used. Verifying that they're an actual person, that they're really
someone you have a reason to trust, and that they themselves haven't been
compromised, is less trivial. (This is asserted by `Debian', but hey,
like you say, Debian could be compromised. Who'd wanna trust them?)

> In this situation, I don't have to trust anyone except the Debian developer.
> Not the admin team, not the security team, not master, not dinstall. Can't
> you see that this is a crucial advantage?

Can't you see that it's a crucial *flaw*? You have to trust *every*
person who's a developer. And guess what. That means you have to trust
the admin team and the security team. It means you have to assume that
every machine every developer stores a secret key on is maintained as or
more securely than master.

> If you also want a link 2 from dinstall to the user, I don't care. But don't
> tell the users that link 2 asserts that all packages come from Debian
> developers, it doesn't.

No, it asserts that all packages come from *Debian*. Debian itself states
that they'll only distribute packages that come from developers listed in
the keyring; and yes, it might turn out that Debian as an organisation has
been compromised, or hacked, or is just lying.

Cheers,
aj

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

 ``The thing is: t

Re: Signing Packages.gz

[Anthony Towns]

On Sat, Apr 01, 2000 at 03:38:29PM +0200, Marcus Brinkmann wrote:
> I could not trust either. The former, because it is stored on a network
> connected machine, the latter because it is transfered over the net (if it
> is shared among the security team). Of course, if the security team use
> their personal key in the latter case, I can trust it.

Are you really sure that no developer stores their key on a net connected
machine?

Also, what's so fundamentally wrong with transferring a secret key over
the net? Hint: PGP does it every time you send an encrypted email.

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


pgpI6fj63HQs1.pgp
Description: PGP signature

Re: Signing Packages.gz

[Anthony Towns]

On Sat, Apr 01, 2000 at 10:36:44PM -0600, Zed Pobre wrote:
> > Also, what's so fundamentally wrong with transferring a secret key over
> > the net? Hint: PGP does it every time you send an encrypted email.
> Either you are using the phrase "secret key" in a context with
> which I am unfamiliar, or you do not understand PGP.  PGP/GPG does not
> transfer your secret key component when encrypting a message to
> another.  It is possible to encrypt a message to someone else's public
> key without *having* a secret key of your own in the first place.

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*.

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


pgpS8YZqnjgrO.pgp
Description: PGP signature

WARNING: problems with postgresql-7.0-0.beta3.[12]

[Oliver Elphick]

I have had some serious bug reports about this release (see bugs 61515
and 61573).

If you are tracking woody (unstable) this may affect you.
Please do not let the postgresql packages be upgraded automatically; put them
on hold.  If you decide to upgrade, make absolutely sure you have a backup
of $PGDATA (defined in /etc/postgresql/postmaster.init) and also that you
have installable debs of 6.5.3-16, so that you can go back if necessary.

=

To ftp maintainers: please remove these packages from woody to experimental:

Binary:
ecpg_7.0-0.beta3-2_i386.deb
libpgperl_7.0-0.beta3-2_i386.deb
libpgsql2_7.0-0.beta3-2_i386.deb
libpgtcl_7.0-0.beta3-2_i386.deb
odbc-postgresql_7.0-0.beta3-2_i386.deb
pgaccess_7.0-0.beta3-2_i386.deb
postgresql-client_7.0-0.beta3-2_i386.deb
postgresql-contrib_7.0-0.beta3-2_i386.deb
postgresql-dev_7.0-0.beta3-2_i386.deb
postgresql-doc_7.0-0.beta3-2_all.deb
postgresql-pl_7.0-0.beta3-2_i386.deb
postgresql-test_7.0-0.beta3-2_i386.deb
postgresql_7.0-0.beta3-2_i386.deb
python-pygresql_7.0-0.beta3-2_i386.deb

Source:
postgresql_7.0-0.beta3-2.diff.gz
postgresql_7.0-0.beta3-2.dsc
postgresql_7.0.orig.tar.gz

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
   PGP key from public servers; key ID 32B8FAA1
 
 "If the Son therefore shall make you free, ye shall be 
  free indeed." John 8:36  

Re: ITP John the ripper

[Christian Kurz]

On 00-03-26 Matt Zimmerman wrote:
> On Sat, Mar 25, 2000 at 03:39:24PM +0100, Christian Kurz wrote:

> > as jsut discussed on debian-devel, I would like to package John the
> > Ripper. If someone already has done or is working on it, please mail me,
> > then I will stop packing it. Otherwise I will try to upload this package
> > till friday next week to woody.

> I briefly looked into packaging this a while ago, and I couldn't find a 
> license
> in the distribution.  Are you aware of a license for this program, or have you
> contacted the upstream author?

After talking with the upstream author, this program has now been
packaged for debian is available on master in incoming.

Ciao
 Shorty
-- 
Debian Developer and Quality Assurance Committee Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpjFlyBK8R4l.pgp
Description: PGP signature

Re: glibc-compat ???

[Konstantin Kivi]

On Sat, Mar 25, 2000 at 05:34:20PM +0100, Robert Varga wrote:
> 
> 
> On Thu, 23 Mar 2000, Steve Greenland wrote:
> 
> 
> However I don't really like 8i, since it needs much more (and it should be
> written as MUCH MORE) resources than 8.0.5. I know there is one aspect of
> using 8i on linux when compared with 8.0.5, its being free for development
> purposes.
> 
> Robert

I totaly agree with Robert. 8i is a memory hog
and need X to be installed. I have RH compat packeges
installed but I think having native packages is better.
Or lets start persuading Oracle to release
simpler Oracle version with glibc 2.1 ;-) 

-- 
Sincerely yours, Konstantin Kivi <[EMAIL PROTECTED]>

Re: Release-critical Bugreport for March 31, 2000

[Adrian Bunk]

On Sat, 1 Apr 2000, Ben Collins wrote:

> 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.

Perhaps the first should be reassignet to ftp.debian.org, too? Both bug
reports say that cricket is not installable because it depends on a
package that was removed from potato because of RC bugs.

cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: Signing Packages.gz

[Bart Schuller]

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.
So equating the sending of this kind of secret key and leaving your
private key on a server is comparing apples and oranges.

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sun, Apr 02, 2000 at 01:36:56PM +1000, Anthony Towns wrote:
> On Sat, Apr 01, 2000 at 03:38:29PM +0200, Marcus Brinkmann wrote:
> > I could not trust either. The former, because it is stored on a network
> > connected machine, the latter because it is transfered over the net (if it
> > is shared among the security team). Of course, if the security team use
> > their personal key in the latter case, I can trust it.
> 
> Are you really sure that no developer stores their key on a net connected
> machine?

No, but if I find out, I can investigate the installed packages or delete
his key from my personal copy of the debian-keyring (and could configure the
not-existing dpkg-verify software to use this smaller keyring), if I really
cared.

Do you see the difference? I can make an informed decision, while in the
signed packages file case, I can not verfiy the origin of any of the packages
I don't have the changes file for.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sat, Apr 01, 2000 at 02:49:40PM -0700, Jason Gunthorpe wrote:
> 
> On Sat, 1 Apr 2000, Marcus Brinkmann wrote:
> 
> > In the signed .debs case, I, as a developer, assert that the package comes
> > from me. A user can directly verify this by checking the signature.
> 
> No, the user cannot verify that. The user can check the signature against
> our keyring but they have no idea who *should* have signed it.

It seems to be hard to understand, so I will explain it one more time:

Why do you think this is not true in the signed packages case? Because you
only have one key to verify and trust, the dinstall key.

In my case, there is also a single one key to trust: The key used to sign
the debian-keyring package.

To complete the analogy: You could sign the debian-keyring package with your
dinstall secret key to reach the same effect. Only that we alread have a
debian-keyring package, and no mechanism to sign Packages files.

The signature on the Packages files corresponds the signature on the
debian-keyrng package in some way. Both secret keys should be kept private,
but it is easier with the latter, as it is a trusted maintainers package.
If this ever changes, we need to publish a different public key to verify
against, the same is true for the dinstall key.

> This means
> that all I need to do is nix one of our maintainers keys and I can
> undetectably forge Debian packages willy nilly. 
> 
> This is aside from the other problem of keeping 600 keys up to date on the
> client machines and making sure that huge keyring is not disturbed in
> transit. 

Oh yeah. I think if you are paranoid, you don't care about 500k additional
bandwidth. Can you be more specific about the "disturbed"? I don't know of
any valid attack that involves "disturbing the transit"?
 
BTW, just to turn it around for the sake of argument: The Packages file is
bigger than the debian-keyring.

> > whatever comes from dinstall, but he can not directly check if what is in
> > the archive comes really from the developers (not a problem if dinstall can
> > be trusted).
> 
> If we store the .changes files as I propose then the end use can check it,
> if they want.

Yes, and it should be stored, and verificable automatically.

> But nobody will, because it is not a usefull thing to check.

You say so. I disagree, and I think I gave sufficient arguments to show the
opposite. Unfortunately, the people involved in this discussion are not
interested in working out a good solution, but to win an argument. I don't
have time for child games, sorry.

The signed deb case not only has all the advantages of the signed packages
file (there is almost a one to one correspondency, modulo location of the
secret key (dinstall/debian-keyring)), it also allows verification of
individual packages from a different source, which does not come with a
packages file.

It seems that people around here are happily throwing away an integrated
solution in favour of a simple one. I doubt that the dinstall key will be
stored secretly, and I doubt that the responsible people will tell the
truth about this. This will lead to a false security by the user, and this
is what I am concerned about.

> It has use to definitively verify the root archive (say, after a hacking
> or something) but otherwise the end user cannot make much use of it at
> all.

The root of the packages are the developers, not master.

> > The latter adds a chain, thus one further point of weakness. I might add
> > that as the dinstall key can't be kept truly secret if it is stored on a
> > net-connected machine, this weakness is rather huge.
> 
> The dinstall and security keys (particularly the security key) are going
> to be far, far more secure than the weekest key in the key ring. 

It's a single point of failure, while maintainer keys only are applied to
some packages.
 
> > I could not trust either. The former, because it is stored on a network
> > connected machine, the latter because it is transfered over the net (if it
> 
> This is a flawed assertion - by your logic SSL is insecure and must not be
> used. In reality it is a perfectly good system that has really good
> security benifits.

I don't know SSL, so, no comment. It does however serve a different purpose
(encryption of streams, as opposed to verification of archives), so I doubt
whatever is true for SSL is applicable to this discussion.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote:
> 
> On Sat, 1 Apr 2000, Marcus Brinkmann wrote:
> 
> > Wrong. If you have signed debs, and you are careful when updating the
> > debian-keyring package, there is no risk even if master is compromised.
> 
> Hahha!
> 
> Sorry, your are deluded if you belive this :> Seriously, if someone can
> hack master we are all vunerable - how many people out there do you think
> use the same password on master as on their home boxes? How many people
> foward ssh agents and put that key in their home .ssh/authorized_keys? How
> many people have foolishly left their pgp key on master?
> 
> Hint: Lots to all of the above [except the last, we purged a bunch of
> people for that awhile ago].

Ok, I was only looking at master as the ftp archive. I am happy that the the
last is not true anymore. BTW, those people should be forced to use a new
key to sign Debian packages.

The SSL problems I don't know about.
 
> If master is compromized right now, we would take the d-changes archive
> from a more secure machine [which we may not even have, hence the interest
> in storing that in the archive], a slink cd, some potato CDs developers
> might have, etc, and begin painstakingly verfiying each and every .deb and
> .dsc to make sure it comes from where it was supposed to come from - there
> is no automated way to do this and only people like James would actually
> know who should be singing what packages. 

Yes, this is exactly my point. What would you do when you have signed
Packages file and master is compromised? The attacker could replace some
packages and create a new signed Packages file, just as dinstall does, and
you had no way to find out after the mirrors catched up.

In the signed deb case, you can easily verify all packages individually.
(thanks for proving my point).

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]

Re: Signing Packages.gz

[Marcus Brinkmann]

On Sat, Apr 01, 2000 at 03:18:17PM -0700, Jason Gunthorpe wrote:
> > Now link 2. It is currently absent. What you seem to suggest is to add a key
> > (dinstall-key) here, so the user can verify the archive. This adds a point
> > of weakness. As the dinstall key can't be used automatically and kept 
> > "truly"[1]
> 
> How about this, if someone was able to hack master to the point of being
> able to get the dinstall key, I assure you they would be able to hack
> some]weak developer machine and lift their key too.

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.

> I also assert that the
> chance of a hacker getting the security key is lower than say 50% of the
> keys in our keyring. 

I would not make such claims. In any way, see above.
 
Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]

Re: Signing Packages.gz

[Marcus Brinkmann]

Hi,

On Sun, Apr 02, 2000 at 01:33:53PM +1000, Anthony Towns 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.
 
> They're not very /convenient/, though. I was figuring to make them convenient
> enough to automate, you'd need to tack them on inside the .deb, like has
> been proposed in the past. You're welcome to correct this assumption, if
> you like.

What you said is correct.
 
> > signed packages --> dinstall --> user
> >  12
> >
> > Now link 2. It is currently absent. What you seem to suggest is to add a key
> > (dinstall-key) here, so the user can verify the archive. This adds a point
> > of weakness. As the dinstall key can't be used automatically and kept 
> > "truly"[1]
> > secret (it directly depends on the security of master), this weakness is 
> > rather
> > huge. This problem is avoided if the link 1 is propagated to the users:
> 
> 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. PGP has been tested by thousands of
people (experienced security experts), while every linux box has its own
weak points. But already the complexity of a running system (which runs that
many services as master does), is almost guaranteed to have an exploit.
 
> Yes, it's a problem, but one you seem to be vastly overrating.

Are we talking about security, or are we talking about belief?

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".

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.

> >signed packages --> dinstall
> >  \  1
> >   \--> user
> > 1
> 
> Really, what we have is:
> 
>  maintainers -3-.
>  |  V
>  1users
>  |  ^
>  `->debian--2---'
> 
> The first link is already checked completely. Debian knows that all the
> packages it distributes are created by developers.

Yes, almost. It knows that all packages it accepts are created by
developers. If the current packages in the archive are the one we uploaded,
I can't know without messing around with the devel-changes archive :)
 
> Link 2, which could be accurately implemented by signing Packages files
> and nothing more (and is hence really easy to do, really easy to automate
> and adds next to no overhead at all), allows a user to confidently say
> "This distribution is Debian's." Hence, if Debian (ie, all our servers,
> some of our important people, whatever) gets compromised, they're stuffed,
> yes.

Yes. Does this not worry you?
 
> Do think about that though: Debian gets compromised. That's not some J.
> Random Event that happens every day, every month, or every year. It's not
> something you can just blithely work around, either. People installing
> for the first time might be willing to trust www.debian.org to be controlled
> by Debian, but they're not going to have any other way of verifying the
> whole debian-keyring. If www.debian.org is compromised, there's no reason
> for them not to accept some bizarrely wrong keyring as gospel.

The debian-keyring signature is verified exactly in the same way as the
dinstall key on the Packages file. Only that the debian-keyring keys secret
key is stored securely on James machine (I hope), while the dinstall key is
on a net connected machien and revealed to the attacker "for free".
 
> Link 3, allows you to verify for yourself who built a particular package
> that Debian distributes. Or at least, allows you to verify the key
> they used. Verifying that they're an actual person, that they're really
> someone you have a reason to trust, and that they themselves haven't been
> compromised, is less trivial. (This is asserted by `Debian', but hey,
> like you say, Debian could be compromised. Who'd wanna trust them?)

Debian is compromised, but you had to compromise James to get a fake key in.
You are correct about the trust analysis.
 
> > In this situation, I don't have to trust anyone except the Debian develope

Re: Signing Packages.gz

[Julian Gilbey]

On Sat, Apr 01, 2000 at 04:56:59PM -0700, Jason Gunthorpe wrote:
> 
> On Sun, 2 Apr 2000, Julian Gilbey wrote:
> 
> > On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote:
> > > How many people
> > > foward ssh agents and put that key in their home .ssh/authorized_keys?
> > 
> > What does that mean?  It could easily be that I am doing something
> > wrong without even realising it
> 
> If you can ssh into your machine using RSA authentication and the key you
> use for that is in your ssh agent and you forward your agent then you can
> ssh from master back to your home machine without a password - and thus so
> can root. 

I think I understand now, thanks.  In my case I had done this:

On my home machine, I have an identity in .ssh/identity.pub.
I copied that into .ssh/authorized_keys on master (possibly using the
LDAP system).
I *also* copied it into .ssh/authorized_keys on my home machine.

That extra copy on my home machine (somehow) allows root to snoop my
identity and so get into my home machine without a password.

Solution: remove the identity from .ssh/authorized_keys on my home
machine.  If I were really paranoid, I ought to reinstall everything
on my home machine in case I'd already been hacked.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

END Key in Emacs (only in Xterm)

[Rodrigo Castro]

Hello,

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.

- All programs have right key configuration

- Emacs in console or X works fine

- I renamed .emacs in order to not be read and it didn't work

- If I change my XTERM variable from "xterm" to "linux" when I
am in Xterm, Emacs works with END key

- Oh, my END key beeps when I press it in Emacs (in Xterm)

Any idea? This started happening from sometime, when I
upgraded my potato to the lastest version at that time. I do have now
the lastest version of potato.

Thank you in advance,
-- 
Rodrigo Castro   <[EMAIL PROTECTED]>
Computer Science undergraduate student - University of Sao Paulo

I do not fear computers.  I fear the lack of them.
-- Isaac Asimov

Re: END Key in Emacs (only in Xterm)

[Marshal Kar-Cheung Wong]

> "Rodrigo" == Rodrigo Castro <[EMAIL PROTECTED]> writes:

> Hello, 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.

>   - All programs have right key configuration

>   - Emacs in console or X works fine

>   - I renamed .emacs in order to not be read and it didn't work

>   - If I change my XTERM variable from "xterm" to "linux" when I
> am in Xterm, Emacs works with END key

Since this changes things, perhaps there's something different with
the termcap/terminfo definitions of xterm?  I'm guessing here...

Marshal

>   - Oh, my END key beeps when I press it in Emacs (in Xterm)

>   Any idea? This started happening from sometime, when I
> upgraded my potato to the lastest version at that time. I do
> have now the lastest version of potato.

> Thank you in advance, -- Rodrigo Castro
> <[EMAIL PROTECTED]> Computer Science undergraduate
> student - University of Sao Paulo

> I do not fear computers.  I fear the lack of them.  -- Isaac
> Asimov



> -- Unsubscribe?  mail -s unsubscribe
> [EMAIL PROTECTED] < /dev/null

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

[Colin Watson]

Hi all,

I've been working on javawrapper, a utility which uses the binfmt_misc
kernel module to let you execute Java classes like any other program -
'./MyProgram.class' instead of 'java MyProgram.class'. For those of you
unfamiliar with binfmt_misc, the documentation is in
Documentation/binfmt_misc.txt in the kernel sources (since 2.1.43). It
occurred to me while I was writing the init.d script (with the advice of
my sponsor (cc'ed), IANYAD) that most of what I was doing was reusable.

I'm not aware at the moment of any packages that use binfmt_misc; please
somebody let me know if I'm wrong. The author of binfmt_misc says it
would be useful for Python and elisp, and I've found it convenient to
use it for WINE too.

Now, at the moment, actually using this is rather complicated for both
package maintainers and sysadmins. Maintainers have to cope with the
fact that there's a bug in 2.2/2.3 binfmt_misc (patch sent, and with
luck might make it in before 2.4) which allows you to register two
binary formats with the same name and thus create two files with the
same name in /proc. This needs to be handled consistently across
packages. Sysadmins have to cope with the not-obviously-memorable syntax
of what you have to echo to /proc/sys/fs/binfmt_misc/register to make
the whole thing work.

I've been working on a tool called update-binfmts which, along the same
lines as update-alternatives, dpkg-divert, et al, keeps a database of
binfmt_misc interpreters in /var/lib/dpkg/binfmts, and lets root
register and unregister them at will.

To take WINE as an example of how this might be used, the idea is that,
instead of me using systune to effectively do:

  echo ':wine:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register

... at startup (without any error-detecting code around this, as I
haven't done the same thing with wine as with javawrapper yet), the wine
package ought to be able to do something in its postinst like:

  update-binfmts --package wine --add wine /usr/bin/wine --magic MZ

... and something in its prerm like:

  update-binfmts --package wine --remove wine /usr/bin/wine

Then /etc/init.d/binfmt-misc (or similar) does this:

  start)
[...]
update-binfmts --register
[...]
;;
  stop)
[...]
update-binfmts --unregister
[...]
;;

... to (un)register all installed binary formats with the kernel, and a
sysadmin can do something like 'update-binfmts --register wine' or
'update-binfmts --unregister wine' to turn support for an individual
format on or off.

Obviously this interface is fluid at the moment, but I think it has the
benefit that it's quite close to the syntax used by tools like
dpkg-divert so maintainers should be able to remember it, and it's
almost trivial for an admin. I have a working implementation of
something close to this running on my system, though it needs a few
recent interface changes applied to it and to have its robustness
improved more.

Various issues I thought I ought to take to debian-devel before
proposing this to the dpkg people:

1) Is this a solution in search of a problem? It's certainly a minority
   interest. I think that it's a useful feature which is woefully
   underused, but some may disagree.

2) Is the interface right? Once it's being used it will be difficult to
   change, and particularly as a non-developer I don't want to sound
   like I'm imposing my own ideas on everyone. There are several option
   switches other than those I've listed above (--offset, --mask, and
   --extension) and another action switch (--display).

3) Where should this go? The obvious place is dpkg, but am I being too
   arrogant there? It feels too small for its own package, though.

Thanks, and please let me know if you think I'm in over my head,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: dwww: cat and file (pipe race condition)

[Andrew Pimlott]

On Thu, Mar 30, 2000 at 10:03:14AM -0500, Daniel Martin wrote:
> Well, if I do a 
> $process | file -b - | magic2mime
> 
> where "$process" is anything that produces a large amount of output
> slowly, then the process is killed by a SIGPIPE in short order.
> 
> If, however, I do:
> $process | (file -b -; cat >/dev/null) | magic2mime
> then it seems that the process runs happily (that is, no signals) to
> completion.
> 
> However, this may not be what you really would want.  (Since waiting
> for process to finish could cause the webserver to time out)  What
> your problem may be is that somehow the cat process is not receiving
> the SIGPIPE signal; I would then try to see about rewriting the dwww
> script so that it does.  (I'm not sure how to do this, since the bash
> manpage seems to imply that one can't change which signals are ignored 
> by the shell).

I just read this one message so I don't know what the original
problem is.  However, I think you are misdiagnosing or misexplaining
this.  The SIGPIPE goes to and only to $process.  The reason is that
file closes its stdin as soon as it has ready a few bytes, with the
result that $process then has nowhere to write.  cat cannot get a
SIGPIPE because it is writing to /dev/null, which rarely stops
accepting bits.

As far as the web server timing out, without knowing the full
context I believe that whatever script is calling this pipeline can
just kill it after reading what it needs from magic2mime.  Course,
this might be a problem if any of the programs in the pipeline
handle their buffers in unfortunate ways, causing the output from
magic2mime to wait for the completion of $process

My apologies if you understood this and I just misread your message.

Andrew

Re: ATTN: pjw@edmc.net

[Robert Bihlmeyer]

Marcus Brinkmann <[EMAIL PROTECTED]> writes:

> Yes, but you have not "the right" (what loaded words!) to close the bug
> reports. Feel free to ignore them, but don't close them without a better
> reason.

If communication with the reporter is necessary to fix the bug, and
this communication is broken (mail address is wrong, misconfiguration
at the reporter's site, whatever), closing the bug report may be
justified.

Other users seeing the same error may re-file a report.

I don't think mail delayed by Sauce's anti-spam tactics qualifies as
"broken communication", though.

-- 
Robbe

Re: Signing Packages.gz

[Torsten Landschoff]

On Sat, Apr 01, 2000 at 10:48:54PM +0200, Marcus Brinkmann wrote:
 
> No. Currently there is NO chain of verification (I should not have said
> "trust", it's the wrong term. Sorry).

So you agree that it would be an improvement?

> However, it doesn't establish a complete chain of verification from the
> developers to the users, au contraire to what you seem to believe.

Please don't tell me what I believe. I know that the solution is not perfect.
But it's way better then what we have now. 

> > > We already use link 1 (signed changes files), and trust it. This won't
> > > be changed by either proposal. Yes, even in the signed packages file you
> > > trust all developers keys.
> > 
> > There is a difference between our master server trusting the uploaded
> > changes files. master will by definition always have the current keyring.
> > The user might not.
> 
> Yes, but this doesn't change the point. The problem of out of date keys is a
> known problem in any public key cryptosystem.

That it is a known problem does not change anything. It still IS a problem.
While a developer might leave the project or even get thrown out the single
dinstall key would by definition last until either Debian dies (hopefully
this will not happen during my lifetime) or the key is compromised. In the
latter case you can expect that all Linux news services will pick up it 
very soon.

> > Okay - signing Packages will make Debian as secure as master is. Fine.
> > We must assume that master is secure otherwise we are doomed anyway. 
> 
> Wrong. If you have signed debs, and you are careful when updating the
> debian-keyring package, there is no risk even if master is compromised.

I made two points. Which is wrong? I don't think my first point is wrong.
Signing packages will make Debian as secure as master is.

The second point might or might not be wrong. Currently what happens if
master is cracked? Right, we have a BIG problem. With the signed Packages
file we still have a problem in that and only that case.

But under the current setup we also have problem if our mirrors are cracked.
It might even be possible to crack a few push primary mirrors and everybody
will get a compromised Debian. We have to avoid this.

> This is the Debian way, right? Fetching the stick at the wrong end first.
> (Yes, this is a troll).

No. The Debian problem is searching the optimal solution for too long and
doing nothing in the meantime. We still have no perfect solution to improve
our release cycles. So we did nothing. potato is not perfect so we don't 
release it.

I wonder why you are working for the Hurd project then? You can't even
run X11 Servers on the Hurd so why bother about it? The Linux kernel did 
not much when it was first released - but it did something. And you can
improve it.

What I have to admit is that I tend to make the same mistake. Remember, I
wanted to fix GTK+ for the Hurd to not rely on MAXPATHLEN. There is an 
easy work around to make it work but I wanted to essentially rewrite the
file selector. 

I still did not have the time to finish that while having a working (okay, 
working most of the time, it might fail with paths >4k) solution now would
be better I think.

Please stop retarding the efforts of other people because you think it is
not perfect. Get on with your work and let Anthony and Jason implement 
the signed Packages.gz.

Thanks

Torsten

PS: Did I say I will leave the project if we don't implement the signed
Packages.gz? ;-))

-- 
Torsten Landschoff   [EMAIL PROTECTED]   <[EMAIL PROTECTED]>
   Debian Developer and Quality Assurance Committee Member


pgpntESrWbvmA.pgp
Description: PGP signature

Re: Signing Packages.gz

[Robert Bihlmeyer]

Anthony Towns  writes:

> There is an existing single-point vulnerability in *every*
> mirror. Compromise the mirror and you can compromise every single Debian
> user who upgrades from that mirror. You don't even have to try touching
> anything at *.debian.org.

Yes, and I'd very much see this vulnerability fixed. I just advocate
that we could go the whole way, and make ourselves independent from
the security of master, too. I think that is possible, but perhaps you
can prove me wrong.

> For example, if you compromise master, you can pretend to just be
> the new-maintainer team and surreptitiously add yourself as a
> maintainer. Or you can pretend to be on the ftp team, and
> surreptitiously add or change existing package, and replace someone
> else's key with your own, say.

I still won't get paranoid characters to trust my key.

> Let me rephrase that. This makes debian-keyring a base package, since
> if you want to verify the packages you download, you really want to do
> it right from the word "go", rather than just some time later.

That's to decide. This kind of security is optional. But yes, I'd
recommend people to get the security-enabled base distribution.

One problem here is that (depending on the
US-export-regulations-du-jour) this base would qualify for non-US. Not
very good. Of course some more complicated scheme could be built,
which had base download and verify (by MD5) a corresponding
base-secure addendum. More work.

> 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.

> 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.

> The *reason* Debian handles security bugs (security leaks?) in packages
> well is that we have a mechanism for handling bugs, and we make use of
> it. The best way to ensure that we always have mechanisms for fixing
> things is to think about it first, not just handwave it away and say
> "She'll be right, mate".

I don't see how this doesn't apply to the "bad maintainer" scenario.
If someone discovers a security bug in a package that has probably
been put in deliberately, she should:

1) file a critical report against the package
2) Cc or otherwise inform this list, and state her suspicions

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.

> The highly trusted person you're referring to here is eash member of the
> new-maintainer team, by the way.

This is a possibility, not a requirement.

> 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.

> 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.)

> > Corrupting the debian-keyring package is useless, 
[...]
> And if they corrupt this master key as well?

Then we have a problem. Perhaps it's no use to put in another level of
signing. Let's for now forget about the super-key, and make the
debian-keyring package the thing to use.

> 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.

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). 

> 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
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 

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

[David Starner]

On Sun, Apr 02, 2000 at 04:36:00PM +0100, Colin Watson wrote:
> 3) Where should this go? The obvious place is dpkg, but am I being too
>arrogant there? It feels too small for its own package, though.

I like the idea, but I think it should go in its own package, like 
menu. For one thing, a lot of admins may not like the arbitrary 
enabling of executable formats in the kernel. This is true especially
in its experimental phase (sort of like debconf is now.)

-- 
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

Re: Pgcc in Deb

[Jim Lynch]

Hi,

I think the answer is this: it is felt by debian developers that pgcc 
deserves more: it should be included in its own architecture, You may
know that we have the architecture called 'i386', well, pgcc would come
in the architecture called 'i586' with the idea that all packages in
debian would be compiled with pgcc for i586 architecture.

I have heard discussion to this effect, so I suspect that some work 
or at least exploration of this possibility has been done. I don't
know its status. 

(All: does anyone know curr stat of any such?)

-Jim

---
Jim Lynch   Finger for pgp key
as Laney College CIS admin:  [EMAIL PROTECTED]   http://www.laney.edu/~jim/
as Debian developer: [EMAIL PROTECTED]  http://www.debian.org/~jwl/

Re: END Key in Emacs (only in Xterm)

[Rodrigo Castro]

On Sun, Apr 02, 2000 at 11:14:16AM -0400, Marshal Kar-Cheung Wong wrote:
> > "Rodrigo" == Rodrigo Castro <[EMAIL PROTECTED]> writes:
> 
> > Hello, 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.
> 
> > - All programs have right key configuration
> 
> > - Emacs in console or X works fine
> 
> > - I renamed .emacs in order to not be read and it didn't work
> 
> > - If I change my XTERM variable from "xterm" to "linux" when I
> > am in Xterm, Emacs works with END key
> 
> Since this changes things, perhaps there's something different with
> the termcap/terminfo definitions of xterm?  I'm guessing here...
> 

Any idea of what I can do in order to solve it? I reinstalled 
ncurses-bin 5.0-6 and ncurses-term 5.0-6 but it didn't solve.

Oh, I have the lastest version (in potato) of XFree installed.

[]'s
-- 
Rodrigo Castro   <[EMAIL PROTECTED]>
Computer Science undergraduate student - University of Sao Paulo

I do not fear computers.  I fear the lack of them.
-- Isaac Asimov

Re: Pgcc in Deb

[David Starner]

On Sun, Apr 02, 2000 at 10:11:44AM -0700, Jim Lynch wrote:
> I think the answer is this: it is felt by debian developers that pgcc 
> deserves more: it should be included in its own architecture, You may
> know that we have the architecture called 'i386', well, pgcc would come
> in the architecture called 'i586' with the idea that all packages in
> debian would be compiled with pgcc for i586 architecture.
> 
> I have heard discussion to this effect, so I suspect that some work 
> or at least exploration of this possibility has been done. I don't
> know its status. 
> 
> (All: does anyone know curr stat of any such?)

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.

-- 
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

Re: Signing Packages.gz

[Robert Bihlmeyer]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> On my home machine, I have an identity in .ssh/identity.pub.
> I copied that into .ssh/authorized_keys on master (possibly using the
> LDAP system).
> I *also* copied it into .ssh/authorized_keys on my home machine.
> 
> That extra copy on my home machine (somehow) allows root to snoop my
> identity and so get into my home machine without a password.

This is only possible if you used ssh-agent at some point, and had
"agent forwarding" turned on at this time (this may be turned on by
default). If you never use the agent, you're not at risk.

> Solution: remove the identity from .ssh/authorized_keys on my home
> machine.

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.

-- 
Robbe

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

[Colin Watson]

[EMAIL PROTECTED] wrote:
>On Sun, Apr 02, 2000 at 04:36:00PM +0100, Colin Watson wrote:
>> 3) Where should this go? The obvious place is dpkg, but am I being too
>>arrogant there? It feels too small for its own package, though.
>
>I like the idea, but I think it should go in its own package, like 
>menu. For one thing, a lot of admins may not like the arbitrary 
>enabling of executable formats in the kernel. This is true especially
>in its experimental phase (sort of like debconf is now.)

OK, I see your point. I'd better use /var/lib/binfmts instead of
/var/lib/dpkg/binfmts, then, I suppose.

Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: Pgcc in Deb

[Jim Lynch]

Hi,

So the original question remains: is there a simple pgcc available somewhere?

-Jim

---
Jim Lynch   Finger for pgp key
as Laney College CIS admin:  [EMAIL PROTECTED]   http://www.laney.edu/~jim/
as Debian developer: [EMAIL PROTECTED]  http://www.debian.org/~jwl/

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

[Steve Greenland]

On 30-Mar-00, 13:01 (CST), Steve Greenland <[EMAIL PROTECTED]> wrote: 
> On 30-Mar-00, 05:43 (CST), Richard Braakman <[EMAIL PROTECTED]> wrote: 
> > Package: debianutils (debian/main).
> > Maintainer: Guy Maor <[EMAIL PROTECTED]>
> >   59121 run-parts hangs during /etc/cron.daily runs
> 
> There's a reasonable looking explanation and patch associated with this
> bug. Guy, would you like me to do an NMU?

Since I've not heard from Guy, I've prepared an NMU that applies Ingo
Saitz's patch (thanks Ingo!) and placed it at 

http://www.debian.org/~stevegr/debutils/debianutils_1.13.3_i386.deb
http://www.debian.org/~stevegr/debutils/debianutils_1.13.3_i386.changes
http://www.debian.org/~stevegr/debutils/debianutils_1.13.3.tar.gz
http://www.debian.org/~stevegr/debutils/debianutils_1.13.3.dsc

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.

Regards,
Steve




-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Signing Packages.gz

[Jason Gunthorpe]

On 2 Apr 2000, Robert Bihlmeyer wrote:

> > Solution: remove the identity from .ssh/authorized_keys on my home
> > machine.
 
> 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.

No, that is the point of ssh-agent. The key never leaves your machine the
authentication request travels through SSH to your agent, and then back
again with the proper encrypted credentials. So long as your ssh is active
an attacker can use that to access other machines you normally ssh into
and presumably implant his own authorized_key.

Jason

Re: Signing Packages.gz

[Torsten Landschoff]

Hi Marcus, 

On Sun, Apr 02, 2000 at 02:32:04PM +0200, Marcus Brinkmann wrote:

> > No, the user cannot verify that. The user can check the signature against
> > our keyring but they have no idea who *should* have signed it.
> 
> It seems to be hard to understand, so I will explain it one more time:
> 
> Why do you think this is not true in the signed packages case? Because you
> only have one key to verify and trust, the dinstall key.

No, because the signatures on that packages are seen by Debian developers
following -devel-changes as well as by the ftp admins.

> In my case, there is also a single one key to trust: The key used to sign
> the debian-keyring package.

No, you also have to trust the maintainer who signed the package. There is 
no way for an end user to know how is maintaining a package without 
following -devel or somesuch or know if an NMU is okay.

> To complete the analogy: You could sign the debian-keyring package with your
> dinstall secret key to reach the same effect. Only that we alread have a
> debian-keyring package, and no mechanism to sign Packages files.

We don't? Ever tried gpg -a --clearsign Packages.gz?

> The signature on the Packages files corresponds the signature on the
> debian-keyrng package in some way. Both secret keys should be kept private,
> but it is easier with the latter, as it is a trusted maintainers package.

Why does that make keeping the key private easier?

> If this ever changes, we need to publish a different public key to verify
> against, the same is true for the dinstall key.

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.

> > This is aside from the other problem of keeping 600 keys up to date on the
> > client machines and making sure that huge keyring is not disturbed in
> > transit. 
> 
> Oh yeah. I think if you are paranoid, you don't care about 500k additional
> bandwidth. Can you be more specific about the "disturbed"? I don't know of
> any valid attack that involves "disturbing the transit"?

Break into a mirror and modify the debian-keyring package. For new installs
this will be enough to break into a system. 

> BTW, just to turn it around for the sake of argument: The Packages file is
> bigger than the debian-keyring.

But you always need the Packages file anyway (if you are using apt that is).

> > If we store the .changes files as I propose then the end use can check it,
> > if they want.
> 
> Yes, and it should be stored, and verificable automatically.

Please tell me then how to verify the debian-keyring package?

> > But nobody will, because it is not a usefull thing to check.
> 
> You say so. I disagree, and I think I gave sufficient arguments to show the
> opposite. Unfortunately, the people involved in this discussion are not
> interested in working out a good solution, but to win an argument. I don't
> have time for child games, sorry.

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.

I have to say I am glad that not all developers think this way. Otherwise we
would still be discussing on debian-admintool how to implement a configuration
manager. Did you notice that debconf was not perfect at first? It is still 
not perfect (my opinion) but it is working. And it is better than nothing.

Regarding the argument: I do not care if we win this argument. If I'd be 
the project leader I would say let's just ignore you and implement what
we are discussing. It would take much less time to do so instead of talking
to a brick.

Question is: Who can decide if we implement this? Jason? Richard? Manoj?
Wichert? Why are we discussing this all the time anyway? 

> The signed deb case not only has all the advantages of the signed packages
> file (there is almost a one to one correspondency, modulo location of the
> secret key (dinstall/debian-keyring)), it also allows verification of
> individual packages from a different source, which does not come with a
> packages file.

Cool. We want this key to prove that the package actually originates from
Debian and you are telling us it is better if it can come from somewhere 
else?

> It seems that people around here are happily throwing away an integrated
> solution in favour of a simple one. I doubt that the dinstall key will be
> stored secretly, and I doubt that the responsible people will tell the
> truth about this. This will lead to a false security by the user, and this
> is what I am concerned about.

We are not telling our users currently how insecure Debian is. RedHat did 
have the single key from the start. You can verify RPMs. Tell them it's
more insecure that what Debian has. 

Currently we have no security at all. Breaking into ftp.random.debian.

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

[Dale Scheetz]

On Sat, 1 Apr 2000, Craig Sanders wrote:

> On Fri, Mar 31, 2000 at 11:08:53PM -0500, Branden Robinson wrote:
> > On Fri, Mar 31, 2000 at 11:18:47PM +1000, Craig Sanders wrote:
> > > your right to free speech does not include the right to force anyone
> > > else to listen.  
> > 
> > Then this principle must apply universally.  I reserve the right to ignore
> > bug reports for any reason I choose, then.
> 
> of course you have that right.  any volunteer always has the right to
> abandon the responsibilities that they have freely chosen to accept.
> 

I believe the discussion is about speech, not volunteer responsibilities.

Speech implies a listener, otherwise we would never have discussions about
trees falling in the forest unobserved.

Speech without a listener is failed communication. That is exactly what we
are seeing here. 

No single party to the "conversation" can fix the problem. Both parties
must participate in the communication of ideas or there can be no
exchange. Both parties getting to "have their say", and everything
continuing as before, is not communication.

Freedom is a wonderful concept, until it is used to bludgeon someone else
into doing things your way, against their own better judgement.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Re: Signing Packages.gz

[Jason Gunthorpe]

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

If #1 is possible than #3 and #4 sure as heck will be too! Furthermore,
this is lethal, it can effect both stable, unstable, distributed CDs -
everything! What is worse, once you know it has happened - how do you
determine which PGP key has been stolen? You have to *manualy* go
through every single package and check the signer by hand to make sure it
is all correct. Only someone very well versed in the ftp archive can do
this.

In fact, any time a developer is forced to revoke his key for any reason
it calls the security of 'fixed' things we have distributed (stable
basically) into question, you can't quite tell if that CD out there is
legit or modified. This is a very serious weakness. Think about that, it
is important.

With a dinstall key it goes like this
  1) Break root on master
  2) Hack archive use dinstall key.

However, an attacker doing this can only ruin unstable, our stable
distribution and all CDs *remain secure* The archive itself is recoverable
because the process above can be done. 

This is also very easially recoverable, we revoke the dinstall key, create
a new one, signed by the security key and automated tools can fix the
situation without hassle. The dinstall key has no permanance (on CDs on
the like) so this isn't a big deal.

With the secure dinstall key things are the best they can be:
  1) Break root on wichert's machine
  2) Steal security key
  3) Break root on master or forge CD's

Now we assume wichert is very carefull with the security key [more
carefull than the average developer] so #2 is very very hard - thus this
is the most secure alternative to the 2 above. But is impossible for use
on a daily basis.

Jason

Re: END Key in Emacs (only in Xterm)

[Branden Robinson]

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.



-- 
G. Branden Robinson| The greatest productive force is human
Debian GNU/Linux   | selfishness.
[EMAIL PROTECTED] | -- Robert Heinlein
roger.ecn.purdue.edu/~branden/ |


pgpuyxo1VKzM5.pgp
Description: PGP signature

ITP: lirc, devfsd

[Tom Lees]

I have packaged LIRC and will upload it later today or tomorrow if
noone objects.

LIRC is Linux Infra-red Remote Control support, see
http://fsinfo.cs.uni-sb.de/~columbus/lirc/index.html

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

-- 
Tom <[EMAIL PROTECTED]>

Captain's Log, star date 21:34.5...

Re: Signing Packages.gz

[Chris Frey]

Chris Frey wrote:
> I'm curious how this issue is going to be handled now that it has been
> discussed.  (The archives don't seem to be seeing any new messages on this
> topic.)  What has to occur before this cryptographic signing of
> Packages actually happens?

Oops, the recent mail archive update just showed a bunch of new messages.
I was perhaps a bit hasty in declaring this "discussed". :-)

I'm eagerly watching this discussion to see how it turns out.  Thanks to all
who have taken my request so seriously!  I really appreciate it.

- Chris

Re: END Key in Emacs (only in Xterm)

[Rodrigo Castro]

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):

[rcastro:~]$ xrdb -query

*VT100.Translations:#override ~Shift ~Ctrl ~Meta BackSpace:
string("\177")\n   ~Shift ~Ctrl ~Meta
Delete: string("\033[3~")\n   ~Shift
~Ctrl ~Meta Home: string("\033[1~")\n
~Shift ~Ctrl ~Meta End: string("\033[4~")
*customization: -color
XDvi*mfMode:ljfour
XDvi*paper: a4
XDvi*pixelsPerInch: 600
XDvi*shrinkFactor:  8
XDvi*thorough:  true
XDvi*wwwBrowser:netscape

[rcastro:~]$ infocmp | grep end
kend=\E[4~, kent=\EOM, kf10=\E[21~, kf11=\E[23~, 

[]'s
-- 
Rodrigo Castro   <[EMAIL PROTECTED]>
Computer Science undergraduate student - University of Sao Paulo

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

[Raphael Manfredi]

Quoting Steve Greenland:
: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.

Unfortunately, I'm leaving tomorrow morning for a 3-day business trip
and therefore won't be able to download and test the NMU-ed package
before April 6th.

But I will ASAP.

Raphael

Re: Pgcc in Deb

[Romain Chantereau]

>
> So the original question remains: is there a simple pgcc available somewhere?
>
> -Jim

Yes !  is there a simple pgcc available somewhere?

I'm going to tell you why I want a pgcc package: I want to build a
customized
version of the potato.

I have the sources, I compile the sources with pgcc in order to install
these
optimized package on a uniform park of PC.

I modify the configuration files of the applications in order to
preconfigure it
and make there use easier (ho what a bad english !)

That's all folks !

... Hum is there a simple pgcc available somewhere?

- Romainbegin:vcard 
n:Chantereau;Romain
tel;cell:06 70 27 03 47
tel;fax:01 43 66 25 72
tel;home:01 43 66 25 72
tel;work:Student
x-mozilla-html:TRUE
adr:;;33, rue de la Mare;Paris;;75020;France
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;-29152
fn:Romain Chantereau
end:vcard