Am Mittwoch, 18. Juli 2012, 00:10:20 schrieb Marcus Hüwe:
On 2012-07-17 23:14:59 +0200, Adrian Schröter wrote:
Am Dienstag, 17. Juli 2012, 22:15:04 schrieb Marcus Hüwe:
On 2012-07-17 21:45:21 +0200, Adrian Schröter wrote:
Am Dienstag, 17. Juli 2012, 21:13:33 schrieb Marcus Hüwe:
On 2012-07-17 17:47:07 +0200, Marcus Meissner wrote:your
On Tue, Jul 17, 2012 at 05:31:40PM +0200, Marcus Hüwe wrote: > Hi, > > some days ago darix and I had a small discussion about verifying the > integrity of the downloaded packages which are used for local builds. > The idea is that we add a checksum for each package to the buildinfo > xml so that a client/osc can "easily" check if the downloaded file is > corrupted. > For instance we could add the hdrmd5 to buildinfo (this would require > only a small change in the backend) or alternatively we add the md5 > of the whole package to the buildinfo (this would probably require > a bigger change in the backend). The advantage of the latter is that > it is much easier to verify for the client (but then I don't think > there are many clients which deal with the buildinfo at all...). > > Any opinions?:)
I thought there is RPM key checking done already? At least it asks me for the keys..
This could be reused for this.
Yes currently osc checks the rpm signature but this is only true for rpms. We cannot verify the integrity for deb packages or arch packages. Thus it would help if we have some hash value which can be used for checking the package (or in case of the hdrmd5 that at least some "parts" of the downloaded file are correct).
Also the current rpm key checking just "assures" integrity of the package - nothing more (IMHO because we just download a key from the api and check the rpm).
but the user needs to decide if he trusts the project or not. That is the important security thingy here.
Hmm well that can be easily implemented for all binarytypes - we just need walk through the buildinfo's path elements and ask the user. This doesn't change the fact that osc current rpm signature check only assures integrity (IMHO).
Where do you see a security problem?
Well it's rather an issue with the current workflow: - ask user if he "trusts" the project(s) - download the pubkey(s) from the api - check gpg signature of the packages
The user doesn't verify if the received pubkey is a "correct"/expected key. That is the performed gpg check is just some kind of integrity check (we do not verify authenticity - just that the package was signed with "some" key (which is delivered by the api)).
Right, but the api is verified via the SSL certificate. So you trust the server that it hands you the right key for the project.
IMHO we can achieve the same by using some hash value (unless we make the workflow from above more complex). The advantage is that this works for all binarytypes (rpm, deb, arch).
Yes, thinkable with some strong SHA key. But it will fail, when it downloads noarch packages from mirrors (just one noarch package is there and thank to murphy always the one from the other architecture). Also packages from Export filters will be a problem then. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org