[isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Shivanand.Kunijadar]

From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>

Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162

Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
---
 .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
index 263f794..6a5357d 100644
--- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
+++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
@@ -24,6 +24,12 @@ DPKG_ARCH = "all"
 
 do_prepare_build() {
     deb_debianize
+    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
+        timestamp="$(TZ=UTC date -d @${SOURCE_DATE_EPOCH} '+%Y-%m-%d %H:%M:%S')"
+        timestamp_opt="-t \"$timestamp\""
+    else
+        timestamp_opt=""
+    fi
 
     cat <<EOF > ${S}/debian/${BPN}.install
 db.auth usr/share/secure-boot-efi-certs
@@ -35,7 +41,7 @@ EOF
 
 override_dh_auto_build:
 	cert-to-efi-sig-list /usr/share/secure-boot-secrets/secure-boot.pem PK.esl
-	sign-efi-sig-list -k /usr/share/secure-boot-secrets/secure-boot.key \
+	sign-efi-sig-list ${timestamp_opt} -k /usr/share/secure-boot-secrets/secure-boot.key \
 	    -c /usr/share/secure-boot-secrets/secure-boot.pem PK PK.esl PK.auth
 	cp PK.auth KEK.auth
 	cp PK.auth db.auth
-- 
2.39.5

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[MOESSBAUER, Felix]

On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> 
> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
> 
> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> ---
>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> index 263f794..6a5357d 100644
> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>  
>  do_prepare_build() {
>      deb_debianize
> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then

Good catch! Thanks for debugging this. Please just use
DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
available and aligns the timestamp of SB parts with the one from the
changelog.

Felix

> +        timestamp="$(TZ=UTC date -d @${SOURCE_DATE_EPOCH} '+%Y-%m-%d %H:%M:%S')"
> +        timestamp_opt="-t \"$timestamp\""
> +    else
> +        timestamp_opt=""
> +    fi
>  
>      cat <<EOF > ${S}/debian/${BPN}.install
>  db.auth usr/share/secure-boot-efi-certs
> @@ -35,7 +41,7 @@ EOF
>  
>  override_dh_auto_build:
>  	cert-to-efi-sig-list /usr/share/secure-boot-secrets/secure-boot.pem PK.esl
> -	sign-efi-sig-list -k /usr/share/secure-boot-secrets/secure-boot.key \
> +	sign-efi-sig-list ${timestamp_opt} -k /usr/share/secure-boot-secrets/secure-boot.key \
>  	    -c /usr/share/secure-boot-secrets/secure-boot.pem PK PK.esl PK.auth
>  	cp PK.auth KEK.auth
>  	cp PK.auth db.auth
> -- 
> 2.39.5

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Jan Kiszka]

On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>
>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>
>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>> ---
>>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>> index 263f794..6a5357d 100644
>> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>  
>>  do_prepare_build() {
>>      deb_debianize
>> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> 
> Good catch! Thanks for debugging this. Please just use
> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
> available and aligns the timestamp of SB parts with the one from the
> changelog.
> 

And simpler code - even better.

Thanks for debugging my bug! :)

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[MOESSBAUER, Felix]

On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
> > > From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > 
> > > Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
> > > 
> > > Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > ---
> > >  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > index 263f794..6a5357d 100644
> > > --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
> > >  
> > >  do_prepare_build() {
> > >      deb_debianize
> > > +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> > 
> > Good catch! Thanks for debugging this. Please just use
> > DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
> > available and aligns the timestamp of SB parts with the one from the
> > changelog.
> > 
> 
> And simpler code - even better.
> 
> Thanks for debugging my bug! :)

While thinking about it, I'm wondering if the timestamp actually has
security relevance (e.g. for checking the freshness of the DB). I know
that timestamps in general are pointless in this context, but I'm
wondering why it can be set in the first place.

The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
(for technical reasons 0 cannot be used as this is "magic").

If we need a proper timestamp here, we should provide a way to set the
DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
variable).

But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
changelog timestamp with the SB one.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

Re: [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Kunijadar Shivanand]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On Fri, Sep 18, 2026 at 04:21 AM, Felix Moessbauer wrote:

