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

Re: RFC: gnupg


[ Fortunately, I have reasonably thick skin.  Next time, James, think
  about what someone might be trying to get across before dumping an
  anthill in your pants. ]

On 5 Jul 1998, James Troup wrote:

>Well, duh.  That is *not* a show stopper.  The whole point of
>switching to GNUPG is to get away from the forced use of non-free
>programs, any program which supports RSA and IDEA is automatically

    Okay, you resign a few hundred megs of packages.  Fine by me.  The
point was that GPG isn't going to be able to verify all the signatures
we currently have in the archive.  Perhaps I'm overestimating our
archive turnover time, but this strikes me as a bit of a problem.

>> They're also the only way of communicating with PGP.
>So what?  This is (or was, before it got dragged onto devel) about
>changing what Debian uses as its verification tool.  We do not need
>to communicate with PGP to do that.  It is not about what Debian

    We will need to communicate with PGP until all of the packages have
been resigned.  That's a lot of packages.

>> Hm.  Maybe I'll experiment with key spoofing during the confusion
>> involved in getting all the new keys in...  Nah.
>a) grow the hell up.  I'm _seriously_ under-impressed by so called
>   developers who talk about trying to bypass our security protocols
>   (such as they are) even in jest.

    Grow the hell up.  I'm seriously under-impressed by anyone so
thin-skinned that they can't tell the difference between someone who's
going to try to compromise Debian security and someone pointing out a
possible security hole.  Granted, it's incredibly improbable that anyone
would ever manage to make use of it, but that hasn't stopped anyone from
making a big deal of other tiny security holes.  If your confidence in
the new-developer procedure is so small that you  think that
developers are likely to be randomly exploiting flaws in Debian
security, maybe you should take another look at that procedure.

>b) what confusion?  Current maintainers send their gpg keys in signed
>   by their PGP key.  How much confusion or opportunity for
>   exploitation do you see there?  Please enlighten me you /<-rad
>   cracker d00d, you.

    You wrote another message that sets up an illustration for this, so
let me add it in here.

>> You can't use an existing PGP key to sign a GPG key, not in the
>> usual fashion anyway.  I suppose I could uuencode the GPG key output
>> and sign THAT with my PGP key.
> *sigh*.  Are you trolling?
> gpg --armor --output mykey.asc --export "Joe Bloggs"
> pgp -fast < mykey.asc > mykey.asc.pgp

    Which is identical to extracting a key and uuencoding it, except
that your way you may run into problems with PGP barfing on the GPG
headers (PGP tends to not like dashes).  So here's how an attack could
take place.

    Old developer A creates a new GPG key, extracts it, signs with his
old PGP key and sends it in.  Verifying developer B receives the
message, verifies and strips the PGP signature.  Unfortunately, he's
foolishly doing this on a machine where he's not root, or doing it in
a user-writable directory.  Nasty intruder C knows that A was planning
on sending in a new key, and has spoofed a key with his name, and
encoded it.  Since he happens to be root, or at least a user with
access to whatever temporary directory is in use, he quickly copies
his spoofed keyfile over the keyfile that was just checked and
extracted.  Knowing that he has just verified the key, B now adds this
substituted key to his keyring.  Checking it over, he finds that it is
signed by itself and seems to work perfectly.  There are no signature
failures because the only signature made by a trusted key was on the
wrapping, not on the key itself.
    Obviously, this requires that the person handling the key exchange
make the error of doing this in a place where the intruder could
overwrite the unwrapped key before it was added to a keyring, so it's
not very likely in terms of a real attack on Debian.  Which puts it
about in the same category as a root exploit discovered in a piece of
software, say, on va, but it's only exploitable for a few seconds each
day and then only by someone who already has an account.  Funny.
People would have made a big deal about that.

    The thing that got my attention when I first looked at GPG was
that there was no way to leave an indelible PGP signature on a GPG.
At the time, I thought that the correct solution was to update PGP to
take advantage of the GPG protocols, so you could create a PGP key
with the new protocol signed by an older PGP key, which could then be
verified, and then use the new PGP key to sign the GPG key, which GPG
could then verify, creating an indelible chain, even though GPG would
not itself be able to verify the start of the chain.  Nobody ever
implemented anything like that, though, mostly because the licensing
on PGP makes it a bitch to modify.  The last time I looked at it, I
was surprised that the pgpi people were able to get away with what
they did, since the license at least for the freeware version forbids
the redistribution of modified binaries.

