Bottomley: Solving the Looming Developer Liability Problem

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

James Bottomley writes
that open-source developers are increasingly likely to be held liable for
flaws in their code and suggests a solution:

Indemnification means one party, in particular circumstances,
agreeing to be on the hook for the legal responsibilities of
another party. This is actually a well known way not of avoiding
liability but transferring it to where it belongs. As such, it’s
easily sellable in the court of public opinion: we’re not looking
to avoid liability, merely trying to make sure it lands on those
who are making all the money from the code.

Next-Gen Broadcom PCIe Switches to Support AMD Infinity Fabric XGMI to Counter NVIDIA NVLink

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/next-gen-broadcom-pcie-switches-to-support-amd-infinity-fabric-xgmi-to-counter-nvidia-nvlink/

Broadcom said it will support AMD XGMI or Infinity Fabric on its next-gen PCIe switches and we expect XGMI NICs in a big counter to NVIDIA

The post Next-Gen Broadcom PCIe Switches to Support AMD Infinity Fabric XGMI to Counter NVIDIA NVLink appeared first on ServeTheHome.

[$] Some recent and notable changes to Rust

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

The Rust project makes incremental releases every six
weeks, a fact that makes it easy to overlook some of the
interesting changes coming to the language, such as new
ABIs, better debugger support, asynchronous traits, and
support for C strings.
The end of the year provides an opportunity to look back
over the past several months of updates, and to look
forward to what to expect in 2024.

Blue/Green Deployments with Amazon ECS using Amazon CodeCatalyst

Post Syndicated from Hareesh Iyer original https://aws.amazon.com/blogs/devops/blue-green-deployments-with-amazon-ecs-using-amazon-codecatalyst/

Amazon CodeCatalyst is a modern software development service that empowers teams to deliver software on AWS easily and quickly. Amazon CodeCatalyst provides one place where you can plan, code, and build, test, and deploy your container applications with continuous integration/continuous delivery (CI/CD) tools.

In this post, we will walk-through how you can configure Blue/Green and canary deployments for your container workloads within Amazon CodeCatalyst.

Pre-requisites 

To follow along with the instructions, you’ll need:

  • An AWS account. If you don’t have one, you can create a new AWS account.
  • An Amazon Elastic Container Service (Amazon ECS) service using the Blue/Green deployment type. If you don’t have one, follow the Amazon ECS tutorial and complete steps 1-5.
  • An Amazon Elastic Container Registry (Amazon ECR) repository named codecatalyst-ecs-image-repo. Follow the Amazon ECR user guide to create one.
  • An Amazon CodeCatalyst space, with an empty Amazon CodeCatalyst project named codecatalyst-ecs-project and an Amazon CodeCatalyst environment called codecatalyst-ecs-environment. Follow the Amazon CodeCatalyst tutorial to set these up.
  • Follow the Amazon CodeCatalyst user guide to associate your account to the environment.

Walkthrough 

Now that you have setup an Amazon ECS cluster and configured Amazon CodeCatalyst to perform deployments, you can configure Blue/Green deployment for your workload. Here are the high-level steps:

  • Collect details of the Amazon ECS environment that you created in the prerequisites step.
  • Add source files for the containerized application to Amazon CodeCatalyst.
  • Create Amazon CodeCatalyst Workflow.
  • Validate the setup.

Step 1: Collect details from your ECS service and Amazon CodeCatalyst role

In this step, you will collect information from your prerequisites that will be used in the Blue/Green Amazon CodeCatalyst configuration further down this post.

If you followed the prerequisites tutorial, below are AWS CLI commands to extract values that are used in this post. You can run this on your local workstation or with AWS CloudShell in the same region you created your Amazon ECS cluster.

ECSCLUSTER='tutorial-bluegreen-cluster'
ECSSERVICE='service-bluegreen'

ECSCLUSTERARN=$(aws ecs describe-clusters --clusters $ECSCLUSTER --query 'clusters[*].clusterArn' --output text)
ECSSERVICENAME=$(aws ecs describe-services --services $ECSSERVICE --cluster $ECSCLUSTER  --query 'services[*].serviceName' --output text)
TASKDEFARN=$(aws ecs describe-services --services $ECSSERVICE --cluster $ECSCLUSTER  --query 'services[*].taskDefinition' --output text)
TASKROLE=$(aws ecs describe-task-definition --task-definition tutorial-task-def --query 'taskDefinition.executionRoleArn' --output text)
ACCOUNT=$(aws sts get-caller-identity --query "Account" --output text)

