On 02/19/2015 03:28 PM, Doug Newgard wrote:

On Thu, 19 Feb 2015 15:15:42 -0500 Mark Lee wrote:

...

Salutations,

After trying to build the mpv-0.8.0-1 and finding that the PKGBUILD's checksum was incorrect, I filed a bug report. See https://bugs.archlinux.org/task/43882?project=5&cat%5B0%5D=33&string=mpv.

I filed it under "critical" since an incorrect checksum means that the package was built from source that doesn't match upstream's source. I was told it's not a critical issue and it was downgraded to medium. I'm wondering why incorrect checksums aren't considered "critical".

Regards, Mark

The checksum matched when the package was built or it wouldn't have built for the maintainer, either. This means it's not a security issue, the only way it could be considered critical. All it means is that upstream changed something, only really affecting people trying to build from the PKGBUILDs. Normally, I would make this low severity, as it really doesn't matter that much.

Doug

To Doug, While I am not accusing the packager of any misdeeds since another bug report indicates that there was an upstream change; a correct PKGBUILD should be able to be rebuilt. If the package cannot be rebuilt using the same PKGBUILD linked to upstream, how can one trust that there hasn't been some tampering with the package source outside of the PKGBUILD? Regards, Mark

On 19 February 2015 at 21:42, Doug Newgard wrote:

You can't. If upstream provides a checksum, that gives you some verification, but since github doesn't, there's no way to verify any of it.

I don't know about github, but with bitbucket the checksums of these generated tarballs may change occasionally as I had this issue with luxrender. However, the sources were always the same, it was the metadata that changed.

On 02/19/2015 05:46 PM, Mark Lee wrote:

On 02/19/2015 05:24 PM, Lukas Jirkovsky wrote:

...

On 19 February 2015 at 21:42, Doug Newgard wrote:

...

You can't. If upstream provides a checksum, that gives you some verification, but since github doesn't, there's no way to verify any of it.

I don't know about github, but with bitbucket the checksums of these generated tarballs may change occasionally as I had this issue with luxrender. However, the sources were always the same, it was the metadata that changed.

How important are checksums to PKGBUILDS then? Should sources with varying checksums just have 'SKIP' in their integrity arrays?

Regards, Mark

Furthermore, if the integrity check is different from upstream, is a packager obligated to host a copy of the source code for GPLed software? Regards, Mark

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/20/2015 03:27 AM, Daniel Micay wrote:

On 19/02/15 11:39 PM, Mark Lee wrote:

...

On 02/19/2015 05:46 PM, Mark Lee wrote:

...

On 02/19/2015 05:24 PM, Lukas Jirkovsky wrote:

...

On 19 February 2015 at 21:42, Doug Newgard wrote:

...

You can't. If upstream provides a checksum, that gives you some verification, but since github doesn't, there's no way to verify any of it.

I don't know about github, but with bitbucket the checksums of these generated tarballs may change occasionally as I had this issue with luxrender. However, the sources were always the same, it was the metadata that changed.

How important are checksums to PKGBUILDS then? Should sources with varying checksums just have 'SKIP' in their integrity arrays?

Regards, Mark

Furthermore, if the integrity check is different from upstream, is a packager obligated to host a copy of the source code for GPLed software?

Regards, Mark

No... the integrity check not matching is not because an out-of-tree source tree was used. The checksums are certainly not there to improve security, that's what GPG signatures are for.

The checksums are there for integrity. The GPG signatures only confirm the packager built the package. My question is if a packager's PKGBUILD fails a checksum and the license is GPL, how does the packager fullfill their requirement to provide the source code? How does the packager prove that the source was used to build the binaries, especially when there are hash collisions in md5? The packager seems to offset the source code necessities by grabbing the source from upstream, but the checksums don't match... I understand that the metadata changed which changed the checksum, but that doesn't really change the question of what to do with source code versioning systems that have changing checksums and the need to supply source code for GPL projects. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlTnPpgACgkQZ/Z80n6+J/bmMwD7Brg4pcLE6Cewagug1pEIrb5X ZPzsu5wZcm+wEwXFF+YA/R0zlmnr7HApAY/4fCyXGa7/myvFw5KBmAJkf7UdtBpt =eFui -----END PGP SIGNATURE-----

Hi, On 02/20/2015 03:22 PM, Daniel Micay wrote:

On 20/02/15 09:03 AM, Mark Lee wrote:

...

I understand that the metadata changed which changed the checksum, but that doesn't really change the question of what to do with source code versioning systems that have changing checksums and the need to supply source code for GPL projects.

