qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU
Date: Wed, 27 Mar 2019 17:24:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 03/27/19 17:15, Paolo Bonzini wrote:
> On 27/03/19 17:05, Daniel P. Berrangé wrote:
>> On Wed, Mar 27, 2019 at 04:58:23PM +0100, Paolo Bonzini wrote:
>>> On 27/03/19 16:30, Daniel P. Berrangé wrote:
>>>> Perhaps the VM test scripts should do a "HEAD" request for the image
>>>> every time to discover if it has been changed on the server, before
>>>> honouring the local cache.
>>>
>>> Another possibility is to first download the shasum from
>>> download.patchew.org, and compare _that_ against the one that is stored
>>> locally, instead of hardcoding it in QEMU's repository.
>>
>> Personally I prefer the idea of having the shasum stored in the repo.
>>
>> That means that if we update git master to point to a newer image,
>> previous stable branches will stick with their original image, rather
>> than using a new image that may be incompatible with the stable branch
>>
>> Storing hash in git also means that if someone compromised the patchew
>> server, they can't cause developer to run compromised images, without
>> first also compromising git to change the hash.
> 
> The two are not mutually exclusive.  We can warn if the hash doesn't
> match against the one in QEMU, add a --force option, or whatever.
> 
> Also, I have now created symlinks by hash at
> http://download.patchew.org/by-sha256sum in case someone finds them useful.

Isn't this risky? If someone replaces an image file (keeping its name),
the old symlink will continue "working", but the hash stated by the
symlink's name will not match the pointed-to image file.

It would be nice to enforce a hash update on upload, or addressing files
by content.

... Are we inventing a git submodule? :)

Laszlo



reply via email to

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