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
lowe
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
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 you
27;^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
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
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, y
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
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 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-
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
> > > > cha
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 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,
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 thou
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 tr
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
> 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 usual
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 upda
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 connecte
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 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-age
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 machin
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 vuln
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
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 doe
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
>
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
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
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
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
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 en
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,
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 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 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 r
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
--
=-=-=-=-=-=-=-=-=-=-=-=
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
read
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 vun
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 id
ackages case
> > adds a further point of weakness to the chain of trust.
>
> Interesting. So signing Packages.gz will lower the security?
No. Currently there is NO chain of verification (I should not have said
"trust", it's the wrong term. Sorry).
However, it doesn
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.
Interesti
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
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 ou
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,
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 I
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/augemen
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)
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 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 i
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 cli
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 upsi
it to people, and they'll legitimately
think you've revoked your key.
> Note that this would not have a theoretic advantage,
> because the user would still have to update his information about trusted
> keys from some other site (pgp key server). It would just add some
> redu
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
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
Anthony Towns 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
those packages, I will no
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 tha
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
> D
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, becau
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
i
On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote:
> Anthony Towns 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*, be
Anthony Towns 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 as root on your sy
Anthony Towns 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 anything moderately o
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 c
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 doi
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
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
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?
> T
Hi,
To my understanding the package process is fairly secure on the incoming
side of Debian's package managment system. Maintainers sign their uploads
which prevents a man-in-the-middle attack.
These packages are then checksumed in Packages.gz, but nowhere is that
file signed, that I know of. T
67 matches
Mail list logo