> 
> On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
> 
>> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>> 
>>> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>>> 
>>>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>> 
>>>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>>> 
>>>> 
>>>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>> ---
>>>> .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git
>>>> a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> index 263f794..6a5357d 100644
>>>> ---
>>>> a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> +++
>>>> b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>>> 
>>>> do_prepare_build() {
>>>> deb_debianize
>>>> + if [ -n "${SOURCE_DATE_EPOCH}" ]; then
>>> 
>>> Good catch! Thanks for debugging this. Please just use
>>> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
>>> available and aligns the timestamp of SB parts with the one from the
>>> changelog.
>> 
>> 
> 
> 

Thanks, sent v2 patch to use DEBIAN_CHANGELOG_TIMESTAMP instead of SDE.

> 
> 
>> And simpler code - even better.
>> 
>> Thanks for debugging my bug! :)
> 
> 

Thanks, the v2 patch has a simpler code now, removed condition check.
The recipe is updated to use timestamp option by default.

> 
> While thinking about it, I'm wondering if the timestamp actually has
> security relevance (e.g. for checking the freshness of the DB). I know
> that timestamps in general are pointless in this context, but I'm
> wondering why it can be set in the first place.
> 
> The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
> (for technical reasons 0 cannot be used as this is "magic").
> 
> If we need a proper timestamp here, we should provide a way to set the
> DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
> variable).
> 
> But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
> changelog timestamp with the SB one.
> 
> Felix

Thanks & Regards
Shivanand K

[-- Attachment #2: Type: text/html, Size: 2877 bytes --]

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Jan Kiszka]

On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
>> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>>>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>
>>>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>>>
>>>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>> ---
>>>>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> index 263f794..6a5357d 100644
>>>> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>>>  
>>>>  do_prepare_build() {
>>>>      deb_debianize
>>>> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
>>>
>>> Good catch! Thanks for debugging this. Please just use
>>> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
>>> available and aligns the timestamp of SB parts with the one from the
>>> changelog.
>>>
>>
>> And simpler code - even better.
>>
>> Thanks for debugging my bug! :)
> 
> While thinking about it, I'm wondering if the timestamp actually has
> security relevance (e.g. for checking the freshness of the DB). I know
> that timestamps in general are pointless in this context, but I'm
> wondering why it can be set in the first place.
> 
> The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
> (for technical reasons 0 cannot be used as this is "magic").
> 
> If we need a proper timestamp here, we should provide a way to set the
> DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
> variable).
> 
> But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
> changelog timestamp with the SB one.
> 

This has security implication because the timestamping of the signature
may be compared to the revocation time in case the signer's cert is
revoked. Signatures that happened before the revocation time will then
still be accepted, those afterwards won't. Therefore, this timestamp may
have to reflect the actual signature time. And this is obviously
complicating reproducibility.

I would vote for making this package (and possibly similar ones)
reproducible to become an opt-in feature that we enable only for the
related test. Or only for snakeoil keys. Maybe the latter is simplest.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[MOESSBAUER, Felix]

On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
> On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
> > > On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
> > > > > From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > 
> > > > > Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
> > > > > 
> > > > > Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > ---
> > > > >  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
> > > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > index 263f794..6a5357d 100644
> > > > > --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
> > > > >  
> > > > >  do_prepare_build() {
> > > > >      deb_debianize
> > > > > +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> > > > 
> > > > Good catch! Thanks for debugging this. Please just use
> > > > DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
> > > > available and aligns the timestamp of SB parts with the one from the
> > > > changelog.
> > > > 
> > > 
> > > And simpler code - even better.
> > > 
> > > Thanks for debugging my bug! :)
> > 
> > While thinking about it, I'm wondering if the timestamp actually has
> > security relevance (e.g. for checking the freshness of the DB). I know
> > that timestamps in general are pointless in this context, but I'm
> > wondering why it can be set in the first place.
> > 
> > The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
> > (for technical reasons 0 cannot be used as this is "magic").
> > 
> > If we need a proper timestamp here, we should provide a way to set the
> > DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
> > variable).
> > 
> > But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
> > changelog timestamp with the SB one.
> > 
> 
> This has security implication because the timestamping of the signature
> may be compared to the revocation time in case the signer's cert is
> revoked. Signatures that happened before the revocation time will then
> still be accepted, those afterwards won't. Therefore, this timestamp may
> have to reflect the actual signature time. And this is obviously
> complicating reproducibility.