>Can we please chill the hell out here?  No one is talking about

    Funny, I was about to say that.

>``cutting off'' anyone, except you, who are doing a fine job of
>spreading large amounts of FUD.

    The tone of the entire thread, both here and the last time I saw
it come up on -policy, was the overall replacement of pgp with gpg as
a signing tool in the Debian community.  Personally, I kind of like
the idea of encouraging the spread of gpg by having new developers
start with it.  Maybe it'll spread.  However, much as free software
might be desirable, you have to know that in terms of usage, it's in
the minority right now, and that includes gpg.  The conversion to gpg
needs to be accompanied by a rewrite of documentation, and a number of
scripts to let things happen automatically.  The only time I've seen
these things mentioned is as an afterthought by people that as far as
I know are not planning on becoming directly involved in the
conversion.  This bothers me.  In effect, the tone has been that no
support is planned for people have been using PGP, but are going to be
switching, which is our entire developer base minus new developers.
That qualifies as "cutting off" until I see a better migration plan.

>> Also be warned that if you decide to abandon pgp completely, you
>> aren't going to be able to verify most of the signature that you run
>> across.
>No, you're wrong, you see, because we *are* going to abandon PGP
>completely, and at some point in the future dinstall will simply
>reject PGP-signed uploads, so *you* better get use to it.

    Let me exaggerate a bit and note that it's possible that by the
time that all of our packages have been resigned by the developers,
assuming that takes as much time as it did for the developers to libc6
compile all of their packages, RSA will have gone into the public
domain, and half of the problem will be gone.
    It's kind of funny to see you take this tone, actually, since my
original message said that if GPG were mandated for package signing,
I'd use it.  Mostly I'd be irritated if it were dumped on me in such a
way that I had to rewrite all my scripts myself (which might not be
that bad, actually, since I've already set up my system in such a way
that package signing is done with PGP 2.6 even though I use PGP 5.0
for everything else).  All I did was to point out problems that I saw.
As requested.  Call it an informal pre-bug report.  Fortunately, I
have thick skin.

>Debian currently uses PGP signatures to ensure packages in the
>distribution come from a Debian developer.  This is
>\litotes{problematic} because it forces our developers and worse our
>users to use non-free software to verify the signatures on these

    Now extrapolate.  How many signatures does this make?  Hm.  How
long until gpg gets set up and the new scripts written well enough for
gpg to be used in signing packages?  Hm.  How long for all of the
developers to get new keys made and to set things up and THEN reupload
all of their packages with new signatures?  Hm.  Has it occurred to
you that during this time, both PGP and GPG will be in use?  I am well
aware of the problems with mandating the use of non-free software.
I'm a developer; I read the contract; I'll support it.  That doesn't
mean that when someone asks if I see any problems I'll stay silent
just because it seems to denigrate the use of a free software package.
I look forward to a conversion to GPG the way I look forward to a
future conversion to a common packaging format.  It'll be cool, but I
expect it to make a mess, and I expect both developers and users to be
confused.  "Oh good, all of the signatures in Debian are available so
I can check packages off of their latest stuff in incoming!  Wait a
minute, this signature check failed.  Hm.  No, I got the keyring.
Lemme go find the FAQ again.  No FAQ.  Hm.  <putter putter>  Oh, you
have to use the OTHER keyring with the OTHER program to verify some
packages.  Lemme try that.  Worked.  What a pain."  And that's
assuming an advanced user.

>I don't use non-free software and I *don't* want it forced on me, but
>the current situation does that.  And I know it's not just me who's

    Nobody said that the current situation wasn't ugly.  My point was
that the solution, at least during the interim time, is going to be
ugly, too.  Which is what I call a show-stopper.  Maybe I
misunderstood the reference.

 Zed Pobre <zed@va.debian.org>  |  PGP key on servers, fingerprint on finger

Version: 5.0
Charset: noconv


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: