[$] A look at the Sequoia command-line interface

Post Syndicated from daroc original https://lwn.net/Articles/1003243/

The

Sequoia
OpenPGP library has been in development for some time. LWN
covered the library in 2020. Now the project’s
command-line interface has
been released. The sq tool offers a
promising alternative to the venerable

GNU Privacy Guard
(GPG) tool — albeit one with a
different interface, set of terminology, and approach to the web of
trust. Several distributions are making increasing use of the tool
behind the scenes.

CVE-2025-0282: Ivanti Connect Secure zero-day exploited in the wild

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2025/01/08/etr-cve-2025-0282-ivanti-connect-secure-zero-day-exploited-in-the-wild/

CVE-2025-0282: Ivanti Connect Secure zero-day exploited in the wild

On Wednesday, January 8, 2025, Ivanti disclosed two CVEs affecting Ivanti Connect Secure, Policy Secure, and Neurons for ZTA gateways. CVE-2025-0282 is a stack-based buffer overflow vulnerability that allows remote, unauthenticated attackers to execute code on the target device. CVE-2025-0283 is a stack-based buffer overflow that allows local authenticated attackers to escalate privileges on the device.

Ivanti’s advisory indicates that CVE-2025-0282 has been exploited in the wild against a limited number of Connect Secure devices. Per the vendor, Ivanti Policy Secure and Neurons for ZTA are not known to have been exploited in the wild at time of disclosure. Google’s Mandiant division and Microsoft’s Threat Intelligence Center (MSTIC) are credited with the discovery of the two issues, which almost certainly means further intelligence will be released soon on one or more zero-day threat campaigns targeting Ivanti devices.

Ivanti also has a short blog available on the new CVEs here.

Mitigation guidance

The following products and versions are vulnerable to CVE-2025-0282:

  • Ivanti Connect Secure 22.7R2 through 22.7R2.4
  • Ivanti Policy Secure 22.7R1 through 22.7R1.2
  • Ivanti Neurons for ZTA 22.7R2 through 22.7R2.3

The following products and versions are vulnerable to CVE-2025-0283:

  • Ivanti Connect Secure 22.7R2.4 and prior, 9.1R18.9 and prior
  • Ivanti Policy Secure 22.7R1.2 and prior
  • Ivanti Neurons for ZTA 22.7R2.3 and prior

Ivanti has a full table of affected versions and corresponding solution estimates in its advisory. As of 1 PM ET on Wednesday, January 8, patches are available for both CVEs in Ivanti Connect Secure (22.7R2.5), but the CVEs are unpatched in Ivanti Policy Secure and Neurons for ZTA (patches appear to be expected January 21, 2025, per the advisory).

Customers should apply available Ivanti Connect Secure patches immediately, without waiting for a typical patch cycle to occur. Ivanti’s advisory notes that “Exploitation of CVE-2025-0282 can be identified by the Integrity Checker Tool (ICT). We strongly advise all customers to closely monitor their internal and external ICT as a part of a robust and layered approach to cybersecurity to ensure the integrity and security of the entire network infrastructure.”

For the latest information, please refer to the vendor advisory.

Rapid7 customers

Our VM engineering team is researching options for coverage of CVE-2025-0282 and CVE-2025-0283 in Ivanti Connect Secure and expects vulnerability checks to be available to InsightVM and Nexpose customers no later than Thursday, January 9, 2025.

2024: Year in Review (Tor Blog)

Post Syndicated from jzb original https://lwn.net/Articles/1004460/

The Tor Project has published a
review
of major milestones from 2024, including merging with
the Tails project
, work to enable human-friendly .onion
addresses, and the launch of WebTunnel:

By mimicking common internet protocols, WebTunnel improves the
resilience of the Tor network in regions with heavy censorship. And
since its launch earlier this year, we’ve made sure to prioritize
small download sizes for more convenient distribution and simplified
the support of uTLS integration further mimicking the characteristics
of more widespread browsers. This makes Webtunnel safe for general
users because it helps conceal the fact that a tool like Tor is being
used.

Customize the scope of IAM Access Analyzer unused access analysis

Post Syndicated from Stéphanie Mbappe original https://aws.amazon.com/blogs/security/customize-the-scope-of-iam-access-analyzer-unused-access-analysis/

AWS Identity and Access Management Access Analyzer simplifies inspecting unused access to guide you towards least privilege. You can use unused access findings to identify over-permissive access granted to AWS Identity and Access Management (IAM) roles and users in your accounts or organization. From a delegated administrator account for IAM Access Analyzer, you can use the dashboard to review unused access findings across your organization and prioritize the accounts to inspect based on the volume and type of findings. The findings highlight unused roles, unused access keys for IAM users, and unused passwords for IAM users. For active IAM users and roles, the findings provide visibility into unused services and actions. Recently, IAM Access Analyzer launched new configuration capabilities that you can use to customize the analysis. You can select accounts, roles, and users to exclude, and focus on the areas that matter the most to you. You can use identifiers such as account ID or scale configuration using tags. By scoping the IAM Access Analyzer to monitor a subset of accounts and roles, you can reduce noise from unwanted findings. You can update the configuration when needed to change the scope of analysis. With this new offering, IAM Access Analyzer provides enhanced controls to help you tailor the analysis more closely to your organization’s security needs.

In this post, we walk you through an example scenario. Imagine that you’re a cloud administrator in a company that uses Amazon Web Services (AWS). You use AWS Organizations to organize your workload into several organizational units (OUs) and accounts. You have dedicated accounts for testing and experimenting with new AWS features called sandbox accounts across your organization. The sandbox accounts can be created by anyone in your company and are centrally recorded. You’re using tags on IAM resources and have followed AWS best practices and strategies when tagging your AWS resources. Tags are applied to the IAM roles created by your teams.

To make sure that your teams are following the principle of least privilege and are working with only the required permissions to access the AWS accounts, you use IAM Access Analyzer. You created an unused access analyzer at the organization level so it will monitor the AWS accounts in your organization. You noticed that you have multiple unused access findings. After analysis, your security team suggests the exclusion of some AWS accounts, IAM roles, and users so they can focus on the relevant findings. They want the sandbox accounts and the IAM roles they use for security purposes (such as auditing, incident response) to be excluded from the unused access analysis.