This is not just complicating reproducibility, but is in general
problematic:

The packages we generate must at least be "logically reproducible" i.e.
the behavior must not change across builds - which it clearly does in
this case. Otherwise this package must be excluded from sstate caching,
which also means all downstream tasks cannot be cached (until we have
hash equivalence support, which then partially heals this).

> 
> I would vote for making this package (and possibly similar ones)
> reproducible to become an opt-in feature that we enable only for the
> related test. Or only for snakeoil keys. Maybe the latter is simplest.

No. Please just add variables which can be set from local.conf to pin
the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
chosen timestamp. Updates of the timestamp must be explicit. This
means, we are still 100% reproducible and perfectly cachable until this
value is explicitly changed by the user.

This of course also needs to be documented.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Jan Kiszka]

On 21.09.26 09:37, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
>> On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
>>>> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>>>>>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>>
>>>>>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>>>>>
>>>>>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>> ---
>>>>>>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>>>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>> index 263f794..6a5357d 100644
>>>>>> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>>>>>  
>>>>>>  do_prepare_build() {
>>>>>>      deb_debianize
>>>>>> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
>>>>>
>>>>> Good catch! Thanks for debugging this. Please just use
>>>>> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
>>>>> available and aligns the timestamp of SB parts with the one from the
>>>>> changelog.
>>>>>
>>>>
>>>> And simpler code - even better.
>>>>
>>>> Thanks for debugging my bug! :)
>>>
>>> While thinking about it, I'm wondering if the timestamp actually has
>>> security relevance (e.g. for checking the freshness of the DB). I know
>>> that timestamps in general are pointless in this context, but I'm
>>> wondering why it can be set in the first place.
>>>
>>> The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
>>> (for technical reasons 0 cannot be used as this is "magic").
>>>
>>> If we need a proper timestamp here, we should provide a way to set the
>>> DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
>>> variable).
>>>
>>> But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
>>> changelog timestamp with the SB one.
>>>
>>
>> This has security implication because the timestamping of the signature
>> may be compared to the revocation time in case the signer's cert is
>> revoked. Signatures that happened before the revocation time will then
>> still be accepted, those afterwards won't. Therefore, this timestamp may
>> have to reflect the actual signature time. And this is obviously
>> complicating reproducibility.
> 
> This is not just complicating reproducibility, but is in general
> problematic:
> 
> The packages we generate must at least be "logically reproducible" i.e.
> the behavior must not change across builds - which it clearly does in
> this case. Otherwise this package must be excluded from sstate caching,
> which also means all downstream tasks cannot be cached (until we have
> hash equivalence support, which then partially heals this).
> 
>>
>> I would vote for making this package (and possibly similar ones)
>> reproducible to become an opt-in feature that we enable only for the
>> related test. Or only for snakeoil keys. Maybe the latter is simplest.
> 
> No. Please just add variables which can be set from local.conf to pin
> the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
> chosen timestamp. Updates of the timestamp must be explicit. This
> means, we are still 100% reproducible and perfectly cachable until this
> value is explicitly changed by the user.
> 
> This of course also needs to be documented.

Sure, but I disagree on having such a variable for production. It's most
often wrong if a user ever runs it with a pinned timestamp for real key.
So better not even expose what will be security-wise incorrect.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[MOESSBAUER, Felix]

