Yearly Archives: 2024

A new package manager for OpenWrt

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

The OpenWrt router-oriented distribution has long used its own opk
package manager. The project has just announced,
though, that future releases will use the apk
package manager from Alpine Linux instead. “This new package
manager offers a number of advantages over the older opkg system and is a
significant milestone in the development of the OpenWrt platform. The older
opkg package manager has been deprecated and is no longer part of
OpenWrt.” There is some more information on this
page.

Седмицата (11–16 ноември)

Post Syndicated from Боряна Телбис original https://www.toest.bg/sedmitsata-11-16-noemvri/

Седмицата (11–16 ноември)

Какво щастие, че част от нещата, които ми направиха силно впечатление тази седмица и които са извън общонационалната говорилня кой с кого и дали ще съставя правителство, стигнаха до мен чрез „Тоест“. Човек би казал, че я следя внимателно тази медия…

Едното е препоръката на Антония Апостолова да прочетем романа на Иля Леонард Пфайфер „Гранд хотел Европа“, в който главен герой е Старият континент. Освен че текстът на Антония е изключително увлекателен и даже малко ме хваща яд, че никога няма да мога така вдъхновено и мотивирано да разкажа за каквото и да е произведение, вниманието ми грабна и сюжетът на романа като книга от и за Европа. Докато дочитах ревюто на Антония, вече приключвах и онлайн поръчката на книгата. Де да можех така хармонично и синхронично да действам и по други въпроси, но нейсе…

Другият материал, който спокойно мога да дръпна за ръка пред останалите в не особено консистентната ми редица на „Какво прочетох тази седмица“, е разговорът между Миглена Николчина и Северина Станкева за посткомунистическото във видеоигрите. Този (остро)умен диалог между две жени, обичащи видеоигрите по онзи начин, по който може да се обича само изкуство, е тотална наслада. Нещо като Жан Клод Кариер и Умберто Еко в „Това не е краят на книгите“, само че не за книги, а за видеоигри. Разговорите между Миглена и Северина ще продължат в рамките на новата рубрика за видеоигри „Игромислие“.

За мен изключително интересен и важен през тази седмица е и материалът на Надежда Цекулова „Приобщаване чрез доверие. Опитът на център „Анна Фройд“ за подкрепа на младежи“. В него тя разказва за срещата с психолога Питър Фугъл, организирана в рамките на експертна дискусия за работа с деца и семейства в риск. Както Надежда отбелязва, Фугъл застава пред колегите си от България не за лекция, а за задълбочен човешки разговор как група специалисти в Англия се опитват да върнат фокуса на комплексните здравно-социални услуги върху нуждите на детето и семейството. И всичко, което този човек разказва, е изключително ценно. Ще се убедите сами.

С фокус върху важен обществен проблем е и текстът на Светла Енчева, в който се разглежда хрониката на една предизвестена вандалщина – пред Народния театър. Как толерирането на хомофобията направи възможни сцените от миналата седмица и какво следва, може да прочетете в анализа на Светла. Процесите, които тя коментира, са грижливо отглеждани години наред от (част от) политическите ни партии и някак не са изненада, макар да имаше много изненадани покрай случката с Народния театър.

Едва ли обаче ще има изненадани, ако скоро тръгнем към нови избори. Според Емилия Милчева това е напълно възможно. Само дето не е ясно как гражданите биха могли да се ориентират в лабиринтите на политическото празнословие и схемаджийство, което ни облива на талази, за да направят съзнателния избор да отидат и да гласуват. Отново. Какво става с партиите в тази ситуация и къде е президентът в цялата картинка – вижте в текста на Емилия „Осмите избори – повече отрова или повече демокрация“.

