[arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)
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. 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. 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! Also the very first reply in the thread talked about adding upstream signatures instead of changing the protocol, where possible — only not every upstream offers or _wants_ to offer them, so I proposed, in response to a prompt for discussion on the subject in the mail I quoted, a way to make that feasible.
Don't get me wrong: I don't judge about it at all, I'm just saying that both are fully independent from each other and you should please open a new thread if you want to discuss this rather then hijack this thread :)
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. ~Celti
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
On 10/31/2016 06:04 PM, Levente Polyak wrote:
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.
Since this thread is helpfully on arch-general now, I want to quickly chime in and say that I would really like authenticated buildscripts at some point :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 31 Oct 2016, at 6:14 pm +0100, Bennett Piater wrote:
I want to quickly chime in and say that I would really like authenticated buildscripts at some point :)
Any PKGBUILD kept in git can already optionally have this feature. See git-commit(1), specifically, its --gpg-sign option. iff
Any PKGBUILD kept in git can already optionally have this feature. See git-commit(1), specifically, its --gpg-sign option.
I know that, I have [commit] gpgsign = true in my ~/.gitconfig. It would be nice if more people did that and if makepkg checked that, though. It would probably be counter-productive to enforce it on the AUR through a git hook, but maybe a warning or something? I might post that to aur-general at some point. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 01/11/16 03:14, Bennett Piater wrote:
On 10/31/2016 06:04 PM, Levente Polyak wrote:
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.
Since this thread is helpfully on arch-general now, I want to quickly chime in and say that I would really like authenticated buildscripts at some point :)
I would like some bourbon. Allan * It might appear unrelated, but I can spend time on pacman/makepkg if I don't have to work for bourbon. Then again, bourbon reduces the quality of my coding after a point... ** makepkg --source --sign
On 11/01/2016 12:40 AM, Allan McRae wrote:
I would like some bourbon.
Allan
I like your sense of humor :)
* It might appear unrelated, but I can spend time on pacman/makepkg if I don't have to work for bourbon. Then again, bourbon reduces the quality of my coding after a point...
I wasn't asking you to do more work, you do enough good work already. I might work on that myself, my studies take up too much time right now though. Remotely related: https://www.xkcd.com/323/ Btw, maybe I might by you some bourbon one day, I'm in Europe though. What kind do you like? Or would you want actual scotch instead?
** makepkg --source --sign
I know about that, it won't help the AUR though :) -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On Mon, Oct 31, 2016 at 06:04:48PM +0100, Levente Polyak wrote:
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 ;)
As a side question... is there a significant difference in signing PKGBUILD vs the compiled package. Given that when building a pkg, I inspect the PKGBUILD, what attack is possible when the PKGBUILD is not signed? Also, isn't the use of dev signature to validate upstream sources is a logical flaw? A dev might herself be mislead and build a trojaned source... Thx, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 10/31/2016 10:50 PM, Leonid Isaev wrote:
On Mon, Oct 31, 2016 at 06:04:48PM +0100, Levente Polyak wrote:
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 ;)
As a side question... is there a significant difference in signing PKGBUILD vs the compiled package. Given that when building a pkg, I inspect the PKGBUILD, what attack is possible when the PKGBUILD is not signed?
Well that are two fundamentally different things. Signing the final binary package authenticates that the one you received and want to install is really what the dev/TU has built. Signing the build-script (PKGBUILD) adds exactly this authentication to the build-script that produced the given binary package. You obviously only have advantage out of it if you are using that build-script for anything (like building it yourself or for a rebuild by someone else). It's exactly why you want to have signatures from upstream (authors): to be sure who actually created it. Reading the build-script is good and especially in the AUR quite important... but at the end it mostly only saves you from obvious shit. If there is anyone evil who alters it to attack you then I'm convinced you most likely won't notice that by manually reading. It could be a small security related change in an existing patch-file that comes with the sources or as simple as a small swapped letter in the domain or github username that is added to the source array of the PKGBUILD and retrieves an evil version instead.
Also, isn't the use of dev signature to validate upstream sources is a logical flaw? A dev might herself be mislead and build a trojaned source...
Sure, but I never said or claimed anything else. That's why i always insisted this to be a different topic (other then the original one). What i specifically said is that you need both as they have fundamental different areas they cover: On 10/31/2016 06:04 PM, Levente Polyak wrote:
Both cover certain areas but are still independent and one does not make the other futile.
By signing a PKGNBUILD of cause you don't "validate upstream sources" in a way you described. No matter what, but to validate authenticity of an upstream source, you obviously need an upstream signature. What you gain is that you add the same authentication to the build-script itself. Anyone obtaining a copy of it can verify it was really created by a dev/TU and everything it used or pulled in (with or without upstream signatures) is actually what that dev/TU had. Again: You want to have both to cover different areas that one or the other does not. cheers, Levente
On 10/31/2016 05:50 PM, Leonid Isaev wrote:
As a side question... is there a significant difference in signing PKGBUILD vs the compiled package.
Do you realize, when you ask if there is a difference between signing a PKGBUILD vs. a built package, it sounds an awful lot like asking if there is a difference between a PKGBUILD and a built package? Well, of course there is a difference. They are two different things...
Given that when building a pkg, I inspect the PKGBUILD, what attack is possible when the PKGBUILD is not signed?
Off the top of my head, there is *the topic of this thread*. Someone could modify the checksums and deliver fake sources. When the PKGBUILD just says "run `make`", how do you tell the difference? -- Eli Schwartz
On Mon, Oct 31, 2016 at 07:18:01PM -0400, Eli Schwartz via arch-general wrote:
On 10/31/2016 05:50 PM, Leonid Isaev wrote:
As a side question... is there a significant difference in signing PKGBUILD vs the compiled package.
Do you realize, when you ask if there is a difference between signing a PKGBUILD vs. a built package, it sounds an awful lot like asking if there is a difference between a PKGBUILD and a built package?
It does not, really...
Given that when building a pkg, I inspect the PKGBUILD, what attack is possible when the PKGBUILD is not signed?
Off the top of my head, there is *the topic of this thread*. Someone could modify the checksums and deliver fake sources. When the PKGBUILD just says "run `make`", how do you tell the difference?
Well, my mentality is that authenticating plain-text data is usually not necessary because a user can always inspect it (notice, I don't care if a PKGBUILD comes from an authentic source, I only care if its not doing smth malicious). This is why I inspect the PKGBUILD and corresponding install files / patches. At least, I thought this is why PKGBUILDs are not signed in the same manner that Gentoo signs ebuilds... Regarding checksums, how did a dev know that upstream sources are authentic? I use a similar judgement (as a practical example, in my packages I always maintain multiple checksums: one from Arch, another from Gentoo, third from Debian/Fedora, and have a keyring with all upstream keys I can get). But anyway, my question has already been answered... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 10/31/2016 07:35 PM, Leonid Isaev wrote:
Regarding checksums, how did a dev know that upstream sources are authentic?
Personally, I check the upstream sources of stuff I publish to the AUR. I maintain an additional *-git package for anything that makes sense that way, so it is easy to diff/log. -- Eli Schwartz
On 01 Nov 2016, at 00:35, Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
Well, my mentality is that authenticating plain-text data is usually not necessary because a user can always inspect it
You just can't reliably inspect plain text install data, unless you spend an awful lot of time on it. As already pointed out, it's just too easy to miss out small malicious changes. And even if you were able to spot those, most average users won't, and that's what policies are meant for: the average user.
Regarding checksums, how did a dev know that upstream sources are authentic?
It's not about the upstream source to be authentic, it's about the upstream source reached your hard drive without further (malicious) modification. That saying, you can't expect a package maintainer to review all the code he uses (indirectly) in his package. If you use another (open source) project, that one could always be malicious. But we'll assume that case not likely (in general). It is much more likely that an attacker will try to break things you install (although I still assume that this is not often), than a group of attackers hiding malicious software in an (open source) project. The former can be easily locked out by checksums, the latter only by extensive code reviews. And even if they were done, you'd still have to trust the one who did the review. Since there's an easy fix for the former, let's use it. Since there is none for the latter, let's keep an eye on this. There's always trust to a certain degree. Cheers, Lukas
On Tue, Nov 01, 2016 at 03:59:28AM +0100, Lukas Rose wrote:
On 01 Nov 2016, at 00:35, Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
Well, my mentality is that authenticating plain-text data is usually not necessary because a user can always inspect it
You just can't reliably inspect plain text install data, unless you spend an awful lot of time on it. As already pointed out, it's just too easy to miss out small malicious changes. And even if you were able to spot those, most average users won't, and that's what policies are meant for: the average user.
Perhaps you should try it yourself instead of arguing? I have been doing this since 2010 with about 50 packages. PKGBUILDs are not usually long and therefore easy to grasp with a single glance.
Regarding checksums, how did a dev know that upstream sources are authentic?
It's not about the upstream source to be authentic, it's about the upstream source reached your hard drive without further (malicious) modification. That saying, you can't expect a package maintainer to review all the code he uses (indirectly) in his package. If you use another (open source) project, that one could always be malicious. But we'll assume that case not likely (in general).
On the contrary, planting backdoors in OSS projects is a very likely scenario, that has happened multiple times already [1-3]...
It is much more likely that an attacker will try to break things you install (although I still assume that this is not often), than a group of attackers hiding malicious software in an (open source) project.
Where is such confifence coming from?
The former can be easily locked out by checksums, the latter only by extensive code reviews. And even if they were done, you'd still have to trust the one who did the review. Since there's an easy fix for the former, let's use it. Since there is none for the latter, let's keep an eye on this. There's always trust to a certain degree.
I can't really disentangle this pile of... thoughts. Cheers, L. [1] https://en.wikipedia.org/wiki/Vsftpd [2] http://arstechnica.com/business/2012/02/malicious-backdoor-in-open-source-me... [3] http://security.stackexchange.com/questions/23334/example-of-a-backdoor-subm...
Cheers, Lukas
-- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (8)
-
Allan McRae
-
Bennett Piater
-
Eli Schwartz
-
Ivy Foster
-
Leonid Isaev
-
Levente Polyak
-
Lukas Rose
-
Patrick Burroughs (Celti)