On Mon, 2026-09-21 at 09:49 +0200, Jan Kiszka wrote:
> On 21.09.26 09:37, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
> > > On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
> > > > > On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > > > On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
> > > > > > > From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > > > 
> > > > > > > Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
> > > > > > > 
> > > > > > > Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > > > ---
> > > > > > >  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
> > > > > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > index 263f794..6a5357d 100644
> > > > > > > --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
> > > > > > >  
> > > > > > >  do_prepare_build() {
> > > > > > >      deb_debianize
> > > > > > > +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> > > > > > 
> > > > > > Good catch! Thanks for debugging this. Please just use
> > > > > > DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
> > > > > > available and aligns the timestamp of SB parts with the one from the
> > > > > > changelog.
> > > > > > 
> > > > > 
> > > > > And simpler code - even better.
> > > > > 
> > > > > Thanks for debugging my bug! :)
> > > > 
> > > > While thinking about it, I'm wondering if the timestamp actually has
> > > > security relevance (e.g. for checking the freshness of the DB). I know
> > > > that timestamps in general are pointless in this context, but I'm
> > > > wondering why it can be set in the first place.
> > > > 
> > > > The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
> > > > (for technical reasons 0 cannot be used as this is "magic").
> > > > 
> > > > If we need a proper timestamp here, we should provide a way to set the
> > > > DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
> > > > variable).
> > > > 
> > > > But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
> > > > changelog timestamp with the SB one.
> > > > 
> > > 
> > > This has security implication because the timestamping of the signature
> > > may be compared to the revocation time in case the signer's cert is
> > > revoked. Signatures that happened before the revocation time will then
> > > still be accepted, those afterwards won't. Therefore, this timestamp may
> > > have to reflect the actual signature time. And this is obviously
> > > complicating reproducibility.
> > 
> > This is not just complicating reproducibility, but is in general
> > problematic:
> > 
> > The packages we generate must at least be "logically reproducible" i.e.
> > the behavior must not change across builds - which it clearly does in
> > this case. Otherwise this package must be excluded from sstate caching,
> > which also means all downstream tasks cannot be cached (until we have
> > hash equivalence support, which then partially heals this).
> > 
> > > 
> > > I would vote for making this package (and possibly similar ones)
> > > reproducible to become an opt-in feature that we enable only for the
> > > related test. Or only for snakeoil keys. Maybe the latter is simplest.
> > 
> > No. Please just add variables which can be set from local.conf to pin
> > the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
> > chosen timestamp. Updates of the timestamp must be explicit. This
> > means, we are still 100% reproducible and perfectly cachable until this
> > value is explicitly changed by the user.
> > 
> > This of course also needs to be documented.
> 
> Sure, but I disagree on having such a variable for production. It's most
> often wrong if a user ever runs it with a pinned timestamp for real key.
> So better not even expose what will be security-wise incorrect.

Hmm... A user that adds secure boot support to his image MUST know what
he is doing. We can't "hide" all the complexity.

What are the alternatives? We can't safely use a floating timestamp.
This makes things even more incorrect in most cases. Along with the
global variable, we could issue a notice regarding the used timestamp.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Jan Kiszka]