You can select accounts and roles to exclude when you create a new analyzer or update the analyzer later. In this post, we show you how to configure IAM Access Analyzer unused access finding to exclude specific accounts across your organization and specific principals (IAM roles and IAM users) once you have set up an analyzer. There is no additional pricing for using the prescriptive recommendations after you have enabled unused access findings.

Prerequisites

The following are the prerequisites to configure IAM Access Analyzer for unused access analysis:

  • An unused access analyzer created at the organization level
  • Administrative level access to the IAM Access Analyzer delegated administrator account
  • A list of account IDs that you want to exclude
  • IAM roles with tags

In the following sections, you will learn how to customize your IAM Access Analyzer to better suit your organization’s needs. This includes the following:

  1. Explore how to exclude specific AWS accounts from the analyzer’s unused access findings.
  2. See how to exclude tagged IAM roles from the analysis, allowing you to focus on the most relevant security insights and you see how to review exclusions on your analyzer to modify them as needed.
  3. By the end, you will have a tailored unused access analyzer that provides more meaningful and actionable results for your organization.

Exclude specific accounts across your organization

In this section, you will see how to update your existing unused access analyzer at the organization level through the AWS Management Console and AWS Command Line Interface (AWS CLI) to exclude specific AWS account IDs from its analysis.

If you don’t have an unused access analyzer in the organization, see this post for instructions on how to create one.

Use the console to update your unused access analyzer:

  1. Connect to your IAM Access Analyzer delegated administrator account (by default, your organization management account).
  2. Open the IAM Access Analyzer console in your management account. You will see the dashboard with your active finding by selecting the analyzer of your choice on the top right. In this example, the analyzer has 251 active findings.
    Figure 1: Unused access findings dashboard without exclusions

    Figure 1: Unused access findings dashboard without exclusions

  3. You can see the split of active findings per account. The example account has 57 active findings that you want to exclude from it.
    Figure 2: Unused access findings per account

    Figure 2: Unused access findings per account

  4. Select Analyzer settings under Access Analyzer in that navigation pane.
  5. The analyzer settings page presents the analyzers in your AWS Region and their status.
  6. Select your unused access analyzer in the list based on its name.
    Figure 3: Active access analyzers

    Figure 3: Active access analyzers

  7. On the Analyzer page, you can see the analyzer settings and a new tab called Exclusion. Because you have no excluded AWS accounts, the count of Excluded AWS accounts is 0 and there are no accounts displayed.
    Figure 4: Unused access analyzer exclusion tab

    Figure 4: Unused access analyzer exclusion tab

  8. Choose Manage in the Excluded AWS accounts section.
  9. Select Choose from organization and Hierarchy and choose Exclude next to the sandbox account that you want to exclude.
    Figure 5: Exclude sandbox account

    Figure 5: Exclude sandbox account

  10. After you select Exclude for the sandbox account, the account will be deselected and will appear in AWS accounts to exclude. The count of accounts to exclude has changed from 0 to 1. After you have finished, choose Save changes.
    Figure 6: Verify that the account is excluded and save changes

    Figure 6: Verify that the account is excluded and save changes

  11. The page will be automatically updated with your changes. You can then review the Excluded AWS accounts and verify that your excluded account is correctly configured.
    Figure 7: Analyzer configuration updated with excluded account

    Figure 7: Analyzer configuration updated with excluded account

  12. You can go back to the console dashboard and see the results. In this example, the exclusion of the sandbox account has caused the total number of active findings to go down from 251 to 194.
    Figure 8: Dashboard showing a reduction in active findings

    Figure 8: Dashboard showing a reduction in active findings

Use AWS CLI to update your unused access analyzer:

You can update your existing analyzer using the AWS CLI command aws accessanalyzer update-analyzer. Use the following command, replacing <YOUR-ANALYZER-NAME> with the name of your analyzer.

aws accessanalyzer update-analyzer 
--analyzer-name <YOUR-ANALYZER-NAME>
--configuration '{
  "unusedAccess": {
    "analysisRule": {
      "exclusions": [
        {
          "accountIds": [
            "222222222222"
          ]
        }
      ]
    }
  }
}'

You will obtain a result similar to the following:

{
    "revisionId": "<UNIQUE-REVISION-NUMBER>", 
    "configuration": {
        "unusedAccess": {
            "analysisRule": {
                "exclusions": [
                    {
                        "accountIds": [
                            "222222222222"
                        ]
                    }
                ]
            }, 
            "unusedAccessAge": 90
        }
    }

You have successfully excluded a sandbox account from the unused access analysis. Now you will exclude the IAM roles used by the security team to audit your accounts based on tags.

Excluding specific principals in your organization using tags

In this section, you will see how to update an existing unused access analyzer by excluding tagged IAM roles in your organization using the console and then AWS CLI.

Use the console to update your unused access analyzer:

  1. Open the IAM Access Analyzer console.
  2. Review the summary dashboard containing your unused findings. Choose Analyzer settings at the top of the screen.
    Figure 9: IAM Access Analyzer summary dashboard

    Figure 9: IAM Access Analyzer summary dashboard

  3. You will see a list of analyzers created in your account in that Region. Select the analyzer that you want to update.
  4. Review the analyzer page. On the Exclusion tab, you will see Exclude IAM users and roles with tags with a count of 0.
    Figure 10: Configure exclusion of IAM roles using tag

    Figure 10: Configure exclusion of IAM roles using tag

  5. Choose Manage in the Excluded IAM users and roles with tags section.
  6. Add the tags attached to the roles that you want to exclude from the analysis and choose Save changes.
    Figure 11: Add tag to exclude

    Figure 11: Add tag to exclude

  7. You can now see that Excluded IAM users and roles with tags now has a count of 1, and you can see the tags in the list.
    Figure 12: List of exclusion tags

    Figure 12: List of exclusion tags

Use AWS CLI to update your unused access analyzer:

You can also update your existing analyzer using the AWS CLI command aws accessanalyzer update-analyzer. Using the following command, replace <YOUR-ANALYZER-NAME> with the name of your analyzer.

aws accessanalyzer update-analyzer 
--analyzer-name <YOUR-ANALYZER-NAME> 
--configuration '{
  "unusedAccess": {
    "analysisRule": {
      "exclusions": [
        {
          "accountIds": [
            "222222222222"
          ]
        },
        {
          "resourceTags": [
            {
              "team": "security"
            }
          ]
        }
      ]
    }
  }
}'

