FerretDB 0.3 ya fue liberada, conoce las novedades de esta modernización de MangoDB

Hace algunas semanas compartimos aquí en el blog la noticia sobre el cambio del nombre del proyecto de MangoDB que permite reemplazar el DBMS orientado a documentos de MongoDB con PostgreSQL sin realizar cambios en el código de la aplicación.

El nuevo nombre del proyecto es FerretDB y recientemente se dio a conocer la liberación de la versión 0.3 del proyecto. La versión FerretDB 0.3 presenta el comando findAndModify, que modifica un documento pero devuelve su versión original, ademas de que se implementaron operadores de actualización de campo, entre otras cosas mas.

Para quienes aún desconocen de FerretDB, deben saber que este se implementa como un servidor proxy que traduce las llamadas a MongoDB en consultas SQL a PostgreSQL, lo que le permite usar PostgreSQL como almacenamiento real.

La necesidad de migración puede surgir en relación con la transición de MongoDB a una licencia SSPL no libre, que se basa en la licencia AGPLv3, pero no está abierta, ya que contiene un requisito discriminatorio para proporcionar bajo la licencia SSPL no solo la aplicación código en sí, sino también los códigos fuente de todos los componentes involucrados en la prestación del servicio en la nube.

El público objetivo principal de FerretDB son los usuarios que no utilizan las funciones avanzadas de MongoDB en sus aplicaciones, pero que desean utilizar una pila de software completamente abierta.

En la etapa actual de desarrollo, FerretDB aún admite solo una parte de las características de MongoDB que se usan con mayor frecuencia en las aplicaciones típicas. En el futuro, planean lograr una compatibilidad total con los controladores para MongoDB y brindar la capacidad de usar FerretDB como un reemplazo transparente para MongoDB.

MongoDB ocupa un nicho entre los sistemas rápidos y escalables que operan con datos clave/valor y los DBMS relacionales que son funcionales y fáciles de consultar.

MongoDB admite el almacenamiento de documentos en un formato similar a JSON, tiene un lenguaje bastante flexible para generar consultas, puede crear índices para varios atributos almacenados, proporciona almacenamiento eficiente de objetos binarios grandes, admite el registro de operaciones para cambiar y agregar datos a la base de datos, puede trabajar de acuerdo con el paradigma Map/Reduce, admite la replicación y la construcción de configuraciones tolerantes a fallas.

Debido a las diferencias en la semántica de las funciones json de PostgreSQL y MongoDB, hubo una discrepancia en el comportamiento al comparar y ordenar diferentes tipos. Para resolver este problema, ahora se extrae una muestra de datos redundantes de PostgreSQL y el filtrado del resultado se realiza en el lado de FerretDB, lo que hizo posible repetir el comportamiento de MongoDB en la mayoría de las situaciones.

Principales novedades de FerretDB 0.3

Tal y como se mencionó al inicio, la nueva versión de FerretDB 0.3 se destaca por introducir el comando findAndModify, que modifica un documento, pero devuelve su versión original.

Otros de los cambios que se destacan es que se ha mejorado el manejo del cero negativo, asi como tambien que se agregó el soporte para ordenar tipos de datos escalares.

Tambien se destacan los nuevos operadores de actualización de campo implementados: $inc y $set, además de que se agregó soporte para ordenar tipos de datos escalares.

Por otra parte, se menciona que se han realizado diversas mejoras para el manejo de las versiones de PostgreSQL y MongoDB.

Ademas de ello, también se destaca que se solucionó la prueba incorrecta para el operador $mod, tambien que se emite la prueba en todos los sistemas operativos ARM64 y que se agregó más visibilidad para los niveles de registro de errores del enrutador/proxy.

De los demás cambios que se destacan de esta nueva versión:

  • Actualizar CODEOWNERS
  • Sincronizar controladores ficticios y pg
  • Renombrar OP_*constantes a OpCode*constantes
  • Mejorar gopkg.in/yaml.v3
  • Bump gopkg.in/yaml.v3 en herramientas
  • Hacer tipo Path
  • Pánico en valores de pedidos inesperados
  • Agregue algunos comentarios a las funciones y variables
  • Eliminar código muerto

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/NR2ucKL
via IFTTT

En Ubuntu 22.10 se usará PipeWire en lugar de PulseAudio

Pipewire

Hace ya algunos días se dio a conocer la noticia que el repositorio de desarrollo de la versión Ubuntu 22.10 se movió para usar el servidor de medios PipeWire predeterminado para el procesamiento de audio.

Con este cambio, los paquetes relacionados con PulseAudio se han eliminado de los paquetes desktop y desktop-minimal, y por compatibilidad, en lugar de bibliotecas para interactuar con PulseAudio, se ha agregado una capa pipewire-pulse que se ejecuta sobre PipeWire, lo que le permite mantener todos los existentes clientes de PulseAudio funcionando.

