#6267 sign ostree commits
Closed: Fixed 2 years ago Opened 3 years ago by walters.

This has been discussed several times. AIUI it is blocked on a Fedora policy of not doing detached signatures.

As downstream Red Hat Enterprise Linux and its associated PST are OK with detached signatures, I think Fedora should as well.

The GPG signature would have helped mitigate https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=1e408e111008f539c89212a9ca9bb955e2c4f823
for example.


It is not blocked only on our policy of not doing detatched signatures. There is a couple of other issues besides detached signatures.

We do not sign rawhide at all. signing the tree adds a manual step at the end of every updates and branched compose as someone would have to go and manually sign the tree.

Ideally we would have metalink support and be able to use the mirrors which would mittigate the need to sign the tree at all. With metalink support besides being able to leverage the mirrors we would gain the support of having the metalink provide via https a sha256 or higher checksum of the tree. which can be used to verify the integrity of the tree.

Metalink and TLS is good, but it's not a direct replacement for GPG. For example:
- GPG is inherently "pinned", whereas the TLS default allows all ca-certs which allows a lot of organizations to MITM
- GPG is much easier to verify "offline"

As far as the manual step - I'd be fine with an automated process.

Replying to [comment:2 walters]:

Metalink and TLS is good, but it's not a direct replacement for GPG. For example:
- GPG is inherently "pinned", whereas the TLS default allows all ca-certs which allows a lot of organizations to MITM
- GPG is much easier to verify "offline"

As far as the manual step - I'd be fine with an automated process.

I guess I was not clear, we have no way to do any signing automatically. The way the signing server works it is entirely manual

I guess I was not clear, we have no way to do any signing automatically. The way the signing server works it is entirely manual

This isn't the only place where it'd be nice to also be able to do some signing automatically. With "no signatures at all" and "only signed by hand" as the only choices, we have a gap which leaves us either less secure or less agile than ideal. Sounds like we need to work on getting a project to address this resourced.

Can we change this conversation from "we have two options and they both suck", to "we (Fedora Rel-Eng) need X things to have a third option that does not suck"? :)

Rawhide isn't signed because of signing-system limitations, not because of policy, right? What do we need to enable that? And if something else wants to be signed after meeting some minimum bar, we could handle that case too.

Rawhide packages are mostly signed nowadays, but the signing system is not as reliable as it should be, therefore it cannot be guaranteed. I would also help with automating the ostree signing.

Note that unlike signing RPMs where the entire binary content is signed, OSTree commits are tiny files which just have a SHA256 of other objects - and OSTree commits can be signed asynchronously from the "build". My observation has been that funnelling significant amounts of data through the signing process has been a source of a lot of the unreliability.

The fact that OSTree signing works this way is not an accident =)

Replying to [comment:6 till]:

Rawhide packages are mostly signed nowadays, but the signing system is not as reliable as it should be, therefore it cannot be guaranteed. I would also help with automating the ostree signing.

But it's still a manual process with no means of gating unsigned packages so it's really moot, either it's all guaranteed to be signed or it's not reliable.

Note also there are two steps:

1) Adding signatures
2) Configuring the client to enforce their presence (i.e. dropping the --nogpg on https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-atomic.ks#n36 )

We can do 1) and see how it works then do 2).

Replying to [comment:5 jgreguske]:

Can we change this conversation from "we have two options and they both suck", to "we (Fedora Rel-Eng) need X things to have a third option that does not suck"? :)

Rawhide isn't signed because of signing-system limitations, not because of policy, right? What do we need to enable that? And if something else wants to be signed after meeting some minimum bar, we could handle that case too.

Sure, I was giving the options available that I think we can realisticly deliver in the short to medium term. the signing software has not realistically been actively worked on ever and has not had a commit at all since 2012 https://git.fedorahosted.org/cgit/sigul.git/log/ we have not been sucessful in getting anyone to be able to work on it despite multiple attempts.

We do have a policy of not doing detatched signatures which we would have to change, unless atomic gained the ability to support inline signatures.

To me the main blocker in implementing this is fixing sigul to be more reliable and to enable a way to provide authentication via a means other than a manual password entry.

The signing automation is now implemented in RoboSignatory, sigul has gained methods to sign ostree commits.
The only reason we're not signing trees at this moment is due to a bug that I need to trace down, but all the parts should be in place.

Metadata Update from @walters:
- Issue assigned to puiterwijk
- Issue set to the milestone: Fedora 23 Final

2 years ago

afaik all commits are now signed. So I am closing this issue

Metadata Update from @ausil:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata