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
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.
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
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
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
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
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,
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
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?
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
Anthony Towns aj@azure.humbug.org.au 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
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
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?
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
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
Anthony Towns aj@azure.humbug.org.au 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
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
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
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
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
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
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
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.
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
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
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.
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?
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
Anthony Towns aj@azure.humbug.org.au 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
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
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.
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:
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
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
On Sat, Apr 01, 2000 at 01:24:03AM +0200, Marcus Brinkmann wrote:
The whole file --- verifying each entry would take at least three minutes
on my hardware, and god knows how long on anything moderately old or
outdated. I certainly wouldn't want to try it on m68k on a regular basis,
eg. (If
On Sat, Apr 01, 2000 at 12:15:01PM +1000, Anthony Towns wrote:
(among many other minor typos)
You can differentiated probably good but outdated old packages, and probably
^^
This should read can't differentiate. Whoops.
bad but outdated old packages, no. On the upside,
On Sat, 1 Apr 2000, Anthony Towns wrote:
I'm not sure why this isn't getting through. Automatically, cavalierly
signing Packages.gz on master *HAS DEFINITE GAINS OVER THE PRESENT WAY
OF DOING THINGS*.
How exactly do you propose to transfer a verification key to the clients?
I can't think of
On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote:
How exactly do you propose to transfer a verification key to the clients?
I can't think of any decent way to do this that isn't prone to some kind
of hack-a-mirror thing or involves annoying extra steps.
Just about everything is
On Sat, 1 Apr 2000, Anthony Towns wrote:
* the web of trust, and having the ftp-team sign it
The average user has no entry to the web of trust, so this is just as
useless. (and massively involved for our poor end user)
* putting a fingerprint on the website and in Debian books,
On Fri, Mar 31, 2000 at 09:31:31PM -0700, Jason Gunthorpe wrote:
On Sat, 1 Apr 2000, Anthony Towns wrote:
* the web of trust, and having the ftp-team sign it
The average user has no entry to the web of trust, so this is just as
useless. (and massively involved for our poor end user)
It's
On Sat, 1 Apr 2000, Anthony Towns wrote:
Why would verifying a new security-key necessarily be significantly harder
than verifying a new unstable-key, though? In both cases you only really
want to check that its signed by the previous security-key.
But in the other case it replaces/augements
Hi,
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?
Does it need to become part of policy? (in which case
On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote:
You are wrong about signed .debs vs signed package files. Signed .debs are
not worth the bytes to transfer a signature and the time check it. Their
only real use is to check the master archive against hack/corruption and
even
Hi,
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
On Tue, Mar 28, 2000 at 12:41:22AM -0500, Chris Frey wrote:
Quoting from the mailing list archives... :-)
Marcus Brinkmann [EMAIL PROTECTED] wrote:
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
The whole file --- verifying each entry would take at least three minutes
On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote:
It seems you feel personally insulted. 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.
Interesting. So signing
On Sat, Apr 01, 2000 at 08:52:36PM +0200, Torsten Landschoff wrote:
On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote:
It seems you feel personally insulted. I am sorry for this, but
unfortunately it doesn't change the situation that the signed packages case
adds a further
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
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
On Sat, 1 Apr 2000, Marcus Brinkmann wrote:
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.
We only trust link1 due to the vigilance of our FTP masters and people
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
Julian
--
Hi Anthony,
On Mon, Mar 27, 2000 at 08:37:10AM +1000, Anthony Towns wrote:
On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote:
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
The whole file --- verifying each entry would take at least three minutes
on my
On Wed, Mar 29, 2000 at 01:12:39PM +0200, Robert Bihlmeyer wrote:
Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.
Actually I don't care that much if the mirror is compromised, if it
affects only packages that I don't install.
Robert Bihlmeyer [EMAIL PROTECTED] wrote:
That's just the point: the security of a singly-signed Packages.gz
would not be much higher than that of the ftp sites themselves.
Nothing to win, here.
Actually I'm not concerned right now with the security of the main
debian ftp site. While that's
Anthony Towns aj@azure.humbug.org.au writes:
Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.
Actually I don't care that much if the mirror is compromised, if it
affects only packages that I don't install. If it affects some of
Quoting from the mailing list archives... :-)
Marcus Brinkmann [EMAIL PROTECTED] wrote:
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
The whole file --- verifying each entry would take at least three minutes
I don't think it is useful to sign the Packages file, because:
On Tue, Mar 28, 2000 at 12:43:32AM +1000, Anthony Towns wrote:
Actually, now I think about it, the Packages file itself is valuable
information. Consider a Packages file that doesn't actually changes the
.deb's, but changes the netbase entry, say to read:
Package: netbase
Anthony Towns aj@azure.humbug.org.au writes:
The only reason not to trust a key dinstall uses explicitly for signing
Packages is if you believe dinstall is compromised. If you believe that,
then you shouldn't be downloading .deb's *ever*, because you're immediately
running *untrusted* scripts
On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote:
Anthony Towns aj@azure.humbug.org.au writes:
The only reason not to trust a key dinstall uses explicitly for signing
Packages is if you believe dinstall is compromised. If you believe that,
then you shouldn't be downloading
On Mon, Mar 27, 2000 at 01:42:47AM +0200, Robert Bihlmeyer wrote:
There is no need to check all of [the packages]
Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.
Actually, now I think about it, the Packages file itself is valuable
On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote:
Chris Frey [EMAIL PROTECTED] writes:
So my question is, what are your thoughts on adding a signature to the
current Packages.gz file, or adding a similar *dsc file for it,
which is then signed?
Do you want to sign each
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
The whole file --- verifying each entry would take at least three minutes
on my hardware, and god knows how long on anything moderately old or
outdated. I certainly wouldn't want to try it on m68k on a regular basis,
eg. (If doing
On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote:
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
The whole file --- verifying each entry would take at least three minutes
on my hardware, and god knows how long on anything moderately old or
outdated. I
Anthony Towns aj@azure.humbug.org.au writes:
On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote:
Do you want to sign each package entry, or the whole file?
The whole file --- verifying each entry would take at least three minutes
on my hardware, and god knows how long on
Chris Frey [EMAIL PROTECTED] writes:
So my question is, what are your thoughts on adding a signature to the
current Packages.gz file, or adding a similar *dsc file for it,
which is then signed?
Do you want to sign each package entry, or the whole file? Whose
signature would be used?
On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote:
Chris Frey [EMAIL PROTECTED] writes:
So my question is, what are your thoughts on adding a signature to the
current Packages.gz file, or adding a similar *dsc file for it,
which is then signed?
Do you want to sign each
66 matches
Mail list logo