echo Account_ID value: $ACCOUNT
echo EcsRegionName value: $AWS_DEFAULT_REGION
echo EcsClusterArn value: $ECSCLUSTERARN
echo EcsServiceName value: $ECSSERVICENAME
echo TaskDefinitionArn value: $TASKDEFARN
echo TaskExecutionRoleArn value: $TASKROLE

Note down the values of Account_ID, EcsRegionName, EcsClusterArn, EcsServiceName, TaskDefinitionArn and TaskExecutionRoleArn. You will need these values in later steps.

Step 2: Add Amazon IAM roles to Amazon CodeCatalyst

In this step, you will create a role called CodeCatalystWorkflowDevelopmentRole-spacename to provide Amazon CodeCatalyst service permissions to build and deploy applications. This role is only recommended for use with development accounts and uses the AdministratorAccess AWS managed policy, giving it full access to create new policies and resources in this AWS account.

  • In Amazon CodeCatalyst, navigate to your space. Choose the Settings tab.
  • In the Navigation page, select AWS accounts. A list of account connections appears. Choose the account connection that represents the AWS account where you created your build and deploy roles.
  • Choose Manage roles from AWS management console.
  • The Add IAM role to Amazon CodeCatalyst space page appears. You might need to sign in to access the page.
  • Choose Create CodeCatalyst development administrator role in IAM. This option creates a service role that contains the permissions policy and trust policy for the development role.
  • Note down the role name. Choose Create development role.

Step 3: Create Amazon CodeCatalyst source repository

In this step, you will create a source repository in CodeCatalyst. This repository stores the tutorial’s source files, such as the task definition file.

  • In Amazon CodeCatalyst, navigate to your project.
  • In the navigation pane, choose Code, and then choose Source repositories.
  • Choose Add repository, and then choose Create repository.
  •  In Repository name, enter:

codecatalyst-advanced-deployment

  • Choose Create.

Step 4: Create Amazon CodeCatalyst Dev Environment

In this step, you will create a Amazon CodeCatalyst Dev environment to work on the sample application code and configuration in the codecatalyst-advanced-deployment repository. Learn more about Amazon CodeCatalyst dev environments in Amazon CodeCatalyst user guide.

  • In Amazon CodeCatalyst, navigate to your project.
  • In the navigation pane, choose Code, and then choose Source repositories.
  • Choose the source repository for which you want to create a dev environment.
  • Choose Create Dev Environment.
  • Choose AWS Cloud9 from the drop-down menu.
  • In Create Dev Environment and open with AWS Cloud9 page (Figure 1), choose Create to create a Cloud9 development environment.

Create Dev Environment in Amazon CodeCatalyst

Figure 1: Create Dev Environment in Amazon CodeCatalyst

AWS Cloud9 IDE opens on a new browser tab. Stay in AWS Cloud9 window to continue with Step 5.

Step 5: Add Source files to Amazon CodeCatalyst source repository

In this step, you will add source files from a sample application from GitHub to Amazon CodeCatalyst repository. You will be using this application to configure and test blue-green deployments.

  • On the menu bar at the top of the AWS Cloud9 IDE, choose Window, New Terminal or use an existing terminal window.
  • Download the Github project as a zip file, un-compress it and move it to your project folder by running the below commands in the terminal.

