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

[Levente Polyak]

On 10/31/2016 04:43 PM, Patrick Burroughs (Celti) wrote:
> On Mon, 31 Oct 2016 16:16:21 +0100
> Levente Polyak <anthraxx at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161031/d6392ec9/attachment-0001.asc>