「OpenSSL」を含む日記 
はてなキーワード: OpenSSLとは
2024-02-01
■本日の趣味プログラミング
第3回 さくらインターネットのスタンダードプランの環境にnpmをインストールする
第2回が頓挫したので、その原因を取り除くためにnpmとやらをインストールする。
参考文献を元に進める。
まず新しいバージョンのOpenSSLをコンパイルするらしい。あと新しいバージョンを使うにはPythonも必要らしい。
openssl version OpenSSL 1.1.1k-freebsd 24 Aug 2021 python --version Python 3.8.12
いきなりnpm(⇔Node.js?)のコンパイルが行けそうな気がしたので、とりあえずやってみる。
参考にしたサイトにはOpenSSL云々に関することが書いてあるが、その辺は全部問題ないことを祈って、関連するオプションを全部取っ払う。
curl -sSf https://nodejs.org/dist/v20.11.0/node-v20.11.0.tar.gz -O tar zxf node-v20.11.0.tar.gz cd node-v20.11.0 ./configure
とすると、
Node.js configure: Found Python 3.8.12... WARNING: C++ compiler (CXX=g++, 9.4.0) too old, need g++ 10.1.0 or clang++ 8.0.0 WARNING: warnings were emitted in the configure phase INFO: configure completed successfully
「successfully」なら問題ないよな？
続いてmakeだ。makeってなに？もちろんconfigureもよくわかってない。大規模なプログラムをコンパイルするときに必要なヤツというボンヤリとした認識だ。
当然コンパイルがなんなのかもよくわかってない。
nohup make install DESTDIR=/home/*****/local PREFIX=
ここから30分経っても応答が無いので飽きる。
はい、もう無理。飽きた! 次回があるとしたら「npmをインストールする②」である。
もっと新しい情報があったようだ。こっち見てやればよかった。
2023-11-26
■
集合知っていうかネットの力とかかな。wikipedia とかもそうだけど、みんなの力で！みたいな顔をしていて実際は数万人とか数十万人に１人のエクストリームな知識と行動力の人だけが動かしてるのが現実だよな。
世界の何十億人が使っているコア技術なのに、ボランティアの１人が全てを背負っている。
あれは自分もOSSだから多くの人たちが力を合わせて開発、運用しているんだ！と何故か無邪気に勘違いいしてたけど、実際は一部のエクストリームな活動の犠牲の上に積み上げられていた。
インターネットの集合知とかも多分嘘で、ネットに出回っている100の情報があったら99.9％は利用者の1/10000くらいの人間だけが出力した内容、またはそれらの劣化コピーの使いまわしな気がしている。
これは元々人間には独自の情報を語る能力、独自の考えや感想とか個人の妄想とか感情とかを垂れ流すインセンティブもないし、会話にそんなものを誰も要求していないみたいな、旧来の社会敵な動きとかが原因な気がする。
口を開けばトムラウシ山遭難の話だとか、三毛別羆事件、福岡大学ワンダーフォーゲル部ヒグマ事件。
これら情報は集合知じゃなく、一部の記者の仕事であり。そしてそれをまとめた一部のエクストリームな活動家の仕事であって、集合知ではない。
エクストリームな１人に依存している状況なので、専門家が正しいことを言っていても大衆の騒音にかき消されてしまっている、みたいな集合に潰されてる智慧がある気がする。（具体的な事例は思いつかないけど）
それって多分私が思い描いていた集合知のイメージとはかけ離れている。
気がついたと言うか、認めたくなかった事実というか。
2023-01-12
■anond:20230112221133
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
2019-11-20
■情弱IT企業への怒りと愚痴
この企業は、真っ赤かなレッドオーシャンのとある企業向けサービスをやっておりまして、開発をやってます。
基本的に受託開発のほうがメインの会社です。受託開発のほうはSE女衒に外注したりしてます。
インフラは利用企業に必要な設定とかやります。基本外向けじゃないのでFWの設定とか、証明書の設定とか、利用数が多くなるに連れCPUの数を増やしたり、サーバーを増やしたりする必要があるとそれの計画を立てて増やす。
インフラチームがやるのはそれだけです
Linuxで何かがあったときに調べる方法のレクチャーしました。
アップデートの方法とか、iptablesの設定とか、SELinuxの設定、監査ログの見方、httpサーバーのいろんなチューニングの方法、MySQLのバックアップ計画の考え方、RHELのsystemdについての説明、OpenSSLとかBashの脆弱性があったときの脆弱性の調査、いろいろなことをこっちでやりました。
全部、アプリケーション開発側がレクチャーして手順書を作りました。
サーバーの構築も俺たちの手順書通りです。
PHPとPythonのインストールについてはアプリの都合だから、アプリ開発の責任でいいけど、httpやネットワークはインフラの仕事だと思うんですの。
インフラは何をやっているんです？
そう、インフラはお客様の言われた通りの設定をするだけチームなのです。
FWとかドメインの設定をしたあと、お客様に接する機会が多いからウチのサービスの設定とかもやることになっているのです。
じゃあインフラじゃないじゃん
Bashのコマンドも手順書に書いてあるだけのことしかしないんです。
何年か前にオブラートに包んで、もっと独自で行動するようになったらいいんじゃないですかねぇと行ったけど
業務知識があれば問題ないというスタンスでずっと変わっていないのです。
最初に作った人たちはそもそも外注の人が中心なので社内にノウハウがないんです
そういう人たちがいなくなったらどうするんでしょうね。
2018-09-10
■弘法は筆を選ばずの格好良さに憧れて迷走
大坂なおみの優勝で、ラケットが市販の物というので、かっこいいなって思った。
エースパイロットでもカラーリングだけ違うけど量産機乗ってるみたいなキャラがいい。
昔、BackTrackというペネトレーション特化型のLinuxディストリビューションがあったでしょ
ワナビーは憧れてた人が多かったんよ
なんか中二心をくすぐる雑誌とかで紹介されたりしてさ。
で、痛い話なんだけど
BackTrackっていう名前はかっこいい名前のまま憧れててさ
そのワナビーコミュニティの中では、時代はkaliみたいな雰囲気になってたんだけど(皆ちゃんと使いこなせてないけど)
「俺は使いやすいからあえて古いBackTrack使ってっから」って言ったりしてさ
完全のあれよね。古いシステムだけど技でそれを補う的なストーリーを演出してたよね。
実際はリポジトリも閉じちゃってバージョンアップできないし、カーネルのバージョンも何年も前のやつで止まってるのよね
でもそんな実際的な不具合は使いこなせてないからわかんないわけよ。
ぶっちゃけOpenSSLとか古いまんまだから、当時の新し目の暗号スイート使えないしさ。他にもブラウザも古いしさ。
ペネトレーションテストするOSがペネトレイタブルな状態ってすごい恥ずかしいよね。
まあ、当時はそんなのもわかるはずもなく、間違ったかっこいい演出しちゃたけど、あれは笑われてたなと思うよ。
はじかしぃ
2018-01-31
■anond:20180130221601
一番最初にHomebrewを落としてくるときなんだけど、素のOSX LoinのcURLを使ってHomebrew用のcURLを落とす過程で、セキュリティ接続のエラーが起きてるみたいだ。
困らないケースって、その人がHomebrewを導入したタイミングではまだレポジトリが高いセキュリティを要求してなかったとか、
あるいはFinkやMacPortsから移行する場合、新しめのOpenSSLやcURLを入れていたからセキュリティ接続ができたんじゃないか、と思う。
とにかく、素のLionのcURLはHomebrewのcURLを落としてこれない。セキュリティ証明書の問題かもしれないが、そのあたりはよく分からないからなんかもういいってなってる。
2017-01-22
■ownership とシステムプログラミングその他に関する怪文書
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。
安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．
宮森
安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？ これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）
安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh（省略されました
安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
＞ システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して，それで入ってきた人材に C を書かせればよいのでは！(ﾋﾟｺｰﾝ!
藤堂
犯罪ですよそれは
安原
はい．
藤堂
安原
まさにそれをイメージしていました．
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
（この辺で一同寝落ち）
2016-08-26
■とある中高生向けSNSアプリで炎上中の運営会社のホームページ
いろんなところから「ゴルバチョフ～スターリンの略」と呼ばれている例のSNSアプリ。
その運営会社のお問い合わせページをSSLLabsにかけると、F判定(2016/8/25時点)。OpenSSLのバージョンアップをサボってるな。
https://www.ssllabs.com/ssltest/analyze.html?d=sprix.jp
プライバシーポリシーを見たら、"Java Script"だって。へー、JavaとScriptの間にスペース入るんだ。JavaのScriptってなーに？(棒読)在籍しているWebエンジニアから突っ込みは来なかったのだろうか。
そして、採用情報にある「人財こそが最も重要」。うわっ...。
ところで、運営会社批判をするだけでアカウントをBANするような言論弾圧をやっておいて「世界No.1の教育アプリ」なんてなれると思っているんだろうか。
2015-11-18
■ゲーム内チャットが諜報機関にとって悪夢である理由
テロリストがゲーム機(PS4)のゲーム内チャット機能を使ってるかも、っていう報道が出ている。
この件でPS4を叩いても仕方が無い。というのはPS4に限らずゲーム内のチャットはテロリストが会話を行うのに適した理由がこんなにも多いからだ
① 膨大なチャネル
会話経路がゲームの数だけ、星の数ほどある。NW的にはPSNを利用していても、プロトコルや暗号化方法はゲーム毎に異なるのでPSNの根っこで監視をしても結局各ゲーム毎に解析方法を作らなければならない。『釣天使』とかかわり合いたいと思うほど諜報機関は暇では無いだろう。
そして、ゲームの数はアーキテクチャの数であり、それぞれ異なる方式で情報が伝達されている。あるゲームではメッセージサーバ集中管理でも、また別のゲームではP2P通信だったりする。それらを複合的に扱っている場合もあるだろう。テロリストとは無関係な第三者のゲーム機をホストとして会話が行われ、運営者側では会話ログを一切持っていない、こんなケースはいくらでもあるだろう。
サイバー犯罪対策法はログ保存を事業者に義務づけているが、P2Pアーキテクチャではそもそも事業者との通信自体が行われていない。
② チーターとの戦いで洗練された暗号化
オンラインゲームの運営は常にチーターとの戦いだ。ゲーム運営者はゲーム機とサーバの間の通信が解読されないように暗号化を当然のように行っているし、鍵割れ対策として鍵交換も頻繁に行われている。また、暗号化アルゴリズム自体もカスタマイズしていることが多い。
平文でへろへろとメッセージが飛んで行くEmailとは根本的に設計・運用レベルが異なる。
③ 豊富なゲーム内コミュニケーション手段
ゲームの世界はコミュニケーションに使える手段が豊富だ。プレイヤー同士でコミュニケーションが取りやすいようにチャット機能の他にも各種のアクションやメッセージ伝達手段が豊富に用意されているし、符号化の方法さえ決めておけばあらゆるゲーム内のオブジェクトが通信に使える。
ポケモンを繰り出す順番でメッセージを伝えることもできるだろうし、ゲーム内のインクで床に書いても良い。そこから第三者が意味を感知するのはほぼ不可能だ。これらはもちろんログにも残らない。ゲーム内の全行動・全会話（音声含む）を保存しておけるようなリソースはどこの会社も持っていないし、そんなことに浪費しようとすれば株主が黙っては居ないだろう。
④ 木を隠すための森の存在
ゲーマーは攻略のために「強い目的意識」を持った「物騒な会話」を日常的に行っている。
何時に集合してなんとかを殺す、とか爆弾を仕掛けてXXが通ったら起爆するとか、普通の会話の中ではあんまり出てこないがゲーム内ではごく普通の会話だ。仮に傍受/平文に解読を出来たとしても、どれが善良な市民の会話でどれがテロリストの会話か識別するのは辛いことだろう。
追記：
大多数のITエンジニアが通信路暗号化の基盤として信頼していたOpenSSLに巨大な脆弱性"HeartBleed"が昨年発見され、その脆弱性をNSAが事前に把握していた、という昨年の事件はオープンな暗号化基盤さえも国家レベルの諜報機関に対しては大穴が空いている可能性を示唆するものだった。
このような背景の元では、テロリストが「通信の内容」よりも「通信の存在」の秘匿、そして事後の捜査のしづらさを重視したとしても不思議ではない。
ブコメやトラバでも指摘されているが、事後的に平文の会話ログや行動ログを運営会社に提出させることそれ自体は可能だろう。
しかし巨大IT企業や通信会社と比較して捜査慣れ（証拠提出慣れ）していない、しかも英語が十全に通じるか怪しい国にある運営会社からログを入手し、ゲームの仕様に依存するログを読み取る時間と手間を考えたとき、この夢と虚構と暴力の世界は秘密の謀りごとを埋める森として十分な広さがあるように思えるのだ。
2014-04-22
■サーバーエンジニア？ には何年ぐらいでなれるの？
大体20年ぐらいクライアント側のアプリをずっと作ってきたおっさんだけど、ここ1年ほど前にサーバー側に移った。
今までずっとWindowsで作ってきたから、何もかも新しいことばかり。
LinuxとFreeBSDのどっちがいいかわからないから、CentOSとFreeBSDの両方で開発している。
Shellスクリプトもちょこっとわかるようになった。
今は主にErlangで０から開発した数十台に分散して動くサーバーを運用している。
言語を覚えるのは苦ではなくて色んな言語を使うことができるけど、OSはなんだか別な感じがする。
今日、FreeBSDのOpenSSLのアップデートをしたらサーバーに繋がらなくなって、なんかpsshとかも動かないし、もうわけわからなくて全部再インストールすることにした。
分からないなりにいろいろ頑張って実際にサーバーを運用しているけど、知識の足りなさを実感している。
俺はもう40代だから、やっぱり脳みそがだめなのかなぁ、とか思いながら今自棄酒飲んでいるところ。
今、第一線で活躍している人はだいたい何年ぐらいでまともに”使える”ようになったんだろうか？
教えてほしい。