2025-07-10 Top Stories #

Giao thức Model Context Protocol (MCP) của Supabase có thể dẫn đến rò rỉ cơ sở dữ liệu SQL.
Tòa án Hoa Kỳ đã bác bỏ quy định “nhấp để hủy” của FTC, cho rằng quy trình xây dựng quy định có sai sót về thủ tục, quy định yêu cầu các công ty cung cấp phương thức hủy dịch vụ dễ dàng như đăng ký dịch vụ.
Tree Borrows của Rust thay thế cấu trúc ngăn xếp bằng cấu trúc cây, giải quyết các hạn chế của Stacked Borrows, thể hiện hiệu suất vượt trội trong thử nghiệm với 30.000 gói và đã giành được giải thưởng bài báo xuất sắc PLDI'25.
Lỗ hổng CVE-2025-48384 của Git thông qua việc chèn ký tự xuống dòng, kẻ tấn công có thể thực thi mã từ xa khi sao chép các submodule, người dùng cần cập nhật Git lên phiên bản đã sửa lỗi và thận trọng khi sử dụng tùy chọn –recursive.
Ikea chuyển sang tiêu chuẩn Thread và Matter, ra mắt hơn 20 thiết bị nhà thông minh, thay thế các thiết bị Zigbee, hỗ trợ khả năng tương thích với các thiết bị của các thương hiệu khác, dự kiến phát hành vào tháng 1 năm 2025.
Linda Yaccarino từ chức CEO của công ty X, sau hai năm tại vị, không nêu rõ lý do từ chức, công ty đã trải qua những thay đổi lớn sau khi bị Musk mua lại.
Nhiều API được gọi là “RESTful” không tuân thủ đầy đủ các nguyên tắc REST, đặc biệt là về mặt siêu phương tiện (HATEOAS), luận văn của Fielding định nghĩa các ràng buộc cốt lõi của REST.
Bulgaria sẽ chính thức gia nhập khu vực đồng euro vào ngày 1 tháng 1 năm 2026, tỷ giá hối đoái giữa Lev và Euro là 1,95583, đánh dấu một bước tiến quan trọng trong quá trình hội nhập kinh tế của nước này.
Framework Astro lấy HTML tĩnh làm cốt lõi, chỉ tải JavaScript khi cần tương tác, sử dụng “kiến trúc đảo” để tối ưu hóa hiệu suất, phù hợp với các trang web hướng nội dung, nhưng không phù hợp với SPA phức tạp.
RapidRAW là một trình chỉnh sửa ảnh RAW không phá hủy và được tăng tốc bằng GPU, được tạo bởi một nhà phát triển 18 tuổi, với mục tiêu trở thành một sự thay thế hiện đại cho Adobe Lightroom.

Supabase MCP có thể làm rò rỉ toàn bộ cơ sở dữ liệu SQL của bạn #

Supabase MCP can leak your entire SQL database

https://www.generalanalysis.com/blog/supabase-mcp-blog

Bài viết này thảo luận về các vấn đề bảo mật có thể phát sinh từ Model Context Protocol (MCP) khi tương tác với các công cụ bên ngoài, đặc biệt là đối với tích hợp MCP của Supabase. Bài viết trình bày một ví dụ về cách kẻ tấn công có thể khai thác tích hợp MCP của Supabase để làm rò rỉ dữ liệu bảng SQL riêng tư của nhà phát triển.

Tổng quan về vấn đề: Các mô hình ngôn ngữ lớn (LLMs) thường xử lý dữ liệu dựa trên các chỉ thị được xác định trước. Các system prompt, chỉ thị của người dùng và ngữ cảnh dữ liệu đều được cung cấp dưới dạng văn bản cho LLM. Vấn đề cốt lõi là LLM không thể phân biệt ranh giới giữa chỉ thị và dữ liệu. Nếu “dữ liệu” do người dùng cung cấp trông giống như chỉ thị, mô hình có thể xử lý nó như một chỉ thị. Thiết lập môi trường: Tác giả bài viết đã tạo một dự án Supabase, mô phỏng một SaaS hỗ trợ khách hàng đa người thuê điển hình. Instance chỉ chứa dữ liệu ảo, bật Row Level Security (RLS) và không giới thiệu thêm các extension hoặc policy. Cuộc tấn công khai thác cấu hình “out-of-the-box”, bao gồm service role tiêu chuẩn, mô hình mặc định, RLS và một trợ lý mô hình ngôn ngữ đại diện cho nhà phát triển để thực hiện các lệnh gọi MCP. Vai trò và ranh giới quyền: - Khách hàng/Kẻ tấn công: Sử dụng biểu mẫu “gửi yêu cầu hỗ trợ” công khai, không có vai trò (RLS giới hạn).

Đại diện hỗ trợ: Sử dụng bảng điều khiển hỗ trợ, vai trò hỗ trợ (RLS giới hạn).
Nhà phát triển: Sử dụng Cursor IDE và Supabase MCP, service role (bỏ qua RLS).
Trợ lý IDE: LLM được Cursor gọi, thực thi SQL với service role. Ứng dụng: Ứng dụng hỗ trợ cho phép nhân viên mở các yêu cầu hỗ trợ và giao tiếp với đại diện. Thông tin được lưu trữ trong cơ sở dữ liệu SQL do Supabase quản lý. Nhà phát triển có thể thỉnh thoảng sử dụng proxy của Cursor để liệt kê các yêu cầu hỗ trợ mới nhất và tin nhắn của chúng. Quy trình làm việc bình thường: Ứng dụng hỗ trợ cho phép người dùng mở yêu cầu hỗ trợ và trao đổi tin nhắn với đại diện hỗ trợ. Tất cả dữ liệu, bao gồm tin nhắn và yêu cầu hỗ trợ, được lưu trữ trong cơ sở dữ liệu SQL do Supabase quản lý. Nhà phát triển thỉnh thoảng sử dụng trợ lý AI trong Cursor để xem các yêu cầu đang mở. Cursor truy vấn cơ sở dữ liệu thông qua Supabase MCP server và tạo ra một bản tóm tắt các hoạt động hỗ trợ gần đây. Quá trình tấn công: Kẻ tấn công bắt đầu cuộc tấn công bằng cách gửi một yêu cầu hỗ trợ mới và gửi một tin nhắn được tạo dựng cẩn thận. Nội dung tin nhắn bao gồm một câu hỏi thân thiện và một khối chỉ thị rất rõ ràng, nhắm trực tiếp vào Cursor proxy. Các chỉ thị yêu cầu proxy đọc bảng integration_tokens và thêm tất cả nội dung làm tin nhắn mới vào yêu cầu hỗ trợ. Khi nhà phát triển sau đó sử dụng Cursor để xem các yêu cầu đang mở, proxy sẽ hoạt động theo các chỉ thị được nhúng, dẫn đến rò rỉ dữ liệu nhạy cảm. Các biện pháp giảm thiểu: Cuộc tấn công này bắt nguồn từ sự kết hợp của hai sai sót thiết kế: truy cập cơ sở dữ liệu với quyền hạn quá mức (service role) và tin tưởng mù quáng vào nội dung do người dùng gửi. Mặc dù MCP mở ra khả năng tự động hóa mạnh mẽ, nhưng cần thận trọng để tránh suy giảm bảo mật. Bài viết đề xuất hai bước ngay lập tức mà các nhóm có thể thực hiện để giảm thiểu rủi ro: sử dụng service role ở chế độ chỉ đọc và xác thực và làm sạch nội dung do người dùng gửi.

HN | Độ nóng: 811 điểm | 442 bình luận | Tác giả: rexpository #

https://news.ycombinator.com/item?id=44502318

Các kỹ sư Supabase đang nỗ lực giảm thiểu rủi ro LLM bị tấn công thông qua cập nhật tài liệu và thử nghiệm
Mặc dù đã thực hiện các biện pháp, tấn công prompt injection vẫn là một vấn đề chưa được giải quyết, bất kỳ cơ sở dữ liệu hoặc nguồn thông tin nào chứa dữ liệu riêng tư đều có nguy cơ
Quyền kiểm soát chi tiết hơn và nhiều cảnh báo tài liệu hơn đang được phát triển để tăng cường bảo mật
Có người đặt câu hỏi về tính hợp lý của việc sử dụng MCP làm ranh giới bảo mật, cho rằng nên có ngữ cảnh LLM tách biệt để xử lý các tác vụ khác nhau
Có người lo ngại về tính bảo mật của việc “khuyên” máy tính không thực hiện một số thao tác nhất định, cho rằng việc lập trình nên rõ ràng
Có người chỉ ra rằng, không giống như lập trình truyền thống, công nghệ AI hiện tại giới thiệu đầu vào và đầu ra không rõ ràng
Có người bày tỏ lo ngại về đầu vào và đầu ra không rõ ràng, cho rằng điều này trái ngược với những gì họ mong đợi từ máy tính
Có người đề cập rằng, mặc dù con người cũng khó đảm bảo an toàn cho chương trình mà không có sự mơ hồ, nhưng tình hình hiện tại còn phức tạp hơn
Có người chỉ trích các biện pháp bảo mật hiện tại, cho rằng MCP bỏ qua các rào cản bảo mật hiện có, làm tăng rủi ro
Có người bi quan về tình hình an ninh mạng hiện tại, cho rằng các doanh nghiệp quan tâm đến việc cạnh tranh nhanh hơn là bảo mật
Có người đề cập đến tần suất các dịch vụ đám mây của Microsoft bị tấn công và đặt câu hỏi về tính bảo mật của chúng
Có người chỉ ra rằng, do thiệt hại lớn do các cuộc tấn công mạng gây ra, các tổ chức không coi trọng bảo mật có thể không tồn tại được

