XZ Utilsの脆弱性 CVE-2024-3094 についてまとめてみた - piyolog
2024年3月29日、Linux向け圧縮ユーティリティとして広く利用されているXZ Utilsに深刻な脆弱性 CVE-2024-3094 が確認されたとして、研究者やベンダがセキュリティ情報を公開しました。この脆弱性は特定の条件下においてバックドアとして悪用される恐れがあるものとみられており、当該ソフトウエアのメンテナのアカウントにより実装されたソフトウエアサプライチェーン攻撃の可能性が指摘されています。ここでは関連する情報をまとめます。 脆弱性の概要 xzとは主要なLinuxディストリビューションに含まれる汎用的なデータ圧縮形式で、今回問題が確認されたのはその圧縮・解凍ユーティリティであるliblzma(API)を含むXZ Utils。CVE-2024-3094が採番されており、Red Hatによって評価されたCVSS基本値はフルスコアの10。影響を受けたライブラリをリンクしているssh
Core NGINX Developer Forks Web Server Into Freenginx - Phoronix
Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 19+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phor
今年のオープンソース活動振り返り @ 2023
2023年のオープンソース活動の振り返り記事です。 2023年のオープンソース活動の振り返り記事を書きました！ - textlint/secretlint: 継続的にアップデート - jsprimer: 第二版の改訂出した、Open Collectiveやっていきたい - Notionに色々集約するツール書いてた "今年のオープンソース活動振り返り @ 2023 | Web Scratch"https://t.co/iwUCQfFWiu pic.twitter.com/7qgDjitpQm — azu (@azu_re) December 31, 2023 今までの振り返りの一覧です。 今年のオープンソース活動振り返り @ 2022 | Web Scratch 今年のオープンソース活動振り返り @ 2021 | Web Scratch 今年のオープンソース活動振り返り @ 2020 | W
OSS 観光名所を貼るスレ - ぽ靴な缶
これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ
【翻訳】Prettier を Rust で書き換えたプロジェクトに $20k の報奨金を支払うプログラムは Biome が勝ちました
この記事は vjeux 氏によって Prettier 公式ブログに投稿された「$20k Bounty was Claimed!」を許可をもらって翻訳したものです。 もとのタイトルを翻訳するのが難しかったので、できるだけわかりやすいものに翻訳しました。 PrettierというJavaScriptのコードフォーマッターは、人々がコードを書く様々な方法を慎重に扱うことで、驚くほど広く採用されています。この時点で、フォーマットロジックは安定しており、私たちの三項演算子に関する作業が完了すれば、それは満足のいく状態になるでしょう。 これは、次の重要な側面に注目できるということを意味します：パフォーマンス。Prettierは決して速いとは言えませんが、ほとんどの使用例には十分な速さです。これはいつも不満足な感じがしたので、何かをすることを望んでいました。それには、友好的な競争以上の方法はありません。
【23-06】中国初のオープンソース・ライセンス訴訟、法廷がGPLライセンスの意義を認める|Science Portal China
高須 正和： 株式会社スイッチサイエンス Global Business Development/ニコ技深圳コミュニティ発起人 略歴 略歴：コミュニティ運営、事業開発、リサーチャーの3分野で活動している。中国最大のオープンソースアライアンス「開源社」唯一の国際メンバー。『ニコ技深センコミュニティ』『分解のススメ』などの発起人。MakerFaire 深セン(中国)、MakerFaire シンガポールなどの運営に携わる。現在、Maker向けツールの開発/販売をしている株式会社スイッチサイエンスや、深圳市大公坊创客基地iMakerbase,MakerNet深圳等で事業開発を行っている。著書に『プロトタイプシティ』(角川書店)『メイカーズのエコシステム』(インプレスR&D)、訳書に『ハードウェアハッカー』(技術評論社)など medium.com/@tks/takasu-profile-c50fee
Bounties Damage Open Source Projects ⚡ Zig Programming Language
Bounties Damage Open Source ProjectsAuthors: Andrew Kelley and Loris Cro Please don’t use bounties to incentivize Zig development. This blog post is inspired by this GitHub issue from three days ago: Support WASIX (see also) Here are some reasons why we believe bounties are a poor form of sponsorship when it comes to software development: Bounties foster competition at the expense of cooperation.B
OSSで世界と戦うために - ゆーすけべー日記
「日本人」を理由にしたくないし、「コードは全世界共通語」なのは分かっているけど、自分が日本人で日本語を母国語としていることはOSSにおいて不利になる。 この2年間のHonoの開発をしてきた経験で分かったことだ。 そこに目を瞑ってはいけないし、自覚することで世界と戦えるかもしれない。今回はそのことについて書こうと思う。 8k 現在、HonoのGitHubスター数は8,000を超えた。 これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。 数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。 なぜ「戦う」のか なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 ま
jq 1.7をリリースしました - プログラムモグモグ
jqがjqlang organizationに移譲され、数名の新たなメンテナーを入れた開発体制に移行してから三か月が経ちました。 私にとってこの三か月はとても濃厚で、これまでのOSS活動の中でも特に大変な期間でした。 itchyny.hatenablog.com github.com リポジトリの管理権限をいただいてからまずやったことは、既存のissueやPRの整理でした。 500ほどのissueとPRに目を通し、ラベルをつけて、解決済みのものを閉じて、直近で入れたいものを独断でリリースマイルストーンに入れていきました。 この整理がついた頃には他のメンテナの活動も活発になり、私の作ったマイルストーンのissueやPRを確認してくれました。 そして先日、ようやく1.7をリリースしました。 1.6から実に五年弱、一時は開発が完全に止まってしまいプロジェクトの存続を危ぶむ声も上がるような状況から
OSSすぐ死ぬ - kmuto’s blog
（結論はなく、ダラダラ昔話を書いただけ。） サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア（OSS）を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
core-js、ecspresso、Let's Encryptへの寄付を行いました - Hatena Developer Blog
こんにちは。CTOのid:motemenです。 このたび、これまでも継続的におこなっていたLet's Encryptへの寄付に加え、core-jsおよびecspresso（の作者であるfujiwaraさん）へ、はてなとして寄付を行いました。Let's Encrypt以外にも、はてなで利用しているOSSとして新たにこの2つに今回寄付した次第です。 ほかの多くの企業と同様、はてなのウェブサービスの大部分は、創業以来、多くのOSSによって支えられています。世のソフトウェア開発者がオープンにしてきた処理系やライブラリ、コミュニティのおかげで、初期のはてなから今にいたるまで、さまざまなプロダクトを開発し、事業として世の中に価値をもたらすことができています。 はてなではこれまでもコミュニティイベントのスポンサーや、（多くは個人の活動としてですが）OSSへのパッチ貢献やOSSの自作、イベントのスタッフ参
オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
星取表のアンチパターン
これだけみると LibC がよく見えますね。 オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。 中立な立場でライブラリを選定する過程として出てくることがあります。 自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。 星取表を作る側の意図 よく見かけるパターンがこれです。 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている 恣意的な項目選定で、そもそも負けている そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較) 特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B
jq が jqlang organization に移譲されました - プログラムモグモグ
JSONを操作するコマンドラインツールであるjqは、これまでオリジナル作者であるStephen Dolan氏 (@stedolan)のリポジトリ(github.com/stedolan/jq)で管理されていました。 メンテナンスはNico Williams氏 (@nicowilliams)とWilliam Langford氏 (@wtlangford)の二名が行なっていましたが、近年は活動が減っておりメンテナンスが滞っていることが度々指摘されていました。 最新のリリースは2018年11月に行われた1.6であり、その後に様々なバグ修正やパフォーマンス改善、新機能の実装が行われているのにリリースされておらず、またissueやPRも放置されがちになっていました。 さらにCI (AppVeyor)は常に落ちるので、簡単なドキュメント修正でもCIが通らず苦情が来る、数か月放置されたPRは作った人が諦
趣味だったOSS活動で収入を得られるようになるまで。「継続」と「発信」がキャリアを切り開いた - Findy Engineer Lab
はじめまして。鈴木 颯介(@__sosukesuzuki)です。私は筑波大学情報学群情報科学類の学生をしながら、Ubie株式会社でプロダクト開発エンジニアとして働いています。また、余暇時間を使って、いくつかのOSSの開発に関わっています。 この記事では、私がプログラミングやOSS活動を始めたきっかけから入り、OSS活動で収入を得るということについて私なりの考えを示し、最後にOSSと私のキャリアについて振り返ります。 私は2022年の3月に初めて正社員として働くようになり、まだキャリアと呼べるほど長いキャリアを持ってはいません。ですのでこの記事が、私と立場の近いコンピューターについて勉強している学生やまだ経験の浅いエンジニアの方々が、ご自身のキャリアを考える上での参考になれば幸いです。 最初に断っておきますが、私がこれまで関わってきたOSSのほとんどは、JavaScriptのコミュニティのも
趣味でOSS活動をしていたらDeno Land Inc.にジョインすることになった話
で、GitHub Sponsorsを始めたところ多数のご支援をいただくことができたことを書きました。 その後、OSS活動を細々と続けていたところ、JavaScript/TypeScript ランタイムであるDenoの開発を行っている Deno Land Inc.にジョインすることになりました。 ジョインまでの流れ 上記の記事で書いたように、deno_lint などのDeno関連のプロジェクトにコントリビュートをしていました。定期的にコントリビュートしていると、他の人からのPull Requestのレビューなどもお願いされるようになります。Approveをすることはできますが、mergeの権限はありませんでした。その他にも、issueをクローズするための権限もなく、整理のためにクローズしたいissueがあっても、メンテナに依頼をする必要がありました。 大した手間ではなかったものの、メンテナ権
ユーザーとの摩擦を最小限に保ちつつ Prettierを改善していくための機能設計
ユーザーとの摩擦を最小限に保ちつつ Prettierを改善していくための機能設計 2023/03/24 Encraft#1 もともと「パフォーマンスとメンテナビリティのためにPrettierを複数のパッケージに分割する計画」というタイトルで話す予定で、イベントページにもそう書いてあったと思うんですが、急遽テーマを変えることにしました。 「ユーザーとの摩擦を最小限に保ちつつPrettierを改善していくための機能設計」というタイトルでお話をさせていただきます。 前のお二人とはちょっと「設計」という言葉の意味が違いそうで、皆さんのためになる話ではないんですが、「へー」と思いながら聞いていただ...
GitHubのリリースノートを自動化する仕組み
GitHub のAutomatically generated release notesを使ってリリースノートの内容を PR に基づいて自動生成するフローを作りました。 今までは、コミットメッセージのルールであるConventional Commitsとconventional-github-releaserを使って、コミットからリリースノートを自動生成していました。 他の人の PR でも、squah merge でコミットメッセージを書き換えることで、リリースノートに反映されるようにしていました。 ただ GitHub に仕組みは違うけどほぼ似たことをするAutomatically generated release notesという機能が実装されているので、これをベースに移行しようと思って、そのワークフローを作っていました。 リリースノート自動生成テクニック - mizdra’s bl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2022年のOSS活動の振り返り
core-js/docs/2023-02-14-so-whats-next.md at master · zloirock/core-js
