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(a)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