Tòa án Hoa Kỳ vô hiệu hóa yêu cầu “nhấp để hủy” của FTC #

US Court nullifies FTC requirement for click-to-cancel

https://arstechnica.com/tech-policy/2025/07/us-court-cancels-ftc-rule-that-would-have-made-canceling-subscriptions-easier/

Tòa án phúc thẩm liên bang Hoa Kỳ gần đây đã bác bỏ một quy định “nhấp để hủy”, quy định này yêu cầu các công ty cung cấp các phương thức hủy dịch vụ dễ dàng như đăng ký dịch vụ. Quy định của Ủy ban Thương mại Liên bang (FTC), dự kiến có hiệu lực vào ngày 14 tháng 7, đã bị Tòa án phúc thẩm vòng 8 Hoa Kỳ tuyên bố vô hiệu.

Một hội đồng gồm ba thẩm phán đã nhất trí phán quyết rằng FTC thời chính quyền Biden, khi đó do Chủ tịch Lina Khan lãnh đạo, đã không tuân thủ quy trình xây dựng quy tắc đầy đủ theo yêu cầu của luật pháp Hoa Kỳ. Phán quyết chỉ ra: “Mặc dù chúng tôi chắc chắn không ủng hộ việc sử dụng các hành vi không công bằng và lừa đảo trong tiếp thị lựa chọn phủ định, nhưng những thiếu sót về thủ tục trong quá trình xây dựng quy tắc của ủy ban ở đây là chí tử.”

Các thẩm phán cho biết họ đồng cảm với động cơ của FTC, nhiều người Mỹ “thấy mình vô tình đăng ký vào các chương trình đăng ký định kỳ, tiếp tục trả tiền cho các sản phẩm hoặc dịch vụ không mong muốn vì họ bỏ qua việc hủy đăng ký.” Năm ngoái, FTC đã cập nhật quy tắc lựa chọn phủ định năm 1973, bổ sung các điều khoản “cấm người bán xuyên tạc các sự kiện quan trọng và yêu cầu tiết lộ các điều khoản quan trọng, sự đồng ý rõ ràng của người tiêu dùng và cơ chế hủy đơn giản.”

FTC được yêu cầu thực hiện phân tích quy định sơ bộ khi ước tính tác động kinh tế hàng năm của một quy tắc vượt quá 100 triệu đô la. FTC ước tính trong Thông báo về Quy tắc Đề xuất (NPRM) rằng quy tắc này sẽ không có tác động 100 triệu đô la. Nhưng sau đó, một thẩm phán hành chính đã phát hiện ra rằng tác động của quy tắc này vượt quá ngưỡng này, chỉ ra rằng chi phí tuân thủ sẽ vượt quá 100 triệu đô la, “trừ khi mỗi doanh nghiệp sử dụng ít hơn 23 giờ dịch vụ chuyên nghiệp và được tính theo mức phí giờ tối thiểu ước tính”, phán quyết của Tòa án vòng 8 cho biết. Mặc dù thẩm phán hành chính đã phát hiện ra điều này, FTC đã không thực hiện phân tích quy định sơ bộ mà “chỉ công bố phân tích quy định cuối cùng và quy tắc cuối cùng.”

Các thẩm phán đã bác bỏ lập luận của FTC, FTC lập luận rằng luật pháp Hoa Kỳ “không yêu cầu ủy ban thực hiện phân tích quy định sơ bộ ở giai đoạn sau của quá trình xây dựng quy tắc” và “bất kỳ sai sót nào bị cáo buộc đều vô hại vì NPRM đã thảo luận về các lựa chọn thay thế cho các sửa đổi được đề xuất đối với quy tắc [lựa chọn phủ định] năm 1973 và phân tích chi phí lưu giữ hồ sơ và tuân thủ.” Các thẩm phán không đồng ý với quan điểm của FTC, viết rằng “ngôn ngữ pháp định ‘phải công bố’ yêu cầu trong mọi trường hợp, miễn là ủy ban đã công bố thông báo về quy tắc được đề xuất và ngưỡng 100 triệu đô la đã bị vượt quá, thì phải thực hiện một phân tích sơ bộ riêng biệt để công chúng xem xét và bình luận.”

Nhiều nhóm ngành và doanh nghiệp, bao gồm cả các công ty truyền hình cáp, đã kiện FTC tại bốn tòa án phúc thẩm liên bang. Các vụ việc này đã được hợp nhất vào Tòa án vòng 8, do các thẩm phán vòng quanh James Loken, Ralph Erickson và Jonathan Kobes quyết định. Loken được George H.W. Bush bổ nhiệm, trong khi Erickson và Kobes là những người được Trump bổ nhiệm. Các thẩm phán cho biết, do thiếu phân tích sơ bộ, các nhóm ngành và doanh nghiệp không có đủ thời gian để chất vấn những phát hiện của FTC.

HN | Độ nóng: 529 điểm | 485 bình luận | Tác giả: gausswho #

https://news.ycombinator.com/item?id=44504699

Thẩm phán đưa ra phán quyết dựa trên luật thực tế chứ không phải những gì nghe có vẻ hợp lý, FTC có những thiếu sót về thủ tục trong việc xây dựng quy tắc
Tòa án quan tâm đến quy định thực tế của luật, nhưng trong lịch sử cũng có những trường hợp áp dụng luật một cách chọn lọc, chẳng hạn như vụ Wickard v Filburn
Thẩm phán có thể đưa ra phán quyết dựa trên thông tin được trợ lý sàng lọc, có khả năng phóng đại ước tính chi phí
Tòa án đôi khi tuân theo luật, đôi khi áp dụng luật một cách chọn lọc cho một mục đích cụ thể
Tòa án tuân theo phán quyết của luật là đúng, không nên chỉ trích
Việc tòa án áp dụng luật một cách chọn lọc có thể phục vụ cho một chương trình nghị sự bất hợp pháp
Phán quyết của tòa án đôi khi có lợi cho doanh nghiệp, đôi khi bất lợi cho người tiêu dùng, sự chọn lọc này là nguy hiểm
FTC và các cơ quan chính phủ nếu luôn đánh giá thấp tác động kinh tế của các quy tắc sẽ làm suy yếu khả năng quản lý
Phán quyết của tòa án giúp duy trì sự kiểm soát và cân bằng đối với các cơ quan quản lý
Phán quyết của tòa án có thể quá nhấn mạnh vào thủ tục, bỏ qua số tiền khổng lồ mà người tiêu dùng mất do không hủy đăng ký
Các phán quyết của thẩm phán đôi khi dường như tuân theo luật, nhưng đôi khi lại đi ngược lại luật
Ngưỡng ảnh hưởng quy tắc 1 triệu đô la có vẻ quá thấp trong môi trường kinh tế hiện tại, tác động chi phí đối với nhiều doanh nghiệp nhỏ có thể vượt quá con số này

Tree Borrows #

Tree Borrows

https://plf.inf.ethz.ch/research/pldi25-tree-borrows.html

Trang web này giới thiệu về nghiên cứu “Tree Borrows”, một trong những dự án nghiên cứu của Phòng thí nghiệm Nền tảng Ngôn ngữ Lập trình (Programming Language Foundations Lab) thuộc D-INFK (Khoa Khoa học Máy tính) của ETH Zurich (Viện Công nghệ Liên bang Zurich).

Ngôn ngữ lập trình Rust nổi tiếng với hệ thống kiểu dựa trên quyền sở hữu, cung cấp các đảm bảo mạnh mẽ như an toàn bộ nhớ và tự do khỏi tình trạng tranh chấp dữ liệu. Tuy nhiên, Rust cũng cung cấp các lối thoát không an toàn, những lối thoát này không tự động đảm bảo an toàn và phải được lập trình viên bảo trì thủ công. Điều này tạo ra một sự căng thẳng: một mặt, trình biên dịch muốn tận dụng các đảm bảo mạnh mẽ của hệ thống kiểu, đặc biệt là về bí danh con trỏ, để mở khóa các tối ưu hóa nội quy trình mạnh mẽ. Mặt khác, những tối ưu hóa này có thể dễ dàng bị phá hỏng bởi mã không an toàn “hoạt động kém”. Để đảm bảo tính đúng đắn của những tối ưu hóa này, cần phải xác định rõ ràng mã không an toàn “hoạt động kém” là gì.

Để giải quyết những vấn đề này, các nhà nghiên cứu đã đề xuất Tree Borrows. Như tên gọi của nó, Tree Borrows định nghĩa bằng cách thay thế ngăn xếp cốt lõi của Stacked Borrows bằng một cây. Phương pháp này khắc phục những hạn chế trên: trong quá trình đánh giá trên 30.000 Rust crates được sử dụng rộng rãi nhất, Tree Borrows từ chối ít trường hợp thử nghiệm hơn Stacked Borrows (54%). Ngoài ra, các nhà nghiên cứu cũng đã chứng minh trong Rocq rằng Tree Borrows giữ lại phần lớn các tối ưu hóa của Stacked Borrows và cũng có thể thực hiện các tối ưu hóa mới quan trọng, đặc biệt là sắp xếp lại đọc-đọc.