A successful response will look like the following:

{
    "revisionId": "<UNIQUE-REVISION-NUMBER>", 
    "configuration": {
        "unusedAccess": {
            "analysisRule": {
                "exclusions": [
                    {
                        "accountIds": [
                            "222222222222"
                        ]
                    }, 
                    {
                        "resourceTags": [
                            {
                                "team": "security"
                            }
                        ]
                    }
                ]
            }, 
            "unusedAccessAge": 90
        }
    }
}

Review the exclusion on your analyzer

You can review, remove, or update the exclusions configured on your analyzer by using the console or AWS CLI. For example, as a security administrator managing multiple accounts, you might initially exclude IAM roles that have the tag security from analysis. However, you might need to review these exclusions if your policies change, requiring analysis of certain security roles or removing the exclusion entirely. By adjusting your exclusions, you can make sure that your analyzer’s results remain relevant to your organization’s needs and account structure.

Review the exclusion on unused access analyzer using the console:

In this section, review the tags that have been excluded from an analyzer.

  1. Open the IAM console.
  2. Select Access Analyzer, under Access reports, you will see a summary dashboard of findings from an analyzer.
    1. The Active findings section shows the number of active findings for unused roles, the number of active findings for unused credentials and the number of active findings for unused permissions.
    2. The Findings overview section includes a breakdown of the active findings.
    3. The Findings status section shows the status of findings (whether active, archived or resolved).
      Figure 13: Unused access analyzer dashboard

      Figure 13: Unused access analyzer dashboard

  3. Select the Analyzer settings at the top of the screen.
  4. Select the analyzer that you want to review to see the exclusion tags.
    Figure 14: Review unused access analyzer exclusions

    Figure 14: Review unused access analyzer exclusions

  1. After applying the tags, the updated dashboard is shown after the next scan.
    Figure 15: Dashboard showing reduction of findings after exclusions

    Figure 15: Dashboard showing reduction of findings after exclusions

Review the exclusion on an unused access analyzer using AWS CLI:

Using the name of your analyzer, you can run the command get-analyzer to see the configured exclusion. Using the following command, replace <YOUR-ANALYZER-NAME> with the name of your analyzer:

aws accessanalyzer get-analyzer --analyzer-name <YOUR-ANALYZER-NAME>

You will get a response similar to the following:

{
  "analyzer": {
    "status": "ACTIVE",
    "name": "<YOUR-ANALYZER-NAME>",
    "tags": {},
    "revisionId": "<UNIQUE-REVISION-NUMBER>",
    "arn": "arn:aws:access-analyzer:<REGION>:111111111111:analyzer/<YOUR-ANALYZER-NAME>",
    "configuration": {
      "unusedAccess": {
        "analysisRule": {
          "exclusions": [
            {
              "accountIds": [
                "222222222222"
              ]
            },
            {
              "resourceTags": [
                {
                  "team": "security"
                }
              ]
            }
          ]
        },
        "unusedAccessAge": 90
      }
    },
    "type": "ORGANIZATION_UNUSED_ACCESS",
    "createdAt": "2024-10-11T22:26:57Z"
  }
}

Conclusion

In this post, you learned how to tailor your unused access analyzer to your needs by excluding specific accounts and IAM roles. To exclude the accounts in your organization from being monitored by IAM Access Analyzer, you can use a list of account IDs or select them from a hierarchical view of your organization structure. You can exclude IAM roles and IAM users based on tags. By customizing the exclusion on the unused access analyzer, you saw that the number of active findings went down, helping you focus on the findings that matter most. With this new offering, IAM Access Analyzer provides enhanced controls to help you tailor the analysis more closely to your organization’s security needs.

If you have feedback about this post, submit comments in the Comments section below.

Stéphanie Mbappe

P. Stéphanie Mbappe

Stéphanie is a Security Consultant with Amazon Web Services. She delights in assisting her customers at any step of their security journey. Stéphanie enjoys learning, designing new solutions, and sharing her knowledge with others.

Mathangi Ramesh

Mathangi Ramesh

Mathangi is the product manager for AWS Identity and Access Management. She enjoys talking to customers and working with data to solve problems. Outside of work, Mathangi is a fitness enthusiast and a Bharatanatyam dancer. She holds an MBA degree from Carnegie Mellon University.

Reke Jarikre

Reke Jarikre

Reke is an Associate Security Consultant at Amazon Web Services. She is passionate about safeguarding client infrastructures and crafting robust security measures. Outside work, she enjoys exploring new technologies, public speaking and contributing to open-source projects.

Announcing the pkgsrc-2024Q4 branch

Post Syndicated from jzb original https://lwn.net/Articles/1004429/

The pkgsrc developers have
announced the 2024Q4 branch of the pkgsrc cross-platform
packaging system. It is the default package manager for NetBSD, SmartOS, and is available for
Linux
as well. This marks the 85th quarterly release of pkgsrc:

Since the pkgsrc-2024Q3 release, 110 packages were added, 1580 packages
were updated (with 2399 updates, including language-specific updates:
24 Go, 3 OCaml, 66 Perl, 5 PHP, 626 Python, 282 Ruby, 44 TeX). 33
packages were removed.

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1004428/

Security updates have been issued by Fedora (firefox, mupdf, and php-tcpdf), SUSE (etcd, file-roller, gtk3, kernel, python-django-ckeditor, rubygem-json-jwt, and tomcat10), and Ubuntu (ffmpeg, HTMLDOC, linux-aws, linux-raspi, linux-gke, linux-hwe-6.8, linux-lowlatency, linux-lowlatency-hwe-6.8, and tinyproxy).

Open source all the way down: Upgrading our developer documentation

Post Syndicated from Kim Jeske original https://blog.cloudflare.com/open-source-all-the-way-down-upgrading-our-developer-documentation/

At Cloudflare, we treat developer content like a product, where we take the user and their feedback into consideration. We are constantly iterating, testing, analyzing, and refining content. Inspired by agile practices, treating developer content like an open source product means we approach our documentation the same way an open source software project is created and maintained.  Open source documentation empowers the developer community because it allows anyone, anywhere, to contribute content. By making both the content and the framework of the documentation site publicly accessible, we provide developers with the opportunity to not only improve the material itself but also understand and engage with the processes that govern how the documentation is built, approved, and maintained. This transparency fosters collaboration, learning, and innovation, enabling developers to contribute their expertise and learn from others in a shared, open environment. We also provide feedback to other open source products and plugins, giving back to the same community that supports us.

