On 10/31/2016 04:43 PM, Patrick Burroughs (Celti) wrote:
On Mon, 31 Oct 2016 16:16:21 +0100 Levente Polyak <anthraxx@archlinux.org> wrote:
On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
As a middle ground, I think it would be more reasonable (or at least, less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at least parts of them. For an existing example, OpenBSD's signify(1) uses their cryptographic signature system to sign a simple list sha256sums.
Perhaps makepkg could include, e.g., a sha256sumsigs array, that contains a PGP signature (signed by the developer/TU's official key) of the contents (properly serialised by makepkg so there's a minimum of possible ambiguity) of the sha256sums array?
That is literally a _completely_ different topic that addresses _completely_ different areas. You are speaking about authenticating the build scripts itself. That does not solve _anything_ at all what this thread/topic/todo-list is about.
It really is not. I am not speaking of authenticating the build scripts; both this thread and my proposal are talking about ensuring the integrity of downloaded source files.
Well you wrote exactly that :P If I want to nitpick I could quote you:
On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
As a middle ground, I think it would be more reasonable (or at least, less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at least parts of them.
But never mind, that does not take us anywhere (i just could not resist) :P So lets be productive and focus on advantages... On 10/31/2016 04:43 PM, Patrick Burroughs (Celti) wrote:
Specifically, I am speaking of cryptographically signing the checksums for source files downloaded by the build scripts, so that they download what the author of the build script _intended_ them to download.
If you sign the PKGBUILDs you authenticate it. Where exactly is the difference in what you are saying? I get your point what you try to achieve but the PKGBUILD already contains the integrity values (checksums) for all external sources and if you sign the PKGBUILD (which is the build script) then you have implicitly authenticated all integrity values of the external sources. A signature is nothing more (but also nothing less) then an authenticated checksum. If you sign a tarball then you "only" sign its hash. On top (like a bonus :P) if you sign the PKGBUILD then you did not only authenticate the checksums of the external sources but also the buildscript itself. So you really want so sign that instead ;)
This is presumably the same reason for ensuring sources are downloaded via HTTPS instead of HTTP, where possible — adding a cryptographic authentication to ensure someone building a package does not get sources without being aware they are modified: only embedding signatures in the PKGBUILD is trusting the Arch devs via the pacman keyring or parallel method, instead of the (flawed) CA system. If there is another reason to switch to HTTPS, please — make me aware of it!
No its not. If you read the whole topic then you will see that Dave already perfectly pointed that out: It's simply another layer of security affecting the transport. Even if we would say its additional value for integrity is small, that would still mean its value is >0 (for adding a single letter :P). Lets simply assume an attacker has prepared some source tarballs by investing a lot of resources and time to create backdoored versions of source tarballs and find a collision of the upstream signed checksums. Then the attacker (assuming it has no access to the upstream server and performs a man-in-the-middle attack) would still need to break TLS on top of having the pre-collided backdoored sources. Now is the perfect time to quote Dave: "you must consider that security is not a binary thing". <3 :) But regardless of that, the least thing that you get out of this is confidentiality.
I really, really don't think they're independent from each other, and as I'm not authorised to post on arch-dev-public and didn't expect to draw this out into a conversation, I simply replied to the thread on arch-general. Bowing to peers, however... et voila: a new thread.
Having all this said, I still have the opinion that its related but still another topic. On one side we have transport layer security plus upstream (author) provided authentication of checksums (that's what a signature is). On the other side we have a dev/TU authenticating the buildscript. Both cover certain areas but are still independent and one does not make the other futile. cheers, Levente