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@xxxxxxxxxx
"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
