gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] tla--devo--1.2 has preliminary gpg stuff


From: James Blackwell
Subject: Re: [Gnu-arch-users] tla--devo--1.2 has preliminary gpg stuff
Date: Fri, 26 Dec 2003 23:15:11 -0500

In lists.arch.users, you wrote:
>
> --===============0766641896==
> Content-Type: multipart/signed; micalg=pgp-sha1;
>       protocol="application/pgp-signature";
>       boundary="=-EDsco06i0Q49iViTkhzR"
>
>
> --=-EDsco06i0Q49iViTkhzR
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, 2003-12-27 at 06:55, Tom Lord wrote:
>
>>=20
>> At any rate, it should only be an error if the archive is a signed
>> archive.  Otherwise it should be at most a single warning that the
>> archive is unsigned.
>
> I think that that should be configurable in the long term - i.e.
> --assume-signed-archive or some such - and retain the current behaviour
> in the short term.
>
> Otherwise, our conceptual attacker can simply remove
> \=3Dmeta-info/signed-archive, and turn a hard failure into a warning.

That's the beauty behind a really simple paranoid script like gpgcheck.
It doesn't even bother to see if meta-info/signed-archive exists. It
basically does this: 

scans for all the directories it can find
among those directories, pick the ones that are (base|patch)-[0-9]+
among those directories, pick the ones that have checksums
try to verify the signature of every checksum
for every checksum file check all the listed md5s.

Then: 

list all the dirs that are missing checksum files
list all the checksum files that have md5s that don't match
list all the checksum files that don't have a good signature


Why did I write it that way? 

1. Its too stupid to trick by removing a file here or twidling
   a bit there. *everything* is bad unless its been verified 
   to be good.
2. Even if a patch wasn't signed, the admin (while performing his 
   security sweep) needs to be reminded that he's got these patches
   that don't have a good signature and thus aren't protected.
3. It keeps the code simpler to not try and second guess gnupg. Here's
   what we have for documented return codes:
     | The program returns 0 if everything was fine, 1 if at least a
     | signature was bad, and other error codes for fatal errors.
   By using caveman '0 good, everything else Baaaad' tactics, we don't
   have to worry about gpg changing undocument return codes or mistaking
   return code 34 for 'no signature present' when the author changed
   it to mean gpg died trying to parse intentionally bad data.

During a we-got-cracked attack, anything on that filesystem we can touch
*is tampered with* until we can provably state that it has not been.
Thats why I didn't bother dealing with the .listing files. They're bad
data unless we can prove that they haven't been tampered with. However,
we can trivially fix that by putting .listing files in the checksum file
too.


-- 
James Blackwell        Using I.T. to bring more                570-407-0488
Owner, Inframix        business to your business        http://inframix.com

   GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400




reply via email to

[Prev in Thread] Current Thread [Next in Thread]