La persona quien confirmo el cambio fue Heather Ellsworth de Canonical, quien mediante una publicación comento sobre la decisión de migrar completamente a PipeWire en Ubuntu 22.10.

Se observa que en Ubuntu 22.04 se usaron ambos servidores en la distribución: PipeWire se usó para procesar video al grabar screencasts y proporcionar acceso a la pantalla, pero el audio continuó procesándose usando PulseAudio. En Ubuntu 22.10, solo permanecerá PipeWire.

Así es, a partir de hoy, Kinetic iso (pendiente, aún no actual ya que se acaban de realizar los cambios) se ha actualizado para ejecutar solo pipewire y no pulseaudio. Asi que@copong, puede esperar esto para kinetic.

Para Jammy, puede notar que tiene tanto pipewire como pulseaudio ejecutándose. Esto se debe a que aún se usa pulseaudio para el audio, pero se usa pipewire para el video. (Se necesita Pipewire para transmitir y compartir pantallas en Wayland).

Espero que esto aclare nuestros planes con respecto a pipewire/pulseaudio, pero avísenos si tiene más preguntas.

Hace dos años, ya se implementó un cambio similar en la distribución de Fedora 34, que permitió brindar capacidades profesionales de procesamiento de audio, eliminar la fragmentación y unificar la infraestructura de audio para diferentes aplicaciones.

Para quienes desconocen de PipeWire, deben saber que este ofrece un modelo de seguridad avanzado que le permite administrar el acceso por dispositivo y por transmisión, lo que facilita la transmisión de audio y video desde y hacia contenedores aislados.

PipeWire puede procesar cualquier flujo de medios y puede mezclar y redirigir no solo flujos de audio, sino también flujos de video, así como administrar fuentes de video (dispositivos de captura de video, cámaras web o contenido de pantalla que muestran las aplicaciones). PipeWire también puede actuar como un servidor de audio de baja latencia y brindar una funcionalidad que combina las capacidades de PulseAudio y JACK , lo que incluye tener en cuenta las necesidades de los sistemas de procesamiento de audio profesionales que PulseAudio no podría reclamar.

De las características clave que se pueden destacar:

  • Capacidad de capturar y reproducir audio y video con demoras mínimas
  • Herramientas para el procesamiento de video y sonido en tiempo real
  • Arquitectura multiproceso que permite organizar el acceso compartido al contenido de varias aplicaciones
  • Modelo de procesamiento basado en gráficos de nodos multimedia con soporte para bucles de retroalimentación y actualizaciones de gráficos atómicos. Está permitido conectar controladores tanto dentro del servidor como en complementos externos
  • Interfaz eficiente para acceder a secuencias de video a través de descriptores de archivos y acceso de audio a través de un búfer de anillo compartido
  • Capacidad para procesar datos multimedia de cualquier proceso
  • La presencia de un complemento para GStreamer para simplificar la integración con las aplicaciones existentes
  • El soporte para entornos aislados y sistema de paquetes Flatpak
  • El soporte para complementos en formato SPA (Simple Plugin API) y la capacidad de crear complementos que funcionan en tiempo real duro
  • Sistema flexible para negociar formatos multimedia usados ​​y asignación de búfer
  • Capacidad de poder usar un solo proceso en segundo plano para enrutar audio y video.
  • La capacidad de actuar como un servidor de sonido, un centro para proporcionar video a las aplicaciones (por ejemplo, para la API de screencast de gnome-shell) y un servidor para controlar el acceso a los dispositivos de hardware de captura de video.

Finalmente para quienes estén interesados en poder conocer más al respecto sobre la nota, pueden consultar el hilo de la discusión en el siguiente enlace.

from Linux Adictos https://ift.tt/Bbowvcs
via IFTTT

What Counts as “Good Faith Security Research?”

The U.S. Department of Justice (DOJ) recently revised its policy on charging violations of the Computer Fraud and Abuse Act (CFAA), a 1986 law that remains the primary statute by which federal prosecutors pursue cybercrime cases. The new guidelines state that prosecutors should avoid charging security researchers who operate in “good faith” when finding and reporting vulnerabilities. But legal experts continue to advise researchers to proceed with caution, noting the new guidelines can’t be used as a defense in court, nor are they any kind of shield against civil prosecution.

In a statement about the changes, Deputy Attorney General Lisa O. Monaco said the DOJ “has never been interested in prosecuting good-faith computer security research as a crime,” and that the new guidelines “promote cybersecurity by providing clarity for good-faith security researchers who root out vulnerabilities for the common good.”