Bài báo nghiên cứu (định dạng PDF), công cụ và mã nguồn có thể được truy cập thông qua các liên kết bên ngoài được cung cấp. Nghiên cứu về Tree Borrows đã nhận được giải thưởng bài báo xuất sắc tại PLDI'25.

HN | Độ nóng: 379 điểm | 59 bình luận | Tác giả: zdw #

https://news.ycombinator.com/item?id=44510600

Quy tắc bí danh nghiêm ngặt của ngôn ngữ C được coi là tồi tệ, trong khi quy tắc bí danh do Rust đề xuất hữu ích hơn cho trình biên dịch và ít nặng nề hơn cho các lập trình viên.
Rust cung cấp cơ chế chọn không tham gia trong ngôn ngữ thực tế: sử dụng con trỏ thô và có các công cụ để kiểm tra mã.
Quy tắc bí danh của Rust có thể cung cấp một điểm cân bằng mới cho tối ưu hóa trình biên dịch, nhưng liệu nó có đúng hay không vẫn cần thời gian để xác minh.
Trong phát triển nhúng, ngữ nghĩa của Rust rõ ràng hơn C, không có các quy tắc phức tạp và không rõ ràng về UB trong C.
Quy tắc Tree Borrows của Rust đơn giản hóa việc hiểu các tham chiếu, ngữ nghĩa thao tác con trỏ rõ ràng, không có sự phức tạp của máy trừu tượng trong C.
Mong đợi mô hình bí danh của Rust có thể được đưa vào tài liệu chính thức, giúp cho unsafe Rust dễ dàng viết một cách tự tin và chính xác hơn so với C.
Quy tắc bí danh của Rust khác với C, quy tắc bí danh của Rust tinh tế hơn, không quan tâm đến kiểu “vật lý”, cho phép diễn giải các kiểu khác nhau trên cùng một bộ nhớ.
Bằng cách loại bỏ phần truyền thông tin bí danh đến LLVM trong trình biên dịch, có thể đánh giá tác động của thông tin bí danh đến hiệu suất.
Có người cho rằng nên hoài nghi về quan điểm của Linus về trình biên dịch, vì lĩnh vực chuyên môn của ông khác với trình biên dịch.
Phân tích bí danh cơ bản rất quan trọng để cải thiện hiệu suất, nhưng phân tích bí danh phức tạp hơn mang lại hiệu suất cải thiện hạn chế.
Có người suy đoán rằng, về mặt lý thuyết, phân tích bí danh hoàn hảo có thể mang lại mức tăng tốc khoảng 20% trên mã không phải HPC.
Có người đề cập rằng, sau khi nhóm trình biên dịch của Apple thay đổi cài đặt mặc định thành bí danh nghiêm ngặt, tốc độ của khối lượng công việc quan trọng đã tăng 5-10% và việc khắc phục sự cố dễ dàng hơn dự kiến.

Phá vỡ Git bằng ký tự xuống dòng và nhân bản RCE #

Breaking Git with a carriage return and cloning RCE

https://dgl.cx/2025/07/git-clone-submodule-cve-2025-48384

Bài viết này thảo luận về một lỗ hổng bảo mật nghiêm trọng của Git là CVE-2025-48384, cho phép kẻ tấn công thực thi mã từ xa (RCE) trên các nền tảng Unix-like bằng cách sử dụng lệnh git clone --recursive để sao chép các kho lưu trữ không đáng tin cậy. Bài viết khuyến nghị người dùng cập nhật lên phiên bản Git đã vá lỗ hổng này, cũng như các phần mềm nhúng Git khác (bao gồm GitHub Desktop).

Bài viết bắt đầu bằng việc giới thiệu vấn đề còn sót lại từ thời máy đánh chữ cơ học - ký tự trả về đầu dòng (Carriage Return, CR) và ký tự xuống dòng (Line Feed, LF). Hệ thống Unix đơn giản hóa vấn đề này bằng cách chỉ sử dụng LF để phân tách các dòng, trong khi Windows và một số giao thức Internet sử dụng CR+LF. Git sử dụng định dạng cấu hình kiểu .ini đơn giản, định dạng này không chỉ được sử dụng cho các tệp cấu hình của người dùng mà còn cho tệp .gitmodules, tệp này theo dõi các submodule.

Bài viết giải thích cách Git xử lý dấu xuống dòng DOS trong các tệp cấu hình, cũng như cách đọc và ghi các tệp cấu hình. Vấn đề quan trọng là, khi các giá trị trong tệp cấu hình được ghi lại, Git sẽ đặt chúng trong dấu ngoặc kép nếu giá trị đó chứa các ký tự cụ thể (chẳng hạn như khoảng trắng, dấu chấm phẩy hoặc dấu thăng). Tuy nhiên, nếu giá trị kết thúc bằng CR, Git sẽ loại bỏ nó khi đọc, điều này có thể dẫn đến các vấn đề bảo mật.

Bài viết giải thích thêm về cách lỗ hổng này ảnh hưởng đến việc xử lý submodule trên hệ thống Unix. Nếu đường dẫn trong tệp .gitmodules kết thúc bằng CR, Git sẽ loại bỏ CR khi ghi vào tệp cấu hình, dẫn đến đường dẫn thay đổi sau khi xác thực. Điều này có thể dẫn đến việc submodule được sao chép vào một đường dẫn sai, tương tự như lỗ hổng CVE-2024-32002.

Bài viết cung cấp một biện pháp giảm thiểu thủ công, đó là không sử dụng tùy chọn --recursive khi sao chép, trước tiên hãy kiểm tra xem tệp .gitmodules có an toàn hay không, sau đó mới khởi tạo submodule. Tuy nhiên, GitHub Desktop mặc định sử dụng tùy chọn --recursive, do đó việc sao chép bằng GitHub Desktop có thể kích hoạt lỗ hổng này.

Bài viết cuối cùng đề cập rằng bản vá cho lỗ hổng này tương đối đơn giản, đảm bảo rằng khi ghi các chuỗi chứa CR, chúng sẽ được đặt trong dấu ngoặc kép. Lỗ hổng này có thể được sử dụng để đặt các tệp độc hại ở hầu hết mọi vị trí trên hệ thống tệp, thực hiện ghi tệp tùy ý. Cách khai thác trực tiếp nhất là ghi vào thư mục .git và tạo các tập lệnh hook, từ đó thực thi mã do kẻ tấn công kiểm soát khi Git chạy hook. Bài viết không cung cấp bằng chứng khái niệm (PoC), nhưng đề cập rằng đây là một sửa đổi đơn giản đối với việc khai thác lỗ hổng CVE-2024-32002. Bài viết cũng đề cập rằng đây không phải là lần đầu tiên CR gây ra sự cố cho Git, và cũng không phải là lần đầu tiên phát hiện ra các vấn đề trong phân tích cú pháp cấu hình.

HN | Độ nóng: 359 điểm | 151 bình luận | Tác giả: dgl #

https://news.ycombinator.com/item?id=44502330

Bằng cách sửa đổi ký tự xuống dòng (CR) trong giá trị cấu hình Git, có thể khiến Git ghi tệp sai vào thư mục .git thay vì thư mục làm việc của submodule, do đó cho phép kẻ tấn công thực thi mã tùy ý thông qua hook post-checkout của submodule.
Kẻ tấn công cần ghi script shell vào thư mục .git/hooks của hệ thống mục tiêu để thực thi mã từ xa.
Vấn đề này rất dễ ngăn chặn đối với GitHub, nhưng nhiều kho Git không liên quan đến GitHub.
Submodule có thể là bất kỳ URL nào, việc GitHub ngăn chặn hoàn toàn vấn đề này đòi hỏi phải thu thập thông tin từ các dịch vụ lưu trữ mã khác, điều này có thể dẫn đến ảo tưởng về an ninh.
Ngay cả khi có thể ghi vào .git/hooks, kẻ tấn công đã có thể thực thi mã tùy ý.
Bất cứ khi nào có thể ghi tệp tùy ý, điều đó thường có nghĩa là có thể thực thi mã từ xa.
Việc di chuyển thư mục .git ra khỏi thư mục cây làm việc và sử dụng quy trình không có quyền chỉ truy cập vào thư mục cây làm việc để xử lý tất cả các thao tác tệp có thể giảm thiểu vấn đề này.
Ngay cả khi không sử dụng GitHub, số lượng người sử dụng Git cũng không hề nhỏ, không thể coi là trường hợp cá biệt.
Kẻ tấn công có thể lợi dụng đường dẫn đặc biệt của thư mục .git để thực thi hook, ngay cả khi Git không nên chấp nhận bất kỳ hook nào trong quá trình clone.
Bản PoC (Proof of Concept, chứng minh khái niệm) đầy đủ cho thấy không có tác động bảo mật, vì hầu hết mọi người thường chạy lệnh build sau khi git clone, điều này cũng sẽ thực thi mã tùy ý từ kho lưu trữ.
Khi sử dụng DSL (Domain-Specific Language, ngôn ngữ đặc tả miền) tùy chỉnh để cấu hình, nếu không có đặc tả cú pháp chính thức, có thể dẫn đến sự không đồng bộ giữa trình phân tích cú pháp và trình tuần tự hóa, từ đó gây ra các vấn đề bảo mật.

