DevHeads.net

HEADS UP: Source File Verification

Hello,

we've got new section in Packaging Guidelines about verifying upstream
sources[0] with GPG. Please use it whenever possible :)

Thanks!

[0] <a href="https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification" title="https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification">https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_...</a>

Comments

Re: HEADS UP: Source File Verification

By Joe Orton at 07/25/2019 - 05:17

On Wed, Jul 24, 2019 at 11:15:26PM +0200, Igor Gnatenko wrote:
It seems completely daft doing this at build time.

In the historic CVS-based build system which predated what we now use,
we could do GPG key verification at the time of downloading and
importing a new tarball. This makes FAR more sense to me than checking
the signature on the same tarball every build.

We'd put the set of trusted GPG keys in the repository alongside the
spec file, using some standard filename, and the build system would try
check the .asc against the keys when downloading (or uploading? I can't
remember) a new tarball. This would ensure the tarball uploaded to the
lookaside cache was trusted.

Regards, Joe

Re: Re: HEADS UP: Source File Verification

By Jason L Tibbitts III at 07/25/2019 - 11:08

JO> In the historic CVS-based build system which predated what we now
JO> use, we could do GPG key verification at the time of downloading and
JO> importing a new tarball.

You're right; tmz dug up a copy of the old Makefile.common file:
<a href="https://tmz.fedorapeople.org/tmp/Makefile.common" title="https://tmz.fedorapeople.org/tmp/Makefile.common">https://tmz.fedorapeople.org/tmp/Makefile.common</a>

I believe this is simply functionality that wasn't duplicated into
fedpkg (or rpkg or whatever) when we stopped using Makefiles. It would
certainly be useful to have it implemented and is worth someone opening
a ticket.

And in any case, it's still perfectly valid to check signatures at
package %prep time. Imagine I'm building from an srpm that I've
unpacked, or have grabbed the spec and run spectool -g. Why not have
the specfile check the signatures at that point? Doing it there doesn't
preclude doing it at some other step as well, and it's not as if this is
all that computationally expensive these days.

- J<

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 07/25/2019 - 13:22

Jason L Tibbitts III wrote:
It looks like that searched for and verified signatures when the
packager ran "make download". If they downloaded a new tarball with a
browser, then it would not be verified automatically. The packager
could then download the signature too and run "make download-checks"
manually – if they happened to remember and care. Experience shows that
most people don't care about security until it's too late, so the
verification would often not happen. No one else could know whether the
signature had been verified or not.

Having that functionality back could be a useful tool, but it would not
replace verification during the build, which the packager can't just
forget to do once they have added the one-liner to the spec file.

Björn Persson

Re: HEADS UP: Source File Verification

By Joe Orton at 08/08/2019 - 06:14

On Thu, Jul 25, 2019 at 07:22:56PM +0200, Björn Persson wrote:
If you don't enforce GPG verification at or before "fedpkg upload" there
is no assurance that what hits the lookaside cache is trusted, so I
agree - doing this at build time is a good example of not caring about
security until it's too late.

But I assume the FPC is off doing its own thing and will totally ignore
community feedback as normal, so I'll feel free to carry on ignoring FPC
output and this whole conversation is pointless.

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 08/08/2019 - 10:24

Joe Orton wrote:
I hope most people reading this can see the flaws in that reasoning.

It took a long time and some prodding, but the fact that the source
file verification policy was eventually accepted is proof that this
accusation is false.

Björn Persson

Re: HEADS UP: Source File Verification

By Simo Sorce at 08/09/2019 - 09:01

On Thu, 2019-08-08 at 16:24 +0200, Björn Persson wrote:
Hi Björn,
I have not commented on this till now and both Joe's email is
needlessly provocative as well as your dismissal is a bit content-less.

The question is simply, how can you trust build time verification if
you do not have INPUT time verification ?
What prevents me from putting *into* Fedora a completely bogus source
*AND* public key that always verifies correctly ?

Simo.

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 07/25/2019 - 06:46