Като споменах „съзнателния избор“, се сетих, че тази седмица беше съобщен резултатът от един очевидно особено съзнателен избор, който беше проведен напълно осъзнато даже два пъти в последните месеци. Става дума за Националната награда за български роман на годината „13 века България“. Първия път се оказа, че не трябва да го броим, понеже имало конфликт на интереси. Тогава Елена Алексиева върна наградата, която според първоначалната преценка на журито беше заслужила за романа си „Вулкан“. Съдийството не било особено честно. И затова беше преценено, че този литературен мач ще се преиграва. Вярно, че част от играчите отказаха да играят пак, но пък други останаха на терена и се оказа, че и в литературата, като във футбола, може да има играещи треньори, които даже да спечелят трофей. Личен, не за отбора, който водят. Свиреното – свирено.

За съжаление, няма нищо свирено във войната, която се води на един хвърлей от нас. За опасното разширяване на военните действия между Русия и Украйна става въпрос в материала на Александър Малинов. В него той анализира пет ключови въпроса, свързани с ускоряването на военното сътрудничество между Пхенян и Москва и изпращането на севернокорейски войници на фронта. Учудващо, тук нито Путин, нито Ким Чен Ун имат зор да се правят на играещи треньори. Гледай какво нещо…

За финал ще насоча погледите ви към Далечния изток, но на югозапад от Владивосток и Пхенян, за да се разходим заедно с Емине Садкъ в не толкова туристически познатите зони на Тайланд. В третата част от поредицата си Емине ни разхожда из Ко Ланта, където ни запознава с морските номади и малайзийските мюсюлмани. Накрая даже ни препоръчва да пием куба либре в кокосов орех.

Това някак и аз мога да ви го препоръчам. Ето, даже го правя – препоръчвам ви го.

Приятен „Тоест“!

Подкрепете ни

Against best practices

Post Syndicated from arp242.net original https://www.arp242.net/best-practices.html

I have come to believe that by and large “best practices” are doing more harm
than good. Not necessarily because they’re bad advice as such, but because
they’re mostly pounded by either 1) various types of zealots, idiots, and
assholes who abuse these kind of “best practices” as an argument from authority,
or 2) inexperienced programmers who lack the ability to judge the applicability,

Everyone else just says “X is better because Y”. This is an actual argument that
can be engaged with, and engaging with actual arguments is what discovers the
best solution for the situation at hand.

This is not unique to programming; even the best of ideas becomes silly once you
start uncritically applying it to everything – one can find many examples in
politics. There, too, it’s mostly pounded by various types of zealots, idiots,
and assholes.

All of this doesn’t mean that “best practice” are bad advice. Many are worth
reading, and some should always be followed. But many are little more “this
thing someone said” and/or “just someone’s opinion”.

Take Postel’s “law” – what if I break this “law”? Will the police come and
arrest me? Will I get the Nobel prize in physics as I’ve discovered new laws of
nature? It’s not a “law” in any meaningful sense: it’s just a thing this Postel
guy said in 1980, which may or may not be applicable to whatever you’re doing.

Postel’s quip was probably good advice in 1980 in the context of TCP. There
were tons of little incompatibilities between existing implementations and
Postel was working on the first effort to actually standardize it all. Back then
it was typically harder to write fully correct implementations (no internet with
tons of examples, little to no testing, less access to other implementations,
etc.)

There are other cases where it’s the reasonable and practical thing to do. But
as a general concept applied to all protocols or all software development I find
it’s mostly a bad idea. I’m hardly the first to critique it, and it’s been
controversial for decades.

In spite of that, people citing Postel’s quip as if it’s somehow a “law” are
still plentiful. My law is that everyone who does so is an idiot, asshole, or
some combination of both.