IKEA từ bỏ Zigbee để chuyển sang Thread, tập trung toàn lực vào nhà thông minh Matter #

IKEA ditches Zigbee for Thread going all in on Matter smart homes

https://www.theverge.com/smart-home/701697/ikea-matter-thread-new-products-new-smart-home-strategy

Ikea đang xây dựng một môi trường nhà thông minh hơn

Gã khổng lồ nội thất Thụy Điển Ikea có kế hoạch ra mắt hơn 20 thiết bị nhà thông minh dựa trên giao thức Matter-over-Thread để đơn giản hóa hệ thống nhà thông minh của mình và giảm chi phí. Ikea đang khởi động lại dòng sản phẩm nhà thông minh của mình để các sản phẩm giá rẻ của hãng có thể hoạt động với các sản phẩm của các thương hiệu khác, cho dù có sử dụng trung tâm thông minh của riêng Ikea hay không. Từ tháng 1 năm 2025, Ikea sẽ phát hành một loạt đèn, cảm biến và điều khiển từ xa thông minh Matter-over-Thread mới, đồng thời sẽ “giới thiệu nhiều loại sản phẩm và hình thức mới hơn”, David Granath của Ikea Thụy Điển cho biết trong một cuộc phỏng vấn độc quyền với The Verge. Ikea cũng đang khởi động lại dòng sản phẩm âm thanh của mình để lấp đầy khoảng trống mà Sonos Symfonisk để lại trên kệ của hãng. Hai mẫu đầu tiên trong một loạt loa Bluetooth gia đình giá rẻ, dễ sử dụng là Nattbad phong cách cổ điển với giá 50 đô la và loa/đèn bàn Blomprakt sẽ ra mắt vào tháng 10, và sẽ có nhiều mẫu hơn trong tương lai.

Những sản phẩm mới này là một phần trong nỗ lực liên tục của Ikea để làm cho hệ thống nhà thông minh của mình trở nên đơn giản và thiết thực nhất có thể. “Vài năm trước, chúng tôi đã đưa ra một số quyết định chiến lược về sự phát triển của dòng sản phẩm nhà thông minh và loa để tạo ra tác động đến nhiều người hơn theo cách của Ikea”, Granath nói. Ông đề cập đến kinh nghiệm hợp tác với Zigbee và Sonos trong vài năm qua của công ty, cũng như tham gia thành lập và phát triển tiêu chuẩn nhà thông minh mới Matter. “Chúng tôi cảm thấy mình đã đến được thời điểm đó. Có rất nhiều điều sắp tới, nhưng đây đều là những bước đầu tiên để sắp xếp mọi thứ ổn thỏa.”

Tuần trước, Ikea đã phát hành bản cập nhật cho trung tâm nhà thông minh Dirigera của mình, hiện đang trong giai đoạn thử nghiệm, biến trung tâm này thành bộ điều khiển Matter và kích hoạt radio Thread không hoạt động trong thời gian dài, biến nó thành bộ định tuyến biên Thread. Điều này có nghĩa là nó hiện có thể kết nối và điều khiển bất kỳ thiết bị Matter tương thích nào, bao gồm cả các thiết bị của các thương hiệu khác và điều khiển chúng trong ứng dụng Home Smart của mình. Nó cũng sẽ hoạt động với các thiết bị Matter mới của Ikea, những thiết bị này cuối cùng sẽ thay thế các thiết bị Zigbee hiện có, Granath nói. Đây là một bước quan trọng hướng tới một ngôi nhà thông minh mở hơn, cắm và chạy.

Blomprakt là một đèn bàn LED tích hợp loa Bluetooth ở trên cùng. Đây là một phần trong sự tập trung mới của Ikea vào nhà thông minh và âm thanh sau quá trình chuyển đổi từ Zigbee và Sonos. Ảnh: Ikea

Ban đầu, Dirigera sẽ chỉ hỗ trợ các loại thiết bị Matter mà Ikea hiện đang cung cấp, vì vậy sẽ không có robot hút bụi, khóa cửa hoặc tủ lạnh. Tuy nhiên, Granath cho biết, khi họ tung ra nhiều sản phẩm nhà thông minh hơn, trung tâm sẽ được cập nhật để hỗ trợ nhiều loại thiết bị hơn. Trung tâm Dirigera đã hoạt động như một cầu nối Matter, cho phép các thiết bị Ikea dựa trên Zigbee kết nối với hệ sinh thái Matter lớn hơn, chẳng hạn như Apple Home và Amazon Alexa. Với bản cập nhật, nó hiện hỗ trợ Matter 1.4 và Thread 1.4, cho phép giám sát năng lượng và tham gia các mạng Thread hiện có, v.v. Mặc dù việc triển khai đầy đủ dự kiến sẽ diễn ra vào cuối năm nay, nhưng phiên bản beta hiện có thể được truy cập thông qua ứng dụng Home Smart của Ikea, nhưng Granath cho biết một số chức năng sẽ bị hạn chế.

Matter mở ra khả năng tương tác, dễ sử dụng và khả năng chi trả cho chúng ta

Chúng tôi không có thông tin chi tiết về hơn 20 thiết bị mới sắp ra mắt vào năm tới, nhưng Granath xác nhận rằng chúng sẽ thay thế các chức năng hiện có. Do đó, đèn thông minh, phích cắm, cảm biến, điều khiển từ xa, nút và thiết bị chất lượng không khí mới, bao gồm cả màn hình theo dõi nhiệt độ và độ ẩm. Chúng cũng sẽ có thiết kế mới. Mặc dù “không nhất thiết phải bị rò rỉ”, Granath nói, đề cập đến hình ảnh về nút bấm đôi Bilresa xuất hiện vào đầu năm nay. Ông đã xác nhận một số danh mục sản phẩm mới sẽ đến vào tháng 1, và nhiều sản phẩm hơn sẽ có vào tháng 4 trở đi, bao gồm cả các sản phẩm Matter-over-Wi-Fi có thể. Giá cả sẽ tương đương hoặc thấp hơn so với các sản phẩm trước đây, có giá khởi điểm dưới 10 đô la. “Khả năng chi trả vẫn là một ưu tiên hàng đầu đối với chúng tôi.”

“Phần bù để làm cho sản phẩm trở nên thông minh không còn cao nữa, vì vậy bạn có thể mong đợi các loại và hình thức sản phẩm mới sẽ đến”, ông nói. “Matter mở ra khả năng tương tác, dễ sử dụng và khả năng chi trả cho chúng ta. Quá trình tiêu chuẩn hóa có nghĩa là nhiều công ty đang chia sẻ công việc phát triển.”

Mặc dù chuyển đổi từ Zigbee, Ikea vẫn giữ lại chức năng Touchlink của Zigbee. Giao thức ngang hàng này cho phép các thiết bị ghép nối trực tiếp và hoạt động cùng nhau mà không cần ứng dụng hoặc trung tâm, chẳng hạn như các gói bóng đèn và điều khiển từ xa mà Ikea bán. Điều này có nghĩa là điều khiển từ xa Zigbee cũ có thể điều khiển bóng đèn Thread mới và ngược lại, giữ lại khả năng tương thích ngược với dòng Tradfri của hãng. “Touchlink và Matter sẽ cùng tồn tại trong các sản phẩm mới”, Granath nói. “Điều này vẫn rất quan trọng đối với Ikea - không phải ai cũng muốn ứng dụng hoặc trung tâm.” Điều thú vị là các sản phẩm Matter-over-Thread mới của Ikea cũng có thể hoạt động mà không cần trung tâm hoặc ứng dụng của Ikea, vì chúng có thể được thiết lập trực tiếp trong bất kỳ hệ sinh thái nhà thông minh Matter tương thích nào, chẳng hạn như Apple Home, Amazon Alexa, Google Home, Samsung SmartThings, Home Assistant, v.v.

Khả năng tương thích gốc của Matter có nghĩa là bạn không phải sử dụng ứng dụng Home Smart và trung tâm của Ikea. Ảnh của Thomas Ricker/The Verge

Việc Ikea chuyển đổi hoàn toàn sang Matter, biến nó thành một nền tảng mở hơn, sẽ giúp ích cho những nỗ lực của hãng trong việc làm cho ngôi nhà thông minh trở nên đơn giản và giá cả phải chăng hơn. Đây cũng là một sự thay đổi lớn trong ngành. Granath cho biết, mục tiêu của Ikea là giúp khách hàng nhận được giá trị tối đa từ sản phẩm của họ - cho dù sử dụng với Apple Home, sử dụng trung tâm của họ hay không sử dụng bất kỳ trung tâm nào. Đó là lý do tại sao công ty chấp nhận phương pháp tiếp cận mở của Matter. “Chúng tôi muốn loại bỏ các rào cản phức tạp, chúng tôi muốn nó đơn giản và dễ sử dụng, chúng tôi chỉ muốn nó hoạt động”, ông nói. “Nếu bạn muốn hệ thống thân thiện với người dùng nhất, hãy chọn chúng tôi. Nhưng nếu bạn là người dùng Apple, hãy mang bóng đèn của chúng tôi và tích hợp nó vào Apple Home của bạn.”