Building the best open source documentation experience

Great documentation empowers users to be successful with a new product as quickly as possible, showing them how to use the product and describing its benefits. Relevant, timely, and accurate content can save frustration, time, and money. Open source documentation adds a few more benefits, including building inclusive and supportive communities that help reduce the learning curve. We love being open source!

While the Cloudflare content team has scaled to deliver documentation alongside product launches, the open source documentation site itself was not scaling well. developers.cloudflare.com had outgrown the workflow for contributors, plus we were missing out on all the neat stuff created by developers in the community.

Just like a software product evaluation, we reviewed our business needs. We asked ourselves if remaining open source was appropriate? Were there other tools we wanted to use? What benefits did we want to see in a year or in five years? Our biggest limitations in addition to the contributor workflow challenges seemed to be around scalability and high maintenance costs for user experience improvements. 

After compiling our wishlist of new features to implement, we reaffirmed our commitment to open source. We valued the benefit of open source in both the content and the underlying framework of our documentation site. This commitment goes beyond technical considerations, because it’s a fundamental aspect of our relationship with our community and our philosophy of transparency and collaboration. While the choice of an open source framework to build the site on might not be visible to many visitors, we recognized its significance for our community of developers and contributors. Our decision-making process was heavily influenced by two primary factors: first, whether the update would enhance the collaborative ecosystem, and second, how it would improve the overall documentation experience. This focus reflects that our open source principles, applied to both content and infrastructure, are essential for fostering innovation, ensuring quality through peer review, and building a more engaged and empowered user community.

Cloudflare developer documentation: A collaborative open source approach

Cloudflare’s developer documentation is open source on GitHub, with content supporting all of Cloudflare’s products. The underlying documentation engine has gone through a few iterations, with the first version of the site released in 2020. That first version provided dev-friendly features such as dark mode and proper code syntax. 

2021 update: enhanced documentation engine

In 2021, we introduced a new custom documentation engine, bringing significant improvements to the Cloudflare content experience. The benefits of the Gatsby to Hugo migration included:

  • Faster development flow: The development flow replicated production behavior, increasing iteration speed and confidence. Preview links via Cloudflare Pages were also introduced, so the content team and stakeholders could quickly review what content would look like in production.

  • Custom components: Introduced features like resources-by-selector which let us reference content throughout the repository and gave us the flexibility to expand checks and automations.

  • Structured changelog management: Implementation of structured YAML changelog entries which facilitated sharing with various platforms like RSS feeds, Developer Discord, and within the docs themselves.

  • Improved performance: Significant page load time improvements with the migration to HTML-first and almost instantaneous local builds.

These features were non-negotiable as part of our evaluation of whether to migrate. We knew that any update to the site had to maintain the functionality we’d established as core parts of the new experience.

2024 update: Say “hello, world!” to our new developer documentation, powered by Astro

After careful evaluation, we chose to migrate from Hugo to the Astro (and by extension, JavaScript) ecosystem. Astro fulfilled many items on our wishlist including:

  • Enhanced content organization: Improved tagging and better cross-referencing of  related pages.

  • Extensibility: Support for user plugins like starlight-image-zoom for lightbox functionality.

  • Development experience: Type-checking at build time with astro check, along with syntax highlighting, Intellisense, diagnostic messages, and plugins for ESLint, Stylelint, and Prettier. 

  • JavaScript/TypeScript support: Aligned the docs site framework with the preferred languages of many contributors, facilitating easier contribution.

  • CSS management: Introduction of Tailwind and scoped styles.

  • Content collections: Offered various ways to manage and enhance tagging practices including Markdown front matter validated by Zod schemas, JSON schemas for Intellisense, and a JavaScript callback for filtering returned entries.


Starlight, Astro’s documentation theme, was a key factor in the decision. Its powerful component overrides and plugins system allowed us to leverage built-in components and base styling.

How we migrated to Astro

Content needed to be migrated quickly. With dozens of pull requests opened and merged each day, entering a code freeze for a week simply wasn’t feasible. This is where the nature of abstract syntax trees (ASTs) came into play, only parsing the structure of a Markdown document rather than details like whitespace or indentation that would make a regular expression approach tricky.

With Hugo in 2021, we configured code block functionality like titles or line highlights with front matter inside the code block.

---
title: index.js
highlight: 1
---
const foo = "bar";

Starlight uses Expressive Code for code blocks, and these options are now on the opening code fence.

js title="index.js" {1}
const foo = "bar";

With astray, this is a simple as visiting the `code` nodes and:

  1. Parsing `node.value` with front-matter.

  2. Assigning the attributes from `front-matter` to `node.meta`.

  3. Replacing `node.value` with the rest of the code block.

import { fromMarkdown } from "mdast-util-from-markdown";
import { toMarkdown } from "mdast-util-to-markdown";
 
import * as astray from "astray";
import type * as MDAST from "mdast";
import fm from "front-matter";
 
const markdown = await Bun.file("example.md").text();
 
const AST = fromMarkdown(markdown);
 
astray.walk<MDAST.Root, void, any>(AST, {
    code(node: MDAST.Code) {
        const { attributes, body } = fm(node.value);
        const { title, highlight } = attributes;
 
        if (title) {
            node.meta = `title="${title}"`;
        }
 
        if (highlight) {
            node.meta += ` {${highlight}}`;
        }
 
        node.value = body;
 
        return;
    }
})

The migration in numbers

When we migrated from Gatsby to Hugo in 2021, the pull request included 4,850 files and the migration took close to three weeks from planning to implementation. This time around, the migration was nearly twice as large, with 8,060 files changed. Our planning and migration took six weeks in total:

  • 10 days: Evaluate platforms, vendors, and features 

  • 14 days: Migrate the components required by the documentation site

  • 5 days: Staging and user acceptance testing (UAT) 

  • 8 hours: Code freeze and migrate to Astro/Starlight

The migration resulted in removing a net -19,624 lines of code from our maintenance burden.


While the number of files had grown substantially since our last major migration, our strategy was very similar to the 2021 migration. We used Markdown AST and astray, a utility to walk ASTs, created specifically for the previous migration!

What we learned