Checksums aren't sources. Checksums aren't a proof that the package was built from those sources. Checksums also aren't a valuable security mechanism, unlike the support for GPG verification of sources. They're blindly updated on every release and clobbering release is common... so we've all learned to ignore checksum failures. I don't understand what this has to do with the GPL.

Checksums proof that the sources you downloaded when running makepkg are the same sources the author of the PKGBUILD used. This can be a valuable security measure when those sources are not downloaded on a secure connection (http instead of https and the like). I'm not sure if downloads over the git:// protocol are actually verified, because the transfer is definitely not secure. I do hope so. Greetings, Florian

On 02/20/2015 03:59 PM, Daniel Micay wrote:

The vast majority of users make use of the binary packages and the checksums do absolutely nothing to secure the main attack vector which is a compromise of the sources downloaded by the packager. It is only relevant to the tiny minority of people building a package with ABS.

The more meaningful compromise needs to happen to the actual package in the repositories. A compromise of the server hosting the sources is the most likely way for this to happen. HTTPS can't do anything to defend against it. HTTPS can only defend against a MITM attack on a specific downstream packager.

The difference is that if certain government organizations infiltrate the Arch servers or upstream, they break everyone's security. They may be less likely to do that compared to breaking just yours.

There is support for validating sources with GPG signatures, which is a complete solution to this issue. If you care, then file issues for any packages that aren't using the upstream signatures yet, and complain to upstream if they aren't signing the releases.

This certainly is the right way to go, but I don't think enough upstream projects care to make it a viable option for personal computers today. PKGBUILD checksums provide less security, but they do provide some.

On 20/02/15 09:41 AM, Florian Pelz wrote:

...

I'm not sure if downloads over the git:// protocol are actually verified, because the transfer is definitely not secure. I do hope so.

Git's read-only protocol is not authenticated. It supports SSH and HTTPS which do have two different forms of authentication, both of which are very flawed. Signed tags make a lot more sense, and you shouldn't be using code from development branches if you care a lot about robustness and security, since

