Shozo Hatta hachi8833

Git 2.26.0以下にある脆弱性

Git 2.26.0以下^＊1には、細工したリポジトリをgit cloneしたときに、そのユーザーのCredential(たとえばGitHub.comをcloneするときに使う認証情報)を奪い取れる脆弱性があります。

📝 取得できる認証情報は credential.helper の設定に依存する

既にPoC(検証するためのコード)もあり、結構簡単なので是非Gitを2.26.1以上にアップデートしましょう。 git submoduleを使うと見た目ではわかりにくい攻撃もできるので、「気をつける」では回避は難しいです。

1章冒頭の本文「この章のおもちゃのアプリ (toy_app)」の箇所は一部の書体が斜体になっている。また"toy_app"のフォントスタイルが前後の段落の"hello_app"や"sample_app"と一致していない。

1.1.2本文の「例えば、サンプルアプリケーションproduction.rbの設定ファイルは」の箇所は、原文の「the sample application」については直後に示されるパス表記が"/home/ec2-user/environment/sample_app/"であることから日本語訳としては"sample_app"を当てて、全体として語順を整え「例えば、sample_appの設定ファイルproduction.rbは」とするのが好ましいように思われる。

1.3.3本文の「2.2.2では、このtoyアプリを使って」の「この」は不要と思われる。原文では"toy app"とあるが、これを"toy_app"とし「2.2.2では、toy_appを使って」とすることで文章の見通しが良くなるように思われる。同じ段落に「サンプルアプリケーションでは、MVCの3つの要素をすべて扱いします。」という箇所があるが、まず「すべて扱いします。」は誤記と思われる。また"サンプルアプリケーション"の箇所は原文では"sample app"となっており、文脈的には"sample_app"と表記した上で「sample_appでは、MVCの3つの要素を」とするほうが文章の見通しが良くなるように思われる。

2章全般で sample_app を示す単語として「サンプルアプリケーション」を用いているが、読者にとっては hello_app も toy_app も sample_app も全て「サンプル」アプリケーションと言えるので、表記上の区別をつける方が良いように思われる。

2.2.2本文の「このようなマッピングするコードは」は「このようなマッピングをするコードは」とする方が好ましい。

jsprimerというJavaScriptの書籍を書いている。これを書いてるときに参考にしているものを書いていく。

ECMAScript® Language Specification

ECMAScriptのLiving Standardな仕様書ページ。スナップショットなECMAScriptの仕様書ページもあるけど、基本的にはLiving Standardの方しか見てない。

Standard ECMA-262

最新のステータス: 追記: 2019/7/10

転職しました。長らくのご愛顧誠にありがとうございました。

転職先をちょくちょく探しています。

興味ある方は twitter @mizchi へのリプライorDM、または mizchi2w@gmail.com まで。

ホモトピー型理論(HoTT)に入門するために

前置き

HoTTに興味があるCS系の学生が、HoTT本の冒頭を読んだ体験を元に、知っておくと学び易くなりそうな話をまとめてみた。

対象は自分と同じ、型理論は少し知ってる^[1]けどホモトピーとかわからんという人。「型理論は知らんけどホモトピー論と圏論の用語はわかる」という人はそのまま本読めばいいと思うし、両方ともわからない人は学ぶモチベーションがよくわからない(し、とりあえずどちらかを学んだ方がいいと思う)のでとりあえず無視する。

HoTTについてはさわり程度の知識しかないまま書かれているため、話半分に読んでもらった方がいいと思う。

1. 「依存型に触ったことある」もしくは「TaPLを部分的にでも読んだ」あたりが基準になるだろうか。

I am passionate about Ruby, but its execution time compared to other languages is extremely high, especially when we want to use more complex algorithms. In general, data structures in interpreted languages become incredibly slow compared to compiled languages. Some algorithms such as ´n-body´ and ´fannkuch-redux´ can be up to 30 times slower in Ruby than Go. This is one of the reasons I was interested in embedding Go code in a Ruby environment.

For those who do not know how shared libraries operate, they work in a similar way as DLLs in Windows. However, they have a native code with a direct interface to the C compiler.

Note Windows uses the DLL system, and in this case, this does not necessarily have to be in native code.

One example is DLLs written in C#, which runs on a virtual machine. Because I do not use windows, I ended up not testing if it is poss

	<!-- Some form -->
	<div data-controller="auto-grow-textarea">
	<%= form.text_area :body, cols: 20, row: 2, placeholder: 'Bir yorum yazın...', class:'form-control', data: { action: 'input->auto-grow-textarea#resize', target: 'auto-grow-textarea.input' } %>
	</div>
	<!-- Some form continued -->

	OBJS = \
	bio.o\
	console.o\
	exec.o\
	file.o\
	fs.o\
	ide.o\
	ioapic.o\
	kalloc.o\
	kbd.o\

	require 'bundler/inline'

	gemfile do
	source 'https://rubygems.org'
	gem 'colorize'
	end

	class MatcherInterface
	def initialize(some_object)
	@some_object = some_object

	require "active_support"
	require "active_support/core_ext/string/output_safety"
	require "objspace"

	def assert_same_object(x, y)
	raise unless x.object_id == y.object_id
	end

	def assert_not_same_object(x, y)
	raise unless x.object_id != y.object_id