A website migration like our move to Astro/Starlight is a complex process that requires time to plan, review, and coordinate, and our preparation paid off! Including our Cloudflare Community MVPs as part of the planning and review period proved incredibly helpful. They provided great guidance and feedback as we planned for the migration. We only needed one day of code freeze, and there were no rollbacks or major incidents. Visitors to the site never experienced downtime, and overall the migration was a major success.

During testing, we ran into several use cases that warranted using experimental Astro APIs. These APIs were always well documented, thanks to fantastic open source content from the Astro community. We were able to implement them quickly without impacting our release timeline.

We also ran into an edge case with build time performance due to the number of pages on our site (4000+). The Astro team was quick to triage the problem and begin investigation for a permanent fix. Their fast, helpful fixes made us truly grateful for the support from the Astro Discord server. A big thank you to the Astro/Starlight community!

Contribute to developers.cloudflare.com!

Migrating developers.cloudflare.com to Astro/Starlight is just one example of the ways we prioritize world-class documentation and user experiences at Cloudflare. Our deep investment in documentation makes this a great place to work for technical writers, UX strategists, and many other content creators. Since adopting a content like a product strategy in 2021, we have evolved to better serve the open source community by focusing on inclusivity and transparency, which ultimately leads to happier Cloudflare users. 

We invite everyone to connect with us and explore these exciting new updates. Feel free to reach out if you’d like to speak with someone on the content team or share feedback about our documentation. You can share your thoughts or submit a pull request directly on the cloudflare-docs repository in GitHub.

Highlights from Coolest Projects South Africa 2024

Post Syndicated from Afandi Indiatsi original https://www.raspberrypi.org/blog/highlights-from-coolest-projects-south-africa-2024/

Afandi Indiatsi, our Programme Coordinator in Africa, recently attended Coolest Projects South Africa 2024. Read on to hear her highlights.

What happens when creativity, enthusiasm, fun, and innovation come together? You get Coolest Projects South Africa 2024 — a vibrant showcase of students from all walks of life displaying their talent and shaping the future of technology.

Dozens of projects exhibited at the event in Cape Town

Hosted by our partner, Coder Level Up, Coolest Projects South Africa brought together creators, mentors, educators, and industry leaders to celebrate the creativity and ingenuity of young tech enthusiasts from across the country.

A group of educators at the Coolest Projects South Africa event.

With nearly 200 projects submitted and dozens showcased, the event highlighted the impressive talent and potential of South Africa’s next generation of innovators.

Taking place at the University of Western Cape’s Department of Education in Cape Town, the event was a hub of excitement. Right from the start the venue was buzzing with activity, with the South African World Robot Olympiad (WRO) team kicking things off with a fantastic demonstration of their robotic inventions. Their creations came alive to cheers and applause as they performed flawlessly, leaving attendees in awe — what an inspiration they were!

A group of young people showcases their projects at Coolest Projects South Africa.

Standout projects ranged from garbage collection to chocolate

The participants then presented their projects, each of which was ingenious in its own way. From hardware and visual programming to game development and website creation, there was a wealth of ideas on display — and a demonstration of the boundless potential of young minds when given the right tools and guidance. Adding to the inclusive spirit of the event, participants from Durban and East London joined remotely, their energy resonating through Zoom.

Two young students display their creations at Coolest Projects South Africa.

One standout project was a garbage collection robot created by an all-girls team from Nguzo Saba School. Using a LEGO kit, these creators transformed their idea into a functional invention. What made their project exceptional was their ability to improvise and enhance the kit to achieve their desired functionality. This was a true testament to their creativity, resilience, and problem-solving skills.

A group of young people showcases their projects at Coolest Projects South Africa.

Another memorable presentation came from Emma, who used Scratch to tell the story of the history of chocolate. Her engaging narrative spanned the journey of chocolate from the Olmec civilisation in Latin America to today’s chocolate museums. Emma’s research was extensive, and she captivated the judges not only with her presentation but also with chocolate samples for everyone to enjoy — a sweet touch that left a lasting impression!

Young people display their creations at Coolest Projects South Africa.

How Coolest Projects harnesses the power of education, creativity, and mentorship  

A recurring theme throughout the event was the importance of mentorship. Many of the young people shared that they had sought guidance from mentors, teachers, and family members while developing their projects. This collaborative spirit underscored the role of supportive communities in fostering innovation and creativity among young creators.

Coolest Projects South Africa 2024 was more than a showcase of talent. It was a reminder of the transformative power of education, mentorship, and creativity. Every project had a story of passion and perseverance, and every creator left inspired to dream bigger.

As we reflect on this event — and the many other Coolest Projects events that took place around the world this past year — we are reminded that the future of technology is in capable, imaginative hands.

Get involved with Coolest Projects in 2025

Coolest Projects will be back and bigger than ever before in 2025. 

The Coolest Projects online showcase is open globally to any young person up to age 18. Registration opens 14 January, and we’ll host a celebratory livestream on 25 June.

Thanks to an incredible network of partners, Coolest Projects events will also be hosted in person in many countries around the world. Go to the Coolest Projects website for more event dates and details.

The post Highlights from Coolest Projects South Africa 2024 appeared first on Raspberry Pi Foundation.

Announcing the new AWS Asia Pacific (Thailand) Region

Post Syndicated from Donnie Prakoso original https://aws.amazon.com/blogs/aws/announcing-the-new-aws-asia-pacific-thailand-region/

Today, we’re pleased to announce that the AWS Asia Pacific (Thailand) Region is now generally available with three Availability Zones and API name ap-southeast-7.

The AWS Asia Pacific (Thailand) Region is the first infrastructure Region in Thailand and the fourteenth Region in Asia Pacific, joining existing Regions in Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, and Tokyo, as well as the Beijing and Ningxia China Regions.

Lumphini Park, one of the largest green spaces in central Bangkok spanning 142 acres.

The adoption of cloud computing has gained significant momentum in Thailand, driven by evolving business needs and government initiatives such as Thailand 4.0. These initiatives aim to transform Thailand into an innovation-driven economy by using emerging technologies to enhance productivity, competitiveness, and sustainable growth.

The new AWS Region will help startups, enterprises, government agencies, educational institutions, and nonprofit organizations run their applications and serve end users while maintaining data residency in Thailand. This aligns with Thailand’s digital transformation goals and the growing demand for cloud services. Over the next 15 years, Amazon Web Services (AWS) planned investments in Thailand are estimated to contribute $10B to Thailand’s Gross Domestic Product (GDP) and support an estimated average of 11,000 full-time equivalent (FTE) jobs in local Thai businesses annually.