It is not authenticated, but I care about checksums. (Authentication would be even better because it ensures others don't know what software I am running -- but that is too much to ask.) I don't see why SSH and HTTPS are flawed, other than a distrust in certificate authorities. I still hope that git:// downloads use checksums. I'm not sure. Greetings, Florian

On 20/02/15 10:26 AM, Mark Lee wrote:

However, the issue still stands regarding checksums. Perhaps packages with metadata changes should just not include checksums? Or, they could just link to the sources.archlinux.org in those cases with checksums.

Ideally, devtools would generate a source package, sign it and upload it along with the binary packages. It would eliminate the minor flaws in the current GPL compliance and there would actually be a way to obtain the original sources used to build the package and compare to whatever upstream currently offers. The source packages are currently generated by a cron job on the server... I'm sure patches are welcome but you aren't going to find many people who really care.

In addition, I was thinking more along the lines of coercion.

I don't know what you mean. The checksums prove absolutely nothing about how the binary package was built. The packager can provide whatever checksums they want, regardless of what sources they used to build the package.

On 02/20/2015 04:51 PM, Daniel Micay wrote:

PKGBUILD checksums provide *zero*, yes *zero* security for the case that matters most, which is the build done by the packager. It does provide the ability for other people to verify that a MITM attack was not used to target a specific packager... but that is far, far less likely than a compromise of the sources on the upstream server and it can't do anything about that.

I guess the likelihood depends on who the attacker and what their motive is, but you are probably right. Still, checksums improve security in cases that can matter if there is no better verification from upstream. That said, if the security is verified another way, is there no need to use SHA256 rather than MD5, because the latter should be enough for ensuring there are no download errors?

Trust in certificate authorities is trust in many corporations and governments around the world. It's trust in tends of thousands of individuals with the ability to sign whatever they want. An attacker with the ability to perform a targeted MITM attack on a specific Arch developer likely has the ability to sign whatever they want.

Any certificate authority caught signing fraudulent certificates would no longer be trusted. They surely can, but they would not want to. Unless you are an extremely high value target, I think CAs can be trusted. Greetings, Florian

On Fri, Feb 20, 2015 at 06:54:10PM +0100, Florian Pelz wrote:

On 02/20/2015 04:51 PM, Daniel Micay wrote:

...

PKGBUILD checksums provide *zero*, yes *zero* security for the case that matters most, which is the build done by the packager. It does provide the ability for other people to verify that a MITM attack was not used to target a specific packager... but that is far, far less likely than a compromise of the sources on the upstream server and it can't do anything about that.

I guess the likelihood depends on who the attacker and what their motive is, but you are probably right. Still, checksums improve security in cases that can matter if there is no better verification from upstream.

That said, if the security is verified another way, is there no need to use SHA256 rather than MD5, because the latter should be enough for ensuring there are no download errors?

...

Trust in certificate authorities is trust in many corporations and governments around the world. It's trust in tends of thousands of individuals with the ability to sign whatever they want. An attacker with the ability to perform a targeted MITM attack on a specific Arch developer likely has the ability to sign whatever they want.

Any certificate authority caught signing fraudulent certificates would no longer be trusted. They surely can, but they would not want to. Unless you are an extremely high value target, I think CAs can be trusted.

Greetings, Florian

CAs can, and have, deliberately issued fraudulent certificates. TrustWave is the only one that has been discovered doing this --- and that, only because they came forward on their own years after the fact. The security community generally agrees that many, many of the less reputable CAs have done or are doing this. TrustWave is, by the way, still trusted. In addition, there have been many, many fraudulent certificates issued by CAs that were not keeping their network secure. Such CAs rarely have their trust revoked in practice. The bottom line is that the CA network is large and complex, and your browser trusts thousands of CAs all over the world, including some that are... erm... sketchy. You seem to have an awful lot of confidence, considering the size of that attack surface. I'd be happy to continue this discussion, but we should split it into a separate topic. -Dolan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/20/2015 09:22 AM, Daniel Micay wrote:

On 20/02/15 09:03 AM, Mark Lee wrote:

...

The checksums are there for integrity. The GPG signatures only confirm the packager built the package. My question is if a packager's PKGBUILD fails a checksum and the license is GPL, how does the packager fullfill their requirement to provide the source code? How does the packager prove that the source was used to build the binaries, especially when there are hash collisions in md5? The packager seems to offset the source code necessities by grabbing the source from upstream, but the checksums don't match...

The checksums don't "prove" anything. A package could have simply been built with --nocheck, it may have been built with a corrupt source (it does nothing for the initial and most important download) or upstream may have swapped out the tarball as they often do.

Complying with the GPL may mean making source packages available... but the checksums really have nothing to do with it. You cannot possibly reconstruct the sources from a checksum if the upstream download goes away... it has no relevance to the GPL.

...

I understand that the metadata changed which changed the checksum, but that doesn't really change the question of what to do with source code versioning systems that have changing checksums and the need to supply source code for GPL projects.

Checksums aren't sources. Checksums aren't a proof that the package was built from those sources. Checksums also aren't a valuable security mechanism, unlike the support for GPG verification of sources. They're blindly updated on every release and clobbering release is common... so we've all learned to ignore checksum failures. I don't understand what this has to do with the GPL.

Checksums aren't sources, they are a method of verifying the integrity of sources. In other words, while different files can have the same md5sum (hash collision), a failed checksum indicates something has definitely changed in the package. Checksums can have false positives but not false negatives. In other words, the provided source is definitely not the same as the source the packager used (metadata difference in this case). If checksums are as useless as you claim, why even offer them if they cannot be reproduced for certain packages? Do packagers really just ignore checksums and "blindly update" on every release? Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlTnSmUACgkQZ/Z80n6+J/aM4wD/TUaw/RGkMHEqUbcDoHEZuKIy l+b9kkywSbxOrd7ys+8BAIY2fM1opHOjcJdJjJ35Ifn7yA0PY34FSybyIrzQ4aQe =GqJJ -----END PGP SIGNATURE-----

On 20/02/15 10:04 AM, Martti Kühne wrote:

On Fri, Feb 20, 2015 at 3:53 PM, Mark Lee wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Checksums aren't sources, they are a method of verifying the integrity of sources. In other words, while different files can have the same md5sum (hash collision), a failed checksum indicates something has definitely changed in the package. Checksums can have false positives but not false negatives.

In other words, the provided source is definitely not the same as the source the packager used (metadata difference in this case). If checksums are as useless as you claim, why even offer them if they cannot be reproduced for certain packages?

Do packagers really just ignore checksums and "blindly update" on every release?

Regards, Mark

I get your point. Consider though, that Archlinux' comparably slim manpower cannot account for every time upstream does things to their source tarballs, usually in an unannounced manner. The concept is here, that ABS users need to figure out themselves whether *their* sources are retrafficked dns or the packager's. In so far as these things happen, they don't even have to do with archlinux that much (it's not very nice of an upstream to do that), so try not to bark up the wrong tree.

Cheers! mar77i

You should really just tell upstream to sign their releases, because it wipes out the attack vector instead of just making it possible to audit whether a MITM attack on the original. packager occurred like hashes. The hashes provide no security for the initial packaging work and no defense against an attack that's done by compromising the upstream sources, which is far more realistic than a targeted MITM attack on a specific Arch Linux packager.