On 21.09.26 09:53, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Mon, 2026-09-21 at 09:49 +0200, Jan Kiszka wrote:
>> On 21.09.26 09:37, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
>>>> On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>> On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
>>>>>> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>>>> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>>>>>>>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>>>>
>>>>>>>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>>>>>>>
>>>>>>>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>>>> ---
>>>>>>>>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>>>>>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>> index 263f794..6a5357d 100644
>>>>>>>> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>>>>>>>  
>>>>>>>>  do_prepare_build() {
>>>>>>>>      deb_debianize
>>>>>>>> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
>>>>>>>
>>>>>>> Good catch! Thanks for debugging this. Please just use
>>>>>>> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
>>>>>>> available and aligns the timestamp of SB parts with the one from the
>>>>>>> changelog.
>>>>>>>
>>>>>>
>>>>>> And simpler code - even better.
>>>>>>
>>>>>> Thanks for debugging my bug! :)
>>>>>
>>>>> While thinking about it, I'm wondering if the timestamp actually has
>>>>> security relevance (e.g. for checking the freshness of the DB). I know
>>>>> that timestamps in general are pointless in this context, but I'm
>>>>> wondering why it can be set in the first place.
>>>>>
>>>>> The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
>>>>> (for technical reasons 0 cannot be used as this is "magic").
>>>>>
>>>>> If we need a proper timestamp here, we should provide a way to set the
>>>>> DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
>>>>> variable).
>>>>>
>>>>> But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
>>>>> changelog timestamp with the SB one.
>>>>>
>>>>
>>>> This has security implication because the timestamping of the signature
>>>> may be compared to the revocation time in case the signer's cert is
>>>> revoked. Signatures that happened before the revocation time will then
>>>> still be accepted, those afterwards won't. Therefore, this timestamp may
>>>> have to reflect the actual signature time. And this is obviously
>>>> complicating reproducibility.
>>>
>>> This is not just complicating reproducibility, but is in general
>>> problematic:
>>>
>>> The packages we generate must at least be "logically reproducible" i.e.
>>> the behavior must not change across builds - which it clearly does in
>>> this case. Otherwise this package must be excluded from sstate caching,
>>> which also means all downstream tasks cannot be cached (until we have
>>> hash equivalence support, which then partially heals this).
>>>
>>>>
>>>> I would vote for making this package (and possibly similar ones)
>>>> reproducible to become an opt-in feature that we enable only for the
>>>> related test. Or only for snakeoil keys. Maybe the latter is simplest.
>>>
>>> No. Please just add variables which can be set from local.conf to pin
>>> the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
>>> chosen timestamp. Updates of the timestamp must be explicit. This
>>> means, we are still 100% reproducible and perfectly cachable until this
>>> value is explicitly changed by the user.
>>>
>>> This of course also needs to be documented.
>>
>> Sure, but I disagree on having such a variable for production. It's most
>> often wrong if a user ever runs it with a pinned timestamp for real key.
>> So better not even expose what will be security-wise incorrect.
> 
> Hmm... A user that adds secure boot support to his image MUST know what
> he is doing. We can't "hide" all the complexity.
> 
> What are the alternatives? We can't safely use a floating timestamp.
> This makes things even more incorrect in most cases. Along with the
> global variable, we could issue a notice regarding the used timestamp.

As I proposed: Demo keys can be signed with pinned timestamp. Regular
signing must have the timestamp of the action to reflect when this
happened. Otherwise, you risk to resign something with a date that is
older than the meanwhile declared revocation time.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[MOESSBAUER, Felix]