Growing presence of AWS in Thailand
Our journey in Thailand began in 2013 with the first AWS office in Bangkok. Since then, AWS has continuously expanded its infrastructure and services in the country:

Amazon CloudFront – Since 2020, AWS has established six Amazon CloudFront edge locations throughout Thailand. These edge locations are part of the highly secure and programmable AWS content delivery network (CDN), designed to accelerate the delivery of data, videos, applications, and APIs to users worldwide with low latency and high transfer speeds.

AWS Outposts – In the same year, 2020, AWS introduced AWS Outposts to the Thai market. As a fully managed solution, AWS Outposts brings AWS infrastructure and services to virtually any on-premises or edge location, enabling a truly consistent hybrid experience. This service is particularly valuable for workloads that require low latency, local data processing, or local data storage.

AWS Local Zones – In 2022, AWS strengthened its commitment to Thailand by launching AWS Local Zones in Bangkok. This infrastructure deployment places compute, storage, database, and other select services closer to large population, industry, and IT centers. As a result, customers can deliver applications requiring single-digit millisecond latency to end users.

AWS Direct Connect – AWS established a AWS Direct Connect location in Bangkok in 2023 to enhance connectivity options and added a new AWS Direct Connect location with the launch of the AWS Asia Pacific (Thailand) Region. Customers can use AWS Direct Connect to establish secure and dedicated network connections to their AWS resources, providing improved network performance and reduced bandwidth costs.

AWS customer success stories in Thailand
Organizations in Thailand are using our services to drive innovation and transformation. Here are a few examples:

2C2P
2C2P, a leading Thailand-based FinTech startup, chose AWS for its robust security capabilities. As an omnichannel payment service provider in Southeast Asia, the company processes millions of customer payments globally using AWS CloudHSM for cryptographic key management, AWS Shield for distributed denial of service (DDoS) protection, and AWS Secrets Manager to safeguard sensitive credentials.

“Through AWS, we’ve unlocked the power to securely, dynamically, and compliantly scale to meet the surge in payment transaction volumes. AWS CloudHSM plays a pivotal role in fulfilling compliance requirements and propelling us toward accelerated business expansion,” says Myo Zaw, Chief Technology Officer at 2C2P.

aCommerce
aCommerce, the largest ecommerce enabler in Southeast Asia, has revolutionized market intelligence by launching AskIQ, a generative AI–powered feature on AWS. This software as a service (SaaS) platform provides the world’s leading brands with comprehensive competitor and category performance tracking capabilities across Southeast Asia’s largest ecommerce sites.

Leena Chanvirach, VP of Data Products at aCommerce Group, emphasizes the strategic value of their AWS collaboration: “Our collaboration with AWS allows clients to double down on their core competencies and business priorities. This best-of-both-worlds approach gives brands a competitive edge without the burden of building and maintaining sophisticated data infrastructure in-house.”

Ascend Money
Ascend Money, a leading Southeast Asian FinTech company, achieved a 70 percent reduction in compute costs while simultaneously improving application performance by up to 40 percent in certain workloads. Ascend Money implemented a sophisticated compute strategy using Amazon EC2 instances, resulting in significant operational improvements.

“AWS has significantly improved our performance, enabling us to deliver more innovative services to our customers,” says Peerawit Phuangkaeo, Head of Technical Operations at Ascend Money.

Building cloud skills together
AWS has built comprehensive programs for cloud education and skills development in Thailand, training more than 50,000 individuals in cloud skills since 2017. Here are some of the programs:

AWS Skill Builder
AWS Skill Builder is an online learning center where you can learn from AWS experts and build cloud skills online. AWS has made cloud education more accessible to Thai learners by offering more than 600 courses, with 106 courses specifically available in Thai language. The recent launch of the Amazon AI Ready initiative has further expanded the learning opportunities, particularly in the growing field of AI.

AWS Educate
Since its introduction in 2016, AWS Educate has played a transformative role in Thai education. The program has successfully integrated cloud computing into educational curricula across Thailand, providing students with direct access to AWS resources and hands-on experience. The impact has been substantial, with over 20,000 Thai students enrolled in the program. Beyond student education, AWS Educate has invested in training Thai educators, preparing them to deliver engaging and practical cloud computing courses that prepare students for the demands of the digital economy.

AWS Academy
AWS Academy has been instrumental in connecting academic learning with industry needs since its launch in Thailand in 2017. Through strategic partnerships with more than 30 leading universities and colleges across the country, AWS Academy has created a robust pipeline of cloud-skilled professionals. The program provides educational institutions with comprehensive cloud computing curricula that align with industry needs, making sure that students graduate with practical, job-ready skills.

Through these various initiatives and programs, AWS is not just providing educational resources, it’s building a foundation for Thailand’s digital future by helping equip the workforce with the necessary skills to use cloud technologies effectively.

Supporting sustainable innovation in Thailand
The AWS commitment to sustainability extends to supporting innovative companies in Thailand that are driving environmental initiatives.

BODA Technology & Consultancy
BODA, an AWS powered sustainability startup, uses AWS IoT Core to develop AI-powered solutions for energy efficiency optimization. The company has successfully improved operations in over 100,000 buildings and factories across Thailand, enabling these facilities to maximize efficiency while reducing costs and environmental impact.

GSPC Group
GSPC Group, a leading sustainable power company in Thailand, demonstrates how AWS supports the energy sector’s digital transformation. Following the merger between Global Power Synergy Public Company and Glow Energy, the group chose AWS Cloud for migrating its photovoltaic solar plant operations. Working with AWS and AWS Partner Dailitech, GSPC Group has achieved a 20–25 percent reduction in hardware, software, and licensing costs since moving to the cloud.

Things to know
AWS Community in Thailand — Thailand is home to two AWS Heroes, seven AWS Community Builders, and more than 17,000 members of the AWS User Group. If you’re interested in joining AWS User Group Thailand, visit their Facebook page.

AWS Global footprint — AWS now spans 111 Availability Zones within 35 geographic regions worldwide. We have announced plans for 15 more Availability Zones and five more AWS Regions in Germany, Taiwan, Mexico, the Kingdom of Saudi Arabia, and New Zealand. 