On 20/02/15 09:53 AM, Mark Lee wrote:

On 02/20/2015 09:22 AM, Daniel Micay wrote:

...

On 20/02/15 09:03 AM, Mark Lee wrote:

...

The checksums are there for integrity. The GPG signatures only confirm the packager built the package. My question is if a packager's PKGBUILD fails a checksum and the license is GPL, how does the packager fullfill their requirement to provide the source code? How does the packager prove that the source was used to build the binaries, especially when there are hash collisions in md5? The packager seems to offset the source code necessities by grabbing the source from upstream, but the checksums don't match...

...

The checksums don't "prove" anything. A package could have simply been built with --nocheck, it may have been built with a corrupt source (it does nothing for the initial and most important download) or upstream may have swapped out the tarball as they often do.

...

Complying with the GPL may mean making source packages available... but the checksums really have nothing to do with it. You cannot possibly reconstruct the sources from a checksum if the upstream download goes away... it has no relevance to the GPL.

...

...

I understand that the metadata changed which changed the checksum, but that doesn't really change the question of what to do with source code versioning systems that have changing checksums and the need to supply source code for GPL projects.

...

Checksums aren't sources. Checksums aren't a proof that the package was built from those sources. Checksums also aren't a valuable security mechanism, unlike the support for GPG verification of sources. They're blindly updated on every release and clobbering release is common... so we've all learned to ignore checksum failures. I don't understand what this has to do with the GPL.

Checksums aren't sources, they are a method of verifying the integrity of sources. In other words, while different files can have the same md5sum (hash collision), a failed checksum indicates something has definitely changed in the package. Checksums can have false positives but not false negatives.

I'm well aware of what cryptographic hashes are. A failed validation of the sources indicates that the sources are different from what the packager specified in the PKGBUILD, which could mean that the download was corrupt or that something malevolent happened but in all likelihood it simply means that upstream clobbered the tarball.

In other words, the provided source is definitely not the same as the source the packager used (metadata difference in this case). If checksums are as useless as you claim, why even offer them if they cannot be reproduced for certain packages?

Again, checksums prove nothing. If the packager wants to build the binary package with different sources, they can do that without the checksums in the PKGBUILD reflecting it. The packager can ask makepkg not to verify the checksums, and they could simply modify makepkg to remove the check if there was no switch to turn it off... it in no way avoids placing trust in the packager.

Do packagers really just ignore checksums and "blindly update" on every release?

Yes, what else do you expect them to do? They run `updpkgsums` which downloads the sources and updates the checksums... it has no security value for the packages in the repositories. Zero. Value. If upstream cares about security, they sign their releases. There is fantastic support for verifying GPG signatures in makepkg, and we use it whenever it's available. File a bug if a package could be using it and is not using it. Either way, you trust the packagers of binary packages. It is difficult to verify that trust... the only way it is easy to do is if the build is deterministic and the version of the packages used to build it is specified. Since Arch's toolchain is rolling, reproducing builds is going to be quite hard...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

I understand that the metadata changed which changed the checksum, but that doesn't really change the question of what to do with source code versioning systems that have changing checksums and the need to supply source code for GPL projects.

if i understand you correctly, you want to be able to prove, that a certain source was used in a certain PKGBUILD to generate a certain binary package you are looking at. that kind of security is not built into arch. you cannot even prove that the PKBUILD from abs or svn reflects the one that was used to build that package you have. it is a well-intended question to ask for GPL compliance and provable sources, but that is not happening in arch. its about trust (thats why they are called TU!), and the problem you try to solve ist ill-defined. that aside, i think, that rebuilding packages should be possible (correct checksums etc), but it can fail for a bunch of reasons, so its not the TUs fault mostly. 0,02€ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU50dJAAoJELKHx5nAxn3sKssIAIj2vyA4vuxvbbmS7mv8z41E vyaCP6gZPWTCi0lA4xEIiRamgIV4QgLYmv7a5BR3xfoOvc/vxTzIOhBWqgigf7Y7 u34vYOCfcUcyKT1pse8mbuOHiTVd78LDanugX/TAkRzwM4y4aq/HXlLaXjiz6LC1 g7Rh9QCzqsMO+a8/KfClQXvIT1od1Frvgxnh5LQqgzZ47iVbkJfNUVbqCBmLVybi vjmdO3Zma5Qq0xiFbR3gAewKMcpl7EBs6svvv82BreHYyQf8VdPKderLtjqhCaR8 bMldKGuaH1RW6oDAmMZNdIANgzmBFs3FmgVfrV/pjHYBvAAe/zcuKGlWQgmfP8Q= =d7Rj -----END PGP SIGNATURE-----