There are many more examples:

  • “Don’t use globals” is obviously good, but “never use globals under any
    circumstances” is just silly. I’ve seen people throw a hissy fit over
    “globals” in simple CLI tools with a few functions. Whoop-dee-doo.

  • “Don’t use unstructured GOTO” has turned into “never use goto”, “don’t use
    continue because it’s like a hidden goto”, and “use single point of exit”, and
    that kind of absolute insane bollocks.

  • “Don’t Repeat Yourself” (DRY) is basically good advice, but sometimes just
    copy/pasting things is just the more pragmatic thing to do, and not really a
    big deal.

  • I think “12 factor app” has some okay ideas, some dubious ideas, and some
    outright bad ideas.

  • While the basic ideas of “SOLID” are okay, I generally find that strong
    adherence does not lead to particularly good code. It’s typically 80% fucking
    about with how to do things, and 20% actually doing the stuff you want to do
    (which makes things harder to understand and change, not easier).

  • etc. etc. etc.

You can disagree with any of the above, and that’s fine. But citing “laws” or
“best practices” are just a fallacious arguments from authority.

One of the difficulties with argueing against “best practices” is that it often
goes something like this:

  • “X is not according to best practices”

  • “I think X is better because Y”

  • “But it’s not following best practice Z! Here is a book about it! Why don’t
    you follow it?! Do you want to write bad code?!”

There is kind of a gaslighting effect here, because it’s very natural to assume
that maybe you should be following the “best practice”, especially when
declared with great arrogance.

This is the same fallacious argument people use for safety:

  • “I don’t X will improve safety.”

  • “What?! You don’t care about safety?!”
  • or: “Better safe than sorry!”

Which is why safety regulation only grows and never shrinks, even when the
regulation just makes no sense eat all: arguing against it is hard, because the
look of things is against you. I call this the Safety Fallacy.

Metasploit Weekly Wrap-Up

Post Syndicated from Jack Heysel original https://blog.rapid7.com/2024/11/15/metasploit-weekly-wrap-up-43/

Palo Alto Expedition RCE module

Metasploit Weekly Wrap-Up

This week’s release includes an exploit module for the Palo ALto Expedition exploit chain that’s been making headlines recently. The first vulnerability, CVE-2024-5910, allows attackers to reset the password of the admin user. The second vulnerability, CVE-2024-9464 is an authenticated OS command injection. The module makes use of both vulnerabilities in order to obtain unauthenticated RCE in the context of the user www-data.

New module content (1)

Palo Alto Expedition Remote Code Execution (CVE-2024-5910 and CVE-2024-9464)

Authors: Brian Hysell, Enrique Castillo, Michael Heinzl, and Zach Hanley
Type: Exploit
Pull request: #19557 contributed by h4x-x0r
Path: linux/http/paloalto_expedition_rce
AttackerKB reference: CVE-2024-24809

Description: Adds a module to chain CVE-2024-5910, a password reset vulnerability with CVE-2024-9464, an authenticated command-injection vulnerability to gain code execution on PaloAlto Expedition servers between versions after 1.2 and before 1.2.92 with or without knowledge of the credentials.

Bugs fixed (3)

  • #19610 from cgranleese-r7 – Fixes the bruteforce summary table to correctly output the identified credentials as part of the smb_login module. This functionality is behind the features set show_successful_logins true command.
  • #19617 from sjanusz-r7 – Fixes a crash when running against a shell session which does not echo the executed commands.
  • #19623 from adfoster-r7 – This fixes a bug in the logic that fetches stored Kerberos tickets.

Documentation added (2)

  • #19369 from Adithya2357 – This improves the clarity and organization of the Metasploit Framework’s README documentation. It restructures content into distinct categories, updates installation instructions, enhances usage guidance, and provides a detailed contributing section.
  • #19635 from adfoster-r7 – Update the Kerberos enumusers module description to include a note about ASREPRoast attacks.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

Replicate changes from databases to Apache Iceberg tables using Amazon Data Firehose (in preview)

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/replicate-changes-from-databases-to-apache-iceberg-tables-using-amazon-data-firehose/

Today, we’re announcing the availability, in preview, of a new capability in Amazon Data Firehose that captures changes made in databases such as PostgreSQL and MySQL and replicates the updates to Apache Iceberg tables on Amazon Simple Storage Service (Amazon S3).