Việc khởi động lại này giúp Ikea trở thành một trong những nhà bán lẻ lớn đầu tiên đưa Matter vào thị trường đại chúng.

HN | Độ nóng: 356 điểm | 220 bình luận | Tác giả: thunderbong #

https://news.ycombinator.com/item?id=44507971

IKEA từ bỏ Zigbee chuyển sang tiêu chuẩn Thread và Matter, bị cho là bất lợi cho hệ sinh thái mở và cần phải trả phí bằng sáng chế
Chuyển sang Thread sẽ phá vỡ khả năng tương thích với các thiết bị Zigbee hiện có, người dùng có thể cần phải thay thế thiết bị hoặc đối mặt với sự phân mảnh mạng
Trên nền tảng Home Assistant, việc chạy nhiều loại thiết bị thông minh không phải là vấn đề, chỉ cần cấu hình các radio khác nhau
Có người dùng cho biết, chỉ sử dụng các sản phẩm nhà thông minh IKEA, tránh sử dụng Home Assistant, vì không muốn xử lý các cấu hình phức tạp và khắc phục sự cố
Có người dùng cho rằng nền tảng Home Assistant bản thân nó rất ổn định, không cần cập nhật cấu hình thường xuyên, nhưng thiết bị của một số nhà sản xuất có thể không ổn định
Có người dùng đề cập rằng, việc cập nhật Home Assistant đôi khi gây ra vấn đề, cần phải gỡ lỗi để giải quyết
Có người dùng cho biết, việc sử dụng hệ thống đèn tự động chất lượng cao có thể giảm các vấn đề không ổn định, và sử dụng các giải pháp rẻ hơn cho các thiết bị ít quan trọng hơn
Có người dùng khuyên rằng, đối với các cảm biến chỉ cần đọc, tốt nhất nên tránh sử dụng Bluetooth/Wi-Fi/Zigbee/Zwave, mà nên sử dụng các cảm biến cơ bản, không cần cập nhật
Có người dùng cho rằng, sự không ổn định của một số thiết bị là do cách chúng phát API, chứ không phải do vấn đề kết nối do cập nhật Home Assistant

Linda Yaccarino rời khỏi X #

Linda Yaccarino is leaving X

https://www.nytimes.com/2025/07/09/technology/linda-yaccarino-x-steps-down.html

Linda Yaccarino, Giám đốc điều hành của công ty X do Elon Musk thuê vào năm 2023, đã thông báo vào ngày 9 tháng 7 năm 2025 rằng bà sẽ rời công ty sau hai năm tại vị. Yaccarino đã đăng một thông điệp trên nền tảng truyền thông xã hội X, bày tỏ lòng biết ơn đối với Musk, nói rằng khi thảo luận về tầm nhìn của X với ông, bà nhận ra đây là một cơ hội tuyệt vời để thực hiện sứ mệnh phi thường của công ty. Mặc dù bà không nêu rõ lý do từ chức, nhưng quyết định này đánh dấu sự kết thúc một giai đoạn đầy biến động của công ty X sau khi Musk tiếp quản.

Kể từ khi Musk mua lại Twitter (nay là X) với giá 44 tỷ đô la vào năm 2022, công ty đã trải qua những thay đổi lớn. Musk đã cắt giảm 3/4 nhân viên của công ty, nới lỏng các hạn chế về ngôn luận trên nền tảng và sử dụng X như một công cụ để bày tỏ quan điểm chính trị, những thay đổi này đã khiến các nhà quảng cáo lo lắng, dẫn đến sự sụt giảm trong hoạt động kinh doanh quảng cáo của công ty. Ngoài ra, Musk đã tuyên bố vào năm 2023 rằng ông sẽ bán X cho công ty khởi nghiệp về trí tuệ nhân tạo xAI của mình, một giao dịch bất thường được thực hiện dưới hình thức toàn bộ cổ phiếu, định giá X ở mức 33 tỷ đô la và xAI ở mức 80 tỷ đô la.

Trong thời gian này, các doanh nghiệp khác của Musk, như Tesla và SpaceX, vẫn đang hoạt động. Ông từng là cố vấn cho Tổng thống Trump ở Washington và công khai bày tỏ sự quan tâm đến việc thành lập một đảng phái thứ ba. Điều đáng chú ý là, sự thay đổi quản lý diễn ra thường xuyên trong các công ty khác nhau của Musk, nhưng Chủ tịch của SpaceX, Gwynne Shotwell, đã giữ chức vụ này kể từ khi công ty được thành lập vào năm 2002.

Bài viết được viết bởi các phóng viên công nghệ của tờ New York Times, Mike Isaac và Kate Conger.

HN | Độ nóng: 338 điểm | 501 bình luận | Tác giả: donohoe #

https://news.ycombinator.com/item?id=44510731

Linda Yaccarino đã từ CEO của X Corp trở thành cựu CEO.
Bà ấy thể hiện không tốt trong các bài phát biểu công khai, không có quyền lực thực sự và rõ ràng là có người khác thao túng sau hậu trường.
Mặc dù định giá công ty đã giảm 80% trong thời gian bà ấy nắm quyền, nhưng bà ấy không nên chịu trách nhiệm về điều này.
Việc bà ấy không có quyền lực với tư cách là CEO có thể là một trong những lý do khiến công ty hoạt động kém hiệu quả.
Việc bà ấy vừa báo cáo với Musk vừa “quản lý” ông ấy là một sự sắp xếp vị trí mâu thuẫn đáng ngạc nhiên.
Một số người cho rằng bà ấy với tư cách là CEO nên có khả năng tự bảo vệ mình, thay vì hoàn toàn phục tùng Musk.
Nếu bà ấy chấp nhận một công việc CEO hoàn toàn là để tẩy trắng danh tiếng cho Musk, thì bà ấy có trách nhiệm xã hội là không nên chấp nhận.
Với tư cách là CEO, bà ấy nên có khả năng đứng lên chống lại Musk và lãnh đạo tốt hơn.
Một số người cho rằng việc bà ấy không có quyền lực để chống lại Musk không phải là một lời biện minh hiệu quả.
Một số người cho rằng “chỉ làm theo lệnh” không phải là một lời biện minh hiệu quả.
Một số người cho rằng bà ấy đã không gây rắc rối và giữ im lặng.
Một số người cho rằng bà ấy cũng phải chịu một phần trách nhiệm với tư cách là vật tế thần.
Một số người cho rằng Musk thực sự tin vào mô hình đăng ký và nghiện Twitter, là một con bạc bốc đồng.
Một số người cho rằng Twitter có thể có giá trị hơn như một nguồn đào tạo AI hơn là một mạng xã hội đầy giận dữ.

Hầu hết các API RESTful không thực sự là RESTful #

Most RESTful APIs aren’t really RESTful

https://florian-kraemer.net//software-architecture/2025/07/07/Most-RESTful-APIs-are-not-really-RESTful.html

Bài viết này thảo luận về kiến trúc REST (Representational State Transfer) trong thiết kế dịch vụ web hiện đại, và vấn đề nhiều API được gọi là “RESTful” thực tế không tuân theo các nguyên tắc REST.

Bài viết bắt đầu bằng việc đề cập rằng, để hiểu về REST, nên đọc luận án tiến sĩ của Roy Thomas Fielding, “Architectural Styles and the Design of Network-based Software Architectures”. Luận án này lần đầu tiên đề xuất kiến trúc REST và xem nó như một khuôn khổ để thiết kế các hệ thống mạng có khả năng mở rộng, hiệu suất cao và dễ bảo trì (đặc biệt là các dịch vụ Web). Luận án của Fielding phân tích những ưu điểm và nhược điểm của các kiểu kiến trúc hệ thống mạng, đồng thời định nghĩa REST như một kiểu kiến trúc cụ thể được tối ưu hóa cho mạng hiện đại, nhấn mạnh khả năng mở rộng, tính đơn giản và khả năng thích ứng.

Fielding trong luận án của mình không quy định phải sử dụng các động từ HTTP (như GET, POST, PUT, DELETE) hoặc tập trung vào API theo kiểu CRUD, đây là nơi REST thường bị hiểu lầm và đơn giản hóa. Ông nhấn mạnh rằng, nhiều API được gọi là “RESTful” không thực hiện các ràng buộc quan trọng của REST, đặc biệt là sử dụng siêu phương tiện để điều khiển chuyển đổi trạng thái ứng dụng. Trong bài đăng trên blog năm 2008 của mình, “REST APIs must be hypertext-driven”, Fielding chỉ rõ rằng, nếu API không được điều khiển bởi siêu văn bản, thì nó không thể được gọi là RESTful.

Bài viết tiếp tục giải thích ý nghĩa của “được điều khiển bởi siêu văn bản”, tức là nhiều API tự xưng là RESTful thiếu siêu phương tiện (Hypermedia as the Engine of Application State, viết tắt là HATEOAS) như một công cụ trạng thái ứng dụng. HATEOAS là một nguyên tắc cơ bản của REST, yêu cầu máy khách tự động khám phá các hành động và tương tác thông qua các liên kết siêu phương tiện được nhúng trong phản hồi của máy chủ, thay vì dựa vào kiến thức bên ngoài (ví dụ: tài liệu API). Bài viết minh họa cách HATEOAS hoạt động thông qua một ví dụ JSON, nhấn mạnh cách nó giải quyết vấn đề ghép nối không gian tên giữa máy khách và máy chủ, đồng thời cải thiện khả năng phát triển của hệ thống.