The new Asia Pacific (Thailand) Region is ready to support your business. To learn more, visit the AWS Global Infrastructure page and start building on ap-southeast-7!

Happy building!
— Donnie

Kicinski: netdev in 2024

Post Syndicated from corbet original https://lwn.net/Articles/1004376/

Kernel networking maintainer Jakub Kicinski reviews progress in
the networking subsystem
in 2024.

Work on relieving the rtnl_lock pressure has continued throughout
the year. The rtnl_lock is often mentioned as one of the biggest
global locks in the kernel, as it protects all of the network
configuration and state. The efforts can be divided into two broad
categories – converting read operations to rely on RCU protection
or other fine grained locking (v6.9, v6.10), and splitting the lock
into per-network namespace locks (preparations for which started in
v6.13).

2024 in retrospect (Gentoo News)

Post Syndicated from jzb original https://lwn.net/Articles/1004373/

Gentoo Linux has published a project
retrospective
that looks at the major improvements and news from
2024, the Gentoo Foundation’s finances, and contributions to Gentoo by
the numbers.

The number of commits to the main ::gentoo
repository
has remained at an overall high level in 2024, with a
2.4% increase from 121000 to 123942. The number of commits by external
contributors has grown strongly from 10708 to 12812, now across 421
unique external authors.

The importance of GURU, our
user-curated repository with a trusted user model
, as entry point
for potential developers, is clearly increasing as well. We have had
7517 commits in 2024, a strong growth from 5045 in 2023. The number of
contributors to GURU has increased a lot as well, from 158 in 2023 to
241 in 2024. Please join us there and help packaging the latest and
greatest software.

Use CI/CD best practices to automate Amazon OpenSearch Service cluster management operations

Post Syndicated from Camille BIRBES original https://aws.amazon.com/blogs/big-data/use-ci-cd-best-practices-to-automate-amazon-opensearch-service-cluster-management-operations/

Quick and reliable access to information is crucial for making smart business decisions. That’s why companies are turning to Amazon OpenSearch Service to power their search and analytics capabilities. OpenSearch Service makes it straightforward to deploy, operate, and scale search systems in the cloud, enabling use cases like log analysis, application monitoring, and website search.

Efficiently managing OpenSearch Service indexes and cluster resources can lead to significant improvements in performance, scalability, and reliability – all of which directly impact a company’s bottom line. However, the industry lacks built-in and well-documented solutions to automate these important operational tasks.

Applying continuous integration and continuous deployment (CI/CD) to managing OpenSearch index resources can help do that. For instance, storing index configurations in a source repository allows for better tracking, collaboration, and rollback. Using infrastructure as code (IaC) tools can help automate resource creation, providing consistency and reducing manual work. Finally, using a CI/CD pipeline can automate deployments and streamline workflow.

In this post, we discuss two options to achieve this: the Terraform OpenSearch provider and the Evolution library. Which one is best suited to your use case depends on the tooling you are familiar with, your language of choice, and your existing pipeline.

Solution overview

Let’s walk through a straightforward implementation. For this use case, we use the AWS Cloud Development Kit (AWS CDK) to provision the relevant infrastructure as described in the following architecture diagram that follows, AWS Lambda to trigger Evolution scripts and AWS CodeBuild to apply Terraform files. You can find the code for the entire solution in the GitHub repo.

Solution Architecture Diagram

Prerequisites

To follow along with this post, you need to have the following:

  • Familiarity with Java and OpenSearch
  • Familiarity with the AWS CDK, Terraform, and the command line
  • The following software versions installed on your machine: Python 3.12, NodeJS 20, and AWS CDK 2.170.0 or higher
  • An AWS account, with an AWS Identity and Access Management (IAM) role configured with the relevant permissions

Build the solution

To build an automated solution for OpenSearch Service cluster management, follow these steps:

  1. Enter the following commands in a terminal to download the solution code; build the Java application; build the required Lambda layer; create an OpenSearch domain, two Lambda functions and a CodeBuild project; and deploy the code:
git clone https://github.com/aws-samples/opensearch-automated-cluster-management
cd opensearch-automated-cluster-management
cd app/openSearchMigration
mvn package
cd ../../lambda_layer
chmox a+x create_layer.sh
./create_layer.sh
cd ../infra
npm install
npx cdk bootstrap
aws iam create-service-linked-role --aws-service-name es.amazonaws.com
npx cdk deploy --require-approval never
  1. Wait 15 to 20 minutes for the infrastructure to finish deploying, then check that your OpenSearch domain is up and running, and that the Lambda function and CodeBuild project have been created, as shown in the following screenshots.

OpenSearch domain provisioned successfully OpenSearch Migration Lambda function created successfully OpenSearchQuery Lambda function created successfully CodeBuild project created successfully

Before you use automated tools to create index templates, you can verify that none already exist using the OpenSearchQuery Lambda function.

  1. On the Lambda console, navigate to the relevant Function
  2. On the Test tab, choose Test.

The function should return the message “No index patterns created by Terraform or Evolution,” as shown in the following screenshot.

Check that no index patterns have been created

Apply Terraform files

First, you use Terraform with CodeBuild. The code is ready for you to test, let’s look at a few important pieces of configuration:

  1. Define the required variables for your environment:
variable "OpenSearchDomainEndpoint" {
  type = string
  description = "OpenSearch domain URL"
}

variable "IAMRoleARN" {
  type = string
  description = "IAM Role ARN to interact with OpenSearch"
}
  1. Define and configure the provider
terraform {
  required_providers {
    opensearch = {
      source = "opensearch-project/opensearch"
      version = "2.3.1"
    }
  }
}

provider "opensearch" {
  url = "https://${var.OpenSearchDomainEndpoint}"
  aws_assume_role_arn = "${var.IAMRoleARN}"
}

NOTE: As of the publication date of this post, there is a bug in the Terraform OpenSearch provider that will trigger when launching your CodeBuild project and that will prevent successful execution. Until it is fixed, please use the following version:

terraform {
  required_providers {
    opensearch = {
      source = "gnuletik/opensearch"
      version = "2.7.0"
    }
  }
}
  1. Create an index template
