2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン（以降はLog4j2と記載）で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 １．何が起きたの？ Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性（CVE-2021-44228）を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
Webセキュリティ製品などを手掛ける米LunaSecの報告によると、Minecraftの他、ゲームプラットフォームのSteamやAppleの「iCloud」もこの脆弱性を持つことが分かっており、影響は広範囲に及ぶと考えられるという。 この脆弱性の影響があるのは、Log4jのバージョン2.0から2.14.1までと当初みられていたが、Log4jのGitHub上の議論では、1.x系も同様の脆弱性を抱えていることが報告されている。対策には、修正済みのバージョンである2.15.0-rc2へのアップデートが推奨されている。 セキュリティニュースサイト「Cyber Kendra」によれば、この脆弱性に対して付与されるCVE番号は「CVE-2021-44228」という。 脆弱性の報告を受け、Twitter上ではITエンジニアたちが続々反応。「やばすぎる」「思っていたよりずっとひどいバグだった」「なぜこんな
［速報］10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードのコピーはフェアユースの範囲 オラクルがGoogleに対して、Android OSがJavaの著作権を侵害しているとして訴えていた裁判で、米連邦最高裁判所はGoogleが著作権侵害をしていないとの判断を示し、Googleが勝訴しました。 以下は米連邦最高裁判所の動向を伝えているSCOTUSblogのツイートです。 BREAKING: In major copyright battle between tech giants, SCOTUS sides w/ Google over Oracle, finding that Google didnt commit copyright infringement when it reused lines of code in its An
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence（正確には分社前の会社）に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな
閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？ そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 （この記事はJava8が対象となります。） OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no
Javasparrow株式会社（読み：ジャバスパロウ、本社：東京都千代田区、代表取締役：國舛等志・稲田祐介、以下「当社」）は、米国Oracle America Inc.（以下「オラクル社」より、弊社商標「Javasparrow」の商標登録に対する無効審判請求を前提とした商標権一部放棄の検討要求を受けましたので、下記の通りお知らせいたします。 社名の由来について弊社の社名である「Javasparrow」は、鳥綱スズメ目カエデチョウ科キンパラ属に分類される鳥類である文鳥の英名です。 代表取締役が文鳥好きで、文鳥のように人々に愛されるような存在でありたい、また鳥瞰の目をもって物事を大きくとらえ全体を見渡したもの作りをしたい、という想いから社名をJavasparrow株式会社にしました。 2017年10月には、社名である「Javasparrow」および弊社の第1号製品である「wesign」について
Oracle Javaに訪れた大きな変化に気が付いていない人が多い 2018年9月26日に、Oracle Java 11がリリースされました。 Oracleからダウンロード可能となっていて、これまでいろいろ騒ぎになっていた割にはいつもと同じ景色で拍子抜けしたという方も多いのではないでしょうか。 何も世界は変わっていない。 しかし、それは勘違いです。以下の文を、ご理解ください。 契約が変わった Oracle Java 10までは、 Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX （Java SEプラットフォーム製品およびJavaFX用のOracleバイナリコードライセンス契約） という契約でした。全文はこちら（オラクルのサイト）をご確認ください。 Oracle Java 11か
自前のサイトで今までにない例外（Illegal group reference）が発生していたので調査していたら、どうも「replaceAll」によるものみたい。 文字列の置換は「replace」と「replaceAll」の二つがあるのだけど、replaceだと最初の一文字だけ置換かと思って、いままではすべて変換は「replaceAll」を使っていた。 でもどうもどちらもすべて変換してくれるようです。 違いは、replaceは正規表現ではなく、replaceAllは正規表現であるということみたいです。 では、なぜ「replaceAll」は上記例外が発生しているか？ それは置換後文字列に「$」が入っているためでした。 正規表現では、「(」と「)」で結ばれた文字を、置換後文字列の「$1」「$2」で置き換えるということができるのでそのために「$」を検出したら置き換えをしようとしている模様。 「$
About ThreeTen-Backport provides a backport of the Java SE 8 date-time classes to Java SE 6 and 7. The backport is NOT an implementation of JSR-310, as that would require jumping through lots of unnecessary hoops. Instead, this is a simple backport intended to allow users to quickly use the JSR-310 API on Java SE 6 and 7. The backport should be referred to using the “ThreeTen” name. The backport i
クライアントへの応答を制御する－responseオブジェクト－ outオブジェクトがコンテンツ本体の出力を制御する役割を担っていたのに対し、responseオブジェクトはむしろコンテンツ本体に付随するヘッダ情報やステータスを制御する際に用います。 一見、outもresponseも「クライアントへの出力手段を制御するための手段」を提供するオブジェクトですので区別がつきにくいかもしれませんが、ざっくりと区分するならば、前者は可視的な情報を、後者は不可視の情報を制御するものであると思っていただければよいでしょう。 ヘッダ情報の発行 先のrequest_header.jspでは、クライアントから送信された一連のヘッダ情報を取得してみました。ここでは、サーバ側での処理結果にカスタムのヘッダ情報を付加することで、クライアント側をコントロールしてみることにします。 以下サンプルは、クライアント側の「キャ
なんとなくネットサーフィン (死語) してたら次の記事を見つけました。 確かに Java のファイル読み込みはいろいろややこしいですよね。 今時なJavaでテキストファイルを読みこむ方法 - /dev/null 「Java ファイル 読み込み」 とかで検索しても FileInputStream を InputStreamReader でラップしてさらに BufferedReader でラップする例が出てたりして、Java を使い始めたころの私も混乱させられました。 参考: テキストファイルを読む - テキストファイルの入出力 - Java入門 Java ファイル読み込み（文字） とほほのJava入門 昔はこういった方法が当たり前でしたが、今ではもっと簡単になっています *1。 Java SE 7 で導入された Files や Path といった便利なクラスを使うことで、ファイル読み込みの処
いろんな言語で使うことができるテンプレートエンジン、mustacheというものがあるそうです。 「ロジック・レス・テンプレート」といってるだけあって、構文もシンプルな感じです。 mustache http://mustache.github.com/ manual http://mustache.github.com/mustache.5.html 正確には、いろんな言語で使うことができるというよりはいろんな言語の実装が用意されている、というのが正確な表現なのでしょうが。 今回は、Java版を使ってみます。 mustache.java https://github.com/spullara/mustache.java 基本的な使い方 Mavenなり、Gradleなりを使って、依存関係の定義をしましょう。自分は、Gradleを使用しました。 apply plugin: 'java' vers
今回の記事ではmustacheの記法について書いていきます。 もともと社内共有用にドキュメントを日本語＆適当に端折って簡単にまとめてたのですが、せっかくなのでQiitaにも投稿してみることにしました。 mustache is 何 様々な言語で組み合わせて使えるテンプレートエンジンです。 Loopなどロジック地味たことをする構文が存在しないので、Logic-Less templatesと呼ばれています。 タグの記法が{{hoge}}みたいになっていて、 { が口ひげみたいに見えるためmustache(口ひげ)というらしいです。 mustache記法 早速記法について書いていきます。 ドキュメント 英語のドキュメントがあるよ。日本語はないよ(´・ω・｀) https://mustache.github.io/mustache.5.html デモ これ書き方あってんの？を簡単に確認したい場合は以
JMustache のサイトからダウンロードした samskivert-jmustache-jmustache-1.3-8-g7255cb7.zip から Mustache.java, MustacheException.java, MustacheParseException.java, Template.java のソースコード4ファイルを取り出して使う。外部ライブラリに依存していないので簡単に導入できる。ちなみに JMustache のライセンスは BSD License っぽい。 環境: Windows XP + Eclipse 3.4 + Java SE 6 いくつかサンプルコードを書いてみる。 まずは、JMustache のサイトにあったシンプルなサンプルを書いて実行。 メイン処理は Mustache.compiler().compile(String) だけなのでお手軽。 J
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
