[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt 0.6 and how it does *not* solve the problem

Thanks for all the input so far!

also sprach Thomas Bushnell BSG <tb@becket.net> [2004.08.23.0121 +0200]:
> I think this is a real problem.  I would quibble with your
> estimate of its likelihood, but that doesn't really matter.  (And
> I don't know what "incredulously high" means--check your
> dictionary--"incredulous" is not a synonym of "incredible".)

Yeah, sorry, incredible. I felt smart, and it was late.

> Start off with the assumption that we can trust real developers.
> If we cannot, then all bets are off.


> I have some ideas about how this could be done.

Please share.

> > I think, adding package signatures will actually make Debian less
> > secure than it was before, although it's doubtful that the average
> > user will notice or care.
> How can it make it less secure?

It gives the users a false sense of security. Having the package
verify suggests that it is authentic, when in fact it only says that
it has been uploaded by someone with control over any of the Debian
developer GPG keys.

I see that this goes both ways and does also raise security. But
do you also see my point?

also sprach Geoff <geoff.crompton@bjhcontrols.com.au> [2004.08.23.0134 +0200]:
> Is it possible on a gpg key server to mark a key as invalid, with
> out access to the private key?

Yes, by removing it from the keyring.

The question is how one would continuously QA the developers... and
how one would make sure that they treat the keys securely, which is
a whole different thing.

also sprach Russell Coker <russell@coker.com.au> [2004.08.23.0459 +0200]:
> Sounds like a reasonable idea.  We can't automatically make the
> key invalid.  But we can have a central Debian key that's used to
> sign the keys of all developers.  If such a signature was revoked
> then it would show the change in status of the developer.

Can you then readd such a signature?

Wouldn't removal from the Debian keyring be easier?

> Removing developers who don't meet certain criteria (EG no package
> uploads for 6 months) from active status makes a lot of sense.
> Anyone care to propose a GR?

No! not a GR! Technical committee or APT people...

also sprach Thomas Bushnell BSG <tb@becket.net> [2004.08.23.0507 +0200]:
> Careful about terminology here.  I wouldn't say "remove", just we
> drop them from the list of signatures.  They are still Debian
> developers. When a developer uploads who has been dropped from the
> list, maybe some kind of active authentication process can take
> place.  That is, this is the point for human intervention.


also sprach Thomas Bushnell BSG <tb@becket.net> [2004.08.23.0530 +0200]:
> But that's a totally different subject.  If you want to remove
> Debian developers from the list of developers, because they
> haven't uploaded in six months (what about packages that don't
> have bugs?!)

Good point. And also: uploading once every six months does not
ensure that the developer otherwise treats his/her key safely. Thus,
it does not really address the issue.

also sprach Bron Gondwana <brong@brong.net> [2004.08.23.0646 +0200]:
> b) if by date, what's to stop someone backdating a package and
> falsifying a mirror/proxy with a copy of their package.  The
> signature will still check out.

The mirrors/proxies have their own date. If the incoming queue does
not accept a backdated package, nothing could happen.

also sprach Hubert Chan <hubert@uhoreg.ca> [2004.08.23.0813 +0200]:
> AFAIK, developer keys aren't used to sign packages in the archive.
> They are only used to upload packages.  When you check the signature
> from the repository, you are checking it against the Debian archive key
> (which changes periodically).


Please do not CC me when replying to lists; I read them!
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

Attachment: signature.asc
Description: Digital signature

Reply to: