On Tue, Jul 17, 2012 at 5:38 PM, Pascal Bleser wrote:

(don't use MD5, it's insecure and can relatively easily be hacked with collisions, use SHA instead ;))

While this is basically true MD5 is used in OBS all over the place and thus for consistency and code reuse reasons it might still make sense to go with that. It should also be noted that the intent of the MD5 sum in Marcus' proposal is not to add a layer of security for malicious attacks (that you better prevent by verifying RPM signatures and SSL certificates for the connection (when using https)) but to use it as a simple checksum mechanism to detect technical transmission issues. Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 2012-07-17 17:43:40 (+0200), Robert Schiele wrote:

On Tue, Jul 17, 2012 at 5:38 PM, Pascal Bleser wrote:

...

(don't use MD5, it's insecure and can relatively easily be hacked with collisions, use SHA instead ;))

While this is basically true MD5 is used in OBS all over the place and thus for consistency and code reuse reasons it might still make sense to go with that. It should also be noted that the intent of the MD5 sum in Marcus' proposal is not to add a layer of security for malicious attacks (that you better prevent by verifying RPM signatures and SSL certificates for the connection (when using https)) but to use it as a simple checksum mechanism to detect technical transmission issues.

Alright, I understood "integrity" as in "security" too ;) And "while this is basically true" is always a risky statement, so let's make this very clear: MD5. IS. INSECURE. period. Unless you have legacy code and don't use it for security, and you are fine with someone manipulating the content unless you have another source of authentication, never, ever use MD5 again. As long as it is very clear to everyone that MD5 hashes can be manipulated (quite easily, actually), then it's fine, but just don't confuse it for an authoritative source :) But indeed, in this case, the X.509 of the HTTPS connection already provides an authenticity verification (as long as those are indeed verified, including on the hostname). cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

On Tue, Jul 17, 2012 at 8:54 PM, Greg Freemyer wrote:

Ignoring the X.509 certificate:

I find it much more troublesome that in most situations the hash comes from the same source as the package/data file. In those situations it is trivial to change the payload file, then just recalculate the hash and update it in the metadata file/source.

The hash *has to* come from the source of the package, the hash is there to avoid tampering in transit. It would be quite trivial to install a proxy between both systems that inserts malicious code into the package. The proposed GPG signatures can stop malicious proxies from recalculating the hashes.

Thus if the hash value itself can't be robustly trusted, there is no reason to worry about collision attacks which require far more resources than an attacker just updating the hash value to match his altered/infected payload file.

And collision attacks for MD5 do not require that many resources. I've carried them out successfully with my lowly Pentium 4 for a security workshop.

My impression is that the proposed solution makes no effort to "sign" the metadata, thus if a attacker is able to access the distribution infrastructure to manipulate the payload, they could manipulate the metadata.

Repos should already have signed metadata. At least I can see the signatures in download.o.o The only weak spot in verifying signatures is key distribution, which OBS cannot implement it 100% trustworthy. But, as I explained, it still is better than mere hashes. And, certainly, SHA-family hashes are way better than MD5.

Thus, other than the X.509 cert I argue that the whole proposed integrity mechanism as I understand it is broken from a authentication perspective no matter what hash is used, MD5 or otherwise.

X.509 is no stronger than GPG signatures. Hashes alone, maybe, but not with GPG-signed metadata. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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. However, our plan is to prepare SHA sums by the signer. It could be used for your usecase. But that means all rpms (and actually debs should) would be verified twice, because you can't skip the security verification. It would double IO load here and would not make the build faster... What would help here would be store if an rpm got verified in the cache. So the next build could skip it. -- 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

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).

However, our plan is to prepare SHA sums by the signer. It could be used for your usecase. But that means all rpms (and actually debs should) would be verified twice, because you can't skip the security verification.

If it's implemented in the signer is there a way to assign SHA sums to imported binary packages, too (like for imported Debian:5.0 packages) (it would be nice if all packages in the buildinfo carry a checksum attribute)?

It would double IO load here and would not make the build faster...

What would help here would be store if an rpm got verified in the cache. So the next build could skip it.

We would probably only do the check once the package is downloaded. Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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)). 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).

...

...

However, our plan is to prepare SHA sums by the signer. It could be used for your usecase. But that means all rpms (and actually debs should) would be verified twice, because you can't skip the security verification.

If it's implemented in the signer is there a way to assign SHA sums to imported binary packages, too (like for imported Debian:5.0 packages) (it would be nice if all packages in the buildinfo carry a checksum attribute)?

...

It would double IO load here and would not make the build faster...

What would help here would be store if an rpm got verified in the cache. So the next build could skip it.

We would probably only do the check once the package is downloaded.

And why not doing the gpg check at that point of time as you need to do it anyway?

See above. Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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

On Wed, Jul 18, 2012 at 2:28 AM, Adrian Schröter wrote:

...

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.

Is it? I don't remember setting up CA trust when connecting to my private OBS instance, and I would imagine I would have to in order to have osc validate the certificate. It would be really nice if osc did validate, I would applaud that :) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Wed, Jul 18, 2012 at 12:00 PM, Marcus Meissner wrote:

...

Is it?

I don't remember setting up CA trust when connecting to my private OBS instance, and I would imagine I would have to in order to have osc validate the certificate.

It would be really nice if osc did validate, I would applaud that :)

It does.

If your https is already signed with a valid CA then the query will not show up.

Of course you need to interface with "https://...." as API url.

I do use https. I'll have to check the sources, there are lots of subtle ways to bork SSL certificate checks in python's httplib, and the fact that osc didn't ask me (or I don't remember) makes me suspicious. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org