[arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Patrick Burroughs (Celti)]

On Mon, 31 Oct 2016 16:16:21 +0100

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

[Levente Polyak]

Post by Patrick Burroughs (Celti)
On Mon, 31 Oct 2016 16:16:21 +0100

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.

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

Post by Patrick Burroughs (Celti)
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 ;)

Post by Patrick Burroughs (Celti)
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.

Post by Patrick Burroughs (Celti)
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

[Bennett Piater]

Post by Levente Polyak
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

[Ivy Foster via arch-general]

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

[Bennett Piater]

Post by Ivy Foster via arch-general
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

[Allan McRae]

Post by Bennett Piater

Post by Levente Polyak
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

[Bennett Piater]

Post by Allan McRae
I would like some bourbon.
Allan

I like your sense of humor :)

Post by Allan McRae
* 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?

Post by Allan McRae
** makepkg --source --sign

I know about that, it won't help the AUR though :)

[Leonid Isaev]

Post by Levente Polyak
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.

[Levente Polyak]

Post by Leonid Isaev

Post by Levente Polyak
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.

Post by Leonid Isaev
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

Post by Leonid Isaev
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

[Eli Schwartz via arch-general]

Post by Leonid Isaev
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...

Post by Leonid Isaev
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?

[Leonid Isaev]

Post by Eli Schwartz via arch-general

Post by Leonid Isaev
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...

Post by Eli Schwartz via arch-general

Post by Leonid Isaev
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.

[Eli Schwartz via arch-general]

Post by Leonid Isaev
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.

[Lukas Rose]

Post by Leonid Isaev
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.

Post by Leonid Isaev
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

[Leonid Isaev]

Post by Lukas Rose

Post by Leonid Isaev
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.

Post by Lukas Rose

Post by Leonid Isaev
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]...

Post by Lukas Rose
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?

Post by Lukas Rose
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-messaging-apps-not-spotted-for-4-months/
[3] http://security.stackexchange.com/questions/23334/example-of-a-backdoor-submitted-to-an-open-source-project

Post by Lukas Rose
Cheers, Lukas