resource "opensearch_index_template" "template_1" {
  name = "cicd_template_terraform"
  body = <<EOF
{
  "index_patterns": ["terraform_index_*"],
  "template": {
    "settings": {
      "number_of_shards": "1"
    },
    "mappings": {
        "_source": {
            "enabled": false
        },
        "properties": {
            "host_name": {
                "type": "keyword"
            },
            "created_at": {
                "type": "date",
                "format": "EEE MMM dd HH:mm:ss Z YYYY"
            }
        }
    }
  }
}
EOF
}

You are now ready to test.

  1. On the CodeBuild console, navigate to the relevant Project and choose Start Build.

The build should complete successfully, and you should see the following lines in the logs:

opensearch_index_template.template_1: Creating...
opensearch_index_template.template_1: Creation complete after 0s (id=cicd_template_terraform)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

You can check that the index template has been properly created using the same Lambda function as earlier, and should see the following results.

Terraform index properly created

Run Evolution scripts

In the next step, you use the Evolution library. The code is ready for you to test, let’s look at a few important pieces of code and configuration:

  1. To begin with, you need to add the latest version of the Evolution core library and AWS SDK as Maven dependencies. The full xml file is available in the GitHub repository; to check the Evolution library’s compatibility with different OpenSearch versions, see here.
<dependency>
    <groupId>com.senacor.elasticsearch.evolution</groupId>
    <artifactId>elasticsearch-evolution-core</artifactId>
    <version>0.6.0</version><!--check the latest version-->
</dependency>
<dependency>
   <groupId>software.amazon.awssdk</groupId>
   <artifactId>auth</artifactId>
</dependency>
  1. Create Evolution Bean and an AWS interceptor (which implements HttpRequestInterceptor).

Interceptors are open-ended mechanisms in which the SDK calls code that you write to inject behavior into the request and response lifecycle. The function of the AWS interceptor is to hook into the execution of API requests and create an AWS signed request stamped with proper IAM roles. You can use the following code to create your own implementation to sign all the requests made to OpenSearch within AWS.

  1. Create your own OpenSearch client to manage automatic creation of index, mappings, templates, and aliases.

The default ElasticSearch client that comes bundled in as part of the Maven dependency can’t be used to make PUT calls to the OpenSearch cluster. Therefore, you need to bypass the default REST client instance, and add a CallBack to the AwsRequestSigningInterceptor.

The following is a sample implementation:

private RestClient getOpenSearchEvolutionRestClient() {
    return RestClient.builder(getHttpHost())
        .setHttpClientConfigCallback(hacb -> 
            hacb.addInterceptorLast(getAwsRequestSigningInterceptor()))
        .build();
}
  1. Use the Evolution Bean to call your migrate method, which is responsible for initiating the migration of the scripts defined either using classpath or filepath:
public void executeOpensearchScripts() {
    ElasticsearchEvolution opensearchEvolution = ElasticsearchEvolution.configure()
        .setEnabled(true) // true or false
        .setLocations(Arrays.asList("classpath:opensearch_migration/base",
            "classpath:opensearch_migration/dev")) // List of all locations where scripts are located.
        .setHistoryIndex("opensearch_changelog") // Tracker index to store history of scripts executed.
        .setValidateOnMigrate(false) // true or false
        .setOutOfOrder(true) // true or false
        .setPlaceholders(Collections.singletonMap("env","dev")) // list of placeholders which will get replaced in the script during execution.
        .load(getElasticsearchEvolutionRestClient());
    opensearchEvolution.migrate();
}
  1. An Evolution migration script represents a REST call to the OpenSearch API (for example, PUT /_index_template/cicd_template_evolution), where you define index patterns, settings, and mappings in JSON format. Evolution interprets these scripts, manages their versioning, and provides ordered execution. See the following example:
PUT /_index_template/cicd_template_evolution
Content-Type: application/json

{
  "index_patterns": ["evolution_index_*"],
  "template": {
    "settings": {
      "number_of_shards": "1"
    },
    "mappings": {
        "_source": {
            "enabled": false
        },
        "properties": {
            "host_name": {
                "type": "keyword"
            },
            "created_at": {
                "type": "date",
                "format": "EEE MMM dd HH:mm:ss Z YYYY"
            }
        }
    }
  }
}

The first two lines must be followed by a blank line. Evolution also supports comment lines in its migration scripts. Every line starting with # or // will be interpreted as a comment-line. Comment lines aren’t sent to OpenSearch. Instead, they are filtered by Evolution.

The migration script file naming convention must follow a pattern:

  • Start with esMigrationPrefix which is by default V or the value that has been configured using the configuration option esMigrationPrefix
  • Followed by a version number, which must be numeric and can be structured by separating the version parts with a period (.)
  • Followed by the versionDescriptionSeparator: __ (the double underscore symbol)
  • Followed by a description, which can be any text your filesystem supports
  • End with esMigrationSuffixes which is by default .http and is configurable and case insensitive

You’re now ready to execute your first automated change. An example of a migration script has already been created for you, which you can refer to in a previous section. It will create an index template named cicd_template_evolution.

  1. On the Lambda console, navigate to your function.
  2. On the Test tab, choose Test.

After a few seconds, the function should successfully complete. You can review the log output in the Details section, as shown in the following screenshots.

Migration function finish successfully

The index template now exists, and you can check that its configuration is indeed in line with the script, as shown in the following screenshot.

Evolution index template properly created

Clean up

To clean up the resources that were created as part of this post, run the following commands (in the infra folder):

npx cdk destroy --all

Conclusion

In this post, we demonstrated how to automate OpenSearch index templates using CI/CD practices and tools such as Terraform or the Evolution library.

To learn more about OpenSearch Service, refer to the Amazon OpenSearch Service Developer Guide. To further explore the Evolution library, refer to the documentation. To learn more about the Terraform OpenSearch provider, refer to the documentation.

We hope this detailed guide and accompanying code will help you get started. Try it out, let us know your thoughts in the comments section, and feel free to reach out to us for questions!


About the Authors

Camille BirbesCamille Birbes is a Senior Solutions Architect with AWS and is based in Hong Kong. He works with major financial institutions to design and build secure, scalable, and highly available solutions in the cloud. Outside of work, Camille enjoys any form of gaming, from board games to the latest video game.

Sriharsha Subramanya Begolli works as a Senior Solutions Architect with AWS, based in Bengaluru, India. His primary focus is assisting large enterprise customers in modernizing their applications and developing cloud-based systems to meet their business objectives. His expertise lies in the domains of data and analytics.

The collective thoughts of the interwebz