Bài viết cũng khám phá định nghĩa về “tài nguyên” trong REST, chỉ ra rằng tài nguyên có thể là bất kỳ thông tin nào có thể được đặt tên bằng URI, bao gồm tài liệu, hình ảnh, dịch vụ, tập hợp, v.v. Fielding nhấn mạnh rằng, tài nguyên là một ánh xạ khái niệm của một tập hợp các thực thể, chứ không phải là thực thể tương ứng với ánh xạ tại bất kỳ thời điểm cụ thể nào. Ông cũng đề cập rằng, ngữ nghĩa của tài nguyên là kết quả của việc gán định danh tài nguyên và biểu diễn điền tài nguyên, máy chủ hoặc phần mềm máy khách không cần biết hoặc hiểu ý nghĩa của URI, chúng chỉ là kênh để người tạo tài nguyên (cơ quan đặt tên của con người) liên kết biểu diễn với ngữ nghĩa được xác định bởi URI.

Cuối cùng, bài viết trích dẫn RFC 3986, giải thích thêm rằng tài nguyên có thể là bất kỳ thứ gì có thể được xác định bằng URI, cho dù đó là đối tượng vật lý, khái niệm, tài liệu, dịch vụ, hoặc thậm chí là thứ ảo hoặc trừu tượng, miễn là chúng có thể được xác định và biểu diễn duy nhất.

Bài viết tóm tắt quan điểm của Fielding về RESTful API, ông cảm thấy thất vọng khi nhiều người gọi bất kỳ giao diện dựa trên HTTP nào là REST API, và đưa ra sáu quy tắc, những quy tắc này là tiêu chuẩn để đánh giá xem một API có thể được gọi là RESTful API hay không. Các quy tắc này liên quan đến việc API có phụ thuộc vào một giao thức giao tiếp duy nhất hay không, có chứa các thay đổi đối với giao thức giao tiếp hay không, có chủ yếu xác định các loại phương tiện được sử dụng để biểu diễn tài nguyên và điều khiển trạng thái ứng dụng hay không.

HN | Độ nóng: 272 điểm | 436 bình luận | Tác giả: BerislavLopac #

https://news.ycombinator.com/item?id=44507076

Việc ứng dụng thực tế và định nghĩa lý thuyết của RESTful API có sự khác biệt, nhưng cách sử dụng này đã được chấp nhận rộng rãi.
Mọi người có xu hướng sử dụng các hệ thống đơn giản, dễ kiểm soát, ngay cả khi chúng không phải là tối ưu nhất về mặt lý thuyết.
Công việc lặp đi lặp lại tuy không lý tưởng, nhưng trong một số trường hợp có thể dễ bảo trì hơn các hệ thống phức tạp.
Việc tạo ra nhiều phần từ một nguồn dữ liệu duy nhất có thể dẫn đến hệ thống dễ bị lỗi và khó bảo trì do các nhóm khác nhau và lịch trình khác nhau.
Kiến trúc microservice đôi khi có thể dẫn đến sự không nhất quán về phiên bản và thông số kỹ thuật, tạo ra thêm sự khó khăn và nhầm lẫn.
FastAPI kết hợp việc triển khai API, kiểu dữ liệu và tạo thông số kỹ thuật Swagger, giảm công việc lặp đi lặp lại.
gRPC hoặc ConnectRPC (gRPC dựa trên HTTP) được đánh giá cao vì tính đơn giản và nghiêm ngặt của chúng.
gRPC bị chỉ trích vì sử dụng Protocol Buffers, vì Protocol Buffers không có chức năng yêu cầu trường.
Tính linh hoạt của RESTful API dẫn đến nhiều cách triển khai khác nhau, làm tăng thêm sự phức tạp.

Bulgaria sẽ gia nhập khu vực đồng euro vào ngày 1 tháng 1 năm 2026 #

Bulgaria to join euro area on 1 January 2026

https://www.ecb.europa.eu//press/pr/date/2025/html/ecb.pr250708~b9676a9fa8.en.html

Theo thông báo của Ngân hàng Trung ương Châu Âu (ECB), Bulgaria sẽ chính thức gia nhập khu vực đồng euro vào ngày 1 tháng 1 năm 2026. Nội dung cốt lõi của việc gia nhập này như sau:

Tỷ giá hối đoái cố định: Đồng tiền của Bulgaria - Lev Bulgaria (BGN) sẽ gia nhập khu vực đồng euro với tỷ giá hối đoái cố định là 1,95583 Lev đổi 1 euro. Tỷ giá này là tỷ giá trung tâm hiện tại của Bulgaria trong Cơ chế Tỷ giá hối đoái châu Âu (ERM II), mà Bulgaria đã tham gia vào ngày 10 tháng 7 năm 2020.
Thỏa thuận giám sát: Ngân hàng Trung ương Châu Âu và Ngân hàng Quốc gia Bulgaria (Българска народна банка) đã đạt được thỏa thuận sẽ tiếp tục giám sát hoạt động của Lev Bulgaria so với đồng euro trên thị trường ngoại hối cho đến khi chính thức gia nhập khu vực đồng euro vào ngày 1 tháng 1 năm 2026.
Khung pháp lý: Kể từ ngày 1 tháng 10 năm 2020, ECB đã trực tiếp giám sát bốn tổ chức tài chính quan trọng của Bulgaria và giám sát 13 tổ chức tài chính ít quan trọng hơn theo khuôn khổ hợp tác chặt chẽ với Ngân hàng Quốc gia Bulgaria.
Điều kiện gia nhập: Việc Bulgaria tham gia ERM II và tuân thủ phạm vi biến động bình thường trong ít nhất hai năm là một trong những tiêu chí hội tụ cần thiết để gia nhập khu vực đồng euro.
Sửa đổi pháp luật: Tỷ giá chuyển đổi của Lev được thiết lập thông qua việc sửa đổi Quy định (EC) số 2866/98, có hiệu lực từ ngày 1 tháng 1 năm 2026.

Quyết định này đánh dấu một bước tiến quan trọng của Bulgaria trong quá trình hội nhập kinh tế và dự kiến sẽ có tác động tích cực đến sự ổn định kinh tế và tài chính của đất nước.

HN | Độ nóng: 267 điểm | 315 bình luận | Tác giả: toomuchtodo #

https://news.ycombinator.com/item?id=44505308

Đồng tiền chung châu Âu là một dự án thành công và vẫn đang mở rộng, việc Bulgaria gia nhập cho phép việc đi lại gần như hoàn toàn qua khu vực đồng euro từ Tây Ban Nha đến Hy Lạp.
Ba Lan hiện phản đối việc áp dụng đồng euro, cho rằng việc từ bỏ quyền kiểm soát đối với nền kinh tế cho các tổ chức phi dân chủ siêu quốc gia sẽ mang lại nhiều bất lợi hơn.
Ba Lan cho rằng, cung tiền nên phù hợp với tốc độ tăng trưởng kinh tế, trong khi sự khác biệt giữa các quốc gia khu vực đồng euro dẫn đến giá cả ở các quốc gia EU mới tăng nhanh hơn, nhưng thu nhập lại không tăng.
Ba Lan cho rằng đồng euro có lợi hơn khi là đồng tiền thứ hai chứ không phải đồng tiền duy nhất, vì như vậy có thể sử dụng đồng euro trong khu vực đồng euro mà không bị ảnh hưởng bởi chính sách tiền tệ của Ngân hàng Trung ương Châu Âu.
Sự tăng trưởng kinh tế của Ba Lan một phần nhờ vào trợ cấp của EU, vì vậy quan điểm phản đối việc gia nhập khu vực đồng euro có thể chỉ áp dụng cho thập kỷ tới.
Ba Lan, với tư cách là thành viên EU, có thể tận hưởng những lợi ích của thị trường chung EU mà không cần sử dụng đồng euro, chẳng hạn như các quy tắc thống nhất, dòng vốn, trợ cấp và chính sách công nghiệp.
Việc Ba Lan gia nhập khu vực đồng euro có thể làm suy yếu lợi thế của việc sử dụng đồng euro.
Chiến lược hiện tại của Ba Lan là hiện đại hóa và tăng cường đáng kể sức mạnh quân sự, điều này khiến nước này khó có thể đáp ứng các tiêu chuẩn tài chính để gia nhập khu vực đồng euro trong thời gian ngắn.
Việc Ba Lan không thể xây dựng chính sách tiền tệ là một lý do phản đối mạnh mẽ, có thể tham khảo cuộc khủng hoảng đồng euro ở Hy Lạp và Tây Ban Nha.
Nền kinh tế Ba Lan hoạt động tốt một phần là do các khoản trợ cấp lớn của EU trong nhiều thập kỷ.
Ba Lan có nguồn nhân lực và tiềm năng kinh tế tương đương với các nước Tây Âu, nhưng trong lịch sử bị ảnh hưởng bởi sự chia cắt, Thế chiến II, Liên Xô và thiếu đầu tư theo Kế hoạch Marshall.
EU giúp các nước lạc hậu nâng cao kinh tế là một tình huống đôi bên cùng có lợi, việc Ba Lan từ chối chia sẻ đồng tiền có thể khiến các nước thành viên khác không hài lòng.
Thiệt hại mà Ba Lan phải gánh chịu trong Thế chiến II lớn hơn nhiều so với khoản trợ cấp 28 tỷ euro mà EU cung cấp.
Việc áp dụng đồng euro có thể làm giảm chi phí chuyển đổi tiền tệ, chẳng hạn như giảm lãi suất thế chấp và giảm bớt rắc rối khi chuyển đổi tiền tệ trong du lịch và thương mại.

