  |
はてなキーワード: バックドアとは
ゴールデンウィークに入る直前明日に迫った地方から東京への引っ越し作業で焦っていた。
気にしていたのは、賃貸住宅の掃除や過失、そして片付けが間に合うかどうかであった。
引っ越し先は約1/2になる部屋の狭さのため、持っている本はすてなくてはいけない。
手元にある500冊を超える背表紙を眺めながら、専門書や小説を、自炊専門業者の表現ーあなたの部屋の家賃は本の部分も存在する（意訳）ーに諦めヤマト運輸から本詰めの段ボール箱をもらってきて荷造りしているところだった。
引越し業者へ渡す時間はあと2時間しかない、汗が大量にでるなか焦ると悲しい結果になる。焦ってはいけない。必死になって捨ててよいもの、残すものを判断しダンボールに詰めていた。
一箱、また一箱、荷造りをし、それぞれを玄関先へ移動していた。玄関先には自家用車でこれらの箱詰めしたものを運ぶつもりである。
ふぅ。玄関先へ一通り荷造りが終わった。8箱になる。これらはOCRを行う専門業者へ運ばれまた必要であればフレーズを検索し前後が確認できるはずや。そのときは本とはちがうけどええやろーって思っているさなかだった。
さて自家用車へ玄関先から運ぶつもりやった。玄関口の扉を、運びやすいように広げっぱなしにし、バックドアを開け一つ一つを運んでいた。
ダンボールは8つ、1つは約40-50冊程度であろうか、せっせとはこんでいるがどうも視線を感じる。なんやろかー。
玄関先から車までは駐車場がめの前なので横着をして2メートル程度しかない状況である。
視線を感じるのは私のせいなのかと思い周りを見渡すと、
なぜかとなりのとなりの見知らぬ住居の方が、玄関先で男性同士でキスをしながら股間のあたりを片方が弄っていた。
1秒くらい停止してしまった。
見てはいけない、昨今はLGBTやでー、見てはいけない、これも純愛や、私にはやることはある、そう言い聞かせながら、ヤマト運輸へ行こうと決意してダンボールを運ぶ。
汗がでるとどうでもよいことは気にしなくなる。
残りの箱を運びながらこれも人生やなーと思いつつ、最後の箱を車のバックドアの下側へいれる。えいやーバタン。
男性同士で性的な何かを互いにする行為を私はみたことがなかった。
私は男性であり女性にはときめくし、見知らぬ男女がいちゃいちゃするのはええなーと思うし、女女がイチャイチャするのも同様に感じる。
ただ男男を目の前に唾液の伸びや、股間のあたりの互いの接触をみることに性的に違和感をもつことが信じられなかった。
生理的に無理は、男女のなかでも初めてみたり相手の性癖によってはある。
ただ、下呂や、露出されても何も感じなかったのにも関わらず、服を着ている状態の人たちをみて嫌悪感を持つ自分がびっくりしてしまった。
供養のためにここに記す。未だに忘れられない。
反ワクチンの人々の後押しをしたいわけではなくて、先日1回目の接種を終えて、待合所で待っている間に生まれた素朴な疑問。
やっと打てて少し安心と思う反面、例えばこのワクチンを要因として何か別の薬品を投与されたら確実にアナフィラキシーが発生してしまうなんてことってないのかな。
アナフィラキシーでもいいし、今回摂取した抗体の暴走でもいいし、要するにこのワクチンを打たなければ何でもなかったものが、ワクチンを打ってしまったことによって発症させることができるようになるという、いわばこのワクチンのバックドアのようなものってありそうな気がする。
人間の体ってそんなに単純ではないとは思うのだけど、もしかしたらこのワクチンが原因で何らかのアレルギーになる可能性は全くゼロではないわけだし。
そんなことよりもコロナのほうが困るからもちろん2回目も打ちます。
空想科学でしかない話ではあるけど、全人類の大半に仕込めるバックドアって夢があるよね。
そうなったらパッチワクチンを当てて対策をするのだけど、でも、ワクチンを不正入手したハッカーによってゼロデイアタックが発生して、、、とか、未来感がやばい。
教えて専門家さん！
あたなは何か勘違いしているナリ
HTTPプロキシは基本的に CONNECT メソッドを通じて通信するナリ
それ以外の場合は socks プロトコルで通信するナリ（なので基本的に Proxy を通すとは HTTPプロキシを通すということで、その場合 CONNECT メソッドが必ず必要）
CONNECT は基本的にHTTPメソッドを経由して通信するが socks は HTTP とは全く異なるプロトコルなり
（プロトコルというより通信のレイヤーが異なる。socksはISO参照のセッション層だがHTTPはアプリケーション層）
nginx, varnish, apache など適当なサーバーに自分でプロキシを建てて nc, telnet で通信してみればよく分かると思われる
ちなみに当職のおすすめのハッキング本は Hacking Exposure 7 ですを
ttp://www.amazon.co.uk/Hacking-Exposed-Network-Security-Solutions/dp/0071780289
カラッキング下準備
まず、基本となるLAMP自鯖を作って出来る限りのセキュリティを施すナリ
これでLinux系鯖の基本くらいは理解できるようにならないと侵入してもやることが無いナリ
次はツールの使い方を覚えるためにKaliLinuxとかを使って何とかして自鯖のセキュリティを破って侵入するか
自分でSQLインジェクションとかXSSとか書いて侵入するナリ
なお、簡単に入れる鯖はセキュリティ意識低いので拾ってきたバックドアでも問題無いナリ（例えばrootパスがデフォ設定の所とか）
ここまで来たら後は近所の無線をaircrack-ng等でカラッキング→tor+tsocksかproxychains辺りを使って恒心するナリ
これまで主に通信で使われてきた光技術を、端末やサーバーでの情報処理にも適用します。具体的には、デバイス内のチップ間やメニーコアチップ内のコア間の伝送、チップ内の信号処理なども光化することで、光から電気への変換処理を不要にし、低消費電力や低遅延を実現します。
これがオールフォトニクス・ネットワークです。NTTはオールフォトニクス・ネットワークの目標性能として、低消費電力、低遅延、大容量・高品質の3項目をそれぞれ現在の約100倍の向上を目標としています。
いまGbeはメタル結線だがそこも光になるというかんじなのね。
10GbeのSFPモジュールとか既にあるけどそれの100倍速くて安くなる感じか。
中国がバックドア仕込んだ5G機器を売り込んでくれたおかげで、世界の視点が相対的に日本勢の信頼度をふりかえるようになってくれた感じか。
https://www.gizmodo.jp/2021/03/5-reasons-to-ditch-gmail-for-protonmail.html
エンドツーエンド暗号化とゼロアクセスはProtonMailが約束する重要な特徴のひとつで、ProtonMailさえもユーザーのメッセージを読めません。そのうえ、コードと暗号化ライブラリはオープンソースであって誰でも見ることができるので、秘密裏にバックドアを隠せっこありません。
ちょっと疑問なんだけど、本番環境でソレが使われてるって保証はどうやってしてんの？
https://b.hatena.ne.jp/entry/4699887283822227714/comment/theatrical
ossだからバックドアが仕掛けられないと言う主張はおかしい。ossでもコードいじってバックドア仕掛けることはできるし。これはwebclientのjsで暗号化してるから、実際の暗号化処理が確認できて安全と言う方が正しいと思う
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
