はてなキーワード: JREとは
俺はさあ、「世の中のどのくらいの人がJREなるものを理解できるでしょうか。」って世の中をまず変えたほうがいいと思うんだよ。
国民の9割が「JRE?ああJavaでしょ。Javaの仮想環境をコンピュータに導入するための。Java Runtime Environmentね。10年くらい前の情報の国民講義で全国民が習ったはずだよね?当然覚えてるよ」って言えるくらいのリテラシーを備えててほしいわけよ。中学生くらいから後期高齢者までね。
国民の情報リテラシーが高ければ行政コストがめちゃくちゃ削減できると思うのよ。お金だけの問題じゃない。世の中がめちゃくちゃ風通し良くなるはずなんだよ。もう情報リテラシーの高い人だけで国作ったほうが早いんじゃねって思うくらいだけど、まあ現実的にはそんな逃げ道はないわけよ。むしろ情報リテラシーを浸透させるためにこそ情報技術を使うべきだし。
JREをインストールして、公式ランチャーで使用するjavaを指定してもうまく動かない。
そもそもマイクラに同梱されているJREは8の51とかクソ古いバージョンなのが気持ち悪くて仕方ない。
そんなときに使うべきなのは、非公式ランチャーのMultiMC。
openjdkのサイトからJDK14を落としてきて、PATHとJAVA_HOMEを設定して、こいつの設定で使用するjavaを指定すればOK。
JVisualVMを同時に起動するとか、いろんなログがすぐ見られるようになってるとか、modのインストール機能とかいろいろ付いてて非常に便利。
ただ注意しないといけないのは、1.13までしかForgeの自動インストールができないこと。
まーいろいろなMODもどんどんFabricに対応してきているので、Forgeでしか使えないMODが無いと困るって事が無い限り大丈夫。
各種ポイントと現金でしか買えず、クレジットカードやICカード、QRコード決済で買えないものを探している。
「現金でしか買えないもの」ではなく、「各種ポイントと現金でしか買えないもの」だ。
理由は、
クレジットカードなどで買えるものはできるだけその方法で買いたい
→ポイントが溜まってお得
ということだ。
そんな感じで買い物をしていると各種ポイントが溜まるが、前述のとおり、
できるだけお得にポイントを溜めたいし使いたい。
クレジットカードで決済できる商品にポイントを使ってしまっては、
だから、ポイントか現金でしか買えないものにポイントを使うことで
お得の度合いを最大化したいが、これがかなり少ない。
正確には楽天カードなら決済できるが、これ以外知らない。
・PayPayポイント
元号対応で、過去の帳票についてシステムテストを繰り返していたところ、明治初年のテストデータをパスしないバグが見つかった。
Javaのlocaldateが1968/1/1の深夜0時の場合、なぜか1967/12/31の23時41分くらいとなぜか19分ちょい絶妙にずれるため
mmSSを切り捨てる系の日付処理で1967/12/31で検索していることが原因だとすぐにわかったが、
最終的にきしださんのウェブサイトにて日本標準時が1880年を境に江戸城から現在の明石に変更していることを知った。
http://d.hatena.ne.jp/nowokay/20150109
有志が常にtimezoneの変更をJREに行っていることをついでに知る。
http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html
直近だと北朝鮮がつい先日の5月に標準時を変更したらしい。韓国=日本と同じ時間だそうだ。
2015年からたった3年間だけ使われたKorea Timezoneが韓国との融和をうたうパフォーマンスのために一蹴。
北朝鮮にシステム会社がどれだけあるかは知らないけど、中の人たちお疲れ様です。
https://www.jreast.co.jp/card/caution/change_atre.html
コンテストやるのはいいんだけど、今あるJREポイント対応カードのデザイン、真ん中にデカくあるマークがかっこ悪いので、コンテストレギュレーションのデザインで作り直して欲しい。特にアトレカードはとてもきれいだったのに台無しになってしまったし。 — 堀内敏生 (@donpajp) 2017年7月6日
JREポイントがダサく、今のアトレカードのちょうちょが気に入っているその一心でアトレビューカードにしたくない。。— けい@ホルンと歌舞伎♥️ (@keiootee) 2017年4月28日
ちょうちょのシルエット部分が透過しててかわゆいカードだったアトレカードが失効していて、クッソダサいJREポイントのマークがベットリ書き込まれてちょうちょも透過しなくなったクソダサアトレカードになってしもうた— ぷりっとさとみん☆チャン (@_alimika_) 2016年11月12日
今までのアトレカードの、右下の蝶が透明なデザインすごく気に入ってたから、新しいデザイン(JREポイントのロゴをドーンなやつ)になって残念、、💔 — みっきー (@carrieCdel) 2016年3月10日
アトレカードのほんわかした色合いに、JRE POINTのガツンとしたロゴが入るとすごいインパクトあるな... もうちょい... なんとかならんかったん...? — Emma Haruka Iwao🏳️🌈 (@Yuryu) 2016年2月28日
JREポイントねぇ…アトレカードのデザインがぶち壊しになってて溜息— Yoshimura JAM (@jam_f_t) 2016年2月24日
JREポイント移行後のアトレカード糞ダセーw— YK_21@10・11草津温泉 (@yasyuba) 2016年2月16日
・suicaポイントは「黄のJREポイント」へと名前が変わる
・suicaで支払うと「黄のJREポイント」がたまり、JREポイントカードを出すと「緑のJREポイント」がたまる
・片方のJREポイントしかもらえない店が多いが、JREポイントカードを出してsuicaで支払うと両方のポイントがたまる店もある
・「黄のJREポイント」と「緑のJREポイント」はまとめて一緒に使え、suicaへチャージできるようになる
・来年にはクレジットカードのVIEWポイントも「青のJREポイント」へと名前が変わり、JREポイントに共通化される
・VIEWカードでsuicaオートチャージして「青のJREポイント」をためて、suicaで支払うと「黄のJREポイント」がたまり、店によってはJREポイントカード出すと「緑のJREポイント」がたまる
・つまり「黄のJREポイント」「緑のJREポイント」「青のJREポイント」が存在するようになる
ってことであってる?
原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題:Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日:2015年11月12日(午後にタイトルを日本語にしました)
----
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。)を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア(通信相手)とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注:blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント:
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です)
エディタで。vimのキーバインドで。teratermの背景色で。ログファイルの名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。エラーのクラス名で。プロパティ名で。セッター、ゲッターを付けるかつけないかで。コンストラクタで。newを上書きするかしないかで。jreのeditionで。eclipseの見た目で。javadocのエディションで。クラウンのドキュメントIDで。githubにいくつ持っているかで。tryのインデントで。タブを表示するかしないかで。エディット中の飲み物で。待ち合わせはスタバなのかエクセルシオールなのかで。セブンイレブンのコーヒーのサイズで。そのコンビニのコーヒーが一番うまいかで。IDカードは伸びるストラップがいいのか悪いのか。寝るときは机の下か椅子を並べるのか。デスクの上にフィギュアは置いていいのか悪いのか。めんまかつるこか。
上位レイヤーの話はしてないんだけどね。
「Python」でも良いし、「JRE」でも良いし、「HSP」でも良いよ。
「正しい申告」と言うのは、自身が必要とする実行環境についての、正しい申告。(リビジョンとかね)
「すべてのアプリが、自身が必要とする実行環境を必ず用意する」方が、一般市民御用達のWindowsではユーザーにやさしい。
配布サイトが変わる実行環境やライブラリって結構あるが、それは「アプリが独自に解決」すべきなのか。
それとも、それらの実行環境を配布する人は、逐一公的な実行環境としてマイクロソフトに報告しなきゃならなんのか。
1年前の記事がリンクすべて死んでるとかざらにある。
って言うようなパッケージは、自力で解決しろよ、と思うんだが?
ちょっと時間かかったので書く。
VirtualBox上のUbuntu10.04にIntel Fortran11.1をインストールしたのでメモ。普通のIntel Fortranは有償だが、Linux版の非商用に限り無償である。ちなみに、g95やgfortranに比べ厳しくエラーを拾ってくれる他、最適化オプションにより計算時間が大幅に短縮される。
1.Intelのサイトにいって非商用版のところから本体をダウンロードする。CPUによりいくつか種類があるが、適切なものを選ぶ。2010年5月現在では、
http://software.intel.com/en-us/articles/non-commercial-software-development/
からいける。途中でメールアドレスを打って、そこにキーが送られてくる。
./install.sh
を実行。するといろいろ言われるので、読んでEnterを押す。途中でアクティベーションがあるので、先ほど登録した際に言われたのを入れる。
3.いろいろパッケージが足りない、と言われる。もしくはバージョンがサポートしてないと言われる。俺の場合は、
g++
libstdc++5
をapt-getなりネットなりから探して入れる。最後のやつは
http://packages.debian.org/stable/base/libstdc++5
から持ってきた。
4.インストールが終わる。その後、パスを通す。インストール先が標準ならば、自分の場合は、
sudo gedit ./bashrc
をして、最後に
を加えた。これで、例えば
ifort -v
ってやると、
Version 11.1
って返ってくる。これでインストール無事終了。
#そういえば、Ubuntu8.04LTSのVirtualBox用のを使おうとしたら、Kernel Panicになって使えなかった。なんでだったんだろう。
わりあい早い段階でid:tailtameさんが適切な突っ込みしてたのに、このツリーの最初の投稿している増田はとりあげないとかどういうこと思っていた。
FFFTPだけ削除すればいい、みたいなのはどうよって言う。入り口になるJSオフや脆弱性突かれるFlash、PDF、JAVA(JRE)、QuickTimeをアップデートしたほうがいいよね(゚ε゚) //あと検証した人の http://twitter.com/fujista/status/8406841194
<<最重要>>
このないようにはJSオフや脆弱性突かれるFlash、PDF、JAVA(JRE)、QuickTimeをアップデートは含まれてないからなぁ。