| 2020-06-09 10:44:52 |
Andy Whitcroft |
description |
Custom binary uploads are not tracked as first class objects and so are not
correctly removed when the owning source publication is removed. This is
particularly obvious when we open a new series. As we have no tracking for
these we publish all custom uploads which were in the previous series into the
new series. For signing/efi custom uploads this is significant as the act of
publication triggers the signing process. This leads us to sign all existing
signing/efi objects again into the new series and therefore with the
contemporaneous keys in that series. Where the package was completely deleted
in the preceeding series or the preceeding series was signed with a different
key set this leads us to sign stale binaries with these keys. This is a
significant risk for these keys.
If we cannot fix this before the next opening we need to ensure any such signed
binaries are removed from the archive before it becomes public. |
Custom binary uploads are not tracked as first class objects and so are not correctly removed when the owning source publication is removed. This is particularly obvious when we open a new series. As we have no tracking for these we publish all custom uploads which were in the previous series into the new series. For signing/efi custom uploads this is significant as the act of publication triggers the signing process. This leads us to sign all existing signing/efi objects again into the new series and therefore with the contemporaneous keys in that series. Where the package was completely deleted in the preceeding series or the preceeding series was signed with a different key set this leads us to sign stale binaries with these keys. This is a significant risk for these keys.
If we cannot fix this before the next opening we need to ensure any such signed binaries are removed from the archive before it becomes public. |
|