On Mon, 2026-09-21 at 09:59 +0200, Jan Kiszka wrote:
> On 21.09.26 09:53, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Mon, 2026-09-21 at 09:49 +0200, Jan Kiszka wrote:
> > > On 21.09.26 09:37, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
> > > > > On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > > > On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
> > > > > > > On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > > > > > > > On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
> > > > > > > > > From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > > > > > 
> > > > > > > > > Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
> > > > > > > > > ---
> > > > > > > > >  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
> > > > > > > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > > > index 263f794..6a5357d 100644
> > > > > > > > > --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > > > +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
> > > > > > > > > @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
> > > > > > > > >  
> > > > > > > > >  do_prepare_build() {
> > > > > > > > >      deb_debianize
> > > > > > > > > +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
> > > > > > > > 
> > > > > > > > Good catch! Thanks for debugging this. Please just use
> > > > > > > > DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
> > > > > > > > available and aligns the timestamp of SB parts with the one from the
> > > > > > > > changelog.
> > > > > > > > 
> > > > > > > 
> > > > > > > And simpler code - even better.
> > > > > > > 
> > > > > > > Thanks for debugging my bug! :)
> > > > > > 
> > > > > > While thinking about it, I'm wondering if the timestamp actually has
> > > > > > security relevance (e.g. for checking the freshness of the DB). I know
> > > > > > that timestamps in general are pointless in this context, but I'm
> > > > > > wondering why it can be set in the first place.
> > > > > > 
> > > > > > The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
> > > > > > (for technical reasons 0 cannot be used as this is "magic").
> > > > > > 
> > > > > > If we need a proper timestamp here, we should provide a way to set the
> > > > > > DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
> > > > > > variable).
> > > > > > 
> > > > > > But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
> > > > > > changelog timestamp with the SB one.
> > > > > > 
> > > > > 
> > > > > This has security implication because the timestamping of the signature
> > > > > may be compared to the revocation time in case the signer's cert is
> > > > > revoked. Signatures that happened before the revocation time will then
> > > > > still be accepted, those afterwards won't. Therefore, this timestamp may
> > > > > have to reflect the actual signature time. And this is obviously
> > > > > complicating reproducibility.
> > > > 
> > > > This is not just complicating reproducibility, but is in general
> > > > problematic:
> > > > 
> > > > The packages we generate must at least be "logically reproducible" i.e.
> > > > the behavior must not change across builds - which it clearly does in
> > > > this case. Otherwise this package must be excluded from sstate caching,
> > > > which also means all downstream tasks cannot be cached (until we have
> > > > hash equivalence support, which then partially heals this).
> > > > 
> > > > > 
> > > > > I would vote for making this package (and possibly similar ones)
> > > > > reproducible to become an opt-in feature that we enable only for the
> > > > > related test. Or only for snakeoil keys. Maybe the latter is simplest.
> > > > 
> > > > No. Please just add variables which can be set from local.conf to pin
> > > > the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
> > > > chosen timestamp. Updates of the timestamp must be explicit. This
> > > > means, we are still 100% reproducible and perfectly cachable until this
> > > > value is explicitly changed by the user.
> > > > 
> > > > This of course also needs to be documented.
> > > 
> > > Sure, but I disagree on having such a variable for production. It's most
> > > often wrong if a user ever runs it with a pinned timestamp for real key.
> > > So better not even expose what will be security-wise incorrect.
> > 
> > Hmm... A user that adds secure boot support to his image MUST know what
> > he is doing. We can't "hide" all the complexity.
> > 
> > What are the alternatives? We can't safely use a floating timestamp.
> > This makes things even more incorrect in most cases. Along with the
> > global variable, we could issue a notice regarding the used timestamp.
> 
> As I proposed: Demo keys can be signed with pinned timestamp. Regular
> signing must have the timestamp of the action to reflect when this
> happened. Otherwise, you risk to resign something with a date that is
> older than the meanwhile declared revocation time.

Fully agree, but my point is that the time of the action is not
predictable if you build with sstate cache (if the artifact is taken
from the cache, it has the old date). This time explicitly needs to be
set somewhere to end up in the bitbake hashes. And as only the user can
know what time is desired, we must make it explicit.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

Re: [cip-dev] [isar-cip-core][PATCH] Fix file timestamps are not reproducible for EFI certificates

[Jan Kiszka]