Astro là sự trở lại với những điều cơ bản của web #

Astro is a return to the fundamentals of the web

https://websmith.studio/blog/astro-is-a-developers-dream/

Astro là khung (framework) mơ ước của nhà phát triển

Sau khi chuyển nhiều dự án từ WordPress sang Astro, tác giả đã trở thành một người hâm mộ trung thành của khung này. Astro là một khung web được ra mắt vào năm 2021, nó rất khác biệt. Hầu hết các khung JavaScript đều bắt đầu bằng việc xây dựng các ứng dụng phức tạp, sau đó cố gắng thích ứng với các trang web đơn giản hơn, trong khi Astro thì ngược lại. Nó được xây dựng ngay từ đầu cho các trang web hướng nội dung. Triết lý của Astro rất đơn giản: hướng nội dung, ưu tiên máy chủ, mặc định không chứa bất kỳ JavaScript nào (thực sự là như vậy), đồng thời dễ sử dụng và có các công cụ tuyệt vời. Nó giống như ai đó đã hỏi: “Nếu chúng ta xây dựng một khung dành riêng cho loại trang web mà hầu hết chúng ta thực sự tạo thì sao?”

Kiến trúc đảo (Island Architecture)

Astro giới thiệu một khái niệm gọi là “kiến trúc đảo”, một khi bạn hiểu nó, bạn sẽ tự hỏi tại sao chúng ta lại làm mọi thứ theo cách khác trước đây. Các khung truyền thống sẽ sử dụng JavaScript để hydrate toàn bộ trang, ngay cả khi bạn có một bài đăng trên blog đơn giản chỉ có một tiện ích tương tác, toàn bộ trang sẽ được xử lý bằng JavaScript. Astro đảo ngược điều này. Trang của bạn mặc định là HTML tĩnh, chỉ những phần cần tương tác mới trở thành “đảo” JavaScript. Hãy tưởng tượng một bài đăng trên blog có hàng nghìn từ, trong Astro, tất cả văn bản đó vẫn là HTML thuần túy. Chỉ khu vực bình luận hoặc trình chiếu ảnh của bạn mới cần tải JavaScript. Mọi thứ khác vẫn cực kỳ nhanh. Đây là một giải pháp đơn giản nhưng khéo léo.

Hiệu suất thực sự, tác động thực sự

Trang web Astro nhanh, chúng ta đang nói về thời gian tải nhanh hơn 40% so với các khung React truyền thống. Nhưng điều quan trọng là, điều này không chỉ để gây ấn tượng với các nhà phát triển khác. Những cải thiện về hiệu suất này chuyển trực tiếp thành thứ hạng tìm kiếm tốt hơn, người dùng hài lòng hơn và nhiều chuyển đổi hơn. Sự khác biệt càng trở nên rõ ràng hơn trên các thiết bị chậm hoặc kết nối di động không ổn định.

Trải nghiệm nhà phát triển thực sự được cung cấp

Trải nghiệm nhà phát triển trong Astro có cảm giác như ai đó thực sự đã xem xét cách chúng ta làm việc. Thiết lập một dự án mới rất đơn giản, bạn sẽ được hướng dẫn trong suốt quá trình bởi trợ lý thiết lập thân thiện của họ, Houston.

Bạn có thấy hàng rào mã ở trên cùng không? Nó chạy trong quá trình xây dựng, không phải trong trình duyệt. Việc tìm nạp dữ liệu của bạn, logic của bạn - tất cả những điều này xảy ra trước khi người dùng tải trang. Bạn nhận được hỗ trợ TypeScript tuyệt vời, mà không có sự phức tạp của các hook, quản lý trạng thái hoặc phương thức vòng đời. Bạn có thể sử dụng bất kỳ khung nào (hoặc không sử dụng), Astro không giới hạn bạn chỉ sử dụng một cách để làm mọi việc. Cần React để xử lý các biểu mẫu phức tạp? Đặt nó vào. Thích Vue để trực quan hóa dữ liệu hơn? Cứ làm đi. Muốn giữ hầu hết mọi thứ dưới dạng các thành phần Astro đơn giản? Hoàn hảo. Tất cả chúng hoạt động liền mạch với nhau.

Quy trình xây dựng hiện đại và hoàn chỉnh. TypeScript hoạt động trực tiếp, biên dịch Sass được tích hợp sẵn, hình ảnh được tự động tối ưu hóa thông qua thẻ <Image /> của Astro, bạn nhận được thay thế module nóng trong quá trình phát triển. Không cần thiết lập cấu hình Webpack hoặc vật lộn với các công cụ xây dựng. Bạn cũng có thể linh hoạt trong việc hiển thị trang. Xây dựng hoàn toàn tĩnh để có tốc độ tối đa, hiển thị phía máy chủ cho nội dung động hoặc kết hợp cả hai phương pháp trong cùng một dự án. Astro thích ứng với bất kỳ cách nào bạn cần.

Nơi Astro thực sự tỏa sáng

Tác giả nhận thấy Astro rất phù hợp cho các trang web tiếp thị, blog, danh mục thương mại điện tử và trang web portfolio. Về cơ bản, bất cứ nơi nào nội dung là yếu tố chính và bạn không cần quản lý trạng thái phía máy khách phức tạp, Astro đều hoạt động xuất sắc.

Sự đánh đổi

Astro không phải là thuốc chữa bách bệnh. Nếu bạn đang xây dựng một ứng dụng trang đơn (SPA) phức tạp với nhiều định tuyến phía máy khách, cần ISR (xin chào Next.js) hoặc bạn cần quản lý trạng thái nặng giữa các thành phần, bạn có thể cần một thứ khác, chẳng hạn như Next.js. Hệ sinh thái đang phát triển, nhưng vẫn còn rất nhỏ so với Next.js. Định tuyến dựa trên tệp có thể cảm thấy hạn chế trong các dự án lớn hơn (mặc dù một số người thích nó).

Bắt đầu thực sự đơn giản:

# new project
npm create astro@latest my-site
cd my-site

Thêm framework nếu cần #

add framework if needed

npx astro add react

# Bắt đầu phát triển

> start dev

npm run dev

Đặt trang của bạn trong src/pages/, các component trong src/components/, bạn có thể bắt đầu xây dựng những thứ tuyệt vời.

Tại sao Astro lại quan trọng

Sau nhiều năm các framework JavaScript ngày càng trở nên phức tạp, Astro mang lại cảm giác như một luồng gió mới. Nó quay trở lại những điều cơ bản của web - trải nghiệm nhanh chóng, dễ truy cập, ưu tiên nội dung - nhưng với tất cả những tiện ích dành cho nhà phát triển hiện đại mà chúng ta mong đợi. Ấn tượng sâu sắc nhất của tác giả sau khi chuyển đổi nhiều dự án là Astro giúp mọi việc trở nên dễ dàng. Muốn một trang web nhanh? Đó là mặc định. Muốn thêm tính tương tác? Đơn giản, nhưng chỉ ở những nơi bạn cần. Muốn sử dụng framework yêu thích của bạn? Cứ làm đi, Astro không phán xét.

Nếu bạn đang xây dựng bất kỳ thứ gì hướng đến nội dung, từ một blog đơn giản đến một trang web thương mại điện tử hoàn chỉnh, hãy nghiêm túc cân nhắc Astro. Người dùng của bạn sẽ có được trải nghiệm nhanh hơn, bạn sẽ tận hưởng quá trình phát triển và các chỉ số web cốt lõi của bạn sẽ rất tuyệt vời.

Lưu ý - trang web bạn đang đọc blog này được xây dựng bằng Astro.

HN | Độ nóng: 264 điểm | 213 bình luận | Tác giả: pumbaa #

https://news.ycombinator.com/item?id=44507854

Astro mặc định hiển thị các trang web dưới dạng HTML tĩnh, chỉ những phần cần tương tác mới sử dụng JavaScript, tương tự như “tăng cường dần” hoặc “trang web” trong quá khứ, giờ đây được gọi là các đảo JavaScript
Giá trị chính của Astro nằm ở việc nó tích hợp với các framework JS, cho phép framework xử lý các cây con của HTML, hiển thị trạng thái ban đầu thành một chuỗi và hydrate nó ở phía client bằng dữ liệu được tải trước từ server
Astro không phải là tăng cường dần, vì HTML trước khi tải không cần phải hoạt động, nó chỉ khớp với trạng thái ban đầu sau khi JS hydrate
Astro nghe không có vẻ đặc biệt mang tính cách mạng, vì nó phụ thuộc vào JavaScript để tiếp quản các phần tử như biểu mẫu
Giá trị của Astro nằm ở việc gửi HTML không có chức năng trước, sau đó sửa chữa bằng JS được thực thi sau, điều này có thể đơn giản hóa framework so với toàn bộ JS
Ưu điểm của Astro là chỉ cần viết component một lần, việc truyền tải server-client minh bạch đối với nhà phát triển, điều mà các framework truyền thống không có
Astro cung cấp chuyển đổi ngữ cảnh server-client minh bạch, cũng như hiệu suất tốt hơn mà người dùng cảm nhận được
Sự thanh lịch của Astro nằm ở chỗ nó hiện thực hóa các ý tưởng trong quá khứ theo một cách hiện đại hơn, mặc dù bản thân khái niệm này không mới
Astro tìm thấy một điểm cân bằng tốt, đặt mã server và client trong một codebase, có thể xác định mã nào là mã phía server, mã nào là mã phía client, thay vì hoàn toàn phụ thuộc vào kiến trúc SPA