Joe Orton wrote:
If you can implement that in such a way that the packager can't neglect
to verify the signature, then that might also work for Fedora's needs.
You'll have to think hard about how the code will know which source
file to verify against which signature in all possible situations.

Björn Persson

Re: HEADS UP: Source File Verification

By Joe Orton at 07/25/2019 - 07:00

On Thu, Jul 25, 2019 at 12:46:11PM +0200, Björn Persson wrote:
You talk like this is a hard problem but it was implemented that way for
the first N years of Fedora - possibly when the infrastructure was only
internal to Red Hat, I don't remember. It just got thrown away with the
move to git & fedpkg.

It worked from Makefiles but a fedpkg equivalent would be something
like:

fedpkg download => worked like spectool -g specfile.spec
but also fetched ${tarball}.asc

fedpkg upload X =>
if ./gpgkeys exists:
enforce verification of ${tarball} against ${tarball}.asc using ./gpgkeys
actually upload X and update sources

Re: HEADS UP: Source File Verification

By =?ISO-8859-1?Q?... at 07/25/2019 - 06:16

BTW, there is this proposal:

<a href="https://github.com/rpm-software-management/rpm/issues/463" title="https://github.com/rpm-software-management/rpm/issues/463">https://github.com/rpm-software-management/rpm/issues/463</a>

Vít

Dne 25. 07. 19 v 11:17 Joe Orton napsal(a):

Re: HEADS UP: Source File Verification

By Remi Collet at 07/25/2019 - 04:58

Le 24/07/2019 à 23:15, Igor Gnatenko a écrit :
Looking at the Guidelines...
Implementing it for PHP...

I agree with Petr and Wit, I don't see any real benefit
probably going to revert this

Remi

Re: HEADS UP: Source File Verification

By Remi Collet at 07/25/2019 - 05:16

Additional question, what will happen when the key will expire ?

Ok, probably not going to happen in Fedora, but may happen in some other
distributions, supported for more years

Re: HEADS UP: Source File Verification

By Vitaly Zaitsev ... at 07/25/2019 - 06:43

Hello, Remi Collet.

Expired keys cannot be used for signing or encrypting. But they still
can be used for decrypting and verifying signatures.

Re: HEADS UP: Source File Verification

By Petr Pisar at 07/25/2019 - 02:46

On 2019-07-24, Igor Gnatenko < ... at fedoraproject dot org> wrote:
May I know a FPC ticket where this change was discussed and approved?

I have few objections:

(1) I don't agree this feature is helpful. If we don't trust ./sources
file content in dist-git, we cannot trust keyring stored in the the same
dist-git repository. In other words it only brings another code into
spec files and build process that consumes resources and can fail.

(2) The "%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}'
--data='%{SOURCE0}'" command awfully verbose. "%{gpgverify}" defaulting
to "%{gpgverify 2 1 0}" for single-source packages would provide the
same functionality with less boiler-plate code. Actually augmenting
%setup macro that would perform the check automatically while user would
only build-require gnupg2 would be the best option.

(3) Recommended way of verifying uncompressed sources means double
decompression. Decompressing, verifying, and unpacking uncompressed
archive would be more processor friendly.

(4) Verification of modified archives conflicts with a legal requirement
that Fedora cannot distribute the unmodified archive.

-- Petr

Re: HEADS UP: Source File Verification

By Pierre-Yves at 07/25/2019 - 06:37

On Thu, Jul 25, 2019 at 06:46:24AM -0000, Petr Pisar wrote:
I'm more worried about it relying on GPG at the moment considering the state of
the SKS network [1].
What are the changes that we end up breaking a build if we suddenly get a
poisoned key? Are we going to break just a build or could this have more
annoying consequences?

Best,
Pierre

[1] "SKS Keyserver Network Under Attack" by Robert J. Hansen:
<a href="https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f" title="https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f">https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f</a>

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 07/25/2019 - 07:22

