Please put the complete date of the security patch date in the release notes

[olli0371]

Hi,

in your release notes it just says :

Security fixes

This /e/OS 3.0.4 version includes the Android security patches available as of June 2025.

Please give the complete date in the documentation as this is important for the anti rollback feature that may brick the phone.

Example:
e/OS Version 3.04 has the patch date of 01.06.2025
Latest Fairphone OS has the patch date 05.06.2025

In this case i can not lock the bootloader as the e/OS patchdate is older than the official FairphoneOS that was installed previously.

I needed to install several tools to extract the flashfile to find this out. Please put the exact date into the documentation - would be very helpfull and cost no efford.

Thank you
Oliver

Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online services

[Manoj]

@olli0371

Please put the exact date into the documentation

Have passed on the feedback to the team.

[aibd]

I have added the tag documentation-inputs @Manoj.

Since about early this year there has been a change in the way that the Android Security Bulletins https://source.android.com/docs/security/bulletin/2025-06-01 are dated as per example in OP.

How does this affect users in the “Can I lock my Fairphone” decision ?

Does the Anti rollback index rely on

• day - month - year
• or is the month of the Android SPL sufficient?

[tcecyk]

@aibd

Since about early this year there has been a change in the way that the Android Security Bulletins are dated

if you mean the 1st vs 5th of date distinction framework vs vendor, it was introduced July 2016 or even earlier

examples of ril index integers I’ve seen are unix epoch derived from the date, so the full date matters

[aibd]

Thanks for the clarification. Sloppy wording on my part but I guess I was just drawing attention to the bulletin’s date of publication where I gave a recent example of the bulletin itself containing the date 01-06-2025.

It seemed to me as if Google have become more upfront about dating as many of us have got used to seeing Android SPL consistently 5th of the month until more recently.

[tcecyk]

the implicit meaning of what the OP presents is: /e/ v3.0.4 doesn’t include the vendor firmware partition updates that fairphone currently ships. Or one forgot to set the string.

[fietje]

I struggle with assessing how out of date (or not) /e/OS is for the different Fairphones… how would one properly assess this?

Also, one step further, if Fairphone provides security updates, it does mean all base hardware issues should be addressed, right? So as long as Fairphone still supports the device (update latency notwithstanding), the device should be patched, right?

[tcecyk]

@fietje

how would one properly assess this?

“assessing”: SPL dates aren’t inherently wrong though intransparent. There was a CVE checker that did analysis on-device (SnoopSnitch), but I don’t think its kept updated.

“the device should be patched”: someone at /e/ has to bundle the firmware, do kernel vendor fixes, it’s not automatic

[fietje]

Yes, alright.

Assuming Fairphone pushes out a new FP OS version, and /e/OS gets the relevant bits from there, we’re ok?

[tcecyk]

if you want to dig into it, look at the device kernel repo, firmware version strings and framework base. But it is another thread. This here is just about some help in knowing the SPL of the image offered to prevent rollback bricks.

[fietje]

@tcecyk

But it is another thread.

How very right you are.

[aibd]

@tcecyk

the implicit meaning of what the OP presents

Seemed to me relating to the June Security Bulletin where wording includes

which to my mind leads to uncertainty which I would hope can be addressed within documentation-inputs

[Robin_A]

Hello aibd, 1st thank you for the time you took to instruct beginners like us. I have been reading about this on several threads of e and fairphone forums. Did you get the answer on the “should we try to lock if the old version is lets say “October the 5st” and the e version we flash is “October the 1st” ? I saw several contradictory replies on this and perhaps you had updated information.

[aibd]

Hi @Robin_A welcome to the /e/ users forum.

The answer is that you must not roll back … or “Never go back”

Your example is a roll back:

the old version “October the 5st”
e version is “October the 1st”

(With this build one must wait till the next release 3.3 expected this week.

[Robin_A]

Ok thanks that clarifies the issue. I had seen someone saying it worked for them and they managed to put a e os 5 days older in security patch. But maybe they missed something or it happened as an exception.

In anycase, thank you a lot

[aibd]

The four day thing is rather new … if one wants to study more there are links to the Security Bulletins in this post.

@aibd

This is a new hazard which maybe started

However the hazard only comes with Locking the Bootloader. Locking requires that the system has full integrity so I see no real point in experimenting with the hazard if you want to lock.

However no lock, no worry.

[mihi]

For me this one is also a bit 2 sided:

fastboot flashing get_unlock_ability

Once it gave positiv feedback and yet it resulted in bootloop after locking. Just to add to ‘experimenting with locking’.

[aibd]

That command has a different purpose. It does not help to confirm the dates. It does not ask for the stored index.

As said it gets unlock_ability.

This is not Lock Ability but it does happen to check the device state [1] and indicates locking will be ok if dates are right.

[1] OP prior experience

[mihi]

Now I feel stupid never actually read and processed in my head that it is ‘unlock ability’ and not ‘lock ability’

[mihi]

In the release notes for 3.3 there is an info for FP6:
‘Rollback date is now aligned with Fairphone’s’.

Now the mlnth is only relevant or…?

I can’t check security patch yet since I am still on community v3.2. Waiting couple days before I update