info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#992155: extrepo: A cronjob / systemd timer should automatically refresh signing keys
0 views
Skip to first unread message
Francois Marier
Aug 13, 2021, 8:10:03 PM8/13/21
to
Package: extrepo
Version: 0.8
Severity: normal
If I install a package using a supported external repo:
extrepo enable brave_release
apt update
apt install brave-browser
the current Brave signing key will automatically be fetched and placed in
/var/lib/extrepo/keys/.
However, when Brave updates their signing key, then what I get is a message
along the lines of:
$ sudo apt update
...
Err:3 https://brave-browser-apt-release.s3.brave.com stable InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://brave-browser-apt-release.s3.brave.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
W: Failed to fetch https://brave-browser-apt-release.s3.brave.com/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
W: Some index files failed to download. They have been ignored, or old ones used instead.
until, assuming the new signing key was merged in the extrepo-data
repository, I manually refresh the local key using:
extrepo update brave_release
Given that upstream key rotations such as these should generally be
encouraged (as opposed to never-expiring or 10year-long expiries), many
users are going to get stuck with broken updates and won't know from the apt
error message that they need to do an extrepo update.
I suggest a simple fix, a daily cronjob or systemd timer which goes through
all enabled repos and updates the local copy of the keys. These keys are
already signed by extrepo, so the trust chain is maintained at all times.
Francois
--
https://fmarier.org/
Version: 0.8
Severity: normal
If I install a package using a supported external repo:
extrepo enable brave_release
apt update
apt install brave-browser
the current Brave signing key will automatically be fetched and placed in
/var/lib/extrepo/keys/.
However, when Brave updates their signing key, then what I get is a message
along the lines of:
$ sudo apt update
...
Err:3 https://brave-browser-apt-release.s3.brave.com stable InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://brave-browser-apt-release.s3.brave.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
W: Failed to fetch https://brave-browser-apt-release.s3.brave.com/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A8580BDC82D3DC6C
W: Some index files failed to download. They have been ignored, or old ones used instead.
until, assuming the new signing key was merged in the extrepo-data
repository, I manually refresh the local key using:
extrepo update brave_release
Given that upstream key rotations such as these should generally be
encouraged (as opposed to never-expiring or 10year-long expiries), many
users are going to get stuck with broken updates and won't know from the apt
error message that they need to do an extrepo update.
I suggest a simple fix, a daily cronjob or systemd timer which goes through
all enabled repos and updates the local copy of the keys. These keys are
already signed by extrepo, so the trust chain is maintained at all times.
Francois
--
https://fmarier.org/
Tomas Pospisek
Sep 17, 2021, 1:50:04 AM9/17/21
to
An alternative approach could be that an `apt update` would trigger an
`extrepo update`.
I don't know enough about apt hooks etc. to be able to say if that would
be feasible or - in case such a mechanism isn't available today - if
apt's maintainers would be in favor of it?
Installing a cron job that periodically retrieves extrepo updates would be
easier to implement. However the problem of offline systems should be
considered then. What do you do with systems (laptops f.ex.) that sleep
when a cron job would be triggered or that are not connected to the
internet at that time? One could look into systemd's timer mechanisms if
the support being deferred until the system wakes up and is connected to
the internet.
*t
`extrepo update`.
I don't know enough about apt hooks etc. to be able to say if that would
be feasible or - in case such a mechanism isn't available today - if
apt's maintainers would be in favor of it?
Installing a cron job that periodically retrieves extrepo updates would be
easier to implement. However the problem of offline systems should be
considered then. What do you do with systems (laptops f.ex.) that sleep
when a cron job would be triggered or that are not connected to the
internet at that time? One could look into systemd's timer mechanisms if
the support being deferred until the system wakes up and is connected to
the internet.
*t
Francois Marier
Sep 17, 2021, 2:10:03 AM9/17/21
to
On 2021-09-16 at 22:38:27, Tomas Pospisek (t...@sourcepole.ch) wrote:
> An alternative approach could be that an `apt update` would trigger an
> `extrepo update`.
That's an interesting idea. I also don't know how feasible that is.
> An alternative approach could be that an `apt update` would trigger an
> `extrepo update`.
> What do you do with systems (laptops f.ex.) that sleep when a cron job
> would be triggered
Francois
--
https://fmarier.org/
0 new messages