cd codecatalyst-advanced-deployment
wget -O SampleApp.zip https://github.com/build-on-aws/automate-web-app-amazon-ecs-cdk-codecatalyst/zipball/main/
unzip SampleApp.zip
mv build-on-aws-automate-web-app-amazon-ecs-cdk-codecatalyst-*/SampleApp/* .
rm -rf build-on-aws-automate-web-app-amazon-ecs-cdk-codecatalyst-*
rm SampleApp.zip

  • Update the task definition file for the sample application. Open task.json in the current directory. Find and replace “<arn:aws:iam::<account_ID>:role/AppRole> with the value collected from step 1: <TaskExecutionRoleArn>.
  • Amazon CodeCatalyst works with AWS CodeDeploy to perform Blue/Green deployments on Amazon ECS. You will create an Application Specification file, which will be used by CodeDeploy to manage the deployment. Create a file named appspec.yaml inside the codecatalyst-advanced-deployment directory. Update the <TaskDefinitionArn> with value from Step 1.
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "<TaskDefinitionArn>"
        LoadBalancerInfo:
          ContainerName: "MyContainer"
          ContainerPort: 80
        PlatformVersion: "LATEST"
  • Commit the changes to Amazon CodeCatalyst repository by following the below commands. Update <your_email> and <your_name> with your email and name.

git config user.email "<your_email>"
git config user.name "<your_name>"
git add .
git commit -m "Initial commit"
git push

Step 6: Create Amazon CodeCatalyst Workflow

In this step, you will create the Amazon CodeCatalyst workflow which will automatically build your source code when changes are made. A workflow is an automated procedure that describes how to build, test, and deploy your code as part of a continuous integration and continuous delivery (CI/CD) system. A workflow defines a series of steps, or actions, to take during a workflow run.

  • In the navigation pane, choose CI/CD, and then choose Workflows.
  • Choose Create workflow. Select codecatalyst-advanced-deployment from the Source repository dropdown.
  • Choose main in the branch. Select Create (Figure 2). The workflow definition file appears in the Amazon CodeCatalyst console’s YAML editor.
    Create workflow page in Amazon CodeCatalyst

    Figure 2: Create workflow page in Amazon CodeCatalyst

  • Update the workflow by replacing the contents in the YAML editor with the below. Replace <Account_ID> with your AWS account ID. Replace <EcsRegionName>, <EcsClusterArn>, <EcsServiceName> with values from Step 1. Replace <CodeCatalyst-Dev-Admin-Role> with the Role Name from Step 3.
Name: BuildAndDeployToECS
SchemaVersion: "1.0"

# Set automatic triggers on code push.
Triggers:
  - Type: Push
    Branches:
      - main

Actions:
  Build_application:
    Identifier: aws/build@v1
    Inputs:
      Sources:
        - WorkflowSource
      Variables:
        - Name: region
          Value: <EcsRegionName>
        - Name: registry
          Value: <Account_ID>.dkr.ecr.<EcsRegionName>.amazonaws.com
        - Name: image
          Value: codecatalyst-ecs-image-repo
    Outputs:
      AutoDiscoverReports:
        Enabled: false
      Variables:
        - IMAGE
    Compute:
      Type: EC2
    Environment:
      Connections:
        - Role: <CodeCatalystPreviewDevelopmentAdministrator role>
          Name: "<Account_ID>"
      Name: codecatalyst-ecs-environment
    Configuration:
      Steps:
        - Run: export account=`aws sts get-caller-identity --output text | awk '{ print $1 }'`
        - Run: aws ecr get-login-password --region ${region} | docker login --username AWS --password-stdin ${registry}
        - Run: docker build -t appimage .
        - Run: docker tag appimage ${registry}/${image}:${WorkflowSource.CommitId}
        - Run: docker push --all-tags ${registry}/${image}
        - Run: export IMAGE=${registry}/${image}:${WorkflowSource.CommitId}
  RenderAmazonECStaskdefinition:
    Identifier: aws/ecs-render-task-definition@v1
    Configuration:
      image: ${Build_application.IMAGE}
      container-name: MyContainer
      task-definition: task.json
    Outputs:
      Artifacts:
        - Name: TaskDefinition
          Files:
            - task-definition*
    DependsOn:
      - Build_application
    Inputs:
      Sources:
        - WorkflowSource
  DeploytoAmazonECS:
    Identifier: aws/ecs-deploy@v1
    Configuration:
      task-definition: /artifacts/DeploytoAmazonECS/TaskDefinition/${RenderAmazonECStaskdefinition.task-definition}
      service: <EcsServiceName>
      cluster: <EcsClusterArn>
      region: <EcsRegionName>
      codedeploy-appspec: appspec.yaml
      codedeploy-application: tutorial-bluegreen-app
      codedeploy-deployment-group: tutorial-bluegreen-dg
      codedeploy-deployment-description: "Blue-green deployment for sample app"
    Compute:
      Type: EC2
      Fleet: Linux.x86-64.Large
    Environment:
      Connections:
        - Role: <CodeCatalyst-Dev-Admin-Role>
        # Add account id within quotes. Eg: "12345678"
          Name: "<Account_ID>"
      Name: codecatalyst-ecs-environment
    DependsOn:
      - RenderAmazonECStaskdefinition
    Inputs:
      Artifacts:
        - TaskDefinition
      Sources:
        - WorkflowSource

The workflow above does the following:

  • Whenever a code change is pushed to the repository, a Build action is triggered. The Build action builds a container image and pushes the image to the Amazon ECR repository created in Step 1.
  • Once the Build stage is complete, the Amazon ECS task definition is updated with the new ECR repository image.
  • The DeploytoECS action then deploys the new image to Amazon ECS using Blue/Green Approach.

To confirm everything was configured correctly, choose the Validate button. It should add a green banner with The workflow definition is valid at the top.

Select Commit to add the workflow to the repository (Figure 3)

Commit Workflow page in Amazon CodeCatalyst
Figure 3: Commit workflow page in Amazon CodeCatalyst

The workflow file is stored in a ~/.codecatalyst/workflows/ folder in the root of your source repository. The file can have a .yml or .yaml extension.

Let’s review our work, using the load balancer’s URL that you created during prerequisites, paste it into your browser. Your page should look similar to (Figure 4).

Sample Application (Blue Version)
Figure 4: Sample Application (Blue version)

Step 7: Validate the setup

To validate the setup, you will make a small change to the sample application.

  • Open Amazon CodeCatalyst dev environment that you created in Step 4.
  • Update your local copy of the repository. In the terminal run the command below.

git pull

  • In the terminal, navigate to /templates folder. Open index.html and search for “Las Vegas”. Replace the word with “New York”. Save the file.
  • Commit the change to the repository using the commands below.

git add .
git commit -m "Updating the city to New York"
git push

After the change is committed, the workflow should start running automatically. You can monitor of the workflow run in Amazon CodeCatalyst console (Figure 5)
Blue/Green Deployment Progress on Amazon CodeCatalyst

Figure 5: Blue/Green Deployment Progress on Amazon CodeCatalyst

You can also see the deployment status on the AWS CodeDeploy deployment page (Figure 6)

  • Going back to the AWS console.
  • In the upper left search bar, type in “CodeDeploy”.
  • In the left hand menu, select Deployments.

Blue/Green Deployment Progress on AWS CodeDeploy
Figure 6: Blue/Green Deployment Progress on AWS CodeDeploy

Let’s review our update, using the load balancer’s URL that you created during pre-requisites, paste it into your browser. Your page should look similar to (Figure 7).
Sample Application (Green version)

Figure 7: Sample Application (Green version)

Cleanup

If you have been following along with this workflow, you should delete the resources you deployed so you do not continue to incur charges.

  • Delete the Amazon ECS service and Amazon ECS cluster from AWS console.
  • Manually delete Amazon CodeCatalyst dev environment, source repository and project from your CodeCatalyst Space.
  • Delete the AWS CodeDeploy application through console or CLI.

Conclusion

In this post, we demonstrated how you can configure Blue/Green deployments for your container workloads using Amazon CodeCatalyst workflows. The same approach can be used to configure Canary deployments as well. Learn more about AWS CodeDeploy configuration for advanced container deployments in AWS CodeDeploy user guide.

William Cardoso

William Cardoso is a Solutions Architect at Amazon Web Services based in South Florida area. He has 20+ years of experience in designing and developing enterprise systems. He leverages his real world experience in IT operations to work with AWS customers providing architectural and best practice recommendations for new and existing solutions. Outside of work, William enjoys woodworking, walking and cooking for friends and family.

Piyush Mattoo

Piyush Mattoo is a Solution Architect for enterprises at Amazon Web Services. He is a software technology leader with over 15 years of experience building scalable and distributed software systems that require a combination of broad T-shaped skills across multiple technologies. He has an educational background in Computer Science with a Masters degree in Computer and Information Science from University of Massachusetts. He is based out of Southern California and current interests include outdoor camping and nature walks.

Hareesh Iyer

Hareesh Iyer is a Senior Solutions Architect at AWS. He helps customers build scalable, secure, resilient and cost-efficient architectures on AWS. He is passionate about cloud-native patterns, containers and microservices.

Kernel prepatch 6.7-rc5

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

The 6.7-rc5 kernel prepatch is out for
testing.

Nothing looks particularly scary, which is good, because if it had
been, I wouldn’t have had the capacity to deal with it last week.

Let’s hope it stays that way even as I am getting better. Because the
holidays are almost upon us, and I’m woefully underprepared.

Електронното бъдеще е възможно, но не е неизбежно

Post Syndicated from Bozho original https://blog.bozho.net/blog/4180

С редица законодателни промени в последните месеци беше даден нов тласък на електронното управление. Разбира се, както се е доказвало многократно през годините, обнародването на един хубав текст в Държавен вестник не означава, че той ще бъде реализиран на практика, поради което предстои сериозна работа в изпълнителната власт.

Измененията в Закона за електронното управление бяха изготвени в Министерството на електронното управление (МЕУ) в предходното редовно правителство и приети през септември. В тях има редица подобрения, които изискват от администрацията сериозна работа.

Едно от тези изменения е приравняването на служебните справки по електронен път на удостоверенията, които администрацията изисква от гражданите. Задължението за администрацията да събира по служебен път информация, с която държавата вече разполага, е в Закона за електронното управление от 2009 г. За съжаление, практиката е, че администрациите цитират специалните закони, по които работят, и казват, че те се прилагат, а там по инерция законодателят е сложил изискване на удостоверения. За да не трябва да променяме цялата нормативна уредба, с измененията в закона се приравнява служебната справка на удостоверенията, изисквани по специалните закони. В допълнение се въвежда забрана за това в подзаконов акт да се предвижда изискване на удостоверения, както и гаранции за сигурността на служебното събиране, като по този начин удостоверенията, на които гражданите и бизнесът са куриери, най-накрая трябва да отпаднат. Това ще се случи, след като изпълнителната власт преправи наредбите си в съответствие със закона, за което Министерството на електронното управление е поело ангажимент.

Друга важна промяна е отпадането на изискването за квалифициран електронен подпис при заявяване на електронни услуги от физически лица. Електронният подпис е сигурен, но много неудобен и това през годините е било бариера пред използването на наличните е-услуги. С изменението вече няма да се изисква заявленията да бъдат подписвани, което ще позволи заявяване след идентификация по множество различни начини – вкл. с бъдещата електронна идентификация, с ПИК и др. Това означава надграждане на системи, така че те да позволят по-широко използване, но този процес вече започва.

Със същите изменения се предвижда догодина всички регистри, които държавата води, да станат електронни. За целта се създава централизирана система за управление на регистри, така че да не се налага всеки регистър да се електронизира поотделно с отделна обществена поръчка, а разходите за бюджета да станат непосилни. Централизираната система ще позволява създаването на нов регистър с няколко клика. Всички тетрадки, екселски таблици и остарели информационни системи ще могат да бъдат мигрирани към съвременна система, която да е достатъчно защитена, да се грижи за резервните копия, за връзките с други регистри, за публикуване на отворени данни, за проследимост на действията в тях – все неща, които една екселска таблица не може да предостави.

Споменавайки електронната идентификация, трябва да дадем повече детайли – след като процедурата за нови лични документи на МВР беше обединена с процедурата за електронна идентификация, общата такава „заби“ в съда в Люксембург. Това наложи Министерството на електронното управление през 2022 г. да възложи изграждане на мобилно приложение за електронна идентификация, какъвто е правилният подход от няколко години насам. За съжаление, през лятото на 2022 г. МВР не даде достъп на министерството до данни, необходими за функционирането на приложението. Едва в края на 2022 г. съдът на Европейския съюз и съответно Върховният административен съд позволиха сключването на договор от страна на МВР. В момента МВР изпълнява своя проект, подготвен през 2016 г., като Министерството на електронното управление опитва да му предостави вече изграденото по мобилното приложение през изминалата година, за да могат гражданите да получат електронна идентичност в мобилните си устройства дори без нужда от смяна на личните си карти. Когато такова приложение е налично, в комбинация с отпадането на изискването за подпис всеки гражданин ще може да ползва всички налични електронни услуги.

На следващо място през септември бяха приети измененията в Кодекса на труда, с които се предвижда отпадане на трудовата книжка. Данните от нея ще се въвеждат в регистър в НАП, който ще бъде базиран на настоящия регистър на трудовите договори. НАП има срок до юни 2025 г. да направи бизнес анализа, да измени подзаконовата уредба и да надгради регистъра. Когато това се случи, трудовите книжки ще се ползват само при пенсиониране, и то само от служители, които имат стаж през миналото хилядолетие. Причината за това е, че масовото дигитализиране на старите хартиени трудови книжки, в които има доста грешки и злоупотреби, и за които отговорността е на служителите, е почти непосилна задача за реализиране в мащаб. Важното е, че избраният подход ще позволи трудовата книжка да отпадне от ежедневието и на бизнеса, и на служителите.

Други важни промени, които ще бъдат усетени от гражданите, са измененията в Закона за движението по пътищата. Те отварят път за електронно връчване, получаване на известия по имейл или sms за издадени електронни фишове, както и възможност за плащането им с карта онлайн още преди да бъдат връчени официално. Всички тези мерки ще позволят на добросъвестните водачи да си плащат глобите. Отпадането на синия талон от своя страна освен символно значение на скъсване с хартиеното минало прави възможно изцяло електронен процес по административно наказване по Закона за движението по пътищата – нещо, което синият талон спираше заради нуждата да бъде отнет и съответно върнат.

Не можем да пропуснем и измененията в Закона за достъп до обществена информация – на пръв поглед скучно транспониране на европейска директива, но на практика въвеждащ задължения за всички администрации да поддържат отворени данни в реално време чрез програмни интерфейси. Макар досега да имаше такива текстове, те бяха в наредба и тя рядко се спазваше. Оттук нататък липсата на такива интерфейси ще може да бъде санкционирана, а ползата от тях е безпрецедентна прозрачност. Един пример – данните за всички плащания на държавата през системата СЕБРА, които отворихме еднократно през 2022 г., сега ще трябва да бъдат достъпни в реално време.

По Плана за възстановяване и устойчивост (ПВУ) също предстоят важни проекти и мерки. Вече описахме напредъка по една от тях – за дигитализация на всички регистри. Първият голям проект е за дигитализация на хартиените архиви на имотния регистър, регистъра на населението и кадастъра. Там за разлика от трудовите книжки хартиените документи се съхраняват от администрацията по определен ред и подлежат на систематично привеждане в цифров вид заедно с необходимите метаданни. Това ще позволи най-накрая да имаме истински имотен регистър, да не трябва да заявяваме удостоверение за наследници по постоянен адрес (защото наследниците се установяват и чрез „ровене“ в хартиените картони за гражданска регистрация), ще бъдат усетени и много други ползи.

Вторият голям проект по ПВУ е осигуряването на високоскоростна свързаност за всички региони в страната. Мрежата на Министерството на електронното управление ще достигне до всички 265 общини, а телекомите и интернет доставчиците ще осигурят покритие с висока скорост на слабо населените места. Така например в пощенските клонове ще могат да бъдат предоставяни административни услуги, като пощите ще бъдат в ролята на посредник (отново изменение, прието с промените в Закона за електронното управление). За съжаление, поради забавяне, натрупано при служебния кабинет, големият проект за дигитализация на пощите отпадна от ПВУ, но не отпада и възможността те да предоставят услуги, за да не трябва хората в малките населени места да ходят до областния град, за да ползват административни услуги.

Продължава да има нужда от подобрения в много закони, но основната работа е свършена в последните месеци. Сега предстои изпълнителната власт и администрацията да използват политическата подкрепа, която има за тези мерки, за да може след две години да имаме променена държава – по-електронна, по-ефективна, по-удобна за гражданите и бизнеса, по-сигурна и по-защитена от корупционни практики.

За да изпълни всичко това обаче, държавата трябва да организира по-добре възлагането на софтуер и други информационни и комуникационни технологии. Това е важна точка в програмата на правителството, без която изброените мерки могат да се окажат затлачени от безкрайни процедури, недобросъвестни изпълнителни, липса на вътрешен капацитет за управление на проекти, саботаж и административно безвремие. В програмата на правителството е включена промяна на начина, по който държавата ползва ИТ, като би трябвало тази промяна да намери своето законово изражение догодина.

Електронното бъдеще е възможно, но не е неизбежно – нужна е сериозна работа и активна политическа подкрепа, иначе има риск добрите намерения, макар и обнародвани в Държавен вестник, да не постигнат желания резултат.

(Статията е написана специално за сп. Мениджър)

Материалът Електронното бъдеще е възможно, но не е неизбежно е публикуван за пръв път на БЛОГодаря.

Facebook Enables Messenger End-to-End Encryption by Default

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/12/facebook-enables-messenger-end-to-end-encryption-by-default.html

It’s happened. Details here, and tech details here (for messages in transit) and here (for messages in storage)

Rollout to everyone will take months, but it’s a good day for both privacy and security.

Slashdot thread.

Ext4 data corruption in stable kernels

Post Syndicated from jake original https://lwn.net/Articles/954285/

There is a problem in multiple stable kernel releases that is causing data corruption in ext4 filesystems. It is caused by a problematic commit that is in multiple stable kernels:

The commit got merged in 6.5-rc1 so all stable kernels that have
91562895f803 (“ext4: properly sync file size update after O_SYNC direct
IO”) before 6.5 are corrupting data – I’ve noticed at least 6.1 is still
carrying the problematic commit.

More information can be found in a Debian bug report. It has also delayed the release of Debian 12.3 images. “Please do not upgrade any systems at this time, we urge caution for users
with UnattendeUpgrades configured.
”

(Thanks to Alex Ridevski for giving us a heads up on this.)

The collective thoughts of the interwebz