Codecov Report

Attention: 29 lines in your changes are missing coverage. Please review.

Comparison is base (fab63c2) 79.90% compared to head (3e3feeb) 80.03%.
Report is 40 commits behind head on master.

❗ Current head 3e3feeb differs from pull request most recent head e942178. Consider uploading reports for the commit e942178 to get more accurate results

@@            Coverage Diff             @@
##           master    #1285      +/-   ##
==========================================
+ Coverage   79.90%   80.03%   +0.13%     
==========================================
  Files          67       67              
  Lines       19892    20075     +183     
==========================================
+ Hits        15894    16068     +174     
- Misses       3998     4007       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@sanapci Thank you for sharing your work!

How does RAUC benefit from the feature? This could be useful also for other users if want to handle certificates outside of the RAUC, in their application. For example, let's say there are multiple signing certificates and we want to get from the bundle which one was used and interpret behavior based on this.

I guess with 'multiple signing certificates' you mean alternative ones, since RAUC at the moment does not support multiple signers (at once), right?
Could you give an insight on what kind of interpretation you would do based on the signer?
Does it have to be done before invoking the installation?

From inside the bundle one could for example use hooks and the exported SPKI hashes to perform actions based on the kind of certificate used for signing: https://rauc.readthedocs.io/en/latest/advanced.html#switching-the-keyring-spki-hashes

This approach would make it easy to have a TOC/TOU vulnerability, as there is no guarantee that an installation started after calling this method would use the same bundle.

As @ejoerns mentioned, we'll need more details on your use case and an explanation why you see this approach is the best solution for it.

@ejoerns

I guess with 'multiple signing certificates' you mean alternative ones, since RAUC at the moment does not support multiple signers (at once), right?

Yes, you are right, I meant to have alternative ones and not in one bundle.

Could you give an insight on what kind of interpretation you would do based on the signer?

Let's say, the bundle validation fails with the installed trustchain. In this case, maybe an update required for the trustchain on the system because it is an outdated one and the installation fails.

Does it have to be done before invoking the installation?

Yes, this could be a prevention for a scenario, where the bundle installation fails.

From inside the bundle one could for example use hooks and the exported SPKI hashes to perform actions based on the kind of certificate used for signing: https://rauc.readthedocs.io/en/latest/advanced.html#switching-the-keyring-spki-hashes

With the hashes it is required to get the certificate with the same hash from the internet, otherwise it would not be possible to do verifications and checks with the certificate.

@jluebbe

This approach would make it easy to have a TOC/TOU vulnerability, as there is no guarantee that an installation started after calling this method would use the same bundle.

This feature is not intended to take over the verification from the installation process. If the install is trigerred the internal verification still executed.

@ejoerns @jluebbe Could you give an update (remarks, opinions, etc.) about this based on my previous comment?

@ejoerns @jluebbe Could you give an update (remarks, opinions, etc.) about this based on my previous comment?

Sorry, but the scenario doesn't make sense to me, yet.

How do you authenticate the new certificate?

Could you give an insight on what kind of interpretation you would do based on the signer?

Let's say, the bundle validation fails with the installed trustchain. In this case, maybe an update required for the trustchain on the system because it is an outdated one and the installation fails.

To know that you keyring is outdated, you shouldn't need the certificates, but just a dedicated error result from InstallBundle or InspectBundle. If you see that error, you'd know that an update is needed and the correct CA certificate could be fetched over a separate authenticated channel.

At that point I'm wondering though: If you have a way to authenticate the new CA certificate, why not just use the same certificate to authenticate RAUC bundles and avoid the whole issue from the start?

The changes in the pull requests are containing some errors and needs to be updated if required.

The details maybe were a bit misleading, so to be clear:
There is a root CA, an intermediate CA and the certificate used for bundle creation. By using the --intermediate, the bundle can be used with the root CA, what is more the intermediate CA can be extracted also. If the CA is updated online, but the system is offline or used offline, the certificate extraction from the bundle can be a solution to install new CA via an update bundle.

The extracted CA and certificate is verified with the root CA.