What constitutes “good faith security research?” The DOJ’s new policy (PDF) borrows language from a Library of Congress rulemaking (PDF) on the Digital Millennium Copyright Act (DMCA), a similarly controversial law that criminalizes production and dissemination of technologies or services designed to circumvent measures that control access to copyrighted works. According to the government, good faith security research means:

“…accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.”

“Security research not conducted in good faith — for example, for the purpose of discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services — might be called ‘research,’ but is not in good faith.”

The new DOJ policy comes in response to a Supreme Court ruling last year in Van Buren v. United States (PDF), a case involving a former police sergeant in Florida who was convicted of CFAA violations after a friend paid him to use police resources to look up information on a private citizen.

But in an opinion authored by Justice Amy Coney Barrett, the Supreme Court held that the CFAA does not apply to a person who obtains electronic information that they are otherwise authorized to access and then misuses that information.

Orin Kerr, a law professor at University of California, Berkeley, said the DOJ’s updated policy was not unexpected given the Supreme Court ruling in the Van Buren case. Kerr noted that while the new policy says one measure of “good faith” involves researchers taking steps to prevent harm to third parties, what exactly those steps might constitute is another matter.

“The DOJ is making clear they’re not going to prosecute good faith security researchers, but be really careful before you rely on that,” Kerr said. “First, because you could still get sued [civilly, by the party to whom the vulnerability is being reported], but also the line as to what is legitimate security research and what isn’t is still murky.”

Kerr said the new policy also gives CFAA defendants no additional cause for action.

“A lawyer for the defendant can make the pitch that something is good faith security research, but it’s not enforceable,” Kerr said. “Meaning, if the DOJ does bring a CFAA charge, the defendant can’t move to dismiss it on the grounds that it’s good faith security research.”

Kerr added that he can’t think of a CFAA case where this policy would have made a substantive difference.

“I don’t think the DOJ is giving up much, but there’s a lot of hacking that could be covered under good faith security research that they’re saying they won’t prosecute, and it will be interesting to see what happens there,” he said.

The new policy also clarifies other types of potential CFAA violations that are not to be charged. Most of these include violations of a technology provider’s terms of service, and here the DOJ says “violating an access restriction contained in a term of service are not themselves sufficient to warrant federal criminal charges.” Some examples include:

-Embellishing an online dating profile contrary to the terms of service of the dating website;
-Creating fictional accounts on hiring, housing, or rental websites;
-Using a pseudonym on a social networking site that prohibits them;
-Checking sports scores or paying bills at work.

ANALYSIS

Kerr’s warning about the dangers that security researchers face from civil prosecution is well-founded. KrebsOnSecurity regularly hears from security researchers seeking advice on how to handle reporting a security vulnerability or data exposure. In most of these cases, the researcher isn’t worried that the government is going to come after them: It’s that they’re going to get sued by the company responsible for the security vulnerability or data leak.

Often these conversations center around the researcher’s desire to weigh the rewards of gaining recognition for their discoveries with the risk of being targeted with costly civil lawsuits. And almost just as often, the source of the researcher’s unease is that they recognize they might have taken their discovery just a tad too far.

Here’s a common example: A researcher finds a vulnerability in a website that allows them to individually retrieve every customer record in a database. But instead of simply polling a few records that could be used as a proof-of-concept and shared with the vulnerable website, the researcher decides to download every single file on the server.

Not infrequently, there is also concern because at some point the researcher suspected that their automated activities might have actually caused stability or uptime issues with certain services they were testing. Here, the researcher is usually concerned about approaching the vulnerable website or vendor because they worry their activities may already have been identified internally as some sort of external cyberattack.

What do I take away from these conversations? Some of the most trusted and feared security researchers in the industry today gained that esteem not by constantly taking things to extremes and skirting the law, but rather by publicly exercising restraint in the use of their powers and knowledge — and by being effective at communicating their findings in a way that maximizes the help and minimizes the potential harm.

If you believe you’ve discovered a security vulnerability or data exposure, try to consider first how you might defend your actions to the vulnerable website or vendor before embarking on any automated or semi-automated activity that the organization might reasonably misconstrue as a cyberattack. In other words, try as best you can to minimize the potential harm to the vulnerable site or vendor in question, and don’t go further than you need to prove your point.

from Krebs on Security https://ift.tt/TFQPSOK
via IFTTT

Key insights from ESET’s latest Threat Report – Week in security with Tony Anscombe

A review of the key trends that defined the threatscape in the first four months of 2022 and what these developments mean for your cyber-defenses

The post Key insights from ESET’s latest Threat Report – Week in security with Tony Anscombe appeared first on WeLiveSecurity

from WeLiveSecurity https://ift.tt/OrGyKeb
via IFTTT