RapidRAW: Một trình chỉnh sửa ảnh RAW không phá hủy và được tăng tốc bằng GPU #

RapidRAW: A non-destructive and GPU-accelerated RAW image editor

https://github.com/CyberTimon/RapidRAW

RapidRAW là một trình chỉnh sửa ảnh RAW đẹp mắt, không phá hủy và được tăng tốc GPU, được xây dựng với hiệu suất làm cốt lõi. Nó là một sự thay thế hiện đại, hiệu suất cao cho Adobe Lightroom®, cung cấp trải nghiệm chỉnh sửa phong phú, đẹp mắt và nhẹ (nhỏ hơn 30MB) cho Windows, macOS và Linux.

Dự án này được phát triển bởi một nhà phát triển 18 tuổi như một thử thách cá nhân, với mục tiêu tạo ra một công cụ hiệu suất cao cho quy trình làm việc chỉnh sửa ảnh của riêng mình, đồng thời làm sâu sắc thêm sự hiểu biết về React và Rust, và được hỗ trợ bởi Google Gemini. RapidRAW phù hợp với các nhiếp ảnh gia thích chỉnh sửa ảnh trong một quy trình làm việc sạch sẽ, nhanh chóng và đơn giản. Nó ưu tiên tốc độ, giao diện người dùng đẹp mắt và các công cụ mạnh mẽ, cho phép bạn nhanh chóng hiện thực hóa tầm nhìn màu sắc sáng tạo của mình. Tuy nhiên, nó không dành cho những người dùng tìm kiếm độ chính xác màu tuyệt đối, hoàn hảo. Mặc dù kết quả tốt cho hầu hết các mục đích, nhưng trọng tâm là vào quá trình sáng tạo trôi chảy, chứ không phải độ chính xác màu hoàn hảo.

RapidRAW vẫn đang được phát triển tích cực và chưa hoàn thiện như các công cụ trưởng thành như Darktable, RawTherapee hoặc Adobe Lightroom®. Hiện tại, trọng tâm là xây dựng trải nghiệm chỉnh sửa cốt lõi nhanh chóng và thú vị. Nếu người dùng gặp lỗi trong quá trình sử dụng, vui lòng báo cáo để nhà phát triển sửa chữa. Phản hồi rất hữu ích để cải thiện sản phẩm.

Các cập nhật gần đây bao gồm:

2025-07-08: Có thể chuyển đổi khả năng hiển thị của các phần điều chỉnh riêng lẻ, sửa lỗi thu phóng ở góc trên bên trái, sửa hành vi thu phóng trong bảng điều khiển cắt xén, giữ nguyên tỷ lệ khung hình gốc mặc định.
2025-07-08: Đã thêm bộ lọc xếp hạng hình ảnh, thiết kế lại bảng điều khiển metadata với bố cục được cải thiện, các phần rõ ràng hơn và bản đồ GPS nhúng.
2025-07-07: Cải thiện các chức năng AI tạo sinh và cập nhật lộ trình AI.
2025-07-06: Tích hợp AI tạo sinh ban đầu với ComfyUI - để biết thêm chi tiết, vui lòng xem lộ trình AI.
2025-07-05: Có thể ghi đè cài đặt hiện tại lên preset.
2025-07-04: Bộ nhớ cache tốc độ cao và chính xác, tăng tốc đáng kể việc chỉnh sửa ảnh lớn.
2025-07-04: Cải tiến đáng kể các shader, cung cấp khả năng khử sương mù tốt hơn, đường cong chính xác hơn, v.v.
2025-07-04: Khả năng xoay 90° theo chiều kim đồng hồ và lật hình ảnh được xác định trước.
2025-07-03: Chuyển từ rawloader sang rawler để hỗ trợ nhiều định dạng RAW hơn.
2025-07-02: Mặt nạ tiền cảnh/hậu cảnh được hỗ trợ bởi AI.
2025-06-30: Mặt nạ chủ thể được hỗ trợ bởi AI.
2025-06-30: Bản dựng Linux được biên dịch sẵn.
2025-06-29: Tỷ lệ khung hình 5:4 mới, chủ đề màu xám tương phản thấp mới và hỗ trợ nhiều máy ảnh hơn (dòng DJI Mavic).
2025-06-28: Phát hành dọn dẹp, cải tiến CI/CD và các bản sửa lỗi nhỏ.
2025-06-27: Phát hành ban đầu. Để biết thêm thông tin về tiến trình ban đầu, vui lòng xem nhật ký phát triển ban đầu.

Các tính năng chính của RapidRAW bao gồm:

Công cụ chỉnh sửa cốt lõi: Tất cả các điều chỉnh hình ảnh đều được xử lý trên GPU bằng các WGSL shader tùy chỉnh để có phản hồi nhanh chóng.
Mặt nạ: Tạo mặt nạ chính xác ngay lập tức thông qua AI phát hiện chủ thể và tiền cảnh. Kết hợp với các mặt nạ cọ vẽ, tuyến tính và xuyên tâm truyền thống, mang lại khả năng kiểm soát tốt.
Chỉnh sửa tạo sinh: Xóa các đối tượng hoặc thêm các yếu tố mới thông qua lời nhắc văn bản. Mỗi chỉnh sửa tạo ra một lớp vá không phá hủy, được hỗ trợ bởi backend ComfyUI tùy chọn.
Hỗ trợ RAW đầy đủ: Hỗ trợ nhiều định dạng máy ảnh RAW nhờ rawler.
Quy trình làm việc không phá hủy: Tất cả các chỉnh sửa được lưu trữ trong một tệp sidecar .rrdata, không chạm vào hình ảnh gốc của bạn.
Độ chính xác 32 bit: Đảm bảo điều chỉnh chất lượng cao, không bị banding hoặc mất dữ liệu.
Điều chỉnh cấp độ chuyên nghiệp: Bao gồm kiểm soát tông màu, đường cong tông màu, phân loại màu, tăng cường chi tiết và hiệu ứng, cũng như các công cụ biến đổi, v.v.

HN | Độ nóng: 251 điểm | 106 bình luận | Tác giả: l8rlump #

https://news.ycombinator.com/item?id=44505876

RawTherapee là một công cụ xử lý ảnh RAW được phát triển bởi những người đam mê khoa học màu sắc, có chức năng script CLI, RawPedia đi kèm cung cấp nguồn thông tin phong phú.
RawTherapee thiếu hỗ trợ xuất HDR, nhưng có thể sẽ được hiện thực hóa trong tương lai thông qua hỗ trợ PNG v3 và Rec. 2100.
Công cụ điều chỉnh đường cong của RawTherapee khó thao tác, khó điều chỉnh chính xác, trải nghiệm người dùng không tốt.
Chức năng mô phỏng “điện ảnh” của Darktable có thể khôi phục ảnh RAW bị phơi sáng quá mức, trong khi RawTherapee không có công cụ tương tự.
Giao diện người dùng của RawTherapee không đủ trực quan, khó sử dụng đối với người dùng không am hiểu kỹ thuật.
Chức năng khử nhiễu của Lightroom tốt hơn RawTherapee, trải nghiệm người dùng mượt mà hơn.
Một số người chọn sử dụng Darktable và RawTherapee vì không muốn mua phần mềm, nhưng việc thiếu kiến thức kỹ thuật sẽ nhanh chóng gặp phải khó khăn.
Có người giới thiệu Nitro, một phần mềm được tạo ra bởi đội ngũ kỹ sư cũ của Apple, phù hợp với macOS.
Pixelmator Pro là một lựa chọn tốt trên Mac, mua một lần với giá cả hợp lý.
Các trình chỉnh sửa mã nguồn mở được tạo ra bởi các lập trình viên chứ không phải các nhiếp ảnh gia, vì vậy các công cụ cần thiết để chỉnh sửa ảnh RAW chuyên nghiệp hoặc bị ẩn trong các chức năng phức tạp, hoặc hoàn toàn thiếu.
Những phần mềm này được tạo ra và sử dụng bởi các nhiếp ảnh gia, được thiết kế cho nhiều mục đích sử dụng, không chỉ giới hạn ở nhiếp ảnh sáng tạo, vì vậy bao gồm nhiều thuật toán khử răng cưa.
Nhiếp ảnh gia không cần kỹ năng phát triển phần mềm, trong khi các lập trình viên có thể lạc lối trong các chức năng geek khác nhau, bỏ qua tính khả dụng thực tế cho đối tượng mục tiêu.