radical suggestion for fc4 release

[Nils Philippsen]

On Thu, 2005-02-03 at 12:39 -0500, Jeff Johnson wrote:
> Nils Philippsen wrote:
> 
> >On Thu, 2005-02-03 at 08:19 -0500, Jeff Johnson wrote:
> >
> >  
> >
> >>Whether changelogs should be part of an immutable region or not is an open
> >>question too. It is (and was) certainly possible to define a header 
> >>immutable region
> >>without including changelogs content, which would permit truncation or other
> >>forms of normalization, editing header content while installing.
> >>
> >>I chose to put *all* tags into a header immutable region so that I
> >>would not have to have the discussion about which tags go where.
> >>
> >>For example, the content in changelogs, if not hardened by digest and/or 
> >>signature,
> >>might be part of a socially engineered exploit to disguise a maliciously 
> >>modified
> >>package. It's very hard not believe what you read.
> >>    
> >>
> >
> >Well, I didn't propose anything of that sort (i.e. changelog outside of
> >what is digested/signed) ;-). What I meant was that it is irrelevant
> >whether you sign/digest an actually existing stream of bytes which
> >contains the changelog or the result of a function which puts together
> >this stream from changelog and the remainder of the header.
> >  
> >
> Yep, one can reassemble a header from components, and verify blobs.
> 
> That was the context of my previous comments: you cannot reassemble a blob
> unless the components are actually present, and there almost certainly 
> will beAWOL
> some way for separate changelogs to go AWOL preventing reassembly.

Agreed. 

> Splitting changelogs out, but not changing how digest/signature are 
> performed on headers,
> adds complexity and additional failure modes where there are none now, 
> that are hard to "trust"
> for no perceivable gain to verifiability other than compatibility with 
> the exsisting mechanism.
> 
> Move changelogs out of headers, or truncate to acceptable length, is 
> better imho.
> 
> Or RFE an explicit mechanism for moving changelogs out of headers and 
> normalizing content.

Just musing ;-): Individual signatures on each header component, along
with a signed list of components that should be present. That way, if
something goes corrupt, you can find out what is broken ("URL not ok")
unless the list gets damaged and a list should be a smaller target to be
hit by random disaster than a complete header blob. This of course
doesn't bring any more security where malice is involved, but I can as
easily corrupt a complete header blob as I can the list or other single
components, so nothing lost here.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011