Re: Re: Rpm-metadata Digest, Vol 16, Issue 5

Randy Zagar wrote:

>When you say that it "raises the bar sufficiently", you really ought to
>add "for me" to the end of that sentence.  You probably aren't working
>for the same set of clients that I am.  In addition to having paranoia
>that "goes to 11" as a job requirement, I also have to consider that any
>RPM-based system I deliver may be deployed for 20 years.  Given the
>current state-of-the-art, and my rather unique customer requirements,
>I'd prefer to follow the "tripwire" philosophy which is to never trust
>any single signature or checksum.
>  
>

I said "raises the bar" because I was too lazy to look up the numbers, 
not stating personal
opinion at all. IIRC, SHA-1 "broken" is 10**59 rather than 10**81 for 
crafted
hash collision. Make what you will of the numbers in whatever paranoid 
space you
want to live in.

And I seriously question 20 year life for rpm. For example, I plan to 
retire way before then. ;-)

The needs of packages for signatures and digests are perhaps less 
critical than live systems.

Packages burned on cdrom held in lock box are quite easy to develop 
significantly
more trust in than live system connected to internet, and so perhaps 
your tripwire
analogy does not apply to rpm.

>Plus, I'm not sure what the rationale for opposing an SHA-1 field in the
>xml file is based on...  Why aren't ALL rpm metadata fields being
>supported in xml?  Wouldn't it be simpler to just say "we support all
>metadata fields supported by RPM"?  That way there is no need to
>"discuss" whether or not something gets included in the DTD.
>  
>

rpm-metadata was designed to simplify depsolver downloads, not as a 
slternative
to package information. So the information that is useful to depsolvers 
is in rpm-metadata.

It's kinda hard to verify a digest on a file when the file is not 
physically present.

And downloading a *.rpm package always brings file md5 digest from signed
header, so it's unlear whether additional copy in rpm-metadata is needed 
at all.

And md5 protected by DSA/RSA signature is still pretty much routine 
algorithm.

If you need better or additional measures, then resigning *.rpm is quite 
easy and achievable
with whatever algorithms satisfy yer sick paranoia. That is entirely a 
different
issue than rpm-metadata fields.

>Anyway, some of these questions are just rhetorical.  I just brought
>this stuff up because I was looking at the sample xml files and didn't
>see all the fields I expected to see.  Anyway, feel free to ignore my
>rantings if you wish.  My needs are probably an edge-case anyway and I'm
>certainly not paying your salary, so handle it how you want...
>  
>

HTH

73 de Jeff

>-RZ
>
>
>On Mon, 2005-02-21 at 11:00, [email protected]
>wrote:
>  
>
>>Message: 2
>>Date: Sun, 20 Feb 2005 16:38:38 -0500
>>From: Jeff Johnson <[email protected]>
>>Subject: Re: [Rpm-metadata] Re: Rpm-metadata Digest, Vol 16, Issue 4
>>To: [email protected]
>>Message-ID: <[email protected]>
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>seth vidal wrote:
>>
>>    
>>
>>>On Sun, 2005-02-20 at 13:02 -0600, Randy Zagar wrote:
>>> 
>>>
>>>      
>>>
>>>>What makes you think I'm joking?
>>>>
>>>>The RPMs themselves contain SHA-1, MD5 checksums and GPG signatures.
>>>>
>>>>Why shouldn't the XML metadata files contain all relevant software
>>>>validation metadata?
>>>>   
>>>>
>>>>        
>>>>
>>>Well, if you want to validate the pkgs you check gpg signatures, not
>>>sha1sums or md5sums.
>>>
>>>so instead of just adding more data w/o any real use to the metadata it
>>>would make more sense, to me, to work on gpg signing.
>>>
>>>      
>>>
>>FYI: The problems are inseperable, DSA is based on SHA-1. If you can
>>create a SHA-1 hash collision, then you can spoof DSA.
>>
>>Meanwhile, *please* don't include Yet Another Digest everywhere in 
>>rpm-metadata,
>>nor try to add duplicate md5+sha1 disgests. Even if SHA-1 collisions are 
>>now know easier
>>than what was originally thought, it's not exactly trivial to do, nor is 
>>it going to be
>>trivial to create a SHA-1 hash collision for quite some years yet (if ever).
>>
>>And even then, having both MD5+SHA1 ain't the right answer, SHA257, or 
>>SHA386 or SHA512
>>raises the bar sufficiently.
>>
>>73 de Jeff
>>    
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Rpm-metadata mailing list
>>[email protected]
>>https://lists.dulug.duke.edu/mailman/listinfo/rpm-metadata
>>    
>>