On 21.09.26 10:07, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Mon, 2026-09-21 at 09:59 +0200, Jan Kiszka wrote:
>> On 21.09.26 09:53, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Mon, 2026-09-21 at 09:49 +0200, Jan Kiszka wrote:
>>>> On 21.09.26 09:37, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>> On Mon, 2026-09-21 at 07:16 +0200, Jan Kiszka wrote:
>>>>>> On 18.09.26 13:21, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>>>> On Fri, 2026-09-18 at 13:01 +0200, Jan Kiszka wrote:
>>>>>>>> On 18.09.26 12:54, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>>>>>>>> On Fri, 2026-09-18 at 14:20 +0530, Kunijadar Shivanand wrote:
>>>>>>>>>> From: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>>>>>>
>>>>>>>>>> Closes https://gitlab.com/cip-project/cip-core/isar-cip-core/-/work_items/162
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Shivanand Kunijadar <Shivanand.Kunijadar@toshiba-tsip.com>
>>>>>>>>>> ---
>>>>>>>>>>  .../secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb  | 8 +++++++-
>>>>>>>>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>>>> index 263f794..6a5357d 100644
>>>>>>>>>> --- a/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>>>> +++ b/recipes-devtools/secure-boot-efi-certs/single-key-to-efi-certs_0.1.bb
>>>>>>>>>> @@ -24,6 +24,12 @@ DPKG_ARCH = "all"
>>>>>>>>>>  
>>>>>>>>>>  do_prepare_build() {
>>>>>>>>>>      deb_debianize
>>>>>>>>>> +    if [ -n "${SOURCE_DATE_EPOCH}" ]; then
>>>>>>>>>
>>>>>>>>> Good catch! Thanks for debugging this. Please just use
>>>>>>>>> DEBIAN_CHANGELOG_TIMESTAMP instead of the SDE. This variable is always
>>>>>>>>> available and aligns the timestamp of SB parts with the one from the
>>>>>>>>> changelog.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And simpler code - even better.
>>>>>>>>
>>>>>>>> Thanks for debugging my bug! :)
>>>>>>>
>>>>>>> While thinking about it, I'm wondering if the timestamp actually has
>>>>>>> security relevance (e.g. for checking the freshness of the DB). I know
>>>>>>> that timestamps in general are pointless in this context, but I'm
>>>>>>> wondering why it can be set in the first place.
>>>>>>>
>>>>>>> The DEBIAN_CHANGELOG_TIMESTAMP usually is set to 1h after unix epoch
>>>>>>> (for technical reasons 0 cannot be used as this is "magic").
>>>>>>>
>>>>>>> If we need a proper timestamp here, we should provide a way to set the
>>>>>>> DEBIAN_CHANGELOG_TIMESTAMP just for that package (e.g. by introducing a
>>>>>>> variable).
>>>>>>>
>>>>>>> But still, the code should use DEBIAN_CHANGELOG_TIMESTAMP to align the
>>>>>>> changelog timestamp with the SB one.
>>>>>>>
>>>>>>
>>>>>> This has security implication because the timestamping of the signature
>>>>>> may be compared to the revocation time in case the signer's cert is
>>>>>> revoked. Signatures that happened before the revocation time will then
>>>>>> still be accepted, those afterwards won't. Therefore, this timestamp may
>>>>>> have to reflect the actual signature time. And this is obviously
>>>>>> complicating reproducibility.
>>>>>
>>>>> This is not just complicating reproducibility, but is in general
>>>>> problematic:
>>>>>
>>>>> The packages we generate must at least be "logically reproducible" i.e.
>>>>> the behavior must not change across builds - which it clearly does in
>>>>> this case. Otherwise this package must be excluded from sstate caching,
>>>>> which also means all downstream tasks cannot be cached (until we have
>>>>> hash equivalence support, which then partially heals this).
>>>>>
>>>>>>
>>>>>> I would vote for making this package (and possibly similar ones)
>>>>>> reproducible to become an opt-in feature that we enable only for the
>>>>>> related test. Or only for snakeoil keys. Maybe the latter is simplest.
>>>>>
>>>>> No. Please just add variables which can be set from local.conf to pin
>>>>> the DEBIAN_CHANGELOG_TIMESTAMP of exactly these packages to a user
>>>>> chosen timestamp. Updates of the timestamp must be explicit. This
>>>>> means, we are still 100% reproducible and perfectly cachable until this
>>>>> value is explicitly changed by the user.
>>>>>
>>>>> This of course also needs to be documented.
>>>>
>>>> Sure, but I disagree on having such a variable for production. It's most
>>>> often wrong if a user ever runs it with a pinned timestamp for real key.
>>>> So better not even expose what will be security-wise incorrect.
>>>
>>> Hmm... A user that adds secure boot support to his image MUST know what
>>> he is doing. We can't "hide" all the complexity.
>>>
>>> What are the alternatives? We can't safely use a floating timestamp.
>>> This makes things even more incorrect in most cases. Along with the
>>> global variable, we could issue a notice regarding the used timestamp.
>>
>> As I proposed: Demo keys can be signed with pinned timestamp. Regular
>> signing must have the timestamp of the action to reflect when this
>> happened. Otherwise, you risk to resign something with a date that is
>> older than the meanwhile declared revocation time.
> 
> Fully agree, but my point is that the time of the action is not
> predictable if you build with sstate cache (if the artifact is taken
> from the cache, it has the old date). This time explicitly needs to be
> set somewhere to end up in the bitbake hashes. And as only the user can
> know what time is desired, we must make it explicit.

IOW: Production-signing packages must not be cached.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center