Package Signing

ZD: https://gitlab.zendesk.com/agent/tickets/14437

Description

We recently had to update through a client's package mirror which resulted in a no gpg signature message.

Next steps

Investigate if there is something we can do to improve this.

---

/cc @dblessing @marin

@balameb which OS package was this?

@marin pretty sure it was gitlab-ce-8.3.4-ee.0.el6.x86_64.rpm

Suspected as much.

We can do something about this, omnibus can sign packages. I will add the issue to a milestone but no guarantees when it is going to happen. Unless the customer needs this urgently.

Milestone changed to 8.6

@marin We're not signing packages now? If that's the case, it's strange that we ran in to this error. We figured the problem was that the packages were signed, but because the user was mirroring the repo it couldn't verify that GPG signature. Strange issue. Probably related to how the customer was mirroring the repo.

@dblessing We are not signing packages with a gpg key.

We should probably do that so the issue still stands for implementation.

@marin move this to a later milestone?

Yup, this will have to be handled when we get some capacity in omnibus-gitlab.

Milestone changed to 8.8

mentioned in issue #1203 (closed)

ZD: https://gitlab.zendesk.com/agent/tickets/19020

Adding another report to this issue.

@marin customer is not able to update. What do you recommend?

Customer from the previous comment used Acquire::https::packages.gitlab.com::Verify-Peer "false"; as a temporary solution.

@marin How much work would it be to implement this?

@stanhu as to RPMs it's very easy - see howto http://fedoranews.org/tchung/gpg/

With the new build system I'm working on currently, I don't think it will take that much time to implement package signing.

@davidhrbac we also need to do this on deb packages and do it programatically.

@marin good to hear that. It's very easy to implement it within the automatic build pipeline. BTW are you using the mock for the RPMs?

mentioned in issue #1360 (closed)

Milestone changed to %8.10

RPM signing is nearly done, waiting for GPG key to be provided from our infra.

Milestone changed to %8.11

Reassigned to @marin

mentioned in merge request !922 (closed)

This is blocked. RPM signing is done, keys are created but the issue is how to easily share this with the users, see https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/922#note_14053165 .

Packagecloud responded to my query with:

You are correct -- this is not possible with packagecloud at the moment, but I'm actually working on this after I ship another feature that I am (hopefully) wrapping up this week.

One temporary workaround for now is: sign your RPMs, upload your public key somewhere, and then generate your own repository list that mentions both keys.

I don't think this is worth the effort, and I see very small number of users that would be willing to do this manually. Postponing this until we get that feature from Packagecloud or find another way of doing it.

@marin you can always create package like gitlab-release. It will contain the key and yum repo configuration. Yum conf might also point to the key at URL.... An easy solution to distribute and deploy by the end-user.

I am aware of that @davidhrbac but I don't think it is worth the effort to be honest.

@marin I guess that it is worth doing... Having release package you can control yum setting on end-user side. So you can migrate, modify the repos, ergo you are in control. BTW create release file might take 10-15?!? mins... Just my 2 cents...

Milestone changed to %8.12

Added blocked label

I've received another request for this from another customer who are close to implementing a security policy that won't allow them to install without signature.

@marin Just a note, if you provide the errata within the repository you might make happy users of Spacewalk. It can automatically update RPM packages based on errata within the infrastructure.

I can help with RPM spec file, I can also help with Spacewalk and repository design. I can show you real world scenario.

We already have infrastructure in place, introducing another thing we have to maintain for this one case is an effort we cannot afford. Once packagecloud introduces the support or we decide to move away from our current package server, this issue will be finished.

Milestone changed to %8.13

Milestone changed to %Backlog

Sorry for bumping but are there any news? We're using gitlab in the core of our infrastructure. Having an unsigned package there is . Is there a packagecloud issue we can bump?

No news. Packagecloud doesn't have an open issue tracker.

Crazy that packagecloud doesn't have this implemented considering they have an article on how it improves security...

https://blog.packagecloud.io/eng/2014/11/24/howto-gpg-sign-verify-rpm-packages-yum-repositories/

Signing data with a GPG key enables the recipient of the data to verify that no modifications occurred after the data was signed (assuming the recipient has a copy of the sender’s public GPG key).

This is actually a pretty serious issue for anyone who wants to use gitlab in highly secured environment. We have strict rules that all installed software must be cryptographically signed and that signature must be verified before it's installed.

It's also a scored CIS Benchmark, meaning any company that adopts CIS will require this.

I am aware of that @davidhrbac but I don't think it is worth the effort to be honest.

I think there's a small number of people complaining about this, but I'd be willing to bet there's a much larger number of people who simply choose another tool.

@marin what do you think about at least computing hashes during the build process so they can be posted somewhere and manually checked?

mentioned in issue #2537 (closed)

changed milestone to %9.5

assigned to @WarheadsSE

Work is being done to finish package signing within our build system and serve it via package server since our package server now has support.

removed blocked label

Work being done for this can be followed at

• https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2537
• https://gitlab.com/gitlab-org/omnibus/merge_requests/7

mentioned in merge request !1771 (merged)

Is this issue closed by omnibus!7 (merged) @briann ?

@ernstvn Still not resolved. We have a few more tasks to do, see https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2537 . Once they are complete, this issue will be closed.

marked this issue as related to #2537 (closed)

closing. Will be in 9.5.0

closed