Apache Iceberg is a high-performance open-source table format for performing big data analytics. Apache Iceberg brings the reliability and simplicity of SQL tables to S3 data lakes and makes it possible for open source analytics engines such as Apache Spark, Apache Flink, Trino, Apache Hive, and Apache Impala to concurrently work with the same data.

This new capability provides a simple, end-to-end solution to stream database updates without impacting transaction performance of database applications. You can set up a Data Firehose stream in minutes to deliver change data capture (CDC) updates from your database. Now, you can easily replicate data from different databases into Iceberg tables on Amazon S3 and use up-to-date data for large-scale analytics and machine learning (ML) applications.

Typical Amazon Web Services (AWS) enterprise customers use hundreds of databases for transactional applications. To perform large scale analytics and ML on the latest data, they want to capture changes made in databases, such as when records in a table are inserted, modified, or deleted, and deliver the updates to their data warehouse or Amazon S3 data lake in open source table formats such as Apache Iceberg.

To do so, many customers develop extract, transform, and load (ETL) jobs to periodically read from databases. However, ETL readers impact database transaction performance, and batch jobs can add several hours of delay before data is available for analytics. To mitigate impact on database transaction performance, customers want the ability to stream changes made in the database. This stream is referred to as a change data capture (CDC) stream.

I met multiple customers that use open source distributed systems, such as Debezium, with connectors to popular databases, an Apache Kafka Connect cluster, and Kafka Connect Sink to read the events and deliver them to the destination. The initial configuration and test of such systems involves installing and configuring multiple open source components. It might take days or weeks. After setup, engineers have to monitor and manage clusters, and validate and apply open source updates, which adds to the operational overhead.

With this new data streaming capability, Amazon Data Firehose adds the ability to acquire and continually replicate CDC streams from databases to Apache Iceberg tables on Amazon S3. You set up a Data Firehose stream by specifying the source and destination. Data Firehose captures and continually replicates an initial data snapshot and then all subsequent changes made to the selected database tables as a data stream. To acquire CDC streams, Data Firehose uses the database replication log, which reduces impact on database transaction performance. When the volume of database updates increases or decreases, Data Firehose automatically partitions the data, and persists records until they’re delivered to the destination. You don’t have to provision capacity or manage and fine-tune clusters. In addition to the data itself, Data Firehose can automatically create Apache Iceberg tables using the same schema as the database tables as part of the initial Data Firehose stream creation and automatically evolve the target schema, such as new column addition, based on source schema changes.

Since Data Firehose is a fully managed service, you don’t have to rely on open source components, apply software updates, or incur operational overhead.

The continual replication of database changes to Apache Iceberg tables in Amazon S3 using Amazon Data Firehose provides you with a simple, scalable, end-to-end managed solution to deliver CDC streams into your data lake or data warehouse, where you can run large-scale analysis and ML applications.

Let’ see how to configure a new pipeline
To show you how to create a new CDC pipeline, I setup a Data Firehose stream using the AWS Management Console. As usual, I also have the choice to use the AWS Command Line Interface (AWS CLI), AWS SDKs, AWS CloudFormation, or Terraform.

For this demo, I choose a MySQL database on Amazon Relational Database Service (Amazon RDS) as source. Data Firehose also works with self-managed databases on Amazon Elastic Compute Cloud (Amazon EC2). To establish connectivity between my virtual private cloud (VPC)—where the database is deployed—and the RDS API without exposing the traffic to the internet, I create an AWS PrivateLink VPC service endpoint. You can learn how to create a VPC service endpoint for RDS API by following instructions in the Amazon RDS documentation.

I also have an S3 bucket to host the Iceberg table, and I have an AWS Identity and Access Management (IAM) role setup with correct permissions. You can refer to the list of prerequisites in the Data Firehose documentation.

To get started, I open the console and navigate to the Amazon Data Firehose section. I can see the stream already created. To create a new one, I select Create Firehose stream.

Create Firehose Stream

