brefphp
Preliminary work to compile on Amazon Linux 2023
AL2023 is eventually going to happen. Out of curiosity, I drafted this PR trying to build our layers for AL2023.
It removes a lot of custom system libraries we compile because AL2023 contains more recent versions: https://docs.aws.amazon.com/linux/al2023/release-notes/all-packages-AL2023.1.html
We'll need to reevaluate when we actually get AL2023 Lambda images (right now we have the generic AL2023, not specific to Lambda), but it is looking good.
I'm opening this PR to gather early feedback and see if I'm missing something.
@GrahamCampbell that wasn't long :) https://github.com/aws/aws-lambda-base-images/issues/92
Ha, it's not available on the Lambda APIs and cloudformation yet. ;)
Thanks so much for jumping in the discussion @stewartsmith.
There is some balance that we need to find.
Would it be reasonable to apply the following logic:
- When we need specific features (random example: HTTP3 support in curl) that are not present in AL2023, we recompile the libraries
- The rest of the time, we rely on AL2023 versions for CVEs and security fixes
Is that reasonable enough? Can we assume that all CVEs are patched in AL2023 eventually? (I understand it may take a few hours/days depending on the issue)
The benefits of that approach would be:
- our compilation scripts are simpler
- our layers might potentially be lighter (faster cold starts)
- security fixes are delivered in the Lambda OS, not via a new version of the Bref layers -> for most Bref users, that means that security fixes are actually applied faster, because most Bref users don't necessarily update Bref layers every week or so (meaning they are actually using older unpatched system libraries provided by Bref).
WDYT?
Building anything from source and replacing an OS component with it carries various risks. Naturally it means you have to keep it updated, but there's also the nuance of building it with the same hardening and optimisations as the one in the OS, and ensuring ABI compatibility with the one in the OS. It's not something we recommend doing.
It is (of course) something which is possible to do, as it's basically what we do all the time when building updates for the OS. From a "does the Amazon Linux team support this" standpoint, replacing core system libraries falls into "can you reproduce the issue without that change" territory - i.e. a freedom that Free and Open Source Software gives you, but the vendor doesn't necessarily provide support for if you pick up the (metaphorical or literal) phone.
I would recommend building RPMs instead of manually from source tarballs though, as that way you capture all the hardening and optimization flags that are added in the RPM macros.
In Amazon Linux, security is job zero. We do fix security issues of all severity, and aim to do so not just in the most recent major version of the OS. The places where don't patch something basically boils down to risk outweighing the benefit - such as Low CVEs that are a quite invasive fix that we can't reasonably bring in without creating other, more severe issues.
Thanks a lot @stewartsmith for chiming in. I've taken some time to think about it, and also discuss this with a few Bref users. For example I discussed this topic with a bank running on Bref (i.e. they have huge security constraints).
The feedback was quite simple: if we build our own versions, we (Bref project) are responsible for the security related to those libraries. If we don't, AWS is.
To summarize:
- Bref users looking for strong security guarantees will usually prefer to delegate as much as possible to AWS (https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/the-shared-responsibility-model.html). This allows ticking a lot of boxes.
- Additionally, most Bref users will not update the runtime versions frequently enough, leaving them more exposed to CVEs and security issues (in the case where we build libraries). By using system libraries instead, AWS is able to patch the underlying runtime automatically, which gives a more secure environment.
That leads me to conclude that we should aim to compile as few libraries as possible. This will benefit both extremes of the spectrum: users with strong security requirements and those that don't update frequently (i.e. care less about security, if I can say so).
The downside is that we have no way to control the frequency/speed at which AWS patches security issues. This basically means putting more trust into AWS over Bref regarding security, and I think that is a reasonable choice 😅
This PR is still WIP, but I'll be slowly updating it to reflect that. I.e. the build scripts should be simpler with AL2023 than AL2.
Also since we'll want to support both, I'll probably reorganize the code entirely. We will also likely not support PHP 8.0 with AL2023.
Hello, Thank you for your continuous work on the Bref project. It seems this ticket has been postponed for a little bit while. I'm interested in how long Amazon Linux 2023 will be supported. And is there any key milestones or timelines related to this support?
Amazon Linux 2023 will be supported officially until 2027. However every 2 years Amazon will release a new major version. So in 2025 there will be the release of Amazon Linux 2025, which in turn will be supported until 2029 etc. See their release cadence: https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html
Amazon Linux 2023 will be supported officially until 2027. However every 2 years Amazon will release a new major version. So in 2025 there will be the release of Amazon Linux 2025, which in turn will be supported until 2029 etc. See their release cadence: https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html
Thank you for answering my question. Sorry about not asking question clearly.
I want to know the schedual that brefphp/aws-lambda-layers support Amazon Linux 2023 which this ticket was working on (If I'm not misunderstanding).
Because I found that that brefphp/aws-lambda-layers only suppot amazon linux 2(provided.al2).
See the capture below (I get this capture from Lambda function which I deployed)
Hi! I have made progress on this offline (not pushed here). This is definitely in my TODO list, though not the most urgent because AL2 works well and is supported by Amazon. But this is not something I have forgotten about or abandoned 👍
Hi! I have made progress on this offline (not pushed here). This is definitely in my TODO list, though not the most urgent because AL2 works well and is supported by Amazon. But this is not something I have forgotten about or abandoned 👍
Thank you for your reply.
There was a discussion in Slack but to update here: this is in my TODO, this is related to many other changes with Bref v3 that's why it's progressing seemingly slowly.
We run nodejs on the same machine as bref and modern versions of nodejs do not compile on al2 so we are tied to an old nodejs version. An al2023 update would allow us to update nodejs as well.
@GrahamCampbell why? Are we missing a feature with the version shipped in AL2023?