Pierre-Yves Chibon wrote:
The build doesn't access any key servers. The packager must obtain the
correct key and include it in the source package. Normally the packager
should download the keyring directly from the upstream website over
HTTPS. If upstream doesn't provide such a keyring (which would be
rather dumb), then the packager might fetch a key from a keyserver. In
that case a problem with the SKS network could prevent the packager
from obtaining the key. This would only be a problem when the packager
initially obtains the key, not when they update the package to a new
version, and certainly not on every build. Upstream can solve the
problem by publishing a keyring, taking keyservers out of the picture
entirely.

Note that a packager who gets a key from a keyserver has a problem with
verifying that the key they received is the correct one, as anyone can
upload any key to a keyserver. That's the primary reason why upstream
projects should publish their keys on their own websites.

Björn Persson

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 07/25/2019 - 06:17

Petr Pisar wrote:
<a href="https://pagure.io/packaging-committee/issue/610" title="https://pagure.io/packaging-committee/issue/610">https://pagure.io/packaging-committee/issue/610</a>

This objection is answered in the policy itself:

“Although a checksum in the sources file certifies that a file retreived
from the lookaside cache is the one that the packager uploaded, it is
silent on whether the file is what the upstream project released. A
signature by the upstream developers certifies that the source is
identical to what they released. Verifying the signature as part of the
build ensures that packagers don’t forget to verify it.”

The syntax is designed to be easy to remember and self-explanatory to
the reader.

Everyone who reads that would have to already know that the numbers are
source file numbers. Otherwise they won't understand what “2 1 0” means.
Packagers who are supposed to write it would have to look up the order
of the parameters every time. Named parameters can be given in any
order.

An RPM spec is not a place for golfing. Readable code takes priority
over saving keystrokes.

As you can see in the ticket, there was an attempt to make it fully
automatic, which was abandoned.

This is technically true, and doing that obviously works, though it
takes more of what you called “boiler-plate code”. In practice, I doubt
many upstream projects sign their code that way. It's a bad idea because
it unnecessarily exposes the decompression program to untrusted input.

If what you package is not what upstream released, then obviously you
can't verify it against upstream's signature. If you must remove
something for legal reasons, and you still want to verify the tarball,
then you can sign your modified tarball with your own key.

Björn Persson

Re: HEADS UP: Source File Verification

By Petr Pisar at 07/25/2019 - 08:30

On 2019-07-25, Björn Persson <Bjorn@xn--rombobjrn-67a.se> wrote:
-- Petr

Re: HEADS UP: Source File Verification

By Vitaly Zaitsev ... at 07/25/2019 - 07:57

Le 2019-07-25 12:17, Björn Persson a écrit :

Hit,

Then it should be implemented cleanly in a declarative syntax,
with %{gpg_signatureX} and %{gpg_keyringX} variables matching
%{sourceX}, and a single %gpgverify call that loops over all the
available variables.

With a declarative syntax there is less boilerplate in spec files, the
implementation can be changed later, or even moved outside the build
process, without requiring the rewrite of thousands of spec files

Regards,

Re: HEADS UP: Source File Verification

By =?ISO-8859-1?Q?... at 07/25/2019 - 03:31

Dne 25. 07. 19 v 8:46 Petr Pisar napsal(a):

I had the same objections:

<a href="https://pagure.io/packaging-committee/issue/610#comment-144451" title="https://pagure.io/packaging-committee/issue/610#comment-144451">https://pagure.io/packaging-committee/issue/610#comment-144451</a>

<a href="https://pagure.io/packaging-committee/issue/610#comment-535982" title="https://pagure.io/packaging-committee/issue/610#comment-535982">https://pagure.io/packaging-committee/issue/610#comment-535982</a>

Vít

Re: HEADS UP: Source File Verification

By =?iso-8859-1?q?... at 07/25/2019 - 06:35

Vít Ondruch wrote:
And in response to that I added the paragraph that explains that a
signature by the upstream developers certifies that the source is
identical to what they released, not just that the file is the one that
the packager uploaded. Policies should come with justification, so
thank you for pointing out that the initial draft didn't explain this.

Björn Persson