I select a Source and Destination. In this example: a MySQL database and Apache Iceberg Tables. I also enter a Firehose stream name for my stream.

Create Firehose Stream - screen 1

I enter the fully qualified DNS name of my Database endpoint and the Database VPC endpoint service name. I verify that Enable SSL is checked and, under Secret name, I select the name of the secret in AWS Secrets Manager where the database username and password are securely stored.

Create Firehose Stream - screen 2

Next, I configure Data Firehose to capture specific data by specifying databases, tables, and columns using explicit names or regular expressions.

I must create a watermark table. A watermark, in this context, is a marker used by Data Firehose to track the progress of incremental snapshots of database tables. It helps Data Firehose identify which parts of the table have already been captured and which parts still need to be processed. I can create the watermark table manually or let Data Firehose automatically create it for me. In that case, the database credentials passed to Data Firehose must have permissions to create a table in the source database.

Create Firehose Stream - screen 3

Next, I configure the S3 bucket Region and name to use. Data Firehose can automatically create the Iceberg tables when they don’t exist yet. Similarly, it can update the Iceberg table schema when detecting a change in your database schema.

Create Firehose Stream - screen 4

As a final step, it’s important to enable Amazon CloudWatch error logging to get feedback about the stream progress and the eventual errors. You can configure a short retention period on the CloudWatch log group to reduce the cost of log storage.

After having reviewed my configuration, I select Create Firehose stream.

Create Firehose Stream - screen 5

Once the stream is created, it will start to replicate the data. I can monitor the stream’s status and check for eventual errors.

Create Firehose Stream - screen 6

Now, it’s time to test the stream.

I open a connection to the database and insert a new line in a table.

Firehose - MySQL

Then, I navigate to the S3 bucket configured as the destination and I observe that a file has been created to store the data from the table.

View parquet files on S3 bucket

I download the file and inspect its content with the parq command (you can install that command with pip install parquet-cli)

Parquet file content

Of course, downloading and inspecting Parquet files is something I do only for demos. In real life, you’re going to use AWS Glue and Amazon Athena to manage your data catalog and to run SQL queries on your data.

Things to know
Here are a few additional things to know.

This new capability supports self-managed PostgreSQL and MySQL databases on Amazon EC2 and the following databases on Amazon RDS:

The team will continue to add support for additional databases during the preview period and after general availability. They told me they are already working on supporting SQL Server, Oracle, and MongoDB databases.

Data Firehose uses AWS PrivateLink to connect to databases in your Amazon Virtual Private Cloud (Amazon VPC).

When setting up an Amazon Data Firehose delivery stream, you can either specify specific tables and columns or use wildcards to specify a class of tables and columns. When you use wildcards, if new tables and columns are added to the database after the Data Firehose stream is created and if they match the wildcard, Data Firehose will automatically create those tables and columns in the destination.

Pricing and availability
The new data streaming capability is available today in all AWS Regions except China Regions, AWS GovCloud (US) Regions, and Asia Pacific (Malaysia) Regions. We want you to evaluate this new capability and provide us with feedback. There are no charges for your usage at the beginning of the preview. At some point in the future, it will be priced based on your actual usage, for example, based on the quantity of bytes read and delivered. There are no commitments or upfront investments. Make sure to read the pricing page to get the details.

Now, go configure your first continual database replication to Apache Iceberg tables on Amazon S3 and visit http://aws.amazon.com/firehose.

— seb

[$] Two approaches to tightening restrictions on loadable modules

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

The kernel’s loadable-module facility allows code to be loaded into (and
sometimes removed from) a running kernel. Among other things, loadable
modules make it possible to run a kernel with only the subsystems needed
for the system’s hardware and workload. Loadable modules can also make it
easy for out-of-tree code to access parts of the kernel that developers
would prefer to keep private; this has led to many discussions in the
past. The topic has returned to the kernel’s mailing lists with two
different patch sets aimed at further tightening the restrictions applied
to loadable modules.